Отключение деактивированных аварий

Добрый день!

Помогите, пожалуйста, решить вопрос. Используем СПК-110.
При возникновении условий аварии происходит изменение ее статуса, который считывается в коде программы методом GetState().
Причем, если авария изначально деактивирована переменной из колонки "Деактивация" группы аварий, то возникшие условия для аварии статус аварии
не могут изменить, т.е. она выключена из работы программы (не используется).
Если же переменная из колонки "Деактивация" включена (по факту деактивация выключена, т.к. используется инверсия переменной), т.е. авария используется и авария возникла, то затем сбросив эту переменную авария остается. Какой метод можно использовать для сброса аварии в случае сброса переменной из колонки "Деактивация" (по факту включили деактивацию)?

Добрый день.
Какая версия прошивки у вашего СПК?

1.3.0928.2149Вложение 63937

Соответственно, вы используете CODESYS V3.5 SP16 Patch 3.
Вы столкнулись с багом, который исправили в V3.5 SP17:

Вложение 63938

У нас уже есть прошивка с поддержкой V3.5 SP17 Patch 3.
Если решитесь до нее обновляться - очень внимательно изучите первый пост в этой теме:
https://owen.ru/forum/showthread.php?t=36852

Вложение 63965Вложение 63966Вложение 63967Вложение 63968Вложение 63969
Добрый день!
Смена прошивки и codesys не помогли.
В банере и таблице тревог после деактивации тревоги статус остался активным.

Цитата:

---

Сообщение от alekstani

Вложение 63965Вложение 63966Вложение 63967Вложение 63968Вложение 63969
Добрый день!
Смена прошивки и codesys не помогли.
В банере и таблице тревог после деактивации тревоги статус остался активным.

---

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

В проекте авария возникает если текущий уровень воды GVL.ACT_Water_Level_ опустится ниже уставки PV.SET_W_Lvl_AlarmLow и если авария включена PV.ErrorsArray[19].enabled
Если таким образом активировать аварию, то после сброса PV.ErrorsArray[19].enabled авария в таблице и банере аварий все равно будет в активном положении.

alekstani Меня это достало (у меня SP14), и я сделал отдельную переменную для значения, по которому работает тревога с её флагом деактивации.
То есть, если тревога отключена - то значение выставляется якобы нормой, чтобы тревога не срабатывала. А если тревога включена - то значение передаётся как есть.

Цитата:

---

Сообщение от alekstani

В проекте авария возникает если текущий уровень воды GVL.ACT_Water_Level_ опустится ниже уставки PV.SET_W_Lvl_AlarmLow и если авария включена PV.ErrorsArray[19].enabled
Если таким образом активировать аварию, то после сброса PV.ErrorsArray[19].enabled авария в таблице и банере аварий все равно будет в активном положении.

---

Это ожидаемое поведение.
Я выше выкладывал скрин из баг-трекера - начиная с V3.5 SP17 тревогу нельзя деактивировать, если она активна.
Т.е. пока тревога активна - даже если PV.ErrorsArray[19].enabled = FALSE - тревога исчезнет, если ее условие прекратит выполняться (а в старых версиях - она бы так и висела до перезагрузки контроллера).
Т.е. на отображение тревоги с типом REP влияет только ее условие.

А нельзя как-то это обойти? Я имею ввиду скидывать принудительно тревогу в случае ее деактивации, например используя какой-нибудь метод. Очень неудобно в период отладки когда в баннере и таблице тревог постоянно висит аварийное сообщение и его никак нельзя отключить. Можно конечно вставить костыль ввиде подсовывания нормальных условий для аварийного сигнала в момент деактивации аварии (как писал Cs-Cs). Но такой вариант мало привлекателен, т.к. для каждой аварии нужно будет использовать "нормальные условия". Кстати у нас тревога не обязательно висела до перезагрузки ПЛК, достаточно было снова активировать тревогу (переменной деактивации - в нашем случае PV.ErrorsArray[19].enabled) и если условий для аварии уже не было, то она уходила.
Сейчас сделали так, что авария уходит если условия для ее возникновения исчезли и она даже в это же время находится в деактивированном состоянии.

Цитата:

---

Сообщение от alekstani

А нельзя как-то это обойти? Я имею ввиду скидывать принудительно тревогу в случае ее деактивации, например используя какой-нибудь метод. Очень неудобно когда в баннере и таблице тревог постоянно висит аварийное сообщение и его никак нельзя отключить. Можно конечно вставить костыль ввиде подсовывания нормальных условий для аварийного сигнала в момент деактивации аварии. Но такой вариант мало привлекателен. Кстати у нас тревога не обязательно висела до перезагрузки ПЛК, достаточно было снова активировать тревогу (переменной деактивации - в нашем случае PV.ErrorsArray[19].enabled).

---

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

alekstani

Цитата:

---

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

---

Вот меня это и бесит! Потому что в домашнем СПК у меня тревоги по датчикам давления воды в квартире должны отрубаться, когда вода по вводу перекрыта.
А фиг: если, например отключили горячую воду в доме и её давление упало и если я воду перекрыл (и ПЛК про это знает) - то тревога так и будет висеть (

В процессе наладки оборудования и отладки ПО часто требуется включать/отключать ряд аварий. Чтобы их сообщения не висели в банере и таблице аварийных сообщений их нужно оперативно убрать, не останавливая оборудование, которое находится также под управлением ПЛК.
Другая ситуация: станция СОЖ обслуживает 10 станков, один может быть выведен из работы (например в ремонт) и СОЖ подаваться в него уже не будет, но датчики уровня при этом находятся под контролем ПЛК. Таким образом, если наладчик забудет деактивировать аварии датчиков в их нормальном состоянии, начнет например их снимать, то мы получим аварийные сообщения, которые снять уже не сможем. Станцию при этом отключать нельзя и ресетить ПЛК тоже, т.к. оставшиеся станки в работе. Если бы такая же авария произошла в процессе работы этого станка, то это была бы нормальная ситуация, этот станок был бы исключен из процесса подачи СОЖ, станция бы просто перешла на другой станок и аварийное сообщение было бы к месту, сигнализируя о неисправности датчика.

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

Т.е. вместо условия

Код:

---

GVL.ACT_Water_Level_ < PV.SET_W_Lvl_AlarmLow

---

использовать

Код:

---

GVL.ACT_Water_Level_ < PV.SET_W_Lvl_AlarmLow AND PV.ErrorsArray[19].enabled

---

а в столбце Деактивация привязку убрать.

Тогда (с учетом способа подтверждения REP) если PV.ErrorsArray[19].enabled = FALSE, то ваша тревога исчезнет из таблицы/баннера, и не сможет появиться, пока PV.ErrorsArray[19].enabled не примет значение TRUE.

Тоже вариант. Спасибо

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

Цитата:

---

Сообщение от alekstani

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

---

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