Inconsistent Triggers

[mp5555]

I'm currently having an issue with a NI-6363 card.  I set up two tasks -- a data task and a counter task.

The data task looks at the counter task as a clock -- it uses the Counter InternalOutput to as it's sample clock for timing.

The counter waits for an external trigger on PFI5.  When it receives that trigger, it should create 104 counter pulses that thus shift out 104 bits from the data task.  The data task is a port, so it shifts 104-bits out on all 32 lines.

I load up the data buffer with a ton of samples (enough for a couple hundred triggers) and then set about triggering.

But it keeps missing triggers here and there when we attempt to do this at above 100Hz or so.  There's plenty of time post the 104-pulses for recovery and arming for a re-trigger, but it's just missing them fairly regularly.

Shouldn't since I have the buffer in there, it just *go*?  This should be bread and butter, right?  So what am I missing?  I've attached an O-scope picture of what I'm seeing.  The red traces are the trigger, yellow is the clock (counter), green is the data line.  I've tried changing the frequency of the counter clock around and up and down from 300kHz to 6MHz with no real big changes in behavior.

Any help would be appreciated!!

//create tasks
 tmp += ChkForError(DAQmxCreateTask("Data_t",out taskHandle_DAT));
tmp += ChkForError(DAQmxCreateTask("Counter_t",out taskHandle_CTR));

//asign port zero to the data task
tmp+= ChkForError(DAQmxCreateDOChan(taskHandle_DAT,$"{DeviceNum}/port0","Data",NI.DAQMX.DAQmx_Val_ChanForAllLines));

//Set all tasks that will be writing digital data to not allow regen of data.
tmp += ChkForError(DAQmxSetWriteRegenMode(taskHandle_DAT,NI.DAQMX.DAQmx_Val_DoNotAllowRegen));
//Set up counter for the clock, 50% duty cycle, rate defined by our global frequency, create only 104 samples out each time it's triggered
tmp += ChkForError(DAQmxCreateCOPulseChanFreq(taskHandle_CTR, $"/{DeviceNum}/Ctr2", "", NI.DAQMX.DAQmx_Val_Hz, NI.DAQMX.DAQmx_Val_Low, 0.0, Global_Frequency, 0.50));
tmp += ChkForError(DAQmxCfgImplicitTiming(taskHandle_CTR, NI.DAQMX.DAQmx_Val_FiniteSamps, 104));
//make the data task look at the Ctr2 (clock) for edges to shift data on.  Frequency is inconsequential, as-is # of samples (cont samples)
tmp += ChkForError(DAQmxCfgSampClkTiming(taskHandle_DAT, $"/{DeviceNum}/Ctr2InternalOutput", Global_Frequency, NI.DAQMX.DAQmx_Val_Falling, NI.DAQMX.DAQmx_Val_ContSamps, 104));
//set the trigger for the clock, and set it to be retriggerable
tmp += ChkForError(DAQmxCfgDigEdgeStartTrig(taskHandle_CTR, $"/{DeviceNum}/PFI5", NI.DAQMX.DAQmx_Val_Rising));
tmp += ChkForError(DAQmxSetStartTrigRetriggerable(taskHandle_CTR, 1));

 

[mp5555]

Oops, picture attached this time!!

[Kevin_Price]

If I'm interpreting that scope pic correctly, your channels are all set for 500 mV/division, right?   Well then it looks like your signals max out in the realm of 1.5-2.0 V, an indeterminate region for TTL and CMOS logic.  Nominally, these signals should be much closer to 5 V amplitude.

So the next question is *why* are the voltages so low?  I would guess that you might be connected to a low-impedance sink that wants to draw more current than your DAQ device can source, thus driving down the terminal voltage.

Can you disconnect all external equipment and do another scope capture to troubleshoot?

-Kevin P

[mp5555]

That's an easy answer, they're low because they go through a 5V -> 1.8V logic level converter!

The trigger (red) is a bit low -- I've been investigating that, and it could be a cause for missing some of the triggers....but it doesn't make sense to me why it would miss more when I speed the rate up -- the voltage always hits the same level.

I hooked up an external function generator and to replicate the pulse train as closely as possible that that I could then tweak parameters on the pulse train and low and behold, it's beautiful.  Works every time.  I'm thinking that it's a driver / DMA issue....need to test more to replicate.  But the device that is making the red pulse is also sending me data via USB in a different thread.  My suspicion is that it's hogging the bus and for some reason the NI drivers need some time critical resources right then, and it's just not getting them....despite the fact that I have a dual socket system with two 12-core Xeon processors in them, none of which are loaded above 20%....

[Kevin_Price · Accepted solution]

It's good to know you got correct behavior when using an external function generator.  I'm not sure I have a clear understanding of the rest of your setup.

What is the USB device in question?  What's its role with respect to the issue in this thread?  What else is it doing as far as USB data transfer?

Which signal did you replace with the function generator?  Was it the pulse train or was it the trigger signal you thought was a bit low?

Either way, I'm doubtful the pulse train task would be affected by DMA or USB transfer issues.  That CTR task should be pretty well self-contained in the device hardware.  The pulse params will be held in a register on the board and the rest of the behavior is up to the logic and timing circuitry.  That task has no further need to transfer data to your app, it just produces a timing behavior.

So that leads me to wonder about the code that you didn't show earlier.  You aren't making software calls that stop and restart the CTR and DATA tasks between trigger signals, are you?   The counter task only ever needs to be started once.  The "recovery time" for retriggering will be based on the logic circuitry -- probably a small fraction of a microsecond.  And the DATA task should also only be started once.

Thinking out loud, trying to help...

-Kevin P

[mp5555 · Accepted solution]

I have it working now, nothing specifically wrong with the NI card.  I had to get some data from the vendor of the other device.  The device has a 1.8V output with a 100Ohm in series resistor, and a 10kOhm pull down connected to it.

I was scoping it at the NI card input (goes from there through the 68-pin cable and into the NI card).  I think that the card itself, and whatever resistances in the cable, etc were enough along that path to drop it from 1.8V to below the 1.4V triggering threshold.  The function generator I believe could source enough current to keep the voltage high, and/or didn't have the resistors that the device had, which led to less voltage drop along the line.

So, I washed that trigger signal through a 1.8V logic buffer chip that I wired up real quick, and it worked totally fine.

So let this be a lesson that just because you're scoping at the last possible input before the card, that doesn't always mean that you're seeing what the card's seeing 🙂

I went to a function generator because setup of the equipment to do that pulsing is somewhat laborious and between each run there's a 1-2 minute setup session, whereas the function generator let me quickly change parameters and troubleshoot quickly.

Thanks for the help Kevin!  Marking your response as a solution because it did lead me to focus more on the hardware side of things for investigation instead of the driver and other potential theories on what could be happening.