Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

Waterfalling Pulse on X-series (PCIe-6363)

I have a PCIe-6363 (and a PCIE-6536 next to it).

 

The PCIe currently takes a digital edge trigger on PFI5, and then Uses Port 0 to marshall out a waveform.  That works fine. 

 

Once that's done I need to pulse an enable line.  That seems easy enough.  But I need to do it across 8 ideally (4 minimum) lines.  I have to pulse the latch enables in a waterfall-like fashion so that I only update an eighth (or quarter) of the system at once to prevent glitching.

 

I have 8+ PFI lines available on the PCIe-6363 and 3 other counters, but I don't see a way to effectively do that.  Am I stuck just using the 3 available counters to divide these up, or is there some clever way to make this happen?

0 Kudos
Message 1 of 7
(1,878 Views)

What's the 1 counter being used for such that there are only "3 others"?  What are the timing requirements for these pulses?   Can you get away with software-timed DO?   Or do you need precise hardware timing?

 

If you need hardware timing, you'd likely need to use counters.  Depending on total time requirements, you might be able to use, say, Ctr1 to generate a pulse on PFI1.  Then after you've stopped the task, reconfitgure Ctr1 to generate its pulse on PFI7 or something.  The down side is that you might run into issues with "lazy uncommit".  (Search for more info).

 

All in all, I'd try to do this with software-timed DO.  If the enabling gets latched, it seems from here that you probalby won't need super precise pulse width timing nor pulse-to-pulse timing for the cascade.

 

 

-Kevin P

 

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 7
(1,868 Views)

Thanks Kevin.  I unfortunately do have to do hardware timed DO.  The other counter is being used as a clock for the other digital outputs.  So I load up a couple hundred samples, set the pulse train from the counter to be triggered via an external digital edge.  That goes and generates a finite pulse train shifting my samples out.  Then once that completes (~100 samples later) I need to pulse the other lines to get the registers to latch what I just shifted out before the next pulse comes in and I need to do it all again.

 

That all happens at ~4kHz, so software timed stuff just doesn't get me there.  

0 Kudos
Message 3 of 7
(1,849 Views)

Aren't both your boards capable of hw-timed DO?   Have you connected them with a RTSI cable (34-pin ribbon)?   Here's an idea I'm picturing:

 

1. External edge comes in to your 1st board.

2. This triggers a finite pulse train at 50% duty cycle (truly square).  This pulse train is used to clock out your first "couple hundred samples" on your 1st board.

3. You could also export this pulse train up to one of the RTSI lines for the 2nd board to use.

4. The 2nd board uses it as a start trigger for its own hw-timed DO task.

5. The data to output from the 2nd board would include some NULL data at the beginning just to occupy time until the 1st board gets done.  The remainder of the data would accomplish the cascading enable pulses.

6. This kinda depends on the 6536 supporting retriggering. 

7. If not, you could instead use a 2nd counter from the 6363 as the retriggerable finite pulse train needed by your 2nd board.  You may need to search for a deeply nested property that lets you set an initial delay value that's used for *all* the triggers rather than just the first one.  The "initial delay" value is used to delay the 2nd board's sample clock until after the 1st board will have finished.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 7
(1,845 Views)

Thanks.  I only have PFI's available on the other card, and there's no counters, so it's kinda the same thing where I would need to make PFI's do the heavy lifting.

 

Right now I'm experimenting with connecting terminals (ctr n internaloutput) to multipe PFI's, and playing with the invert / not-invert option on that.  I might be able to get six edges with the 3 clocks if I invert half of them...

0 Kudos
Message 5 of 7
(1,836 Views)

Next thought:  are there spare bits on port 0 of the 6363 you can use for these enable pulses?   Then you could just merge the waveform data with these enabling pulses (probably with a short gap time in between), and do a longer finite generation on each trigger.  The first half toggles waveform bits while the second half toggles enable pulses.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 7
(1,831 Views)

That would have been my first go-to if I hadn't already used all 32 lines on port0.  Really just maxing out the capacity of the NI cards here (next gen product will try the reconfigurable DIO FPGA cards so that we don’t have this limitation), and if not that then just spin our own hardware.

0 Kudos
Message 7 of 7
(1,827 Views)