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

[capzap]

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

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

[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 которая возможно совпадает с ожидаемым ответом и вводит Вас в заблуждение, если есть эксперименты где последний байт не будет равен единице, выложите

[Eznamos]

capzap Вас вводит в заблуждение короткий ответ, который похож на код ошибки, но это не так. в ПК должна прийти ошибка, если её сформирует slave. Ошибка 01 ILLEGAL FUNCTION должна быть сгенерирована slave. Задача конвертора её просто транслировать. Здесь проблема не в этом. Ошибки с кодами с 01 до 08 формирует slave, шлюз может формировать ошибки к кодом 0А, 0B (так говорит стандарт).

если есть эксперименты где последний байт не будет равен единице, выложите

Да такие пакеты есть и я их видел. Но это было 3 мес. назад, после чего я написал в ТП и оправил им логи и описание того, что происходит... и тишина..

Если Вы мне сформируете пакет (запрос) в ответ на который, должен прийти ответ с CRC16 < 0x0100 и будет содержать, то что Вы хотите увидеть, я не поленюсь и соберу стенд и выложу результат.

[capzap]

ответ на который, должен прийти ответ с CRC16 < 0x0100 и будет содержать, то что вы хотите увидеть, я не поленюсь и соберу стенд и выложу результат.

как по формированию запроса дискретных входов можно заранее знать какой ответ придет, вот Вам ответ который можно получить запрашивая 16 входов Screenshot 2024-09-24 161147.png, не знаю что Вам это даст

ЗЫ если речь шла про последний ноль то возможно так должны входы активироваться чтоб был последний ноль и ответ в случае ошибки не соответствовал коду 1 Screenshot 2024-09-24 162053.png