12-04-2013 11:22 AM - edited 12-04-2013 11:24 AM
I'm writing some variables out to a binary file in real-time (xpos, ypos, elapsed time) with a while loop (see blockdiag.png). I'm using the time recorded by LabVIEW with an external devices clock to interpolate position values, before you ask, I don't have access to the external clock so interpolation is necessary after the data has been collected. Currently, the while loop is unabated and runs as fast as the CPU will let it. After I'm done collecting my data, I plotted up the elapsed time in MATLAB and noticed some very strange behavior, negative time (see clocks.png)!!!! The black data here is my external devices clock and the red data represents the elapsed time written out by LabVIEW. There are two instances in the vector that indicate a large negative step in time. This doesn't always happen and seems to occur somewhat spontaneously within the elapsed time vector.
Questions:
1) Has anyone seen this behavior before?
2) Would putting a Wait.vi in the while loop help? (I figured this would at least regularize the time step.)
3) Please help.
Much thanks, please don't judge my LabVIEW code (I'm sure there are better ways to do it, but it works and that is how I want it).
Adam
Solved! Go to Solution.
12-05-2013 02:33 PM
Hi AdamBlues,
To clarify, you said you are writing in real-time. Are you using the Real-Time module?
It is good practice to put a wait in your while loop. This frees up the processor to address other tasks.
This odd behavior may be because of a race condition due to the local variables. Where in your program are you graphing the clocks? Also, where is the start time variable being written? Finally, do the discontinuities always occur at the same place?
Best Regards,
12-05-2013 02:37 PM
I'm not using a Real-Time module, I don't think. I actually don't know what that is. Could you please give me some more information on that?
I put a wait in the while loop and still had the problem.
I am not graphing the clocks anywhere in the program, I don't really need to see them. The start time is written in the previous frame of a flat sequence structure. The discontinuities do not occur in the same place. Sometimes there is one, sometimes two, have never seen more than two.
Thank you for your response. I hope we can get this figured out.
Adam
12-06-2013 09:58 AM
The Real-Time module is an add-on to LabVIEW that is used to interface with our Real-Time operating systems and hardware. Since you had mentioned real-time, I just wanted to clarify so we could be on the same page. More information about the Real-Time module can be found at the link below:
https://decibel.ni.com/content/docs/DOC-23701
Can you post your full code (project files and VIs in a zip folder)? It is difficult to get a full picture of what is going on from the snapshot you included in your initial post.
Thanks,
12-06-2013 12:15 PM
I am guessing writing to disk is causing your timing errors
You might want to consider a producer-consumer program architecture in this instance.
That will allow the acquisition to be independent of writing to disk
12-11-2013 11:02 AM
I think what you are suggesting is that I just store all the data into an array during acquisition and then write it out at the end? I'm fairly certain I tried this once and I had a huge slow down when the arrays got large. They could potentially have about 1e6 elements in some cases.
Adam
12-11-2013 11:11 AM
Here is a couple versions of my .vi. I got an error when trying to save as LabView 8.0, so hopefully you have the more recent version.
Thanks for all your help.
Adam
12-11-2013 01:30 PM
@AdamBlues wrote:
I think what you are suggesting is that I just store all the data into an array during acquisition and then write it out at the end? I'm fairly certain I tried this once and I had a huge slow down when the arrays got large. They could potentially have about 1e6 elements in some cases.
Adam
If you are refering to my suggestion of a Producer Consumer archetecture, then no that is not what PC does.
Simple explainition a PC has a fast running aquisition loop (producer) that puts the data put into a Queue
Then a consumer loop dequeues the data and saves to a file.
Using a queue allows the Producer to get ahead of the Consumer without losing any data.
12-11-2013 01:41 PM
@AdamBlues wrote:
Much thanks, please don't judge my LabVIEW code (I'm sure there are better ways to do it, but it works and that is how I want it).
Adam
I just wanted to make a brief comment regarding the above statement. I would recommend that you be open to changes to your code. There are many VERY experienced LabVIEW developers on these forum and there is always an opportunity to learn and improve your code. Just because something works doesn't mean that the code can't be improved dramatically. You may find that being open to suggestion will result in you becoming a better programmer and that your applications are more stable, robust and easier to maintain. For example, more often that not you are much better office using a state machine to replace a flat sequence structure. Learn how to use dataflow properly and the need for sequence structures generally disappears. These are just a few things that can be done.
I guess my point is that it is a good idea to try and remain open above suggestions to improve or change your code.
12-11-2013 02:46 PM