Passing Data Out of a while loop

[packstove]

I've created a labview VI that allows me to parse information from a data string. This prcess uses a while loop to read the string, parse the data, and display the parsed data and update on a continuous basis. But I do not only need to display the data but also save it to a file fo later analysis. Unfortunately, I can't just save it all in one big file or else I would just build an aray within the loop and pass it out upon completion. I need to save the data in a sequence of seperate files, so that if something goes wrong I won't loose ALL the data. Besides I would rather work with smaller chucks of data than one big file. I would like to pass data out of the while loop after EACH iteration into a seperate data logging process( for loop within a seperate while loop to build an array to pass to a file save). Is there a way in labview to do this?

[Jacemdom]

Salut.

You could use a notifier, a queue, a global or local variable or directly to the file by happending the data at each iteration...i advise you to search for those words in the LabVIEW help...for the direct to file, you can look at examples...search for "Write Datalog File Example.vi"....

[packstove]

Salut.

You could use a notifier, a queue, a global or local variable or directly to the file by happending the data at each iteration...i advise you to search for those words in the LabVIEW help...for the direct to file, you can look at examples...search for "Write Datalog File Example.vi"....

Thank you for your suggestions. I'll look them up immediately and let you know how it turned out. I've been banging my head for weeks. I can display the data beautifully. I just can't seem to log it correctly

[packstove]

Writing and reading from a global variable did the trick. It works wonderfully. Thank you Jacemdom. You're a life saver.

[Jacemdom]

If you did not go trough the entire help doc on globals, here is some advice on the subject :

- Every global in read mode creates a copy of the data in memory

- you can lose data if you write at 2 different places in the code before reading (race condition)

- they make the code harder to follow (no wires to follow)

- If you plan on using a global in many places, consider making all the global operations in one VI that you use everywhere, this will always keep the data to one copy in memory.

[crelf]

If you did not go trough the entire help doc on globals, here is some advice on the subject :

Nicely summarized

[packstove]

If you did not go trough the entire help doc on globals, here is some advice on the subject :

Thanks Jacemdom,

I was wondering about the read and write timing. But luckily most of my need for globals are only going to be used to logg the latest readings. But I do have one question about using only one Global Vi for all globals. Is there a chance of conflicts if a parallel VI attempt to read from the Global while another is writing to it?

[Jacemdom]

Is there a chance of conflicts if a parallel VI attempt to read from the Global while another is writing to it?

The calls will end up in a queue, like any standard calls to VIs

[Mike Ashe]

You might also want to look in the examples for Queued Message Logging, see:

C:\Program Files\National Instruments\LabVIEW 7.1\examples\general\queue.llb\Queue Message Logging.vi

If you look this up with the example finder you'll get a couple more VIs open, or just look through the library above. With a little tweaking you can have the logger change file names based on various criteria. I've done this a couple different ways, like sensing when you pass midnight, close the old file and open a new log file with today's date. Etc.

[packstove]

Thanks Jacemdom, It will certainly be easier if I can keep all my Globals in one VI. And Mike, I'll go ahead and look that up. Queue Messaging may come in handy, Thank you.

[bsvingen]

I think this example show all too obvious why dataflow is not exactly rocket science in terms of compiler technology/programming paradigm. In my first larger project i was wondering about the exact same thing. I had one loop for logging and one loop for several PID controllers. The PID loop was run at a much slower rate than the logging, but at a steady rate independent of the logging loop which would change rate according to user specifications. I also ended up with using global variables, even though the manuals also back then said "use globals only when neccesary because they are inefficient and will break the data flow" or something like that + "dataflow make parallell operations easy and fool proof".

1. You cannot pass data out of a loop without breaking the dataflow.

2. The only way to run in parallel is to break the dataflow.

So that dataflow really makes parallel operations easy and straight forward is some big myth IMHO. Dataflow just as often prevent parallel operation where parallel operation are the only natural thing to do. With queues, goop, lcod etc all this is now more or less an academic discussion, except for newecomers to labview, and it is therefore a bit strange that NI still advocated that dataflow is THE big thing for parallel programming.

:beer:

[Jacemdom]

I think this example show all too obvious why dataflow is not exactly rocket science in terms of compiler technology/programming paradigm. In my first larger project i was wondering about the exact same thing. I had one loop for logging and one loop for several PID controllers. The PID loop was run at a much slower rate than the logging, but at a steady rate independent of the logging loop which would change rate according to user specifications. I also ended up with using global variables, even though the manuals also back then said "use globals only when neccesary because they are inefficient and will break the data flow" or something like that + "dataflow make parallell operations easy and fool proof".

1. You cannot pass data out of a loop without breaking the dataflow.

2. The only way to run in parallel is to break the dataflow.

So that dataflow really makes parallel operations easy and straight forward is some big myth IMHO. Dataflow just as often prevent parallel operation where parallel operation are the only natural thing to do. With queues, goop, lcod etc all this is now more or less an academic discussion, except for newecomers to labview, and it is therefore a bit strange that NI still advocated that dataflow is THE big thing for parallel programming.

:beer:

simple parallel dataflow...