I am writing a program to control laser mirrors. I use the example: continuous Analog output - non regeneration. When i put a counter on itteration from the while loop, i can see i runs very fast for the first 10 times, and then it slows down to the normal pase... Is it possible to make the VI that it doen'st run so fast in the first run? It looks like it's buffering a whole bunch of data... But i want to pause the output from time to time...
Solved! Go to Solution.
when configuring a task, the driver automatically allocates a buffer unless it is single point IO.
The size of that buffer is first of all connected to the sample rate and the "number of samples":
For finite acquisition, the buffer is simply "number of samples"
For continuous acquisition, the buffer size is either a specific number depending on the sample rate (there is a table for this) or "number of samples", which one is greater. The buffer is typically covering between 1/10 up to 1s (sometimes even more).
That being said, it sounds like your sample rate and number of samples as combination creates a buffer which is about ten times bigger than your number of samples. Therefore, you can write about ten packages before the buffer is full and the write function has to wait for a free segment.
There are several ways to solve your request. So maybe you should elaborate on your requiriments, esp. those of pausing.
A simple solution for pausing at any time would be using a counter in order to generate the sample clock.
Thanks for the explanation... I've made a small VI and a data file where i can show you what happens... If you connect a scope you can see that only the last two records are being outputted? And that's very strange... When you see the total wave form it should do much more...?
Without giving more information, we cannot help any further. Which device are you using?
Your loop iterates 12 times and runs for 7.2 seconds using a simulated NI DAQ device (6353). You "TotalWaveForm" Graph hover displays only 6000 values, which would be 6s for 1kHz update rate. So obviously, the data you read from the datalog-file is inconsistent or the way you collect the data for this graph is incorrect.
Looking into the datalog-file using a text editor shows that obviously the records are different in length. Is that on purpose?
You see that there are some confusions you have to clear up. Please also check out the default output example which runs with non-regenerative output. Does that behave as expected?
I use a NI USB-6211, but i am going to use a different Daq device with 8 Daq outputs later on.
I store a data log file with records each with a length of 500 samples. When i run my program it takes 1295 ms?
Now it's realy confusing...
The data i collect from my datalog file is the exact data you see in the "Total Wave Form" graph... so it cannot be inconsistend.
With 500 samples per record and 12 records, the output should work for 6s as it is also displayed in the final graph.....
What is the "standard example" doing?
This is a derivation of the standard example... It collects 10 records realy fast and then outputs the last 2, number 11 and 12...
If you play the example (non-regeneration) and you switch between the different waveforms (triangle to sinus etc...) it also takes a while before you can see the change appear. So there are a couple of record still in the buffer.
But in my case, it looks like it just skips them?
[...]If you play the example (non-regeneration) and you switch between the different waveforms (triangle to sinus etc...) it also takes a while before you can see the change appear. So there are a couple of record still in the buffer.
This is the expected behavior, esp. if the buffer is way bigger than each individual package of data you write to it.
Regarding your datalog-file:
Yes, the total graph looks as you obviously expect it to be. But the file itself obviously has records which are different in size. This might be affected by "values per channel" as "channel count"... point is, the overall sum of data for your channel is correct, but could be distributed differently upon all 12 records.
Can you please test the standard non-regeneration example in order to see if it also creates the issue of being "too short in output times"?
Somehow it seems to me that you have some kind of overwrite enabled for your buffer.... that means that data, which is not passed to the device yet is overwritten by the new data package each time. So essentially, the first 11 records create some random glitches followed by the unmodified 12th record.
Also you might want to check with another PC.....
Attached is a file with 12 records each with exact the same size (500 samples x 3 channels) each. Also a file with 6 records of 1000 samples each... I don't know how to test the standard example, but i think you do see al the samples there on my scope, but it buffers 10 loops at the beginning. So when you switch you have to wait 10 seconds before the sinus changes into a triangle for example. I can't find a setting where to change buffer overwrite function??