PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

PXIe multiple chassis triggering with 6674T and no TClk

Solved!
Go to solution

This will be a long one.

 

This is a continuation of the topic of PXI to PXIe multiple chassis migration. Camilo Vargas pointed me to a great blog post on Synchronizing multiple chassis by swatts. That got me a lot of the way down the road in my setup, but a few key differences between my setup and that one are tripping me up now. I should start by explaining my setup. I don't have the time to draw a diagram, so a word picture will have to suffice. Smiley Happy

 

Hardware

I have three PXIe-1085 chassis (though unlikely, it could be even more, but I'd like to stick to this base case for now). One of the chassis, which I'll call the master chassis, has the shiny new PXIe-8301 Thunderbolt Remote Controller in slot 1, two PXIe-8364 MXI bus extenders in slots 2 & 3 to connect to the slaves, a PXI-6683H Timing Reference in slot 9 to provide time of day synchronization to the rest of the system, a PXIe-6674T System Timing Module in slot 10 to distribute a sample clock and trigger signals to the rest of the system (and the modules in the chassis itself), and the remaining slots are populated with PXIe-4303 DAQ cards. 

 

In the two slave chassis, I have a PXIe-8360 MXI Remote Control Module in slot 1 to connect to the bus extenders in the master. There is a 6674T in slot 10 to receive timing and triggers from the master and distribute to the slots of the chassis, and again the remaining slots are populated with 4303s (I'm trying to make a lot of voltage measurements at the same time). 

 

Clock Routing

I am using NI Sync to route the clock, and I'm letting each 4303 derive its own sample clock from the backplane PXI_Clk100, as recommended in Synchronization Explained, Table 2. I actually have some diagrams of this for my setup. I put them inside a spoiler since the images are so large.

 

 

Spoiler
MasterChassisClockRouting.pngSlaveChassisClockRouting.png

 

There two differences between the diagrams and my actual setup: the first is that I am routing the ClkIn port on the master 6674T directly to PFI_LVDS0, so the slave chassis are being disciplined by the 6683H directly rather than by the OCXO on the master 6674T. Functionally, this is almost the same thing (I think). The second difference is that I'm not using any clock disciplining software. From my understanding, the software is not necessary since I have the right timing modules. Let me know if there are any lies in those diagrams or what I've written so far, because I'd like to catch them early before things really matter

 

DAQ Configuration

Obviously, I'm doing this part with DAQmx. I take all the channels from all the 4303s in all the chassis and put them into a single `AI Voltage` task. I designate PXI_DStarB as the sync pulse source in DAQmx via the `SyncPulse.Src` property and I designate PXI_Star as the start trigger source using the `DAQmx Start Trigger (Digital Edge)` VI (it looks like I can also use a property node to set the start trigger, but I'm not sure if it's preferrable to the start trigger VI).

 

Trigger Routing

Once again, I am using NI Sync for signal routing. What I'm trying to do is send a sync pulse via software trigger to all the 4303s in the system. I am doing this by connecting the software trigger to PFI_LVDS1 (to the slave chassis) and PFI4 (back into PFI5 so that master chassis gets the trigger over the same line length as the slaves). Because I remember it being recommended in documentation, I invert this signal, and the sync pulse triggers everything by its falling edge. For each chassis, I connect the input PFI port that receives the trigger to PXI_DStarB. I then send the software trigger. Since there are no errors when I run my code up to this point, I think that means it's working. I bet there is a way to tell if the sync pulse is really doing its thing via property nodes, and I'd love it if someone could enlighten me.

 

Next is start triggering. After the sync pulse trigger, I disconnect the software trigger from all of its connections and reconnect them without the inversion that was necessary for the sync pulse. I also disconnect all the input PFI ports from DStarB and connect them to PXI_Star. Everything should now be ready to start.

 

Starting DAQmx Task

The next thing I do is start the DAQmx task. This is where I run into trouble. I receive an error -89125, which tells me 'no registered trigger lines could be found between the devices in the route'. Specifically, I get this:

 

```

DAQmx Start Task.vi:7220001<append>
<B>Source Device: </B>PXI1Slot3
<B>Source Terminal: </B>te3/StartTrigger
<B>Destination Device: </B>PXI2Slot3
<B>Destination Terminal: </B>te0/StartTrigger

```

 

So where did I go wrong? If you made it this far, thank you in advance for your time.

0 Kudos
Message 1 of 3
(2,992 Views)

Forgot to add: the blog post seemed be able to solve a lot of routing and trigger specification through the use of TClk. Apparently, TClk is only used with the 'PXI Modular Instrument' line of modules, and the PXIe-4303 falls under the 'SC Express' line (did I get that right?), so I need a different mechanism for telling modules that they share triggers.

0 Kudos
Message 2 of 3
(2,991 Views)
Solution
Accepted by topic author KingWeasel11

Actually, I think this one answers the question of where I went wrong:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kEXuSAM&l=en-US

 

The original source code for the PXI system I'm replacing allowed modules from different chassis to be in the same task. I thought it would be the same with PXIe. I guess I'll have to live with that.

 

In light of that, this post answers the question of how I synchronize multiple chassis:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kHJ7SAM&l=en-US

 

I think I'll just have to be extra careful when making reads from different tasks and then merge the data from them based on if timestamps match.

0 Kudos
Message 3 of 3
(2,970 Views)