LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA missing routed triggers on PXI Trigx

This is a duplicate post, but I need an answer quick.

I'm setting up a system with a 14 slot PXI chassis using a MXI-4 fiber optic controller. The chassis is holding a PXI-5112, a PXI-6251, PXI-7831R and 4 PXI-6133 cards.

What I’m attempting to do is receive an external trigger into a PFI of one of the 6133 cards to trigger an acquisition on the cards and route that trigger to PXI_Trig0 so the FPGA can create some triggers for some external instruments that need to be delayed by different amounts of time.

I have this working, but occasionally the FPGA misses a trigger and I don’t see any reason for it.

The attached VIs show a simplified version of my setup. It’s generating 6 triggers on digital lines with a different delay for each trigger. Most of the time, the FPGA gets the trigger and generates the delayed triggers, but sometimes not. There’s a counter showing the number of start triggers generated and the number of times the FPGA gets triggered.

Am I doing something wrong or is there an easier way to do this.

Any suggestions appreciated.

This is all LabVIEW 8. "Test Triggers.vi" is the host VI and "Triggers__diocles.vi" is the FGPA VI.

Thanks

Ed


==========================================
Edwin Dickens - Certified LabVIEW Developer
LabVIEW Champion
DISTek Integration, Inc. - NI Certified Alliance Partner
http://www.distek.com
Hey Rocky, watch me pull a VI out of my hat.
==========================================


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
Download All
0 Kudos
Message 1 of 3
(3,343 Views)

You may miss triggers for 2 reasons from what I see.

1) Using a While Loop to sample the Trigger

The FPGA VI is using a while loop to sample the trigger line.  Using the while loop has overhead and limits the sampling rate of the trigger line to 8MHz in your case.  If you replace this while loop with a timed loop (simply right click on the loop and replace) you can sample the trigger line at 40MHz.  You could even then use a derived clock (create one from the 40MHz clock) at a very fast rate, perhaps 200MHz, and use this new derived clock as the timing source for the timed loop. This would allow you to make sure you have high enough resolution sampling the trigger line.

2) You are busy performing your delayed outputs and miss a new trigger

After you receive a trigger your code goes into generating the delayed outputs.  It seems the time spent on these operations is long (hundreds on msec).  If your code is running through the sequence structures creating the delayed then it cannot be waiting for the next trigger. Depending on your trigger behavior you may completely miss the new trigger. It appears that you are generating the triggers every 5 seconds so this is less likely.

Also since you are just looking at level and not rising edge you could run into the case that the trigger is still high from the previous run.  When your trigger loop executes again it would immediately stop since the level is still high.  This would cause the Main Loop (FPGA Triggers) to be greater than the Aquisitions.  You did not mention this was happening, but it is worth noting.

I recommend changing the while loop to a timed loop since you are likely undersampling the trigger line.

Regards,

Joseph D.

National Instruments 

Message 2 of 3
(3,340 Views)
Thanks Joseph,

Replacing the While with a Timed Loop running at 40MHz seems to have taken care of it. I'm going to let it run for a while just to be sure. I'll also change it to watch for a rising edge just in case. I didn't realize the regular While Loop had so much overhead. That's good to know.

The possible issue you describe in "2" won't be a problem. The actual delays I'll using are in the milli to micro second range and the trigger pulse can arrive no faster than once every 100ms and the 250ms delay to turn the triggers off will be more like 5-10ms. I just have everything stretched out here so I could see whats happening.

I was hoping there was an FPGA function I was missing that would just sit and wait for a PXI_Trig line to go high so I wouldn't have to poll it at all. No such luck??

I've got 100 acquisitions and 100 triggers so far, so it's looking good.

Ed


Ed Dickens - Certified LabVIEW Architect - DISTek Integration, Inc. - NI Certified Alliance Partner
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
0 Kudos
Message 3 of 3
(3,334 Views)