Mac OS X DAQmx Base error -200284; unreliable scanning

[WM_John_Weeks]

I am using NI-DAQmx Base to build a plug-in for my company's main application. I am having some problems...

The plugin is being developed on both Windows, where I am using NI-DAQmx and on Macintosh OS X using NI-DAQmx Base. The plug-in works correctly on Windows with NI-DAQmx.

I am scanning and reading in a background loop; I set the timeout on DAQmxReadAnalogF64() to zero so that I can read just the data that is currently available, and then let the main application display what has been acquired so far.

1) Every call to DAQmxReadAnalogF64() returns error code -200284, DAQmxErrorSamplesNotYetAvailable. This is true even when all the samples asked for have been read. I'm asking for all the samples each time (that is, if I'm expecting a total of 200 samples, I set the numSampsPerChan to DAQmx_Val_Auto and arraySizeInSamps to 200).

2) Doing it this way, where I get a more or less random-sized chunk of data each time, I often miss a sample or two or three. That is, the sampsPerChanRead when summed for all the calls to DAQmxReadAnalogF64() don't sum up to 200 (using the previous example).

3) Once I've called into DAQmxBase, I can't quit the main application. Is something about the Labview engine intercepting my Quit menu event? I would guess that DAQmx Base on Mac OS X hasn't been tried in a plug-in? Further, the main application is a CFM Carbon application and the plug-in is Mach-O.

4) It takes a very long time to make the first call to DAQmx Base. I guess that's the Labview engine loading, eh?

Thanks to anyone who has thoughts, observations, solutions, sympathy, etc.!

[WM_John_Weeks]

I have a bit of new information: it seems that when samples are dropped, it is a single sample during multi-channel acquisition. I have tried this while scanning two channels; after a sample is dropped, the data for the two channels is swapped. So it seems that pretty often (but at random times) a single sample is dropped while transferring from the board to the memory.

This happens with either DAQmx_Val_GroupByChannel or DAQmx_Val_GroupByScanNumber.

***
I forgot some important information:

Mac OS X 10.3.7
DAQmx Base 1.4.0f2
Dual 2 GHz G5
512 MB RAM

[Salvador_Santolucito]

Hi John,

First lets see if I can clear up a little confusion. DAQmx is only for Windows operating systems. DAQmxBase is for the Mac OSX operating system. Are you developing two different sets of code (one for each)?

You said that it is working correctly in DAQmx. However, your questions all pertain to DAQmx function calls. I'm assuming that these are really referring to the DAQmxBase function calls on the Mac. Correct?

1) For some reason your acquisition is timing out. You are not getting the specified number of data points in the specified timeout period. Are you using an internal or external clock? What is your sampling rate?

Can you post your code for the DAQmxBase function calls?

2) This is related to #1

3) I'm not really sure what is going on here. Can you describe the issue a bit more?

4) Yes, it takes LONG time to load the DAQmxBase functions. DAQmxBase was written in LabVIEW (not in C like our other drivers) to get the development done quickly. For this reason it takes a bit longer than typical to load the driver.

-Sal

[WM_John_Weeks]

Sal- Thanks for taking a look. I admit my post was written fast at the end of the day and perhaps wasn't as clear as it might have been.

>First lets see if I can clear up a little confusion. DAQmx is only for Windows operating systems.
>DAQmxBase is for the Mac OSX operating system. Are you developing two different sets of code (one for each)?

It is one code base with #defines to make DAQmx calls into DAQmxBase calls. There are, of course, some places where I have to add ifdef's to remove functionality that is missing under DAQmx Base.

>You said that it is working correctly in DAQmx. However, your questions all pertain to DAQmx
>function calls. I'm assuming that these are really referring to the DAQmxBase function calls
>on the Mac. Correct?

Oops. I copied the calls from the code where they appear as DAQmx calls, but they are changed to DAQmxBase calls behind the scenes. You are correct- my problems are with DAQmxBase calls on Macintosh.

>1) For some reason your acquisition is timing out. You are not getting the specified number
>of data points in the specified timeout period. Are you using an internal or external
>clock? What is your sampling rate?

The acquisition is happening during the event loop of the host application (the DAQ code is in a plug-in). The intent is to get whatever samples have been acquired so far each time through the event loop. I do that by passing DAQmx_Val_Auto to DAQmx(Base)ReadAnalogF64(). I use the sampsPerChanRead parameter to know how many samples I get each time so that I can display partial results.

This is with an internal clock; it happens with scanning rates anywhere from 10 to a few thousand samples per second. It looks to me like pretty often I make the call after the first channel has been sampled but before the second channel. In that case, I lose a data point and subsequent calls return data with the channels swapped. I'm doing this while scanning two channels; it works when scanning only one and I haven't tried three yet.

>Can you post your code for the DAQmxBase function calls?

That's difficult- my code implements functions that can be called from our application's built-in language so the code is spread around a bit. It comes down pretty much to this:

DAQmxCreateTask(taskname.str().c_str(), &h);

do this twice:

error = DAQmxCreateAIVoltageChan(h, (i->getChannelName(devName)).c_str(), NULL, (*i).getCType(), (*i).getMinV(), (*i).getMaxV(), DAQmx_Val_Volts, NULL);

And read repeatedly at more or less random times:

readerror = DAQmxReadAnalogF64(h, DAQmx_Val_Auto, 0.0, DAQmx_Val_GroupByChannel, &(dAvailableReadArray[0]), dAvailableReadArray.size(), &nSamples, NULL);

dAvailableReadArray is an STL vector of doubles.

The problem happens whether I use DAQmx_Val_GroupByChannel or DAQmx_Val_GroupByScanNumber. Naturally, my unpacking code has to take that into account.

>3) I'm not really sure what is going on here. Can you describe the issue a bit more?

The DAQmxBase function calls are in a plug-in module loaded into our main product (Igor Pro, www.wavemetrics.com). We field an kAEQuitApplication Apple event to quit. After the first call into DAQmxBase, we don't get the Apple event. I'm presuming that this is because the Labview engine (which is basically an application, right?) is eating the event.

>4) Yes, it takes LONG time to load the DAQmxBase functions. DAQmxBase was written in LabVIEW
>(not in C like our other drivers) to get the development done quickly. For this reason it
>takes a bit longer than typical to load the driver.

And has other consequences, like putting a window into our window list!

Again, thank you for taking a look. I've written a lot and not all that clearly!

[Randy_H]

John,

Just to follow up on what Sal stated...

NI-DAQmx Base does not support a zero timeout (we don't mention it in the help file because we do not support it, but it is there in DAQmx). This is probably what is casing the timeout and possibly the other issues. Along with that, when you pass a -1 for the number of samples to read we do two things. First we see how many samples are default to read. Currently for E Series, if you do not use a timing function, this is zero. We also check the size of the buffer that is input. We give the minimum value of these to the actual read VI. In going through that code (if you have LabVIEW) you can see that the DMA reading will correct for the zero number of samples to read and give you what it has, but this will depend upon when the read is called relative to start because it could quickly overflow the DMA and overwrite data. But, because you are getting the timeout error, this error might be getting covered up. I know that this is a long explaination for a simple issue, but this is what is happening. I suggest using the DAQmxBaseCfgSampClkTiming call to set the default number of samples to read if you pass a -1 value to it. Also, do not pass 0 for the timeout as that is exactly what you will get, a zero timeout and always an error.

The window that is created is created by LabVIEW and you are nto the first to bring this up. We have a request in with LabVIEW to see if we can get this resolved. We hope to get this resolved, but it does sound like you have a workaround for now. Others have had luck at initializing all of the GUI items before making the first call to NI-DAQmx Base and resolving most of the issues, however, events may still be caught by the LabVIEW Run-time Engine.

Loading speed is the number one complaint we get about NI-DAQmx Base. Overall, that is not so bad when you think about everything else that could go wrong when writing a device driver. It is written in LabVIEW and uses static calls to VIs so we can use the same code base for Linux, Mac OS X, Windows, and PocketPC. LabVIEW for PocketPC in LabVIEW 7.0 and 7.1 did not support VIServer calls to the same machine. This is why the VIs are placed directly on the block diagram. Also, since the other purpose of this driver is to be a reference for register level programmers, it is easier to follow this way. We are working on trying to speed up the loading time of the driver, but from what I have mentioned, it will take a rearchitecture of the driver and supporting environments to make this happen. We will get there and we thank you for your support on this issue.

Randy Hoskin
Measurements RLP (NI-DAQmx Base)
National Instruments

[WM_John_Weeks]

Randy, thanks! You and Sal are being very generous with your help.

>First we see how many samples are default to read. Currently for E Series, if you do not
>use a timing function, this is zero.

Woops. In my effort to gather the calls to DAQmxBase from the various parts of my code, I forgot the call to DAQmxCfgSampClkTiming():

NIerror = DAQmxCfgSampClkTiming(h, src, frequency, edge, SampleMode, nSamples);

where nSamples is set to the total number of samples to be acquired.

>Also, do not pass 0 for the timeout as that is exactly what you will get,
>a zero timeout and always an error.

OK- I'll give it a try with a non-zero timeout. My intention was to get whatever is available without spending more time than necessary waiting for nothing. Any guidance on the what is the minimum time that is large enough?



The long start-up time is annoying, but it is not the largest issue by a long way. If there is any single thing that I would prioritize above others is to implement access to (or a replacement for) DAQmx properties.

[WM_John_Weeks]

>First we see how many samples are default to read. Currently for E Series, if you do not
>use a timing function, this is zero.

Woops. In my effort to gather the calls to DAQmxBase from the various parts of my code, I forgot the call to DAQmxCfgSampClkTiming():

NIerror = DAQmxCfgSampClkTiming(h, src, frequency, edge, SampleMode, nSamples);

where nSamples is set to the total number of samples to be acquired.

>Also, do not pass 0 for the timeout as that is exactly what you will get,
>a zero timeout and always an error.

OK- I'll give it a try with a non-zero timeout. My intention was to get whatever is available without spending more time than necessary waiting for nothing. Any guidance on the what is the minimum time that is large enough?



The long start-up time is annoying, but it is not the largest issue by a long way. If there is any single thing that I would prioritize above others is to implement access to (or a replacement for) DAQmx properties.

[WM_John_Weeks]

>Also, do not pass 0 for the timeout as that is exactly what you will get,
>a zero timeout and always an error.

OK- I tried it with timeout set to 0.001, 0.01, and 0.1 and I get exactly the same results- sometimes (pretty often) a single sample is dropped causing the data for two channels to be swapped.



On a related topic, the ReadMe file says, "DAQmxBaseIsTaskDone does not currently support analog input." How should I check to see if an acquisition is finished? It seems like if asking for samples before the acquisition is done is unreliable (see above) then waiting for it to be finished would be a possible work-around. Ask for zero samples and check the error return from DAQmxBaseReadAnalogF64()?

[Salvador_Santolucito]

Hi John,

Let me see if I can explain the timeout a little more clearly. The timeout is the MAX amount of time that the function will wait for all of the data points to be read. So that means you can set the timeout for 10 seconds and if all the data points are read in 1 second then the DAQmxBaseRead function will return before the full 10 seconds are up.

I would suggest using a larger timeout since you should be getting all of your data points.

You are correct that there is no isTaskDone in DAQmxBase. You probably won't need it. If you are doing a finite read, you will know when the read has completed by the fact that it finishes and returns data. The isTaskDone function is not really necessary for analog input acquisitions.

-Sal

[WM_John_Weeks]

---

@salvador Santolucito wrote:
Hi John,

Let me see if I can explain the timeout a little more clearly. The timeout is the MAX amount of time that the function will wait for all of the data points to be read. So that means you can set the timeout for 10 seconds and if all the data points are read in 1 second then the DAQmxBaseRead function will return before the full 10 seconds are up.

I would suggest using a larger timeout since you should be getting all of your data points.

You are correct that there is no isTaskDone in DAQmxBase. You probably won't need it. If you are doing a finite read, you will know when the read has completed by the fact that it finishes and returns data. The isTaskDone function is not really necessary for analog input acquisitions.

-Sal

---

I understand what a timeout is. But I would expect that having a call time out would not lose data. I can think of two ways that could be considered correct:

1) The call times out and no samples are returned. When sufficient time has elapsed, all the samples are returned.

2) The call times out and just the samples acquired so far are returned. This has to be programmed so that no data is lost- if the first channel has been sampled but no the second, it must not return *or lose* the data from the first channel, it should return it on the next call.


But it sounds like you are telling me that I'm not allowed to call DAQmxBaseReadAnalogF64() before the acquisition is finished, or at least I must give a timeout that allows it to wait until all samples are acquired.

How do I work this when external clocking is used? I guess I'm supposed to know how long it takes to sample when using external clocking? What if the external clock is based on an irregular event?

Currently, it seems that DAQmx Base on Macintosh behaves like 2) above, but without the important proviso that it not lose data.

I have attached a file containing C code that illustrates what I'm trying to do, and the problem. I would expect that the program would not give me any points until all are available, since the numSampsPerChan parameter is set to the total expected number of points. But the program returns some points each time it times out, but sometimes loses a one point for a single channel.

Careful- it prints out lots of stuff; I did that to try to see where the data is going.