Настольное SCADA-приложение - чтение и запись в ПЛК через C++
Я приложил все усилия, чтобы найти все темы, относящиеся к SCADA и разработке собственного настольного приложения на C++ для связи с ПЛК, но не смог найти ни одной недавней или, по моему мнению, соответствующей темы, которая бы соответствовала моим потребностям. Если бы я их пропустил, ссылка на них была бы очень признательна. Если я случайно разместил это в неправильном разделе, или вы можете придумать лучший раздел, чтобы я мог опубликовать это, я возьму его туда.
С учетом сказанного я заранее благодарю вас за то, что вы нашли время прочитать мои вопросы, и благодарю вас за любые предложения, которые вы можете предложить.
Немного о том, что я делаю
В настоящее время я учусь в школе электромеханики, и для своего последнего учебного года я разрабатываю настольное приложение на C++ для мониторинга ПЛК, которые мы разместили в одной из наших лабораторий.
В этой лаборатории у меня есть уже существующая сеть Ethernet, соединяющая все ПЛК в единую точку, к которой я подключаюсь с ПК, и буду выполнять всю свою работу оттуда.
Я буду разрабатывать приложение на Qt для простого способа разработки графического интерфейса и предоставления мне доступа к QNetworkInterface, а также к QTcpSocket.
С учетом сказанного, я бы не сказал, что являюсь опытным программистом, но я дурачился с несколькими языками (например, python, C++, c, php) уже несколько лет, и до сих пор обучение, учитывая, что обучение НИКОГДА не останавливается.
Мои вопросы
Могу ли я прочесть какой-либо справочный материал, который вы можете предложить по этому вопросу, чтобы легче понять, какой процесс мне нужно пройти для получения информации (т. Е. Отдельные операции ввода-вывода, биты состояния, теги, журналы и т. Д.)...) из ПЛК напрямую, а не через OPC-сервер?
Если требуется OPC-сервер, я никогда не имел дело с ссылками OPC, кроме использования Rockwell Automations RSLinx для захвата тегов и отображения их значений в Excel (я создал прототип, используя этот точный метод для запуска, но хотел бы отойти от Excel, и, если возможно, OPC-сервер (RSLinx). Что бы вы посоветовали кому-то, кто ничего не знает о предмете серверов OPC или, насколько мне известно, OPC в целом?
Кто-нибудь из вас ранее написал свое собственное приложение, чтобы сделать что-то похожее, если не того же характера, что я пытаюсь сделать?
Какой совет или предложение вы бы дали тем, кто пытается реализовать этот тип проекта?
PS: Для начала этого проекта я бы просто хотел получить показания входов / выходов (теги или адреса), чтобы увидеть их текущие значения (закрыты или открыты для входов, под напряжением или нет для выходов). Но в конечном итоге я также хотел бы иметь возможность записывать значения в теги ПЛК, которые я отслеживаю, основываясь на значениях, которые я получил от них.
PSS: Я хотел бы еще раз отметить, что я все еще студент, и все еще изучаю этот предмет в целом. Я просто хотел бы попросить вас о терпении, так как я не могу понять вещи с первого раза!
Если я пропустил какую-либо информацию, которая, по вашему мнению, уместна, чтобы дать ответ, пожалуйста, дайте мне знать! Я сделаю все возможное, чтобы своевременно представить эту информацию!
Спасибо!
РЕДАКТИРОВАТЬ # 1: Добавлено в другой вопрос, и немного изменил мой первый вопрос
РЕДАКТИРОВАТЬ № 2: Исправлен вопрос 2
4 ответа
ИМХО программа SCADA должна иметь как минимум требование для возможности подключения к серверу OPC. OPC используется для большинства коммерческих ПЛК.
Строго говоря, нет необходимости в подходе OPC-сервер / клиент, но он дает вам гибкость и модель абстракции. Если вы хотите напрямую подключаться к ПЛК по протоколу, то это, конечно же, возможно. Затем вам нужно узнать больше информации о протоколах и их различных версиях.
Да, я работал в течение нескольких лет в команде, которая разработала коммерческое приложение SCADA.
В таком проекте очень легко потеряться в деталях, поэтому постарайтесь сделать все как можно проще. Используя OPC, вы сэкономите время, а не возитесь с протоколами напрямую. Вы можете добавить возможность добавления пользовательских драйверов для других протоколов - в зависимости от вашего таймфрейма. Попытайтесь смоделировать свой проект, прежде чем приступить к кодированию с высоты птичьего полета модели и не потеряться в деталях.
Я бы не стал писать свой собственный код для прямого подключения к ПЛК AB - есть продукты, которые вы можете использовать в своем приложении: http://www.rtaautomation.com/software/ethernetip/client/tagc/ControlWin.html http://www.automatedsolutions.com/products/dotnet/ascomm/
Вам было бы лучше использовать OPC - вы можете написать свой собственный клиент OPC, если хотите, и следовать примерам, которые вы найдете здесь: http://www.opcconnect.com/source.php
Согласно этому http://www.control.com/thread/1026173407 вы сможете получить исходный код быстрого клиента Kepwares OPC.
Вероятно, было бы проще просто использовать библиотеку, как в этом примере (RSLogix, C#): http://www.mesta-automation.com/opc-client-with-c-an-how-to-video/
Вы можете найти это использование: http://www.rockwellautomation.co.kr/applications/gs/ap/GSKR.nsf/files/rslinxsdk_ma_eng.pdf/$ file / rslinxsdk_ma_eng.pdf
Некоторые ресурсы: http://www.opcconnect.com/, http://www.mesta-automation.com/
Ответ на вопрос № 4 - осознайте, что технически ваша лаборатория может содержать ПЛК ЛЮБОГО производителя в будущем. Если вы когда-либо брали класс Data Communications, вы понимаете, что для N разных типов ПЛК вам придется написать N разных драйверов связи для вашего клиента ПЛК.
Здесь стандарты полезны. Без использования стандартного протокола масштабирование вашей лаборатории может стать более трудоемким и менее управляемым. Вот почему существуют стандарты связи.
ОДНАКО, не все ПЛК обязательно поддерживают стандарт (ы), по которому вы можете принять решение.
Лучший выбор - OPC/UA. Многие ПЛК имеют серверные драйверы, легко доступные. Это означает, что ваш клиент просто должен понимать 1 протокол (OPC/UA), и тогда он может "легко" подключиться к любому ПЛК, в котором есть драйвер для этого стандарта.
После этого идет OPC. После этого Modbus (разновидности TCP и RTU) - относительно простой отраслевой стандарт, который поддерживается большинством ПЛК. EtherNet/IP также является возможным выбором, хотя не все ПЛК поддерживают его в роли "сервера" (многие поддерживают его как клиента, но это не то, что вам нужно).
Взгляните на pycomm в github или pylogix на github, которые представляют собой написанные на Python драйверы для связи с clx plc.