Аналог промышленного контроллера Schneider Electric на российском микроконтроллере АМУР MIK32
В прошлом году я начал публиковать первые тесты своего компилятора WIA32 и среды разработки 3o|||sheet на различных микроконтроллерах и FPGA (STM32, CH32, Altera Cyclone 4). Был и российский АМУР MIK32.
На одном известном ресурсе, по поводу подобных МК были возражения типа - 16 КБ ОЗУ, что из этого можно сделать в современном мире?
Рантайм (регистровая ВМ) моей разработки выполняющая байткод на стороне железа, требует всего 5 КБ RAM, поэтому в подобный МК как АМУР MIK32 с 16 КБ влезает достаточно много(в сотни LD\FBD блоков, или несколько сотен ST строк ) программы причем с изолированным выполнением. То есть, речь идет не о зависшей задаче, это - самый легкий сценарий ,так как планировщик все равно задачи меняет. Речь об устойчивости к тотальному краху данных.
Таким образом 3o|||sheet является первой(?) средой где АМУР MIK32 успел побывать полноценным промышленным контроллером хоть и в тестовом режиме, а не игровой консолью, умным домом или мигалкой светодиода.
ПЛК на АМУР MIK32 как аналог Schneider Zelio Logic
Своему софт-процессору и набору команд дал название - WIA32 (переводится как - широкий непосредственный адрес) который и отображается на графике синим. Тут данные по скорости выполнения программ лестничных диаграмм или функциональных блоков (ST - не тестирую, так как в документации брендов ПЛК нет данных производительности алгоритмов на ST чтоб сравнивать).
Не путать тест с бенчмарками, производительностью машинных инструкций и программ написанных на СИ.
Если б я делал ПЛК на АМУР MIK32 то получил бы аналог программного реле Schneider Zelio Logic. Это с точки зрения производительности, хотя в данный момент моя ВМ - трансформируется, и не оптимизирована под конкретную архитектуру. Я не производитель ПЛК и не занимаюсь глубокими оптимизациями своей ВМ под отдельный чип для максимума.
Но в отличии от среды Schneider , у меня более продвинутые функции, так как мой компилятор WIA32 поддерживает:
Сложные данные (структуры в структурах, многомерные массивы и прочее).
Такой вид данных поддерживается моим компилятором:
Гибкость. Использование сложных структур и многомерных массивов данных в программе Промышленного Контроллера.
Сложные структуры любого уровня можно использовать в лестницах и блоках.
Менеджер адресов который точно расставляет данные\инструкции в памяти, расставляет адреса и не промахнется ни на один байт среди миллиарда - отдельный шедевр мысли.
Так как у нас свой компилятор и собственный софт процессор - есть возможность безопасно добавлять структуры данных и менять код на лету не перезагружая ПЛК вообще. Добавлять новые программы которые тут же заработают как в смартфоне установленное только что приложение с маркета.
Schneider , китайские, российские и многие другие страны создающие ПЛК (те которые на собственной среде, а не на Codesys) не поддерживают работу с многомерными массивами, вытесняющими задачами, заменой кода на лету и другими возможностями для которых нужен собственный компилятор. Практика перевода языков МЭК 61131-3 (IEC 61131-3) в язык СИ а потом прошивка в ПЛК обычным компилятором, как это делают в Beremiz и 95% разработчиков ПЛК - дает легкий и быстрый эффект в разработке, но такие ПЛК очень деревянные/неповоротливые, и подвержены трудно уловимым ошибкам с тяжелой (или невозможной) отладкой.
Сама среда, графический движок от Schneider - сильно уступает моим наработкам тоже. У Schneider можно создавать “строки” из 5 элементов и одной катушки, в то время как мой движок (без каких либо фреймворков - рисует примитивами) - может отображать любые разветвленные ветки и связи любой сложности, создавать собственные блоки любых размеров с любым количеством переменных и структур и описывать их программно.
Программируемые Машинные Контроллеры.
Промышленный процессор на базе микроконтроллеров с 4-6 КБ ОЗУ как MIK32 Амур или STM32G030 можно использовать не только как ПЛК, но и - Конструктор кастомного пульта - рабочее место оператора.
То есть не пульт с вылитым корпусом на фабрике, или корпуса в которых надо что то сверлить или отвертками крутить . Имеет смысл - дизайн модулей с разным набором кнопок, ползунков и т.д с использованием настройки экосистемы и среды для ПЛК.
Когда процессор от ПЛК может стать процессором пульта и обратно, подключая нужные наборы кнопок, джойстиков или модулей ввода/вывода.
Но идея не только в дизайне, но и подходе к надежности. В чем лично моя идея это - разработка самого надежного отказоустойчивого пульта в промышленности, работающий по принципу Zero Protocol.
Обычно в АСУ ТП между модулями идет общение по CAN и подобных протоколах. Я разработал гибрид с конфигурацией на подобии идеи конфигурации FPGA:
Шина,например CAN/RS485 - тоже есть, для конфигурации,и низкоприоритетных задач.
Шина Zero Protocol - прямые линии- провода(в зависимости от количества входов у процессора CPU).
Визуально это выглядит вот так:
Подключение к процессору - модулей с кнопками (на подобии модулей ввода вывода)
с нужными комбинациями энкодеров, кнопок , ползунков и т.п. С двумя шинами: протокольная (CAN\RS485) и прямая Zero Protocol.
Преимущества дизайна:
Единая среда разработки программ для ПЛК и пультов с автоматической детекцией подключаемых, типов кнопок/ползунков/энкодеров,в единый дизайн.
Кнопки можно покупать конечно отдельно и подключать их к ПЛК, но это годится только для закрытых шкафов. Для пульта внутри машины/или управлять светом на дискотеке со сцены - не практично и не красиво. Я не просто инженер, по второму диплому (и со стажем) - преподаватель живописи и графики. Дизайн - неотъемлемая часть моего мышления, нахожу это - красивым.
Преимущества технические:
Реакция на нажатие кнопки, энкодера и т.д - нулевая задержка. Прямой провод, никакого зависания коллизий линии и прочее.
Подтверждение (прошел сигнал/не прошел) - как второстепенная информация. Если подтверждение придет через 0.5 -1 секунд - неважно, главное реакция на нажатие оператором - сработает 100% без зависаний.
Если оператор видит машины или механизмы своими глазами - все подтверждения по проводам - избыточны.
Если оператор не видит глазами - происходящее (задвижка какая нибудь), то задержка подтверждения в 0.5 - 1 секунду роли никакой не сыграет для реакции человека, зато может сыграть для критического сигнала (например кнопки STOP) 0.5 сек - это много, и есть смысл убрать протоколы замедляющие сигнал идущий в -> сторону машин и механизмов.
Мы имеем программируемые модули кнопок, с автоматическим отображением переменных в среде, при том сохраняя всю скорость реакции как у прямого примитивного железа.
Таким образом у нас машинный контроллер имеет три приоритета на реакции:
1) Высокий приоритет, например кнопка STOP и подобное, работает в обход процессора (к процессору подключен но только для регистрации времени события например или для сообщений в SCADA).
2) Средний приоритет - так же работает без протокола, по прямому проводу, но есть задержка в размер цикла (программируемая реакция, может быть добавлен алгоритм обработчик).
Это как будто бы вы подключили просто кнопку/рубильник к входу обычного ПЛК как упоминалось ранее, но естественно эта кнопка не отобразится в обычных ПЛК и средах, все нужно прописывать руками. В нашей Среде она - отобразится автоматически (тип, название) по протокольной шине.
3) Самый низкий приоритет - те кнопки и элементы которые полностью на линии CAN/TCP и др., там время реакции большое:
Сигнал должен пройти все рукопожатия, контрольные суммы, побороть коллизии + быть обработан в цикле ПЛК.
Как раз на этом уровне и работают всякие модули в ПЛК мировых вендоров, И они это называют - надежным модулем. В моем представлении это считается самым медленным и ненадежным в сравнении с Zero Protocol.
Перефразируя коротко мою идею - это так: обеспечить прохождение сигнала в ту сторону (до машины) без помех и риска, а обратно (от машины) - как у всех, через шину с протоколом типа CAN/RS485.
Я больше склоняюсь к RS485 (и с ним экспериментирую ) так как такой модуль кнопок можно обеспечить на совсем примитивных и дешевых микроконтроллерах с UART и 1-2 кб ОЗУ и получить надежность превышающую дорогие пульты называющие себя - отказоустойчивыми.
Вот такой был тест MIK32 AMUR и мое масштабное видение применения слабого железа к своим наработкам.
Пишите критические мысли в комментарии или на почту zoshytlogic@gmail.com














