Hi Chris,
Just want to make sure - the new nightly won’t work with NI DAQ mx base 14
anymore, only 3.7, right? If so I’ll make sure the rest of the lab gets a
heads up.
- Evan
Just want to make sure - the new nightly won’t work with NI DAQ mx base 14
anymore, only 3.7, right?
Yes, that’s correct.
Chris
Hi Evan,
After downgrading all my test systems to NI-DAQmx Base 3.7, I’m no longer seeing the “samples requested have not yet been acquired” errors with the USB-6212. (Well, I did see a couple instances on some of the test machines, but nothing like the massive spew I had been getting. I assume the remaining errors are due to system load.) If it turns out that the PCIe+Thunderbolt rig still has issues under 3.7, then the USB DAQ should be a workable alternative.
Cheers,
Chris
I’m no longer getting the errors on the Mac Pro after downgrading to
NI-DAQmx Base 3.7. I’m still getting warnings about skipping 10-20
executions every 5 minutes or so with the USB, and every 15 minutes with
the Thunderbolt-PCIe. Do you get these on your Mac Pro? I don’t remember
getting them on ours.
I’m still getting warnings about skipping 10-20 executions every 5 minutes or so with the USB, and every 15 minutes with the Thunderbolt-PCIe. Do you get these on your Mac Pro?
I see those sometimes (although not at those specific intervals, I think). Those warnings come from MWorks, not NI-DAQmx Base. Presumably, they’re caused by one or more threads getting backed up due to system load or some other scheduling issue. With NIDAQ devices in particular, data has to hop through multiple processes and threads before it reaches MWorks; the delays could be happening anywhere along the route.
My feeling is that this isn’t something you need to worry about. Of course, if it seems like it’s becoming a problem, I’ll try to investigate what’s happening.
Chris
Hi Evan,
After many weeks of back and forth with NI, we’ve finally reached some resolution on the “samples requested have not yet been acquired” error with USB devices.
The NI applications engineer that I worked with (Clint, who was very helpful and really stuck with it despite the length of the process) was able, using my sample code, to reproduce the issue with a USB-6212 and NI-DAQmx Base 15.0, on a Mac with USB 3 running OS X 10.10. (Interestingly, he was not able to reproduce it on an older Mac with only USB 2, which lends some support to my hypothesis that USB 3 is involved somehow.) After that, Clint escalated the issue to NI’s R&D department. After examining my test code, they provided him with their best guess of what’s happening.
To summarize: The process of acquiring analog samples on a USB DAQ and getting them in to a Mac application involves three different “actors”. The first is the DAQ itself, which acquires the samples and stores them in on-board memory. The second is a software component, running on the Mac but not under the control of the end-user’s software (e.g. MWorks or my test code), which periodically pulls new samples off the DAQ hardware and stores them in the Mac’s memory. The third is the end-user application, which periodically uses NI-DAQmx Base functions to request new samples from the second component (not directly from the DAQ).
The issues arise in the second component. Although it’s doing its best to pull samples from the DAQ in a regular, timely fashion, it’s ultimately just another process running on a time-sharing, non-realtime operating system. While it is, on average, capable of keeping up with the stream of incoming data, there are times when (due to CPU load, USB bus traffic, or some other resource allocation issue) it gets behind. It will catch up (if it didn’t, you’d eventually get a distinct, buffer-overflow error due to the DAQ’s onboard memory filling up), but during the intervals where it’s behind, requests for new samples from the end-user application will fail.
For example, my test code uses a sampling rate of 1kHz and tries to read 3 samples every 3ms. Between one read attempt and the next, the DAQ has definitely acquired 3 new samples. However, the “middle man” process may not have had a chance to pull those samples. Therefore, when the test code requests new samples, the middle layer reports that they aren’t available.
Unfortunately, there’s really no solution that eliminates this behavior. You can avoid the errors by increasing the read timeout. (In my test code, the initial timeout was 3ms. Increasing it by just 20% appears to eliminate the errors, at least over a 5-minute run.) However, you still have to live with the fact that samples are sometimes going to come in later than you’d expect.
A few questions remain unanswered:
- Why don’t we see this issue with NI-DAQmx Base 3.7?
- How and why is USB 3 involved (if it is at all)?
Clint wasn’t able to provide much insight into these. Also, I don’t think any of this applies to PCIe devices, which presumably use DMA or some other high-speed transfer mechanism to get samples off the DAQ.
Given this information, I plan to add an analog read timeout parameter to MWorks’ NI-DAQ interface. Beyond that, though, I’m not sure how we should proceed.
It still seems like, at this point, NI only just barely supports macOS, so it’s hard to see them as a reliable supplier of MWorks-compatible DAQ hardware in the long term. Also, the “middle man” approach that NI uses for data transfer from USB DAQ’s isn’t the only way to do things. For example, with LabJack devices, the code for pulling samples over USB runs in the end-user application, which may result in better overall performance (since there’s one less software component that needs to be scheduled and run by the OS).
For the record, the reference number for the support request that was just closed is 3109950.
Cheers,
Chris
Hi Chris,
Thank you for working to sort this out. This will be great information to
have when making hardware decisions going forward.
Best,
Evan
Hi Evan,
I plan to add an analog read timeout parameter to MWorks’ NI-DAQ interface.
This is done and available in the nightly build. The parameter is called analog_read_timeout. If omitted, it defaults to the value of update_interval (which preserves the old behavior).
Cheers,
Chris