Триггеры событий

[Valerich]

Приветствую!
Столкнулся с непонятным поведением триггеров событий.
Есть 4 типа условий: ON, OFF, ON->OFF, OFF->ON

Аннотация 2020-07-30 112449.png

С первыми понятно: условие возникло - триггер включился, условие ушло - триггер выключился.
А с ON->OFF, OFF->ON логично, что они работают как детекторы переднего и заднего фронтов: прошел нужный фронт - триггер сработал, прошел обратный фронт - триггер не реагирует.

Но почему-то работа триггеров ON и OFF->ON одинаковы, как и противоположные!
Объясните, пожалуйста, чего я не понимаю в чем различия ON и OFF->ON, если работают они одинаково? Или это баг?

В приложении тестовый проект, можно пощелкать.

Аннотация 2020-07-30 112827.png

А потребность возникла по причине того, что в режиме реального времени события отображается очень удобно: в одной строке отображается время начала и окончания события, но в этом режиме при перезагрузке панели информация пропадают; в режиме журнала информация сохраняется, но почему-то нет возможности отобразить время окончания события в этой-же строке.
В итоге сообщения с началом и концом события генерируются в разных строках и при наличии других событий могут быть сильно разнесены и непросто их найти. Я же планировал организовать начало и конец события в отдельных сообщениях, типа "Бит 1 включился/Бит 1 выключился" но из-за непонятной работы триггеров фронтов это не получается.

[VanMo]

Добрый день.
Разница в том, что в одном случае отслеживается состояние бита, а в другом именно фронт.
Разницу можно заметить при включении панели(симулятора), когда первоначально нет смены состояния.
Но при работающей панели разницы не будет, поведение будет одинаковое.
Триггер окончания события работает одинаково в обоих случаях.
Что касается отображения журнала из файла(режим Журнал), возникновение события и окончание события можно различить только по цветам. Дело в том, что в файл события пишутся именно так как их выводит Дисплей событий - возникновение и завершение в разных строках.
Теоретически, с помощью WATCH можно сформировать сообщение события типа "Бит 1 включился/выключился", но для этого нужно придумать механизм формирования строк "включился", "выключился" во внутренних регистрах на которые будет ссылаться WATCH.

[Valerich]

Обнаружил, что пункт меню сортировки "Вернуться к нормальному" изменяет формирование событий!

Аннотация 2020-07-31 131431.png

Если пункт отмечен, то событие формируется 2 раза: по переднему и заднему фронту, если пункт не отмечен, то событие формируется только по фронту!
И действия триггеров ON и OFF->ON все равно одинаковы и непонятно их назначение, ведь в реале эта функция переключается пунктом "Вернуться к нормальному".

Вот такая китайская логика

Отправлено спустя 27 минут 46 секунд:

Теоретически, с помощью WATCH можно сформировать сообщение события типа "Бит 1 включился/выключился"

Не получается. WATCH загружается при возникновении сообщения и при заднем фронте отображается то-же сообщение, что и при переднем, даже если WATCH за время сообщения изменился.

[VanMo]

Если пункт отмечен, то событие формируется 2 раза: по переднему и заднему фронту, если пункт не отмечен, то событие формируется только по фронту!

Не событие формируется 2 раза, а выводится, или не выводится завершение события. Завершение события всегда пишется в файл отдельной строкой и формируется по обратному фронту.

И действия триггеров ON и OFF->ON все равно одинаковы и непонятно их назначение, ведь в реале эта функция переключается пунктом "Вернуться к нормальному".

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

Не получается. WATCH загружается при возникновении сообщения и при заднем фронте отображается то-же сообщение, что и при переднем, даже если WATCH за время сообщения изменился.

Поэтому, нужно либо заранее сформировать правильную надпись макросом, либо макросом ловить событие, формировать сообщение, а потом формировать событие в Журнале событий. Может и можно без макроса обойтись, но я пока не представляю как.

[Jackson]

И действия триггеров ON и OFF->ON все равно одинаковы и непонятно их назначение

Я предполагаю, что сначала к OFF добавился ON->OFF на случай того, что панель на какое-то время потеряет питание - чтобы гарантированно ловить или не ловить эти события после перезагрузки. Потом, заодно, добавили и OFF->ON, но по факту разницы нет от ON.

Это всё будет иметь значение, если сами события (биты) обрабатываются макросами и задана задержка на исполнение этого макроса после рестарта, а в других случаях разницу не увидеть.

Могу ошибаться, но кажется так.

Отправлено спустя 3 минуты 57 секунд:
Например на моих установках. Агрегат работает может обозначаться одним битом: 1 = работает, 0 = остановлен. И можно завести два события: агрегат запустился и агрегат остановился. Если при стоящем агрегате перезапустить панель, то в журнале получим событие "агрегат остановился", хотя он и так стоял и не запускался. И с помощью этих игр можно избежать этих ложных сообщений.

Это просто пример что на ум пришёл.

[AlexandrS]

И действия триггеров ON и OFF->ON все равно одинаковы и непонятно их назначение, ведь в реале эта функция переключается пунктом "Вернуться к нормальному".

Не одинаковы. Допустим мы имеем какой либо бит передающийся из контроллера который в момент загрузки панели уже равен 1 , если триггер ON , то событие сработает , а если OFF-> ON , то не сработает.