LabVIEW Portal

Добрый вечер! Подскажите, как в данном проекте в основном цикле запустить например непрерывный цикл (в одном из состояний стэйт машины), но чтобы и на события реагировала программа и выходила из цикла.
есть вариант конечно в event structure в окне timeout, но где-то здесь на форуме читал, что не желательно так делать...

не tasking нужна библиотека, а jki state machine)

Мне кажется, что верхний цикл event здесь лишний, можно и через второй все делать. Или использовать верхний в случае, если циклов более 1 для удобства?

Я в таких случаях в кейсе, который должен повторяться. отправляю запрос на такой же кейс. Главное таймауты поставить, иначе цикл сожрёт все ресурсы.

Как же она будет выходить из этого кейса?

тогда запросы должны сыпаться снаружи. Таймаут будет стоять там.
Ещё можно так. Если действие цикличное, то таймаут >0, если его надо выключить, то снова поставить -1 минус: при приходе других запросов период сбивается, если запросы будут частыми, то и вовсе можно не дождаться таймаута

Как же она будет выходить из этого кейса?

в сдвиговом бегает флаг, который снимается по команде "стоп". Если флаг стоит. то следующий запрос отправляется, если его нет, то и отправлять не надо.

Artem.spb, программа работает на основе user event, нельзя ли без очередей обойтись?

используйте события вместо очередей, кто запрещает?
таймаут что в событиях, что в очередях работает одинаково - ждёт с момента _последнего_ действия, а не задаёт реальный период цикла.

Артем, не сложно на примере показать как это сделать, ранее только с очередями работал, с событиями только начинаю?

Artem.spb, программа работает на основе user event, нельзя ли без очередей обойтись?

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

не сложно на примере показать как это сделать

что "это"? вы забраковали оба варианта

Artem.spb писал(а):

Artem.spb, программа работает на основе user event, нельзя ли без очередей обойтись?

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

не сложно на примере показать как это сделать

что "это"? вы забраковали оба варианта

Понравилась модель программирования от jki (jki state machine) - с точки зрения удобства, хочу перейти на нее, заодно и user event освоить.
Но информации как взаимодействовать между циклами мало и как в этой машине запустить правильно цикл сбора информации тоже мало.
Так что хотелось бы попробовать через user event)

Можно использовать Timeout Event Structure как показано на картинке.
Если скините свой пример в версии < 18 могу показать как это можно сделать в JKI SM.

Спасибо. Сохранил в 14 версии. И еще вопрос по программе - зачем верхний цикл, нельзя ли обойтись одной state machine.
хочется, чтобы одна state machine отвечала за 1 прибор. В частности в данной машине буде крутиться цикл, где будут считываться кадры с камеры.

rushonda писал(а):И еще вопрос по программе - зачем верхний цикл, нельзя ли обойтись одной state machine.
хочется, чтобы одна state machine отвечала за 1 прибор. В частности в данной машине буде крутиться цикл, где будут считываться кадры с камеры.

Машина состояний у Вас одна - нижний цикл, он же получается ведомый.
Верхний цикл - ведущий.

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

А вот на риторический вопрос, что лучше, Артем попытался дать ответ:

Artem.spb писал(а):вы уж определитесь, очереди или события. Если опыт с очередями, то зачем лезть в неведомое? разве только в образовательных целях

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

Что касается личного опыта, то лучше использовать очереди (Queue), а не события (User events).
Т.к. уже напарывался несколько раз, когда внезапно нарушается логика работы.
Возникает это по причине того, что событие было инициализировано раньше, чем выполнена регистрация в SubVI (параллельном цикле). И такие события довольно сложно выловить в большом проекте со сложной логикой.
Плюсы тоже конечно есть, то что не нужно рассылать каждому циклу команду индивидуально в индивидуальной очереди.
Но приходится мириться, т.к. достоинство в одно, обязательно влечет неудобство в другом.

Есть конечно библиотеки NI Qbus (http://labviewportal.org/viewtopic.php? ... 823#p78560), но тоже влечет определенные неудобства.

Я бы порекомендовал почитать книгу: LabVIEW: стиль программирования - Блюм Питер
Потому что, сколько людей, столько и мнений. А книга позволяет, провести анализ и систематизировать информацию.

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