Woes with NIDAQmxBase on a Mac

[mauricev]

I am trying to do basic analog input on a 450 Mhz PowerMac G4 (10.4.11) using NIDAQmxBase 3.1 with 1.25 GB RAM. The PCI card is a MIO-16E-4.

First, to initialize NIDAQ, I call

SInt32 theError = DAQmxBaseCreateTask(kPlaceholderString,&theTaskHandle);

This line takes about 20 seconds to run. It takes time on the G5, but I think it's less than half that value. Does that sound too long?

Second, I'm getting a -200265 error on doing analog collection. I'm passing APFI0 to the theTriggerSlope in the line below:

theError = DAQmxBaseCfgAnlgEdgeStartTrig(gTaskHandle,theTriggerSource,theTriggerSlope,theTriggerLevel);

This code works fine on the 6251 card. The trigger is physically wired to PFI0 on the BNC-2090A.

Third, previous version of NIDAQmxBase had to be run in its own application because it re-entrantly calls into Mac HIToolbox and therefore couldn't run inside a multi-threaded application. Has this limitation been removed?

Fourth, does this version support Intel Macs?

[mallorim]

Hi Maurice,

1)     While this does seem like a long time to run, it is possible that this is fine. DAQmxBase was developed in LabVIEW with the Driver Development Kit and therefore, the first time you call that function, it has to load the entire .dll into memory. When I placed this function down in LabVIEW on a fast computer, it took at least 8 seconds to load and this was in its native environment.

2)     For the MIO-16E-4, I do not believe that there is an APFI line. Try instead connecting to pin 11 or PFI 0. In the C Function Reference Help Document, for the function DAQmxBaseCfgAnlgEdgeStartTrig, it says that the only terminal that can be used as a trigger source for E-series cards is PFI0. Try this and see if the error is removed. You can also take a look at the Knowledge Base: Why Does My Specified Channel Not Work as an Analog Trigger Source in DAQmx?

3)     I will have to look into this, to see if this version of DAQmx Base will run inside a mutli-threaded application.

4)     With regards to support for Intel Macs, the Readme for version 3.1 says NI-DAQmx Base 3.1.0f2, the LabVIEW 8.2 support is mass compiled for PowerPC. The VI support will function properly in LabVIEW 8.2 for Intel, but should be mass compiled for faster load times.

You can also look at the Knowledge Base Documents: Using LabVIEW and NI Hardware on Macintosh Computers with Intel x86 Architecture and NI Data Acquisition Support for the Intel Macintosh.

Hope this helps, Mallori M.

[pstys]

1) the initial delay at the first call to any mxBase function is "normal"; apparently a lot of startup stuff goes on and no way around it.

2) I also noticed that mxBase calls are not thread-safe. I wish they were. NI: are they in 3.1?

Peter.

[mauricev]

OK, it is PFI0, but what tripped me up wasn’t only this error, but apparently when the card is driven by 3.1 under OS X, it wants a trigger signal of a longer duration and more voltage. That is, we were running fine with this card under OS 9. After I fixed, PFI0, it still wouldn’t run until I lengthened the trigger pulse and increased the voltage.

Regarding multi-threading, I want to make clear that it was NIDAQmxBase itself wasn’t the problem but for some bizarre reason, it makes calls to the Mac’s HIToolbox and that is not thread safe. This means that if it still makes these calls, it will probably crash eventually; otherwise, it may work!

The knowledgebase article regarding the Intel Macs is out of date, so it’s not clear if the other cards, such as the M-series cards, are now supported.

[pstys]

To me there is no reason to call the HIToolbox so I'd urge NI to remove these extraneous calls so the drivers are thread-safe.

P.

[Tom_W_[DE]]

Hi All-

NI-DAQmx Base 3.1 supports both PowerPC and Intel Macs.  The "C" interface is a compiled LabVIEW .dll that is fully compatible with both platforms.

No version of NI-DAQmx Base is designed to be multi-thread safe.  Aside from the interaction with the apparently non-threadsafe HIToolbox (which I'm unaware of but which might be a result of the reliance of NI-DAQmx Base on the LabVIEW runtime engine), the driver code for NI-DAQmx Base itself is not designed for multi-thread safety.  This is basically due to the fact that NI-DAQmx Base does not have persisted storage features to allow for proper global device and resource reservation (a la the MAX database used by NI-DAQmx for Windows). 

This allows NI-DAQmx Base to port quickly and support a variety of platforms but has the unfortunate side effect of requiring the user to access the device/driver from only a single thread at a time.  This limitation is unlikely to change in the forseeable future.  If multi-thread operation is very important to your application, I would encourage you to file a product suggestion (feature request) here.

FYI for any LabVIEW users- the LabVIEW interface for NI-DAQmx Base 3.1 is compatible with Intel but the API VIs are compiled for PowerPC.  This means that they may need to be re-mass-compiled for quicker loading or higher performance on Intel Mac.  This limitation does not apply to the "C" interface, and the mass compiling will likely be changed to Intel Mac by default in a future release of NI-DAQmx Base.

[mauricev]

The lack of thread safety in NIDAQmxBase in and of itself is irrelevant. I can't think of a reason to call it from multiple threads, but because (at least the old version) calls the HIToolbox it cannot be used in any secondary thread because the HIToolbox is called from the primary, application thread. And it's next to useless inside this thread because it blocks the application's GUI from running when it's doing a task. My solution was to put all the DAQ calls in their own application and then send and receive messages to my main application.

Regarding the Intel Macs, I'm still confused. That knowledgebase article says the old version supports only NI's USB hardware on Intel, but you seem to be implying the "C" interface will support other cards, including the M-series.

[Tom_W_[DE]]

Hi Maurice-

Apologies for the confusion.  That KB is out of date- I haven't seen an Intel Mac with PCI slots yet, but we fully tested PCIe M Series and all supported USB products (including the newly-supported USB-9233, USB-9211A, USB-9215A, and USB-621x devices) with NI-DAQmx Base 3.1.  I'll make sure that KB is updated accordingly.

Thanks for the heads up-

[pstys]

I WOULD want to call a continuous data acq task from a thread leaving the main thread of my app (and therefore the GUI) responsive to other tasks.

P.

[stilly32]

I would like to expand on what Tom was saying:

 It kind of depends on what you mean by "thread-safe". You can make DAQmx Base calls in any thread you want to, but you do want to ensure that certain calls are not made in different threads at the same time. I'm pretty sure you're using C to code, but the same would apply to LabVIEW and parallel calls. Hopefully this helps:

Can you run DAQmx Base code on a dual core machine? Yes - the DAQmx Base calls will be executed sequentially in C and will be fine.

Can you run AI and AO tasks at the same time in the same program? Yes - again the DAQmx Base calls will be sequential, the HW will be generating or acquiring data and using DMA and buffers per task. This also applies to other types of I/O and other devices as long as you keep in mind the next two use cases.

Can I spawn different threads and configure and run different tasks in different threads - No, DAQmx Base is not supported in this use case, there is a chance for race conditions, especially in the creating and clearing of tasks (due to lack of persisted storage pointed out by Tom).

Can I configure sequentially, then perform reads\writes in different threads, then clear tasks sequentially? - This specific case hasn't been fully tested, but it should be ok. I've done plenty of read/writes in parallel after ensuring that the Create tasks and clear tasks were called sequentially (good old error cluster) and haven't run into any issues.

Hope this helps,

Andrew S