Discontinuity in digital outputs when task started with external sample clock

[chrisjbillington]

I'm using an NI PCI 6733. I also have NI USB 6343 devices that don't seem to show the below behaviour.

I am first outputting constant digital signals on the device with a task running in software time. Then, I stop this task and start a new one configured to use an external sample clock. Between the two tasks, I'm seeing potential discontinuity of output.

I'm observing that the state of digital outputs upon calling DAQmxStartTask() can change with respect to the previously-written constant values before an external edge arrives. This is undesirable because the digital lines may produce edges that affect other hardware in a way that produces bad data for our experiment.

My code is something like this (translating from the Python wrapper I'm using around the NI DAQmx C API, probably incorrect C grammar below but you get the idea):

// Start outputting some values DO_data in software time:
DAQmxResetDevice("Dev1")
TaskHandle task;
int written;
DAQmxCreateTask("", &task);
DAQmxCreateDOChan("Dev1/port0", "", DAQmx_Val_ChanForAllLines);
DaqmxStartTask(task);
DAQmxWriteDigitalU32(task, 1, True, 10.0, DAQmx_Val_GroupByChannel, DO_data, &written, NULL);

// ... some time later ...

DaqmxStopTask(task);
DaqmxClearTask(task);

// Start a task to output buffered_data of length npts with external clock on clock_terminal with given maxrate:
DAQmxCreateTask("", &task);
DAQmxCreateDOChan("Dev1/port0", "", DAQmx_Val_ChanForAllLines);
DAQmxCfgSampClkTiming(clock_terminal, maxrate, DAQmx_Val_Rising, DAQmx_Val_FiniteSamps, npts);
DAQmxCfgOutputBuffer(npts);
DAQmxWriteDigitalU32(npts, False, 10.0, DAQmx_Val_GroupByChannel, buffered_data, &written, NULL);
DaqmxStartTask(task);

// The output now potentially changes before the first external sample edge arrives on clock_terminal.

// Then external triggers produce samples until buffered output is complete

DaqmxClearTask(task);

 (the full code is here but not super useful without context. I may try to make a more minimal example with actual working code, but I can't access the hardware for testing at the moment, as the experiment is in use)

I notice that if the above runs repeatedly, but with the DAQmxResetDevice only run once at the start, then on the first run the outputs are all high in between the DaqmxStartTask() call for buffered output and the first edge, whereas on the second run they are all low - this could be because the final values of the buffered task is that they are all low (I'll test this when I next have the hardware on hand).

It seems like the digital outputs all being high is the power up state of the device. In either case though—in the first run or subsequent runs—there is the potential for discontinuity because the values output prior to the first sample clock edge are not based on those from the previous software-timed task.

This is a problem because these digital lines control equipment, and although we can just ensure the assumed state is always zero and always disregard the first run of our experiment as incorrect, it would be nice to fix the problem.

Is there any way to ensure continuity between the software-timed DO task and a subsequent hardware-timed task, that works regardless of what the digital outputs are set to in the software-timed task?

As mentioned the problem does not occur on an NI USB 6363 devices.

Any help would be appreciated.

[Kevin_Price]

Are you really sure you're doing this on a PCI-6733?  That's a very old board that uses a very old timing chip (DAQ-STC) that I've never known to support hardware-timed DO.

Aside from that, I'd give a try to only stopping the software-timed task, not clearing it, and then reusing the task rather than recreating a new one.  You might want to think twice about the call to DAQmxResetDevice too.   Resetting the board will make your DO revert to power-up state.  Clearing the task is kinda like giving the driver/board permission to do the same by releasing any "hold" you've placed over I/O states.

-Kevin P

[chrisjbillington]

Hi Kevin,

Thank for the advice! I will try re-using the task and see if that helps. Though, from my testing, it does look like the discontinuity occurs not after DAQmxClearTask, but only after the new task is started. Still, fingers crossed.

Calling DAQmxResetDevice is something I've been undecided about, our software is designed to try and start hardware in as clean a state as possible (so that you can click 'reset' when things break and be fairly sure previous configuration is gone), but I'm certainly keeping in mind the option to remove it if it will help (then the issue might be reduced to "the first run after rebooting the computer is bad" instead of "first run after starting the software").

We are definitely using an NI PCI 6733, and it definitely does allow hardware-timed output - though potentially only with an externally provided sample clock, perhaps that is consistent with its timing chip not being capable of providing hardware-timed DO?

Most of the labs I've worked in/with have at least one of these models (5 labs that I can think of), and I suspect the reason is for compatibility with software written a fairly long time ago to drive them. But now that we've developed this more general-purpose Python driver (for which you helped me last year solving the problem of figuring out whether a given model has incomplete sample detection - all that is working great by the way!), it should be easier for new experiments in the same groups to use newer DAQmx models.

Thanks again! Will post back here next week after trying your suggestion.

[Kevin_Price]

Still surprised about hw-timed DO support on the 6733.  I believe it though.  Generally, spec sheets for devices that support it have a DIO section titled "waveform characteristics" and I saw no such section in the spec sheet.   Curious, I dug around and found that this support page mentions the capability pretty prominently (while curiously not mentioning analog output capability *at all*).   Also, a subsequent closer reading of the linked spec sheet shows some mention of DIO buffers and DMA transfer mode, which would be good clues about support for hw-timed DIO.

Anyway, some additional poking around suggests that the "tristate" property is supported for DO on the 6733.  I'm not solidly grounded in the electrical theory, but would hold out some hope that a combo of things like tristating and a weak pull-up or pull-down resistor might be able to help you achieve *consistency*.  I'm not sure whether power-up states are board-programmable on that device -- I'm inclined to think not due to its age, but that's what I thought about hw-timed DO too.

-Kevin P