Проблема при опросе MB3170 из самописной программы

[motovyurii]

Всем доброго дня!

Возникла проблема при опросе устройства через MGate MB3170 из самописной программы (Delphi + IdModbusClient). Опрос через Lectus OPC\DDE Toolkit при этом работает исправно.

Если посмотреть в лог, записанный с помощью функции Monitoring, то видно что и моя программа и Lectus генерируют абсолютно идентичные запросы (за исключением номера транзакции), но запросы от моей программы остаются без ответа, а с запросами Lectus всё в порядке.

Обновил прошивку MB3170 до версии 3 - результат тот же..

Может кто-то подскажет что это может быть?

Может быть это как-то связано: доступ к MGate организован через пробрасывание портов на OnCell из внешней сети. Попробовать опрос из локальной сети пока нет возможности.

Скриншот лога прикрепил, там первые 4 запроса - запросы от самописной программы, остальные - от программы Lectus OPC\DDE Toolkit.

[motovyurii]

Если включить опцию Modbus exception  в настройках MGate, то в программе выдаётся код ошибки "11" (расшифровку кодов ошибок не нашёл), а лог мониторинга выглядит вот так:

[Незнайка]

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

Если на первой картинке смотреть строчку 1 (первый запрос) и сточку 9 (5тый запрос), то они всё таки никак не одинаковые...

[motovyurii]

9 часов назад, Незнайка сказал:

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

Если на первой картинке смотреть строчку 1 (первый запрос) и сточку 9 (5тый запрос), то они всё таки никак не одинаковые...

Но ведь отличаются только первые два байта, а согласно описанию протокола ModbusTCP первые два байта - Transaction Identifier (Идентификатор транзакции): 2 байта устанавливаются Master, чтобы однозначно идентифицировать каждый запрос. Может быть любыми. Эти байты повторятся устройством Slave в ответе, поскольку ответы устройства Slave не всегда могут быть получены в том же порядке, что и запросы.

[motovyurii]

Вопрос более не актуален, решил использовать для своих целей готовый Modbus OPC сервер.

Возможно описанная выше проблема была связана с малым временем ожидания ответа в настройках IdModbusClient (хотя таймауты в настройках компонента были выставлены по 3 сек., но возможно это какая-то особенность компонента), т.к. при первой попытке настройки Modbus OPC сервера получилась похожая картина (запросы оставались без ответа через один), но увеличив значение параметра "Время ответа" с 1 секунды на 2 удалось добиться стабильной связи.

Всем спасибо!

[motovyurii]

Всё-таки пришлось вернуться к изначальному варианту, OPC-сервер не подошёл под задачу..

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

MGate в ответ на запрос выдаёт ответ с кодом функции 131, что означает ошибка при запросе с кодом функции 3. И в теле пакета непонятный набор чисел. Можно ли их как-то расшифровать?

[Незнайка]

On 6/23/2018 at 7:45 AM, motovyurii said:

Но ведь отличаются только первые два байта, а согласно описанию протокола ModbusTCP первые два байта - Transaction Identifier (Идентификатор транзакции): 2 байта устанавливаются Master, чтобы однозначно идентифицировать каждый запрос. Может быть любыми. Эти байты повторятся устройством Slave в ответе, поскольку ответы устройства Slave не всегда могут быть получены в том же порядке, что и запросы.

Верно, просто обратил на это внимание. Но ведь и на запрос из 9той строки есть ответ (строка 12). Поясните детальнее, пожалуйста, где нет ответа на первой картинке?

[motovyurii]

На первой картинке нет ответов на запросы в строках под номерами 1, 3, 5 - эти запросы были отправлены моей программой, написанной на Delphi. Последующие запросы (строки 9,13,17,21) - это запросы, отправленные программой Lectus OPC, на них ответы, как видно, есть. Сейчас только заметил, что запрос в строке 7 отправлен тоже программой Lectus OPC, но на него ответа не было - но это редкость, практически на все запросы от Lectus OPC ответы есть.

Т.е. ситуация получается такая: и моя программа и Lectus OPC посылают идентичные Modbus TCP запросы (судя по логам мониторинга), Moxa на их основе посылает идентичные запросы Modbus RTU. На запросы Lectus OPC ответ по Modbus RTU приходит и Moxa отправляет ответ по Modbus TCP, а на запросы от моей программы ответ от конечного устройства по Modbus RTU не приходит и Moxa генерирует исключение (если включена опция Modbus Exception).

Ещё забыл ранее упомянуть, что компонент IdModbusClient использую не впервые, уже 3 проекта на нём реализовано и все работают стабильно. В упомянутых проектах опрос устройств ведётся в том числе и через MGate (конечные устройства правда другие).

 

[Незнайка]

Всё, теперь дошло. Думаю, причина здесь не в программах, а в нестабильной связи между MGate и Slave. Ведь со стороны RTU запросы в любом случае всегда выглядят одинаково. Exception code 11 = Gateway Target Device Failed to Respond, то есть нет ответа с другой стороны шлюза.

[motovyurii]

7 часов назад, Незнайка сказал:

Всё, теперь дошло. Думаю, причина здесь не в программах, а в нестабильной связи между MGate и Slave. Ведь со стороны RTU запросы в любом случае всегда выглядят одинаково. Exception code 11 = Gateway Target Device Failed to Respond, то есть нет ответа с другой стороны шлюза.

Дело в том, что я много раз проверял опрос как своей программой, так и программой Lectus OPC, и своей программой ни разу не удалось получить значение, а через Lectus OPC опрос стабильно хороший..

Но кажется я победил эту проблему) Дело было вот в чём: у меня программа получив ошибку выводила сообщение в модальном окне и делала следующий запрос только после нажатия ОК. Таким образом между запросами образовывалась пауза в несколько секунд. В очередной раз запустив программу и увидев сообщение об ошибке я быстро нажал на ОК и следующие запросы пошли уже без ошибок. Т.е. получается конечное устройство (кстати, это был расходомер Siemens FUS080) игнорирует первый запрос и начинает отвечать только если запросы идут один за другим с маленьким интервалом. Этим же объясняется и отсутствие ответа на запрос Lectus OPC  в 7 строке на первой картинке..

Незнайка, спасибо огромное за участие в решении вопроса!

[Незнайка]