LabVIEW
Start/stop button to start and stop and start again
Solved!
Hi dilge,
I want my program to start when I push the button, and I want it to stop when I push it again.
Right now I don't see any place where you "stop" it when you push the "START" button again…
THINK DATAFLOW: the case of the case structure is only left when all the content is executed.
Did you even tried to debug your VI? Did you use highlight execution to debug your VI?
But it does not start from the beginning, it continues from the same place left.
Some notes:
1. Right now you NEVER "stop" your sequence.
2. You cannot "break" a sequence.
3. If you would stop your sequence then you would start from the beginning.
4. Replace that sequence by a state machine. This really helps to implement your requirement!
Why don't you use AutoCleanup? This really improves your block diagram!
Edit:
- Don't use some many local variables. Use more wire! (This also applies to your subVIs.)
- Use BuildPath functions instead of string functions to build a path…
- FormatIntoString really helps to build a file name!
- Use less sequence structures! In general they aren't needed.
- Use UnbundleByName in favor of plain Unbundle to increase readability of your code.
- Use better connector panes: inputs at the left, outputs at the right side!
- Don't use Matrix operations when there are simple array functions (TransposeMatrix vs TransposeArray)!
Hi dilge,
Yeah, it is not working
What is not working?
I still see way too much locals in all those subVIs.
I still see a lot of unneeded sequence frames in all those subVIs.
All your subVIs miss a descriptive icon.
Still that Matrix operation where you need to handle arrays…
Hi dilge,
whenever the Start button is pressed again, the execution stops, and whenever it is pushed again, it starts from the very beginning.
The starting is ok right now: when "start" is switched to TRUE you go to state "Start".
But to stop "Measure" immediately (or: within some milliseconds) you need to read the "start" button in each sub-step in this state! You may divide this "Measure" state into several states and read the "start" button in each of them…
What this one does is that it finishes until the 'Measure' case is executed fully and displays the results anyway.
Yes. sure.
"THINK DATAFLOW!" explains it all…
Obviously I need an event structure
No.
And also, what do we need the descriptive icons for?
Because it helps to improve code readability when the subVI icon describes the functionality within the subVI.
When you would create functions using textual programming would you name functions like "1()" and "2()" or maybe use names like "read_data()" and "write_data()"?
Next item to learn: "polymorphism"!
In your subVIs you are using many loops which contain just a divide function. You don't need those loops as divide is polymorphic and can handle arrays on its own!
One more item to learn: AutoCleanup. Use it in your subVIs!
Hi dilge,
Dividing the measure state would mean a lot of work,
Because you try to implement a proper programming scheme AFTER you started programming. When you would have taken time to design your program BEFORE starting actual programming it would be much less work…
Btw. I don't think it's much work: there are several "steps" in the Measure state which you can easily divide into several states.
what about putting a while loop there and stop the execution by controlling that loop?
How would that help?
I would need a more practical way as I will apply this to larger VIs in the future.
There shouldn't be "larger" VIs in the future: your current VI is still too large to fit into one (FullHD) screen!
Dividing the measure state would mean a lot of work, what about putting a while loop there and stop the execution by controlling that loop?
You have implemented your while loop already. Use ONLY the outer while loop and add for every case an entry in your State- Enum. Something like:
Initialize Program
Start
Stop
Initialize Mesurement
Measure
SS
End
...
Make a TypeDef of your Enum, so every change to the list of states are applied to all instances of this TypeDef.
The type of your Queue could be this Enum, so you could force your state machine from the "producer loop" to jump into every state and only have to decide (with a "select" node) whether you get the next state from the "dequeue Element" function or from the shift register. Btw. in this way you have to wire a constant to the timeout- input of the dequeue node.
As Gerd stated, it doesn't seem very complicated to brake your code into chunks. Use "Edit - Create SubVI" from the Block Diagram menu to modularize your widespread code. As an example I took a part of your code as a very good candidate to be hidden into a SubVI:
Select this (except the "Measurement range" control) and execute the menu command and all of this shrinks to 32x32 Pixel with very few wires going in and out. You could put this into its own state and after executing this code-part the loop will check whether the producer loop has sent a Stop- Signal or continues with the next state. (Unbundle these boolean wires and the two Dbl wires outside the SubVI)
Another point is the long name of this control in your "timing range" Cluster control. The "unbundle by Name" node uses the label of the sub- control. Instead of showing the label of that control you could show the Caption on the Front Panel and use a short name for the label which then is hidden. This can be done very convenient via the properties dialog of the sub- control.
I would need a more practical way as I will apply this to larger VIs in the future.
With these strategy you will easily handle much larger VIs. I understand your "large" as "more complicated", not bigger in Block Diagram size. Take care that your BD always fits to a single monitor.
There are a lot of approaches to programming LabVIEW programs which are easily expandable and maintainable (as a start like this, what I explained before) like the JKI State Machine, the State Machine Editor from NI or something like the Actor Framework.
