Типовые проблемы и способы их устранения Modbus

<< Click to Display Table of Contents >>

Navigation:  Проект в MasterSCADA 4D > Дерево системы > Получение и отправка данных > Стандартные протоколы > Modbus > Рекомендации по настройке протокола Modbus >

Типовые проблемы и способы их устранения Modbus

С прибором нет связи даже с одним каналом – отказ в TRUE

Посмотрите лог запросов, если вы увидите ERROR: no answer, то это означает что нет ответа от устройства. Проверьте настройки прибора, подключение, добавьте таймаут.

Если же нет запросов совсем (даже запроса к устройству), то это означает проблемы в настройках подключения - неверный COM порт. В случае с TCP - неверный IP адрес или порт, или порт не прослушивается устройством (Modbus TCP сервер не активен).

Есть запросы, есть ответы, но все равно выдается отказ

Такое может возникать при повреждении пакетов. Данная проблема часто возникает при опросе по Modbus RTU, так как конец кадра он определяет по "тишине" на шине. Поэтому если при передаче возникла задержка, сервер может воспринять это как конец кадра и попытаться разобрать принятый неполный кадр. Особенно актуальна данная проблема при работе по GSM и радиоканалам, но может возникать и в обычном RS-485 если устройство имеет медленный буфер и рвет пакет.

Данную ситуацию достаточно хорошо видно в логе - пакет как бы рвется на составные части.  

Для решения данной проблемы нужно увеличить время таймаута.

Часть каналов имеют качество Uncertain

Такое, может быть, если устройство отвечает кодом ошибки. По стандарту, если устройство получило запрос, но не может его выполнить (например, запрашивается неподдерживаемая функция или некорректный адрес), то оно отвечает кодом ошибки. Код ошибки представляет собой сумму кода функции и числа 0x80, то есть при запросе функцией 0x03 в случае ошибки устройство вернет 0x83.

Например:

Modbus driver. Read start

55000360: Port=3 iTimeout=1000 len=8: 10 03 00 05 00 01 97 4A  t-> (port=3 dt=1084 c=5 fc=00) 10 83 02 90 F4  

Modbus driver ERROR: get code error. Exit

Modbus driver. Read done

В данном случае устройство вернуло после адрес число 0x83 – код ошибки региона Holding Registers (0x80 + 0x3). Следом после кода идет код расшифровки ошибки. Стандартом определены следующие значения:

Код

Название

Описание

01

ILLEGAL FUNCTION

Не поддерживаемая функция (данный регион или способ обращения к нему не поддерживается).

02

ILLEGAL DATA ADDRESS

Некорректный адрес - данный адрес этого региона не может быть запрос.

03

ILLEGAL DATA VALUE

Не корректное значение - возникает при записи в устройства недостоверного значения (например, слишком больше или слишком маленькое число для устройства).

04

SERVER DEVICE FAILURE

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

Есть ещё ряд расшифровок ошибок, но они почти не применяются - полный список вы можете посмотреть в спецификации протокола.

В данном случае было получено значение 02 - некорректный адрес. Это означает что данный адрес не может быть опрошен - необходимо свериться с документацией на прибор.

Каналы, на которые пришел код ошибки в дереве системы, имеют признак качества Uncertain, что упрощает диагностику данной проблемы.

Один канал опрашивается корректно, но при увеличении их количества возникает отказ устройства

Такая проблема может возникать на приборах с Modbus RTU работающих по RS-485. Данные устройства могут иметь ограничения на количество запрашиваемых регистров. Обычно максимальное значение запрашиваемых регистров описано в документации.

Для ограничения длины пакетов есть специальная настройка устройства:

tipovie_problemi_i_sposobi_ih_ustraneniya_Modbus

Опрос есть, но спустя некоторое время опрос прекращается и восстанавливается только после перезапуска

В этом случае, вы скорее всего, увидите в логе сообщений что драйвер не может открыть порт. Это происходит из-за зависания порта. Решить данную проблему можно, включив настройку устройства Реинициализация узла при ошибке - в этом случае сервер закроет порт, а затем откроет его снова. Это может вывести его из зависания. По умолчанию настройка включена.

Периодически возникает признак качества BAD.  

Здесь также нужно анализировать лог – возможно в какой-то момент устройство перестает отвечать или возникают задержки или помехи. Можно попробовать увечить количество попыток и время ожидания ответа.

В процессе работы в тегах иногда появляются некорректные значения.

Такая ситуация может возникать при работе по радио и GSM каналам по протоколу Modbus RTU (при работе по Modbus TCP такая ситуация невозможна). Это происходит из-за "наслоения" ответов. В Modbus RTU нет специального поля, по которому можно было бы определить соответствие ответа определенному запросу (в Modbus TCP такое поле есть – Transaction ID). Представим ситуацию, протокол послал запрос в устройство, устройство ответило, но возникла задержка в сети (в радио сетях это обычное явление), протокол не получил ответ и отправил запрос повторно, ему пришел ответ на предыдущий запрос – он корректен, протокол разобрал его и послал следующий запрос (следующего регистра), ему приходит ответ от предыдущего запроса - но в нем содержаться данные совершенно от других регистров. Затем протокол производит анализ полученного ответа, например, если в запросе было 2 регистра, а пришло 4, то такой запрос он отбросит и запросит заново, аналогично он отбросит пакет если запрос пришел не от запрошенного устройства или с другой функцией. Однако если запрос по структуре совпадает с предыдущим, протокол его примет и запишет значения в канал, которые будут некорректными.  

Решить проблему можно увеличением таймаута, а также настройкой пакетов таким образом, чтобы идущие друг за другом пакеты обязательно отличались по структуре. Например, вы запрашиваете каналы с адреса 100 – 5 регистров, и с адреса 200 – также 5 регистров. Добавьте еще один канал с адресом 206, и тогда у вас будет 5 регистров в одном запросе и 6 регистров в другом – тогда пакеты никак не перепутаются и протокол данную ситуацию корректно отработает.

Канал типа FLOAT (DOUBLE, INT32) имеет некорректное значение

Здесь возможны два варианта.

Первый вариант - неправильное чередование байт. Представим себе, что устройство передает число 100, в переменный типа INT16. Число 100 будет представлять собой два байта - 00 64. Мы можем принять старшим байтом вперед и получить 00 64 - 100, а может принять младшим байтом вперед и получить 64 00 - 25600. Аналогичная ситуация возникает и с FLOAT, но только там байт уже не 2, а 4 (а у DOUBLE - 8). По стандарту применяется следующие настройки чередования:

2 байтовые числа (INT, WORD) – старшим байтом вперед - _1_0

4 байтовые числа (LINT, LWORD, REAL) – старшим словом вперед - _3_2_1_0

8 байтовые числа (LREAL, LINT, DWORD) – старшим двойным словом вперед - _3_2_1_0

Настройка чередования байт находится в панели свойств модуля в разделе Чередование байт:

tipovie_problemi_i_sposobi_ih_ustraneniya_Modbus_1

Однако есть и исключения из правила. У всех контроллеров с Codesys 2, и для 2 байтовых (WORD), и для 4 байтовых (REAL) чередование байт - старшим байтом вперед _1_0_3_2.

Второй вариант - некорректный адрес регистра.  

Например, есть два числа DWORD с адресами 100 и 102. Допустим они имеют следующие значения в байтах:

100 L

100 H

101 L

101 H

102 L

102 H

103 L

103 H

0x1

0x2

0x3

0x4

0x5

0x6

0x7

0x8

Если мы прочитаем значение DWORD указав адрес 100, то получим значение 01 02 03 04 - 16909060 (чередование _3_2_1_0). Но если мы укажем адрес 101, то получим значение 03 04 05 06 - 50595078, т.е. одну часть значения мы взяли из одного числа, а другую – из другого. Конечно же в этом случае значение всегда будет недостоверным, независимо от чередования байт.

Аналогичная ситуация может быть и с числом типа REAL или LREAL. Проверяйте корректность задаваемых адресов Modbus.

Обращение в техническую поддержку

Если вам не удалось решить проблему самостоятельно, то подготовьте необходимую информацию для техподдержки:

1.Опишите детально проблему, приложите несколько скриншотов или видео.

2.На отдельном проекте с одним проблемным прибором, с минимумом переменных проявите проблему и включенным расширенным логом (с установленным значением /t для настройки Параметр запуска RT).

3.Сформируйте отчет об ошибках и направьте всю информацию в HelpDesk систему технической поддержки.

Смотрите также: