А пока настройка "минимального" значения в отчете не введена (а это именно то, что нужно в данном случае), опишу несколько "программных" методов (кстати, довольно непривычно видеть отсылки к форттелекомовским отчетам тут - их система действительно отличается от виалон и в целом немного не на те цели направлена, а на более узкоспециальные).
Тем не менее это все лирика - итак исходные, имеем что-то вроде ППО25 (или 40) - счетчик фиксирует количество оборотов эллипсов (или зубцов) на единицу времени. При прохождении жидкости происходит вращение. Сам счетчик не определяет, в какую именно сторону вращается - просто говорит - два, десять, сто пятьдесят и т.п. Отсюда при движении колебание топлива, вибрация и прочее приводят к сообщениям вида 1-5 импульсов, которые фиксируются виалоном, которые попадают в отчет в виде 0 в строке (при экспорте ничтожно малые значения будут видны в таблице Excel).
Для работы с УСС в Виалоне чаще всего используется таблица “датчики счетчики” - ее логика подразумевает вывод интервала, когда счетчик работает, целиком. Сообщение с 0 (для мгновенного) или совпадающее по значению с предыдущим (для абсолютного) обрывает интервал. Таким образом в отчете появляются строки, которые вы желаете не показывать.
Данные от прибора могут поступать в виде либо мгновенного либо абсолютного показателя – они требуют немного разного подхода к реализации. И в том и в том случае необходимо добиться того, чтобы сообщения с малыми колебаниями не фиксировались системой – проще всего сделать их невалидными.
С момента старта этой темы появилось несколько функций, которые смогут помочь проделать вашу “костыльную” работу быстрей.
К примеру для счетчика можно применить нижнюю границу, которая будет рассчитана как по “сырым” данным, так и по пересчитанным. Чем это поможет? К примеру вы знаете, что 200 импульсов приходится на литр, а при движении и дребезге получается 1-5 – поставьте нижнюю границу в 10 и все сообщения ниже этого количества импульсов станут невалидными. Валидация – заменять валидатором в случае ошибки. Валидатор имеет параметр const0. Можно активировать “применять после расчета” - тогда нижняя граница будет отсекать не по X, а по Y (говоря терминами таблицы из “мастера”).
В итоге – любая работа счетчика ниже реальной выдачи становится нолем, в отчете выводиться не будет.
Приводился пример работы с датчиком переполнения, когда для его значений используется не 2 байта, а произвольное число – но вам-то оно известно? Это как минимум поможет воспользоваться этим датчиком в отчетах и вывести данные, как необходимо именно вам. Для этого первый ушаг – превратить дифференциальный в мгновенный. param1-#param1 даст значение импульсов между сообщениями. При переполнении будет очень большой минус, который разумно отсечь таблицей. Чтобы все-таки учесть эти импульсы в отчете – датчик будет примерно такой 999999-#param1+param1 ( 999999 поменяйте на свою точку переполнения), ну и по классике - “заменять валидатором в случае ошибки”. Обратите, пожалуйста, внимание, что иногда приходят значения вида - 999999, 999989, 999991 (т.е. небольшое падение значения). Такие моменты стоит предусмотреть в валидаторе – т.е. указать в нем верхнуюю границу.
Ну а получив из дифференциального мгновенный уже можно воспользоваться первой частью описания.
Это все к тому, что на данный момент это сделать возможно, но для этого требуется действительно провести некоторую работу. Правда как показывает практика такой техники немного – 50-100 на крупного интегратора, каждый такой бензовоз это индивидуальность (почти личность) со своим поведением, особенностями, водителем. А значит с ним возни итак хватает - настройка такой схемы в общем объеме работ - капля в море, однако если минимальный интервал в отчете эту работу вам облегчит, мы будем рады.
