Перейти к содержанию
    

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

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

 

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

 

1. пользователь нажимает на кнопку ОТКРЫТЬ

2. Мотор №1 начинает двигаться - открывается крышка - мотор останавливается достигнув концевого выключателя №1.

3. Мотор №2 начинает двигаться - выезжает экран - мотор останавливается достигнув концевого выключателя №2.

 

4. пользователь нажимает на кнопку ЗАКРЫТЬ

5. Мотор №2 начинает двигаться - экран заезжает обратно - мотор останавливается достигнув концевого выключателя №3.

6. Мотор №1 начинает двигаться - закрывается крышка - мотор останавливается достигнув концевого выключателя №4.

 

Естественно на любом участке пути пользователь может применять команды СТОП, ОТКРЫТЬ, ЗАКРЫТЬ и логика отрабатывает команды в соответствии с положением моторов.

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

И отслеживаются все положения - скажем Мотор №2 не может начать движение пока крышка полностю не открыта (концевик №1 нажат)

 

До сих пор я этот сценарий жестко кодировал в микроконтроллере и все было хорошо.

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

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

(значениям на аналоговых и дигитальных входах) я выставляю значения на выходах.

 

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

post-71075-1500272529_thumb.png

Изменено пользователем Jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

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

 

Есть такая система.

Выезжает короб. Из него выезжает экран. Экран поворачивается вправо влево.

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

post-71075-1500277690_thumb.png

Изменено пользователем Jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

То есть должно быть что то вроде

1. Смотрим какая команда пришла

2. По команде смотрим какое действие к ней пришпандорено (указатель на ф-цию?)

3. Идем в действие - какой мотор должен двигаться и в какую сторону.

4. Проверяем следующее действие - другой мотор начинает движение или нет

Ну это так в общем, каша в голове. А в коде это выразиться в структуре и в алгоритме проверки этой структуры.

Изменено пользователем Jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Да не надо тут никакого сценария.

Просто запоминайте в каком направлении надо было двигаться по последней команде пользователя.

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

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

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

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

И вы получите правильную последовательность работы моторов в любом случае.

И этот цикл повторяется каждый рабочий такт PLC.

Советую подсмотреть у PLC такие удобные компоненты как TOF, TON и TP

 

 

Буквально на прошлой неделе я сдал большой проект для нового аэропорта в Мельбурне.

Там таких моторов было 40 шт. управляемых одновременно по EtherCAT.

Цикл программы 4 мс.

И программа строилась именно так.

Никаких автоматов здесь придумывать не нужно. Сама среда исполнения PLC выполняет роль автомата.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да не надо тут никакого сценария.

Просто запоминайте в каком направлении надо было двигаться по последней команде пользователя.

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

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

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

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

И вы получите правильную последовательность работы моторов в любом случае.

И этот цикл повторяется каждый рабочий такт PLC.

Советую подсмотреть у PLC такие удобные компоненты как TOF, TON и TP

 

 

Буквально на прошлой неделе я сдал большой проект для нового аэропорта в Мельбурне.

Там таких моторов было 40 шт. управляемых одновременно по EtherCAT.

Цикл программы 4 мс.

И программа строилась именно так.

Никаких автоматов здесь придумывать не нужно. Сама среда исполнения PLC выполняет роль автомата.

 

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

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

Изменено пользователем Jenya7

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Большинство PLC - это программы написанные в микроконтроллере.

Или вы хотите сказать что у вас ненастоящий PLC?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

По поводу автоматного программирования мне тут недавно подкинули хорошую ссылку http://is.ifmo.ru/books/_book.pdf

Что-то похожее по уровню, но по stateless подходу для для ответственной автоматики почитать не подскажите?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По поводу автоматного программирования мне тут недавно подкинули хорошую ссылку http://is.ifmo.ru/books/_book.pdf

Что-то похожее по уровню, но по stateless подходу для для ответственной автоматики почитать не подскажите?

В реальности нет такого подхода, как нет и автоматного подхода.

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

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

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

Чтобы я мог изобразить что-то в стиле "stateless" , мне надо было иметь как основу мощный фреймворк PLC.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

 

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

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

 

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

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

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем Trump

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

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

×
×
  • Создать...