roboforum.ru

В моем понимании и очень кратко - ключевым моментом Switch-технологии является возможность много поточного взаимодействия в параллельных циклах с применением конечных автоматов FSM, когда состояния FSM могут находиться в состоянии ожидания на входе при тех или иных предшествующих событиях и передачей команды на выходе.
https://youtu.be/hFoMia3s4NU?si=NlxsvZsqutVLDr-o

Уважаемый бип бим, можете как то не так откровенно лезть с рекламой своего проприетарного продукта после каждого моего сообщения? Мне это честно говоря уже очень не нравиться. Если кратко, то Ваше понимание очень ценно, но очень навязчиво. Или я вынужден буду обратиться к модератору.

smur писал(а):Уважаемый бип бим, можете как то не так откровенно лезть с рекламой своего проприетарного продукта после каждого моего сообщения? Мне это честно говоря уже очень не нравиться. Если кратко, то Ваше понимание очень ценно, но очень навязчиво. Или я вынужден буду обратиться к модератору.

Если Вы сумеете здесь, свои мало понятные посты, изложенные на академическом уровне и примерах, подкрепить реальной демонстрацией того, как это работает у Вас, Вам скажут только спасибо, если Вам не важна реакция тех кто в теме, а это похоже только я да Вы, то это будет выглядеть как диалог с самим собой. Я отвечаю здесь чисто из соображений здорового дискуса, т.к. я и сам работаю в этой теме и пока не могу понять насколько она здесь кому либо интересна.
Если админы не согласны, они и без Вашего обращения все забанят. Ролики мои, больше имеют образовательный характер и если Вы там видите для себя рекламу, думаю никто не расстроится если и Вы сумеете продемонстрировать в какой либо доступной и подобной форме донести это для всех, глядишь и вопросы появятся.
Иначе для чего тогда весь этот каламбур?

Что касается пропприетарного, здесь надо разделять мух от котлет что считать проприетарным, а что нет, если какой либо языковый компилятор доступен для быстрого старта, а другой требует массу усилий и времени на освоение, каждый сам для себя решает что ему важней, как и то, в какой среде писать скрипт для управления робототехникой, в мире робототехники все очень взаимосвязано и если быть практиком, то именно в теории автоматного программирования есть противоречия по применению тех или иных IDE, под которыми многие теоретики пытаются реализовать свои алгоритмы, о чем собственно и идет речь в моем видеопоказе.

Для чего я пишу данные посты. Во первых, чтобы обновить в памяти уже сделанное и чтобы найти новые варианты решения построение логики работы автоматизированного устройства. Ну и может кому то это понадобиться. Если пригодиться одному из 1000 это уже хорошо. Отрабатывать логику работы гораздо интереснее на какой то робототехнической тележке с разными датчиками, чем на унылом стенде как на данном видео:
https://cloud.mail.ru/public/YqSV/VWeDuSeGd
Это не я на видео, но начинка стенда моя, один из прототипов. Это вспомогательное электронное устройство для проведения операций на берцовой кости. Там есть несколько магнитных датчиков, управление питанием, управление индикацией, калибровка, обработка ошибок итп. Промышленный прототип работает и принят заказчиком.
Отрабатывать логику работы на таком виде стенда не интересно, а вот на роботе интересно.

Добавлено спустя 13 минут 45 секунд:
Начал работать с metaauto и столкнулся с некоторыми трудностями при преобразовании в код CPP.
https://is.ifmo.ru/projects/metaauto/
Написал по этому поводу письмо Шалыто Анатолию Абрамовичу и получил развернутый ответ на мое письмо, который можно найти по ссылке:
https://vk.com/@1077823-avtomatnoe-prog ... h-ne-ubesh
Там есть некоторые правки в шаблоны metaauto которые нужно сделать для получения правильного кода CPP.

Для отладки логики управления роботом, как от внешних команд, так и для самостоятельного движения с учетом датчиков, сделал отладочный вариант в Visio.

Здесь можно найти Visio файлик и jpeg с автоматов:
bibi_automata_win
https://cloud.mail.ru/public/r2yS/UXqN1mTG6

Это для простых действий по выполнению команд - вперед, вправо, влево, назад, стоп, но с учетом имеющихся на борту датчиков касания, расстояния и одометров.

Вот здесь программа для отладки немного переделанная под Windows, правда она под 8.1 версию, тк на этом отладочном компьютере Windows давно не обновлялся, на нем понаставлено много старого софта который обновление на более новые версию не переживет да и сам компьютер старый.

bibi_prog_win
https://cloud.mail.ru/public/MXpV/n9QTx1jfM

Исполняемый модуль под Windows 8.1 собранный на DEV C++ 5.11, проект там же лежит:
BiBi_1.x.exe

Для отладки эта программа выводит логирование состояния и переходов. Параметры во время работы программы можно задавать нажатием на кнопки, описание кнопок есть в main.cpp.

// Клавиша 1 - e1 - Команда Стоп
// Клавиша 2 - e2 - Команда Вперёд
// Клавиша 3 - e3 - Команда Назад
// Клавиша 4 - e4 - Команда Вправо
// Клавиша 5 - e5 - Команда Влево
// Клавиша 6 - e6 - Команда Приостановка
//

// В данной версии будем использовать симбиоз командного и смешанного режимов, в командном режиме нет параметров выполнения команды, нельзя сказать - вперед один метр
// В смешанном варианте можно сказать - вперед один метр
// Переменные Х для полуавтоматического режима (смешанного). В этом режиме должна передаваться команда и параметр, например - вперед один метр
// Переменные X в этом случае сообщают о выполнении команды с выполнением условия указанного в параметре
// В данной версии нет работы в полуавтомататическом режиме тк это отладка логики, есть только реакция на нажитию клавиши для проверки логики работы автоматов
// Команда стоп выполнена "q" такой нет переменной
// Команда вперёд выполнена "w" x32_2_in=1
// Команда вправо выполнена "e" x34_2_in=1
// Команда влево выполнена "r" x35_2_in=1
// Датчика касания правый сработал "t" x20_6_in=1
// Датчика касания левый сработал "y" x20_7_in=1
// Показания радара меньше заданного "u" x20_8_in=1
// Коррекция вперед требуется "i" x32_1_in=1
// Коррекция назад требуется "k" x32_1_in=1 //Была введена эта переменная тк может при коррекции назад нужно отдельная переменная, пока только для красоты: чтобы ее номер был созвучен с номером автомата
// Команда назад выполнена "o" x33_2_in=1

Вывод примера отладочной информации работы логики есть в файле log_example.txt

tic : 2
Старт A20 EVENT = 0
A20 в состоянии 1 запущен с событием e0
A21 в состоянии 1 запущен с событием e0
A21 в состоянии 1 завершил событие e0
A20 в состоянии 1 завершил событие e0

BUTTON 2 PRESSED

tic : 3
Старт A20 EVENT = 2
A20 в состоянии 1 запущен с событием e2
A21 в состоянии 1 запущен с событием e2
A21 перешел из состояния 1 в состояние 2
A32 в состоянии 0 запущен с событием e0
A32 перешел из состояния 0 в состояние 2
z32_2_1 Ф-я Вперёд старт запущена
A32 в состоянии 2 завершил событие e0
z21_2 Ф-я Вперёд запущена
A21 в состоянии 2 завершил событие e2
A20 в состоянии 1 завершил событие e2
Event: 2 Event freeze count: 1

Добавлено спустя 5 минут 11 секунд:
Да, забыл сказать еще про гироскоп, там же еще коррекция движения при получении от гироскопа данных о необходимости коррекции маршрута

Собственно в моем дискусе с Анантолием Шалыто, была затронута тема отображения алгоритмов в автоматизации (роботизации) методом составления графов, что по его мнению на сегодня дает исчерпывающий и оптимальный вариант для построения алгоритма процессингов. При этом профессор сетовал на отсутствие по сей день такой IDE которая давала бы возможность интерпретации графов в исходный код под ту или иную ARM MCU архитектуру с компиляцией на одном из популярных машинных языков, как и отсутствие заказов подкрепленных финансированием для найма кодеров, с целью создания среды разработки.
В своих работах я ему продемонстрировал альтернативный подход к автоматному программированию на реальных примерах в автоматике, когда визуальная среда дает разработчикам возможность отказаться от как предварительного построения графов, так и процесса скрипт кодинга, оперируя всего лишь простыми инструкциями настройки состояний конечных автоматов.
Такой подход у Шалыто вызвал множество вопросов и его заинтересовал пример такого автоматного программирования с демонстрацией всех этапов от алгоритмизации до конечного продукта.
В представленном Вами видеоролике с ссылкой на опыт А.А.Шалыто, я пообещал ему представить такой проект, над чем собственно сейчас и работаем.
Это уникальная возможность, о которой и Вы здесь упоминаете - "не абстрактный стенд, а реальное роботизированное решение", которое продемонстрирует весь потенциал автоматного программирования и предоставит дорожную карту к репликации на другие идеи автоматизации и робототехники.
Нам осталось совсем немного, масса времени и ресурсов уходит на мехатронику, на поиск оптимальных с точки зрения затрат на аппаратную часть и оптимизацию управления перемещениями.
Пришлось буквально изобретать колесо с нуля, т.к. многих механических решений в готовом исполнении не существует и это был мозговой штурм по созданию нашего дозатора, по динамике вспомогательных действий актуаторов, выбор между типами датчиков по их надежности и минимальном наборе.
Что важно, так это тот факт, что у меня нет сомнений, что та или иная часть управления, ограничит проект слабой или невыполнимой процессорной архитектурой, языковой репликацией сложного алгоритма под длинную цепочку сценария. Благодаря свитч технологии нашей IDE все эти проблемы, для меня не проблемы.
Таким образом рабочий прототип уже на 90% готов, ведутся процессы отладки, юстировки, работа над дизайном и эргономикой, включая и документирование, а как без него.

Стендик на небольшой роботележке сделан. Добавлена запись "Проект BiBi. Часть 9."

https://vzikblog.wordpress.com/

Текст размещенный в части 9:

Описание роботележки было дано в "Проект BiBi. Часть 7."
Автоматы реализованы в самом базовом варианте. Описание автоматов и программу для Arduino можно найти по ссылке:
https://cloud.mail.ru/public/pyF1/kFxFyXR7z

Там же выложено небольшое видео показывающее базовую работу автоматов при движении робота вперед.
Тут нужно уточнить, что при срабатывании датчика расстояния робот должен полностью останавиться.
Но так как движетели колес сделаны из старых сервомашинок со спиленными ограничителями, то добиться полной остановки робота при срабатывании датчика расстояния или касания не удается и он начинает немного поворачивать. Это особенность работы переделанных сервомашин в данной реализации.

Проект можно считать успешным в базовом варианте.
Далее можно на имеющиеся автоматы "навешивать" дополнительный функционал, как то - одометры, дополнительные датчики расстояния и другие. Так же предусмотреть передачу обработанных показаний на более высокий уровень контроля движения. Можно по запросу отдавать показания датчиков. Дополнительный функционал будет несложно встроить в уже отлаженный вариант имеющихся автоматов. Так же будет довольно просто переделать программу с Arduino Atmega 328 варианта на любой другой контроллер и IDE так как логика задается на уровне программы сгенерированной на языке С и легко встраивается в другие языки программирования микроконтроллеров.

Так же будет довольно просто переделать программу с Arduino Atmega 328 варианта на любой другой контроллер и IDE так как логика задается на уровне программы сгенерированной на языке С и легко встраивается в другие языки программирования микроконтроллеров.

Здесь честно говоря лично мне не понятно и не все так прозрачно с Вашим SDK для встраивания такого исходника на Си в качестве библиотечного? блока в том виде, в котором Вы его готовы раздавать если к примеру IDE, тот же ROS или нечто под Python, Matlab, LabView или какая либо SCADA... как понимаю Вам нужно под каждую IDE дать в разных языковых форматах представление регистровых значений (Object List) с их описаниями, или предложить какой то шлюз для декодирования Вашего исходника в другие языковые IDE.
Есть здесь еще одни грабли, в плане что при передаче кода на Си к высокоуровневым языковым компиляторам, код становится более требовательным к процессорной части, памяти, частоте, питанию и т.п. Проводили ли Вы для себя такие эксперименты с Atmega/STM/ESP/Texas Instrument и т.п.

Уважаемый Бип Бим, ни о каком моем SDK речи не шло. Если Вы внимательно ознакомились с подходом Автоматного программирования разработанного Шалыто Анатолием Абрамовичем и ссылки на который Вы даете постоянно из Вашего видео и проч. как на источник, Вы это должны прекрасно понимать. Целью данной активности было показать возможность использования подхода для программирования самодвижущихся роботележек чтобы упростить процесс разработки алгоритмов при использовании многочисленных датчиков. Сначала я пробовал самостоятельно писать программу придумывая разные там диспетчеры команд итп, но потом, когда при наличии нескольких датчиков время на отладку и поиск ошибок стало занимать очень много времени при любом несложном изменении логики системы, то стал искать разные вариант подходов к программированию систем со сложным поведением и о чудо! - нашел ресурс на ИТМО по Автоматному программированию. Далее, изучив теорию и просмотрев разные варианты реализации на том же ресурсе, стал применять подход на практике. Время разработки, поиска ошибок, трудоемкость при изменении логики поведения системы сократилась в разы! И я решил поделиться своим опытом с широкой аудиторией, чтобы люди могли ознакомиться с данным подходом если они о нем еще не знают.
По поводу реализации и других особенностей генерации кода нужно просто быть в теме, то есть изучить теорию. Я вообще не понимаю, как Вы могли ссылаться на труды мною глубоко уважаемого Шалыто А.А. если здесь Вы почему то мне задает вопросы прекрасно разобранные в многочисленных публикациях и трудах на ресурсе ИТМО. Советую Вам внимательно с ними ознакомиться, чтобы не обсуждать проблему беспредметно.
И да! Здесь показан процесс построения логики работы, отладки и реализации с записью итогового видео.
А теперь, уважаемый Бип Бим, перемещаемся на Ваш ресурс! Вы же просили от меня предоставить рабочий образец, вот он! Работает! Теперь уже от меня алаверды, так сказать, А где Ваш работающий образец и описание процесса построения алгоритма для него? И просьба, сюда не писать по Вашему IDE. Давайте про Ваше изделие общаться на Вашем ресурсе. И Вы там покажете, как Ваш продукт встраивается куда нибудь. Ну, если Вы упомянули ROS, ну пусть будет ROS, там удобно всякие интерфейсы взаимодействия между разными модулями строить. Ну а я потом в отдельной теме займусь (если время будет) встраиванием роботележки с процессором, эээ, ну пусть будет STM, с логикой написанной на парадигме Автоматного программирования, в более высокоуровневый контроллер движения под каким нибудь более мощным процессором. Хода за Вами! Бип Бим! Ждемс!

Мой последний вопрос относился к Вашему утверждению и я не зря его процитировал. Что касается метода алгоритмизации по А. Шалыто, он красивый и по праву занимает свое место в теории построения алгоритма для языковой реализации, проблема в другом, на сегодня нет среды, которая даст разработчику его реализацию на уровне простой и понятной интерфейсной абстракции, все нужно строить в скрипт языковых IDE, а чтоб это уметь, нужно немало потереться о клавиатуру и отладку ошибок транскрипции или вылавливание ошибок в процессе компиляции, вот о чем и говорю, о чем собственно и сетует наш общий друг.
Что касается моей работы, там люди смотрят и вопросы не задаются, да и не нужен мне так уж сильно Ваш пост, переливание многократное из пустого в порожнее. Смотрел я ваши внешние ресурсы, порог вхождения высокий для интересующихся.

Вот с этого последнего вашего поста я вас не хочу больше здесь видеть. Вы не уважаете собеседников, а нагло лезете со своей проприетарщиной присваивая себе чужие научные труды сами не имея никакой научной базы. Я показал конкретику, а вы лезете со своим проприетарным софтом потому что хотите денег заработать. Вот как раз у вас и есть постоянное переливание из пустого в порожнее с целью впарить вашу программу для лохов не умеющих думать, это и есть ваша аудитория, идите к ней. Лично я никакой коммерческой выгоды из своих постов не получаю и цели у меня совсем другие - чтобы своими мозгами люди думали. Надеюсь вас здесь больше не увидеть.

Всё в.с. есть полный бред, даже в мыслях не было здесь что либо навязывать и чего то присваивать, как вы все это так воспринимаете.
Ну и ладно, чур меня хамством на хамство отвечать, сидите сами здесь в гордом одиночестве и пишите эти опусы для тех кто по вашему в теме и соответствует вашим понятиям опыта.
Что касается демонстрации моих проектов, запаситесь терпения, серьезные вещи требуют детальной проработки, но как я всем обещеал это парад здесь рабочих идей появится на форуме.

Автоматная парадигма – это наверное правильно. Большинство технологических процессов так и работает: тактируемый цикл сбора информации с датчиков и внешних воздействий, обработка измененного состояния, запоминание нового состояния. Т.е. событийное процедурное программирование. Все это, безусловно , работает, но код читается ужасно. Сплошные глобальные флаги, ифы и свичи. Это я про свой код, если что. И не очень соответствует парадигме ООП. По идее робот – это объект (кем же он еще может быть!?). А управляет этим объектом какая-то логическая последовательность команд – миссия («сгоняй на кухню за пивом», например). Сама миссия запускается событием, например по таймеру. Но, последовательность шагов – это уже не автоматное программирование (там скорее параллельность) – это в основном циклы ожидания выполнения функций типа «переместись в точку Х». Зато читается такая программа замечательно, т.к. виден весь сценарий действий робота, который легко редактируется. Можно, конечно, послать смотреть на граф вместо программы. Но и там не особо понятно, где искать ту самую миссию. А функция с названием Z21() любого айтишника повергнет в шок. Граф – это вообще для математиков, а не для программистов.
Мне все говорят, что висеть в циклах, ожидая чего-то, не есть хорошо, даже, если они в другом потоке. И я, скрипя сердцем, возвращаюсь к бесконечным флагам и свичам. Но, в душе понимаю, что истина д.б. где-то в смешении парадигм.

Любая сложная система состоит из набора подсистем. Функционирование системы может быть рассмотрено как взаимодействие между агентами мультиагентной системы. Агенты могут быть разной сложности и выполнять разные задачи, но действовать они должны в общей схеме поведения. Например, у человека есть сердце, есть лёгкие итп. Если рассмотреть еще ниже, то есть клетки, а ещё ниже есть ферменты, белки итп. На самом верхнем уровне имеется кора гоовного мозга, которая управляет работой комплекса но не вмешивается в базовый функционал отдельных агентов, то есть не отслеживает работу ферментов, не управляет работой сердца. Сердце может реагировать на внешние факторы - количество андреналина в крови итп. Работа отдельного примитивного агента основывается на приёме сигналов от других агентов, анализе вычислительной среды (окружающей), внутреннего состояния агента. Работа систем более высокого уровня уже не может быть описана в виде простого агента, так как на высоком уровне действуют другие модели принятия решений. Тот же мозг, это миллиарды отдельных нейронных колонок связанных по топологии звезда. У всех колонок имеется полный набор хранимых данных, то есть память голографическая. Колонки группируются в контексты для поиска информации при её анализе в разных вариантах. Работа систем управления высокого уровня не сводится к описанию логики на базе простых автоматов. А вот работа фермента по выработко того или иного белка как раз очень хорошо описывается с помощью машины Тьюринга, то есть автоматом. Поэтому говорить, что какой подход в описании работы комплекса хорош, а какой то плох не совсем верно. На каждом уровне есть свой алгоритм и применяются свои методы. В данном же случае, на базе тележки с колёсами, я пытался разобраться с работой автоматов для задания алгоритма взаимодействия несложных подсистем. Периодически наблюдаю, как программисты сначала пытаются что то запрограммировать, а потом пытаются понять, как это работает. Как правило работу подсистем они задают с помощью state mechine но при этом никакой академической базы не применяют, пишут, кто во что горазд. В итоге при попытке понять что же у них получилось и как это все вместе работает и откуда и куда и при каких условиях переходит, начинают рисовать схемы взаимодействия, то есть графы, а так как они изначально не рисовали графы в виде продуманной структуры, а делают это уже по факту, то выходит картина в виде тарелки спагетти с помидорками черри. То есть в сложных системах управления от автоматов никуда не деться, но нужно иметь какой то подход, как это правильно проектировать. На сайте института ИТМО я нашел очень неплохой вариат, точнее набор разных подходов для разных задач. Ссылка на сайт https://is.ifmo.ru/ https://is.ifmo.ru/books/ https://is.ifmo.ru/projects/ прочитал многие материалы оттуда, в том числе "Поликарпова Н.И., Шалыто А.А. Автоматное программирование". Что касается кода, который генерируется автоматически на базе графов, то зачем в него смотреть, если логика задаётся графами? А как можно описать логику работы автоматизированной системы, если не использовать визуализацию? А в данном случае, графическое отображение транслируется в код автоматически.

В моем понимании разница между бинарным управлением логики в привычной для нас автоматике, топология которой состоит из программируемой и управляющей станции, исполнительных устройств и устройств обратной связи) которые адаптированы к таким командам как ON, OFF, OR, ELSE, XOR, IF и предполагаемой интеллектуальной логике на тех же командах, но генерируемой в потоке реального времени, по аналогии как это сегодня делают текстовые модели уровня GPT, которые предварительно прокачаны инструкциями с правилами на будь каких-то языках программирования или их симуляторах, включая и протокол передачи таких команд с их обработкой и портированием на программно аппаратном уровне с автоматическим запуском к исполнению.
Т.е. когда мы ему задаем алгоритм – миссию («сгоняй на кухню за пивом», например), и система воспринимает это именно на текстовом уровне с дальнейшей обработкой в реальном времени источника данных где можно взять все эти команды ON, OFF, OR, ELSE, XOR, IF, включая и функции локальной навигации с алгоритмами машинного зрения для анализа изображений и еще дополнительный массив данных для принятия решений в случае непредвиденных ситуаций (кошак прыгнул роботу на камеру и как с этим быть).

Недавно я предпринял эксперимент:
После того, когда я причесал свою платформу до максимально желаемого результата, с изрядной долей перфекционизма со всеми возможными инструкциями и задачами, которые на данный момент мне были поставлены сторонними клиентами и поле многочисленных проб платформы в разных темах, я задался вопросом о возможности прокачать GPT ее инструкциями по их генерации в том виде в котором они представлены в интерфейсе их ввода, который у меня актуален в последней версии.

Я очень подробно наполнил контент примером по управлению шаговиками в разных вариантах от ручного пуска и останова, до управления ими с обратной связью в финале я записал даже видеоролик, как мне это понравилось:.Это линк на всякий случай если у кого-то будет аномалия с просмотром.



Если Вас еще не утомило чтение и просмотры до этого момента, это мои исследования по работе платформы с чатом GPT.

После чего поставил ему задачу:

Нужно на базе всех описаний по настройке и вводу инструкций для логического управления составить инструкцию сценария и указать аппаратные модули для выполнения следующего сценария:
Открыть соленоид гидрозатвора на 12 вольт до момента, когда сосуд наполнится жидкостью на 1 литр, после чего закрыть клапан.

И Вот результат:
Я получил аппаратную спецификацию и детальное описание функционала.

Цель сценария

Открыть соленоидный клапан подачи жидкости до тех пор, пока объем в сосуде не достигнет 1 литра, после чего закрыть клапан.
Необходимые аппаратные модули

Соленоидный клапан на 12 В (обычно нормально закрытый)

Мосфет коммутатор с гальванической развязкой (для подачи питания на клапан)

USB GPIO выходной модуль (как минимум 1 канал)

USB GPIO входной модуль (для сбора сигнала с датчика уровня)

Датчик уровня на 1 литр — можно:

ёмкостной (если жидкость прозрачная и диэлектрическая)

поплавковый с сухим контактом (реле)

NPN индуктивный (если используется металлический шар/флажок)

Источник питания 12 В для силовых цепей

USB HUB (если используется несколько модулей)

Подключение и базовая настройка

Соленоид подключается к выходу мосфет коммутатора, а его вход управляется от GPIO выходного модуля (например, канал 1).

Датчик уровня подключается к GPIO входному модулю (например, канал 1 или 2), который подключён к USB.

Запуск БИптулкит, установка ID входного и выходного модулей через панель R and D.

Проверьте индикацию на датчике: при ненаполненном сосуде — низкий уровень (0 В), при достижении нужного уровня — триггерное значение (например, 2.5 В). Убедитесь, что считывание происходит корректно.

Все каналы по умолчанию в состоянии OFF.
Сценарий пошагово в логических инструкциях
Используемые порты:

Выходной канал 1 — управление мосфет-коммутатором и соленоидом

Входной канал 1 — датчик уровня

Инструкции:

Порт 1:

Условие: Запуск сценария

Действие: Открыть канал 1 (подать 12 В на соленоид через мосфет)

Комментарий: начинается подача жидкости

Порт 2:

Условие: ТРИГГЕР от входного канала 1 превышает 1 В

Действие: Закрыть канал 1

Комментарий: уровень достигнут — клапан закрыт

Дополнительно (опционально):

Порт 3 (логика завершения):

Условие: Закрытие канала 1

Действие: Остановить сценарий / отправить сигнал / отключить питание

Рекомендации по отладке

Используйте 16-канальный дисплей напряжений для проверки срабатывания датчика.

Следите за задержками в логике — сигнал от датчика может слегка "плавать", поставьте временную задержку на 0.2–0.5 с для стабильности.

Проверьте, чтобы соленоид не оставался открыт при сбоях связи (предусмотрите таймер аварийного отключения по времени — например, 10 сек макс. работы)

А вот собственно и портирование с настройками, которые нужно 1:1 перенести в интерфейс IDE программного контроллера и всё, только нажать пуск(прикрепление графики png):

Для сравнения я ставил аналогичные задания для такого алгоритма под разные платформы на базе STM32, ESP и ROS, мне не хватит и километра текста чтоб все это здесь выложить.