ModDiffCalculator — настройка

[manjey73]

Смотрим в документацию, и пункт 2, если не ошибся.
Модуль читает тот же архив, куда сохраняет.
Ну и как тут в принципе сохранить в текущий?

[Andrew123]

«Ну и как тут в принципе сохранить в текущий?» — да, пропустил момент.

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

[manjey73]

Так он априори не сможет узнать разность при работе (если не выдавал бы ошибок) с текущими. Или период с текущими должен быть равен нулю, тогда логична разница между текущим и прошлым значением

Но у вас проблема в другом, в том, что, как вы говорите у вас появляется 0, значит в дело вмешивается время опроса, вы можете получить то же самое значение, как было и минуту ранее.

[Andrew123]

Проблема в том, чтобы можно было писать разницу в текущий архив в другой расчётный канал (и не важно, на основе какого архива это будет сделано, важно чтобы писал).
Но этого ModDiffCalculator делать не может, понятно уже.

Допустим, есть группа, для примера:
<Group active=»false» name=»LifeBit_Min» periodType=»Minute» offset=»00:00:00″ delay=»5″ adjustForDst=»false» recalcDiff=»false» archiveBit=»1″>
<Item srcCnlNum=»6650″ destCnlNum=»6651″ />
</Group>

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

[manjey73]

Простой пример, ПЛК с равным промежутком времени меняет значение 0-1-0-1-0-1…

Нет гарантий, что при опросе вы дважды и более не нарветесь на 0. Соответственно два раза считали одно и то же значение, разница = 0, что логично.

Тут нужен другой подход, создать счётчик и достаточную паузу при чтении одного и того же значения. Счётчик завис, за 3-5 минут не продолжил увеличиваться — вот тогда алярма.

з.ы. а вообще использовать служебный тег Status на устройство и так же паузу по таймеру, на случай ошибки чтения разовой.

[manjey73]

Поставьте период по нулям для текущего, будет ошибка ?

[manjey73]

<Group active=»false» name=»LifeBit_Min» periodType=»Minute» offset=»00:00:00″

ну нет в текущем архиве значения МИНУТУ назад, его в принципе там не существует.
А вот что будет при периоде 00:00:00 ?

[Andrew123]

«А вот что будет при периоде 00:00:00 ?» — 2026-09-01 11:51:28 Не задан пользовательский период для группы «LifeBit_Cur»

[manjey73]

Забавно 😀

Но тип сигнала из ПЛК вы так и не описали.
Может тут подойти Диф или нет остаётся вопросом. С учётом периодов опроса ПЛК.

[Andrew123]

«Может тут подойти Диф или нет остаётся вопросом.» — почему только тут …
Применений много, количесво типов разниц … да даже по расходам, когда например нет суточного расхода, а хотелось бы его иметь на мнемосхеме.

А по лайфбиту — так этот сигнал, например, у Сименса отвечает, жив ли OPC DA. У некоторых других жив ли контроллер как отдельно, так и в резервируемой конфигурации.

Мой пример, это лайфбит — импульс длительностью 1сек.(0-1-0-1 …) или более(в зависимости от настоек), во всяком случае за минуту, две, три всегда будет изменение, если норма.

Потому вопрос, может ли добавить в функционал ModDiffCalculator-а возможность писать в текущий архив требуемую разность.

[manjey73]

Мой пример, это лайфбит — импульс длительностью 1сек.(0-1-0-1 …) или более(в зависимости от настоек), во всяком случае за минуту, две, три всегда будет изменение, если норма.

Вот про это я и говорю, время цикла опроса может приводить к тому, что каждую минуту вы на самом деле будете получать 0 или 1 несколько раз подряд, что не является ошибкой, ну просто так совпало, что вы прочитали ТАКОЕ ЖЕ значение как и в прошлый раз.
тут более корректным будет счетчик и уже на основании прекращения счета за определенный период определение, что что-то умерло.

С нарастающим итогом, что Diff, что формулы работают корректно
А вот тот же Расход ТАК ЖЕ может совпасть на прошлом чтении прибора и текущем. Просто вот равномерный расход, особенно если проводятся округления значений расхода. Тут тоже некорректно применять Diff.

В некоторых случаях правильнее применить служебный Тег устройства — Status 0 — Норма, 1 — Авария. И задержку на случай случайной ошибки при запросе.

[Andrew123]

Дак у меня сейчас и стоит функция подсчёта кол-ва импульсов. Есть увеличени -норма нет, плохо. Для того и надо писать разницу. Потому и спрашивал, может ли разработчик внести изменение в ModDiffCalculator!

[manjey73]

з.ы. кстати вы должны еще понимать, как работает опрос Коммуникатором.
Там тоже идет привязка ко времени.
При старте Коммуникатора первый же опрос производится вне точки времени, ну потому что Коммуникатор стартанул. Потом опрос происходит строго в точку времени. Например вы выставили цикл 00:00:20 каждые 20 секунд.

При старте было время х:х:12 — это первый опрос, потом опросы будут
в x:х:20, х:х:40, y:y:00, y:y:20 и так далее
и вот у вас опрос каждую секунду например, длительность в ПЛК 0-1-0-1 меняется каждую секунду и привет Медвед, вы получаете 0-0-0-0 при опросах 🙂

[manjey73]

для счетчика разница не нужна 🙂 там тупо если канал = 1 сделай +, не 1 не делай +
Все…

А если у вас продолжительное время расход равен? Разница всегда будет 0, потому что вы в прошлый раз считали расход 0,2м3 в час, через минуту расход такой же, те же 0,2м3 в час — все, разница равно нулю…

• Ответ изменён 5 дней, 21 час назад пользователем manjey73.

[Andrew123]

«вы получаете 0-0-0-0 при опросах» — это легко решается длительностью импульса и длительность опроса … к тому же 0-0-0-0 это при идеальной синхронизации в плоть до милисекунд между ллэйвом и мастером(что в моё случае просто не достижимо).

[Автор]

Записи