Цитата:
Сообщение от ATS
Соответствует пакету Modbus RTU и Modbus поверх TCP
|
Modbus-RTU он не может соответствовать, т.к. поле данных обрамлено служебными полями TCP.
А вот "Modbus поверх TCP" - вполне. Т.к. налицо инкапсуляция.
Но тут нарушено главный принцип: устройства по оба конца провода должны играть по одним и тем же правилам. Контроллер ждёт Modbus-TCP и скармливать ему что-либо иное априори не имеет смысла.
Цитата:
Сообщение от ATS
Для протокола Modbus TCP выглядит следующим образом:
ид транзакции | ид протокола | длина пакета | адрес slave | код функции | данные
где
ид транзакции - два байта, обычно нули
ид протокола - два байта, нули
длина пакета - два байта - длина следующей за этим полем части пакета
адрес slave - адрес подчинённого устройства, к которому адресован запрос. Обычно игнорируется, если соединение установлено с конкретным устройством. Может использоваться, если соединение установлено с бриджом, который выводит нас, например, в сеть RS485.
Поле контрольной суммы в Modbus TCP отсутствует.
|
Ну вот вы и разобрались. Осталось только понять, при чём тут виртуальный COM-порт и зачем было его упоминать в самом первом сообщении
Вы ставили в пример
бридж MOXA DE-311, для которого (как и для других бриджей) "Modbus поверх TCP" и придуман
Понятное дело, что в этом случае он становится "Виртуальным СОМ-портом", т.к. драйвер всё приходящее в себя тупо запихивает в пакет TCP, приняв который MOXA DE-311 не менее тупо его выпихивает себе на разъём безо всякой обработки.
Но контроллер-то не бридж. И ему не нужно ничего никуда выпихивать.
Цитата:
Сообщение от ATS
Ответ однозначный - контроллер Modbus поверх TCP пока не поддерживает
|
Этот же вывод можно было сделать просто прочитав описание контроллера
