Работа TCP клиента

[manjey73]

2023-05-18 23:36:00 Сеанс связи с устройством [3] PulsarImpuls
Отправка (14): 00 10 12 86 01 0E FF 03 00 00 3F 92 34 A5
Приём (3/90): 01 00 F3
Ошибка: некорректная длина ответа!
Отправка (14): 00 10 12 86 01 0E FF 03 00 00 3F 92 34 A5
Приём (90/90): 00 10 12 86 01 5A 00 00 00 00 00 02 AB 40 66 66 66 34 33 33 0B 40 46 B6 F3 FD 54 25 90 40 CD CC CC CC CC 51 90 40 00 00 00 00 00 23 B4 40 66 66 66 66 66 75 93 40 5C 8F C2 F5 28 3C 38 40 D7 A3 70 3D 0A 87 8F 40 52 B8 1E 85 EB 8F 8F 40 00 00 00 00 00 F0 A2 40 3F 92 C7 C1
OK
Отправка (12): 00 10 12 86 0A 0C 06 00 AC 46 36 0B
Приём (18/18): 00 00 10 12 86 0A 12 00 00 00 00 00 00 00 00 AC 46 F1
Ошибка CRC
Отправка (12): 00 10 12 86 0A 0C 06 00 AC 46 36 0B
Приём (18/18): 7B 00 10 12 86 0A 12 00 00 00 00 00 00 00 00 AC 46 F1
Ошибка CRC
Получено за 3488 мс

Интересно, что через данный преобразователь другой прибор отработал несколько месяцев на этом же порту м этими же настройками. 5-ая версия и с данным прибором работала без нареканий (проверю чуть позже еще раз).

Да и по другим приборам заметил ухудшение работы.
На этом же драйвере другой прибор Пульсар, (с этим так же проверю позже) работает используя при этом софтовый преобразователь Rthernet-RS485 на Raspberry

Были ли какие-то изменения в коде в данной части, что могло повлиять? Летит тупо мусор, как правило в начале пакетов.
Преобразователь USR-IOT N520

[manjey73]

Приём (18/18): 00 00 10 12 86 0A 12 00 00 00 00 00 00 00 00 AC 46 F1
Ошибка CRC

Здесь например прилетел лишний 00

Приём (18/18): 7B 00 10 12 86 0A 12 00 00 00 00 00 00 00 00 AC 46 F1
Ошибка CRC

А тут 7B если убрать 00 а 7B прилепить к первому к хвосту первого ответа, то ответ корректный.

[manjey73]

Да, через обычный COM порт нареканий нет абсолютно

Галочка оставаться на связи не играет роли, что с ней, что без нее

• Ответ изменён 3 года, 3 месяца назад пользователем manjey73.

[manjey73]

За ночь ни одной ошибки при работе через COM порт

[Mikhail]

В журнале видно, что приходит лишний байт в начале ответа. Вопрос в том, откуда он берётся.

[manjey73]

он не лишний, он откуда-то из буфера. При этом запрос же идет например на 18 байт и хвост тогда обрезается. и если заняться подстановкой байта следующего запроса и удалением первого чудно весь пакет становится правильным.

Постараюсь сегодня проверить с 5-й версии через этот же преобразователь.

[Mikhail]

Сравнить работу в разных версиях будет полезно.
Если контроллер ответил больше байт, чем считали, то 1 байт останется в буфере и будет считан в следующий раз.

[manjey73]

Проверил на 5-й версии, тоже валятся ошибки. Ощущение что несовместимость прибора с преобразователем. На том же куске провода на столе (0,5м) через USB-RS485 работает, а через преобразователь нет…

сейчас поищу сопротивление 120Ом и попробую с ним…

[JurasskPark]

Проверил на 5-й версии, тоже валятся ошибки. Ощущение что несовместимость прибора с преобразователем. На том же куске провода на столе (0,5м) через USB-RS485 работает, а через преобразователь нет…

сейчас поищу сопротивление 120Ом и попробую с ним…

Не совсем по теме… Но мы неделю бились с Моксой в режиме TCP-cервера, потому что у преобразователя дергалась нога на приём сигнала, буфер преобразователя начинал готовить массив байт, потом понимал, что он пустой и отправлял null.
Короче, ставили драйвер виртуальный сом-порта и через него получали данные. Только как раз драйвер COM-порта не от MOXA, а от Usirot. Помогло. 🙂

[Mikhail]

Проверил на 5-й версии, тоже валятся ошибки.

Воспроизводимость ошибки — это плюс.
Помог ли резистор?

[manjey73]

еще не проверял, руки не дошли…
Виртуальный COM порт пробовал, но использовал Tibbo VPS Manager — не помогло.

[Автор]

Записи