M-Series read + Write, threading or async , performance issues

[makos]

I have a slightly unusual issue: Using 2 USB-6251 and 2 USB-6015 within the same application.

1 of the USB-6251s reads data on a 50 msec look (Driven by an async timer).

Depending on the input the code decides to output a 40 Hz, 300 usec  waveform  of varying amplitude  - the output goes one until there is  a user event that might make it stop.

Now , here is the problem.  I have implemented the output function using a sepereate high priority thread and the delay( delay_in_sec) command.

I find that while the data acquisition timer is NOT running the frequency of the output is very close to 40 Hz. When the data acquisition IS running , the frequency of the output varies considerably - most likely reflecting USB delays.

I was able to see the output 40Hz, 300 usec waveform using a seperate app using a single async timer w/o any data acq and the timing was immaculate.

My questions are:

1. Could I use 2 different async timers in the same app - I tried to do this and the output was still wacky when I turned data acquisition on

2. Is there any way outside the delay() command that could improve the timing accuracy of the analog output thread?

3. I measured the time to create a 300 usec pulse of a certain amplitude, write it to the USB-6251 and start the task and it was ~ 13 msec. This is way too slow for 300 samples at 1 MHz - is it a USB bus limitation, or I should look at my design to see what is going on?

4. Any NI hardware that would allow me to handle 4 analog outputs more gracefuly? (FYI, 2 of my outputs are at 1 MHz and 2 of them at 50 Hz).

Thanks

AP

[Joe_S]

Hi AP,

My first impression is that you would want to use hardware timing rather than software timing.  Try using a DAQmx Timing command and specify the rate there.  Aside from that, could you be more specific about your application?  How do you have your hardware set up and which devices are handling each part of the task?  How are you generating the output?

Regards,

Joe S. 

[makos]

THanks for taking the time to look at my message.

I am using 4 DAQs. First one, USB-6251 is used to collect data (4 analog inputs @ 20Hz) and also occasionally provide analog output @ 1 MHz.

Second DAQ is a USB-6251 occasionally provide analog output @ 1 MHz.

Third and Fourth DAQ  areUSB-6015 occasionally providing analog output @ 50 Hz.

All devices are connected via USB to a Dell Dual Core notebook.

THis is how I create & configure the analog output channels - using 1 task per device.

                    DAQmxErrChk(DAQmxCreateAOVoltageChan(TaskAnalogX,channelstring , "Ramp 1",0 , 10, DAQmx_Val_Volts, ""));
                    DAQmxErrChk(DAQmxCfgSampClkTiming(TaskAnalogX, "",1MHz OR 50Hz, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps     , SECONDS*1MHz));
                    DAQmxErrChk(DAQmxWriteAnalogF64 (TaskAnalog1, ( int32 )SECONDS*1MHz OR 50Hz ), 0, DAQmx_Val_WaitInfinitely, DAQmx_Val_GroupByChannel , PHAOarr, &sampsPerChanWritten, NULL));

THe design/architecture is pretty complex but on a very high level whenever I need to deliver analog output I configure the output waveforms and then write it to the DAQs and then use some timers/logic to deliver the waveform from the DAQ as needed.

Now the challenge has been that in one specific case I need to deliver analog output of uknown duration (whereas everything else is deterministic). In that case i  created a seperate thread and write each 300 usec pulse individually to the analog output (using USB 6251)using the following tASK:

                    DAQmxErrChk(DAQmxCreateTask("Tonic Output Task", &TaskTonic));  
                    DAQmxErrChk(DAQmxCreateAOVoltageChan(TaskTonic, channelstring , "PulseToPulse",0 , 10, DAQmx_Val_Volts, ""));    
                    DAQmxErrChk(DAQmxCfgSampClkTiming(TaskTonic, "",1.0E+06, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps , 301));

As described in my first message this is very sensitive to timing and it takes 13 msec to stop the task , write the array to the DAQcard and then start the task again.

On the hardware timing recommendation. I tried to configure the DAQ  using the DAQmx_Val_HWTimedSinglePoint samplemode but it seems not to be supported by the hardware I am using.  Is there a CVI example of using hardware timing that I can take a look at?

THanks

AP

Hi AP,

My first impression is that you would want to use hardware timing rather than software timing.  Try using a DAQmx Timing command and specify the rate there.  Aside from that, could you be more specific about your application?  How do you have your hardware set up and which devices are handling each part of the task?  How are you generating the output?

Regards,

Joe S.

[Joe_S]

AP,

Let me see if I understand what you are doing.  Correct me if I'm wrong, but it sounds like you are setting up four individual output tasks, one for each card, using the portion of code you provided in your post.  Additionally, you have a fifth task on a completely separate channel for one of the USB-6251 devices that will continuously output a 40Hz signal with a 300us pulse width until a user tells it to stop.  The 13ms delay you are seeing comes from when you instruct one of the four initial tasks to stop and begin outputting the signal from the fifth task.  Is this correct?

First, my recommendation for general programming purposes is to include a DAQmxStartTask before executing the DAQmxWrites (and reads).  This will improve the timing and efficiency of your tasks.

Second, if you are using external user input to stop the fifth task and timing is very important to the application, it sounds like you may want to use a pause trigger.  This will keep the task running and simply halt the output of the waveform until the pause trigger is deasserted.  You can find an example of this here.  Let me know if this helps or if there is more that you need!

Regards,

Joe S. 

[makos]

YOu are right in ur assessment. Let me clarify a few points:

THe 2nd (non data acquiring) DAQ 6251 , depending on the flow of the code, can produce either a few seconds of analog output at 1 MHz ( is shall call it TASKANALOG) - and for this function I write the data from an array to the device buffer) OR the continuous (until user intervenes to stop it) 40Hz, 300 usec signal ( I shall call this TASKTONIC) .

THe 13th msec delay i refer to is measured during TASKTONIC.  Inside the thread I stop the TASKTONIC task, then  update the output buffer of 300 usec on the fly, wirte it to the DAQ buffer and then restart TASKTONIC. I use a Delay(1/40Hz) command in order to keep the 40Hz frequency - this is where i discovered the ~13 msec delay.

Now, your point about starting the task before the write is one I do not understand. I tried to start the task before writing anything to the DAQ and I get an error message:

 NON-FATAL RUN-TIME ERROR:   "ThreadFunctions.c", line 206, col 21, thread id 0x00001378, function id 1:   Function DAQmxStartTask: (return value == -201025 [0xfffceebf]). Non-buffered hardware-timed operations are not supported for this device and Channel Type.  Set the Buffer Size to greater than 0, do not configure Sample Clock timing, or set Sample Timing Type to On Demand. Task Name: Tonic Output Task  Status Code: -201025

I take this message to say that my USB-6251s do NOT allow for starting the task and then writing the output values to the DAQ - am I correct or there is a flow in the way I handle my DAQ devices?

Thanks for your example - will look into it - however I am happy with the speed of response of the user interface events to stop the stimulation.

One original question I had was:  Had I used two asynctimers would I be able to get better timing resolution in the output or the USB bus is the limiting factors here  and the delays I see are because of USB latency?

[Sean_N]

Concerning your last question, I believe that you shouldn't need to asynctimers; it does seem that USB bus is the limiting factor due to latency.  I would also look at the example I have attached.

Hope this helps!

Sean N