Доброго времени суток.
Столкнулся с проблемой.
В моей текущей задаче мне необходимо постоянно опрашивать ЦАП (picoscope USB 3000) и контролировать, в ручную, положение шагового двигателя при помощи логических переключателей (на блок диаграмме названы как Home, Scan for Pmin etc.).
В случае когда оба subVI запускаются как отдельные VI все работает превосходно, т.е. есть регулярный сигнал с ЦАП и контроль шагового двигателя происходит без заминок, при этом во время движения мотора на заданную позицию сигнал с ЦАП продолжает поступать и обрабатываться;
Проблема возникает тогда, когда я пытаюсь собрать оба прибора в mainVI: в момент когда мотор получает команду поменять положение и начинает вращаться, сигнал с ЦАП перестает поступать и "замораживается" до тех пор покуда мотор не займет заданную позицию, после чего сигнал с ЦАП появляется как ни в чём не бывало...
В качестве примера приведу здесь одну из модификаций моего "творчества", "одну из" - поскольку думая что дело в иерархии, я эксперементировал с различныими комбинациями whileloop и case structure
После начальной инициализации обоих приборов каналы разводятся в два отдельных whileloop'а где ведется постоянная работа с каждым из приборов.
subVi никаким образом (насколько мне позволят мой опыт) между собой не связаны. В чем конкретно проблема, понять можно, до тех пор пока мотор не передвинется, whileloop работающий с ним не закончится и следовательно не наступит очередь whileloop'а опроса ЦАП.
Существуют ли средства Labview принудительно запускающие whileloop'ы чтобы не приходилось ждать окончания других независимых циклов ?
Заранее благодарин за любые полезные комментарии.
проблема в параллельной работе двух subVI
-
IvanLis
- guru
- Сообщения: 5467
- Зарегистрирован: 02 дек 2009, 17:44
- Награды: 7
- Версия LabVIEW: 2015, 2016
- Откуда: СССР
- Благодарил (а): 28 раз
- Поблагодарили: 87 раз
Re: проблема в параллельной работе двух subVI
Независимые циклы и так работают независимо, а у Вас сейчас они выполняются параллельно, но потом для запуска следующей итерации внешнего цикла, верхний ожидает окончания работы нижнего (т.к. там несколько итераций).seva011 писал(а):Существуют ли средства Labview принудительно запускающие whileloop'ы чтобы не приходилось ждать окончания других независимых циклов ?
Вам нужно продумать архитектуру таким образом, что бы циклам не приходилось ждать друг друга.
Можно все свернуть в один цикл. Либо разбить на независимые, для начала попробуйте как на рисунке. Единственная проблема, это остановка двух циклов одной кнопкой, но вариантов решения на форуме полно (все равно у Вас и сейчас коряво работает). Ну и как рекомендация, не знаю, что за оборудование, но желательно поставить задержку в цикле, что бы он не крутился на максимальной частоте и не выжимал все соки из процессора. Хотя в ряде случаев в этом необходимости нет, оборудование само может притормаживать выполнение функций.
Знание нескольких принципов освобождает от знания многих фактов!
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
Правила форума
Как добавить в сообщение картинку или файл
Конвертация / версий (форматов) VI
Как правильно задать вопрос...
-
- interested
- Сообщения: 7
- Зарегистрирован: 04 май 2012, 09:28
- Версия LabVIEW: 12
- Контактная информация:
Re: проблема в параллельной работе двух subVI
Проблема решена.
Вывод: будьте аккуратнее в использовании чужих примеров.
Благодарю. На простых примерах, окончательно убедившись в невозможности Labview создавать подобного рода задержки (без надлежащих плясок), копнул несколько "ниже".
Ответ был найден в мануале по программированию мотора:
Motor Method "MoveAbsolute"
If the bWait parameter is set to 'False', the method returns as soon as the move has been initiated. If bWait is set to 'True', MoveAbsolute returns only after the motors have completed their moves. In either mode, a MoveComplete event is fired once the motor moves have been completed.
When a client application needs to sequence motor moves, it is more efficient programming practice to set bWait to 'False' and respond to the MoveComplete event. This event driven approach allows a client application to service other tasks while the motors are moving.
Если приглядеться, то на принтскрине subVI motor я подавал неверную переменную True. Замена на False привела к желаемому результату.
Благодарю за ваш комментарий и помощь. Спасибо.
Вывод: будьте аккуратнее в использовании чужих примеров.
Благодарю. На простых примерах, окончательно убедившись в невозможности Labview создавать подобного рода задержки (без надлежащих плясок), копнул несколько "ниже".
Ответ был найден в мануале по программированию мотора:
Motor Method "MoveAbsolute"
If the bWait parameter is set to 'False', the method returns as soon as the move has been initiated. If bWait is set to 'True', MoveAbsolute returns only after the motors have completed their moves. In either mode, a MoveComplete event is fired once the motor moves have been completed.
When a client application needs to sequence motor moves, it is more efficient programming practice to set bWait to 'False' and respond to the MoveComplete event. This event driven approach allows a client application to service other tasks while the motors are moving.
Если приглядеться, то на принтскрине subVI motor я подавал неверную переменную True. Замена на False привела к желаемому результату.
Благодарю за ваш комментарий и помощь. Спасибо.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: проблема в параллельной работе двух subVI
У вас изначально архитектура приложения неверная. Потому и приходится извращаться с помощью "плясок", как вы говорите. Это уже много раз обсуждалось, но напишу ещё раз. На каждое устройство должен существовать отдельный цикл для работы с этим устройством (чтение/запись). Хоть это двигатель, хоть плата ввода-вывода, не важно. Для обработки событий лицевой панели должен выделяться отдельный цикл. И собственно на логику работы программы (основной алгоритм) должен быть создан отдельный цикл. Здесь преимущественно используется шаблон State Machine в нескольких вариациях, хотя можно изобрести что-то своё. Коммуникация между циклами выполняется через инструменты синхронизации, такие как очереди и уведомители. Хотя, если вы не хотите их использовать, можно обойтись локальными и глобальными переменными.seva011 писал(а):окончательно убедившись в невозможности Labview создавать подобного рода задержки (без надлежащих плясок)
У вас же сейчас два цикла, которые должны быть параллельными, содержатся в одном большом цикле, который принудительно задаёт начало их работы. Так не делается. Убирайте этот большой While Loop. Для формирования логики вам придётся создать рядышком отдельный цикл. Почитайте темы на форуме по ключевым словам "state machine", "конечный автомат", "машина состояний", "параллельные циклы". Также прочтите вот это моё сообщение - http://labviewportal.org/viewtopic.php?p=72332#p72332 и далее, по ссылкам посмотрите.
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: проблема в параллельной работе двух subVI
Ну он может спокойно загнать все в один цикл, чтобы работа с несколькими устройствами была последовательной. Но тогда он должен понимать, что время цикла будет равно сумме задержек обмена со всеми устройствами. И что важно (для профессионального применения) любая возникающая ошибка внутри цикла может стопорить всю систему.На каждое устройство должен существовать отдельный цикл для работы с этим устройством (чтение/запись). Хоть это двигатель, хоть плата ввода-вывода, не важно.
Если работу с каждым устройством выделять в отдельный цикл (который в является полноценным потоком), то максимально возможная задержка может быть сведена к максимальной задержке самого медленного устройства. А минимально возможная - к задержке, которую дает самое быстрое устройство. И тут возникает возможность достаточно гибкого решения задачи.
Не стоит начинающих грузить машиной состояний, синхронизацией потоков и прочим... Пусть начинают с самого простого...
-
- interested
- Сообщения: 7
- Зарегистрирован: 04 май 2012, 09:28
- Версия LabVIEW: 12
- Контактная информация:
Re: проблема в параллельной работе двух subVI
Спасибо большое за науку, думаю при необходимости я обращусь к ссылкам из упомянутого поста http://labviewportal.org/viewtopic.php?p=72332#p72332 .
Честно говоря, все свои "проекты" я начинаю с всеобъемлющего whileloop'а и запихиваю все необходимое в него пытаясь соблюдать требуемую иерархию (видимо это унаследованно из старыз getting started мануалов). Приведенный мною пример являлся одной из многих попыток решить проблему:
В данном конкретном случае элегантное (но не единственное работающее как требуется решение) - это роскошь за которую расплачиваешься временем на освоение.
Честно говоря, все свои "проекты" я начинаю с всеобъемлющего whileloop'а и запихиваю все необходимое в него пытаясь соблюдать требуемую иерархию (видимо это унаследованно из старыз getting started мануалов). Приведенный мною пример являлся одной из многих попыток решить проблему:
Благодаря вашим комментариям я обнаружил что мои представления (если они и были) о потоках в Labview неверные.В качестве примера приведу здесь одну из модификаций моего "творчества", "одну из" - поскольку думая что дело в иерархии, я экспериментировал с различными комбинациями whileloop и case structure
В данном конкретном случае элегантное (но не единственное работающее как требуется решение) - это роскошь за которую расплачиваешься временем на освоение.
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение