LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Starting/Stopping a polling loop with a user event.

I keep reading on this forum that placing a loop inside a user event structure is a bad idea because it disables other user events from triggering.  However, it seems like a good idea to be able to start and stop a loop from a user event (like a button being pressed or de-pressed) and it seems like a good idea to not have the loop waist CPU resources while it does not need to be running.

So what are the solutions to this?  Is a notification the best approach?

Attached is my solution.  Is there a more graceful approach to this problem?

Aside: Why are boolean controls that are of the "Latched" mechanical action always pressed in after their event fires?  For instance, the stop button on the attached VI?  Shouldn't it be depressed after the user clicks on it because it is "Latch when released?"  I've always wired "false" constants to 'variables' of these controls after the event structure fires, but do not find this approach very graceful.

-Nickerbocker
LV 8.5
0 Kudos
Message 1 of 12
(5,592 Views)


Nickerbocker wrote:
Aside: Why are boolean controls that are of the "Latched" mechanical action always pressed in after their event fires? 

A latched boolean reverts to false once it is read by the code. Your terminal in outside the loop, thus it is only read at the start of the program and never again. If you place it inside its event case, it will get read and will reset whenever its event has triggered.
 
Can you explain the logic with the error split and merge? Just wire all errors across.
 
A better way for the rest of the code is to use the timeout event for polling, keep the timout in a shift register, and manipulate the timeout value as needed.
 
 
0 Kudos
Message 2 of 12
(5,571 Views)
Here's a quick implementation (LV 8.5). Modify as needed.
Message 3 of 12
(5,567 Views)
altenbach,

I guess the reason why I split the error code was because i was worried about an error happening during the creation of my Notification.  If an error is generated on the first itteration, then the loop is terminated with that error line.  Right?

As for your event structure polling example, manipulating the timeout from -1 to what rate I want my loop to poll out seems very clever and crafty.

Can multiple event structures exist in the same block diagram?  For some reason I was under the impression that there could only be one event structure that fires at one time.  If that structure was in execution then no other Event Structures could fire....  if my information is wrong, then I like your solution.  If it is right, then I don't like your solution :P.
Message 4 of 12
(5,557 Views)


Nickerbocker wrote:
If an error is generated on the first itteration, then the loop is terminated with that error line.  Right?

Wrong! The loop cannot terminate until everything in it has terminated. RIght now it will stall at the event structure no matter what until an event occurs. At this time it is sufficient to get the error piped through the event structure. If you are worried about an error in creating the notifier (anything that happens before the loop starts), you shold place your entire later code inside a case structure wired to the error so the loops don't even start.


Nickerbocker wrote:
Can multiple event structures exist in the same block diagram?  For some reason I was under the impression that there could only be one event structure that fires at one time.  If that structure was in execution then no other Event Structures could fire....  if my information is wrong, then I like your solution.  If it is right, then I don't like your solution :P.

Your information is wrong again. You can have as many event structures as you want, and all is well as long as all event structures can execute in parallel. So make sure they are in independent loops.
 
(If you would place two event structures in the same loop, both must trigger for the loop to complete the iteration, probably something that does not make a lot of sense. So don't do that!).
0 Kudos
Message 5 of 12
(5,550 Views)
Ok, I like that approach then.  So the event structures in those loops are dedicated to two tasks, watching for the change in the button, as well as the timing of the polling.

One thing that concerns me is the change of state of the polling? button during the execution of the case structure that contains "polling code."  What happens if the user changes the value of polling before the event structure resets?

I guess I could do some testing of your code and find out....

Thanks for all your help!

-Nic
0 Kudos
Message 6 of 12
(5,543 Views)


Nickerbocker wrote:
One thing that concerns me is the change of state of the polling? button during the execution of the case structure that contains "polling code."  What happens if the user changes the value of polling before the event structure resets?

Again, it's all in the dataflow. The polling code for the current iteration needs to finish for the loop iteration to complete. The event gets queued until the event structure can execute at the beginning of the next loop iteration.
 
I don't know what you mean by "...event structure resets".
0 Kudos
Message 7 of 12
(5,541 Views)
"...event structure resets"

I guess that is what I call it when you place an event structure inside a while loop.  You place it inside the while loop so that after the event code finishes firing the event structure is reset so another event can take place.

I was not aware that events are queued up....how does LabVIEW know which events to queue and which ones not to?  After the event structure fires and data flows from it to other parts of the block diagram, how does LabVIEW know to watch the "polling?" signal for changes just by chance that the code will loop back to the same event structure?

In anycase, I've highlighted the execution of the code and made a change in "Polling?" which worked as you described.  Changes in the "Polling?" while the code is executed in the case structure introduced an event to be fired when the loop itterated and the event structure needed to fire.
0 Kudos
Message 8 of 12
(5,536 Views)
See, you are again preventing the event loop from servicing the events because you trap the code in an inner loop! 😞 Don't do that! Whay good is an event structure if it is not ready to process within a reasonable timeframe?
 
Use the outer loop for everything. Here's a possible modification.
 
 
0 Kudos
Message 9 of 12
(5,532 Views)
Oh, I trapped it intentionally so that I could be for sure that I had 5 seconds to depress the "Polling?" button to verify that what you were saying about LabVIEW queueing events even if it wasn't waiting on an Event Structure to init was true.  I understand that the timing of the outter loop is controled by the timeout event :P.


Message Edited by Nickerbocker on 12-03-2007 05:23 PM
0 Kudos
Message 10 of 12
(5,528 Views)