MAG

С наступающим праздником! Личного сообщения не увидел. Если можно, вышлите и описание на MGate. Не факт, что и он подойдёт.

Здравствуйте. Хотелось бы разобраться, как формируются порты source в протоколах UDP, какие возможны варианты. Не могли бы дать ссылку. Обратил внимание, что контроллер перебирает порты source в своих запросах, если нет ответа. Появилась надежда наладить связь... К программе ModPoll обратился как к инструменту, чтобы понять, почему нет связи с контроллером. Контроллер поддерживает только два, как считается на www.modbus.org - стандартных соединения: Modbus/TCP и Modbus RTU over UDP. Так что выбор у меня ограничен. Посмотрел на предложенные вами преобразователи MGate. Там есть для расширенного диапазона температур, которые нам подошли бы: MGate MB3270I-T и MGate MB3270-T. К сожалению, не нашёл описания на них. В чём между ними разница? P.S. Не могли бы дать образец на тестирование?

Вы правы, всё дело в несогласованности портов при приёме ответной посылки. Такая же история происходит и при опросе от контроллера. Вопрос - как узнать этот destination адрес, чтобы прописать его в настройках NPort. Мы забыли, что в запросе, который посылает и контроллер и компьютер с программой ModPoll есть не только порт назначения, но и порт источника. Логично было бы отвечать по этому адресу источника. Провёл эксперимент. Запустил программу WireShark, которая мне позволила посмотреть содержимое посылок по IP. Подсмотрел там порт источника и прописал его в настройках как destination port. Порт оказался совсем дурацкий: 55719. И обмен пошёл. Но если я перезапускаю программу ModPoll (разрываю связь и вновь восстанавливаю), то этот порт будет уже другой. А, значит обмена вновь нет. Логично было бы в настройках NPort ввести режим, когда destination port задаётся не фиксированным, а берётся из посылки-запроса. Не знаю, почему "прыгает" порт в запросе, и, наверное, тоже самое происходит с контроллером. Так что пытаться найти и прописать этот destination port дело бесполезное. Вывод печальный: NPort не поддержиает стандартный обмен по UDP. Может быть вы можете предложить альтернативные варианты? Задача простая: у контроллера есть Ethenet порт, спомощью которого надо опросить, скажем, 8 устройств по COM-портам. Устройства умеют "говорить" только по протоколу Modbus RTU. Контроллер может работать в следующих режимах: Modbus/TCP, Modbus RTU over UDP. Спасибо за внимание.

Прикладываю скрины обоих режимов. MOXA1.doc

Добрый день. На время забудем про контроллер. Есть компьютер с установленной программой Modbus Poll. По сети ETHERNET он связан с NPort. К COM-порту NPort по RS-485 подключено устройство с Modbus-протоколом. Реализовывал 2 режима работы NPort: 1. UDP Mode. При этом в Modbus Poll задавал связь Modbus RTU over UDP/IP. Устройство отвечает на запросы, приходящие с COM-порта (подключил осциллограф), но до компьютера ответы не доходят: программа выдаёт ошибку тайм-аута. 2. TCP Server Mode. При этом в Modbus Poll задавал связь Modbus RTU over TCP/IP. В этом режиме компьютер получает ответы, идёт полноценный обмен информацией. Почему не приходят ответы в первом случае?

Для увеличения количества COM-портов контроллера планируется использовать NPort IA-5250. Программное обеспечение контроллера предлагает только режим Modbus over UDP. Вижу, что запрос от контроллера на COM-порт пришёл, устройство ответило, а контроллер от NPort посылку не получает - выдаёт тайм-аут готовности. Проверил связь с NPort от компьютера с помощью программы Modbus Poll: При задании в программе связи Modbus over TCP (NPort - в режиме TCP Server Mode) обмен идёт нормально: вижу код отправленный и код полученный. При задании в программе режима Modbus over UDP (NPort - в режиме UDP Mode) ответа не получаю. Что-то надо изменить в настройках?