Есть системы с довольно сложным поведением.

Скажем есть система где

1. пользователь нажимает на кнопку ОТКРЫТЬ
2. Мотор №1 начинает двигаться - открывается крышка - мотор останавливается достигнув концевого выключателя №1.
3. Мотор №2 начинает двигаться - выезжает экран - мотор останавливается достигнув концевого выключателя №2.

4. пользователь нажимает на кнопку ЗАКРЫТЬ
5. Мотор №2 начинает двигаться - экран заезжает обратно - мотор останавливается достигнув концевого выключателя №3.
6. Мотор №1 начинает двигаться - закрывается крышка - мотор останавливается достигнув концевого выключателя №4.

Естественно на любом участке пути пользователь может применять команды СТОП, ОТКРЫТЬ, ЗАКРЫТЬ и логика отрабатывает команды в соответствии с положением моторов.
То есть если нажать на кнопку ОТКРЫТЬ при закрытой крышке - начнет двигаться Мотор №1. А если нажать на кнопку ОТКРЫТЬ в середине пути - начнет двигаться Мотор №2.
И отслеживаются все положения - скажем Мотор №2 не может начать движение пока крышка полностю не открыта (концевик №1 нажат)

До сих пор я этот сценарий жестко кодировал в микроконтроллере и все было хорошо.
Сейчас есть требование сделать эти сценарии движения програмируемые. (Пользователь загружает скрипт.)
У меня в принципе есть проект где пользователь по UART заливает скрипт я его обрабатываю и произвожу действия. Но там простой PLC - по входным условиям
(значениям на аналоговых и дигитальных входах) я выставляю значения на выходах.

В данном случае никак не соображу какую структуру создать под сценарий движения и как учитывать все логические условия.

Почитайте про конечные автоматы, затем нарисуйте диаграмму состояний для вашего случая. А потом по этой диаграмме уже пишите код. На сколько я знаю, для PLC реализация конечного автомата - типовая вещь. Первый же пример из гугла: Конечные автоматы и автоматизация или программируем ПЛК

У меня код уже написан и все работает. Мне не нужна диаграмма для данного случая. Мне нужен генерик алгоритм в котором я мог скриптом задавать сценарии движения. Я описал частный случай. Завтра сценарий может быть другой.

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

Завтра может быть другая система. Без крышки. Другое движение. Мотор 2 первый начинает движение. Останавливается по другому условию. Единственно что не меняется - это моторы в системе. А паттерны движения и взаимодействия между ними могут меняться - задаваться пользовательским скриптом.

Я думаю тот кто занимался motion или писал axis manager меня поймет.

Есть такая система.
Выезжает короб. Из него выезжает экран. Экран поворачивается вправо влево.
Иногда вместо концевиков я останавливаюсь по положению энкодера или по току. Но это уже частности.

ну так возьмите любой понравившийся скриптовый язык и перепешите ваш рабочий код на нём.

вопрос был не про скрипт

То есть должно быть что то вроде
1. Смотрим какая команда пришла
2. По команде смотрим какое действие к ней пришпандорено (указатель на ф-цию?)
3. Идем в действие - какой мотор должен двигаться и в какую сторону.
4. Проверяем следующее действие - другой мотор начинает движение или нет
Ну это так в общем, каша в голове. А в коде это выразиться в структуре и в алгоритме проверки этой структуры.

Да не надо тут никакого сценария.
Просто запоминайте в каком направлении надо было двигаться по последней команде пользователя.
И пытайтесь включить одновременно все двигатели.
Но перед включением каждого двигателя проверяете все возможные запреты на его включение.
Это и все конечники,и цепи безопасности, и направления, и напряжение, и правильность фазировки напряжения, и таймауты от последней смены направления, а таймауты с предыдущего движения того же мотора и проч.
Тот мотор движение которого ничем не запрещено включится, а кому есть запрет не включиться.
И вы получите правильную последовательность работы моторов в любом случае.
И этот цикл повторяется каждый рабочий такт PLC.
Советую подсмотреть у PLC такие удобные компоненты как TOF, TON и TP


Буквально на прошлой неделе я сдал большой проект для нового аэропорта в Мельбурне.
Там таких моторов было 40 шт. управляемых одновременно по EtherCAT.
Цикл программы 4 мс.
И программа строилась именно так.
Никаких автоматов здесь придумывать не нужно. Сама среда исполнения PLC выполняет роль автомата.

По сути это stateless подход. Я считаю его наиболее надежным и безопасным для ответственной автоматики.

То есть в цикле пробежаться по всем моторам и проверить условия? А как реагировать на приходящие команды? Включать команду в условие? Мое PLC это программа написанная в контроллере.

Да, именно. В условии проверяется и команда. И пытаемся включать во всех возможных направлениях.

Большинство PLC - это программы написанные в микроконтроллере.
Или вы хотите сказать что у вас ненастоящий PLC?
У PLC важнейшая фича - это менеджер задач с контролем времени исполнения каждой задачи. Если его нет, то надо сделать.

По поводу автоматного программирования мне тут недавно подкинули хорошую ссылку http://is.ifmo.ru/books/_book.pdf
Что-то похожее по уровню, но по stateless подходу для для ответственной автоматики почитать не подскажите?

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

Создается впечатление, что это "взгляд со стороны" какой-то. Ну, т.е. поверхностный.

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

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

Я, конечно, большие и сложные системы не проектировал, но вот вы пишите
А я чего-то думаю ну ОК, а возможность/невозможность включения двигателей(т.е. все эти ограничения) как раз и зависят от состояния в котором находится сервопривод(назовем так совокупность двигателя, концевиков, измерителей тока и т.д.). Т.е. вы, собирая параметры с серво привода и пытаясь проверить ограничения, решая можно ли включать двигатель, по сути неким дедуктивным способом и пытаетесь выяснить состояние...

Аналогичным образом в вышеупянутой pdfке реализован будильник а при каких-то действиях проверяется куча флагов.

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

Отдавать пользователю возможность управления автоматической системой скриптами - большего бреда и представить не могу.

Это Jenya7, это норма ))))

Не я собираю, а среда исполнения PLC. Она каждую 1 мс берет и собирает всю 1000 сигналов которые использовались в моей программе, меня не спрашивает.
Ну просто так устроены PLC. A EtherCAT позволяет все собрать за 1 мс.
Конечно в cамой среде PLC есть состояния, события, очереди сообщений и проч. Там, не сомневаюсь, жесткая RTOS установлена.
Я использую массивы из сотен таймеров чтобы тот же дребезг конечников нейтрализовать.
Но в цикле моей программы, которую именно я написал нет никаких состояний.
Мне фреймворк PLC позволяет это сделать. Вот и вся теория.

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

Ок, я тут спорить не буду, 1000 сигналов никогда не собирал и не использовал в программе. В общем так пока отметил для себя, что когда автоматы и состояния сделали всю работу, то дальше можно стэйтлэсс что-то совсем высокоуровневое сделать по быстрому ))))))