Разбор байт VISA

[Kosist]

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

[Andrew Lunev]

Часто приходится работать с приборами у которых похожий протокол. Но у вашего прибора есть серьезные отличия. Обычно в протоколе организуются хоть какие-то признаки начала и конца пакета и добавляется контрольная сумма по которой можно будет определить верно ли нашли пакет в потоке байт и верно ли идентифицировали каждый байт в пакете.
Например, каждый пакет может начинаться последовательности байт FF AA и потом 5 байт данных и в конце байт контрольной суммы.
Я не понимаю, как в вашем случае понять, что например байт A0 относится к Quality, а не к angle или distance? Даже если вы приняли пять байт, как определить, что все они на своем месте? Я вижу только вариант проанализировать бит S и инверсный ему, но такой вариант бит может появиться случайно в любом следующем байте просто как часть данных.
Читать данные на высоких скоростях по одному байту и анализировать этот байт не получится. Visa работает с большой загрузкой процессора и не успевает обрабатывать. Лучше всего вычитывать данные какими-то кусками и кидать в промежуточный буфер и там уже обрабатывать. Про это уже не раз написали выше.
Но я вижу главную проблему в том, что в потоке байт невозможно однозначно или хотя бы с высокой вероятностью определить начало и конец пакета.
P.S. Мне очень интересно, тот протокол, что вы указали это реальный протокол какого-то прибора, который разработан какой-то фирмой и продается за деньги или это "поделка школьника"? Ну не верю я, что в качественном приборе могли допустить реализацию подобного протокола. Или вы не все байты пакета показали в примере.

[dadreamer]

P.S. Мне очень интересно, тот протокол, что вы указали это реальный протокол какого-то прибора, который разработан какой-то фирмой и продается за деньги или это "поделка школьника"? Ну не верю я, что в качественном приборе могли допустить реализацию подобного протокола. Или вы не все байты пакета показали в примере.

Судя по всему, вот с этим аппаратом автору приходится иметь дело: RPLIDAR A2M8 360° Laser Scanner (или с аналогом) + мануал, откуда описание протокола взято. Да, получается, что ни терминатора, ни CRC там нет. Остаётся только анализировать первые 3 бита - S, S/ и C. Или же перейти на режим Express Scan, там по крайней мере есть два стартовых байта и чек-суммы, но формат посылки сложнее.

[ujin1]

P.S. Мне очень интересно, тот протокол, что вы указали это реальный протокол какого-то прибора, который разработан какой-то фирмой и продается за деньги или это "поделка школьника"? Ну не верю я, что в качественном приборе могли допустить реализацию подобного протокола. Или вы не все байты пакета показали в примере.

Судя по всему, вот с этим аппаратом автору приходится иметь дело: RPLIDAR A2M8 360° Laser Scanner (или с аналогом) + мануал, откуда описание протокола взято. Да, получается, что ни терминатора, ни CRC там нет. Остаётся только анализировать первые 3 бита - S, S/ и C. Или же перейти на режим Express Scan, там по крайней мере есть два стартовых байта и чек-суммы, но формат посылки сложнее.

В пакете название звучит как Format of the Data Response Packet. Предполагается ответ на какой-то запрос.
Даже если в приборе только один режим - отправлять данные без перерыва и без таймаутов можно попробовать привязаться к битам S, S/ и C в нескольких посылках. Так вероятность правильности приема увеличивается.
Например так

[Andrew Lunev]

Спасибо за описание прибора, с ним стало всё намного понятней. Вполне нормальная реализация протокола. Просто надо понимать для чего выбраны эти режимы и как их использовать.
В приборе реализованы два варианта работы. Потоковый, который вы пытаетесь реализовать, и по запросу, со всеми необходимыми стартовыми флагами и контрольной суммой, чтобы гарантировать получение корректных данных.
Потоковый вариант реализован для минимизации лишней информации в потоке данных, чтобы обеспечить максимальную скорость передачи по интерфейсу. Но надо понимать, когда его можно использовать. Этот вариант используется в том случае, когда вероятность ошибок в протоколе очень мала. Такой вариант реализуется, когда передатчик и приемник расположены в одном корпусе или вообще распаяны на одной плате. Расстояние между ними несколько сантиметров и все цепи хорошо согласованы и защищены от помех на этапе проектирования устройства.
Запуском и остановом потока управляет контролер, так что нет никаких проблем по синхронизации. В этом случае алгоритм работы следующий.
1. Очищаем буферы RS.
2. Отсылаем ЛИДАРу команду запуска потоковой передачи.
3. Ждем, когда в буфере накопится нужное нам количество данных. Мне кажется имеет смысл ждать одного полного оборота ЛИДАРа. Например он проходит 360 градусов с шагом в 1 градус. В этом случае нам надо ждать, когда в буфере накопится 360 (градусов) * 5 (байт)= 1800 байт данных. Их вычитываем, разбираем на пакеты по 5 байт и обрабатываем. Получаем полную картину с ЛИДАРа за один оборот сканирования. Использовать дополнительный программный буфер в этом случае не имеет смысла, он будет дублировать буфер VISA без дополнительных плюсов, но с дополнительными расходами ресурсов. То есть в VISA Read ставим чтение 1800 байт и таймаут равный двукратному времени передачи одного полного оборота ЛИДАРа. Выход по таймауту будет говорить о потере связи с ЛИДАРом.
4. Так как запуском потока управлял контролер, мы можем гарантировать, что первый байт в полученных данных будет именно первым байтом первого пакета. Смещения тут быть не может. Во время обработки данных с ЛИДАРа проверяем биты S, !S, C. И в случае ошибки хотя бы в одном пакете считаем все полученные данные неверными и отбрасываем их. В этом случае посылаем команду ЛИДАРу на останов потоковой передачи, очищаем буфер RS и перезапускаем потоковую передачу для повторной синхронизации потоков.
Такой вариант будет работать в случае надежной связи между приборами, но при ошибке хотя бы в одном бите приведет к необходимости повторного перезапуска связи для синхронизации.
Если же связь не надежная и ошибки возникают часто, то надо переходить на другой протокол обмена и в нем уже есть вся необходимая информация для определения начала пакета и проверки данных в пакете на корректность по контрольной сумме.

[AndryG]

Спасибо всем за ответы ,давно не заходил на форум ,все ,что было предложено здесь ранее я пробовал сразу и первое ,что было реализовано это проверка бит ,но как выше описано этим нельзя синхронизироваться ,так так как в данных попадаются установленные биты и все рушится, плюс большая скорость и средствами VISA так получать достоверные данные не получается , по крайней мере на скорости 115200 из виртуального порта ,как правильно было отмечено выше. Для реалии жизни я пришел к тому же, что и было написано в последнем сообщении ,к альтернативному протоколу , там хоть и примитивно ,но реализована проверка суммы , да и ответ на запрос , все остальное можно игнорировать . Более ,менее работоспособный вариант , если кому может придется работать это оказалось просто прием по 5 байт после команды старта и проверки ответа , проверка их на правильность .Но как показывает практика на одном компьютере это работает ,на другом синхронизация нарушается . Мне нужно было быстро оценить работу этого лидара , не хотелось заморачиваться с платой управления на контроллере и поэтому я пытался принимать этот вал байт . Измерения прибором достаточно точны, если нет конкретной прозрачности и бликов , 1 мм точность есть, на графике скан помещения , расстояния указаны в мм. На всякий случай выложу свой вариант упрощенной реализации , может кому пригодится)

[Borjomy_1]

Да уберите уже bytes as port. Ставьте количество байт 500 для чтения и читайте сразу 100 посылок. Все это отдельным циклом. И не будет разницы в поведении на разных компьютерах

[AndryG]

Да уберите уже bytes as port. Ставьте количество байт 500 для чтения и читайте сразу 100 посылок. Все это отдельным циклом. И не будет разницы в поведении на разных компьютерах

Это плохая идея, результаты измерений будут видны через пол часа, а так я считываю количество пакетов ,пока не получу данные о новом измерении, все лишнее убирается пока идет отрисовка графика. Здесь только один узел программы, а она гораздо сложнее. Одно могу добавить ,что не попробуешь ,не поймешь.

[Borjomy_1]

Что значит, плохая идея считывать 500 байт разом? При скорости передачи 115200 это 43 мс, 23 кадра в секунду. Для восприятия чаще нет смысла обновлять картинку. Все равно не заметите.

[AndryG]

Что значит, плохая идея считывать 500 байт разом? При скорости передачи 115200 это 43 мс, 23 кадра в секунду. Для восприятия чаще нет смысла обновлять картинку. Все равно не заметите.

На такой скорости обязательно происходит пропуск как правило сбой ,потом не происходит синхронизация, проще это делать по готовности, попробуйте и поймете, по теории здесь много уже было предложено ,но на практике не работает это все должным образом ,мне просто не нужно было циклиться на этом китайском ,школьном протоколе.

[Borjomy_1]

У нас, например, один из датчиков работает через VISA на скорости 921кбит и никаких пропусков не наблюдается, хотя он работает с полной нагрузкой месяцами без перерыва. Объясняю популярно, почему у вас пропуски: цикл приема надо выносить в отдельный цикл и делать его зависимым ИСКЛЮЧИТЕЛЬНО от запроса конкретного количества байт. И никаких таймеров и чтения количества принятых байт внутри цикла.
А на визе и последовательном протоколе я собаку съел, 20 лет им занимаюсь. Скорость 115200 это лишь 11520 кбайт в секунду. Опрос количества принятых байт не моментален. Обновление информации может достигать 55 мс, в зависимости от некоторых особенностей конфигурации. За это время можно переполнить буфер. Если цикл приема совмещён с обработкой и тем более, визуализацией, пропуски гарантированы.
Вы также можете попробовать увеличить размер приемного буфера. Но при правильной организации программы этого не требуется

[ujin1]

Обновление информации может достигать 55 мс, в зависимости от некоторых особенностей конфигурации. За это время можно переполнить буфер. Если цикл приема совмещён с обработкой и тем более, визуализацией, пропуски гарантированы.
Вы также можете попробовать увеличить размер приемного буфера. Но при правильной организации программы этого не требуется

Железо как-то обошли вниманием.
1. Обычный компьютер с WIN10.
2. Преобразователь USB-COM.
3. Сигналы вместо +-12 +-5В.
4. Загрузка процессора более 70%.
5. Мышкой двигаете быстро и переключаете окна.

[Borjomy_1]

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