Tasks in NIDAQmxBase (vs. NIDAQmx)

[Orjan Friberg]

Hi,

I'm porting a Windows/NIDAQmx program to Linux/NIDAQmxBase which uses a number of tasks. I'm trying to assess whether Base will be usable for our program which uses a number of tasks (most of which live run indefinitely). The NIDAQmxBase README says:

NI-DAQmx Base is designed to complete one process/task per board functionality at a time. You can have one task that does DIO and another task that does AI on the same board at the same time. You cannot, however, run two AI tasks on the same board at the same time.

Does this mean that one task each for analog in, analog out, digital in, digital out (and clocking) is ok, but adding any analog/digital in/out task is not? Are there any additional constraints/gotchas compared to NIDAQmx?

Also, is there a well-defined behaviour when too many tasks are used (such as task creation failing) or is the behaviour simply undefined?

Thanks in advance,
Orjan

[Neil_S.]

Orjan,

This means that NI-DAQmx Base is not thread safe.  Therefore doing something like

 is not recommended.  While doing this

is okay.  In the second case the NI-DAQmx Base Vis are excuted in series rather than parallel avoiding access to the driver from two threads simultaneously.

If you call two NI-DAQmx Base VIs in parallel the behavior is not defined, you could experience the results of race conditions, strange data and incorrect operation.

As a side note, I see that you have posted twice about this project to port from NI-DAQmx to NI-DAQmx Base on Linux.  I also see that you are using the PCIe-6259 which is also supported in NI-DAQmx 8.0 for Linux.  Obviously this was released some time ago, and it does not officially support newer distros, but it still has several advantages over NI-DAQmx Base.  We have been exploring where we would like to go with our Linux support and are currently evaluating our next steps.  What distro are you currently using?  Would you be more interested in using NI-DAQmx on Linux?  Are you using any USB DAQ devices?  Could you provide any details about your application?  What motivated your port to Linux?

Thanks for the feedback,

Neil S.

Multifunction DAQ

Product Support Engineer

National Instruments

Message Edited by Neil S. on 10-03-2008 10:08 AM

[Neil_S.]

I just noticed that you are using C in your other thread.  The same is true in C.  You can't spawn two threads or have two processes that access NI-DAQmx Base at the same time.  If you have two threads or processes that need to access the driver you will need to add protections such as semafores or other thread synchronization techniques.  Hopefully the LabVIEW code examples are still helpful to show the flow that I mean.

Regards,

Neil S.

[david.miller]

Neil,

I'm also a linux NIDAQmxBase user and I'd would be really enthusiastic about updated linux support as well. I think there's several people (including myself) who would like to see the driver ported to debian. It's not commercially supported, but with the number of ubuntu users there's really great forum support. Also, I'm currently using RH5, but would like to see the 'non-base' driver with linux 2.6 kernel support. The 2.6 kernel has a number of real-time features directly built-in. Users can set real-time priorities of certain tasks and gain significant improvements in OS jitter.

The NIDAQmxBase driver doesn't really do justice to my application, but I'm hesitant to move back to such an outdated OS as RH3 because of performance hits and difficulties with other software that I currently use. I think this causes many users to default to comedi. 

[Neil_S.]

David,

We appreciate the feedback.  There is a real possibility that we will be able to release a version of NI-DAQmx 8.0 that has been updated to install on the 2.6 kernel and would install on many newer distributions.  Adding support for Debian based distributions is a bit further out, but is also something we have seriously been considering.  What devices are you currently using?  The first newer release of NI-DAQmx for Linux will likely not add any hardware support.  It will just fix the issues that prevented installation on newer distros.  Would this be enough for your current needs?

I am also curious from a user that seems familiar with the comedi drivers, what features does NI-DAQmx provide that you lack in a driver such as comedi?  What features of NI-DAQmx would you be most enthusiastic about being supported on Linux?

Thanks,

Neil S.

[pawel]

Hi Neil

Is it OK though to do that first example on two physically different cards?

cheers

Pawel

---

@Neil S. wrote:

Orjan,

This means that NI-DAQmx Base is not thread safe.  Therefore doing something like

 is not recommended.  While doing this

is okay.  In the second case the NI-DAQmx Base Vis are excuted in series rather than parallel avoiding access to the driver from two threads simultaneously.

If you call two NI-DAQmx Base VIs in parallel the behavior is not defined, you could experience the results of race conditions, strange data and incorrect operation.

As a side note, I see that you have posted twice about this project to port from NI-DAQmx to NI-DAQmx Base on Linux.  I also see that you are using the PCIe-6259 which is also supported in NI-DAQmx 8.0 for Linux.  Obviously this was released some time ago, and it does not officially support newer distros, but it still has several advantages over NI-DAQmx Base.  We have been exploring where we would like to go with our Linux support and are currently evaluating our next steps.  What distro are you currently using?  Would you be more interested in using NI-DAQmx on Linux?  Are you using any USB DAQ devices?  Could you provide any details about your application?  What motivated your port to Linux?

Thanks for the feedback,

Neil S.

Multifunction DAQ

Product Support Engineer

National Instruments

Message Edited by Neil S. on 10-03-2008 10:08 AM

---

[Tom_W_[DE]]

Hi pawel-

No, you should avoid multi-threading completely in any NI-DAQmx Base application.  Even though you might be using physically separate hardware, the same software internals are shared and are not designed to be multi-thread safe.

[pawel]

Thanks Tom