Добрый день!
Всё равно с искажениями, видимо с настройками что то не то.
Но данные видно и это достаточно.
Судя по обмену, по 485 интерфейсу всё хорошо.
11:14:25 RX : [HEX] 3f 2 12 74 0 2 3f 3f - запрос от OPC сервера через шлюз
11:14:25 RX : [HEX] 3f 2 1 0 3f 0 - ответ от прибора
Видно, ответ полноценный, четыре байта пакета и два контрольная сумма.
По факту на линии вот такие данные:
F7 02 12 74 00 02 A8 3F - запрос от OPC сервера через шлюз
F7 02 01 00 92 00 - ответ от прибора
Хитрость здесь в контрольной сумме.
CRC для последовательности F7 02 01 00 = 92 00
CRC для последовательности F7 02 01 = 00 92
При получении ответа от прибора шлюз формирует следующий пакет:
00 00 00 00 00 03 F7 02 01
А должно быть
00 00 00 00 00 04 F7 02 01 00
Т.е. он отбрасывает крайний байт.
Причина здесь в том, что CRC пакета шлюз высчитывает по мере поступления байт с 485 линии, на лету, до тех пор пока не совпадет контрольная сумма, как только она совпала, он формирует Modbus TCP пакет и, с чистой совестью, отправляет его OPC серверу. Но, по факту, произошло ложное совпадение контрольной суммы, на не принятом до конца пакете.
Таким же образом работает и та тестовая программа, которой вы проверяли в первый раз.
OPC сервер так же на лету рассчитывает контрольную сумму, но помимо этого, он контролирует целостность пакета и если видит что пакет ещё не собран, даже если и совпала CRC, он продолжает дальнейший расчет.
Поэтому OPC сервер работает на 485 линии, напрямую, а шлюз нет.
Думаю вам, с этой проблемой, необходимо обратиться в поддержку производителя шлюза.
