DAQmxRegisterEveryNSamplesEvent for Analog Output

[Paball]

I have a USB-6009 device which I can write to successfully using the calls below for setting up the task and writing the Analog Output. Unfortunately, the DAQmxWriteAnalogF64  call takes almost 2 milliseconds to complete, which in my real-time application, is a lifetime. I don't have this problem when acquiring Analog Inputs since I set up the task for a buffered input using DAQmxCfgSampClkTiming and DAQmxRegisterEveryNSamplesEvent. I've looked through the examples searching for some way to buffer my Analog Outputs using the DAQmx_Val_Transferred_From_Buffer value in the DAQmxRegisterEveryNSamplesEvent but have not found anything that uses it. Does anybody know how to buffer Analog Outputs so that the call to DAQmxWriteAnalogF64 takes microseconds instead of milliseconds?

Thanks for any help.

   szTaskName.Format ("USB-6009 %s Analog Out", m_szDevNum);
   nDAQStatus = DAQmxCreateTask(szTaskName, &m_hAOutTask);
   if (nDAQStatus < 0)
      return (DisplayDAQmxError(nDAQStatus));

   szChanRange.Append("/ao0:1");
   nDAQStatus = DAQmxCreateAOVoltageChan(m_hAOutTask,     // task handle
                                         szChanRange,     // physcial channel list
                                         NULL,            // virtual channel name
                                         0.0,             // minimum voltage
                                         5.0,             // maximum voltage
                                         DAQmx_Val_Volts, // voltage scale
                                         NULL);           // custom scale name
   if (nDAQStatus < 0)
      return (DisplayDAQmxError(nDAQStatus));

   nDAQStatus = DAQmxStartTask(m_hAOutTask);
   if (nDAQStatus < 0)
      return (DisplayDAQmxError(nDAQStatus));

   for (i=2; i < USB6009MX_MAX_AOUT_PORTS; i++)
   {
      dValue[i] = 0.0;
      pPort = (fl{oat*)pCard->m_AODevice.m_aryElementPtrs.GetAt(i);
      if (pPort)
      {
         dValue[i]  = *pPort;
         dValue[i] *= USB6009MX_MAX_AOUT_VOLTS;
         if (dValue[i] > USB6009MX_MAX_AOUT_VOLTS)
            dValue[i] = USB6009MX_MAX_AOUT_VOLTS;
      }
   }
   nDAQStatus = DAQmxWriteAnalogF64 (hTask,   // task handle
                                     1,       // samples/channel
                                     1,       // autostart = true
                                     10.0,    // timeout in seconds
                                     DAQmx_Val_GroupByChannel,
                                     dValue,  // float 64 array
                                     NULL,    // samples/chan written
                                     NULL);   // reserved

[Ed W]

Hi Paball,

While it has the ability to do continuous (clocked) analog input, the USB-6009 cannot perform continuous (hardware-timed) analog output. The device allows only software-timed updates to its digital to analog converter (DAC), up to 150 samples per second. This information can be found in the USB-6009 user manual.

For an example of software-timed analog output using C, the "MultVoltUpdates-SWTimed.c" example can be found in the "C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog Out\Generate Voltage\Mult Volt Updates-SW Timed" directory. 

There is also a Visual C++ example located in the “C:\Program Files\National Instruments\MeasurementStudioVS2003\DotNET\Examples\DAQmx\Analog Out\Generate Voltage\GenMultVoltUpdates_SWTimed” directory.

This information is also available in one of our Knowledge Base articles, linked below.

USB-6008/6009 Continuous Analog Output

I hope this helps!

Ed W.

[Paball]

Hi Ed,

Thanks for the info. I used the "MultVoltUpdates-SWTimed.c" example as a guideline when I set up my code. The task configuration part of the code I showed you takes place just prior to going into a real-time loop (the real-time loop is configured at 40 Hz, or 25ms per frame). The DQXmxWriteAnalog64 call is in another function which the real-time executive calls once per frame (every 25ms). My problem is that the DQXmxWriteAnalog64 call takes almost 2ms to complete, which is 8% of my frame time. The real-time executive has many other "chores" to accomplish in each frame, and 2ms is, as I said before, a lifetime within the loop. It seems to me, that if I'm simply writing to a buffer, that it should be on the order of tens (or even hundreds) of microseconds. If I understand you correctly, the USB-6009 does not have the capability to configure an output buffer to which I can write. Is my understanding of this correct? Aside from using another product, isn't there anything I can do to speed up the call to DQXmxWriteAnalog64?

[Ed W]

Hi Paball,

Your understanding is correct - the USB-6008/6009 devices do not contain any analog output buffers – all analog output is implemented through software timing.  The only other suggestion that I could make for you besides getting a new device is to update your computer.  Since everything that is being output is software timed, upgrading your RAM, CPU, and other PC resources will allow your operating system to output these analog signals more quickly.  However, regardless of your computer, you probably won’t be able to get to the microseconds level using that device. 

Also, unless you use a real-time operating system, the data output will not be deterministic.  So for instance, if you’re using Windows XP with software timed analog output, your output rates still may vary within several hundred microseconds.

If using another device is a possibility for you, I would suggest something from our multifunction M Series product line.  The link to the M Series website is below.

M Series Data Acquisition

Best regards,

Ed

[Paball]

Hi Ed,

Thanks for the info. I also found out that I can't set up Digital Inputs and Digital Outputs through buffers with the USB-6009 either. The call to DAQmxCfgSampClkTiming only works for Analog Inputs. When I do it for an AO, DI, or DO task, it returns a status that tells me that the DAQmx_Val_SampClk is not supported for the DAQmx_SampTimingType property (error code -200077). It then tells me that I can select DAQmx_Val_OnDemand, which I finally understood to mean that I can't set up a buffer.

What I've ended up doing is spawining a separate executable which can do the processing for the AO, DI, and DO tasks. I put it in a loop that runs around 30Hz. The data that is written to and read from the USB-6009 is then put into a shared memory area that my parent task can collect and distribute to the appropriate places.

It's not really important that the data is collected and distributed in a hard real-time fashion. It's just important that my loop in the parent app does not blow frames (25ms). Our main application is for audio and communications simulation which is used in flight simulators for commercial and military use. Hence, we are processing voice and wavefile streams in our real-time loop, and if the loop blows a frame, there's a high probability that an audio stream can get mangled (much like a cell phone when it starts dropping packets). We use the USB-6009 to collect switch settings and volume knob settings, and to control indicators and dimmers and the like. A change in a switch or a light is not really perceptible to a human unless it takes around 250ms (1/4 second) for it to take hold.

I really like the USB-6009 because of its versatility and compactness. And because it's USB, you can use a bunch of them and put them just about anywhere. It also plugs and plays nicely. NI did a good job with the device naming. Even if you unplug it, the device number remains the same for that serial number (until I assume, you clear out the registry). We've been using NI PCI cards in the past and have never had any problems with them.

Thanks again for all your help, Ed.

Best Regards,

Paul Halliday (Paball)