PXI

cancel
Showing results for 
Search instead for 
Did you mean: 

pxi multiple device trigger problem

Hi all --
 
We have a PXI chassis with a PXI5404 clock generator, some 5122 scopes, a 5421 AWG and some 6552 HSDIO cards. The clock generator puts a clock signal on the PXI start line that serves as main sample clock for all other devices.
 
All of the devices start together using the TClk synchronisation mechanism.
 
We want to add a second AWG to our system, a standalone AWG. Because this one can't be locked to an external signal, we let this external AWG generate a 10MHz signal and feed it to the REF IN channel of our 5404 clock generator, which locks itself to this signal. So the PXI starline is synchronous to the 10MHz of the AWG, which has been verified by looking at the output of one of the HSDIO cards: the output runs synchonous to the 10MHz generated by the external AWG.
 
Now we want the external AWG to generate another signal (of course), and we want this signal to start together (a constant delay is also OK) with the output of 1 of our HSDIO cards. Therefore, we have routed a trigger signal from the external AWG to the PFI0 input of the HSDIO card. The HSDIO card uses this script:
 
script hsdio2script
  wait until scripttrigger0
  Repeat forever
     Generate data      
  end repeat
end script
 
So we want the HSDIO to wait for the trigger pulse sent by the AWG, and then start outputting the data waveform continually.
 
The problem: every time we restart our main VI, the delay between the trigger pulse and the beginning of the data waveform is different! We need to get this delay to be constant.
The HSDIO card itself reacts OK when using a separate VI that drives only the HSDIO with the same script : each time the VI is restarted, the waveform begins at the same position relative to the trigger pulse.
So my guess is that the TClk causes some problems, but I can't find any descent examples on using triggers with TClk.
 
 
I hope this introduction was complete enough; if not, please ask some more specifcations.
0 Kudos
Message 1 of 7
(4,101 Views)
When using a 40MHz clock on the PXI starline, the delay between rising edge of the trigger and start of the waveform is between 2 and 3 microsecs. When using a 80MHz clock, the delay halves: between 1usec and 1.5usecs.
0 Kudos
Message 2 of 7
(4,085 Views)
Hello,
 
When you use NI-TClk, the incoming triggers are synchronized with a slower clock called the "TClk".  This slower clock is a common multiple of each device's sample clock and ensures that each device will "see" the trigger on the same clock edge.  The problem you're facing is that each time you call "TClk Synchronize", the synchronization of the trigger is redone and the trigger will end up being synchronized on a different clock edge with respect to the time the trigger comes in.  That's what is causing the jitter in your trigger response time.  There are two solutions to this:
 
1)  Only call TClk Synchronize once.  Once you call it, everything will remain synchronized until you close your session and your response time will be fixed; there is no need to call it multiple times. 
2)  If this doesn't work, and your system depends on a predictable trigger response time (for example, it has to ALWAYS be 1 microsecond), you may consider not using NI-TClk.  Without NI-TClk, you can align the input/output of two devices to within one sample clock period - maybe that's enough for your application?
 
Also, how are you using your 5404?  Is it in slot 2 of the PXI Chassis?  What rate is the clock that the 5404 is providing on the PXI-Star lines?
 
Drew Creel
National Instruments - Signal Generators
Software Engineer
Drew Creel
NI Software Group Manager
RF and Signal Generators
0 Kudos
Message 3 of 7
(4,065 Views)

If your second AWG was also a National Instruments AWG, you could do this.  You would include the second NI AWG in your TClk synchronization (so it shared not just a commone Refernce clock, but also a common trigger clock (TClk)). However, this second NI AWG would not start at the same time as all the other devices in the system.  It would start with it's own Start Trigger (which could be immediate, software, digital edge, etc.), but the start trigger would be delayed so the AWG would start on the next TClk edge.  If the "trigger" being exported by the second AWG was a marker event, it would alway come out at a particular sample, which has a fixed relationship with the TClk edge that the AWG started on.  This "trigger" (event) would then be received by the other devices in the system and you HSDIO device(s) would also start with a fixed delay between the "trigger."


The fundamental problem is that your external AWG, while sharing a reference clock, is not starting, nor exporting it's trigger, synchronous to the trigger clock (TClk) that is starting the other devices.


Neil Feiereisel
Software Engineer
Modular Instruments
National Instruments

Neil Feiereisel
Principal Engineer, Modular Instruments, National Instruments
0 Kudos
Message 4 of 7
(4,039 Views)
Thanks for the replies. The setup has been in use the last week for some urgent measurements, I will try your suggestions when these are done.
0 Kudos
Message 5 of 7
(4,010 Views)
Hi again,
 
@Drew Creel :
I tried implementing your solution, but I get the same result. I'm not sure however I've done everything the way it's supposed to be done, as the whole TClk thing is new to me. This is how I implemented it:
 
Almost our whole VI is placed withing one while loop, except for session generations. Inside the while loop, the named waveforms of all HSDIO cards are filled, the scripts are created and the cards are configured. Then, all their sessions are merged into an array, and this array is passed to 'niTClk Configure For Homogeneous Triggers.VI', 'niTClk Synchronize.VI' and 'niTClk Initiate.VI' (in this order). The devices start running their infinitely looping scripts. One of these cards starts running after it receives an external script trigger 0 (see the script in the first post).
 
When the user presses a button, the cards operations are aborted and their named waveforms deleted. The loops restarts: named waveforms are created, cards configured. Now, I only call the 'niTClk Initiate.VI', as you proposed.
 
The response time of the HSDIO card that waits for the script trigger 0 still is different every cycle of the while loop. I have not yet set any master trigger session settings, as I don't know if these are related to my problem.
 
The final goal would be that all devices start together after one of the HSDIO cards receives an external trigger. Important is that the response time is the same for every iteration of the while loop.
 
 
@NeilF:
Thanks for the suggestion, but our AWG is not from NI.
 
Once again, thanks for your suggestions, I appreciate them a lot.
Riemer Grootjans.
0 Kudos
Message 6 of 7
(3,994 Views)
Hi Riemer,
 
Unfortunately, it is very difficult to have deterministic trigger response time when using TClk.  If you are only calling niTClk Synchronize.vi once, like you said, then you should be seeing a jitter in the trigger response time that is within one TClk period.  To measure the TClk period, you can route the TClk signal to a PFI or backplane trigger line using the "DAQmx Connect Terminals.vi" - specify "/Dev1/TClock" as the source and "/Dev1/PFI0" as the destination, for example (replace "Dev1" with the resource name of your device).  Call this VI after calling "niTClk Initiate", and call the "DAQmx Disconnect Terminals" VI to disconnect the terminals.
 
To reduce the trigger response time jitter, you can try triggering your external Arb off of the TClk signal, and then having the external Arb trigger the HSDIO device.  To do this, after you call "niTClk Initiate" on the HSDIO device, use the DAQmx terminal VIs to route the TClk signal to the external Arb.  The external Arb will then start on a TClk edge and will send the trigger to the HSDIO device, which will recognize the trigger on another TClk edge.  The number of TClk edges between the time the trigger is recognized by the external Arb and the HSDIO device should remain the same from run to run, so your trigger response time should have much lower jitter.
 
Hope that helps,
Drew Creel
National Instruments - Signal Generators
Software Engineer
Drew Creel
NI Software Group Manager
RF and Signal Generators
0 Kudos
Message 7 of 7
(3,952 Views)