09-15-2011 11:37 AM
Hello All,
I am writing a simple program where I am recording temperatures to a file with a timestamp coming from a waveform. The thing I am playing with is the time stamp. I would like to write samples every 1 second with the timestamps reading 1,2,3,4......
When I set the acquisition mode on the task to N Samples and set a wait in the false case for 1 sec the time stamps usually run a little over 1 second apart and vary a little bit. I realize the delay of writing the file adds to the 1 sec time so the time stamp does not come out exactly 1,2,3,4...... I found that if I use countinuous samples as the acquisition mode there is less variation in the time stamp of the data, but it is still not exactly 1,2,3,4....
So if I play with the time in the false case I can get the timestamps to come out as 1,2,3,4... just like I want. But I imagine as I change the code that "wait" value will also have to change.
Is there an easier way to log the data at 1 second intervals and get the timestamps of 1,2,3,4.... no matter how I change the original program? I usually don't care about the extra fractions of a second in the timestamp, but I have some extra time and thought I would look for a better way to make it happen.
Thanks
09-15-2011 12:19 PM
09-15-2011 12:26 PM
To get more consistent time on your data loop and recording you are going to need to split your data acquisition and file saving into two different loops. Have you ever heard of the producer consumer architecture? This is where I would start if I were aiming for a more consistent result. You should also think about saving the original file as a binary file and convert it later to CSV. You will be able to save binary data faster. You should also look into buffered data acquisition so that you can process chunks of data at a time.
The general idea of your vi is good and I think that if you use some of the ideas above you will see that you get much better data saving control.
09-15-2011 12:51 PM
@aeastet wrote:
To get more consistent time on your data loop and recording you are going to need to split your data acquisition and file saving into two different loops. Have you ever heard of the producer consumer architecture? This is where I would start if I were aiming for a more consistent result. You should also think about saving the original file as a binary file and convert it later to CSV. You will be able to save binary data faster. You should also look into buffered data acquisition so that you can process chunks of data at a time.
The general idea of your vi is good and I think that if you use some of the ideas above you will see that you get much better data saving control.
I was kind of figuring the best way would be to save data in it's own loop for better control. (Producer Consumer)
I did not think the file save time or processing the data would be that big of a deal with a 1 second sample rate, but I have been wrong before.
But as usual, adding up all the small things will makes a difference. But will the buffered data make that big of a difference in this case? I have not really looked into it much before, but if I did buffer the data into chunks wouldn't I have to seperate those chunks into seconds of data then I guess write a few seconds of data at a time? I will have to look into that some more.
09-15-2011 12:58 PM
@jcarmody wrote:
How about using Wait Until Next ms Multiple?
I guess that could work if I saved data in a different loop, otherwise it would slow the whole program down. I guess my question is why do you put the output into a feedback node?
09-15-2011 01:04 PM - edited 09-15-2011 01:04 PM
@_Bryan wrote:
[...] I guess my question is why do you put the output into a feedback node?
Because I wasn't thinking clearly... I saw your Feedback Nodes and got excited!
I'm glad you caught it, otherwise you'd have had a horrible mess. Sorry.
09-15-2011 01:05 PM
_Bryan wrote
I was kind of figuring the best way would be to save data in it's own loop for better control. (Producer Consumer)
I did not think the file save time or processing the data would be that big of a deal with a 1 second sample rate, but I have been wrong before.
But as usual, adding up all the small things will makes a difference. But will the buffered data make that big of a difference in this case? I have not really looked into it much before, but if I did buffer the data into chunks wouldn't I have to seperate those chunks into seconds of data then I guess write a few seconds of data at a time? I will have to look into that some more.
I am not sure that you need to buffer the data. It may make it harder to process. I was simply offering you suggestions on how to optimize your program to get the best chance at getting 1 sec repeatability. I would say that you most definitely need to break your system in to two parts. then do the rest of the stuff it that does not do it for you. You are going to be dependent on windows so the more you can do to free up things the better repeatability you will have.
09-15-2011 01:19 PM
@jcarmody wrote:
Because I wasn't thinking clearly... I saw your Feedback Nodes and got excited!
I'm glad you caught it, otherwise you'd have had a horrible mess. Sorry.
No problem, thanks for your time.
09-15-2011 01:21 PM
Hi Tim,
I always appreciate suggestions and options.
09-15-2011 01:32 PM
Producer/consumer- producer directly connected to input node and consumer receiver data from producer via queues is the best I have known. User wait until next ms multiple in consumer configures as ms timer wired up with constant 1000 on left input node. Also I suggest change properties of graph by right clicking on the graph indicator and disabling autoscaling of x axis and using minimum and maximum to get 1,2,3 intervals.
Hope it helps