Ошибка BAD COMM FAILURE LIMIT OK

[vorobev22rus]

Добрый день! Опрашиваю два одинаковых ПЛК РИДАН через шлюз Овен МКОН (10.4.15.26). Один с адресом 246 - читается верно, другой с адресом 247 ошибки "Bad comm failure limit OK" по нескольким булевым переменным (т.е. регистры зеркальные и на одном читаются на втором нет. Регистры 4724 4725 4737 4741 4911). В диагностике ошибки "Ответ от другого устройства" и "GATEWAY TARGET DEVICE FAILED TO RESPOND (11)"
Приехал на объект пробовал подключаться через СОМ - все читается на 247 - верно. Затем подключился только к 247 ПЛК через шлюз МКОН, стали возникать ошибки - "несовпадение количества бит в ответе". Пробовал: менять задержку пакетов на шлюзе, межбайтовый интервал в настройках канала ОРС, задержку в настройках канала ОРС, убирать/добавлять подтягивающие резисторы(программные) на ПЛК и шлюзе, убирать/добавлять терминирующие резисторы на ПЛК и шлюзе. Пробовал опросить через qModMaster - тоже не читает эти регистры.
НО заметил пока переключал резисторы на ПЛК (программно): когда значение 1 в регистре - считывается верно, когда 0 - ошибка по Timeout. Попробовал включить в работу контур, чтобы на этих регистрах изменились значения с False на True. Значения меняются, но ошибки по несовпадению количества бит, и соответственно - плохое качество тега сохраняется.
Подскажите что еще можно проверить?
Во вложении логи текущие, логи опроса только 247, настройки шлюза, канала, скриншот работы ОРС в настоящее время

[arOPC]

Добрый день!

1. Ошибка "Ответ от другого устройства" это из=за того, что в настройках канала связи, выставлен маленький таймаут.
Т.к. вы через шлюз работаете, необходимо увеличить его, хотя бы до 1000 мс. Задержку можно обнулить и выставить межбайтовый интервал, например, в 10 мс.

2. Ошибку "GATEWAY TARGET DEVICE FAILED TO RESPOND (11)" в файле только для 247 не видел. А в общем файле нет обмена с приборами, нужен обмен.

3. Ошибка "несовпадение количества бит в ответе".
Там на самом деле некорректное поведение, со стороны прибора (или шлюза).

20.05.2025 16:08:22.956;TC_Loco_MKON;10.4.15.26:502;SEND;12;0B 00 00 00 00 06 F7 02 13 2F 00 01
20.05.2025 16:08:23.002;TC_Loco_MKON;10.4.15.26:502;REC;9;0B 00 00 00 00 03 F7 02 01
20.05.2025 16:08:23.018;APPLICATION;Устройство "ITP_Loco_A2": Несовпадение количества бит в ответе..

Если смотреть на трассировку, в ответе не хватает одного байта
По факту: 0B 00 00 00 00 03 F7 02 01
Должно быть (например): 0B 00 00 00 00 04 F7 02 01 00

Если напрямую, по проводу, всё работает, значит такие искажения шлюз вносит.
Возможно ошибка "GATEWAY TARGET DEVICE FAILED TO RESPOND (11)", так же его рук дело. Но это надо трассировку смотреть.

Айрат

[vorobev22rus]

Настройки канала изменил, первая ошибка пока не наблюдается. Прошу подсказать как посмотреть трассировку, и на что я должен обратить внимание. Или разговор про TCP/IP (команда tracert)?

Если напрямую, по проводу, всё работает, значит такие искажения шлюз вносит. Возможно ошибка "GATEWAY TARGET DEVICE FAILED TO RESPOND (11)", так же его рук дело. Но это надо трассировку смотреть.

Я думаю если бы проблема был в шлюзе, то скорее всего на обоих контроллерах были схожие проблемы

[arOPC]

Прошу подсказать как посмотреть трассировку, и на что я должен обратить внимание.

Нужен такой же лог, с OPC сервера, как только для 247, но в котором есть обмен с обоими контроллерами.
Если вы знаете Modbus протокол, там сразу будет видно несоответствие, если нет я посмотрю это дело.

Приехал на объект пробовал подключаться через СОМ - все читается на 247 - верно. Затем подключился только к 247 ПЛК через шлюз МКОН, стали возникать ошибки

Вы писали, что при прямом подключении всё работает, а через шлюз пошли ошибки. Если для контроллера, по существу, ничего не поменялось и работает он так же на 485, то между OPC сервером и контроллером появилось дополнительное звено и пока, предположительно, искажение вносит оно.
Почему такое не происходит с другим контроллером, без логов с трассировкой, сказать невозможно.

Айрат

[vorobev22rus]

Согласен. Почистил все логи, записал новые. Покопался в запросах/ответах: на некоторые запросы по этим регистрам (проблемы с регистрами 4724 4724 4737 4741 4911) как будто вообще нет ответа, или я так смотрел. Если не сложно, посмотрите опытным глазом (канал - TC_Loco_MKON;10.4.15.26,   246 адрес -все хорошо, на 247 - ошибки по регистрам выше).

[vorobev22rus]

Вот те же логи, очищенные от остального оборудования (первые 8 секунд), я думаю по ним уже видно будет

[arOPC]

Пока всё равно непонятно.
У 247 данные читаются только для адресов которые начинаются с 10

21.05.2025 16:55:03.166;TC_Loco_MKON;10.4.15.26:502;SEND;12;FC 01 00 00 00 06 F7 02 10 E5 00 02
21.05.2025 16:55:03.212;TC_Loco_MKON;10.4.15.26:502;REC;10;FC 01 00 00 00 04 F7 02 01 02
21.05.2025 16:55:08.008;TC_Loco_MKON;10.4.15.26:502;SEND;12;07 07 00 00 00 06 F7 01 10 F0 00 01
21.05.2025 16:55:08.071;TC_Loco_MKON;10.4.15.26:502;REC;10;07 07 00 00 00 04 F7 01 01 01

Это норма

А адреса которые начинаются с 12 или 13 уже ошибочный приходит ответ

21.05.2025 16:55:05.321;TC_Loco_MKON;10.4.15.26:502;SEND;12;26 04 00 00 00 06 F7 02 12 74 00 02
21.05.2025 16:55:05.399;TC_Loco_MKON;10.4.15.26:502;REC;9;26 04 00 00 00 03 F7 02 01
21.05.2025 16:55:06.180;TC_Loco_MKON;10.4.15.26:502;SEND;12;29 05 00 00 00 06 F7 02 13 2F 00 01
21.05.2025 16:55:06.243;TC_Loco_MKON;10.4.15.26:502;REC;9;29 05 00 00 00 03 F7 02 01

Странно то, что Modbus TCP заголовок сформирован корректно, а вот сам ответ нет, не хватает одного байта. И сформирован Modbus TCP заголовок именно на некорректный ответ.
Тут может быть три варианта, на вскидку:
1. Шлюз не принимает до конца ответ от контроллера и раньше времени пересылает его в сеть. Но, судя по всему, он преобразует из Modbus RTU в Modbus TCP и должен проверить контрольную сумму, прежде чем пересылать, а без приёма полного пакета, контрольная сумма не совпадет и такой ответ не должен пересылаться в сеть. Маловероятно. Ну или он реально не проверяет.
2. Контроллер не отвечает нормально и присылает пакет не совсем тот. Но у него, при прямом подключении, всё корректно работает, а значит эта версия так же не подходит.
3. Какой то баг в ПО шлюза.

Вы же напрямую опрашивали контролер, попробуйте подцепиться к 485 линии преобразователем, на прослушку. И посмотреть, что реально на 485 линии происходит.

[vorobev22rus]

Добрый день!
На объекте встал параллельно 485 на прослушку, результат:
При опросе 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)

При чтении этого же регистра (4911) через COM port, ответ уже 6 байт, т.е. правильный ответ - шесть байт

Код

22.05.2025 17:27:49.151;Канал №1;COM3;SEND;8;F7 02 13 2F 00 01 98 11
22.05.2025 17:27:49.214;Канал №1;COM3;REC;6;F7 02 01 00 92 00

Даже не знаю что теперь делать...

[arOPC]

Добрый день!

Код

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]

Такого рода расшифровка каким ПО выдаётся?

Нашел на "просторах" скрипт на Python для прослушки СОМ (гуглится по "Modbus RTU Sniffer" на GitHub). Не знаю можно ли здесь оставлять ссылки. Мне понравился.

[arOPC]

А покажите сам пакет, на основе которого он такой вывод сделал.

Айрат

[vorobev22rus]

Есть пакет Modbus TCP. Должен быть подобный (т.к. метку времени Python свою ставит с опозданием не стал сильно копаться)
22.05.2025 16:41:02.959;TC_Loco_MKON;10.4.15.26:502;SEND;12;31 04 00 00 00 06 F7 02 13 2F 00 01
22.05.2025 16:41:02.991;TC_Loco_MKON;10.4.15.26:502;REC;9;31 04 00 00 00 03 F7 02 01
22.05.2025 16:41:03.007;APPLICATION;Устройство "ITP_Loco_A2": Несовпадение количества бит в ответе..

[arOPC]

Нет, это не то.
Эти пакеты мы уже видели.
Мне нужен пакет, в чистом виде, который прошёл по 485 линии.
Вы включили преобразователь на прослушку, любым терминалом (не используя эту библиотеку) просто записать пакет, без расшифровки.
У меня уже есть предположение, но без настоящего пакета, в чистом виде, я не могу его подтвердить.

Айрат.

[vorobev22rus]

Сейчас не получится. Теперь уже на следующей неделе поеду на объект, попробую сырые значения снять. Через терминал надо сделать?
Каким ПО? Чтобы наверняка Вы увидели то, что хотите увидеть (то что умеет параллельно 485 шлюза слушать)

[arOPC]

Добрый день!

Да, хотя бы этим.
https://sourceforge.net/projects/serial-port-terminal/

Самое главное что бы данные было видно.

Айрат