04-23-2015 02:53 PM
Here is what I am trying to do:
Push Run-> collect measurement for x seconds.
0.5 seconds after "Run", signal output 1
'x' + 2 seconds after output 1, signal output 2
2 seconds after output 2, signal output 3
1 second after output 3, signal output 4
I am using two timed loops. One loop has the data collection for 1 iteration.
The other timed loop is starting on a delay of 500ms. I have the 4 case structures inside this loop. Loop stops after a total of 4 iterations.
I am using a case structure because I need to output the status of the outputs (form of boolean LED). (sequence structure doesn't work this way to my understanding).
If I put a 'wait' outside the case structure and inside the timed loop, it works as expected. However when I move this inside one or several case structures, the LEDs do not work and the timing doesn't work as expected.
I am new to this so any help would be appreciated.
04-23-2015 03:16 PM
04-23-2015 03:28 PM
Note that if you actually download this Snippet, you'll see that I "cheated" -- the big boxes are just Text boxes placed on top of the Error line to "look like" sub-VIs, but the Wait VI, tied to the error line to enforce sequential activity, is real.
Bob Schor
04-23-2015 03:31 PM
Notice how compact, logical, and "readable" my simple-minded example is. You don't have to know hardly anything about LabVIEW to understand what it does. [Incidentally, "burying the messy details" inside sub-VIs is often a very good idea -- it keeps your Block Diagram small and neat, hence comprehensible, and "isolates" the potential Trouble Spots. Once the messy sub-VIs have been debugged, you can string them as you need to one level up.
BS
04-23-2015 03:44 PM
With regards to the event structure, would each next task be in an event case or a separate event structure?
04-23-2015 03:46 PM
Is using an error line the best way to pass this functionality through? So far I have been ignoring the error feature.
04-23-2015 03:53 PM
04-23-2015 06:25 PM
Can you attach the wait vi as well? It seems like I couldn't grab that from the snippet. I appreciate the help
04-23-2015 06:39 PM
The idea is to have one event structure in a loop that implements the state machine embodying you process. The problem with the "simple" structure you have seen presented is that while it might do this one thing, it is not scalable (it can't grow to meet additional requirements) and it is not maintainable (it can evolve to address changes in existing requirements).
Assuming you have been through the tutorials and basically feel comfortable with LabVIEW, check here for examples of a state machine architecture that can grow to meet your needs.
Mike...
04-24-2015 11:53 PM
Sorry, I didn't see this earlier. Here is the Wait VI. It is very simple -- just a VI with an Error Line (so it can be "tied down" and a Wait (ms) function. I put this (as you can see) inside a 16-by-32 icon, so it takes up less space than the Wait function, itself, and can be tied to the Error Line.
But there is a "trick". My code shows three of these in sequence, which is just fine -- it gets called, finishes, gets called again, finishes, and gets called a third time. But what if I had parallel loops, or otherwise wanted to use this in several places and couldn't be sure that the calls would be sequential? Well, it wouldn't work! For example, suppose I have a loop I want do delay for an hour, but (in parallel) another loop I need to delay for a second. Well, if the Wait is "waiting" for an hour, I can't even call it until the hour is up! What to do?
The answer is to use an Execution Property (right-click the icon, choose Properties, and look at Execution) called Pre-Allocated Clone Reentrant Execution. What this means is everywhere I put a Wait in my code, LabVIEW puts a "clone" of this Wait code at that spot. Since all of the clones are independent, they can all run simultaneously without stepping on each other's toes (or should I say "stopping" on each other's toes?).
Finally, Mike Porter took me to task for presenting such a "simple" scheme, rightly pointing out that it was "too specific" and didn't allow for flexibility and growth. He is absolutely correct about this. However, I deduced from your questions and the code examples that I saw that you were not ready for State Machines or other Advanced LabVIEW Concepts, having not mastered some of the more elementary aspects of the language. Sometimes, particularly when starting out, Simple is Better (if it helps to make the concepts clear), particularly if you can point to the Simple Code and say "That's nice, but what if we need more flexibility? Can we come up with a better design?" [Hint -- the answer is almost always "Yes" ...]
Bob Schor