Ошибки опроса и способы их устранения

<< Click to Display Table of Contents >>

Navigation:  Modbus Universal MasterOPC Server > Руководства по подключению различных контроллеров > Настройка модемов > Опрос по GPRS (3G) каналу >

Ошибки опроса и способы их устранения

При работе по каналу GPRS отсутствует явление разрыва пакетов, однако может проявляться задержка пакетов – при этом может возникнуть ситуация, при которой будет происходить перепутывание пакетов. Рассмотрим данную ситуацию подробнее.

OPC сервер ведет опрос устройства и посылает ему запрос (запрос №1). В канале связи, по какой-либо причине, возникла задержка и время ответа превысило настроенное время ожидания. OPC сервер, не получив ответ, посылает новый запрос (запрос №2). Ему поступает ответ на запрос №1. Поскольку данные получены, то OPC сервер посылает новый запрос (Запрос №3), но ему приходит ответ на запрос №2 – ответы перепутались.

При работе по протоколу Modbus TCP данная ситуация не является критической, так как в протоколе заложено специальное поле – Transaction ID. При каждом запросе OPC сервер инкрементирует данное поле (если включена настройка Отслеживать Transaction ID), а устройство при ответе также должно указать Transaction ID равное значению в запросе. Поскольку можно точно понять на какой запрос пришел ответ, перепутывания запросов в Modbus TCP не происходит.

У протокола Modbus RTU подобного поля нет, поэтому при работе с ним через GPRS шлюзы, перепутывание запросов возможно.

Решить проблему можно правильно настроив OPC сервер. Во-первых, нужно установить достаточно большое время ожидания ответа – 5000 мс или даже более (посмотрите лог запросов, посмотрите сколько времени уходит на запрос-ответ и задайте значение в 2-3 раза больше). Но даже указав очень большое время ожидания нельзя гарантировать что и оно не будет превышено. Поэтому вторым защитным механизмом должна быть реинициализация соединения. Дело в том, что если пакет, по какой-то причине "застрял" в сети, то можно произвести закрытие соединения, тогда пакет будет отброшен и не попадет в OPC сервер.

Для решения данной проблемы можно настроить опрос устройства таким образом, чтобы его пакеты отличались. К примеру, мы опрашиваем устройство с 15 тегами типа Holding Registers, опрос производится в 3 запроса по 5 тегов в каждом: первый запрос - адрес с 0 по 5, второй запрос - с 10 по 15, третий запрос с 20 по 25. Перепутывание запросов в данной конфигурации возможно - например, если при выполнении второго запроса возникнет задержка, то данный пакет впоследствии может быть принят как ответ на третий запрос. Но если сделать, чтобы в каждом из запросов было разное количество запрашиваемых регистров - это решит проблему, в этом случае ОРС сервер обнаружит что пакет имеет не корректную длину и отбросит его, после чего повторит запрос. Сделать, чтобы длина запросов отличалась можно добавив дополнительные регистры - например, во второй запрос добавить еще один тег, с адресом 16, а в третий еще два тега с адресами 26 и 27. Теперь длина всех трех пакетов будет отличаться, и они уже никогда не перепутаются.

Если запросов много, не нужно добавится чтобы каждый из них имел уникальную длину - главное чтобы отличалась длина идущих друг за другом запросов. Снимите лог обмена устройства и посмотрите его. Отредактируйте все запросы к устройству с одинаковым регионом и количество регистров, идущих друг за другом. Также не забудьте проверить последний и первый запросы - их длина тоже должна отличаться.