DAQmx digital slow compared to Trad DAQ

[jjsomer]

Forgive me for re-hashing this issue as I have seen many threads regarding the performance decrease from Trad DAQ to DAQmx.  However, I haven't seen a solution for the problem that I currently am encountering.

Out of necessity, I am upgrading VB6 software that currently uses Trad DAQ drivers to use DAQmx drivers to increase data acquisition flexibility.  I have modified the code and everything appears to work without much problem.  However, the DIO control on a PXI-6508 card is significantly slower.  I have timed a typical task in the software with the DAQmx drivers and the time elapsed is 29 s.  The same task using Trad DAQ drivers takes 0.2 s.  This obviously is causing significant performance problems in my software. 

A little backgound.

My application uses three 8-bit DIO ports to communicate with external devices - a control port, an address port, and a data port.  The control port and the address port are output only ports.  The data port, on the other hand, can be either an output or input port depending on the functionality.  When I want to clock data to the device, I need the PXI-6508 to set the bits on the data port.  When I want to read information from the external device, I need the PXI-6508 to read the bits on the same data port.

As of right now, I have written my software to create one output task for each port (3 total).  When I go to write data to the port, I start the task, write the data to the output port, and stop the task.  When I want to read data from the data port, I go through the whole process for each read process.  So every time I want to read data from the data port, I create a DI task, start the task, read the data, then stop the task.  This set up seems to work without problem, only at a much slower pace.

How can I improve the performance of the DIO control?  I need this to be extremely efficient, since communication with the external device is nearly constant while the application is running.

Thanks for any help.

[Robert_F]

Hello Jjsomer,

Normally, you only want to create/configure and start each task only once.  Then you can read/write to the task several times in a loop without reconfigure the task.  After your application is completely done, you want to stop/clear the task.  If you want to restart a task, then you just have to stop and start the task without resetting it up.  Creating/configuring and stopping/clearing the task every time you want to read/write to a digital port can very time consuming.

29 seconds sounds like a very long time for your application to take even if you are creating/configuring and stopping/clear the task every time you read/write to a digital line.  Are you running any other applications while you executing this program? Are there any delays that are created between reading/writing data out on the digital ports? 

[jjsomer]

Thanks for the reply.

As I mentioned previously, I have one digital port that can either be input or output.  If I create an output task for that port and start it running, then create an input task for the same port and start it running, I receive an error that says the digital lines are reserved.  So, I have since modified my software to create an output task and an input task for this port and start the output task running.  When I want to set the port status, I simply write digital lines.  The speed lost from the traditional daq method is acceptable ~ 20 times slower.  When I want to read the data from this port (set the port up to be an input port), I stop the currently running output task, start the previously created input task, and then read the input port.  If I do one or the other, the software works fine.  If I switch the port direction, I experience a significant slow-down.

The problem I am encountering is downloading 20,000 bytes of data to a microprocessor on an external device using this one digital port.  The software sets a byte on this digital port, clocks the data to the micro with another output line on another digital port, then checks the one byte response from the micro on the same data port.  So, the process of stopping one task (output or input) then starting the other task occurs 40,000 times (20,000 data bytes sent + 20,000 responses).  This takes a significant amount of time to perform.

I had hoped there was a way to change the direction of the port without necessarily stopping the task and starting another task.  But, from your response, this does not sound possible.  Is the way that I have it set up currently the most efficient way to handle changing the digital port direction?

Thanks for your assistance.

Jeremy Smith

[jjsomer]

29 seconds sounds like a very long time for your application to take even if you are creating/configuring and stopping/clear the task every time you read/write to a digital line.  Are you running any other applications while you executing this program? Are there any delays that are created between reading/writing data out on the digital ports?

The time details were for a particular task in my software.  This task consists of several digital port writes with software coded time delays.  It was only meant for reference to detail the amount of slow-down from traditional daq to daqmx.  There are no other applications running on this pc.  There are several tasks running at one time on the PXI-6508, 7 tasks total.

Task A execution with Traditional DAQ drivers ~ 0.2 seconds.

Task A execution with DAQmx drivers initial attempt (create a fresh task for each digital read/write) ~ 29 seconds.

Task A execution with DAQmx drivers most efficient method I've found (two tasks - one output and one input running at one time - only stopping/starting tasks when the type of access required changes for a particular port) ~ 4 seconds.

Hopefully, this isn't too confusing.  What I really need is the most efficient method of changing direction of a digital port.

[Robert_F]

Hello Jeremy,

Here is a simple example in LabVIEW that demonstrates how to read from a digital output channel.  The only difference between VB6 and LabVIEW is that LabVIEW is going to use subVIs and VB6 is going to use functions that have all the same parameters.  Make all of your tasks Digital Output tasks, then make them tristate when you would like to read from those channels.  This will allow you to not stop and start the task.

Message Edited by Robert F on 09-13-2007 06:27 PM

[jjsomer]

Thanks for the reply.

I assume in your last response that I need to use the DAQmx funtion DAQmxTristateOutputTerm.  The function takes as an argument a string representing the terminal name.  I assume this is the same as the identification string I used to create the DO task - /Dev3/port0.

I am having a problem executing this function as it returns an error  - "Device not available for routing.  It is possible that the device needs to be reset or that the device is being reset.  If you are resetting the device, wait for the reset to complete.  For example, if you have used the device through Traditional NI-DAQ, you must reset the device before the requested route can be made.  For SCXI devices, you must reset the communicator DAQ device. Call the Traditional NI-DAQ Device Reset VI or the Init_DA_Brds function. To reset all devices in Traditional NI-DAQ, right-click the Traditional NI-DAQ Devices folder in MAX and select Reset Driver for Traditional NI-DAQ."

I first create a DO task for /Dev3/port0 to set the port to value 255.  Then I use the DAQmxTristateOutputTerm function for terminal /Dev3/port0 and I receive the above error.  Not sure if my assumptions are correct. 

The Labview diagram you provided does not help much as I am not familiar with that software.

Again, thanks for the help.

[Robert_F]

Hello Jeremy,

You can read and write on one port if it is set to tristate mode.  Setup the task as a digital output task then set the tristate mode on and off to read or write from that port.  If you want to read from that line, then set the tristate mode to “TRUE” and read the data.  If you want to write to that line, then set the tristate mode to “FALSE” and write the data.

You just need to set the tristate mode back and forth from “TRUE” to “FALSE” in order to read and write on the same line.

int32 __CFUNC DAQmxSetDOTristate(TaskHandle taskHandle, const char channel[], bool32 data);

Message Edited by Robert F on 09-17-2007 06:57 PM

[jjsomer]

Still working on this.

I implemented your suggestion in code and received the following error message:  "Requested value is not a supported value for this property."  The function call looks like this in code: lngErrorCode = DAQmxSetDOTristate(lngTaskHandle, strChannel, boolSetTristate).  lngTaskHandle is the handle assigned when the digital output task is created.  strChannel is the virtual channel name that I specified when creating the digital output task.  boolSetTristate is a logical TRUE or FALSE depending on the function of the port that I want.  I have verified each of the parameters that they are what were specified or assigned when creating the digital output task.

Does the PXI-6508 support bidirectional i/o ports?

The error occurs when I first execute this function.  I create a digital output task, write a byte to the digital port, then try to set the port to tristate to read the port value when the error occurs.  The task is still available as I can write a port value after I trap on the error.

[Robert_F]

Hello jjsomer,

Digital lines on the 6508 and 6509 can not be used in tristate mode.  We are considering making the 6509 able to tristate its digital lines in the future.  The 6509 is very similar to the 6508 in functionality but it only uses the DAQmx driver.  The 6508 can use both the Traditional NI-DAQ and NI-DAQmx drivers. 

The best way to accomplish your application is to stop and restart the different tasks, which is your current method. 

We have already contacted you to discuss alternate options for your application.

[jjsomer]

Thanks again for your help.

I am continuing forward with DAQmx to determine the extent of the timing hit on a full conversion from Traditional DAQ to DAQmx.  My guess is that this increase in time will never be acceptable in a production environment, especially considering that some products test with a complete test time of 10 seconds.  Adding 3 or 4 seconds of communication time is a very significant increase.

It may end up that our app use a mix of Traditional DAQ and DAQmx drivers in the near future.  In which case I may be back on the forums to discuss issues that arise from that.  The push to upgrade from Traditional DAQ has been suggested to us many times in the past, because Trad DAQ has reached its service lifespan and we continue to have Trad DAQ installation problems.