NI6341 unwanted ouptut delay

[Spurious]

Hi. I am using an NI x series 6341 USB DAQ. I have noticed that there is a significant delay between asking for a digital command to be output and it appearing on the output lines. Using On Demand timing this can be as much as 2mS. The Digital Write one Channel vi in DAQ mx can take 2ms to return from its call. This is causing me significant problems. Things get worse if I use a wavefom sequence of data. The change in output can be very fast but there can be a delay of over 100ms before this actually hits the lines. It is quite liklely that this is the wrong piece of kit for the task. I dont know if it is the USB nature of the device or the DAQmx software that is responsible.

Could someone suggest a better approach? will a DIO card on the PCI bus be more responsive?

Any advice gratefully recived.  

[crossrulz]

It could be your program as well.  Care to share?

In general, the PCI bus will have less latency and more bandwidth, so it is possible it will help.  See here for an acticle about the different buses.  The other problem is that (I'm guessing that you are not using an RT system) the OS will randomly take over CPU time.  I've seen OS delays hit almost a second.  It is usually in the 10ms range though.

[Spurious]

Thanks for the reply, the article on bus types was very informative.

Posting code snippets is difficult as the code is running on a stand alone machine. However it is fairly standard stuff. I have spent a long time tweaking the code as I assumed it was a problem with the programming (ie my fault). After measuing the response and making no improvements through software I am convinced it is amore fundamental issue.

You are correct, I am not using RT - would that help I haven't looked into what that can do.  

Is there any way I can pursuade the operating system to speed up talking to the USB deveice - can I change the priorities for that device?

Thanks for the assistance 

[crossrulz]

I'm not sure about changin priorities.  I have not mucked around Windows enough to find that.

Out of curiousity, how are you measuring this delay?

[Mcdan]

Spurious,

Unfortunately, USB devices are fairly slow when using on-demand timing (USB is a high latency bus).  Delay on the order of a couple of mS does not sound unexpected to me.  To be as fast as possible, make sure that you explicitly start the DAQmx task before you begin to call write on the task.  This will prevent the task itself from needing to do unnecessary state transitions, and prevent DAQmx from performing unnecessary configuration on the device.

Hope that helps,

Dan

[Ali_Bailey]

Hi Spurious,

Depending on what you require to appear at the outputs of your device there may be ways of architecting your code that can achieve it.

Would you be able to share what you would like to achieve at the high level? Also, if you are able to upload examples of what you have tried to do that that it would be great.

[Spurious]

Thank You for your replies and suggestions and apologies for the delays in responding- I have been unwell.

To address an number of points:

I have experimented with a number of approaches to overcome this problem and so far the on demand version works best. As was correctly pointed out the tasks must be initialised and maintained - creating a new one each calll takes up significant time.

It is difficult to share sample code as it is written on a stand alone machine, however I am not doing anything too unusual code wise.

It is effectively choosing a channel of communication between two computers both using USB DAQ devices.

1. Machine 1 selects a channel and sends a digital word from the DAQ to the device (using digital write in DAQmx)and then waits inside a while loop to see if the channel selection was succesful.
2. Machine 2 uses an analog input to sample its reciever to see if the signal goes above a threshold. This sampling takes place inside a while loop - a separate thread -  that sends it results via a notifier to a main receiver programme.
3. Machine 2 sends a signal only if the notifier from  anaolg sample is above threshold (this is via a slow RF connection). This signal is sent (via the digital write one channel one point vi )
4. Machine 1, after waiting for a period of some 6ms after sending the channel select, examines the latest value of a countern which receives the RF signalling. This counter reading also takes place in a separate thread and the counter value is passed by a notifier.
5. If the counter value has increased then the channel selection is successful. If not a new channel is selected via step 1 and the cycle continues.

The system works but there are many potential channels to use so the cumulative effect of waiting for each channel selection to see if it was successful can take around half a second which is too long. the main source of the delays comes in the time taken for the signals sent to be actioned by the USB DAQ's at both ends. ie the latency. If there are ways of reducing this latency I would be delighted to hear about them. I am thinking that probably the best approach now is to use DAQs on the PCI bus.

Thanks for your time and apologies for not being able to post code.

[Ali_Bailey]

Hi Spurious,

This may well be something that you are aware of and have tried an alternative.

Using on-demand timing means that you are using software timing only to output data.  The DAQmx Write VI will wait until all samples have been generated if you use this timing method so this is possibly adding a delay.

You said in step 1 that your code “waits inside a while loop to see if the channel selection was successful”, is this the section in step 4 where it “examines the latest value of a counter”?  If so then you can possibly use this in the couple of suggestions below.

Firstly, you could generate a pulse train and use hardware timing to output it which will speed things up in the software for that part.

Here is an example from the user community and an accompanying tutorial from our website that generates a finite digital pulse train that is retriggerable.  You initially configure the output characteristics then start the task, generating pulses using hardware timing.  You could use the result of your check on the channel selection to retrigger the pulse train, changing what you are output each time.

Generate Retriggerable Finite Digital Pulse Train from Counter Output

Creating a Delayed, Retriggerable and Finite Pulse Generator

Secondly,if you are doing it over a whole port and the values are in parallel then you could have an array of the possible values written to the device buffer then output them on a hardware timed clock (in much the same way as before).  That clock could come from the result of the check on the channel selection too.   If you take a look at “Cont Write Dig Port-Ext Clk.vi” in the NI Example finder you should see what I mean.  The clock on that can be an external input from a PFI line, however you can also generate a trigger on that same line each time you unsuccessfully select a channel.

(Just in case you cant find it in the example finder, it is also here (Continuous Write Digital Port - External Clock)

I hope this helps pointing you towards getting something working in your code.