Ошибка BAD COMM FAILURE LIMIT OK

[vorobev22rus]

Добрый день! Данные соответственно собираю во время штатной работы: ПЛК-ШЛЮЗ-ОРС? Или ПЛК-СОМ-ОРС тоже нужны пакеты?
Сейчас проверил: почему то только ответы фигурируют в терминале. Каких либо настроек не нашел как включить запросы в логи

[arOPC]

Проблема только в конфигурации ПЛК-ШЛЮЗ-ОРС наблюдается.
Этого будет достаточно.

Айрат

[vorobev22rus]

Логи снял (по несколько секунд), но похоже на какую то ерунду... По крайней мере я не понял, даже где адрес слейва. Log_GVS - горячая вода (контроллер 247 - по этим регистрам все хорошо).  Log_SV - система вентиляции (контроллер 247 - проблемы с регистрами 4724,4725,4741,4737,4911)

[arOPC]

Да, это какая то ерунда.
С настройками не ошиблись, скорость и т.д?

Айрат

[vorobev22rus]

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

[vorobev22rus]

Сегодня доехал еще раз - снял дамп, сегодня все вроде нормально (не считая, что не пойму почему в ответах адрес как будто одинаковый). Во вложении SO- контроллер с адр 246 (на нем читаются без ошибок 4724 4725 4737), SV - контроллер с адр 247 (читаются с ошибками 4724 4725 4737 + 4911, 4741)

[arOPC]

Добрый день!

Всё равно с искажениями, видимо с настройками что то не то.
Но данные видно и это достаточно.
Судя по обмену, по 485 интерфейсу всё хорошо.

Код: pascal

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 - ответ от прибора

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

По факту на линии вот такие данные:

Код: pascal

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 линии, напрямую, а шлюз нет.

Думаю вам, с этой проблемой, необходимо обратиться в поддержку производителя шлюза.

[vorobev22rus]

Возможно, но у меня не складывается в голове, почему на первом контроллере (адр 246), шлюз этого не делает?

Код: pascal

27.05.2025 11:23:45.183;TC_Loco_MKON;10.4.15.26:502;SEND;12;0B 00 00 00 00 06 F6 02 12 74 00 02
27.05.2025 11:23:45.214;TC_Loco_MKON;10.4.15.26:502;REC;10;0B 00 00 00 00 04 F6 02 01 00

[arOPC]

Дело в контрольной сумме.

Если брать пакет с 246
Полный пакет будет F6 02 01 00 93 FC, где 93 FC это CRC
Если рассчитать для неполного F6 02 01, то CRC = 51 52
Последовательности цифр 51 52 в исходном пакете нет, поэтому он рассчитывает до конца, а там CRC совпадает.

Если брать пакет с 247
Полный пакет будет F7 02 01 00 92 00, где 92 00 это CRC
Если рассчитать для неполного F7 02 01, то CRC = 00 92
Последовательность цифр 00 92 в исходном пакете идет сразу после 01, шлюз принимает это за совпадение CRC и останавливается, игнорируя крайний байт.

Айрат

[vorobev22rus]

Айрат, вы абсолютно были правы!!! И, как оказалось, совпадение CRC и содержимое пакета возникает именно на адресе 247 (подсказали ребята на другом форуме). Заменил адреса на 4 и 5 и проблема решилась. Еще подсказали попробовать перестроить режим "прозрачный шлюз" на МКОН и Modbus поверх TCP в ОРС - тоже все ровно, проверил(с адресом 247 в том числе). Искренне благодарю вас за отношение к своему делу! Век живи, век учись как говорится.

[arOPC]

Добрый день!

Рад, что разобрались.
Но заменой адресов проблема, на самом деле, не решена. Это просто маскировка, на текущий момент.
Я всё таки рекомендовал бы обратиться к производителю, что бы прошивку поправили.
В таком виде, используя как преобразователь протоколов, на более менее серьёзном объекте, использовать его нельзя.
Такое совпадение может возникнуть на любом адресе, особенно если речь идёт о больших пакетах с постоянно меняющимися данными.

Айрат

[vorobev22rus]

Да я им написал, описал ситуацию и приложив выводы сделанные Вами

[Gleb]

Добрый день, коллеги!

У меня похожая ситуация, стоит  МКОН, за ним два устройства. по отдельности через ОВЕН OPC и через arOPC опрашиваются нормально, вместе с ошибками. Ответ ТП Овна - "МКОН не поддерживает больше 2х (одного) TCP соединений. А OwenOPC для каждого slave за МКОН, создает свое отдельное соединение." может ли arOPC создавать одно соединение для двух устройств?

В MasterOPC все работает нормально, но там стоимость кусается....

Спасибо!

[arOPC]

Добрый день!

Да, arOPC так может работать.
Заведите один канал, с IP адресом МКОН и привяжите его, к каждому из опрашиваемых устройств, в arOPC.

Айрат

[Gleb]

 Спасибо!

Надо создать канал -клиент или канал -сервер?