12-28-2011 08:32 AM
I need to log data over long periods of time, using NIDAQmx and WinXP with a USB NIDAQ 6008. Logging in TDMS format is probably quite efficient since data are stored in binary format, 2 bytes per channel. I have made some modifications to one of the example files in order to obtain continuous logging to a TDMS file. I take the liberty of including the hacked source code as well as the error message screen. Note that buffer sizes were adjusted with respect to sector size (4096) on the WinXP machine. Two problems:
1) data reading takes place approx. 3.5 times slower that expected, judging from the screen updates every 1000 measurements.
2) After about 3300 samples, the program hangs with the attached error screen, indicating data overrun in the data buffer.
If I change the data rate to e.g. 500 samples/s instead of 1000 samples/s, there is no difference in behaviour, so this is probably not due to timing problems.
Changing the ConfigureLogging parameter from Val_LogAndRead to Val_Log (naturally!) produces an error message right at the start, indicating that data reads cannot take place while logging is taking place. I strongly suspect a coding error.
Any advice will be strongly appreciated. Kind regards, Willem
Solved! Go to Solution.
12-29-2011 05:49 AM
I have since got the ANSI C code to work. However, this was done experimentally by guessing buffer sizes until it eventually worked. I take the liberty of attaching the C code. I log values on six voltage channels (1 diff, 5 RSE) at 1 second intervals. Buffer size = 2000 times the number of channels = 12000. I still do not understand what the crucial values are for successful operation of this code. Everything hinges on the buffer sizes and how the sampling rate and various other values interact with this.
1) ReadAnalogF64: The value for No.Samples/channel in ReadAnalog64F64 affected the working and produced errors when some values were used. I eventually set it to the default system value. What does this parameter actually mean if one samples at a 1Hz rate? Does the ArraySize parameter in ReadAnalogF64 need to exactly correspond to the size of the data[ ] array? Does this need to be identical to the last parameter in CfgSampClkTiming?
2) CfgSampClkTiming: How does the last parameter (sampsPerChannelToAquire) relate to the parameters in ReadAnalogF64 (No.Samples/Channel and ArraySize)? Also, how does sampsPerChannelToAquire relate to the values of parameters in RegisterEveryNSamples? (I supect not at all).
If anyone has good knowledge about thius, I would really welcome some clarification. Kind regards, willem
12-29-2011 05:40 PM - edited 12-29-2011 05:41 PM
Hi there. I'll try to answer a few of your questions.
The value for No.Samples/channel in ReadAnalog64F64 affected the working and produced errors when some values were used. I eventually set it to the default system value. What does this parameter actually mean if one samples at a 1Hz rate?
When you're sampling continuously, the Number of Samples per Channel parameter basically indicates how many values to pull out of the buffer each time. The default value you put in (DAQmx_Val_Auto) is -1, which means each time, it grabs everything available in the buffer. If the array you're dumping to is too small for this (as per the ArraySize parameter), Depending on what values you were putting here before, you might not have been grabbing enough data at a time to prevent the buffer from overflowing.
Does the ArraySize parameter in ReadAnalogF64 need to exactly correspond to the size of the data[ ] array?
I believe it technically does not "need to"; it's essentially setting the expectation for how big the array pointed to is. So if you put a value smaller than the actual array size, then you'll be safe from errors. If you put a number bigger than the actual array size, and the program then tries to write to the array with more values than it can hold, you'll probably get an array index out of range error. Remember, like I said in the above question, when the DAQmx function is grabbing values from the buffer, it looks at the ArraySize parameter to check its limit, not at the array itself (this is how pointing to an array typically works, and is a common point of frustration in C code).
Does this need to be identical to the last parameter in CfgSampClkTiming?
No. The last parameter in this function, when in continuous mode, actually helps determine the buffer size (note: this doesn't set the buffer size; it helps determine what the buffer size is).
Also, how does sampsPerChannelToAquire relate to the values of parameters in RegisterEveryNSamples?
You are right that they do not relate. The parameters in RegisterEveryNSamplesEvent set the number of samples to wait to arrive in the buffer (or leave the buffer in the case of output) before firing an event.
You can find a lot more specific information about this in the LabWindows help. If you go to LabWindows >> Help >> Contents >> Choose the Index tab and scroll down alphabetically to "DAQmx...", then you'll find the list of all those DAQmx functions. If you double-click one, you get a description of the function and each of the parameters. This might help clear things up for you. All these parameter names sound very similar and can thus be confusing, so this is a handy reference tool to clarify things. 🙂
12-30-2011 07:11 AM
Thank you somuch for your time!! Kind regards, willem