Встречаются при работе с ТСРВ-026М расхождения в значении настраиваемых отдельно ячеек прибора (наблюдал на Wтс и Мтс) в ЛЭРС Учет и Взлет ИИС. Иногда это явные видимые расхождения в виде одинаковых значений за небольшой период времени, иногда просто похожее но не то число.
Вот сравнения со Взлет ИИС за апрель и июнь.
Настройка точки
Данные за апрель вычитывалисьза один раз, прикладываю жирнал обмена и его дамп
также прикладываю выгрузку из ЛЭРСа и аналогичный период из Взлет ИИС.
Мы произвели анализ описываемой ситуации. Действительно, при повторном опросе прибора интеграторы не перезаписываются даже если отключена галочка “Только недостающие данные”. Это происходит потому, что данному прибору требуется использовать расширенный алгоритм интерполяции (в модели оборудования на вкладке “Обмена данными” → “Драйвер” в параметре “Возможности” присутствует флаг “NeedsAdvancedTotalsInterpolationAlgorithm”), так как при использовании данного алгоритма перезапись предыдущих интеграторов приводит к неправильному расчету.
Для подобных приборов требуется вручную удалять интеграторы перед повторным опросом.
В первом сообщении вы приложили журнал повторного опроса (переопроса). Нам необходим журнал опроса, при котором фигурирующие на скриншоте данные были получены изначально, и дамп обмена к этому журналу.
Поясните это утверждение. Уже не первый год для ТСРВ-026М для восстановления интеграторов используется “интерполяция по имеющимся” без “Использовать расширенный алгоритм интерполяции интеграторов”. Т.е. вот так
Мы проверили присланные журналы опроса суточных данных за 05.7 и 06.07. Опять же ситуация воспроизводится только в том случае если присутствуют импортированные данные. Если же удалить суточные данные и интеграторы, после чего произвести опрос по присланному журналу и дампу, то ситуация не воспроизводится.
Возможно где то в начале всей цепочки неправильных данных произошел сбой при чтении интеграторов. Пришлите пожалуйста журнал опроса и дамп обмена за дату, начиная с которой появились расхождения, и журнал и дамп за предыдущую дату относительно этой начальной даты.
В данном комментарии я подробно объяснил почему именно отключение галочки “Только недостающие данные” не приводит к перезаписи интеграторов и почему их нужно удалять именно вручную для возможности считать заново. Если у прибора выставлен вышеописанный флаг, то данный алгоритм задействуется Сервером в любом случае независимо от того выставлена ли вышеописанная настройка или нет. Ничего неправильного в том, что она у вас не установлена в параметрах расчета, в данном случае нет.
Так ведь я Вам показываю расхождения не интеграторов, а значения суточных архивов. Они должны читаться напрямую их прибора, в том числе и Wтс. Почему Вы рассказываете о сбое в чтении интеграторов? Более того, по этому прибору вычитывают только суточные архивы, интеграторы и текущие.
О какой цепочке идет речь, ведь интеграторы восстанавливаются между двумя полученными из прибора значениями интеграторов. Так вроде написано в документации у Вас, т.е. ошибка не может накапливаться, т.к. постоянно делается “сверка” с данными прибора. При чем тут “сбой при чтении интеграторов”?
В начале темы видно, что Wтс и deltaQ периодически совпадают, как я дожен вычислять “начальную дату”?
Хотя я прислал самые ранние дампы из тех которые есть. И в них должна быть видна ошибка, на мой вгляд.
Хотелось бы нормального пояснения алгоритма работы этой настройки. Т.е. “флажок” про расширенный алгоритм можно вообще не использовать? он автоматически включается? зачем тогда он нужен?
Дело в том что у прибора в ячейках хранятся только интеграторы. Потребление в ячейке не хранится, оно рассчитывается по интеграторам. У данного прибора в принципе очень сложная схема хранения данных. Архивные интеграторы (суточные, часовые, месячные ) у данного прибора есть только в ячейках. Для параметров по каналам интеграторы есть только в текущих данных. Если вы откроете присланный вами журнал опроса, допустим, за 05.07.2019, то увидите что вместе с суточными данными за 05.07.2019 считываются интеграторы на 05.07.2019 00:00:00 и на 06.07.2019 00:00:00. Это интеграторы, хранящиеся в ячейке Wтс, по которым впоследствии Сервером будет произведен расчет потребления данной ячейки. Данное рассчитанное потребление уже будет сохранено в параметр dQ, к которому привязана ячейка Wтс.
Под цепочкой я подразумевал последовательность суточных данных (потребление), идущих непрерывно друг за другом в течении какого то периода.
О каком восстановлении данных и о какой сверке идет речь мне непонятно. Если вы про расширенный алгоритм интерполяции, то на сколько я понимаю, в вашем случае при опросе суточных данных данный алгоритм задействован небыл, так как в нем небыло необходимости. Но даже если бы он был задействован, данный алгоритм не предполагает каких либо сверок или восстановления данных. Алгоритм интерполяции это алгоритм расчета недостающих записей.
Все верно, то периодически данные нормальные, а периодически возникает несоответствие. В пункте 2 я описал подробнее что подразумевалось под цепочкой неправильных данных. Допустим на последнем представленном вами скриншоте видно, что последняя цепочка неправильных данных начинается с 01.07.2019 по 11.07.2019. Если это вся цепочка, а не ее часть, то начальная дата 01.07.2019. В этом случае вам необходимо предоставить журнал опроса и дамп обмена суточных данных за 01.07.2019 и журнал опроса + дамп обмена на дату предыдущую начальной дате.
Так как данных ранее 05.07.2019, как я понимаю, уже нет, в таком случае давайте поступим следующим образом:
Нормализуйте данные путем полного переопроса суточных данных, по которым наблюдаются расхождения, вплоть до сегодняшнего дня, предварительно удалив их вручную
Как только ситуация воспроизведется, приложите журнал опроса суточных данных + дамп обмена за дату, начиная с которой появятся расхождения.
У нас на форуме существует правило: один вопрос - одна тема. В данной теме обсуждается проблема с расхождением показаний прибора ТСРВ-026М в ЛЭРС УЧЕТ и в заводской программе. Скажу лишь, что расширенный алгоритм интерполяции запускается либо если выставлена соответствующая настройка в разделе “Расчет и хранение” свойств точки учета по кнопке “Дополнительно”, либо если в модели прибора указан вышеописанный флаг “NeedsAdvancedTotalsInterpolationAlgorithm”. Разница лишь в том, что настройка привязана к точке учета и может быть выставлена или не выставлена, а флаг жестко привязан к модели прибора и его регулирование пользователем невозможно.
Ранее мы обсуждали прибор #1311157. Сейчас вы приложили опрос прибора #1203776. Уточните, пожалуйста, совпадают ли у точки учета прибора #1203776 настройки привязки ячеек и настройки расчета с настройками, отраженными на ранее приложенных скриншотах по точке учета прибора #1311157? Если не совпадают, пожалуйста, приложите обновленные скриншоты.
Также приложите результаты опроса прибора #1203776 за тот же период и по тем же данным, что и в представленном журнале опроса, заводской программой.
Версия 3.30.4 - ошибка по записи суточного потребления все еще присутствует. Напишу свои наблюдения, может поможет.
Экперементировал с ТСРВ-026М. Выбрал период - с 31го числа предыдущего месяца по 8е число текущего.
Удалял данные за этот период полностью и опрашивал прибор ручным опросом. Произвел 4 таких переопроса “месячные, суточные, текущие” - всегда в таблице после этого отображались одинаковые суточные данные по dQ и dM.
Решил запросить только суточные, в результате :ya_hoo_oo: в таблице появились правильные данные, но интеграторы по М1 и М2 не считались( вроде это особенность данного прибора ) . Не удаляя более данные из базы запустил опрос “месячных и текущих”, после этого все заполнилось правильно!