motovyurii

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

На первой картинке нет ответов на запросы в строках под номерами 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 (конечные устройства правда другие).

Всё-таки пришлось вернуться к изначальному варианту, OPC-сервер не подошёл под задачу.. Прогнал в отладчике код взаимодействия по Modbus, похоже дело не в настройках таймаутов компонента. Для чистоты эксперимента заменил код генерации Transaction ID (поменял порядок байт в слове), теперь запросы в логе мониторинга полностью идентичны. MGate в ответ на запрос выдаёт ответ с кодом функции 131, что означает ошибка при запросе с кодом функции 3. И в теле пакета непонятный набор чисел. Можно ли их как-то расшифровать?

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

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

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

Всем доброго дня! Возникла проблема при опросе устройства через MGate MB3170 из самописной программы (Delphi + IdModbusClient). Опрос через Lectus OPC\DDE Toolkit при этом работает исправно. Если посмотреть в лог, записанный с помощью функции Monitoring, то видно что и моя программа и Lectus генерируют абсолютно идентичные запросы (за исключением номера транзакции), но запросы от моей программы остаются без ответа, а с запросами Lectus всё в порядке. Обновил прошивку MB3170 до версии 3 - результат тот же.. Может кто-то подскажет что это может быть? Может быть это как-то связано: доступ к MGate организован через пробрасывание портов на OnCell из внешней сети. Попробовать опрос из локальной сети пока нет возможности. Скриншот лога прикрепил, там первые 4 запроса - запросы от самописной программы, остальные - от программы Lectus OPC\DDE Toolkit.

Спасибо огромное, указал шлюз и всё заработало!

Всем добрый день! Столкнулся с проблемой при попытке организовать доступ к Moxa MGate MB3170 через пробрасывание портов на Moxa OnCell G3111-HSPA. MGate находится во внутренней сети, я настроил на OnCell пробрасывание порта 971 на порт 502 устройства MGate, но связь установить не удаётся. При этом из локальной сети MGate и ONCell пингуются хорошо, установлены в одном шкафу и подключены к одному неуправляемому коммутатору. Пробовал так же пробрасывать порт 970 на порт 80 и коннектиться с помощью Веб-браузера, но так же безрезультатно. Через этот же OnCell организован доступ к нескольким IOLogik'ам, и там такие же методы работают хорошо. Подскажите, в чём может быть загвоздка? Может кто-то сталкивался с такой проблемой?