LabVIEW
Stop Button in dynamic data type
Hi Danandu,
one more (important) issue:
This is what I see AFTER I placed those buttons next to each other (one of them was way off screen!)…
How should your user know which button to use, in which order to use and which order not to use to avoid problems???
Again the recommendation is: simplify your VI using a clear (and senseful) algorithm! No need for 2 stop buttons, no need for two "Pause/Continue" buttons…
Hi Karnarjun,
@Karnarjun2495 wrote:
The pause / continue part in the code has no effect?
I didn't say so.
The "pause" code surely has an effect - but your user might be irritated about how it works…
(The event structure also has an effect, especially when set to not use a timeout event.)
@Karnarjun2495 wrote:
Is there any other method to do so?
I already mentioned simple state machines…
@Karnarjun2495 wrote:
Is there any other method to do so?
You've worked yourself up to a level when you get concurrency issues.
In LabVIEW, you get parallel execution for free. That is actually great, but you do get the concurrency issues early on, for free.
The solution is to take a dive into architectures. A state machine might work (JKI SM or (D)QMH, or a DIY SM, Queues or not, event driven maybe...). A consumer\producer structure might work. Even actor framework will solve some issues (e.g. start the daq as an actor). You can also simply make a gui VI and a DAQ VI (or even a loop) and connect them with a channel wire.
These are all ways to decouple the daq and gui logic. How strict of a decoupling is desired depends on a lot of factors.
In general I'd say you always want an even structure handling the gui, and almost always have the daq running in parallel.
Search LabVIEW like a graph! 
