Для меня это до сих пор загадка, как например тот же Овен это делает. Они делают ПЛК под среду Codesys, вероятно и рантайм (транслятор с языков МЭК) предосавляет тот же Codesys. И видимо совсем не бесплатно.
Да и транслятор это одно, а пошаговая внутрисхемная отладка языков МЭК из среды — это отдельная тема, как она реализуется, мне тоже непонятно.
А то сейчас много «ПЛК», вон на ардуине несколько «ПЛК» есть в инете, только на поверку оказывается что никакой это не ПЛК.
С++ прекрасный сильнейший язык программирования. На нем можно запрограммировать любые задачи. Но, это компьютерный язык, а не язык спроектированный специально для ПЛК. Тут есть определенные особенности.
1) Для ПЛК важно иметь интегрированные отладочные средства,
заточенные под специфику автоматизации. Они должны позволять производить технологические операции с оборудованием. Например, при ремонте/наладке некой машины, техник/электрик/механик может машину остановить, вручную поуправлять выходами, проверить входы, зафиксировать выходы и т.п.
В CoDeSys это делается элементарно. Никаких программ писать не нужно вообще. Ни в одной среде С++ этого нет и близко. Там для элементарного задания нескольких последовательных наборов значений выходов, технику надо звать программиста и тратить время на программу.
2) Для ПЛК практически наплевать на эффективность кода, размер программы, экономию памяти, без которых не обойтись, например в базах данных, играх, при запуске непредсказуемо разных приложений пользователя и др. и пр.
Для ПЛК генератор кода должен давать простой дубово-надежный машинный код. Огромные массивы данных тут гонять не нужно. Рядом с ПЛК нет человека-контролера, который бы его перезагрузил при зависании. Да и сам подобный факт может быть фатальным. Поэтому из языков ПЛК намеренно выброшены все потенциально опасные штуки, типа new. В мире широко известны несколько громких аварий по причине примитивных программных ошибок в Си. В МЭК подобные ошибки сделать просто нельзя.
3) ПЛК всегда работает в реальном времени. В МЭК системы встроены свои переносимые средства многозадачности, обеспечения времени цикла, вызова задач по фронтам и т.п. Программисту МЭК нет дела какая ОС сидит внутри ПЛК. Изучать ее функции не надою. В С++ без этого никуда. Своих подобных средств в нем нет, он опирается на ОС. Ее надо изучать.
Ее качество влияет на программу непосредственно. Перенос программы из одной ОС в другую (если сразу не приняты специальные меры) представляет сложность.
4) Языки МЭК значительно проще в освоении. Это не декларация, а факт. Мы не раз сталкивались с обучением техников/наладчиков на заводах. Максимум полдня и электрик уже может выполнить минимально необходимые ему действия сам. Шансов его обучить С++ за полдня ноль. С++ язык для программистов профи. Он позволяет залезать на низкий
уровень и эффективно программировать на уровне железа. Ест-но такие программы требуют знаний, тестирования, по специальным методикам и пр.
5) Часто для некоего электронного устройства 1 программист пишет все от формирования времянок микросхем, до прикладных вещей на С++. Программа выглядит одним большим винегретом. Никто, кроме автора в этом разобраться не может. Он незаменим и обязан сопровождать свою программу, даже если это ему совсем уже не хочется. Руководитель не может отдать это сопровождение молодому специалисту, а этого квалифицированного человека перевести на более выгодную работу. Ни в от отпуск, никуда… У нас это классическая судьба С++ программиста.
Теперь делим софт на системный уровень и прикладной. Между ними простой, четко описанный интерфейс. Это переменные ввода/вывода и системные биб-ки. Системный софт четко разграничен и понятен. Его может писать любой программист, даже наемный. Его легко заменить. Аналогично с прикладным.
Это широко известная старая концепция разделяй и властвуй, но верная и ныне. Подробнее тут.
Для системного уровня С++ прекрасно подходит. Для прикладных задач МЭК языки прекрасно подходят.
Все ограничивается что есть пользователи ПЛК, у них например есть Codesys. Программируется ли ваш ПЛК из Codesys? Нет? Значит есть своя среда с поддержкой одного из популярных языков? Нет? Аа, можно в IAR на С++ запрограммировать? Чудесно.
Для программирования ПЛК используются стандартизированные языки МЭК (IEC) стандарта IEC61131-3
Языки программирования (графические)
LD (Ladder Diagram) — Язык релейных схем — самый распространённый язык для PLC
FBD (Function Block Diagram) — Язык функциональных блоков — 2-й по распространённости язык для PLC
SFC (Sequential Function Chart) — Язык диаграмм состояний — используется для программирования автоматов
CFC (Continuous Function Chart) — Не сертифицирован IEC61131-3, дальнейшее развитие FBD
Языки программирования (текстовые)
IL (Instruction List) — Ассемблеро-подобный язык
ST (Structured Text) — Паскале-подобный язык
Я 4 KB использую как буфер значений датчика. При отключаниях питания буфер не стирается, этим гарантируется непрерывный мониторинг.
Ну и плюс в этих 4 KB хранится запись SytemHealth, там вся инфа о возникших ошибках/ассертах, срабатываниях вочдога и т.д. за все время работы. Очень помогает увидеть качество работы устройства в реальных условиях у заказчика. А то может быть ситуация когда девайс у заказчика перезагружается по вочдогу, а разработчик об этом никогда и не узнает.
Общаться через COM порт многие могут.
Да и транслятор это одно, а пошаговая внутрисхемная отладка языков МЭК из среды — это отдельная тема, как она реализуется, мне тоже непонятно.
А то сейчас много «ПЛК», вон на ардуине несколько «ПЛК» есть в инете, только на поверку оказывается что никакой это не ПЛК.
О С/С++ речи нет.
Ну и плюс в этих 4 KB хранится запись SytemHealth, там вся инфа о возникших ошибках/ассертах, срабатываниях вочдога и т.д. за все время работы. Очень помогает увидеть качество работы устройства в реальных условиях у заказчика. А то может быть ситуация когда девайс у заказчика перезагружается по вочдогу, а разработчик об этом никогда и не узнает.
Очень интересно бы подробнее, процесс так сказать в красках.