Comments 46
Я не настоящий электронщик, но вроде да - опторазвязка стоит в количестве
Не, так, к сожалению не получится. Тут всё завязано на циклическое выполнение.
Вот смотрите, допустим ПЛК крутит 100 мс цикл (ну то есть десять циклов в секунду), а мы в нашем коде хотим что-то делать только один раз в секунду. Sleep(1) тут не покатит (даже если мы насильно попытаемся задержать исполнение, то ПЛК вывалится в ошибку).
Делают примерно вот так:
#include <AsIecCon.h> // Заголовок для МЭК 61131-3 функций
TON_typ myTimer; // собственно таймер
void _INIT ProgramInit(void)
{
Counter = 0;
myTimer.IN = 1;
myTimer.PT = 1000; // 1 секунда задержка
}
void _CYCLIC ProgramCyclic(void)
{
// Циклически вызываем таймер
TON(&myTimer);
myTimer.IN = 1; // Стартуем и работаем пока не прилетит Q
myTimer.PT = 1000; // 1 сек, можно менять от цикла к циклу
ElapsedTime = myTimer.ET; // тут лежит прошедшее время
// Проверяем, что время таймера пришло:
if (myTimer.Q) {
Counter++; // Тут что-то делаем раз в секунду
// Сбрасываем таймер
myTimer.IN = 0;
}
}Ну и вот:
И так со всем функциями, где требуется таймаут или ожидание.
Допустим, я коннекчусь к какому-нибудь серверу, да хоть к OPC UA, а ПЛК выступает клиентом. У "нормальных" программистов грубо говоря есть функция connect(IP, Port, timeout), и исполнение будет задержано на время таймаута, a здесь добавляется выход Busy, и connect будет всегда завершаться мнговенно после вызова, просто он будет держать выход "занято" активным до тех пор, пока не установит соединение (либо наступит таймаут), и его в цикле надо (именно надо) постоянно опрашивать.
Мне как-то раз кучу таких фунций надо было вызвать (там было много разных OPC UA Methods Call), так я препроцессором в некоторой степени выкрутился, спрятав туда проверку на "занято", код просто компактнее выглядел, но разворачивался примерно в то, что я выше показал.
А, теперь понял. Тут я не буду утвержать, что что-то похожее (или хтя бы внешне похоже выглядещее) сделать невозможно, в библиотеке sys_lib там есть пара фукций, которыми можно попридержать/возобновить исполнение циклической программы:
В общем надо будет попробовать, я этими функциями вообще никогда не пользовался.
В ПЛК есть SFC, зачем извращаться с написанием конечных автоматов на С++? Подозреваю, что в вашей реализации нет всего функционала, который даёт SFC для реализации шагового программирования, что делает ещё менее понятным смысл расписывать вашу реализацию КА на С++.
И да, стандарты на функциональную безопасность разрешают использовать для задач управления языки С/С++ с рядом оговорок, о чём я в статье не заметил упоминаний.
О, это очень хорошее замечание, спасибо. Мне подумалось, что С++ привносит определённую "гибкость", ведь там, пользуясь последними стандартами можно реализовать практически любой мыслимый функционал. Я (как программирующий в том числе на такой "эзотерике" как LabVIEW), вообще считаю, что язык программирования — это всего лишь язык и везде можно реализовать одно и то же, просто вопрос времени. Где-то одно удобнее, где-то другое. В конечном итоге итоге это может снизить общее время разработки при наличии достаточно гибкого и универсального фреймворка (мы ведь можем и свои библиотеки создавать). Что касается стандартов, диктующих применение тех или иных языков для задач управления либо налагающих ограничения, то я, к сожалению, не в той области, где эти стандарты строго применимы, в автомобильной промышленности всё достаточно "свободно". Впрочем мы делали системы и для проверки деталей турбин и лопаток, и даже там ограничений в требованиях не налагалось. Иногда заказчик требует определённый тип или производителя ПЛК, это да, но это лишь для того, чтобы избежать зоопарка железа — если у него всё предприятие на Сименсе, то "подарок" в виде B&R ему совершенно не нужен, так то ему совершенно без разницы, FB там или SFC или что ещё, хоть бейсик. Киньте пожалуйста, если не трудно, в комментарии номер стандарта на функциональную безопасность, я с удовольствием полистаю на досуге.
Почитал. Еще больше уверился, что нужно даже ST запрещать для ПЛК, не говоря про С. Увеличивает требования к персоналу, уменьшает читаемость кода. Практически нет шансов новому электронщику быстро понять программу. А это не просто редкость, это норма. за 2-3 года персонал АСУ на мелких предприятиях обновляется полностью. Иногда и быстрее. А если нужно решать обратную кинематическую задачу, ну так тут PAC и электронщику там все равно понимать нечего...
P.S. У автомобилистов misra С про безопасность...
Да не надо ST запрещать, он через какое-то время помрёт сам собой. А представляете, если бы персонал АСУ все как один знали паттерны из "банды четырёх", книги Роберта Мартина, вот это всё? На самом деле проблема существует, да, запустив код на С++ в ПЛК можно легко придти к ситуации "тут больше ничего не трогай, а то сломаешь". Вообще говоря я сам являюсь "адептом" графического и визуального программирования, беда в том, что в настоящий момент просто нет такого языка "общего назначения". Есть LabVIEW, есть то, что используется в ПЛК, но это всё довольно узкоспециализированные "нишевые" продукты. Хотя я бы хотел иметь LabVIEW в ПЛК, я в позапрошлом году программировал на LabVIEW Real-Time cRIO c FPGA на борту, это было круто, но это ни разу не промышленный ПЛК. Моё мнение таково, что в очень далёкой перспективе текстовые языки уйдут в прошлое, и программирование, в том числе и автоматики не будет таким, каим мы его видим сейчас. А так сейчас в промышленном секторе не то чтобы "застой", но такое "плато" — за последнее время мы в основноем переехали с Profibus на Profinet, с OPC на OPC UA, да ещё c PNOZ на Safety ПЛК, в остальном всё осталось как прежде. А тут какая-никакая свежая струя — игрушка с почти свежим gcc на борту.
За misra С спасибо, я читал стандарт NASA (Jet Propusion lab вроде), но только сейчас узнал, что он как раз на этом основан. С нас не требуют, но у нас другие сертификации типа NADCAP и стандарты ASTM, но это совсем другое.
В промышленности нужна не свежая струя не пойми чего, а стабильные, проверенные временем решения, к тому же совместимые друг с другом, что не возможно без соблюдения стандартов.
И да, немецкие автоконцерны стали внедрять Codesys для программирования бортовой электроники автомобилей. Надеюсь, понимаете, почему такое происходит.
Да, я прекрасно понимаю, я кручусь в этой области больше двадцати пяти лет (хотя я чуть из другого лагеря - мы приехали, запустили и уехали). Но тем не менее я б не стал называть С/С++ "не пойми чего", даже Ассемблер с LabVIEW не стал бы.
В промышленности всё довольно консервативно, я это вижу практически, это да. Но если посмотреть на мейнстримные, более-менее активно развивающиеся языки программирования, те же С++/С#, да хоть Питон, то станет ясно, что их развитие диктуется постоянно увеличивающейся сложностью систем, которые на них реализуют. В общем это называется "технический прогресс". Он может временами заруливать "не туда", но если попытаться реализовать на чистейшем Си то, что легко делается сейчас на высокоуровневых языках, то местами получится чудовищная цикломатическая сложность. Все эти ООП с синтаксическими сахарами — это просто борьба с этой сложностью.
Что касается автомобилей — у меня довольно навороченный гибрид как раз с мотором из видео, и вот логика взаимодействия с пользователем порой вызывает у меня желание поговорить по душам с дизайнером HMI — ты сам-то ездил на том, что ты разработал? Codesys тут не помогает. У вас в руках современнейшие средства разработки, ну сделайте удобно, но нет.
А, по поводу "не пойми чего" у меня есть пример. Короче, это был где-то 2002 год, я был молодой и горячий, мой начальник — тоже. Короче, повертев в руках PCI карту Profibus CP5613, он выяснил, что входы/выходы с ET200 можно читать прямо через OPC, безо всякого ПЛК. При этом если взять однопользовательский инлайн сервер OPC.SimaticNET.DP (кажется так), то ещё и лицензия не нужна. Он просил меня найти способ писать/читать Dual Ported RAM карты вообще в обход OPC, но тут я вежливо отклонил его инновации. Короче сказано — сделано. LabVIEW 6.1, DataSocket, благо поддерживает OPC и в путь. На заводе надо было видеть глаза главного инженера завода по АСУ. Подходит он к шкафу — видит кабель Profibus, видит ET200, не видит ПЛК. Спрашивает — а где ПЛК-то? Я ему говорю — а нет его здесь. Он видит комп, чуть морщится и говорит — "а, понял, там сименсовский софт ПЛК". Я ему говорю — не, там вообще нет ПЛК, СКАДА на LabVIEW напрямую управляет всей системой. Он смотрит на бодро движущийся конвейер, а вглазах немой вопрос "Как это вообще работает?". Экономия вылилась боком — почти весь бюджет был съеден постоянными командировками дорогостоящих специалистов, потому что обслуживать и модифицировать этого монстра ни сервис ни тем более АСУ отдел завода не могли. Вот это — "не пойми чего".
Хотя я вот, пока писал этот коммент посмотрел описание программного контроллера SIMATIC S7-1500 - там с первой же страницы Сименс задвигает про С++, так что процесс идёт
А пост — он имеет больше развлекательно-информационный характер, нежели руководство к действию.
Не нужна там никакая "свежая струя". Это Вам не айфон, который каждый год новый. В промышленности совсем иные требования и подходы.
Я в курсе, выше я коммент написал, но вот тут я просто оставлю скриншот со странички про SIMATIC S7-1500 Software Controller:
Там с места в карьер:
Так что местами плюсплюсы в требования и подходы промышленности вполне себе вписываются. Но всё хорошо в меру, это да.
Добрый день. Регулярно программирую плк Siemens, но поддержки C++ не встречал. Может это какая то опция в Тиа портале покупная?
Я тоже не встречал, но я программировал на Сименс где-то до 14 версии. Надо смотреть свежую, двадцатую версию, возможно это там добавлено...
Добрый день. Регулярно программирую плк Siemens, но поддержки C++ не встречал. Может это какая то опция в Тиа портале покупная?
Короче, я не поленился, скачал tia двадцатую, да поставил за завтраком
Возможности использования С++ там судя по всему сильно ограничены, потребуется мультифункциональный контроллер, вот этот, 1518-4 PN/DP MFP:
Ну и там появится слот С++
Единственно, я хз, куда там собственно код вкорячивать, B&R Automation Studio выглядит простой как пять копеек, а тут вот что:
Надо просто разобраться, я очень давно с Сименсом не работал. Но вроде С++ теперь есть.
ST это круто и удобно, с читаемостью и удобство всё отлично.
Вот пример считывания аналоговых входов на STL в Сименс:
// Считывание значений аналоговых входов и их пересчёт
FOR #iCycleAI := 1 TO "PER_AI_NUM" DO
#iSenType := "GVL_DAInputs".arSensors[#iCycleAI].iSenType;
IF #iSenType <> "SEN_TYPE_RES" THEN
"GVL_Config".arAInputs[#iCycleAI].wValue := PEEK_WORD(area := "MEM_AREA_IN", dbNumber := 0, byteOffset := "GVL_Config".arAInputs[#iCycleAI].diAddr);
END_IF;
END_FOR;
Спасибо за статью! Хоть всё и знакомо, но приятно, чёрт возьми, прочитать истины в отличном изложении!
Сам работаю в проекте разарботки Safety PLC уровня SIL3 на базе Codesys.
Спасибо за статью, но разве B&R и Siemens сейчас не труднодоступны?
Нет ли у кого опыта эксплуатации/внедрения open source сред программирования ПЛК в рамках перехода с B&R, Siemens на аналогичные решения? 4DIAC, например?
Спасибо за статью, но разве B&R и Siemens сейчас не труднодоступны?
B&R больше не поставляет оборудование, я видел пресс-релиз. У них, кажется, был офис в Москве, сейчас, вероятно, закрыт. Это, безусловно заметно снижает практическую ценность вышеизложенного материала, но тем не менее, мне подумалось, что кому-нибудь будет просто интересно, это так сказать популяризация автоматизации. Я с удовольствием читаю такие обзоры про любой ПЛК.
Что касается "труднодоступности" B&R и Siemens — я смею надеяться, что это не всегда будет так.
Так и не понял в чем преимущество программирования ПЛК на C.
На C программируют сложные глубоко встроенные системы. А ПЛК это про программирование только верхнего слоя и про масштабирование.
Если приходится вручную писать расчет SHA256 на ПЛК, значит неправильно выбран ПЛК. SHA считается уже давно аппартатно на STM32, ESP32 и прочей мелочи.
Если на ПЛК в демо-примере обрабатывается пара светодиодов, то тема ПЛК вообще не раскрыта.
ПЛК - это когда вы одним движением руки переходите от десятка сигналов к тысяче. И нужно лишь показать как это движение сделать и как увидеть лимит и не разрушить риалтайм. Нужна демонстрация в IDE масштабного рефакторига - одновременных операций над тычячами переменных таких как: переименования, мапирование на физические сигналы, редактирование типов и т.д.
Как тут поможет C непонятно.
Другое дело графические нотации типа Stateflow. У них хоть и нет нативной масштабируемости, но зато уникальная гибкость в рефакторинге архитектуры. Гибридная графическая нотация типа Stateflow гораздо легче воспринимается чем чисто текстовая.
Преимущество Си может проявиться лишь на узком классе задач. Иногда вычисления удобно оформить именно сишной библиотекой. Тема, которую я хотел раскрыть - это поддержка свежих С++ стандартов, что добавляет определённую скажем так, степень свободы. Ну а использовать или нет - это от задачи зависит, мы ж не используем крестовую отвёртку там, где нужен шестигранник. ПЛК это не всегда тысячи сигналов, в нашем случае их несколько десятков, но временами используются хитрые манипуляторы плюс безопасность.
Просто есть подозрение, что задачи тут не при чем. А речь о компетенциях.
Почему бы просто не признать, что вот при таком уровне компетенций и ресурсах мы выбираем вот такой ПЛК, других выбрать не могли, но нет времени на освоение ST и всех либ с API, поэтому еще и C используем.
Не вижу ничего в этом плохого, нормальная экономика в условиях ограничений.
Но маскировать одну причину некоей абстрактной свободой или некими задачами, это знаете ли так себе. Описали бы тогда вашу задачу. А то ни то, ни сё. Неинформативно.
Как выглядят кривые интерфейсы разных IDE полагаю и так все знают.
И это конечно, тоже. Как говорил Козьма Прутков: "нельзя объять необъятное". Если команда работает с определённым стеком технологий, то, конечно же отдаёт первое предпочтение хорошо знакомым языкам и паттернам, нежели бросается в неизведанные области. Само собой, при выборе определённого стека необходимо в совершенстве владеть всеми, тогда будет понятна применимость и удобство и будет возможность сделать реалистичную оценку трудозатрат на осное ТЗ.
Пример с ST - ну такое, он довольно примитивен сам по себе, ну вот что такого можно сделать на ST, чего невозможно или затруднительно на Си? Я уж не говорю о C++.
Кстати, данная логика работает и в обратную сторону. АСУ программисты порой "зашорены" своими ST/LD/FBD/SFC, поэтому возникает определённое отторжение других стеков, которые кажутся сложными.
В продакшене я использовал Си/С++ трижды.
В первой задаче нужно было сделать хитрый анализ коллизий. Я получал от системы с сервомоторов положение осей (там шестиосный манипулятор), геометрию оборудования, навешанного на этот манипулятор, плюс геометрию детали в виде 3D модели. Задача была в реальном времени анализировать коллизии при ручном перемещении манипулятора джойстиками (это нужно для обучения манипулятора, так-то система автоматическая). Поставить лазерную защиту было затруднительно в силу ограниченности пространства и постоянно меняющейся конфигураии. Если вы программировали роботов типа Kuka или ABB, то знаете, что там это есть. Я же сделал 3D симулятор на LabVIEW и разработал код на Си, который затем просто отдал АСУ программисту, он был интегрирован в проект, который также вначале обкатали на Digital Twin c Industrial Physics. Я б реально помер делать это на чём-то ещё, тем более что все базовые алгоритмы-кирпичики всяких пересечений полигонов и трейсинга для Си сто раз написаны.
Вторая задача была написать универсальную библиотеку конечных автоматов. Походу в конечных автоматах ничего сложного — там просто состояния и переходы, но в нашем случае переход из состояния в состояние сопровождается "перебрасыванием" детали, к которой приаттачен пакет данных (тип, серийный номер, результаты проверки и т.д.). Поскольку мы делаем кастомные системы на заказ, то конфигурация каждый раз разная, и метаданные разные, и нехитрый самодельный тулкит реально экономит время на написание новых автоматов, така как их не нужно делать с нуля, а просто "конфигурировать", грубо говоря. Тут ООП очень помогает.
На рендере одна из систем вот как-то так выглядит, там конвейер, пара лифтов для загрузки/выгрузки, пара роботов да манипулятор внутри, каждая часть работает под управлением своего автомата, они общаются друг с другом, обмениваются данными, при этом они однотипны, просто наследуются от одного класса, там фабрика:
Ну а третья задача была написать OPC UA клиента для B&R для "внешнего" OPC UA сервера. Сервер в ПЛК поднимается парой кликов, а вот для клиента нет, там есть библиотека "сделай сам". И всё бы ничего, но там была куча OPC UA Methods Call с кучей параметров, которые ещё и парсить надо было хитрым образом. Я сделал это на Си, причём на всю катушку используя препроцессор, и он меня очень выручил, сильно упростив код. Я реализовал бы это и на ST, положив, вероятно, втрое больше времени.
Раньше так про С говорили те, кто писал на ассеблере. А до них про так про ассемблер говорили те, кто набивал перфокарты. А до них про перфокарты так говорили те, кто считал на счетах. Угадайте что говорили о тех кто считал на счетах те, кто ...
В общем именно так, "высокоуровневость" языка позволяет выражать всё более сложные конструкции более простым представлением, и по итогу мы в профите.
Но что касается визуалки, то я вот по просьбе одного из читателей добавил немножко (там про сокеты вопрос был, промотайте выше до раздела "Обновление 22 декабря 2024", если любопытно), и вот там есть:
Код на Питоне
import socket
import struct
PLC_IP = "127.0.0.1" # куда коннектимся
PLC_PORT = 1234 # порт
print("Connecting...")
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((PLC_IP, PLC_PORT))
try:
while True:
sock.sendall(b"R")
data = sock.recv(4)
counter_value = struct.unpack(">I", data)[0]
print(f"Counter value: {counter_value}")
except KeyboardInterrupt:
print("Stopping...")
finally:
sock.close()И ровно тоже самое на LabVIEW, вообще один-в-один:
Мне вот (чисто субъективнo) в данном случае визуальный язык нравится больше.
что мешает визуалке "под капотом" генерить не странный текст, завязанный строго на одного производителя,
Ну это собственно и не нужно, LabVIEW гонит визуалку прямо в машинный код (точнее по капотом через LLVM гонит), и оно достаточно резво работает.
Попыток привести это к текстовому виду было предприято две, обе провалились. Первая - был такой тулкит "С code generator". То, что там генерялось было предназначено для "роботов", это реально каша была, в которой человеку без поллитра не разобраться. Сейчас закрыт. Вторая попытка называлась LabVIEW NXG (в смысле NeXt Generation), там визуальный код выгонялся в XML (нам же ещё расположение элементов надо хранить и т.п.), но они сделали ставку на .net, переписав это всё на Шарпе с WPF. Сказать, что это тормозило — это ничего не сказать. Запускаешь IDE и идёшь на перекур. Они так и не смогли догнать основную LabVIEW по функционалу, и проект тихо помер.
Беда в том, что на визуальные языки общего назначения сейчас нет стандарта. Как только он выкристаллизуется - всё будет норм.
Я бы сказал что "высокоуровневоcть" тут не при чем.
Вы же изобразили в графике примитивный счетчик, а не нечто высокоуровневое. И ничего ведь, удобно.
Вы изобразили аналог нотации Simulink, это немного не то. В LabVIEW аналогом нотации Stateflow является Statechart.
Это не то, на чем можно весь софт разработать, но это идеальные нотации для конечных автоматов реализуемых в автоматизации. Причем написаные таким образом автоматы не привязаны не только к железу, но и к базовому языку. Их можно конвертировать и в ST и в С++ и в Python.
Удобство графической нотации в отсутствии имён. На своей диаграмме вы могли бы вообще не писать никаких названий, и она бы осталась рабочей. А еще иерахичность и следовательно невероятная гибкость рефакторинга. НО эти фичи становятся чувствительными и значимыми при гораздо больших размерах проекта.
НО эти фичи становятся чувствительными и значимыми при гораздо больших размерах проекта.
Это так, да. Но если следовать правилу одна диаграмма - один экран, не использовать без нужды диаграммы последовательности и сильно вложенные кейсы, провести разумную функциональную декомпозицию, да воспользоваться ООП, то в общем норм. Опять же есть тулкиты типа Actor или DQMH, они помогают.
Кстати, приложение, что там на видео, оно и написано на LabVIEW от начала и до конца, эти индикаторы ни с чем не спутаешь (хотя нет, времякритичные части там на Си + интеловский компилятор):
Причём это, на секундочку, LabVIEW 7.1.1, аккурат двадцатилетней давности, там классов вообще не было.
Тут уже не понял.
Если взяли ПЛК, то сключительно для реального времени, иначе это уже не ПЛК, а одиозный ПК. Так вот Actor или DQMH как раз убивают реальное время. Очереди не могут образовываться в системе жесткого реального времени. Потому что планирование очередей основано на статистике, а не детерминизме.
Не, я видно не так выразился. Программа на LabVIEW - это фактически СКАДА, причём часть машинного зрения. Она не заменяет в данном случае ПЛК, она работает вместе с ним. ПЛК управляет частью конвейера, общается с роботом, ну там кнопки на пульте, вот это вот всё, ну и всё время критичное крутится в ПЛК, само собой. А наружу торчит OPC, программа на LabVIEW получает оттуда данные "деталь такая-то, робот приехал в позицию", тогда хватает рентгеновскую картинку и говорит ПЛК (а тот уже — роботу) - ехай дальше. В конце проверки сообщает ПЛК - хорошая деталь или плохая, вот и всё. Времякритичных частей в LabVIEW в данном случае нет вообще. Если нужно реальное время, то есть LabVIEW Real-Time и FPGA до кучи, но тут совсем не тот случай.
Сорри, но даже ChatGPT не понял что вы хотели спросить или сказать.
Если что, то технология выглядит так:
Человек создает свой софт в нотации Stateflow, потом он конвертируется в C, C++ или ST, потом он компилируется в ASM, потом ASM компилируется в машинные коды.
И вот что здесь интересно. ChatGPT не сможет с вами конкурировать в Stateflow потому что не тянет визуальные языки и неизвестно когда потянет.
А в C или C++ любого инженера переплюнет школьник использовав Copilot и Visual Studio Code. Уже это должно невероятно соблазнить "лудиттов".
А в C или C++ любого инженера переплюнет школьник использовав Copilot
Чем я, кстати и воспользовался, пока утром дополнение к статье писал. Ошибок он, правда, накидал знатно, но поправить их мне быстрее оказалось, нежели я б с нуля всё писал. Про библиотеки B&R он в курсе, циклические программы тоже, в общем не всё так плохо.
Пробовал B&R. Оборудование дешевле, но программистских человекочасов сильно больше. Невозможно там быстро разрабатывать, а дописывать код онлайн и сразу дебажить вообще тормоза. Сименс теперь тоже тормозной в разработке из-за неповоротливого тиапортала. И только Studio5000 от Rockwell оперативней всех. Разве что FTView не дотягивает до WinCC...
Полностью согласен. Ценник был основной причиной переезда с Сименс, но среда разработки местами раздражает, да и АСУ отдел стал больше. Единственно - Motion мне чуть удобнее показался - если автоматизировать, скажем сырорезку, где режущий нож синхронно с конвейером работает, то там просто пара щелчков и готово, либо если по хитрым траекториям перемещаться. Но я давно Сименс не смотрел, вот свежий двадцатый тиапортал хочу как раз на рожденственских каникулах погонять.
А как происходит общение по сети?
Обычным образом, поднимает сокет, если открылся он (от клиента), то начинаем читать-писать?
Или как-то можно штатно и без особых костылей например получить доступ до переменных?
В общем да, есть библиотеки, ПЛК может быть как сервером так и клиентом, я попробую на досуге набросать примерчик связи между Питоном и ПЛК. Делал такое на Сименсе, положил кучу времени (там был нужен хитрый протокол), тут должно быть попроще. Для доступа к переменным OPC UA вполне себе штатно. Либо если сокет открыт, свой протокол сделать, либо как вариант сдёрнуть и отреверсить протокол обмена между AS и ПЛК (если он не шифрован), но тут я не копал. У Сименса вот сделали реверсинжиниринг, но в продакшн с этим я б не пошёл.
Я за чашкой воскресного кофе набросал пару примеров, и добавил их в конец статьи. Промотайте выше до "Обновление 22 декабря 2024", там пример сокетов и OPC UA на Питоне в том числе.
дивно! Мало того что на Си прошивкой льется так еще окружение такое как будто интерпретируемый iec каконить, всякие там мапинги переменных
О программировании промышленного ПЛК на C++