МКОН. Ошибка в прошивке конвертора. Возникает если в CRC16 нулевой старший байт.

[Eznamos]

Устройство: МКОН-24 H/W 2.0
Версия ПО: g2.43
Сер.номер: 116100240232065411
Дата пр-во: 02.2024

Собран стенд:
ПК1 <--- ethernet ---> МКОН <--- rs485 ---> ПК2, где
ПК1 - Master
ПК2 - Slave (ID=17)

ПК1 спрашивает у ПК2 один InputStatus (FC=02), по адресу (0).

Из журналов обмена:

Запрос ТСР от ПК1 к МКОН:   00 00 00 00 00 06 17 02 00 00 00 01
Запрос RTU от МКОН к ПК2:   17 02 00 00 00 01 BB 3C
Ответ RTU от ПК2 к МКОН:    17 02 01 01 64 00
Ответ TCP от МКОН к ПК1:    00 00 00 00 00 03 17 02 01

Рассмотрим подробнее Ответ TCP от МКОН к ПК1:
00 00 00 00 00 03 - это номер транзакции, код протокола, длина пакета
17 наш идентификатор
02 код фунции
01 длина данных
и всё

Обратим внимание что в ответе от МКОН нет байта с данными (т.е. пакет после преобразования приходит без данных).
После серии экспериментов установил, что в некоторых случаях ответ приходит на один байт короче, чем должен.
Естественно, мастер такой пакет считает некорректным, и обмен заканчивается ошибкой.
Из-за этого мастер может зависнут, зациклится ну или просто будет "иногда говорить", что связь, то есть, то нет.

Почему же так происходит, спросит внимательный читатель?

Проведя серию экспериментов выяснил, что эта ситуация возникает, если в ответе у (CRC16) старший байт равен 0.
Для нашего примера (см. Ответ от ПК2 к МКОН) 17 02 01 01, CRC16 = 0x0064 (в порт пишется старшим байтом вперед)

При этом "Сниффер" овен конфигуратора пишет:

1	19:32:50.595	Ethernet: master	RS-485: Slave	Modbus TCP (PDU) -> Modbus RTU	32	Запрос		17 02 00 00 00 01 BB 3C	Slave ID: 0x17 (23)	Код функции: 0x02 (2) - Read Discrete Inputs	Адрес регистра: 0x0000 (0)	Количество регистров: 0x01 (1)	Контрольная сумма: 0xBB3C (47932)
2	19:32:50.886	RS-485: Slave	Ethernet: master	Modbus RTU -> Modbus TCP (PDU)	27	Ответ	Ошибка Modbus. Код: 1 - Устройство не может обработать код функции.	17 02 01	Slave ID: 0x17 (23)	Код функции: 0x02 (2) - Read Discrete Inputs	Код ошибки: 0x01 (1)

Данная ошибка воспроизводится всегда, когда в конце ответа в RS линии стоит "0", отдельно хочу заметить, что я не исследовал, что произойдет, если "0" будет стоять в конце запроса в RS линии предполагаю, что тоже ничего хорошего).

О данной проблеме я сообщил в службу тех. поддержки 14.06.2024 (так же подробно, даже более). До сих пор нет решения, и даже подтверждения, что работа над устранением ведется.

Далее все тоже самое в картинках:
Запрос ТСР от ПК1 к МКОН: 00 00 00 00 00 06 17 02 00 00 00 01
Wireshark_Request.png
Запрос RTU от МКОН к ПК2: 17 02 00 00 00 01 BB 3C
Ответ RTU от ПК2 к МКОН: 17 02 01 01 64 00
sideRS485.png
Сниффер
OwenConfig_Request_Response.png
Ответ TCP от МКОН к ПК1: 00 00 00 00 00 03 17 02 01
Wireshark_Response.png

[melky]

все очень странно, учитывая, что в Modbus протоколе всегда известна длина пакета.

[EFrol]

Она становится известной не сразу. Надо какую-то часть сначала принять и обработать, чтобы понять сколько и чего будет в пакете ещё.
А ведь конец пакета определяется по таймауту в 3.5 байта (по стандарту). Передатчик (промежуточное устройство) чуть замешкался и вот приемник ловить уже два пакета.
И если первый пакет короткий (без длины данных), то замучаешься осколки собирать.

[Eznamos]

Дело не в таймаутах или скорости обмена и т.п. Это происходит только при нулевом байте в CRC.
Я даже могу предположить, а при наличии исходников прошивки, на любом языке, указать точное место, где ошибся программист прошивки.
Всё дело в работе со строками в языках программирования. Библиотечные функции по работе со строками считают "\0" концом строки.
Скорее всего, что "ошибка" происходит в одной из библиотечных функций (по сути это и не ошибка) просто особенность её работы, о которой не подумал программист.
Сам такой. Написал реализацию нескольких протоколов для разных устройств и по "таким" граблям тоже ходил.
Расстраивает, что ТП не реагирует, когда так подробно им пишешь, тратя свое время ((.

[melky]

EFrol она известна на этапе запроса, так как мы запрашиваем Х регистров, а не "дай нам что-нибудь"

[capzap]

Дело не в таймаутах или скорости обмена и т.п. Это происходит только при нулевом байте в CRC.
Я даже могу предположить, а при наличии исходников прошивки, на любом языке, указать точное место, где ошибся программист прошивки.
Всё дело в работе со строками в языках программирования. Библиотечные функции по работе со строками считают "\0" концом строки.
Скорее всего, что "ошибка" происходит в одной из библиотечных функций (по сути это и не ошибка) просто особенность её работы, о которой не подумал программист.
Сам такой. Написал реализацию нескольких протоколов для разных устройств и по "таким" граблям тоже ходил.
Расстраивает, что ТП не реагирует, когда так подробно им пишешь, тратя свое время ((.

а с чего Вы решили что работа со строками должна быть, по сути там просто к пришедшему набору байт добавляется в начало служебная информация из шести байт и отбрасывается контрольная сумма, зачем там строки?
Формат ответа ТСР правильный, хоть и не верный и не ожидаемый, скорее всего он напоминает ответ ошибки, если вместо 02 будет стоять 82. То что там последние нули не обрабатываются, так это на стадии расчета контрольной суммы для проверки выяснилось бы, тут просто надо знать как выглядит ответ с ошибкой CRC, это могут сделать обладатели МКОН-а. Ну и второй момент это есть ли проверка CRC или шлюз сразу отправляет транзитом данные, тогда в этой функции не верно рассчитывается объем данных всего пакета, возможно из-за наличия нуля в последнем байте

[Pavel5698]

Расстраивает, что ТП не реагирует, когда так подробно им пишешь, тратя свое время ((.

А вы написали им на почту? Для Овена форум, как я понял, - последний канал связи куда они смотрят. Можете написать и просто дать ссылку на свой пост

[Eznamos]

А вы написали им на почту? Для Овена форум, как я понял, - последний канал связи куда они смотрят. Можете написать и просто дать ссылку на свой пост

Конечно написал:

О данной проблеме я сообщил в службу тех. поддержки 14.06.2024

[Eznamos]

capzap, Вы немного не разобрались. В причине. TCP сторону можете пока не рассматривать там уже никаких CRC нет, ошибка возникает до отправки ответа МКОНом в TCP об этом говорит ошибка в сниффере самого МКОН (он тоже не смог разобрать неполный пакет), о чем сообщил в журнал.

CRC считается верно, просто она 0x0064 в данном примере, 
далее прошивка "получает" пакет 17 02 01 01 64 00, 
по какой-то причине, далее в обработчик передаётся пакет на один байт короче 17 02 01 01 64, 
от которого затем откусывается CRC16 (два байта) и остается уже 17 02 01

которые уже обрабатывает сниффер, и к которым уже добавляется TCP обвязка.

Я проводил разные эксперименты, "теряется" всегда этот байт даже если в ответе будет много байт данных, главное условие чтобы CRC16 была меньше или ровна 0x00FF.

[capzap]

capzap, Вы немного не разобрались. В причине. TCP сторону можете пока не рассматривать там уже никаких CRC нет, ошибка возникает до отправки ответа МКОНом в TCP об этом говорит ошибка в сниффере самого МКОН (он тоже не смог разобрать неполный пакет), о чем сообщил в журнал.

CRC считается верно, просто она 0x0064 в данном примере, 
далее прошивка "получает" пакет 17 02 01 01 64 00, 
по какой-то причине, далее в обработчик передаётся пакет на один байт короче 17 02 01 01 64, 
от которого затем откусывается CRC16 (два байта) и остается уже 17 02 01

которые уже обрабатывает сниффер, и к которым уже добавляется TCP обвязка.

именно про выводы снифера в первой части я и говорилScreenshot 2024-09-24 145129.pngв ПК должна прийти ошибка, а приходит функция 02 которая возможно совпадает с ожидаемым ответом и вводит Вас в заблуждение, если есть эксперименты где последний байт не будет равен единице, выложите