Using PXIe 6612 to measure PXI 6528 channel pulsewidth - channel not available.

[mikan900]

Hello everyone,

I am using PXIe 6612 counter card to measure the pulse width of the signals on PXI 6528 DIO card. Both these cards are in the same PXI chasis (NI PXIe-1065). I could measure the pulse widths using the LabVIEW 2013 example Counter - Read pulse width and frequency (finite).vi example. However not all the channels of the PXI 6528 card are shown in the drop down list of channels on which pulse width can be measured. Trying to connect any channel other than those available in the drop down list returns error. On PXI 6528 card port 0,1 and 2 are input ports and port 3-5 are output ports. I can measure pulse width on port 0, port 3 and only line 0 of port 1 and 4.

Can anyone explain to me why don't I see port 1 or port 2 channels in the drop down list or force the VI to measure pulse width on these channels ??

I can connect PXI 6528 input channels externally to PXIe 6612 counter input channels and measure the pulse width, but If possible I would like to avoid the external cabling between the 2 cards.

[Kevin_Price]

I haven't used a PXI-6528 nor am I on a PXI chassis.  All I could do was define a simulated PCI-6528 device on my desktop.  In MAX, there's a tab for "Device Routes" which shows one-way routing from port 0 to the RTSI timing bus (analogous to a similar PXI backplane timing bus) and one-way routing from RTSI to port 3.

Honestly, that seems backwards considering that port 0 is input-only and port 3 is output-only.  I'm just reporting what I see.

Anyway, it appears the board is designed with limited and prescribed capability of routing signals internally across the timing bus to other PXI cards in the chassis.  You're pretty much stuck with what you see, it appears to be the design intent.

-Kevin P

[mikan900]

Thanks Kevin for bringing this to my notice. I see the same on my system in MAX. Is there a work around other than physically connecting the channels ?

[Kevin_Price · Accepted solution]

Probably not.  Unless the routing map is in fact reversed like it kinda sorta seems it might be.  As shown on my system, you can route *from* an input port *toward* RTSI, or you can route *from* RTSI *toward* an output port.  That doesn't make much sense to me, but that's what I see:

If the routing map *is* reversed, your only likely workaround without physical wires would be to generate the pulses in question from port 3.  It's pretty clear that ports 1,2,4,5 have no ability to interact with the timing bus, physical wiring would be the only option.

-Kevin P