Чтение данных с ВИС.Т в разрезе точек учета [9310] [10581]

В продолжение темы Повторный опрос уже опрошенных данных с ВИС.Т - Опрос - ЛЭРС УЧЁТ и телефонного звонка просим Вас добавить чтение данных в разрезе точек учета.
При опросе не формировать общий период недостающих данных в приборе, а анализировать реальные недостающие данные по точкам учета.
Например, если в приборе имеются две точки: ГВС на первом тепловом вводе и ХВС - на втором, то сначала переключиться на первый тепловой ввод и считать недостающие данные по ГВС, а затем - на второй для опроса недостающих по ХВС.

Добрый день!

Предложение понятное, но сделать его крайне затруднительно. Архитектура системы пока не позволит нам считывать данные по конкретным точкам. Мы подумаем каким образом можно это ограничение обойти для ВИС.Т, но, к сожалению, простого решения у нас на данный момент нет.

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

Обновились наконец до последней версии(3.43.3), ситуация не изменилась.

Доступ к прибору отправили на support.

Доступ к устройству проверен. Мы приступили к работе над данной задачей.

Мы внесли изменения в драйвер устройства. Изменения будут доступны начиная с версии 3.44.

Наконец-то обновились с 3.43.3 до 3.48.1 и проверили алгоритм опроса.

В целом ситуация улучшлилась: приборы с несколькими тепловыми вводами лучше начали опрашиваться, хоть и с лишними повторами. Но вместе с этим появились проблемы у приборов на объектах с плохой связью. Так как в новом алгоритме ЛЭРС УЧЕТ сразу считывает по всем точкам, из-за таймаутов или ошибок между запросами, иногда сохраняются кривые данные.

Журнал опроса.xlsx (8.4 КБ)
dump.GPRS(Telemetric)(148).2022-10-20.log (12.7 КБ)

То есть при чтении архивной записи по тепловому вводу №1 произошёл таймаут, система потворно отправила запрос, затем пришёл старый ответ на первый запрос, затем при запросе данных по тепловому вводу №2, пришёл второй старый ответ по тепловому вводу №1 и т.д., из-за чего получился сдвиг в данных.
Такая проблема скорее всего всегда была и до обновления, просто смещение происходило по записям одного и того же ввода, из-за чего данные более-менее были правдоподобные(правда в отчёте данные не бились из мелких расхождений после запятой).

Мы проанализируем возникающую ситуацию и дадим вам ответ позже.

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

Выслали повторно доступ к прибору из этой темы выше.

Доступ к устройству проверен. Внесение исправления предварительно запланировано на версию 3.49. Не прекращайте доступ к прибору.

В 3.49 мы повысим стабильность чтения данных. В случае если принят дубликат архивной записи, запрос будет повторён.

@lersbot update 3.49.0

Добрый день!

Обновление 3.49.0 (сборка 34907) от 28.11.2022 доступно для установки.

После 3.49.0 проблема все еще имеет место быть.
Алгоритм не всегда срабатывает - все равно есть кривые данные.
Посмотрели журналы за кривые даты - не везде выводится “ВИС.Т-ТС: Ответ от устройства совпадает с предыдущим ответом. Повторяем запрос.”. То есть при чтении иногда было несколько таймаутов, но алгоритм не сработал(и появились кривые данные).

На странице 16 протокола обмена есть рекомендуемая последовательность чтения архива.
modbus-2.pdf (286,3 КБ)
Есть предложение реализовать что-то подобное, при этом немного доработав этот алгоритм следующим образом:

  1. Запросить дату и время прибора и запомнить текущую дату чтения(время компьютера, где стоит служба опроса).
  2. Рассчитываем текущее время по прибору путем прибавления количества прошедшего времени с момента чтения даты прибора в п.1. Если по времени прибора скоро наступит новый час(например, по прибору 19:59:45, добавляем паузу в 20-30 секунд для наступления на приборе нового часа), либо наступил новый час(например, по прибору 20:00:01, добавляем на всякий случай паузу в 5-10 секунд), то считываем заголовок архива и запоминаем поле “Время обновления архива”.
  3. Рассчитываем индекс и считываем требуемую архивную запись и проверяем CRC
  4. Повторно считываем архивную запись с тем же индексом из п.3
  5. Если содержимое двух считанных записей из п.3 и п.4 не совпадает, то добавляем паузу(например 5 секунд, для очистки входного буфера из-за таймаута или других ошибок) и переходим в п.2. Если содержимое совпадает, то получена достоверная архивная запись - сохраняем её. Переходим в п.2.

Проверку повторов и вывод “ответ от устройства совпадает с предыдущим ответом” нужно отключить. Для расчёта пауз, например, можно брать значение задержки ответа из свойств оборудования:

// задержка ответа из свойств оборудования
int ReadTimeout;
// дата и время по прибору
DateTime deviceDateTime;
// дата чтения deviceDateTime по времени текущего компьютера
DateTime serverDateTime;

/* ... */

// обеспечивает проверку наступления нового часа в приборе
private void EnsureNewHour()
{
	// текущее время по прибору
	var dateTime = this.deviceDateTime.Add(DateTime.Now.Subtract(this.serverDateTime));
	// текущий час по прибору
	var lastHourStart = new DateTime(dateTime.Year, dateTime.Month, dateTime.Day, dateTime.Hour, 0, 0);
	// следующий час по прибору
	var nextHourStart = lastHourStart.AddHours(1);
	// прошедшее время с начала текущего часа
	var after = dateTime - lastHourStart;
	// сколько осталось времени до следующего часа
	var before = nextHourStart - dateTime;
	// указывает, что наступил новый час и нужно добавить паузу
	var isNewHour = after.TotalMilliseconds < ReadTimeout;
	// указывает, что скоро наступит новый час и нужно добавить паузу
	var waitNewHour = before.TotalMilliseconds < ReadTimeout;

	if (isNewHour || waitNewHour)
	{
		//если скоро наступит новый час, то пауза будет равна 2 * ReadTimeout, иначе ReadTimeout
		var timeout = isNewHour
			? ReadTimeout
			: ReadTimeout * 2;

		//выводим в журнал сообщение
		LogWarning($"Добавляем паузу({timeout} мс) для формирования новых архивов, так как по часам устройства {dateTime:dd.MM.yyyy HH:mm:ss} " +
			$"{(isNewHour ? "наступил" : "скоро наступит")} новый час");
		
		//пауза для формирования новых архивов
		Delay(timeout);
		
		// считываем заголовок архива повторно для получения даты обновления
		ReadArchiveHeader();
	}
}

Приложите пожалуйста журнал опроса и дамп обмена для сеанса опроса, во время которого алгоритм не сработал.

В часовые за 11:00 в Q попали интеграторы из заголовка архива.

dump.GPRS(Telemetric)(111).2023-01-20.log (8,7 КБ)
Журнал опроса.xlsx (8,0 КБ)

Приношу извинения за долгий ответ.

У нас были внесены изменения связанные с повторением запросов для ВИС.Т. Изменения доступны в версии 3.51.3. Какую версию ЛЭРС УЧЁТ вы сейчас используете? Если вы используете версию 3.51.3, тогда сообщите, возникают ли проблемы с опросом устройства?

Пока что еще 3.49.3. Возможно ближе к середине лета обновимся.