jenya7 0 17 июля, 2017 Опубликовано 17 июля, 2017 (изменено) · Жалоба Есть системы с довольно сложным поведением. Скажем есть система где 1. пользователь нажимает на кнопку ОТКРЫТЬ 2. Мотор №1 начинает двигаться - открывается крышка - мотор останавливается достигнув концевого выключателя №1. 3. Мотор №2 начинает двигаться - выезжает экран - мотор останавливается достигнув концевого выключателя №2. 4. пользователь нажимает на кнопку ЗАКРЫТЬ 5. Мотор №2 начинает двигаться - экран заезжает обратно - мотор останавливается достигнув концевого выключателя №3. 6. Мотор №1 начинает двигаться - закрывается крышка - мотор останавливается достигнув концевого выключателя №4. Естественно на любом участке пути пользователь может применять команды СТОП, ОТКРЫТЬ, ЗАКРЫТЬ и логика отрабатывает команды в соответствии с положением моторов. То есть если нажать на кнопку ОТКРЫТЬ при закрытой крышке - начнет двигаться Мотор №1. А если нажать на кнопку ОТКРЫТЬ в середине пути - начнет двигаться Мотор №2. И отслеживаются все положения - скажем Мотор №2 не может начать движение пока крышка полностю не открыта (концевик №1 нажат) До сих пор я этот сценарий жестко кодировал в микроконтроллере и все было хорошо. Сейчас есть требование сделать эти сценарии движения програмируемые. (Пользователь загружает скрипт.) У меня в принципе есть проект где пользователь по UART заливает скрипт я его обрабатываю и произвожу действия. Но там простой PLC - по входным условиям (значениям на аналоговых и дигитальных входах) я выставляю значения на выходах. В данном случае никак не соображу какую структуру создать под сценарий движения и как учитывать все логические условия. Изменено 17 июля, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
arhiv6 14 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба Почитайте про конечные автоматы, затем нарисуйте диаграмму состояний для вашего случая. А потом по этой диаграмме уже пишите код. На сколько я знаю, для PLC реализация конечного автомата - типовая вещь. Первый же пример из гугла: Конечные автоматы и автоматизация или программируем ПЛК Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба Почитайте про конечные автоматы, затем нарисуйте диаграмму состояний для вашего случая. А потом по этой диаграмме уже пишите код. На сколько я знаю, для PLC реализация конечного автомата - типовая вещь. Первый же пример из гугла: Конечные автоматы и автоматизация или программируем ПЛК У меня код уже написан и все работает. Мне не нужна диаграмма для данного случая. Мне нужен генерик алгоритм в котором я мог скриптом задавать сценарии движения. Я описал частный случай. Завтра сценарий может быть другой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ikm 0 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба В данном случае никак не соображу какую структуру создать под сценарий движения и как учитывать все логические условия. Я вот тоже не могу понять какие могут быть еще логические условия. Ведь пользователь физически не может двигать монитор, если крышка не в том положении. Так же у концевиков всего 3 состояния оба открыты, или один из них закрыт. Вот в голову не приходят какие либо скрипты, кроме совсем абсурдных, типа открыть крышку и и закрыть крышку не двигая монитор. Ну или ввести "код-последовательное нажатие кнопок" чтобы перевести монитор в другое положение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 17 июля, 2017 Опубликовано 17 июля, 2017 (изменено) · Жалоба Я вот тоже не могу понять какие могут быть еще логические условия. Ведь пользователь физически не может двигать монитор, если крышка не в том положении. Так же у концевиков всего 3 состояния оба открыты, или один из них закрыт. Вот в голову не приходят какие либо скрипты, кроме совсем абсурдных, типа открыть крышку и и закрыть крышку не двигая монитор. Ну или ввести "код-последовательное нажатие кнопок" чтобы перевести монитор в другое положение. Завтра может быть другая система. Без крышки. Другое движение. Мотор 2 первый начинает движение. Останавливается по другому условию. Единственно что не меняется - это моторы в системе. А паттерны движения и взаимодействия между ними могут меняться - задаваться пользовательским скриптом. Я думаю тот кто занимался motion или писал axis manager меня поймет. Есть такая система. Выезжает короб. Из него выезжает экран. Экран поворачивается вправо влево. Иногда вместо концевиков я останавливаюсь по положению энкодера или по току. Но это уже частности. Изменено 17 июля, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 54 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба ну так возьмите любой понравившийся скриптовый язык и перепешите ваш рабочий код на нём. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 17 июля, 2017 Опубликовано 17 июля, 2017 (изменено) · Жалоба ну так возьмите любой понравившийся скриптовый язык и перепешите ваш рабочий код на нём. вопрос был не про скрипт То есть должно быть что то вроде 1. Смотрим какая команда пришла 2. По команде смотрим какое действие к ней пришпандорено (указатель на ф-цию?) 3. Идем в действие - какой мотор должен двигаться и в какую сторону. 4. Проверяем следующее действие - другой мотор начинает движение или нет Ну это так в общем, каша в голове. А в коде это выразиться в структуре и в алгоритме проверки этой структуры. Изменено 17 июля, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба В данном случае никак не соображу какую структуру создать под сценарий движения и как учитывать все логические условия. Да не надо тут никакого сценария. Просто запоминайте в каком направлении надо было двигаться по последней команде пользователя. И пытайтесь включить одновременно все двигатели. Но перед включением каждого двигателя проверяете все возможные запреты на его включение. Это и все конечники,и цепи безопасности, и направления, и напряжение, и правильность фазировки напряжения, и таймауты от последней смены направления, а таймауты с предыдущего движения того же мотора и проч. Тот мотор движение которого ничем не запрещено включится, а кому есть запрет не включиться. И вы получите правильную последовательность работы моторов в любом случае. И этот цикл повторяется каждый рабочий такт PLC. Советую подсмотреть у PLC такие удобные компоненты как TOF, TON и TP Буквально на прошлой неделе я сдал большой проект для нового аэропорта в Мельбурне. Там таких моторов было 40 шт. управляемых одновременно по EtherCAT. Цикл программы 4 мс. И программа строилась именно так. Никаких автоматов здесь придумывать не нужно. Сама среда исполнения PLC выполняет роль автомата. По сути это stateless подход. Я считаю его наиболее надежным и безопасным для ответственной автоматики. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 17 июля, 2017 Опубликовано 17 июля, 2017 (изменено) · Жалоба Да не надо тут никакого сценария. Просто запоминайте в каком направлении надо было двигаться по последней команде пользователя. И пытайтесь включить одновременно все двигатели. Но перед включением каждого двигателя проверяете все возможные запреты на его включение. Это и все конечники,и цепи безопасности, и направления, и напряжение, и правильность фазировки напряжения, и таймауты от последней смены направления, а таймауты с предыдущего движения того же мотора и проч. Тот мотор движение которого ничем не запрещено включится, а кому есть запрет не включиться. И вы получите правильную последовательность работы моторов в любом случае. И этот цикл повторяется каждый рабочий такт PLC. Советую подсмотреть у PLC такие удобные компоненты как TOF, TON и TP Буквально на прошлой неделе я сдал большой проект для нового аэропорта в Мельбурне. Там таких моторов было 40 шт. управляемых одновременно по EtherCAT. Цикл программы 4 мс. И программа строилась именно так. Никаких автоматов здесь придумывать не нужно. Сама среда исполнения PLC выполняет роль автомата. По сути это stateless подход. Я считаю его наиболее надежным и безопасным для ответственной автоматики. То есть в цикле пробежаться по всем моторам и проверить условия? А как реагировать на приходящие команды? Включать команду в условие? Мое PLC это программа написанная в контроллере. Изменено 17 июля, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба То есть в цикле пробежаться по всем моторам и проверить условия? А как реагировать на приходящие команды? Включать команду в условие? Мое PLC это программа написанная в контроллере. Да, именно. В условии проверяется и команда. И пытаемся включать во всех возможных направлениях. Большинство PLC - это программы написанные в микроконтроллере. Или вы хотите сказать что у вас ненастоящий PLC? У PLC важнейшая фича - это менеджер задач с контролем времени исполнения каждой задачи. Если его нет, то надо сделать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба По сути это stateless подход. Я считаю его наиболее надежным и безопасным для ответственной автоматики. По поводу автоматного программирования мне тут недавно подкинули хорошую ссылку http://is.ifmo.ru/books/_book.pdf Что-то похожее по уровню, но по stateless подходу для для ответственной автоматики почитать не подскажите? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба По поводу автоматного программирования мне тут недавно подкинули хорошую ссылку http://is.ifmo.ru/books/_book.pdf Что-то похожее по уровню, но по stateless подходу для для ответственной автоматики почитать не подскажите? В реальности нет такого подхода, как нет и автоматного подхода. Есть теория автоматов, она существует параллельно с теорией линейных систем, с теорией массового обслуживания, с теорией управления, с теорией относительности и прочими теориями. Но брать и так тупо, изолировано и механистически переносить торию автоматов на технологию программирования это надо быть больным на всю голову. В программировании гораздо больше инструментов, методов и подходов чем может дать какая-то теория автоматов. Чтобы я мог изобразить что-то в стиле "stateless" , мне надо было иметь как основу мощный фреймворк PLC. Не теории помогают программировать сложные вещи, а фреймворки. Они и диктуют стиль и "подходы" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба Не теории помогают программировать сложные вещи, а фреймворки. Они и диктуют стиль и "подходы" Создается впечатление, что это "взгляд со стороны" какой-то. Ну, т.е. поверхностный. А так то под всеми фреймворками лежит некая основа. Что конкретно они упрощают для человека путем введения более высокоуровневых абстракций. На определенном же уровне парадигма автоматного программирования очень даже уместна и упрощает программирование. Там приведен очень красноречивый пример с будильником на флагах и на состояниях. Какими бы не были,цитирую, "больным на всю голову", авторы упомянутой книги, они очень подробно и аргументированно изложили свои мысли. Думал есть что почитать подобного уровня изложения, но про ваш "stateless" подход. Я, конечно, большие и сложные системы не проектировал, но вот вы пишите И пытайтесь включить одновременно все двигатели. Но перед включением каждого двигателя проверяете все возможные запреты на его включение. А я чего-то думаю ну ОК, а возможность/невозможность включения двигателей(т.е. все эти ограничения) как раз и зависят от состояния в котором находится сервопривод(назовем так совокупность двигателя, концевиков, измерителей тока и т.д.). Т.е. вы, собирая параметры с серво привода и пытаясь проверить ограничения, решая можно ли включать двигатель, по сути неким дедуктивным способом и пытаетесь выяснить состояние... Аналогичным образом в вышеупянутой pdfке реализован будильник а при каких-то действиях проверяется куча флагов. Вот и хочется понять в чем разница, оценить преимущества и недостатки разных подходов. Кто-то бы выделил состояния в которых может находиться сервопривод и сразу бы однозначно дал ответ на вопрос можно ли из этого состояния включить двигатель на вращение по часовой стрелке или нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Trump 0 17 июля, 2017 Опубликовано 17 июля, 2017 (изменено) · Жалоба Отдавать пользователю возможность управления автоматической системой скриптами - большего бреда и представить не могу. Изменено 17 июля, 2017 пользователем Trump Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sigmaN 0 17 июля, 2017 Опубликовано 17 июля, 2017 · Жалоба Отдавать пользователю скриптами возможность управления автоматической системой - большего бреда и представить не могу. Это Jenya7, это норма ;))))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться