В продаже МКОН - преобразователь протокола Modbus!

[vorobev22rus]

значит стоит найти нормальный просмотрщик RS485, потому что
11:23:55 RX : [HEX] 3f 2 12 74 0 2 3f 3f
и
11:14:25 RX : [HEX] 3f 2 12 3f 0 1 3f c
как бы Вы не писали что обращение к разным адресам, в лог пишется как будто идет обращение на один и тот же адрес 3f что не верно как по сути обмена двух слейвов, так и по контрольным суммам

Например так:

При опросе bool регистров контроллера с адресом 246 ответ полноценный, например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:25:37.602401 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 2
CRC: 61097 (OK)
Packet: MODBUS Response (packet size: 6, data size: 2), 2025‐05‐22 16:25:37.714816 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 8
Values: Input0: 0 Input1: 0 Input2: 0 Input3: 0 Input4: 0 Input5: 0 Input6: 0 Input7: 0
CRC: 64659 (OK)

При опросе bool регистров (по контуру ГВС) контроллера с адресом 247 ответ полноценный, например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:33:21.138886 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4325
Quantity: 2
CRC: 27384 (OK)
Packet: MODBUS Response (packet size: 6, data size: 2), 2025‐05‐22 16:33:21.342707 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4325
Quantity: 8
Values: Input0: 1 Input1: 0 Input2: 0 Input3: 0 Input4: 0 Input5: 0 Input6: 0 Input7: 0
CRC: 49235 (OK)

А вот при опросе bool регистров (по контуру вентиляции) того же контроллера с адресом 247 ответ меньше на 1 байт (байт с данными), например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:39:39.603747 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4911
Quantity: 1
CRC: 4504 (OK)
Packet: MODBUS Response (packet size: 5, data size: 1), 2025‐05‐22 16:39:39.780263 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
CRC: 37376 (OK)

[vorobev22rus]

значит стоит найти нормальный просмотрщик RS485, потому что
11:23:55 RX : [HEX] 3f 2 12 74 0 2 3f 3f
и
11:14:25 RX : [HEX] 3f 2 12 3f 0 1 3f c
как бы Вы не писали что обращение к разным адресам, в лог пишется как будто идет обращение на один и тот же адрес 3f что не верно как по сути обмена двух слейвов, так и по контрольным суммам

PS и не поленится, сменить адреса слейвов на первый десяток

Просмотр 485 через терминал - убедиться в одинаковом количестве байт в ответе
Так как на предыдущем дампе (который с описанием) видно, что на 247 на некоторых регистрах на 1 байт меньше ответ. Т.е. по предположению тех.поддержки ОРС - скрипт Python также как и МКОН исчисляет СRC не дождавшись всего пакета и игнорирует последний нулевой байт
На дампе Modbus TCP - ответ тоже короче на 1 байт

[imaex]

Видно только что на этих регистрах на один байт информации меньше (Modbus TCP) - соответственно качество тега становится в BAD. На пакетах Modbus RTU - вроде все нормально.
...
Есть какие нибудь мысли?

Есть. Если эта модель МКОН поддерживает прозрачный режим, то попробовать переключиться на него. И на стороне OPC-сервера переключиться на Modbus RTU over TCP вместо Modbus TCP. На худой конец виртуальный COM-порт создать, там уж чистый RTU.

Если нет, то приобрести адекватный шлюз вместо этого. Адекватный - это не про МКОН.

Вчитываться в выкладки по байтам с подсчётом CRC мне просто лень, извините.

[capzap]

Packet: MODBUS Response (packet size: 5, data size: 1), 2025‐05‐22 16:39:39.780263 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
CRC: 37376 (OK)

проблема не в МКОНе а в слейве, 37376 получается от контрольной суммы 9200, а ответный пакет должен быть таким F7 02 01 00 92 00, что означает что сумма в DEC должна считаться от 0092, поэтому и ошибка. И как я говорил проверить такую же ошибкы можно было бы и в первом слейве по адресу 246

[vorobev22rus]

Есть. Если эта модель МКОН поддерживает прозрачный режим, то попробовать переключиться на него. И на стороне OPC-сервера переключиться на Modbus RTU over TCP вместо Modbus TCP. На худой конец виртуальный COM-порт создать, там уж чистый RTU.

Если нет, то приобрести адекватный шлюз вместо этого. Адекватный - это не про МКОН.

Вчитываться в выкладки по байтам с подсчётом CRC мне просто лень, извините.

Мкон так не умеет насколько я понимаю, он как раз преобразует Modbus RTU/Modbus TCP. Адекватный это какой? На старом предприятии МОХА была в приоритете (не помню проблем), на этом - бюджеты скромнее

[vorobev22rus]

проблема не в МКОНе а в слейве, 37376 получается от контрольной суммы 9200, а ответный пакет должен быть таким F7 02 01 00 92 00, что означает что сумма в DEC должна считаться от 0092, поэтому и ошибка. И как я говорил проверить такую же ошибкы можно было бы и в первом слейве по адресу 246

Вы про это:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22
16:25:37.602401 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 2
CRC: 61097 (OK)
Packet: MODBUS Response (packet size: 6, data size: 2), 2025‐05‐22
16:25:37.714816 +0.000000
Mode: RTU Mode
Address: 246 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4724
Quantity: 8
Values:Input0: 0 Input1: 0 Input2: 0 Input3: 0 Input4: 0 Input5: 0 Input6: 0 Input7: 0
CRC: 64659 (OK)

Так ошибок нет

[capzap]

А вот при опросе bool регистров (по контуру вентиляции) того же контроллера с адресом 247 ответ меньше на 1 байт (байт с данными), например:
Packet: MODBUS Request (packet size: 8, data size: 4), 2025‐05‐22 16:39:39.603747 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
Starting Address: 4911
Quantity: 1
CRC: 4504 (OK)
Packet: MODBUS Response (packet size: 5, data size: 1), 2025‐05‐22 16:39:39.780263 +0.000000
Mode: RTU Mode
Address: 247 (Slave)
Function: 2 (Read Discrete Inputs)
CRC: 37376 (OK)

здесь опрашивается адрес 4911 по одной катушке, ответ в отличии от остальных не печатает ни Starting Address ни Quantity ни Values, сразу переходит к контрольной сумме которая не верная

ЗЫ поставте адреса 4 и 5 и проблема должна уйти

[imaex]

Мкон так не умеет насколько я понимаю

Возможно я перепутал чего, но, вроде бы тут кто-то утверждал, что в новых версиях есть. Не буду спорить.

Адекватный это какой?

Работающий и (желательно) дешевле МКОН. Тот же usr-iot посмотрите, если совсем дешёво (но работает). Или icp-das, тут в ту же цену, что и у МКОН, уложитесь.

Во: https://docs.owen.ru/product/mkon/579/73003#topic-73013

Раздел "Режим прозрачного шлюза".

[vorobev22rus]

здесь опрашивается адрес 4911 по одной катушке, ответ в отличии от остальных не печатает ни Starting Address ни Quantity ни Values, сразу переходит к контрольной сумме которая не верная

Так собственно об этом я и создал пост. Предположение Тех.поддержки ОРС - мне кажется верным: и это ПО (с расшифровкой) и МКОН одинаково видят контрольную сумму и считают, что пакет закончился. Терминал же показывает что количество байт одинаковое и на 247 и на 246. Когда опрашиваю через СОМ порт напрямую - ошибок нет. Вопрос как сделать чтобы Шлюз дожидался весь пакет. Почему контрольная сумма неверная?

[vorobev22rus]

Возможно я перепутал чего, но, вроде бы тут кто-то утверждал, что в новых версиях есть. Не буду спорить.



Работающий и (желательно) дешевле МКОН. Тот же usr-iot посмотрите, если совсем дешёво (но работает). Или icp-das, тут в ту же цену, что и у МКОН, уложитесь.

Во: https://docs.owen.ru/product/mkon/579/73003#topic-73013

Раздел "Режим прозрачного шлюза".

Вот это уже какое то дельное предложение. Попробую...