Потеря байт при работе с COM портом

[sirQWERTY]

Вот Borjomy_1 правильно понял мою проблему. С передачей байт как таковых проблем нет. Просто я новичок в "картиночном программировании" и никак не могу сообразить, как пропустить ненужные байты, если в момент запуска прибора выясняется, что датчик 3 байта уже заслал. Следующие 6 байт то нужно пропустить и начать прием с новой посылки. В обычном программировании я могу завести переменную, которая будет хранить состояние автомата, могу по совпадению с старт-байтом обнулить индекс массива и начать его заполнение следующими байтами и тд и тп. А тут никак не пойму, как это организовать.
В принципе сейчас допетрил, как в полученных 9 байтах отыскать старт-байт и провернуть массив до нужной последовательности, но в этой ситуации получается, что данные, разделенные старт-байтом, принадлежат двум хоть и "соседним", но разным измерениям, что тоже не очень хорошо.

[Borjomy_1]

Я что-то такого тоже не встречал. Хотя я, может, и не так много работал с Prolific'ом. Отключаете модуль, тупо выдергивая из USB-порта? Или до этого программно закрываете все сеансы, потом выдёргиваете? И когда снова вставляете, то ... устройство не определяется / к нему нельзя подключиться / пакеты пропадают / ?..

Ситуация стара, как мир. Есть ноутбук, к которому подключается датчик через конвертер USB-RS-422. Система полевая, не лабораторная. Человек, который ее эксплуатирует тоже, не компьютерный гуру. Требуется, чтобы в любой момент датчик можно было подключить или отключить. Перезагружать ноутбук, если последовательность действий была произведена в другом порядке? Глупость, да и не предусмотрено закрытие сессии VISA при отключении датчика. Программа повисает на VISA Read, когда отключают конвертер от USB порта (при заданных таймаутах 200мс). Может не повиснуть, но потом при подключении порт не открыть, либо порт будет другой. При первом подключении после включении целевой системы порт может быть, например, либо COM3, либо COM4.

Ну, допустим, если используется всё время FTDI, разъём один и тот же и COM-порт получаем один и тот же, то можно ничего не искать. Однако не будет гибкости и универсальности.

Когда при подключении преобразователя появляется соответствующий - гуда уж гибче? Все, что от преобразователя требуется - это виртуальный порт, с которым можно работать через API и который один и тот-же при подключении.

А еще Prolific - это пока единственная микросхема, которая не потребовала драйверов для работы в системе(разумеется из тех, с которыми я работал).

Это не так. Просто драйвер есть на сайте микрософта и подгружается автоматически. Только если вы пошерстите соответствующие форумы, то увидите, что, в отличие от FTDI, Prolific требует танцев с бубнами, если не заработал сразу, поскольку штатный драйвер и микросовтовский друг друга не заменяют, второй надо удалять ручками.

пришла партия преобразователей на базе FT232R - FTDI. Среди рабочих были и такие, которые не обеспечивали даже 115200(частота была в гораздо меньшую сторону). Проверяли осциллографом.

А вы не в курсе, что это могли быть китайские клоны? Тамошние товарищи скопировали этот чип, но что-то там не доделали.. А вы, небось, по дешевке купили партию и порадовались.
Еще очень важная причина отказа от Prolifica в том, что он у нас зависал при непрерывной работе (с максимальной загрузкой канала на скорости 115200) в течение нескольких суток. Требуя при этом для восстановления работоспособности чуть ли не перезапуска целевой системы. Производитель преобразователя (коробочки) тут не причем, мы перепробовали нескольких. Для нас это недопустимо.

[Borjomy_1]

Следующие 6 байт то нужно пропустить и начать прием с новой посылки. В обычном программировании я могу завести переменную, которая будет хранить состояние автомата, могу по совпадению с старт-байтом обнулить индекс массива и начать его заполнение следующими байтами и тд и тп. А тут никак не пойму, как это организовать.

Итак у вас 9 байт в посылке
Считываете 18 байт разом. Ищете в этой строке стартовый байт (или начало посылки, если байт несколько). Предположим, начало посылки у вас идет 3 байтом. Получаем, что надо будет вычитать еще 3 байта (хвост второй целой посылки). Можете их выбросить, можете использовать - как хотите. Но после этой операции в буфере будут лежать посылки, начинающиеся со стартового байта. Их уже можно вычитывать, ориентируясь только по размеру посылки. Если у вас есть сомнения, что стартовый байт найден правильно, то при приеме уже синхронизированных посылок проверяйте начало посылки, если не соответствует заданному, заново запускайте синхронизацию, предварительно считав один байт из буфера, таким образом запуская поиск со смещением.

[sirQWERTY]

Borjomy_1, Спасибо за разъяснения, но на пальцах это все более чем понятно. Вы не могли бы подсказать, какие картинки для этого использовать и как. Я не понимаю, мы же заказываем функцией VISA read 9 байт, получаем мы их все сразу и только потом можем разобраться, есть ли смещение в посылке или нет. Определять это, а также на сколько смещен старт-байт, я научился. Никак не пойму, как заставить функцию VISA read в следующий раз пропустить ненужные байты и выдать строку в той последовательности, в которой нужно.

[dadreamer]

Ситуация стара, как мир. Есть ноутбук, к которому подключается датчик через конвертер USB-RS-422. Система полевая, не лабораторная. Человек, который ее эксплуатирует тоже, не компьютерный гуру. Требуется, чтобы в любой момент датчик можно было подключить или отключить. Перезагружать ноутбук, если последовательность действий была произведена в другом порядке? Глупость, да и не предусмотрено закрытие сессии VISA при отключении датчика. Программа повисает на VISA Read, когда отключают конвертер от USB порта (при заданных таймаутах 200мс). Может не повиснуть, но потом при подключении порт не открыть, либо порт будет другой. При первом подключении после включении целевой системы порт может быть, например, либо COM3, либо COM4.

Сессия остаётся висеть и порт занят. То есть, нужно так или иначе закрыть сессию VISA и освободить ресурсы. Вот здесь я предложил использовать инструмент VISA Close with Abort и это помогло. Но поскольку у вас вообще программа виснет, то остаётся закрытие сессии вручную. В настройках поставьте галку Tools -> Options -> Environment -> Automatically close VISA sessions (в файле параметров опция имеет вид cleanupVisa=True). В таком случае сессия будет закрываться при нажатии на Abort. Вот ещё полезный инструмент: C:\Program Files (x86)\National Instruments\LabVIEW 2011\vi.lib\Utility\visa.llb\Open VISA Session Monitor.vi. Позволяет просмотреть список открытых сессий и вручную закрыть выбранные.
Ну, или возможны вариации "на тему". Например, отдельный поток/процесс, который следит за тем, что преобразователь был извлечён и через некоторое время рвёт сессию/убивает процесс. Можете развить детальнее, если есть желание.

Когда при подключении преобразователя появляется соответствующий - гуда уж гибче? Все, что от преобразователя требуется - это виртуальный порт, с которым можно работать через API и который один и тот-же при подключении.

Гибче в том плане, что

можно было бы заменить один адаптер на другой (с теми же настройками порта) и разницы не почувствовать.

То есть, программе было бы "по барабану", с каким преобразователем работать - она могла бы работать с любым без потери эффективности.

А вы не в курсе, что это могли быть китайские клоны? Тамошние товарищи скопировали этот чип, но что-то там не доделали.. А вы, небось, по дешевке купили партию и порадовались.

Бывает такое прямо с теми же данными чипа (маркировка, серийник и т.п.)? Обычно клоны имеют свои имена, да и часто драйвер у них свой. Ну, из тех, что видел. А FTDI чипы разве не в Китае делает? Вряд ли в Шотландии.

Вот Вам для общего развития: http://habrahabr.ru/company/zeptobars/blog/212859/ .

Еще очень важная причина отказа от Prolifica в том, что он у нас зависал при непрерывной работе (с максимальной загрузкой канала на скорости 115200) в течение нескольких суток.

Интересно, надо будет проверить, как будет такая возможность.

[Vitekkz88]

Borjomy_1 писал(а):в отличие от FTDI, Prolific требует танцев с бубнами, если не заработал сразу, поскольку штатный драйвер и микросовтовский друг друга не заменяют, второй надо удалять ручками.

Все одинаково легко и просто устанавливается/исправляется как для FTDI так и для Prolific. Не надо жути нагонять.

Borjomy_1 писал(а):А вы не в курсе, что это могли быть китайские клоны? Тамошние товарищи скопировали этот чип, но что-то там не доделали.. А вы, небось, по дешевке купили партию и порадовались.

Вкурсе, но это были не китайские клоны. Может у Вас в компании принято на рынках по дешевке закупаться оборудованием или микросхемами, но мы ведем закупки иначе - не надо всех под одну гребенку. Более того, Китай от НЕ Китая легко отличить. Вот Вам для общего развития: http://habrahabr.ru/company/zeptobars/blog/212859/ .

Borjomy_1 писал(а):Еще очень важная причина отказа от Prolifica в том, что он у нас зависал при непрерывной работе (с максимальной загрузкой канала на скорости 115200) в течение нескольких суток.

Не знаю, как там с круглосуточной работай через LabVIEW - но с Си-шной реализацией приёма данных(терминал специальный)- проблем не было. Тем не менее - Ваш горький опыт и профанации с Prolific-ом могут заставить призадуматься. Меня проблемы зависания и чего-то еще в процессе работы обходили стороной.
dadreamer, заодно и С/C++ реализацию можете потестить(если есть конечно). У меня закрались подозрения, что VISA глючила, а не преобразователь.

[Borjomy_1]

Вкурсе, но это были не китайские клоны. Может у Вас в компании принято на рынках по дешевке закупаться оборудованием или микросхемами, но мы ведем закупки иначе - не надо всех под одну гребенку. Более того, Китай от НЕ Китая легко отличить.

Я бы не сказал, что китай от некитая легко отличить, тем более в таком случае как с FTDI. Освоят китайцы лазерную гравировку и что делать.... А брак, ну да, бывает. Мы также сталкивались с тем, что бывают бракованные партии например процессорных плат у производителей, от которых такого никак не ожидать.

[Borjomy_1]

Сессия остаётся висеть и порт занят. То есть, нужно так или иначе закрыть сессию VISA и освободить ресурсы. Вот здесь я предложил использовать инструмент VISA Close with Abort и это помогло. Но поскольку у вас вообще программа виснет, то остаётся закрытие сессии вручную. В настройках поставьте галку Tools -> Options -> Environment -> Automatically close VISA sessions (в файле параметров опция имеет вид cleanupVisa=True). В таком случае сессия будет закрываться при нажатии на Abort. Вот ещё полезный инструмент: C:\Program Files (x86)\National Instruments\LabVIEW 2011\vi.lib\Utility\visa.llb\Open VISA Session Monitor.vi. Позволяет просмотреть список открытых сессий и вручную закрыть выбранные.
Ну, или возможны вариации "на тему". Например, отдельный поток/процесс, который следит за тем, что преобразователь был извлечён и через некоторое время рвёт сессию/убивает процесс. Можете развить детальнее, если есть желание.

Проще применить конвертер на другом чипсете. Лично у меня на старости лет развивается аллергия на "делание из д..ма конфетки". Накушался.

[Borjomy_1]

Borjomy_1, Спасибо за разъяснения, но на пальцах это все более чем понятно. Вы не могли бы подсказать, какие картинки для этого использовать и как. Я не понимаю, мы же заказываем функцией VISA read 9 байт, получаем мы их все сразу и только потом можем разобраться, есть ли смещение в посылке или нет. Определять это, а также на сколько смещен старт-байт, я научился. Никак не пойму, как заставить функцию VISA read в следующий раз пропустить ненужные байты и выдать строку в той последовательности, в которой нужно.

Для того чтобы заставить VISA read в следующий раз пропустить ненужные байты, достаточно заказать чтение количества этих ненужных байт. Функция выполнится и выдаст вам эти ненужные данные. А вы ее обманите и не обрабатывайте их. Что тут сложного?