В Factory I/O построена линия сортировки и сборки с управлением от ПЛК. Изделия перемещаются по цепному конвейеру и проходят через видеодатчик, который выводит цифры от 0 до 9 для определения типа и цвета. Два привода распределяют детали: правый — для крышек, левый — для сырья. Сырье поступает в станок с ЧПУ, который изготавливает основание изделия и укладывает его на поворотный стол. На левых конвейерах крышки останавливаются, когда их определяет видеодатчик. Их цвет сохраняется. Сборочная станция соединяет каждую крышку с основанием только при совпадении цветов. Затем манипулятор поднимает и укладывает готовое изделие.
Интерфейс 3osheet , среда разработки программ на LD, FBD, частично ST, и на псевдо-ассемблере (инструкции виртуальной машины)
Все началось с работы, где я занимался системным администрированием в промышленности. После того как уволился, зная в чем нуждаются предприятия, разрабатывал собственную систему SCADA. Но решил пойти еще дальше в сторону разработки настоящего промышленного контроллера.
Цели которые поставил перед собой:
1) Среда разработки, отображающая в режиме реального времени значений переменных и место выполнения код .
2) Гибрид LD и FBD. Возможность создавать свои блоки (рисовать, и описывать на псевдо ассемблере для виртуальной машины).
3) Создание среды выполнения программ на стороне - микроконтроллера (или ПК если это SCADA).
4) Разработка изолированой среды выполнения (виртуальная ОЗУ) с заменой кода на лету. Например - отключить задачу, через MODBUS переписать или изменить ее программу, и запустить выполнение, и при этом не останавливать другие задачии и не перезагружая ПЛК физичесски.
Являюсь фанатом - оптимизации, восхищаюсь способностью выжать из минимум ресурсов - максимум эффективности. Потому выполнил важную цель - разработка и запуск виртуальной машины (собственной виртуальной машины, об этом в следующих статьях) выполняющий программу ПЛК на микроконтроллере с 8 KB ОЗУ!
Среда разработки. Написана на OpenJDK, Java весом 80мб с самыми примиитивными GUI. Легкая и работает даже на старых Raspberry PI. Если установить IDE(среду разработки с компилятором) и среду выполнения на CPU, получится самодостаточноый ПЛК Сервер, способен сам себя перепрограммировать(пользователем) без внешнего ПК.
LD программы не имеют ограничений по сложности, можно безконечно вставлять ветки друг в друга в любом месте, насколько хватит ОЗУ на стороне микроконтроллера. Мною придуман эффективный алгоритм отрисовки веток LD который не использует рекурсии или графы. Все элементы - линейны и последовательны , а двумерность программы в некоторым смысле илюзорна. Поэтому гарантировано - то что пользователь видит на экране , то видит виртуальная машина на выполнении. Новая ветка на отображении просто скачок координат на дисплее, а для виртуальной машины - скачок счетчика выполнения команд.
Трансляция LD\FBD\ST программ на язык инстукций виртуальной машины, а потом компилятором в байткод для машины
Компилятор. Программная архитектура
Несмотря на то что я пытался сделать инструкции для виртуальный машины, максимально соответствующие машинным, работу с переменными я реализовал - высокоуровневую. То есть, пользователь может создавать свои структуры любой сложности внутри, без ограничений. Типы могут в себе содержать внутри другие типы и массивы любой размерности, и эти массивы также могут внутри содержать сложные типы чередующиеся с массивами.
тут мне пришлось проделать огромную работу компиляторостроения - Memory Manager Layout.
types:
Sensor typedef {
id: word;
value: real;
is_ok: byte;
}
Status typedef {
is_running: byte;
error_code: word;
error_msg: byte[50];
}
ProductionLine typedef {
line_id: word;
sensors: Sensor[10];
production_rate: real[7][24];
status: Status;
};
Таким образом в данный момент, описание пользовательского LD FBD выглядит так:
Но уже сейчас работаю над транслятором ST, чтоб можно было создавать свои LD FBD с описанием их на ST.
То есть, самый низкий уровень VM это гибрид ассемблера с высокоуровневыми данными, поддержку этого я намеренно реализовал для возможности в будущем писать код на свою платформу не только на языке ST, да хоть на Java. При этом, напомню, я разрабатывал VM способную работать на микроконтроллерах с ОЗУ от 8Кб. Да возможно если писать на языке ST , то в такой МК влезет всего под сотню строк кода, но ничего не мешает подгружать инструкции с внешней карты (если пользователю не важна строгость выполнения по времени, будут небольшие задержки), ну или взять МК с ОЗУ побольше. VM имеет эфективное адресное пространство 1 мегабайт, то есть - прочитать переменную с адресом меньше <1МБ можно за один раз:
если работать адресами по выше, то тут нужно использовать две виртуальные иснтрукции - загрузить старшие биты адреса, а потом младшие.
Что можно выжать из МК с ОЗУ 8 килобайт
Инструкции VM - 4 байтные. Одна булевая LD инструкция занимает 8 - 12 байт:
// 8 Байт, Аналог XIC
LDB R15 Reset;
JFALSE R15 Start;
//12 байт если LD читает целое, но проверяет бит
LDB R15 MPPress;
MSK R15 #5
ISFALSE Branch 2;
таким образом, в однозадачном режиме, если создавать ПЛК на МК с ОЗУ 8КБ ( 4 КБ - виртуальная ОЗУ+4 КБ нативный код СИ - сама машина), на 4 КБ виртуальной ОЗУ можно загрузить 300-400 LD (при булевых переменных - 400 LD ) инструкций и около сотни переменных размером 1-4 байта.
Если режим многозадачный ( парралельные не связанные между собой задачи) то среда разработки допишет свой код, где будет дополнительно уходить 80 байт на каждую задачу для создания виртуального стека, и около 160 байт на простейший менеджер задач, который будет управлять выполнением.
В следующей статье напишиу - как это выглядит уже на микроконтроллере.
Мы занимаемся разработкой Scada-системы и для отладки коммуникации с Modbus-устройствами написали небольшую утилиту: PultModbusTester
Утилита бесплатная и без ограничений. Очень простой и удобный интерфейс. Поддержка Modbus TCP, Modbus RTU и Modbus RTU-Over-TCP. Интерпретация значений в форматах INT16, INT32 и Float (с любым порядком байтов). Утилита имеет подробный и наглядный лог, с подсветкой ошибочных байтов - здорово помогает в решении проблем с Modbus-устройствами.
Будем рады, если утилита окажется полезной коллегам-автоматчикам, также будем благодарны за обратную связь по функционалу.
1. Используйте только однобуквенные имена переменных
Например, вместо `ConveyorMotorSpeed` пишите `x`. Так никто не догадается, что переменная управляет скоростью конвейера, и проект превратится в головоломку для коллег.
2. Не комментируйте код вообще
Пусть все догадываются сами! Например, строчка `IF NOT NOT x THEN y := TRUE;` без пояснений станет загадкой на века. Это добавит проекту атмосферы таинственности.
3. Храните все данные в глобальных переменных
Зачем использовать локальные переменные или структуры? Пусть всё висит в `GVL`, чтобы изменения в одном месте ломали логику в десяти других. Это ускорит развитие хаоса.
4. Пишите всю логику в одном ПЛК-цикле
Забудьте о разделении на функциональные блоки или программы. Дайте все 10 000 строк кода в `PLC_PRG`. Это повысит производительность... ну, как минимум, нагрузку на мозг разработчика.
5. Используйте таймеры и счетчики без сброса
Например, вставьте один таймер `TON` в несколько условий одновременно. Пусть его состояние "плывет" между задачами — это добавит неожиданности в поведение системы!
6. Не тестируйте логику до загрузки на железо
Зачем использовать симуляцию? Лучше сразу запускайте код на реальном оборудовании. Внезапные сюрпризы вроде заклинившего сервопривода сделают рабочий день ярче.
7. Применяйте операции с плавающей точкой для таймеров
Например, умножьте `T#5s` на `1.0000001` и удивляйтесь, почему таймер срабатывает несвоевременно. Это идеальный способ запутать даже опытного инженера.
8. Игнорируйте резервное копирование
Делайте правки прямо на боевом контроллере, не сохраняя проект. Если всё сломается — просто начнёте всё с нуля. Это тренирует память и стрессоустойчивость!
9. Мешайте логику управления и визуализации
Пишите код для HMI прямо в ПЛК-программе через `IF HMI_Button THEN ... END_IF`. Так вы создадите идеальный микс между технологической логикой и интерфейсом.
10. Не используйте версионирование
Сохраняйте проект каждый раз под новым именем: `Project_v1`, `Project_v2_final`, `Project_v3_реально_последний`. Через месяц вы сами забудете, где какая версия.
... и оно кажется скоро зохватит этот мир с никчёмными людишками! Короче, в связи с вот этим псто решил я на досуге разобраться в новой для себя области ПЛК на практике. Купил старую железяку на авите, а пока едет ковыряю LD и с чем его едят, читая гайды и пытая специфический ИИ, прикрученный к Warp:
Заценив логику построения ответов, решил найти где ж она сука сломается :)))
После пары наводящих вопросов решаю добить контрольным выстрелом:
И охуева... нахожусь под впечатлением еще долго :))))
UPD: Поскольку автор первого же коммента под постом затребовал выезда пояснительной бригады из дурки собственно поясняю:
ИИ - искусственный интеллект.
ПЛК - программируемые логические контроллеры. Основа промышленной автоматики наших дней.
LD - релейные диаграммы, графический язык программирования (один из) для этих железяк.
Аль Каши 111 - движуха на просторах бывшего СНГ, неразрывно связанная с мотоциклами, путешествиями, распиздяйством, бухлом, фестивалями, феерическиим долбоебизмом на грани с отвагой (от перемены слов "долбоебизм" и "отвага" в этой фразе смысл не меняется, только играет новыми красками), стебом над традиционной мотокультурой и вообще меня туда не взяли тинтобрассы милейшие люди.
Al-Kashi - крайне прошаренный для своей эпохи персидский математик и астроном.
Warp - продвинутая терминальная программа для LInux и Макоси, к которой прикрутили специфический ИИ для Столлмана бородатых одминов, программистов и прочих
Strugatsky brothers - внезапно, Стругацкие.
Профессор Выбегалло - ну, если вы дочитали до сюда и по прежнему ничего не поняли, просто поставьте минус и проходите дальше.
Решил написать свой первый настоящий пост на Пикабу. Даже не представлял, как получается написать такие объёмные тексты. Но тут товарищ прислал одну статейку про новых программистов и реальную автоматизацию на заводах))) И тут вспышка 📸, ничего не помню и выходит текст из памяти!) Добро пожаловать под кат!)
Приходит как-то молодой IT-специалист со свежим стеком из Docker’ов, микросервисов и К8s на завод. В цеху сверкают панели управления, гудят моторы, а он пытается подключиться к этому промышленному добру. И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т. д. и т. п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит: — Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м. И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!»
Шёл 2011 год. У меня на первом заводе, где тогда работал, была 3-зонная методическая печь по нагреву металла, автоматизирована какими-то ПЛК (я тогда ещё слова такого не знал), программа была написана на Pascal. Помню, приехал программист делать доработки. Мы, молодые КИПовцы, специально остались, задержались (нас мастер уговорил, мол, посмотрите, учитесь). Он строки переписывает, меняет какие-то цифры (теперь уже знаю, что это были коэффициенты ПИД), и оно оживает (горелки переходят в другой режим работы) и начинает работать по-другому. Скада, если её можно так назвать (им же нарисована в каком-то редакторе), меняет форму, изменяет значения. Но🫣 тут же ниже на этом шкафу стоит 3 переключателя на 3 положения с фиксацией (вроде бы кулачковых) и ещё 3 обычных 3-позиционных без фиксации. Первые изменяют источник задания на газовые заслонки (1 — ПЛК, 2 — ручное управление, 3 — ещё одно🙂). Программист заканчивает настройку, говорит: «У вас будет всё хорошо». Уходит. Нашему мастеру категорически не понравилось, как работает регулирование. И как только программист уходит, переводит эти кулачковые переклички в то самое 3е положение. И горелками начинает управлять что? Правильно! Старые добрые КСП3 с круговыми диаграммами, которые мы меняли каждые 24 часа))) Говорит, так будет лучше, и уходит, говоря: «Собирайтесь домой». Мы ещё задерживаемся минут на 10 в этом помещении. Всё это время с нами был «печник», который следит за режимом работы печи. Тот, что был на смене, тут же, как наш мастер вышел, переводит кулачковые переключатели в какое положение?) Правильно! В ручное!)😂 И говорит: «Так будет надёжнее!) 😁».
Вот тебе и стеки и TLS и DHCP и 485. А подача 220 на МЭО импульсами надёжнее для конечного пользователя)) ☝️ Но это ещё не всё. Печники, когда лень идти в помещение с этим щитом управления, просто подходят к МЭО и что? Тоже правильно! Просто крутят его с помощью маховика))) Вот тебе и автоматизация)))💡 МЭО было примерно как на фото) Ну и схематически печь)
