Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Железо и гаджеты доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
"В прошлой статье я рассказал о своем подходе к..."
Здесь ещё можно вставить ссылку на прошлую статью.
И часть, как данные от внешних устройств превращаются в XML файл, можно кратенько где-то осветить для преемственности изложения, - пожалуйста.
Я не критикую ( Боже упаси! ) , просто прошу, идея классная, сам хотел бы таким позаниматься, но не с нуля. Спасибо!
XML осуждаю. Слишком много визуального шума.
Сошлюсь на практику мировых вендоров, у которых программу можно править и в виде LD и в виде парного представления IL (с ограничениями конечно же) одновременно
Спасибо за комментарий! Напишу новую статью о том как реализовано , я взял за пример Allen Bradley , у них логика веток (построение) описывается типа :
"XIC XIC BST XIO XIC NXB XIC BND XIO XIO "
то есть, ветки обозначаются маркерами BST,NXB ,BND . У меня тоже самое - есть скрипт который это описывает подобным образом.
.xml в моих модулях он хранит всего лишь - отрисовку графики блока, внутри локального прямоугольника+ описание поведения ASM подобным синтаксисом.
А сами ветки в глобальном плане- ход программы - он описывается скриптом : какая инструкция за какой идет, и какие ветки где находятся.
Или еще аналогия: .xml хранит классы (библиотеки) как визуального вида так и функций программы. А скрипт хранит логику веток, схему, и комментарии.
Для текстовых языков типа ST - конечно никаких .xml не нужно, там просто текст без графики.
Расскажите как реализован интерпретатор байт-кода, как организована компиляция в байт код, как связь с железом (ADC, DAC, DI, DO) осуществляется. Как разделены host = Rasberry и STM32G, Как осуществляется мониторинг и индикация - состояние портов и т.д. Связь с внешним миром - Ethernet, RS485, и т.д. Как делается логирование, сообщения об ошибках?
Я буду и дальше писать периодические посты как это работает. Если коротко:
Компилятор переводит текст программы(собственный язык: си подобные структуры и данные, в инструкции как у ассемблера) в 32 битные единицы и нули.
Массив этих байт (виртуальная прошивка) идет по uart в микроконтроллер в виртуальное ОЗУ ( массив uint8_t memory[size] - в нем все хранится, программа, данные, стек, буферы для связи с внешним миром, единый массив).
Цикл wile() читает эти байты(инструкции) и вызывает обработчики : функция + -прыжок между инструкциями,мвсе как на физическом процессоре, только тут он программный нарисан на си (есть еще и на FPGA).
Но цикл while() не простой, там есть постоянное чтение флага состояния процессора:
Сработало прерывание? Ставим машину в режим : отдать данные на пк, иои сменить задачу (если несколько виртуальных задач работаеют) так же если происходит ошибка (например в лестнице программы плк, деление на ноль или еще что) ставим машину в режим ошибки и вызываем нужную функцию или си, или переводим счетчик команд виртульной машины на виртуальный обработчик (как это в языках ява или питон).
Тут много нюансов есть.
В этом массиве под виртуальное озу: вы можете выделить память под буфер для rs485 /ethernet.
Интеграция с конкретным микроконтроллером необходима тоже если делать плк.
У компилятора есть инструкция extfn, если нужно что то особенное (как например ethernet) компиялтор (то есть среда на ПК) будет вставлять эту инструкцию в ваш нарисованый функциональный блок, а микроконтроллер будет вызывать функцию на си, которую вы внедрили в свой плк.
Для пользователя это будет всего лишь еще один нарисованный функциональный блок, а для производителя плк, нужно будет еще написать функцию что с этими данными из этого блока делать.
Тут главное для понимания не путать нативную прошивку (,который ставит производитель плк на заводе) с виртуальной (программы плк: ST, LD, FBD)
Идет у вас почти по моим аналогичным планам во всяком случае то что описали, контроллер то же на FPGA, разница только в компиляторе и среде программирования софте. С интересом буду ждать продолжения цикла статей. Rasberry под линуксом?
Цикл wile() читает эти байты(инструкции) и вызывает обработчики : функция + -прыжок между инструкциями,мвсе как на физическом процессоре, только тут он программный нарисан на си (есть еще и на FPGA).
по предыдущим дискуссиям стало интересно как оценивать надежность такой вирутуалки (риск что она зависнет намертво в какой то ситуации), по логике это должно быть какое то массовое тестирование
Тестирование есть, это 8 задач с глубокими переходами из функции в функцию 8-10 уровней(то есть , виртуальные функции, программа ST, а не нативная) и их эти задачи хаотично прерывает таймер меняя , вытесняя задачи местами . Так тстировал сохранение контекста , целостность стеков, адресов возврата и прочее. Это суточный мониторинг. Если за сутки ничего не случилось , сотни миллионов смен задач произошли штатно, и все работает значит все норм, , в отладке просматривается все ли на своих местах, не затерлись или не испортились какие то данные даже если программа не слетела. Тестируются другие сценарии. Тут без поблажек
В итоге среда спокойно запускается даже на ранних версиях Raspberry Pi и требует всего 120–200 МБ ОЗУ. Таким образом, из слабого мини‑ПК можно сделать полноценный самопрограммируемый промышленный контроллер.
не сразу понял эти фразы в связке. мини‑ПК это все таки обычно про x86 но gpio там если и есть то запрятаны. плюс вопрос "реального времени". если же че то малиноподобное то интересен вопрос экрана, его размеров и удобства пользования средой на мелких экранах.
а то вон в соседней теме сделали ПЛК с простеньким визуальным ladder на экране на экране 0.96" - вообще никаких сред, все на простом контроллере фурычит
Идея мини плк который имеет в себе и компилятор, и сам выполняет программу плк (например случай когда - сеть не предусмотрена , перепрошивать удаленно, и чтоб не надо было с собой носить ноутбук). То есть можно на месте отлаживать и запускать. А ПЛК с простым ladder и другого поста , - тут вопрос масштаба. С одной стороны и мой рантайм заработает на stm32g030 на аквариуме, но я целился на соревнования с Allen Bradley
ну это да, а экран (на 27" дюймов 6) с собой носить или к каждому ПЛК приставить?
Можно экран 320*280. Не думаю что фирма не найдет 10-15$ на такой дисплей если им нужно будет. С другой стороны, сам рантайм работабщий на мк, можно изменить под себя вывести кнопки и записывать значения. Виртуальная машина, ее память хранится в обычном массиве, сменить байт с 0x6 на 0x8 чтоб изменить инструкцию, или сменить два байта адреса чтоб поменять переменную, не трудно будет
Классно получилось! SCADA уже реализована или только среда разработки?
> Нативная часть для железа выполняющая программу в качестве ПЛК, требует на стороне микроконтроллера 5 кб ОЗУ, и 32 кб флеш
...что заставляет задуматься об её функциональности. Рантайм старого доброго FX2N занимает под 100КБ. У меня с плюшками уже перевалило за 150КБ, и это без реализации команд управления перемещением. Судя по картинкам, кочующим по сайтам и статьям, пока видны только простейшие команды из базового набора ПЛК. Я уже не однократно говорил, что все сравнения вашего ПЛК с другими лишены смысла, потому что для вашего рантайма нет ни описания архитектуры, ни системы команд.
Для того чтоб опубликовать проект его надо подготовить.
А секрет небольшого рантайма: компилятор мой, он все просчитывает до мелочей, это позволяет не нагружать микроконтроллер в выполнении.
Если у бренда (упомянутый Митсубиши) инструкции несут с собой большое количестао метаданных- все это надо разбирать. Кроме того, вы скидывали китайскую документацию , где китайцы жаловались на неудобные поля инструкций ПЛК Митсубиги и это замедляет плк. Митсубиши имеющие свои процессоры разбирающие инструкции за один такт, не должны переживать за неудобность реализации выполнения их кода эмуляцией на СИ, так что рантайм в 100кб, ничего не говорит.
Если б вы поработали с Verilog (и процессоры на нем) то увидели, что реализовать софт-процессор, много прошивки ненадо
> Для того чтоб опубликовать проект его надо подготовить
Речь не о проекте в целом, а о системе команд. А то вы навыкладывали тесты производительности, сравнивания свой ПЛК с брэндами, но так до сих не понятно, что с чем сравнивается.
----------------------
> Кроме того, вы скидывали китайскую документацию , где китайцы жаловались на неудобные поля инструкций ПЛК Митсубиги и это замедляет плк.
Вы меня с кем-то путаете. Я не скидывал китайскую такую документацию, хотя не единожды давал ссылку на то, что было собрано с китайских файлопомоек, и ни когда не_сетовал на сложность декодирования команд. У ARM тоже быстрые команды, поэтому проблем со скоростью интерпретации команд Мицубиси нет.
Я придерживаюсь полной абстракции от железа, все управление циклом например (работа с портами и другое) идет - с байткодом пользователя. То есть, из нативной работы мк выполняет только работыис флеш и uart, и инструкции по 90 штук, все отальное (фоновые задачи какие то, которые могли бы работать наинативном уровне) у меня работают тоже с байткодом, это позволит совсем не трогать прошивку в будущем, одинираз залив, а обновлять логику которые идут вместе с байткодом пользователя. То есть, пользователь сделал программу, 30% среда IDE генерирует код типа ОС+ добавляет к нему 70% код пользователя. Захотел сменить какие то параметры системы - пожалуйста, меняйте ОС пишите сами в этой же среде, не трогая нативную прошивку совсем. Вот и весь секрет легковестности
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ПЛК на микроконтроллере. Визуализация цепей в реальном времени ч.2