Зарегистрирован: Oct 20, 2005 Сообщения: 20 Рейтинг: +0/-0
Добавлено: Пт 31 Мар, 2006 11:23:08 Заголовок сообщения: Алармы в RSView32
В процессе создания экранов аварийных сообщений столкнулся со следующими проблемами:
1я. Для вывода информации по алармам выбрал стандартную табличку Allarm Summary. Там возможно задавать набор кнопок для работы с сообщениями, в частности есть кнопки подверждения сообщений Ack Current, Ack All. Поскольку в проэкте предполагается что экраны операторов будут рускоязычными, то хотелось бы заменить вышеуказанные надписи на кнопках на "Подтвердить текущую" и "Подтвердить все". Но тут обнаружилось что кнопки не растягиваются под ширину надписи автоматически, и как их растянуть вручную тоже не понятно.
Какие есть варианты решения такой проблемы?
2я. В проекте планируется создать нечто вроде иерархии алармов. Т.е. допустим общий дискретный тег аварии в подсистеме А формируется при наличии хотя бы одного из аварийных сигналов для подсистемы А, общий дискретный тег аварии в подсистеме Б формируется при наличии хотя бы одного из аварийных сигналов для подсистемы Б и.т.д.... При этом общие тэги аварий подсистем выводятся в сводную таблицу аварийных сообщений. Нажатие кнопки Identify для текущей строки сообщения об аварии в подсистеме Х вызывает экран с перечнем конкретных аварийных синалов по подсистеме.
Проблема следующая: если все конкретные аварийные сообщения по подсистеме подтверждены, то и общее сообщение на основном экране аварий является подтверждённым. При возникновении нового аварийного сигнала в подсистеме, никакого изменения сообщения о аварии в подсистеме в целом не происходит, так как общий дискретный тэг неисправности состояния не меняет. Как можно сделать сообщение об аварии неподтверждённым опять или сгенерировать новое сообщение при неизменном состоянии тэга?
Уже выяснено шо установка в 1цу Ack Bit для алармного тэга делает этот аларм подтверждённым, а вот сброс Ack Bit в 0 ничего не меняет, увы. Сгенерировать аларм по событию можно при помощи команды AlarmEvent, но AlarmEvent работает только для неалармных тэгов и соответственно для такого сообщения функция вызова пользовательской команды по Identify не работает.
Как можно выкрутится из подобной ситуации?
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Пт 31 Мар, 2006 12:22:24 Заголовок сообщения:
Цитата:
обнаружилось что кнопки не растягиваются под ширину надписи автоматически, и как их растянуть вручную тоже не понятно.
Какие есть варианты решения такой проблемы?
Взять стандартный Button, назначить ему соответствующий Action и написать на нём то, что надо. А кнопки из темплэйта Alarm отключить.
Цитата:
В проекте планируется создать нечто вроде иерархии алармов. ...
Как можно выкрутится из подобной ситуации?
Написать на VBA свой собственный обработчик алармов?
Написать соответствующую логику управления общим аларменным тэгом в контролере? _________________ Обращайтесь к профессионалам.
Зарегистрирован: Oct 20, 2005 Сообщения: 20 Рейтинг: +0/-0
Добавлено: Пт 31 Мар, 2006 13:16:30 Заголовок сообщения:
oldDad писал(а):
Цитата:
обнаружилось что кнопки не растягиваются под ширину надписи автоматически, и как их растянуть вручную тоже не понятно.
Какие есть варианты решения такой проблемы?
Взять стандартный Button, назначить ему соответствующий Action и написать на нём то, что надо. А кнопки из темплэйта Alarm отключить.
А каким Actionом можна подтвердить текущую неисправность - ту что на конкретном экране в данный момент является выделенной курсором?)))
oldDad писал(а):
Цитата:
В проекте планируется создать нечто вроде иерархии алармов. ...
Как можно выкрутится из подобной ситуации?
Написать на VBA свой собственный обработчик алармов?
Написать соответствующую логику управления общим аларменным тэгом в контролере?
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Пт 31 Мар, 2006 13:40:25 Заголовок сообщения:
Цитата:
А каким Actionом можна подтвердить текущую неисправность - ту что на конкретном экране в данный момент является выделенной курсором?)))
Командой Acknowledge (тогда будет подтверждён самый "важный" приоритетный тэг) или Acknowledge [tag] - для какого-то конкретного тэга.
Цитата:
Цитата:
Написать на VBA свой собственный обработчик алармов?
Написать соответствующую логику управления общим аларменным тэгом в контролере?
Поясните пожалуйста подробнее
Мне приходят в голову две вещи (так, в акачестве идеи):
1. Написать на VBA свой собственный обработчик системы алармов, т.е. проверять тэги из процедуры VBA, генерировать в своём собственном окне нужные сообщения и нужные кнопки и т.п.
В объектной модели VBA для этого всё имеется.
2. Реализовать нужную логику обслуживания обобщённого тэга не в RSView, а в контроллере - вылавливать появление нового аларма после квитирования и взводить общий аларменный тэг, сброшенный при квитировании, снова. А RSView оставить те функции, которыми ей положено заниматься, т.е. отображать полученную из контроллера информацию. _________________ Обращайтесь к профессионалам.
Зарегистрирован: Oct 20, 2005 Сообщения: 20 Рейтинг: +0/-0
Добавлено: Пт 31 Мар, 2006 14:38:58 Заголовок сообщения:
самый "важный" приоритетный тэг - это всё таки не текущий тэг в аларменном окошке...
Насчёт собственного обработчика алармов в VBA есть существенный минус - невозможность асинхронного вызова процедур VBA... допустим в ситуации когда отрабатывается одна длинная процедура (например связанная с вызовом внешнего приложения и передачей туда данных) и приодит запрос на выполнение какой то другой процедуры - VBA затыкается. Ежели приходят и приходят ещё новые запросы - не только VBA, но и сам RSView впадают в кататонический ступор.
Реализовать нужную логику обслуживания обобщённого тэга не в RSView, а в контроллере - решение в моём понимании несколько странноватое по изначальному замыслу: обычно в контроллерах закладываются задачи сбора сигналов и их цыклической обработки с выдачей управляющих воздействий на механизмы и.т.д., в т.ч. и формирование сигналов аварии,но формирование же логики системы алармов к традиционным задачам для контроллеров не относится... Или может у меня устаревшие представления?
Как правило при проектировании крупных систем автоматизации написание программы контроллеров и проэктов RSView занимаются разные люди, а часто и разные организации,представителям которых вряд ли понравиться идея, что работники смежной фирмы будут ставить программные эксперименты по созданию логики алармов в их контроллерах )))))
Зарегистрирован: May 05, 2005 Сообщения: 2773 Рейтинг: +89/-5
Добавлено: Пт 31 Мар, 2006 15:05:42 Заголовок сообщения:
Дело в том, что Вас в силу Ваших специфических концептуальных особенностей не устраивает готовый механизм. Значит, его нужно писать самостоятельно, реализуя ту логику работы, которую Вам заказал заказчик системы.
Цитата:
Насчёт собственного обработчика алармов в VBA есть существенный минус - невозможность асинхронного вызова процедур VBA... допустим в ситуации когда отрабатывается одна длинная процедура (например связанная с вызовом внешнего приложения и передачей туда данных) и приодит запрос на выполнение какой то другой процедуры - VBA затыкается. Ежели приходят и приходят ещё новые запросы - не только VBA, но и сам RSView впадают в кататонический ступор.
А почему бы Вам не построить процедуру VBA таким образом, чтобы она не была такой уж длинной? Ведь Вы можете написать не одну, а 2, 3 и т.п. процедуры, из которых первая была бы "диспетчером"? Всё в Ваших руках
Или сделайте диспетчер на Event Detector'е, а по разным Eventam звпускайте разные (более которткие) процедуры
Понимаете, то, что вы пишете, предполагает многозадачность, а это можно реализовать либо используя врождённые механизмы мультизадачности RSView (см.выше), либо там, где естественно и натурально реализовывать логику - в логческом контроллере.
Цитата:
Реализовать нужную логику обслуживания обобщённого тэга не в RSView, а в контроллере - решение в моём понимании несколько странноватое по изначальному замыслу: обычно в контроллерах закладываются задачи сбора сигналов и их цыклической обработки с выдачей управляющих воздействий на механизмы и.т.д., в т.ч. и формирование сигналов аварии,но формирование же логики системы алармов к традиционным задачам для контроллеров не относится... Или может у меня устаревшие представления?
Я, как раз, ровно ничего странного в таком решении не вижу Логику следует реализоваывать там, где ей надлежит быть реализованной и где для реализаии логики есть все необходимые средства и механизмы - в логическом контроллере, например. В нём для этого есть всякие битовые и не только инструкции, и именно он как нельзя лучше подходит для решения логических задач, не правда ли?
Или Вам кто-то или что-то мешает или запрещает писать эту логику удобно и просто в том месте, где ей самое место (простите за тавтологию)?
Цитата:
Как правило при проектировании крупных систем автоматизации написание программы контроллеров и проэктов RSView занимаются разные люди, а часто и разные организации,представителям которых вряд ли понравиться идея, что работники смежной фирмы будут ставить программные эксперименты по созданию логики алармов в их контроллерах Smile)))))
Ну, так это у Вас специфические организационные сложности, уверяю Вас. Это как раз не правило, уж поверьте
Правилом и наиболее распространённой практикой является, по моему опыту, ситуация, когда систему в целом разрабатывает одна и та же команда, под одним и тем же проектным менеджментом и в рамках единой системной концепции. При этом система получается стройной и красивой, эффективной, и без излишеств и попыток достать левой рукой правое ухо в силу межведомственных распрей и организационного хаоса
Мы, во всяком случае, работаем именно так _________________ Обращайтесь к профессионалам.
Зарегистрирован: Oct 20, 2005 Сообщения: 20 Рейтинг: +0/-0
Добавлено: Пт 31 Мар, 2006 15:27:59 Заголовок сообщения:
Насчёт длинной процедуры я понмал процедуру длинную не в смысле количества операторов, а в смысле времени выполнения... как в случае создания объекта Excel. И вот ту даже элементарный евент-детектор, если он сделан в VBA стопорится
Для вывода информации по алармам выбрал стандартную табличку Allarm Summary. Там возможно задавать набор кнопок для работы с сообщениями, в частности есть кнопки подверждения сообщений Ack Current, Ack All. Поскольку в проэкте предполагается что экраны операторов будут рускоязычными, то хотелось бы заменить вышеуказанные надписи на кнопках на "Подтвердить текущую" и "Подтвердить все". Но тут обнаружилось что кнопки не растягиваются под ширину надписи автоматически, и как их растянуть вручную тоже не понятно.
Какие есть варианты решения такой проблемы?
Текущий, страница, все не подходит? В руководстве оператора потом распишете что означатет. И вообще слово Подтвердить ИМХО избыточно. Если оно Вам так надо напишите его над кнопками
Цитата:
В проекте планируется создать нечто вроде иерархии алармов. Т.е. допустим общий дискретный тег аварии в подсистеме А формируется при наличии хотя бы одного из аварийных сигналов для подсистемы А, общий дискретный тег аварии в подсистеме Б формируется при наличии хотя бы одного из аварийных сигналов для подсистемы Б и.т.д....
У нас для индикации аларма в системе используется похожая система. Заводится аналоговый Derived тег в обработчике значения которого прописано
if ( ALM_IN_ALARM({*-A*}) == 0 ) then 0 else
if ( ALM_ALLACKED({*-A*}) == 0 ) then 1 else 2
По значению данного тега, анимируется кнопка, нажатие на которую перемещает на мнемосхему системы в которой произошел аларм. Может стоит пойти по аналогичному пути? Можете по нажатию Alarm Summary требуемую выдавать.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Smart Solutions VDT GmbH | Friedrich-List-Allee 38, D-41844 Wegberg-Wildenrath, Germany Tel.: +49 2432 933 57 83 | e-Mail: office@vdt-solutions.de Все товарные знаки и торговые марки являются собственностью их владельцев.
При использовании материалов сайта ссылка на данный сайт обязательна. Открытие страницы: 0.130 секунды
FAQ
Поиск
Группы
Профиль
Войти и проверить личные сообщения
Вход
)))))