4.7.8.105

Было такое. Скада размером 7-8 тысяч физических тэгов нормально работала с орс-сервером овен, стали добавлять устройства в modbus драйвер, и скада начала вылетать. Чем больше устройств, тем чаще вылетает. Watchdog не помогает, он вроде пытается запустить скаду, но у него не получается. Взяли за правило перезагружать скаду раз в сутки вручную и смотреть, получилось у неё заработать или нет, только так и спасались, но потом она стала вылетать уже несколько раз в сутки.

Опрос через GPRS, таймаут 5000-10000 мсек, минимальный интервал опроса 10 сек, но у основной массы тэгов раз в несколько минут.

Проблему решили покупкой инсатовского орс-сервера и постепенным на него переездом. Сейчас в modbus драйвере осталось примерно 10 устройств, может, там какие-то нехорошие процессы изредка и происходят, но привычка ежесуточной ручной перезагрузки скады осталась, поэтому что-то конкретное сказать не могу.

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

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

Виноват, конечно же аналоговые. Уставки пропали.

Вот ещё незадача: когда интервал опроса минута вместо секунды, отображение дискретных тэгов куда-то пропадает.

Во-первых, трафик. У нас опрос всех устройств идёт через GPRS, это и лишние деньги, и забивание канала. На практике, запрос, который по проводу при скорости 9600 занимает 100 мс, чрез GPRS растягивается на 2 секунды. С учётом того, что на объекте, чаще всего, находится несколько устройств, и у каждого свои тараканы (например, представители славного семейства emerson позволяют опрашивать не более 5 регистров за раз), каждая секунда имеет значение.

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

Пожалуйста, подумайте. Ситуация сложная, из-за этого рассматривался даже вопрос о миграции на другую скаду, но пока мы придумали такое решение: на белом фоне большие чёрные панели, а в них большие светлые цифры - так нерезкость скрадывается. Кстати, тренды всегда чёткие, в отличие от остальных элементов.

Эта ситуация наблюдалась всегда (по крайней мере, последние несколько лет), без привязки к версии и прочему. Если в выбранном диапазоне не было изменений и была связь без разрывов, индикация исчезает. Если диапазон больше суток - график остаётся на месте.

dmir@tdanix.ru В общем, ситуация понятная, будем решать задачу имеющимися средствами. Спасибо.

Письмо было 28 октября.

Через GetChannelInfo сильно муторно, к тому же, там не учитывается задержка аварии. Как вариант сделать, например, выше уставки - 2, а квитировано и выше уставки - 12 (дописывать единичку), ниже уставки - 0 и 10 соответственно.

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

Ну, если нет, сваяю скрипт с триггерами в скаде или вообще перетащу обработку в орс-сервер, посмотрю, как удобнее. Возни только много, 2 000 переменных.

Я для контроля связи создаю по одному виртуальному тэгу на каждую железку. В нём считываю качество какого-нибудь физического тэга, если значение не равно 192, значит, проблемы со связью - тэг меняет своё значение с ноля на единичку. А этот тэг можно и в modbus slave отправить.