- В этой теме 33 ответа, 4 участника, последнее обновление 5 лет, 6 месяцев назад сделано
.
-
Сообщения
-
Посмотрел на его возможности и понял, что не хватает «Добавить событие» по аналогии «Добавить команду ТУ»
На триггере в «Добавить событие» как раз указывать № статуса из базы «Типы событий»
И тогда можно писать свой текст в типы событий и цвет.Кстати как подсвечивать не текст а само поле события, оставляя текст черным ?
Да, один из вариантов на основе модуля.
Если Вы сейчас сделаете дорасчётный канал, который будет реагировать на нужное условие, и поставите для него события по изменению, то получите то же самое. Статус канала тоже можно по формуле задавать. Только текст события таким образом не получится указать.Вопрос про подсветку я не уловил.
Сейчас подсвечивается сам текст, имелось ввиду делать инверсию. фон текста цветной а текст черный (либо белый ля темных цветов)
Имеете ввиду дорасчетный канал, который по формуле взведется в 1, если данные основного канала меньше некоего значения ? и отлавливать по изменению ?
Тут проблема в чем, я хочу выводить в событие только время перехода при значении меньше, мне не нужно еще одно событие, когда значение станет больше (вернется в норму) Это как пример.
Как это сделать ?
выводить в событие только время перехода при значении меньше, мне не нужно еще одно событие, когда значение станет больше
Да, сейчас так не получится, нужно реализовывать такую функциональность в модуле.
manjey73, если Вы писали драйверы для Rapid SCADA, то Вам не составит большого труда разработать небольшой модуль для генерации событий, чтобы не ждать появления штатного модуля.
Увы, я не силен в программировании настолько. Все, что относится к драйверам устройств не сложно, следуя четким описаниям протокола обмена со стороны производителя.
Все, что касается взаимодействия драйвера и уже непосредственно SCADA для меня во-первых сложно, во-вторых еще влияет отсутствие времени на изучение исходников примеров, так как там сплошные кросс-ссылки, пойди туда, сделай там что-то, вернись на шаг вправо, сделай еще что-то и так далее. Вот так для меня выглядит чужой код :).На данный момент вижу по Событиям достаточные неудобства.
1. ограничено количество событий в окне, нельзя посмотреть что было чуть раньше, только через экспорт
2. для данного окна много событий излишне, там надо иметь возможность выбирать, что в него отображать, далее в силу должен вступать журнал событий (новое окно, новый плагин, как угодно)
3. в Модуле Автоматического управления добавить возможность триггером создавать события так же с указанием, что выводить в события окна представления, остальное в полный журнал.Ну как-то так…
Тема внеочередной-опрос-кп-реализация в Понять как работает ПО
(з.ы. почините работу ссылок а то на стартовую отправляет)
ссылкаСобственно в Модуле автоматического управления неплохо бы добавить тригеры на диапазон каналов КП и функцию != значения, то есть если значение изменилось в любом из каналов, то выполнить внеочередной опрос КП.
Ну или есть другие способы чтобы в указанной теме объяснить как это реализовать ?
Настраивать на каждый канал это застрелиться…
К тому же в каналах могут присутствовать формулы.На мой взгляд, слишком специфичная функция. Если подобные функции непосредственно реализовывать в модуле автоуправления, он станет неудобным в настройке. С помощью формул в базе конфигурации можно изящно запрограммировать проверку изменения диапазона каналов.
Либо можно разработать отдельный модуль, который будет отслеживать изменения по заданным диапазонам и записывать флаг в нужный входной канал.
Так вот не хватает примера как изящно сделать проверку изменения канала ?
Не тогда, когда он прилетит обратно, а когда я его в прибор посылаю.
Я не догоняю, как это реализовать ?На данный момент не ясно, каким образом софт «узнает», что нужно выполнить опрос, если опрос выполняется раз в X часов. Сначала нужно прояснить этот момент, а затем уже вернуться к формулам.
Ну как не ясно ? я вызываю команду управления и жму например «Выполнить» это ли не факт того, что надо тут же орпосить изменяемый тег КП или весь КП, если тег читается группой вместе с другими параметрами ?
з.ы. В идеале, базу нужно разбивать на постоянно записываемую и переодически записываемую. Это как раз в тему текстовых параметров, которые нам не надо хранить каждую минуту, то же относится и к каналам даже Modbus, которые нам не надо сохранять постоянно, а достаточно иметь 10-20 записей перезаписываемых по времени, данные канала с новой меткой времени замещают старую метку времени.
Во многих приборах часто есть настроечные параметры, которыми нет смысла захламлять базу. Факт прочтения тега определяется запуском Коммуникатора и принадлежность к объекту и КП этого же прибора, где теги читаются постоянно.
Очень было бы полезно назначать принадлежность каналов к отдельной базе данных, в которой бы указывалось сколько записей на канал необходимо отвести чтобы потом посмотреть действия (время изменения параметров)…
Внеочередной опрос после команды управления можно настроить в Модуле автоуправления. Триггер на команду. Вообще, эту функцию желательно в Коммуникатор встроить, т.к. нужна постоянно. Когда будет следующий блок модификаций Коммуникатора, наверное, так и сделаем.
- Вы должны авторизироваться для ответа в этой теме.