Showing results for 
Search instead for 
Did you mean: 

Stopping in a while loop


I have motors being run in a while loop. Controlled by PID and encoders. The issue is that when I hit the stop button for the program (not for the loop) the motors continue to spin, but the encoders aren't reading anymore and therefore PID control just stays at a constant speed and direction in which they were stopped. I created a stop button for the program that puts all pwm to 0 before ending the loop but this program is going to my professor and I'm worried someone will try to stop it incorrectly and damage the hardware. How can I make labview program stop button work to stop all signals!?

0 Kudos
Message 1 of 4

You need to handle the X in the upper right and ensure proper HW shutdown (e.g. using a discarded "panel close?" filtering event). Hard to tell from an ambiguous paragraph what you are actually doing. Can you show us some code?

LabVIEW Champion. It all comes together in GCentral GCentral
0 Kudos
Message 2 of 4

You'll need to compile your VI into an EXE to prevent someone from clicking the Abort Execution button.  But combined with Altenbach's suggestion for handling the panel close event, that should address your concerns of proper hardware shutdown.  This doesn't handle extreme cases like a force close from the task manager, computer restart, etc. 


Edit to clarify: The abort button can be hid during edit time (in VI Properties -> Window Appearance) but can also be turned back on by someone else. 

LabVIEW 2017
LabVIEW Programming
Message 3 of 4

The same way that you do a step-wise initialization of all of your loops and variables, you need to plan and program an orderly shutdown, particularly when you are dealing with devices that you are controlling.


You should have a single way of stopping your program.  Note that, by design, there are multiple ways to stop LabVIEW, including using a "Stop" button that you read and use its value to stop loops (what I'll called a "Programmed Controlled Stop", hitting the "Stop" button on the Menu Bar (an "Uncontrolled Stop"), executing a LabVIEW "Abort" function (a "Potentially Fatal Uncontrolled Stop"), a "Close Window" (the little "X" at the upper right corner), another potentially "Uncontrolled Stop".


You can remove some of the less-safe methods (please don't ever put the Abort function in you program!).  So let's think about the Programmed Controlled Stop.  Here a Stop Control is usually wired to the Stop Indicator of a While Loop, inside of which "something" is happening (like you are controlling your motor).  When you exit the loop, you want to execute whatever code you need to safely stop your devices and set them into a safe state.


What if you have more than one loop?  Ideally, you have a single "Stop" point, and you use it to send "Secondary Stop" signals to all the other loops.  Sometimes there's a "natural" method to do this.  For example, you might have a Producer/Consumer Design, where you have a Producer with a DAQ function that does a Read, and sends the results (via a Queue or Stream Channel Wire) to a Consumer.  Put the Stop in the Producer, as you want to "stop Producing and start to Shut down when I tell you".  Do not follow the common practice of releasing the Queue when the Producer exits -- the Consumer may still need it!  Instead, put a Unique Value (such as an Empty Array, or an Empty String), sometimes called a "Sentinel", on the Queue to send to the Consumer.  When the Consumer dequeues the data, it needs to check for the Sentinel (this takes at most a microsecond), and if it sees it, it knows (a) the Producer has not sent any data, so it doesn't need to process anything, and (b) the Producer has exited, so the Consumer can also exit and safely Release the Queue.


You can use similar techniques to handle other parallel loops -- follow the data flow, and have the Sender tell the Receiver to exit.


If you need more advice, attach your code (you probably have multiple VIs, so compress the folder holding your Project and attach the resulting .zip file).  "The Devil Is In the Details" ...


Bob Schor

Message 4 of 4