0

Using National Instruments' DAQmx via C++, I would like to present a list of possible physical trigger inputs available on the system to the user.

I can set a task to start on an external trigger by calling something like

char* trigger_source = "/Dev1/PFI0";
DAQmxCfgDigEdgeStartTrig(taskAO, trigger_source, DAQmx_Val_Rising);

Is there a way to get a list of the valid values for trigger_source? I have found DAQmxGetSystemInfoAttribute(DAQmx_Sys_DevNames, , ) to get a list of the devices available in the system, and I know that DAQmxGetDevDILines() and similar functions can give me lists of some of the types of ports on a device. However, I have found nothing that returns the PFIs.

If a list cannot be obtained, is there a sane way to test whether a given guessing string like "/Dev%d/PFI%d" is a valid trigger source?

Lichtkarussell
  • 73
  • 4

1 Answers1

0

There are two ways:

  1. Dynamically on-demand
  2. Guess-check-cache-query

Dynamic

You can build this list, but not with a single call into the driver. Use a combination of these properties:

  • DAQmxGetDevTerminals(const char device[], char *data, uInt32 bufferSize)
    which returns the PFI lines as well as internal terminals. It doesn't return any of the I/O terminals (like ai0).
  • DAQmxGetDevAIPhysicalChans(const char device[], char *data, uInt32 bufferSize)
    which returns the channel terminals for the AI subsystem; there are similar calls for the other DAQ subsystems.
  • DAQmxGetDevAnlgTrigSupported(const char device[], bool32 *data)
    which returns whether the device supports triggering from analog signals.
  • DAQmxGetDevDigTrigSupported(const char device[], bool32 *data)
    which returns whether the device supports triggering from digital signals.
  • DAQmxGetDevAITrigUsage(const char device[], int32 *data)
    which returns what trigger types the AI subsystem can use; there are similar calls for the other DAQ subsystems.

Cached

You could also create a dummy task and preview each terminal and trigger type combination.

You won't need to run the task, just "verify" it, which will prompt the driver to run its rules system on those settings and return an error if that configuration is not supported. If you cache these in memory or a file (or a DB or whatever), it might be easier to query that instead of the driver.

  • DAQmxTaskControl (TaskHandle taskHandle, int32 action)
    which moves the task in the DAQmx state model. Using DAQmx_Val_Task_Verify for the action parameter will verify that all task parameters are valid for the hardware.
Joe Friedrichsen
  • 1,976
  • 14
  • 14