Програмно задать поведение двигателей в С. Опции

[Jenya7]

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

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

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

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

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

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

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

Сообщение отредактировал Jenya7 - Jul 17 2017, 06:22

Эскизы прикрепленных изображений

 

[sigmaN]

Не теории помогают программировать сложные вещи, а фреймворки. Они и диктуют стиль и "подходы"

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

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

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

Я, конечно, большие и сложные системы не проектировал, но вот вы пишите

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

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

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

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