PDA

Просмотр полной версии : Отключение деактивированных аварий



alekstani
18.11.2022, 13:14
Добрый день!

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

Евгений Кислов
18.11.2022, 13:28
Добрый день.
Какая версия прошивки у вашего СПК?

alekstani
18.11.2022, 14:01
1.3.0928.214963937

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

63938

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

alekstani
21.11.2022, 09:00
6396563966639676396863969
Добрый день!
Смена прошивки и codesys не помогли.
В банере и таблице тревог после деактивации тревоги статус остался активным.

Евгений Кислов
21.11.2022, 09:06
6396563966639676396863969
Добрый день!
Смена прошивки и codesys не помогли.
В банере и таблице тревог после деактивации тревоги статус остался активным.

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

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

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

Евгений Кислов
21.11.2022, 11:29
В проекте авария возникает если текущий уровень воды 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 влияет только ее условие.

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

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

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

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

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

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

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


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
22.11.2022, 10:39
Тоже вариант. Спасибо

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

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

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