Synchronize 5122 and 6542

[billmileski]

Hi,

I need to synchronize acquisition with a PXI-5122, and digital pattern generation with a PXI-6542. Both are in a PXI chassis, and am running Labview 8.2.

I have a VI that outputs patterns with the 6542, and added "HSDIO configure ref clock" to its configuration, but was surprised that once I sent a software trigger, there seemed to be a new, several second delay before the pattern was sent.  I had read somewhere that locking the internal clock PLL to the ref clock can take five seconds.  If this is the case, can I establish this somehow before enabling the trigger, or am I mistaken entirely in what I think I'm seeing?

I am happy to have both the 5122 and 6542 clocking at 100MHz. Would it be better to export one's clock to a PFI and use this PFI on the other as the clock source?  Does the first device (source of the clock) need to be configured before the other device is configured to use it as a clock source?

Thanks for any help,

Bill Mileski

[billmileski]

I had subsequently decided to use TClk to synchronize each device's 100MHz internal clock, and treat the 6542 as "master", and use a software start trigger.  The 5122 would be "slave", and inherit the start trigger, and be synchronized. The software trigger would start each device at the same time, and I would be able to predict which samples go with which part of the digital pattern (which drives a multiplexer selecting analog outputs from a big array).

But, to further complicate matters, I found a line in the 6542 spec that reads:

"Delay from trigger to digital data output:   32 Sample clock periods + 160 ns"
(from http://www.ni.com/pdf/manuals/373771b.pdf)

I have no idea whether this a very predictable, stable delay between triggering the pattern generator, and the onset of digital output?

Multiplexing rate (fastest waveform in pattern is a shift register) is about 2.5MHz, and I'd like to get one sample per "pixel" (not really pixels in this app.) and up to 40 per sample, via adjusting decimation on the 5122 digitizer between 1 (100MS/s) and 40 (2.5MS/s). Just to give you an idea of speeds involved.

Does anyone know about this delay in starting pattern output in a 6542, or have any other suggestions?

Maybe use the 6542 to simultaneously acquire one of the pattern outputs, and have the driver time stamp it? And time stamp the 5122 record?

Thanks for any thoughts,

Bill Mileski

CAC

[Ryan_M]

Bill,

It sounds like you have a lot going on so maybe it would help out a little if you could explain your application and the problem you are trying to solve.

It sounds like you have a 6542 generating a pattern to some black box from which you want to capture the analog response.  The analog capture needs to be at the same or an integer divisor from the same frequency and you don't want to start the analog capture until the 6542 is generating.  Is that accurate?

In this case I think TClk may not be necessary.  You could use one of the output events from the 6542 (such as data active or marker event) to act as a start or reference trigger for the 5122.  With a data active signal, the 6542 will change the level of the pfi line to signal that data is active and valid.  You can use this as an edge start/reference trigger on the digitizer.  In this fashion, the 5122 won't start acquiring until the 6542 tells it that the data it is generating has started.

You can achieve the frequency lock by either using the onboard PLL's of both device and lock to the backplane 10MHz or you can export the clock from one device to be used by the other.  Please note that the clock to the 6542 needs to be freerunning so if you export the signal to the 6542 from the 5122, make sure the clock is being exported before you attempt to start your generation.

Specifically, to answer your question about the delay from trigger specification, the 6542 receives a trigger on the front panel.  This trigger is sampled using the generation clock and then gets consumed by an internal statemachine.  You'll notice that the specification is a function of absolute time and of clock cycles.  This is due to analog deterministic delays through traces and components and cycles indicating that the trigger goes through stages of pipelines before it gets consumed.  That specification is an upper bound in that it will not take longer than that amound of time but it could occur sooner.  There is additional ambiguity in how this trigger is consumed deterministically in that often that trigger is not generated from a source operating at the same clock rate as the 6542.  Since the source and receiver are not frequency locked in this case, there is some probability that the event gets sampled +- 1 clock cycle

I hope this helps

-Ryan

[billmileski]

Hi Ryan,

Thanks for the reply.

You are right, the 6542 is generating horizontal and vertical shift registers, to select different analog outputs from a black box.  The only way I know which output I'm sampling, is to have synchronization between the 6542 output and the 5122 acquisition.

I am encouraged to hear that a data active event might provide the synchronization I'm looking for -- I haven't yet looked at the specs for the determinism of this method, and will do so shortly.

I am glad you explained the delayed output in response to triggering. I was starting an experiment to see if it was consistent, and if I could count on it.  I won't bother!

Just had another idea:  I wonder if I could use a software trigger to start the 6542 generation (GUI button press), and then use simultaneous acquisition on the 6542 to start trigger on a pattern match, indicating that generation is underway.  Then maybe I could treat the 6542 acquisition session (which is separate from the gen session) as a master in a TClk sync with the 5122 as slave. This assumes a pattern match start trigger is a valid TClk start trigger type, and also that the acquisition side of the 6542 does not suffer the same start delay after triggering as the gen side.  Any thoughts?

Thanks again.

Bill

[Ryan_M]

Bill,

If you need a trigger synchronous to different digital patterns then i might recommend the exported marker event.  When you are using scripting to generate a digital waveform, you have the ability to generate a pulse on specific samples in a waveform.  For example, I have a 100point waveform where the first 10 samples are associated with DAC_A, the second 20 samples are associated with DAC_B, the next 50 samples with DAC_C, and the final 20 samples with DAC_D then I could use the following generate statement:

generate MyWaveform marker0(0) marker1(10) marker(30) marker3(80)

You can then export these markers to any of the available PFI/PXI_Trig/RTSI lines.

You can use the script editor installed with NI HSDIO to play with various scripting functions.  You can find this application installed in your START>>Programs>>National Instruments>>NI HSDIO>>Script Editor.  When you use the "Add generate" function, a window will pop up that allows you to add markers at specific samples in the waveform.

To answer your question, you can certainly use a software start trigger.  However, you achieve the similar behavior by using no start trigger and just calling the start vi based on some control input.  The software start trigger is found in the "Measurement IO>>NI-HSDIO>>Generation>>Utility>>Send SW Trigger" vi.  If you have your generation use a SW start trigger then this vi is used to fire that trigger.

Also, data active is 100% deterministic / synchronous with your data when exported to a PFI.  If you export it to one of the PFI on the DDC connector then all of the pin to pin skew, clock to out, etc specifications will hold true.  This event will be active on the first sample of the waveform, will go inactive when the device is paused or when the waveform stops.  This is the signal you would use to handshake with another device (ie, connect data active to a pause request line).  If you use RTSI, the data path is not shared between data and trigger so you may see skews or non deterministic behavior depending on how that trigger is consumed.

Finally, you can definitely run an acquisition and a generation on the same channel at the same time and there are a couple of examples that show this.  Based on the quick explanations you've provided, it sounds like this approach may be more complicated than necessary.  I might suggest looking through the triggering section of the documentation to see if those marker or data active events will give you the coverage necessary.

Let me know!

-Ryan

[billmileski]

Ryan,

I will definitely look into how markers are used.  I may still try and preserve a TClk approach (that is if my idea in my last post was valid) because if I can precisely align the clocks, I can have greatest confidence in trying to oversample each analog output as they are selected by the multiplexer, driven by the 6542.  Otherwise, with clocks only frequency locked to the PXI reference clock, there can be a phase difference of 0-1 clock cycle between the two, and this could limit my confidence in digitizing a "pixel's" value near the beginning and end of it's presence at the multiplexer output.

I need to research the notion of pause triggering.  I wonder if that implies that my waveform script could allow me to send a marker as trigger to the digitizer, when a row of pixels starts, and a marker allowing a pause in acquisition at the end of the row until the next row starts (there is a nonstandard delay between rows in the way this sensor works).  Another thing I need to understand better.

Anyway, thanks, and if I learn anything interesting, I'll let you know!

Best,

Bill

[Ryan_M]

Bill,

One caveat to using a marker as a pause trigger is that the marker is intended to be an edge trigger.  That is, the incident edge of the marker event is synchronous to a specific sample but the duration of the marker event is not deterministic.  It is bounded but varies by +- a few samples.

Good luck bill and don't hessitate to throw out any more questions

-Ryan

[billmileski]

Hi Ryan,

Thanks for the info -- it seems you can specify marker duration in NIFgen, but not HSDIO.  Anyway it looks like the 5122 (supported by NI-SCOPE driver) doesn't support a pause trigger.  So I'm using a marker in the 6542 pattern script, exported to PXI-trig1/RTSI1, and on the NI-SCOPE side, as a digital edge ref trigger, positive slope, with source on RTSI1.

It's interesting and annoying that there is inconsistency in nomenclature between the two (HSDIO and NI-SCOPE, see prev. sentence).  And different devices can use certain i/o assets as sources, inconsistently (e.g. 6542 can export markers to PXI, but cannot export Data Active event to PXI, only PFI).  These things trip up a newcomer like me.

Bill

[billmileski]

Ryan (and anyone else),

A new problem:

I thought I was triggering the PXI-5122 with a marker event generated by the PXI-6542, exported on PXI Trigger Line0/RTSI0, but closer inspection revealed that the 5122 was defaulting to immediate start triggering.  I am simultaneously acquiring on the 6542 as a sanity check, and it successfully triggers at the marker, with "PXI Trigger Line0/RTSI0" as the source.

The only trigger configuring of the 5122 was with "niScope Configure Trigger Digital.vi" (Digital Edge Ref Trigger, RTSI_0, positive slope).  This is I guess only to set common properties for all digital edge trigger types on a particular source? I since added an niScope Property Node that sets "Start Trigger Source" to "VAL_RTSI_0", and now it won't trigger.  If I change "VAL_RTSI_0" to "VAL_IMMEDIATE", I get immediate triggering again.

I'm assuming that this is how to configure a start trigger on a PXI-5122, and that selecting RTSI 0 is the same as "PXI trigger line 0 / RTSI 0" defined by the 6542 setting?

I would have tried PXI_STAR as a start trigger source on the 5122, but you can't export a marker event to PXI_STAR in HSDIO.

I ordered some SMB connectors yesterday so I can try direct connection of PFIs between the two boards, but on the 5122 the PFIs are on a DIN-type connector I don't have a mate for.

Help appreciated!

Bill

[David L.]

Hi Bill,

I believe it would be best to continue the new issue in your other post, here. Going with TCLK will be a much easier and cleaner solution than trying to route signals manually.