Комментарии 13
Если велосипедами интересоваться, порекомендовал бы что-то типа https://openplcproject.com/. Там заявлена поддержка языков IEC 61131-3.
Как то с ребенком занимались визуальным программированием для лего mindstorm. Простые вещи — да, наглядно. Любое усложнение алгоритма — ад. Никогда больше!
В статье рассмотрен так называемый SW_Fast_Automat, которых на листе с десяток может быть. А в базовом варианте на лист устанавливается блок SW_Auto и весь лист становится одним большим автоматом. Мало одного листа? Этот же блок ставится на следующие листы и сложность автомата возрастает дальше. Вот где ад! Но куда деваться? Программа с тем же функционалом вообще не воспринимается посторонними, а в графическом варианте ее можно обсуждать хоть с руководством, хоть с заказчиком.
Вы путаете "Визуальное программирование" в целом с "Автоматным программированием".
В Вашем случае операторы языка С, или любого другого, заменяются картинками-пазлами, чтобы ребёнок, не зная синтаксиса языка мог проще его освоить.
"Автоматное программирование" - оперирует состояниями конечного автомата (алгоритма поведения системы) и переходами между ними.
Чем сложнее алгоритм - тем легче его понимание в графическом виде.
Описание конечного автомата в исходном тексте программы имеет множество вариантов и зависит от предпочтений человека, который его реализует, но в целом состоит из операторов Switch Case для состояний и проверки условий - для переходов.
Именно поэтому её еще называют "Switch-технология"
Начиная с третьего абзаца Вашего поста текст можно скопировать и вставить в аннотацию статьи. Ибо полностью разделяю! Увы мне, старался, но не сумел раскрыть.
А вот с первым абзацем Вы погорячились. Читаем раздел "История разработки". Сначала там упоминаются конечные автоматы, а затем указывается на их графическое представление, которое по мнению автора более предпочтительно, особенно для сложных проектов. В каком месте Вы увидели знак равенства, непонятно. Тем не менее, это недоработка прежде всего с моей стороны.
Со вторым абзацем, опять увы мне. Статья показана как "среднего уровня". Предполагаю, что платформа Arduino ассоциируется у вас с детским творчеством... Совершенно непонятно откуда взялось "В Вашем случае операторы языка С, или любого другого, заменяются картинками-пазлами"? Нет в статье такой замены... Картинки описывают состояния (вершины) и переходы (дуги), без наполняющего кода автоматы не работают и уж точно все это не для детей.
А, вот оно как. Не знал. Спасибо за пояснение!
В конце 80-х программировали контроллеры на Стматик степ 5 (Бергер) там тоже были "квадратики" ))
С 2008 года применяем Switch-технологию в программировании промышленных ПЛК для автоматизации задач логического управления. Для этого используем конвертер MetaAuto, переделанный мной для программирования ПЛК под язык ST стандарта МЭК 61131-3. Этот конвертер METAAUTO_VISIO2_ST_CPP, хоть и с открытыми исходниками, но сложный и неудобный в использовании, поэтому были планы переписать его полностью на VBA в Visio.
По просьбе одного пользователя были по-быстрому записаны 2 видосика-инструкции для METAAUTO_VISIO2_ST_CPP
Наши подходы к выходному тексту программы отличаются. Я использую 1 оператор Switch (Case) для одного автомата
Граф переходов и исходный текст
Благодарю за то, что делитесь своими наработками.
Я планировал писать аналогичный конвертер, только с возможностью обратного преобразования: из текста программы строить граф переходов.
Обычно, после наладки оборудования на объекте исходный, текст программы меняется, и приходится вручную переносить эти изменения на граф переходов, поэтому хотелось автоматизировать этот процесс. Однако в сети мало примеров исходников на VBA по трансляции языков программирования, а писать с нуля не хватает знаний/желания...
Да, V2S так же опирается на Switch-технологию, обратите внимание, что автор ее тоже А.Шалыто )).
Даже блок для обозначения автоматов у нас с Вами похожий (корни то одни).
Вот только задачи различаются - у Вас это управление ПЛК, а у меня - создание программ для встраиваемых микроконтроллеров. Поэтому и идут такие различия.
На счет обратного преобразования в графы - мне кажется эта задачи средствами визио решена быть не может. С разумными усилиями, разумеется. Даже не столько с алгоритмической точки зрения, сколько с точки зрения размещения графики на листе Визио. На профильном форуме до сих пор полноценно не решена проблема оптимизации проведения линии между фигурами или даже нахождения пустого пространства на листе...
В практической деятельности поступаю ровно наоборот - создаю граф (автомат), а затем заполняю его кодом. Получается наглядно и позволяет держать весь проект перед глазами.
Первый лист системного автомата микроконтроллерной системы контроля "Топаз"
На счет обратного преобразования в графы - мне кажется эта задачи средствами визио решена быть не может. С разумными усилиями, разумеется. Даже не столько с алгоритмической точки зрения, сколько с точки зрения размещения графики на листе Визио. На профильном форуме до сих пор полноценно не решена проблема оптимизации проведения линии между фигурами или даже нахождения пустого пространства на листе...
Согласен, размещение фигур на листе довольно сложная задача!
Видел одну коммерческую разработку, которая делала визуализацию соединений ЦОД. Получился лист размером с половину волейбольной площадки, со множеством пересечений! На мой вкус абсолютно не читабельная схема…
А о каком профильном форуме идет речь? Явно не профильном по Visio)
оптимизации проведения линии между фигурами или даже нахождения пустого пространства на листе...
В определении пустого пространства на листе может помочь алгоритм построения максимально возможных квадратов от Олега Малютина a.k.a Obsidian (видео)
Графическое программирование конечных автоматов для Arduino. Часть 1