LocalList в TraceMode 6.08: особенность работы №1 | ПЛК и АСУТП

tm1-1Эпиграф: 
Если у вас в программе есть глюк, не спешите его исправлять. 
Просто опишите его в мануале как особенность работы.

Именно это выражение мне вспомнилось, когда я познакомился с каналом LocalList в TraceMode 6.08. Правда, некоторые «особенности работы» канала ни в печатном руководстве программиста, ни в справке ТМ6 ни описаны. Спасибо ребятам из техподдержки- подсказали, сам бы не додумался…

LocalList работает просто- разбивает участок СПАД архива в диапазоне DATA_AND_TIME_1(T_FROM) … DATA_AND_TIME_2(T_TO) на интервалы определенной длительности(1,5,20 мин. и т.д.) и вычисляет среднее значение в каждом из интервалов. Результаты отправляет либо в канал ChGroupReq либо(только среднее) либо в TVC(среднее, макс.,мин.).

Кстати говоря, вынужден я был воспользоваться обработкой СПАД архива не от праздного любопытства- необходимый мне функционал вполне обеспечивал старый добрый MS SQL, но нормально работать с ним из ТМ6 невозможно. Часть моего печального опыта в ТМ6+SQL описана здесь: TraceMode 6 и вывод данных из MS SQL в таблицу . Более детально о моих потугах с SQL я напишу позднее, если будет не лень.

Впрочем, теоретически у СПАДа есть свои преимущества. Одно из них- легкость обработки с помощью специальных каналов, например LocalList(далее- LL).

Написал я тестовую программку: создал канал FLOAT, включил его архивирование в СПАД, создал тренд с этим каналом для визуального контроля работы:

Включил программу, ввел какое-то значение в канал, и сижу жду- время идет, кривая на тренде ползет, вроде все ок. Программа работает 10, 20 минут. Реальное значение параметра не меняется- например, 60.
Пробуем с помощью LL рассчитать средние минутные значения за 5-мин. интервал.
Вводим T_FROM и T_TO, запускаем LL на обсчет(атр. 3, In=1) и…. ничего не происходит. В привязанный к LL ChGroupReq никаких данных не поступило, хотя должно было появиться пять аргументов, в каждом из которых- среднее минутное из 5-минутки.

LL и три  точки.
Смотрим на график: в указанное нами время параметр стоял как литой на отметке 60. След-но среднее в каждой минуте пятиминутки и должно было быть 60!

Долбался я с этим почти 2 недели- перечитал раз 50 справку, курил мануал, думал «не идиот ли я»? И только потом решил обратиться в техподдержку.

Оказалось следующее(мотайте на ус, информация эксклюзивная, в мануалах нет):
LL работает только в том случае, если в заданном диапазоне было хотя бы 3 записанных в СПАД значения. А значения пишутся в СПАД только по изменению реального значения канала! А не через какой-то промежуток времени, как привычно в SQL. В моем случае параметр не менялся с самого старта программы- потому в заданной пятиминутке не разу не было записи параметра в СПАД.
Получился парадокс: значения вроде как есть, на грифике виден, а LL говорит, что значения нет, потому и средних нет.

Опасность такой особенности очевидна, пример навскидку, пример 1:
Допустим, есть холодильная камера, температура в которой должна быть постоянной, например +3 гр. Мы пишем в СПАД эту температуру и хотим по запросу выводить в отчет средние минутные температуры за час- вдруг сбой был? Так вот, не сможем мы создать отчет если холодильник держал заданные +3 т.к. значение не менялось и в СПАД записей не было.

Пример 2, из моего опыта:
Некий параметр приходит в скаду не от датчика, а вводится вручную- человек раз в час посмотрел на антикварный манометр, лаборатория провела расчет содержания бактерий и т.д.
Берем среднее, среднее не рассчитывается.

Какой выход? Слава богу, он есть: используя Data_from_SIAD с заданной периодичностью(напр. 1 мин.) принудительно писать данные в архив. Тогда «проклятье трех точек» не сработает.

Читайте дальше: LL и достоверность, продолжение следует…

Добавить комментарий

Ваш e-mail не будет опубликован.

Подтвердите, что Вы не бот — выберите человечка с поднятой рукой:
Confirm that you are not a bot - select a man with raised hand:

Подпишитесь на нашу рассылку


Copyright © 2016. Перцух Алексей

Индекс цитирования