how to have a while loop inside a case structure?

[NIquist]

The STOP button on the Boolean palette defaults to a latching action.  You can change it by right-click>Mechanical Action.  Latching actions are not compatible with local or global variables however.  

Shared variables are the same I think, I don't really know because I've never used one.  You shouldn't either.  All these variables defy dataflow programming and will invariably confuse a beginner.  They are not magic devices that let you bypass good coding practices.  Stick with learning the state machine.  The only variables you should worry about right now are the wires.

[JÞB]

---

@NIquist wrote:

Shared variables are the same I think, I don't really know because I've never used one.  You shouldn't either.  All these variables defy dataflow programming and will invariably confuse a beginner.  They are not magic devices that let you bypass good coding practices.  Stick with learning the state machine.  The only variables you should worry about right now are the wires.

---

At the risk of proving NIquist right about confusing beginners.....

Shared variables can result in the same types of race conditions as all dataflow breaking functions.  Globals, Locals, Events,  Shared Variables and Queues/Notifiers/semaphores/occurances (lumped as a group), all break dataflow.  Each one is useful and I've listed them from highest to lowest risk.

Globals by their unlimited scope pose the greatest risk and are very problematic to troubleshoot.  "WORM globals" can help bbut you cannot enforce the WO part when another developer "Helps out" while you back is turned.  They can ALLWAYS be replaced with a Functional Global or Action Engine (Check out Ben's famous nugget-  the link is in his signature and theres allways a post around)

Locals with race contitions are easier to track down because the scope is limited to a single Block Diagram.  Follow the style guide, make good decisions on sub-vi design, keep seperate functions in seperate Block Diagrams and you'll "almost" never be tempted to use one.  They can always be coded around.

Events- commonly cause hung loops, irresponsive FP's and unanticipated bugs.  The Caveats when using Events in the LabVIEW help file are GOLDEN if you need to use events (and they cannot always be avoided)

Shared variables are a good way to share data between applications.  They  have some built in features (like time-stamps,  blocking, and timeouts) that reduce the risk of undetected race conditions.  They are pretty darn handy if,  for instance, you want to serve Time, Temp, RH and Baro to every app on every station in a lab.  You only need one app to read the info and all other apps have the info without accessing the hardware monitoring the enviornment.  Again- the help and examples will keep you out of trouble unless you really mess up.

Queues et al. are intended to break dataflow in as safe a manner as possible and are the prefered methods for sharing data within a single application instance and between Producer -Consumer loops.  Its pretty near impossible to get these to cause trouble except for queue overflows

[NIquist]

Thanks for the breakdown Jeff!

There's one more advantage to the shared variable over the global and local, they have error in and out terminals.

[LV_Enthu]

Hello Everyone, since i have explained what I intend to do for my project, I am attaching a sample vi in this thread itself...

In the VI attached, i am starting a while loop, upon which all the analog and digital i/o should start... when the while loop is stopped, all the data should also stop...

I am unable to obtain the analog input continously, also, is there anyway that I can keep on updating the digital output conditions???

I know that the digital output is in a case structure,

so, once the case is selected, the digital output conditions which were provided by the user would remain the same for the current run; but I would like to have the conditions (desired freq, desired amplitude, etc. ) to be updated by the user whenever he wants while the code is running...

Can anyone plz go through the vi and let me know what is wrong in it... I know it is messy, but itseasy to understand... nothing much happening in it, no logic... plain acquisition of data....

THanks...

[NIquist]

Well I can see you have really have been working on this and you're much farther along.  Nice job so far!  This can work as it is but it's also a good candidate for a state machine.  Even though it's pretty simple a SM will give you more versatility and writing it into one will provide you good experience.  We can look into that after this code runs. 

One obvious thing that jumps out is that you have property nodes for the START WHILE LOOP in the inner loops that will immediately stop them. 

I'll look through the rest and put some comments in...

[LV_Enthu]

Hey NIquist, thanks for the feedback, i figured out the prob... 🙂

Now I am really eager to convert this into a SM.... 

Lets see how it goes..

[JÞB]

---

@CrackJack wrote:

Hello Everyone, since i have explained what I intend to do for my project, I am attaching a sample vi in this thread itself...

I nothing much happening in it, no logic...

THanks...

---

Yep- more to the point BAD logic on the exit terminals of all while loops (you have some WEC - Wire Equivalent Code)

As examples:

        The Analog input loop stops on the first iteration since Start must be True.  All that logic, the Stop boolean and the loop itself could be removed and get the same operation

Fixing the logic would be a good first step

[NIquist]

DOH! I'm too slow.

Look at the fixes and notes I made in your VI.  I can't run it without errors since I don't have your hardware or Drill_Rig task but the logic is more... logical.

Next stop:  State Machine University!

[JÞB]

Nicely done NIquist.  All yours- but I'll check in

[LV_Enthu]

Hi NIquist, thanks but can you please save it in lv 8.0 version???