Обслуживание HiHi, Hi, Lo, LoLo аварий

[mak]

Доброе время!

Имее IAS3.0 SP2. В шаблоне создал Field Attributes:"Value", к нему включил галочку "Enable limit alarms". Теперь хочу сделать так, чтобы можно было в runtime отключать обслуживание HiHi, Hi, Lo, LoLo аварий. Только вот поле, которое отвечает за сие ето не могу найтиз!
При наведение указателя мыши на CheckBox'ы в Archestra IDE появляется всплывающая подсказака: "Value.HiHi.Alarmed", казалось бы вот оно,то что искал, а нет! А в Object Viewer'е ваще такое поле не показывает. Что это? Недоработка? В общем ладно, уже привыкли к этому)))
Ваще работая с IAS3.0 SP2 было замеченно много глюков... А как обстоит с версией IAS3.1 SP2? Мы учились на IAS3.1 SP2, но практики на ней почти не было...

[Klinkmann_Msk]

To mak:

В режиме Runtime для изменений доступны только поля Limit и Priority. "Играйте" ими. Можно, конечно, использовать для доступа к полям GRAccess, но муторно это...

[mak]

To mak:

В режиме Runtime для изменений доступны только поля Limit и Priority. "Играйте" ими. Можно, конечно, использовать для доступа к полям GRAccess, но муторно это...

ГЫ) но хочется и надо, чтобы было как в "добром" InTouch'е! Довольно странно, что в IAS не реализованно. Ломает весь принцип оргранизации аварии. Обычно нам очень надо,чтобы возможно было отключать обслуживанеи предупердительных и аварийных состояний аварий!
Ну хоть в IAS3.1 не тоже самое?)

Поиграть полями "Limit" and "Priority"

Будет маловато...

Ладно, допустим я переведу объект в Off_scan, я смогу убрать галочку обслуживание аварий HiHi и т.д.?(я не говорю об общей аварии,там все ок) Или ваще такого поля нет?

И что за поля "GRAccess"?? М.Б., что речь идет о внутренних ролях безопасности GR?? Точно не понимаю, не работал с етим.

[Klinkmann_Msk]

To mak:

В версии 3.1 появилось поле Inhibit, отключающее проверку Alarm-а.

"переведу объект в Off_scan"
Зачем? Можно поправить объект в IDE и передеплоить.

GRAccess - абор инструментов для доступа к GR. Является частью WW Toolkit.

[mak]

To mak:

В версии 3.1 появилось поле Inhibit, отключающее проверку Alarm-а.

очень радует!

"переведу объект в Off_scan"
Зачем? Можно поправить объект в IDE и передеплоить.

Чуть не правильно выразился. Имел виду,что оператор сам в рантайме переведет объект в оффлайн, отключит, то что надо, а потом после настройки запустит объект в работу.

[Klinkmann_Msk]

To mak:

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

[Джа]

To mak:

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

Ну как бы на грамотный подход это не смахивает - задирать предел или менять приоритет. Это похоже на то, как студент-первокурсник пишет программу - на место вылета ошибки по коду шлепается локальная "заплатка", а не устраняется сама причина. Как раз самое беспорядочное действие это и есть - системным подходом, ОО-подходом если хотите - тут и не пахнет, дилетанство это, пусть и вынужденное из за бага в среде разработки. Да и насколько я помню лимит Hi нельзя например "задрать" выше HiHi - система не даст, HiHi не поднять выше верха шкалы, и тд. Засорять базу левыми алармами с левыми приоритетами - тоже не здорово.
Сам столкнулся с такой проблемой, в IAS 3.0 - грамотного решения не нашел. Свойство HiHi.Enable (для примера, или дизэйбл там -запамятовал щас) в постановке его в false - просто исчезает из свойств объекта. Выключить можно, включить потом уже нельзя. Я делал второй слой битовых полей под включение\выключение лимитов, ну и алармы тоже весил на свои поля соответственно, не используя встроенные. Явный глюк WW, фичу из него делать не нужно.

[Джа]

To mak:

В версии 3.1 появилось поле Inhibit, отключающее проверку Alarm-а.

очень радует!

"переведу объект в Off_scan"
Зачем? Можно поправить объект в IDE и передеплоить.

Вы предлагаете например инженеру-технологу передеплаивать объекты в проекте? Дать ему такие права? Смело, очень смело. Учитывая что передеплой в SP - вообще больное место и рикованная операция - вообще экстрим просто предлагаете. Я сам часть не рискую что-либо передеплаивать на работающем объекте - а ну как подвиснет посерединке например? А ввод и вкл/выкл уставок - по крайней мере на нашем предприятии делают именно инженеры-технологи, а зачастую и просто операторы, никак не программисты - не напасешься их под такую ерунду на каждый объект.
С переводом в оффскан в рантайме я бы тоже не стал играться вообщем.

[Klinkmann_Msk]

To Джа:

В версии 3.1 проблема решена. Появилось поле Inhibit для алармов.

[mak]

Вот я и говорю, что вместо всего этого набора беспорядочных действий достаточно изменить лимит Или поменять приоритет аларма, и тогда он перестанет показываться на экране
Ну как бы на грамотный подход это не смахивает - задирать предел или менять приоритет...
...Да и насколько я помню лимит Hi нельзя например "задрать" выше HiHi - система не даст, HiHi не поднять выше верха шкалы, и тд. Засорять базу левыми алармами с левыми приоритетами - тоже не здорово.

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

Явный глюк WW, фичу из него делать не нужно.

Скорее всего не глюк WW, а попросту упущение разработчиков IDE. Забыли...

Вы предлагаете например инженеру-технологу передеплаивать объекты в проекте? Дать ему такие права? Смело, очень смело. Учитывая что передеплой в SP - вообще больное место и рикованная операция - вообще экстрим просто предлагаете. Я сам часть не рискую что-либо передеплаивать на работающем объекте - а ну как подвиснет посерединке например? А ввод и вкл/выкл уставок - по крайней мере на нашем предприятии делают именно инженеры-технологи, а зачастую и просто операторы, никак не программисты - не напасешься их под такую ерунду на каждый объект.
С переводом в оффскан в рантайме я бы тоже не стал играться вообщем.

Полностью согласен. Я, например, нахожусь от объектов довольно далеко. И давать возможность переключать объекты из on scan в off scan очень рискованное дело. Тем более, если тех. процесс непрерывный. Персонала, который был бы там рядом и мог бы подстраховать сие действие попросту нет. Делать себе же подлячку, которая скорее всего када-нить сработает не имеет ясного разума.

В версии 3.1 проблема решена. Появилось поле Inhibit для алармов.

Скоро предстоит делать проект в 3.1. Очень надеюсь,что там меня не поджидает очередной сюрприз

[Klinkmann_Msk]

To mak:

"Скоро предстоит делать проект в 3.1. Очень надеюсь,что там меня не поджидает очередной сюрприз"
Я бы не был ТАКИМ оптимистичным

[mak]

To mak:

"Скоро предстоит делать проект в 3.1. Очень надеюсь,что там меня не поджидает очередной сюрприз"
Я бы не был ТАКИМ оптимистичным

Ну весь сюрприз испортили