Импульсные и поенциальные команды в контроллере

[petr2off]

Дьрбрый день. Был в командировке, познакомился с местным программистом Романом, большим фанатом Овена. С удивлением обнаружил, что он применяет только потенциальные команды, а импульсные считает злом и недоразумением. Сам он по жизни весьма категоричен, и не любит признавать собственные заблуждения. Опять же так пламенно говорил. :) Не стал я с ним спорить.
Ну а вообще, по моим представлениям хорошая практика использовать оба типа команд.
Потенциальные - для (например) блокирующих команд, т.е. есть условия блокировки клапана на закрытие и команда должна висеть пока условия блокировки не исчезнуло.
Импульсные - например команда оператора. Понятно, внутри контроллера она может быть триггером зафиксировано, но на АРМ она должна быть импульсная, что бы (например) при перезагрузке АРМ никаких неявных команд в сторону контроллера не полетело.
А вообще, такое разделение это:
1) Мои личные представления о хорошем стиле (или заблуждения)
2) Хорошая практика
3) Или есть какие то документальные рекомендации ?

[Ryzhij]

Ну а вообще, по моим представлениям хорошая практика использовать оба типа команд.

Поддерживаю Ваше мнение, коллега. Для разных систем - разные команды и фидбэки хороши.

[megavolt86]

на АРМ она должна быть импульсная, что бы (например) при перезагрузке АРМ никаких неявных команд в сторону контроллера не полетело.

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

[petr2off]

Как правило цикл плк достаточно маленький, обычно не более 100 мс, время испульса от кнопки АРМ - связано с человеком, и оно существенно больше, минимум 1 сек, т.е. ПЛК 10 раз успееет попросить регистр связанный с кнопкой. Хотя и предложенный Вами алгоритм, имеет право на существование.

[leon78]

Обычно с АРМ делают однократную запись команды в регистр ПЛК, а ПЛК после обработки обнуляет этот регистр.

[petr2off]

Зависит от элементов АРМ.
Например в Мастер Скада 4д есть элемнт кнопка, этьо элемент можно связать с регистром Модбас. У кнопки есть опция - с фиксацией, если эта опция установлена,то в регистр постоянно пишется знпачение true, есди нет - то в регистр пишется значение true, пока кнопка не нажата. А еще, если переменная может имеет тип InOut - т.е. регистр разделяется на 2 ячейки, с одной пишется командой 6 с другой читается командой 3. Т.е. вариантов множество, а есть еще политика записи по изменению, илли по периоду. В зависимости от конкретной задачи, тот или иной вариант предпочтительней.

Отправлено спустя 6 минут 1 секунду:
Извиняюсь, пишется true - пока кнопка нажата. Это в режиме без фиксации

[Михайло]

Вопрос сводится, кто и когда устанавливает бит, а кто и по какому событию сбрасывает.
Если устанавливается/сбрасывается в HMI по фронту переднему/заднему нажатия кнопки, то это проще всего в реализации, но начинает "глючить" при возрастании времени цикла выполнения ПЛК. Но учитывая, что система должна проектироваться так, что тормозов не должно быть, то как бы вопрос не представляет проблемы. Человек регулирует длину импульса, удерживая кнопку необходимое время. Но если две системы обмениваются сигналами в автоматическом режиме (так называемые флаги), то такой подход не годится.
Самое простое - одна система устанавливает, другая система сбрасывает флаг. При этом каждая из систем может гарантированно контролировать, что сигнал прошел и принят, а также с другой стороны получено подтверждение (целых 4 события одним битом, по два события в каждой системе).

1. Импульсный подход (реакция на фронт)
2. Потенциальный подход (реакция на уровень)

Отправлено спустя 16 минут 21 секунду:
Я сталкивался с устройствами, которые работали по импульсному принципу. Типа "первый импульс - вкл", "второй импульс - откл". Такие устройства оказались нежизнеспособны, а разработчики неадекватны. Всякие там соленоиды, реле и пускатели работают по потенциальному принципу.
В умных домах такая проблема: всякие там Modbus TCP в АСУТП работают в режиме поллинга, т.е. постоянно передают информацию, каждые 10-100 мсек. Беспроводные устройства не выдержат такой нагрузки (сотовые телефоны, устройства Bluetooth, ZWave, Zigbee). Поэтому подход по принципу "издатель-брокер-подписчик". Увидели, что устройство подключилось (сотовый телефон) и если видим, что ранее отправленная "почта" не прочитана, то повторяем отправку. Тут на каждого подписчика вроде как два бита выделено ("отправлено", "принято"). Усовершенствованный импульсный подход что ли... Дополнительный бит - это есть информация о целостности сети (устройство в сети или вне сети).

[megavolt86]

"первый импульс - вкл", "второй импульс - откл". Такие устройства оказались нежизнеспособны, а разработчики неадекватны.

Ой, дядь Миша, обругали то чоооо)))
Почему не жизнеспособны? И почему неадекватны?
Все зависит от задачи, физических возможностей и интуиции разработчика)
Например, управление насосом: привод выключен, нажатие на кнопку приводит к пуску, привод включен - к остановке...длительность нажатия не имеет значения, нужен только растущий фронт сигнала. Длительность нажатия отслеживалась только если сработал сигнал о неисправности - три секунды подержал кнопку авария ушла.
Причина такой реализации - нехватка жил в контрольном кабеле.
И ничего... Работает уже несколько лет без нареканий и аборигенам даж нравится)
Итого одна кнопка реализует три функции, тут и импульсы и постоянный сигнал.

[Михайло]

В моем случае это был драйвер шагового двигателя. Подал импульс - поехал, подал второй импульс - остановилось.
Все свелось к тому, что вместо того, чтобы управлять движением по уровню одного дискретного сигнала, пришлось сгородить целую программу, которая надежно бы определяла, какое число импульсов подано - четное или нечетное, чтобы понимать, в каком реальном состоянии находится драйвер. И непонятно, а вдруг нажали аварийный грибок, когда импульс на запуск уже прошел в течение 20 мс, то в каком состоянии находится драйвер?.. Нужно ли подавать еще один импульс на останов? Все это с кучей таймеров и мозголомки оказалось нежизнеспособно, не работало: нажал стоп, а он, наоборот, едет.
И это оказалось, не единственный подобный продукт данной фирмы с такой фичей и драйверы, оказалось, дают погрешность в позиционировании. В итоге они лежат на полке, хотя по некоторым решениям эти драйверы казались "вкусными".

[petr2off]

У каждого нормального специалиста складывается своя маленькая библиотечка алгоритмов, методов, функций. Естественно, если человек обучаемый она потихоньку развивается. Мое понимание на данный момент следующее. Это колнечно важно знать, что команда дошла до ПЛК, но все таки важней знать, что она начала (как минимум) исполнятся.
Поэтому я практикую следующий подход.
1) Есть исполнительный механизм - ИМ (он может быть разного типа)
2) Есть функциональные блоки, для его управления.
3) Управляющий блок может иметь несколько управляющих входов, потенциальных или импульсных.
4) Входа связанные с блокировками и защитами - потенциальные. И имеют более высокий приоритет.
5) Вместо снятии команды, я использую статусное слово, описывающее состояние ИМ. Т.е. прошла испульсная команда от оператора открывать клапан, в статусе взводится бит - что исполняется команда open и бит что ИМ открывается.
Вариант со статусом ИМ мне кажется более предпочтительным, потому как позволяет обработать много больше сосотояний и ошибок и более информативен чем осознание того факта, что команда дошла до ПЛК.
Кроме того - возникает вопрос, а ПЛК должен узнать, что АРМ увидел, что команда принята ? И насколько далеко должная зайти эта рекурсия ? По статусу ИМ я могу в АРМ показать, что ИМ начал открыватся (например), точто сработали концевики, то что за нормативное время ИМ на отработал команду, что у него пропало питание и т.д. Ну и заодно, такую маленькую феничку, что команда принята на исполнение.

[Универсал]

Всякие там соленоиды, реле и пускатели работают по потенциальному принципу.

Бистабильные реле? Газовые клапаны с ручным взводом?

[keysansa]

Импульсные - например команда оператора. Понятно, внутри контроллера она может быть триггером зафиксировано, но на АРМ она должна быть импульсная, что бы (например) при перезагрузке АРМ никаких неявных команд в сторону контроллера не полетело.

Использование только потенциальной логики в программе - потенциально опасно, как минимум (интересно звучит, хоть и не красиво).
Машина после подачи напряжения не должна выполнять никаких действий. Иначе она опасна.
Значит, для безопасности, необходим импульсный сигнал запуска. Потенциальный сигнал запуска сработает при подаче напряжения быть беде, возможно не сразу, но быть.
Узлы машины - могут иметь потенциальное управление, для удобства. Однако, удобство и безопасность - достаточно часто противоречат друг другу.

[Ryzhij]

Вариантов множество. И у каждого есть свои плюсы и минусы.
С импульсной логикой управления контроллер и машина вполне могут жить каждый своей бурной и независимой жизнью.
Был свидетелем ситуации, когда при сбое питания контроллера машина продолжала работать, но была неуправляемой, т.к. контроллер после своей перезагрузки считал агрегат остановленным - он же его не запускал? Нет. Значит, стоим, защиты отключены. Красота!
А компрессор на полтора мегаватта молотит без никак защит...

Но это только один из частных примеров.

[keysansa]

Был свидетелем ситуации, когда при сбое питания контроллера машина продолжала работать, но была неуправляемой, т.к. контроллер после своей перезагрузки считал агрегат остановленным - он же его не запускал? Нет.

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

[Ryzhij]

При пропадании напряжения - должны сработать. Это не зависит от внутреннего состояния контроллера - просто ошибка программирования не имеет отношения к рассматриваемому вопросу.

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

[Михайло]

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

[petr2off]

Я как то с трудом воспринимаю любое управление без обратной связи. Мне кажется это противоречит методологии АСУ ТП.
Даже на кнопочных пультах управления, стараются рядом с кнопкой лампочку поставить.

[Ryzhij]

[youtube][/youtube]

Я как то с трудом воспринимаю любое управление без обратной связи. Мне кажется это противоречит методологии АСУ ТП.
Даже на кнопочных пультах управления, стараются рядом с кнопкой лампочку поставить.

В системах управления, представляющих собой автоматы с памятью, для перехода из одного состояния в другое используют признак наступления некоего события - обратную связь от объекта.
Но есть нюанс - подпрограммы перехода, и, соответственно, анализа определённого состояния объекта, работают лишь до момента перехода автомата в следующее состояние. Затем в работу включаются другие подпрограммы, относящиеся к иному состоянию автомата управления.
После сброса памяти автомата часто по состоянию объекта управления просто невозможно однозначно восстановить состояние автомата управления, но ещё чаще никто и не задумывается о такой необходимости.
"На-колбасить" можно на любом языке программирования, и SFC (Sequential Function Chart-последовательные функциональные схемы) не исключение.

[keysansa]

А что к чему имеет, или не имеет отношение, позвольте мне решать самому.

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

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

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

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

Отправлено спустя 10 минут 2 секунды:

Я как то с трудом воспринимаю любое управление без обратной связи.

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

ЗЫ.

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

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

[Ryzhij]

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

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

Отправлено спустя 1 минуту 52 секунды:

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

Не буду спорить, вам со студентами оттуда конечно виднее будет, где ошибка программирования, а где отсутствие вменяемой системной интеграции...

[keysansa]

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

Это самом собой, конечно необходимо.

Не буду спорить, вам со студентами оттуда конечно виднее будет

Я не говорю, что нам виднее, я помощь предложил.

[Jackson]

Ну а вообще, по моим представлениям хорошая практика использовать оба типа команд.

Поддерживаю Ваше мнение, коллега. Для разных систем - разные команды и фидбэки хороши.

В общем-о так и есть. Так и применяется - по разному по месту.

В чём новизна темы?