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

[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ке реализован будильник а при каких-то действиях проверяется куча флагов.

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

[AlexandrY]

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

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

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

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