I am working with a number of different DAQ devices for experiment control in a lab environment where we need to trigger hardware timed sequences off the 60Hz power cycle. We do this by pausing and retriggering the external clock for the connected DAQs that generate the AO, AI, and DO lines. For timing reference we use a DAQ counter to measure the length of the pause with a Semi Period measurement of two pulses on a DO line of the same device, one at the beginning of the run and one at the end of the wait once things are retriggered.
The problem I'm having is that the X-series DAQs I have only measure the falling edge of the first pulse then both edges of the second. The M-series devices I have measure all four edges. I'm want to use the same code for all the devices since they are practically identical in function, but I can't now since the number of edges read depends on the device used. I can't seem to find any reason why there should be a difference in the documentation. I'd really like to make the behavior consistent so that the code base doesn't need to diverge or implement hacks.
The devices I have access to are a USB-6343, USB-6229, and PXI-6259. I'm using PyDAQmx to access the C api. I have two separate setups using NI-DAQmx 15.5.1 or 9.9. The setup code is:
self.acq_task = Task()
self.acq_task.CreateCISemiPeriodChan('ubs_6343/ctr0', '', 100e-9, 200, DAQmx_Val_Seconds, "")
self.acq_task.CfgImplicitTiming(DAQmx_Val_ContSamps, 1000)
self.acq_task.StartTask()The edges are then read out one at a time with a read thread using the ReadCounterF64 method to get all four edges. When the first edge is missing, timeouts and timing logic have to be changed.
The only other thing I've noticed in my testing is that the M-series devices show the first edge taking place at some large delay consistent with starting the task in software time before the hardware timed tasks are configured. The X-series devices however always have the first edge measurement give the width of the first pulse. If I didn't know better I'd think the counter start was being triggered by the rising edge, but that's not how it's configured as far as I know. Why would it only be the X-series to behave that way?
Any insight would be great!
(I've attached the full source for the curious. It's part of a larger software suite known as labscript)