Помогите пожалуйста очистить COM PORT

Какой-то шайтан, подменяет принятые данные на ноуте. Причём умудряется правильно сделать CRC для ответа. Не думаю что длина стоп-бита так каждый раз чЁтко подигрывает. Да много чего ещё. Но не тот CRC не должен быть принят программой. Хорошим тоном так же будет, что Master знает что и кому послал и ожидает ответ на свой запрос. Иначе это коллизия. Если Мастер самодельный ищите в нём.

 

Куда читает COM-порт? В буфер?

Код (C++):

....
memset(&rxbuf[0], 0, sizeof(rxbuf));
cntrx = 0;
....

Само устройство без FIFO
Точно анализ есть? Точно?
Чистить буфер ВЕСЬ не только после приёма, но и при П1 и П2 - любая ошибка обмена сразу чистка. Именно обмена а не разбора выполнения.
БУФЕР не циклический. Каждый приём пакета с начала буфера.
Чистка буфера до начала анализа:
- Не совпадение CRC
- П1 и П2 после анализа размера на соответствие
- Не соответствие команды и адреса

 

У меня на работе аналогичная по виду. Что в Linux, что в Windows (но туда надо ставить дрова) работает изумительно с промышленными ведомыми.

 

Попробую еще раз описать проблему в самом простом варианте, чтобы не искать проблему в скаде или ардуине.
Использую только Hterm и подключаю к ЮСБ конвертер ЮСБ-RS485. То есть не использую скаду и ардуину. На ноутбуке у которого нет проблемы при отправке запроса просто уходит запрос и ничего не приходит, так как нет подключенного устройства, которое смогло бы ответить. Это правильная работа СОМ порта. На ноутбуке с проблемой (согласен без Шайтана не обошлось) при отправке запроса с Hterm в конвертер ЮСБ- RS485 считываются какие-то значения, по факту это мусор так как ничего не должно считываться, ведь никакое устройство не отвечает на запрос. Откуда в СОМ порте берутся данные - не могу понять. Если этот мусор перестанет приходить, то все будет нормально работать. Мусор появляется где-то между Hterm -сом порт и конвертер ЮСБ-RS485. При этом настройки на рабочем ноуте и на проблемном одинаковые.

 

"Сквозной канал" иногда такое используется... это когда на мастере принимаются им же отправленные данные, а так же принимаются данные ответа от устройства - бывает и такой опциональный программный контроль. Эта опция есть? Он как правило для отладки. В гипертерминале это аналог эха.

 

Данные которые считываются Hterm после запроса отличаются от отправленной посылки. Специально не настраивал эхо - даже не знаю как это сделать. Прилагаю скрин с настройками Hterm с отправленным запросом и полученным ответом.

 

Наверное у Вас подключено всё к линии. Если поставите резистор 270 Ом(терминатор я ставлю 470...270 Ом) межлу линиями A и B(в самой дальней точке от мастера) . Согласно RS485... потому как переход через 0 на линии это смена уровня. Без этого резистора я не могу настроить устройства OWEN - просто устройство не отвечает. На самом деле на этих устройствах нет уровня (измерял) в режиме молчания. Это наблюдалось на подобном устройстве и ещё на ADAM USB-RS232/422/485. А вот порты MOXA IA240LX/UC7101LX/UC7112LX-PLUS такой резистор нужен был на длинных линиях и/или высокой скорости. Я увидел у Вас на картинке 0xFE и т.п. То есть преобладание уровня. Уточните по напряжениям, но попробуйте резистор.