PXI-1084 trigger routing issue between PXI-6683H and PXIe-7820R

[codcoder]

Hi,

So this is a blatantly repost from the discord channel but I'm getting kind of desperate here. I have opened an issue with the NI support function but I figure I might as well try the rest of the community here too.

This is a copy and paste of my problem description which I have sent to NI and it is very similar to what I have written in the discord channel:

 

I am building a new PXI-based test system that duplicates an older system which has been working reliably since around 2019. The purpose of this setup is to provide absolute time to an FPGA so that all FPGA read/write signals can be timestamped correctly.

The timing architecture is as follows:

• A PXI-6683H generates a custom 1 Hz pulse using NI-Sync.
• This pulse is routed over PXI_Trig0 on the backplane.
• In the LabVIEW RT application, on the falling edge of the pulse, I write the next whole second value to the PXIe-7820R through a front panel control.
• On the rising edge, an FPGA loop is expected to trigger, latch that value as valid, and update the FPGA time function.
• Between pulses, the FPGA time is advanced using the FPGA internal 40 MHz clock.

To verify that the FPGA loop has triggered, the FPGA sets a status indicator to 1, which I read back from the RT side. In the failing system, this status always remains 0. I also observe that other FPGA functions appear inactive. Based on this, my conclusion is that the FPGA is not seeing the trigger, or is not responding to it.

Important context:

• The same software and FPGA firmware concept works in another chassis, a PXI-1062Q.
• The new system uses a PXI-1084 chassis.
• I am aware that the PXI-1084 is divided into three trigger bus segments, but both the PXI-6683H and PXIe-7820R are installed within the same segment.
• I have verified that the PXI-6683H can generate a signal.
• In MAX test panels, I can successfully drive PXI_Trig0 from the 6683H and read it back using MAX functionality, which suggests that the 6683H is operational and that PXI_Trig0 exists at least in some sense.
• I have formatted the RT controller and reinstalled software, but the issue remains.

My main question is whether there is any chassis-specific routing limitation, configuration requirement, or compatibility issue in the PXI-1084 that could prevent a user-generated PXI_Trig0 signal from being seen by the PXIe-7820R, even when both modules are in the same trigger segment.

 

So... anyone? I am hoping for a super obscure yet super easy solution here.

 

Edited 1 hour ago by codcoder

[Miles-lava]

Bit of a long shot but is your FPGA initialising Trig_0 in any way, e.g. Setting it to F on startup to get it into a known state?  I've just recently fixed an issue on my 1085 system where everything was running normally until I used a FPGA card to set a trigger.  Once this had happened the trigger was reserved by the FPGA and I could no longer control it through DAQmx even if I closed and restarted the DAQmx tasks, but I also didn't get any DAQmx errors.