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

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

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

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

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

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

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

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

0

Еще проверку состояний где крышка и экран не описали. У Вас всё расписано.

0

Сообщение от DYZIT Еще проверку состояний где крышка и экран не описали. У Вас всё расписано.

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

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

0

Сообщение от jimyo77 Нужен общий алгоритм.

Сам же написал в первом сообщении этот самый общий алгоритм...

0

Есть 2 действия:
1. Открыть
2. Закрыть
Если нажимаешь кнопку "Открыть" выполняется действие 1, если кнопку "закрыть" - действие 2.
Есть еще кнопка "стоп", но она просто останавливает процесс. На перечень действий она не влияет и не стоит акцентировать на нее внимание.
Опишите алгоритм для открытия, для закрытия. По кнопке "стоп" отключайте оба двигателя.
Примерно так
Открытие
1. Крышка открыта? Если да - Конец
2. Если крышка не открыта - вращать двигатель до открытия крышки
3. Переход к п.1
4. Конец

Закрытие
1. Крышка закрыта? Если да - Конец
2. Если крышка не закрыта - вращать двигатель до закрытия крышки
3. Переход к п.1
4. Конец

Стоп
1. Отключить питание со всех двигателей

0

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

0

Сообщение от Кат495 Если пользователю предлагается загружать скрипт, нужно сначала договориться, на каком языке будет этот скрипт. Когда язык выбран, Вам придется написать для МК интерпретатор этого языка.

Мой вопрос был не про скрипт и не про интерпретатор.

0

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

По сути сценарий и должен быть структурой конечного автомата, и без простого скриптового языка здесь все-таки не обойтись. Причем, если между состояниями автомата возможны произвольные переходы, получится вообще что-то вроде бейсика:
А то и вообще Lua придется запиливать…

0

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

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

0

Сессия давно закончилась, вроде лето пришло. Вам надо программу написать или зачем Вы собой народ мучаете?

0

Слово "IEC 61131-3" еще не прозвучало? Можно взять кого-нибудь из них и реализовать некое подобие.

Но я бы предложил кардинально другой подход: основная прошивка - это исполняющая среда и библиотека. "Скрипт" пользователя - это программа на Си, использующая эту библиотеку. Компилируем локально, отправляем на МК, там вызываем.

0

Сообщение от div Компилируем локально, отправляем на МК, там вызываем.

Можно бутлоадер запилить, который будет, скажем, с флешки считывать код, записывать к себе во флеш и запускать.
Но ТС, похоже, хочет как можно проще реализовать сторону пользователя. Чуть ли не ПЛК свою запилить...

0

Что-то я не вижу здесь проблемы. От слова совсем.
Эленент скрипта = действие. Список описанных действий:
1. Мотор №1 двигается до концевого выключателя №1 (->)
2. Мотор №2 двигается до концевого выключателя №2 (->)
3. Мотор №2 двигается до концевого выключателя №3 (<-)
4. Мотор №1 двигается до концевого выключателя №4 (<-)
В скрипте следует прописать, по команде
ОТКРЫТЬ: п1, п2
ЗАКРЫТЬ: п3, п4
Если последовала команда СТОП, то интерпретатор останавливается.
В любой момент можно нажать любую кнопку, она вызовет прерывание текущей операции и начнет свою.
В "примере" нет "кольцевых" команд, поэтому скрипту вообще перпендикулярно текущее состояние механики.
Если кото не понял, расшифрую - "Мотор №1 двигается до концевого выключателя №1" означает, что мотор будет двигаться до тех пор, пока не сработает концевик. Если на начало команды мотор уже находился в сработавшем концевике, то он начнет движение и сразу остановится, т.к. состояние достигнуто.
Короче говоря, Никаких проблем нет. Но они появятся, если в скрипте появятся "кольца".
Например, надо обойти препятствие. Для этого надо вначале идти вверх, затем вправо, затем вниз. Обратное движение будет зеркальным - вверх, слево, вниз. Если движение прервано в неизвестной точке, то выполнение скрипта ... будет выполнено нормально. Довольно трудно придумать то, что-бы не работало. )) Взаимно симметричные команды буду выполняться правильно, вне зависимости от места их прерывания (в том числе и при отрубании питания системы и кидания механики в неизвестное состояние).
Когда же будет проблема? А тогда, когда появятся НЕ симметричные команды. Например - открыть, выдвинуть, вдвинуть, закрыть.
Их последовательное выполнение не вызывает проблем (никогда), но если пропустить или передвинуть одну из команд, то выйдет хрень. Пропустили "вдвинуть", получили режим закрытия с выдвинутой fosi. Fosi прищемили.
Здесь выходов два - или по команде STOP делать UNDO (обратное выполнение скрипта до начала операции) или ставить концевики и (или) заводить состояние механики (current state). Вот это точно "хрень".
Короче - делайте нормальные симметричные скрипты. Тогда всё просто и надежно. ))

0

Сообщение от u37 Что-то я не вижу здесь проблемы. От слова совсем. Эленент скрипта = действие. Список описанных действий: 1. Мотор №1 двигается до концевого выключателя №1 (->) 2. Мотор №2 двигается до концевого выключателя №2 (->) 3. Мотор №2 двигается до концевого выключателя №3 (<-) 4. Мотор №1 двигается до концевого выключателя №4 (<-) В скрипте следует прописать, по команде ОТКРЫТЬ: п1, п2 ЗАКРЫТЬ: п3, п4 Если последовала команда СТОП, то интерпретатор останавливается. В любой момент можно нажать любую кнопку, она вызовет прерывание текущей операции и начнет свою. В "примере" нет "кольцевых" команд, поэтому скрипту вообще перпендикулярно текущее состояние механики. Если кото не понял, расшифрую - "Мотор №1 двигается до концевого выключателя №1" означает, что мотор будет двигаться до тех пор, пока не сработает концевик. Если на начало команды мотор уже находился в сработавшем концевике, то он начнет движение и сразу остановится, т.к. состояние достигнуто. Короче говоря, Никаких проблем нет. Но они появятся, если в скрипте появятся "кольца". Например, надо обойти препятствие. Для этого надо вначале идти вверх, затем вправо, затем вниз. Обратное движение будет зеркальным - вверх, слево, вниз. Если движение прервано в неизвестной точке, то выполнение скрипта ... будет выполнено нормально. Довольно трудно придумать то, что-бы не работало. )) Взаимно симметричные команды буду выполняться правильно, вне зависимости от места их прерывания (в том числе и при отрубании питания системы и кидания механики в неизвестное состояние). Когда же будет проблема? А тогда, когда появятся НЕ симметричные команды. Например - открыть, выдвинуть, вдвинуть, закрыть. Их последовательное выполнение не вызывает проблем (никогда), но если пропустить или передвинуть одну из команд, то выйдет хрень. Пропустили "вдвинуть", получили режим закрытия с выдвинутой fosi. Fosi прищемили. Здесь выходов два - или по команде STOP делать UNDO (обратное выполнение скрипта до начала операции) или ставить концевики и (или) заводить состояние механики (current state). Вот это точно "хрень". Короче - делайте нормальные симметричные скрипты. Тогда всё просто и надежно. ))

Что внутри? Какие члены структуры?
typedef struct PORSED_SCRIPT_S
{
}PORSED_SCRIPT;

0

jimyo77
u37 предложил простой вариант, разбить файл на 2 секции, в одной кодируем действия, в другой - список действий для кнопки. Какие Вам ещё члены структуры?

0

yacc Вам в помощ. Генерит лексические анализаторы в зависимости от ваших условий.

0

Сообщение от jimyo77 Что внутри? Какие члены структуры? typedef struct PORSED_SCRIPT_S{ }PORSED_SCRIPT;

массив из опкодов виртуальной машины.

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

0

Сообщение от Kitvym jimyo77 u37 предложил простой вариант, разбить файл на 2 секции, в одной кодируем действия, в другой - список действий для кнопки. Какие Вам ещё члены структуры? Код:

[Секция действий]
[ID][Условие завершения][Действие1][Действие2][Действиеn]
[Секция кнопок]
[Кнопка][ID1][ID2][IDn]

ну да...что то вроде того...ну это и есть члены структуры - [ID][Условие завершения][Действие1][Действие2][Действиеn]. это ведь мне передал пользователь в скрипте. мне ведь это хранить где то надо. осталось оформить это как то програмно.

0

Сообщение от _pv Сообщение от jimyo77 Что внутри? Какие члены структуры? typedef struct PORSED_SCRIPT_S{ }PORSED_SCRIPT;

массив из опкодов виртуальной машины.

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

зачем? я положил все это один раз - ну хоть сюда [ID][Условие завершения][Действие1][Действие2][Действиеn] и работаю с этим.

0

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

Прикрутить простенький скритовый движок, Lua или упрощенный JS. Их много, и хороших тоже.

https://github.com/cesanta/mjs
https://github.com/elua/elua

0