Data Acquisition with Comedi

One example of an application for DAQ and Comedi is the Analytical Engineering, Inc. (AEI) airflow laboratory. In the AEI lab, airflow is generated by a fan and is forced through orifices of varying sizes. Using a custom-written software application, a technician can monitor the pressure buildup across the orifice. In turn, this pressure buildup can be used to calculate the approximate amount of air flowing across the orifice. This calculation is vital, because it allows a technician to determine whether various meter calibrations are correct.

However, the actual mass flow is more difficult to calculate completely. This number requires knowledge of two air pressures, three airflow temperatures, humidity, barometric pressure and altitude.

Off-the-shelf components exist for converting these measurements to voltage; one of the most popular interfaces is 5B. Using 5B modular blocks, it's possible to transform all of these measurements to voltages the DAQ card can read.

Figure 1. Airflow Measurement Device

Using Comedi, reading these voltages becomes as trivial as using the comedi_data_read function. Calling this function and specifying a certain channel produces a resultant value, 3,421 for instance. But what does this number mean?

DAQ cards measure with a certain bit precision, 12 bits being the most common. They also specify a range or ranges of voltages over which they can be programmed to measure. Because a 12-bit number is represented from 0 to 4,095, it's easy to see that 3,421 is simply 3,421/4,095 * 100% of full scale (4,095). If the range of voltages is specified as [0, 5], then 3,421 would represent 4.177 volts.

Utilizing this information and knowing that the 5B block for temperature maps as [0 volts – 5 volts] → [0°C – 100°C], a small amount of programmatic math delivers a temperature of 83.56°C. Couple all of these measurements together, add a nice GUI interface and repeat the DAQ process every second.

More complex data acquisition can be performed as well. When acquiring data, it's important to make sure you sample fast enough so as not to miss any important information that occurs between samples. To support this, Comedi offers a command interface that can be used to set up synchronized sampling. Based on the sophistication of the DAQ card, timing can be handled by software interrupts or on-card interrupts.

#include <stdio.h>
#include <comedilib.h>

const char *filename = "/dev/comedi0";
int main(int argc, char *argv[])
{
  lsampl_t data;
  int ret;
  comedi_t *device;

  /* Which device on the card do we want to use? */
  int subdevice = 0;
  /* Which channel to use */
  int channel   = 0;
  /* Which of the available ranges to use */
  int range     = 0;
  /* Measure with a ground reference */
  int analogref = AREF_GROUND;

  device = comedi_open(filename);
  if(!device){
    /* We couldn't open the device - error out */
    comedi_perror(filename);
    exit(0);
  }

  /* Read in a data value */
  ret=comedi_data_read(device,subdevice,
    channel,range,analogref,&data);

  if(ret<0){
    /* Some error happened */
    comedi_perror(filename);
    exit(0);
  }

  printf("Got a data value: %d\n", data);
  return 0;
}

Comedi shines in most data acquisition applications. In fact, Comedi's limit generally resides in the hardware on which it's being run. Less expensive cards typically have a slower scan rate ability. For fast data acquisition, most of the higher priced cards come with onboard DMA, allowing an onboard processor to handle the acquisition and allowing Comedi simply to route the acquired buffered data.

  /* Goal: Set up Comedi to acquire 2 channels, and
     scan each set twice.  Perform the acquisition
     after receiving a trigger signal on a digital
     line.
  */

  comedi_cmd c, *cmd=&c;
  unsigned int chanlist[2];

  /* CR_PACK is a special Comedi macro used to
     setup a channel, a range, and a ground
     reference
  */

  chanlist[0] = CR_PACK(0,0,0);
  chanlist[1] = CR_PACK(1,0,0);

  /* Which subdevice should be used? */
  /* Subdevice 0 is analog input on most boards */
  cmd->subdev       = 0;
  cmd->chanlist     = chanlist;
  cmd->chanlist_len = n_chan;

  /* Start command when an external digital line
     is triggered.   Use digital channel specified
     in start_arg
  */

  cmd->start_src = TRIG_EXT;
  cmd->start_arg = 3;

  /* begin scan immediately following trigger */
  cmd->scan_begin_src = TRIG_FOLLOW;
  cmd->scan_begin_arg = 0;

  /* begin conversion immediately following scan */
  cmd->convert_src = TRIG_NOW;

  /* end scan after acquiring
     scan_end_arg channels
  */
  cmd->scan_end_src =     TRIG_COUNT;
  cmd->scan_end_arg =     2;

  /* Stop the command after stop_arg scans */
  cmd->stop_src =         TRIG_COUNT;
  cmd->stop_arg =         2;

  /* Start the command */
  comedi_cmd(device, cmd);

Fast scan rates don't translate to fast processing, however. Due to the non-deterministic nature of the stock Linux kernel, it's virtually impossible to handle acquisition and processing in real time—that is, to maintain strict scheduling requirements for a process. Help is available, however. The Linux Real-Time Application Interface (RTAI) and RTLinux are two of a small number of add-on packages that allow for better timing control in the kernel. Both packages provide interfaces to Comedi.

The basic idea behind these real-time interfaces is simple. Instead of running the kernel as the monolithic process, run it as a child of a small and efficient scheduler. This design prevents the kernel from blocking interrupts and allows it to be preempted. Then, any application that needs real-time control of the system can register itself with the scheduler and preempt the kernel as often as it needs to.

Figure 2. Normal Linux Process Scheduling vs. Real-Time Linux Process Scheduling