Line Digital Output very slow with DAQmx

[ElbaTech]

Hello,
I am "translating" some LabWindows/CVI code written with Traditional NI-DAQ into the  NI-DAQmx version, because I wish to use M-series cards.
I am experiencing a drastic performance slow-down in simple digital output generation, therefore I wish to ask what I am missing.
I need to set many individual logic lines to either logic 1 or logic 0.
However I  will explain the problem with a practical example: let us switch a line alternatively to logic 1 and to logic 0 as to simulate a clock signal (square wave).

I have written the following Traditional NI-DAQ code:

//... configure the board and the digital port as output...
for( ; ; )
{
    DIG_Out_Line(daq_dev, dio_port, dio_line, 0); 
    DIG_Out_Line(daq_dev, dio_port, dio_line, 1); 
}

The code was translated into the NI-DAQmx code:

// ...create a DO task relative to dio_port and dio_line
for( ; ; )
{
    DAQmxWriteDigitalScalarU32(theDOTask, 1, 10.0, 0, NULL);
    DAQmxWriteDigitalScalarU32(theDOTask, 1, 10.0, 255, NULL);
}

Both software versions run perfectly, BUT with a dramatically different timing (same PC, of course):
-two consecutive rising edges of the DO signal in the case of Traditional NI-DAQ occur in 22 microseconds
-two consecutive rising edges of the DO signal in the case of NI-DAQmx occur in 802 microseconds

Please, advice me on the eventual mistake I have done and how to set a workaround.

(Info: signals measured by means of a HP 54620A logic analyzer
LabWindows CVI version 8.0
Traditional NI-DAQ 7.4
NI-DAQmx 8.0
WinXP Professional
PC with Pentium4 3 GHz).


Thanks in advance,
Marco

[jcarbonell]

Try starting the DAQmx Task before going into your static output loop.

[ElbaTech]

Hi,
many thanks for your suggestion, which actually fixes the problem.
The time elapsed between two consecutive rising edges is now dropped down to 32 microseconds, which is fast enough for my application.
I definitely must study better the Task model of NI-DAQmx 🙂

The purists could ask why, however, NI-DAQmx look slower than Traditional NI-DAQ, but of course this can depend on my software in this case, although it is so simple that I don't believe it introduces fuzzy delays. Have NI a Traditional vs. mx comparison sample code in terms of performances, for example in DO or AI or whatever else ?

I still do not know the implications of having many tasks concurrently started in a working application program (slow down of the overall performances ? Memory problems ? Nothing at all ?), neither the reflections of having cocurrently started tasks for different resources in a multifunction board, say AI and DO or so... Maye you will have the time and patience to address me to some document about this....

Thanks a lot again for your help,
bye,
Marco

[Graziano]

Hi people!
   Since I'm really interested in this  topic, I'd ask something....

   I experienced the same problem (low rate of  samples), but in my case I can't fix it  with StartTask(). the problem is that I have 2 tasks (one for digital read, one for write), and if I start both tasks my target system seems to hang.

   My application is a dll,  called  several times from a third party sw, so I need  to do many read-write, in asynchronous order.  That's why I tried to start both tasks at the beginning of the application.  Any help is welcomed!

graziano

PS.: grazie Marco per questo post, è stato utilissimo per scoprire un po' di concetti anche per me, che tutto sommato uso DAQmx da 2 anni!  In particolar modo riguardo il vecchio Traditional DAQ.

[ElbaTech]

Hi Graziano,
many thanks for your reply and P.S.

Unfortunately I do not have direct experience on the problem you have mentioned. However, while looking for a solution to my problem before posting the above question, I found the following post, which could be useful to you:
http://forums.ni.com/ni/board/message?board.id=70&message.id=3325&query.id=0#M3325
Here you can find a reply by "reddog" who explains that in order to read/write on the same line you can use a function called DAQmxSetDOTristate(). I wasn't actually able to find such a function in DAQmx 8.0, but I believe it has been replaced by DAQmxTristateOutputTerm(). Using this function should speed-up read/write operations on the same line or on a whole port....

Bye,
Marco

[jcarbonell]

Hi Marco,

Since you are trying to create a square wave, have you considered using one of the counters on the M-Series device?

Jeff

[ElbaTech]

Hi Jeff,
unfortunately my scenario is a bit complicated and I cannot use the counter in place of digital lines. However starting the task reduced the timing to about 33 us, which is ok for me. As I said before, one could ask why Traditional NI-DAQ show a better 22 us response.....
Thanks,
Marco

[Jonathan_Brumley]

Hi Marco,

I benchmarked a similar comparison with an M series device on my Dell 1.8GHz computer using LabVIEW and Windows XP.  I found that Traditional DAQ write time was about 15 microseconds and DAQmx was about 19 microseconds.  It sounds like your computer may be a little slower than mine. 

For digital reads and writes, DAQmx is slightly slower than Traditional DAQ mainly because the API is more flexible.  For instance, it allows specifying whether lines are inverted in the channel configuration.  Also it allows a variety of reads (port-based, single line, array of lines, etc.), and it allows different port sizes (U32, U8, etc.).  Also, it supports multi-threaded access on a per-task basis.  These additional features require the implementation to consider more cases, and there is some small amount of additional synchronization overhead.  Of course, all this extra flexibility is no good if you don't need it and if what you're most concerned about is performance.

I work on the NI-DAQmx team and we're aware that single point performance is critical.  We're experimenting with some optimizations specifically for digital single port reads/writes.  Digital single port reads/writes is one case where Traditional DAQ (especially the Traditional DAQ C API) is extremely efficient and it is a hard compare.  Single point digital reads and writes are especially critical for control applications where hardware-timed (correlated) digital is inappropriate. 

Two other facts to note:
1. Because of the improved state model, DAQmx is overall much faster than Traditional DAQ if you consider all types of driver operations including buffering, single point AI, retriggered AI, multithreaded operation, etc. 

2. For the absolute best single point performance with DAQmx, LabVIEW Real-time is the way to go.  Using the LabVIEW ETS real-time system, DAQmx can perform a digital port operations in less than 5 microseconds on an 8176 controller, and there is almost no jitter compared with what you get in Windows.  The main reason for the improved performance is that the real-time operating system is a single mode OS.   There is no user to kernel transition like on Windows.  On my Windows XP box, the kernel transition adds about 10-12 microseconds of overhead. 

[Graziano]

Hi Jonathan,
   thank you!!! It was the clearest explanation of differences between  Traditional and DAQmx!

Bye!

graziano

[Jonathan_Brumley]

Hi Graziano,

I haven't been able to to reproduce your problem with Starting two digital tasks. 
To reproduce, I created one digital input task with lines 0:3 and one digital output task with lines 4:7, I start both tasks and then I take turns reading from one task and writing to the other.  It works fine and my program doesn't hang.

Can you create a single Digital Output task that includes all your digital lines?  With a digital output task, the lines are by default bidirectional.  You can call DAQmx Read and DAQmx Write on all lines.  Also, you can configure the lines for input or output on the fly by setting the channel property.