LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Fast loop inside a slow loop?

I have an application reading data once every hour, and writing this reading to disk continously - this works fine, however it looks like LV runs one complete iteration (an hour!) before asking me for the filename to save data in, even though that operation is step 8 of a structure inside the while loop, and the long-time-period timer is at step 9 or 10.
How do I get the vi to run at normal speed, asking for the filename and writing the first set of data, and THEN going into the long time wait before looping around and executing again. PS - it runs fine, but there is one complete iteration before it comes up asking for the filename. When I run it for xx seconds time period its ok, but not for a long time period.
Thx! (Newbie here..)
0 Kudos
Message 1 of 6
(3,339 Views)
Dataflow is an integral and important part of LabVIEW. Learn it, know it, use it. Dataflow will prevent another function (node, i.e. file I/O VI) from executing before you want it to.

This sounds like the problem that you may be having.

If this doesn't sound like the problem/solution, post a screen shot of your code for us to take a gander at.
0 Kudos
Message 2 of 6
(3,339 Views)
Possibly, but doesn't sound like that is something than can be controlled (other than by the structure of the VI).
Here's the application. Structure 9 is where the long-term WAIT state lives, and the write out to file is in structure 7. The while thing runs to the end before asking for the filename.
Thank you!
0 Kudos
Message 3 of 6
(3,339 Views)
The problem is that you have made the all too common mistake of using a multiframe sequence. This is why so many experience LabVIEW programmers have abandoned the use of multiframe sequences.

See, a multiframe sequence is exactly like a single function, or a subVI for that matter. The data from the sequence isn't available until all frames of the sequence have executed. So, you send the data "out" of the sequence, but it "holds" at the output terminal until the sequence has completed, and then is sent "out".

The other problem is that you have the Write to File... outside of this inner loop, so only after this loop is done (it only iterates once, so I don't even know why you have it there) will the loop exit, and data from that loop b
e available.


If I may suggest, try encapsulating each frame of the sequence into a subVI (or something along those lines, such as using multiple single frame sequences in a line). You will need to remove the inner loop, as it is uneccessary.

It always helps to diagram your code ahead of time. I prefer pseudo code. This is an extremely useful method of aiding in writing your code as it puts things in perspective, in a serial fashion, so that you can visualize what happens, and when, and then just "plop down" each function as they appear in the pseudo code document.

I hope this helps.
0 Kudos
Message 4 of 6
(3,339 Views)
Thanks, I'm trying to figure out what "multiple single frame sequences" are, and how one would provide for one sequence to go on to the next (writing out a command, then reading in the data, then writing out to file), plus handle the long timer value at the end of these sequences, but only while a STOP button hasn't been pressed (so the STOP function has to be in the short loop and in the long-timer loop (if they're still loops). Thx, will work on it, more to go study! Appreciate your input.
0 Kudos
Message 5 of 6
(3,339 Views)
Dave,

Try some encapsulation and error handler forced data flow. This is always a good substitute for sequencing, as it does the same thing, but makes the code much more readable, and also helps you by making your code reusable.

I have attached a diagram of a very simple VI that really does nothing, but illustrates what I am talking about.

Please post here if this doesn't help.
0 Kudos
Message 6 of 6
(3,339 Views)