Форум TRACE MODE: техническая поддержка: Дребезг значения из-за плохой связи с прибором

This is topic Дребезг значения из-за плохой связи с прибором in forum Общие вопросы / Common questions at Форум TRACE MODE: техническая поддержка.

To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/45/t/000254.html

Posted by FiXiZ (Участник № / Member № 5069) on :

Здравствуйте!

Имеется modbus-устройство с которого регулярно считывается накопительное значение. Это значение разбито в приборе на две ячейки памяти. RTM 6.06 считывает эти две ячейки в 2 канала по 16 бит, затем регулярно крутящаяся программа склеивает это дело в один параметр double float, что и является конечным значением с прибора. Раз в десять минут это конечное значение записывается в базу для анализа и прочих преобразований. Проблема в том, что в помещении с прибором действуют наводки и ответы на запросы двух каналов по 16 бит часто не приходят, из за чего они получают недостоверность и падают в ноль, от этого страдает конечное значение и по эффекту карточного домика в базу пишется непонять что. Вопрос: как можно разрулить это дело с программной стороны, чтобы если 16-и битные параметры получат флаг недостоверности, их значения сохранялись и не падали в ноль?

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Факт появления признака недостоверности в канале, связанном с "Источником", не является основанием для для сброса значения канала в 0.
Если это действительно имеет место, возможно, речь идет об отключении канала от "Источника", что осуществлялось в ранних релизах в драйвере Modbus TCP при многократном отсутствии ответов на запросы.

Можно попытаться установить параметр
0 OFFCOUNT
в файле ip_modbus.

Рекомендуем перейти на текщий релиз 6.08, выложенный на сайте.

Posted by FiXiZ (Участник № / Member № 5069) on :

Речь идет о TM6.06 и Modbus RTU через RS-485. Если вы говорите, что при выставлении флага недостоверности не влияет на сброс значения в 0, тогда что это может сбрасывать это значение? Кусок кода, преобразующий 2 16-и битных значений в double float следующий:

code:

  	IF ( Весы73_1_I == 0 && Весы73_2_I == 0 ) THEN
		temp = Весы73_1_R;
		temp = temp  << 16;
		temp = temp  | Весы73_2_R;
		Весы_73_общ_In = temp * 0.001;
	END_IF;

По идее, когда кто-то из них недостоверен это условие не должно срабатывать и общее значение не должно изменяться

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

В драйвере Modbus RTU канал может обнуляться только с приходом корректного ответа со значением 0.
Надо перехватывать трафик COM-порта утилитами, например, PortMon. И по протоколу перехвата устанавливать истинную причину обнуления канала.

Posted by FiXiZ (Участник № / Member № 5069) on :

Посмотрел в портмон, ответ на корректный запрос приходит через раз. Точнее даже сказать, что запрашивается два параметра, но по очереди на один из них ответа как правило не приходит

Posted by AdAstra Technical Support (Участник № / Member № 4) on :

Результат контроля недостоверности лучше посылать в недостоверность результирующего канала, а не учитывать при формировании его значения.
Обнуляются значения каналов Весы73_1 и Весы73_2 или канала Весы_73_общ?
Выключите программу преобразования и проверьте действительное поведение каналов Весы73_1 и Весы73_2.

Установите этим двум каналам флажок "Отладка".
В файле *.cnf узла задайте ключ DEBUG=2200 (контроль атрибутов этих двух каналов и ошибок по RS).
Пришлите, пожалуйста, проект, папку проекта с протоколом профайлера и протокол перехвата PortMon

Posted by FiXiZ (Участник № / Member № 5069) on :

Да, действительно, все оказалось проще. Весы73_1 и Весы73_2 не обнулялись, а становились недостоверными, но при этом почему-то Весы73_общ обнулялся, видимо издержки старой версии. Применив другой программный подход, удалось решить проблему. Спасибо!

Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us

UBB.classic™ 6.7.2