tcp — настольное SCADA-приложение — чтение и запись в ПЛК через переполнение стека
Я приложил все усилия, чтобы найти все темы, относящиеся к 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
Решение
ИМХО программа 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#freesource
Согласно этому http://www.control.com/thread/1026173407 Вы должны быть в состоянии получить исходный код Kepwares OPC Quick Client.
Вероятно, было бы проще просто использовать библиотеку, как в этом примере (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/$ Файл / rslinxsdk_ma_eng.pdf
Некоторые ресурсы:
http://www.opcconnect.com/ ,
http://www.mesta-automation.com/
взгляните на pycomm в github или pylogix на github, которые представляют собой написанные на Python драйверы для связи с clx plc.
Ответ на вопрос № 4 — осознайте, что технически ваша лаборатория может содержать ПЛК ЛЮБОГО производителя в будущем. Если вы когда-либо брали класс Data Communications, вы понимаете, что для N разных типов ПЛК вам придется написать N разных драйверов связи для вашего клиента ПЛК.
Здесь стандарты полезны. Без использования стандартного протокола масштабирование вашей лаборатории может стать более трудоемким и менее управляемым. Вот почему существуют стандарты связи.
ОДНАКО, не все ПЛК обязательно поддерживают стандарт (ы), по которому вы можете принять решение.
Лучший выбор — OPC / UA. Многие ПЛК имеют серверные драйверы, легко доступные. Это означает, что ваш клиент просто должен понимать 1 протокол (OPC / UA), и тогда он может «легко» подключиться к любому ПЛК, в котором есть драйвер для этого стандарта.
После этого идет OPC. После этого Modbus (разновидности TCP и RTU) — относительно простой отраслевой стандарт, который поддерживается большинством ПЛК. EtherNet / IP также является возможным выбором, хотя не все ПЛК поддерживают его в роли «сервера» (многие поддерживают его как клиента, но это не то, что вам нужно).