Статья указывает на особенности разработки для промышленных контроллеров. Написана для объеденения программистов данного направления.
Кто такой этот ваш ПЛК
ПЛК (программируемый логический контроллер) – компьютер с особенностями развития. Главные требования к ПЛК: надёжность, низкая стоимость, быстрая реакция на входные воздействия, простота программирования. Данные требования привели к тому, что большинство производителей для своих ПЛК выпускают нативные среды исполнения и разработки. Но нельзя не отметить CodeSys – общеизвестный разработчик ПО для программирования ПЛК.
Несмотря на многообразие сред исполнения и разработки, программы пишутся на языках стандарта IEC 61131-3:
Графические языки программирования:
LD (Ladder diagram)
FBD (Function Block Diagram)
Текстовые языки программирования:
IL (Instruction list)
ST (Structured Text)
Реализации стандарта у разных производителей могут несущественно отличаться. Единый стандарт позволяет без особых проблем переносить код из одной среды программирования в другую.
Не как все
Самый "нормальный" язык из IEC 61131-3 – ST, который считается высокоуровневым языком программирования. Хочу обратить внимание, что под языком программирования подразумевается спецификация – правила написания кода. Время выполнения одного кода может меняться в зависимости от компилятора.
Самый важный момент, который стоит изучить, перед тем как писать код – это понимание принципов работы ПЛК. На рис. 1 изображена максимально упрощённая схема работы ПЛК.
Рисунок 1 -- Принцип работы ПЛК
Из рис. 1 нужно понять, что ваш код будет выполняться каждый цикл. Время цикла -- это время, которое нужно ПЛК для считывания входов, выполнения своих системных вызовов, выполнения вашей программы и формирования выходных значений. Обычно время цикла измеряется в микро- или миллисекундах.
Если в "классических" ЯП (языках программирования) первая программа выводит в консоль "Hello, world!", то в средах разработки программ для ПЛК вы консоли не увидите. Отладка происходит обычно во время выполнения программы, путём постановки точек останова, значения переменных в режиме отладки обычно накладываются на код, где они используются, причём значения можно изменять при отладке.
Прежде чем отлаживать проект – его нужно написать. И тут можно столкнуться со многими проблемами.
Сперва придётся ознакомиться со структурными единицами проекта: program organization units (POUs). POU может быть представлен как программа, функциональный блок или функция. У каждого элемента свои особенности. Типы данных такие же как и в других ЯП. Объявление переменных происходит в отдельной области перед кодом программы.
Следующая проблема – это подключение библиотек. Разные ПЛК используют разные ОС, устройства и протоколы. GitHub на моё удивление не знает про существование ST. В связи с этим остаётся надеяться на наличие нужных вам библиотек у производителя ПЛК. В случае наличия нужной библиотеки вам в редких случаях придётся ещё заплатить за её использование.
Использовать систему контроля версий в большинстве случаев бессмысленно так как ваш проект будет представлять один бинарный файл – проследить изменения будет сложно, не говоря уже про слияние проектов. Иногда производители предусматривают нативные инструменты для сливания(сравнивания проектов).
Все знают про самый используемый стек протоколов TCP/IP, но в промышленной автоматизации есть игроки поважнее, связано это с тем, что сетевые карты для Ethernet/IP/TCP стека довольно дорогие и требовательные к ресурсам устройства и устанавливать её в простенький блок питания или расходомер нерационально. На сцену выходят RS-232, RS-485, ModBus, CAN, ProfiBus, EtherCAT etc. Кроме знания протокола придётся "поковыряться" с мануалом, чтобы понять как формировать сообщения и какие ждать ответы.
Нормальные люди под frontend-ом понимают HTML, CSS, JS, у автоматизаторов это SCADA или HMI. Если кратко, то это ПО для разработки пользовательского интерфейса. Подавляющее число SCADA взаимодействуют с ПЛК посредством OPC-сервера.
При возникновении ошибок или если не знаете как реализовать ту или иную функцию, то Stack Overflow вам навряд ли поможет – скорее всего вам придётся "ковыряться" в документации производителя ПЛК.
Пора кончать
Получилось много текста, но это меньше капли в океане промышленной автоматизации. Каждой проблеме можно посвятить отдельную статью.
Но главной проблемой я считаю отсутствие площадок для обмена опытом между специалистами данной области. Данная статья нужна для привлечения внимания. Все проблемы решатся быстрее, если о них будут все знать, если решения будут проверены множеством специалистов.
Для дальнейших дискусий и связи предлагаю telegram чат и канал.
Ну и не забываем оставлять свои мысли и замечания в комментах. Надеюсь устроить хоть небольшой движ в этой сфере.
