LabVIEW Portal

Добрый день!
Сталкивался кто с такой штукой?
Ведется последовательный опрос 10 датчиков через COM-порт. Время цикла выполнения программы произвольное, все работает нормально.
Меняю COM-порт на виртуальный (через USB), начинаются проблемы с циклом выполнения программы. Со временем цикла программы от 6 сек и выше
еще работает более-менее нормально. А от 5 сек. и ниже программа работает в цикле где-то 10 сек. Попробовал убрать функцию закрывания COM-порта
немного помогло, но меньше 2 сек. цикл программы отказывается работать.
Ничего не меняю и не трогаю (настройки остаются), а вот такая штука. И не поймешь сразу.
Суда по миганию лампочки на виртуальном COM-порте, он сам отрабатывает нормально, но в программе не могу додумать, что делать.
Работаю с фирмой ICPDAS.

Выкладывайте исходники или скрин исходников. Будет проще помогать.

Чтобы дать адекватный ответ необходимо:
Наименование модуля USB, с которым работаете,
Наименование датчиков и протокол обмена.
Настройки портов, включая низкоуровневые. Ну и программа...
Еще почитайте тему http://labviewportal.org/viewtopic.php?f=22&t=6130

Здравствуйте! Вот инфа.
Оба модуля преобразуют RS485 в RS232.
Предвидя, что структуру программы можно было бы сделать и получше, соглашусь.
Но, опрос такого количества подпрограммок (опрос COM-порта), не должен так критично сказываться на времени выполнения,
даже, если каждый раз открывать-закрывать COM-порт.

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

Открывать порт надо только ОДИН раз перед началом работы. И закрывать тоже.
Опрос делать в цикле, изменяя адрес, используя массив текстовых констант

serg_si писал(а):Предвидя, что структуру программы можно было бы сделать и получше, соглашусь.
Но, опрос такого количества подпрограммок (опрос COM-порта), не должен так критично сказываться на времени выполнения,
даже, если каждый раз открывать-закрывать COM-порт.

У Вас в подпрограмме считывание идет по 1 байту, при этом, за каждую итерацию несколько раз обращается к локальным переменным. В крайнем случае используйте сдвиговые регистры, но я советую использовать терминатор, тем более он у вас используется, только через "нето" место, это позволит вообще убрать цикл.

Я так понимаю, что порт используется один для всех подпрограмм, по этому в основной программе все запросы выполняются по очереди, а не параллельно и каждый из них тормозит (см. выше). При этом каждый раз открывается и закрывается сессия. Все эти запросы можно сделать в одной сессии, используя цикл.

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

Ок! Буду оптимизировать.
А какие мысли, насчет, того, что даже при таком алгоритме обычный COM-порт (шнурок 9-pin) успевает отрабатывать.
А виртуальный, просто, на порядок начинает тормозить.
Все же затык в LabVIEW 7.1 (может разработчики не сильно заморачивались с USB, USB только распространялось).

serg_si писал(а):А какие мысли, насчет, того, что даже при таком алгоритме обычный COM-порт (шнурок 9-pin) успевает отрабатывать.
А виртуальный, просто, на порядок начинает тормозить.
Все же затык в LabVIEW 7.1 (может разработчики не сильно заморачивались с USB, USB только распространялось).

Можно поставить и 1Mbps, только ошибок много будет.
Тут больше наверное зависит не от программной, а от аппаратной реализации. Здесь все определяется неточностью тактирования на устройстве, какие провода используются и их длина.
Т.е. для каждого конкретного случая нужно конкретно и разбираться.

Виртуальный тормозит потому что открытие виртуального порта требует больших временных ресурсов. А вы это делаете каждый вызов. Не говоря уже о том, что сам драйвер чипа Prolific (на котором построены изделия ICPCON) не только тормознутый в этом плане, он еще и глючный.