9402 - single pulse generation on two channels (with shift)

[SzymonM]

Hi!

I have Ni 9402 (4 fast DIO). Two channels are already in use, and I have to generate single pulse on last two.

I need a quite good precision in shifting "slave" channel. So, if the delay between first and second is programmed as 50 us, it should be around 50 us measured.

I know that I have to use triggers, but I have tried different possibilities (dummy channel as trigger too) and it generating only errors.

Can you help me?

[Kevin_Price]

There's more than one way to do this.  What I would consider simplest is to let the later pulse be triggered by the earlier one.   You have a head start in that direction already with the 50 microsec "initial delay" you wired.

When generating a single pulse, I typically omit the call to DAQmx Timing.  It used to be an error to request 1 Finite Sample -- omitting the call to DAQmx Timing was the *only* way to get a single pulse.  Not sure if that's still true, it's been 15 years since I learned that the hard way and probably haven't bothered trying since.

A single pulse will only use 2 of the 3 possible timing parameters.  It will use "initial delay" for the first portion when it's in its idle state.  For you, that's the High state.   And because you have a High idle state, it'll use the Low Time spec for the second portion.  The High Time spec is not used at all for a single pulse (or for the first pulse in a a pulse train) with High idle state.

In your code you should configure a Start Trigger for the later pulse.  Since you're specifying PFI3 as the earlier pulses output terminal, you can send that same wire into the trigger config.  I'd guess that with High idle state, you'd want to trigger on a falling edge.

So that brings up one other possible thing: the default power-up state for PFI0 and PFI3 may be Low.  If so, then starting the pulse tasks will create an initial rising edge transition as the PFI lines change from the board default of Low to the Pulse idle state of High.  After the pulse is done, the PFI lines will remain in the pulse's idle state (until / unless they get reconfigured for another purpose).

    In some apps, this is undesired.  If your device supports programmable power-up states for these lines, you could set them to power-up High.  Another thing you can do is call DAQmx Control Task to "commit" the task long before you get to the part of your code where you actually want to generate the pulses.  The PFI lines will be driven to the pulse's idle state of High when you commit the task.  In some apps, you can arrange to do this before firing up the other equipment that might wrongly react to the extra rising edge transition.

-Kevin P

[SzymonM]

Yeah, I have tried trigger on PFI3 for second line. I was thinking this is the most natural way, but, unfortunately It gives me an error.

[Kevin_Price · Accepted solution]

I'm mostly used to the flexible signal routing options available on desktop MIO boards.  I tried to set up a simulated cDAQ chassis with a 9402 to look at the "Device Routes" tab in MAX and found *no* available routing flexibility for the 9402 module itself.  Dunno what chassis you have and dunno how much it would matter, but my simulated 9178 only showed routes internal to the chassis itself, nothing out to any modules.

FWIW, your error comes from trying to put ctr1 output out onto PFI3, not from trying to configure PFI3 as a trigger for ctr2.

With those things in mind, I'd recommend trying:

- do your counter / PFI selections so that ctr0<-->PFI0, ctr1<-->PFI1, etc.  This *might* be a more default routing that requires fewer resources.  I'll assume for the sake of further discussion that you keep the PFI #'s the same for the sake of existing wiring and change the ctr #'s to match.  So your upper task will use ctr3 and your lower task would use ctr0.

- if needed, you may be able to configure the trigger source as "/cDAQ4/Ctr3InternalOutput" rather than specifying a PFI pin that might not be routable.  The internal output signal is *very* readily routable within the chassis, at least on the 9178 chassis I'm simulating.

-Kevin P

[SzymonM]

"/cDAQ4/Ctr3InternalOutput" 

This is so strange that I cannot choose this from list but I have to write it by myself.

Anyway, after this, module is working as I needed (around 50 ns of delay, i.e. as in datasheet, acceptable).

Thanks!

[Kevin_Price]

FYI, there are right-click options for terminal constants and controls that control which of the possible terminal names are presented as a possible selection.  Right-click, choose "I/O Name Filtering...", then check "Include Advanced Terminals".  There's also an option for limiting the choices to a specific device if you want.

It's been suggested for a long time now that the "advanced" terminals should be visible and available by default.  I agree, but after this many years hoping for it, I'm not exactly holding my breath.

-Kevin P