Fgen : Synchronisation + Delay insertion

[gvanhoeke]

Hi !

Here is the screenshot of my error cluster (not very instructive ...)

Hope it helps ... Thank you for your consideration !

Kind regards,

Geoffrey

[CollindeWit]

Hi Geoffrey!

By default, arbitrary waveform generators use High-Resolution Clocking to generate a waveform if the sampling rate chosen is not an exact integer division of the maximum frequency of function generator. When High-Resolution Clocking is used, the sampling rate specified can actually be coerced to a slightly different value than specified.

For example, with High-Resolution Clocking enabled, specifying a sampling rate of 88 MS/s results in an actual sampling rate of 87.9999999 MS/s. When synchronizing multiple devices using NI-TClk, the algorithm will attempt to choose a TClk frequency that all sampling rates can be divided into evenly. Having an actual sampling rate of 87.9999999 MS/s throws off the NI-TClk algorithm resulting in error -250016.

One workaround is to disable High-Resolution Clocking and use Divide-Down Clocking instead. You can do this in LabVIEW using the Clock Mode property of the niFgen Property Node, and setting the value to NIFGEN_VAL_DIVIDE_DOWN.

Hopefully this helps you!

Best regards,

Collin

[gvanhoeke]

Hi Collin !

Thank you for this remark, indeed the code runs without any error now.

However, the burst I generate with my FGen is not really synchronized with the pulse coming from my DUT (with the delay desired).

I expected both signals (pulse from DUT & burst from FGen) to appear "at a fixed distance" from each other on the screen, but the burst just travels wildly along the time axis, it seems to trigger at the first pulse received but to loose synchronisation after then ... (even when I use "stepped" mode in trigger mode ...).

Do you have any idea to fix this ?

Kind regards,

Geoffrey

[CollindeWit]

Hi!

So if I undertsand you correctly you would like it to be retriggerable? O does the timing seem to change according to yo. Its not that clear what the issue is that is happening and what behaviour you are expecting.

Hope to hear more from you!

Best regards,

Collin de Wit

[gvanhoeke]

Hi Collin !

I have jointed 2 videos to make things clearer.

1) Actual result : What I see on the screen of my ultrasonic device (remote on a computer screen) with the vi we have built together so far. The "triggering" happens fine (since the burst appears on the screen) but there is no real synchronisation (the burst travels along the time axis of my screen and the original pulse of my ultrasonic device stays the reference at the very left side of the screen).

2) Expected result : What we have done so far in our lab (injecting a burst with a tektronix generator and observing it on the instrument itself). The pulse of the ultrasonic instrument is taken as trigger reference, I can adjust some delay parameters for the burst to send back to the ultrasonic instrument (in order to move it more rightwards on the screen). The burst just appears to be "static" regarding the original pulse of the ultrasonic instrument.

I don't know if the tektronix generator really "retriggers" everytime but if it does I did not have to chose that option on it ... Maybe it should be precised somewhere when using NI material ? If so, please let me know.

I hope it's clearer, thank you for your help !

Kind regards,

Geoffrey

[CollindeWit]

Hi Geoffrey!

Sorry it took some time to respond. But i was analysing your videos and was wondering if we can verify some things. The burst on the actual seems to be done by a certain frequency. It also ssems consistent, but unfortunately I cannot calculate this due to the image quality. This might be ood to verify, If the burst is sent at a certain freuqency and if this is expected. Or maybe widen your time axis so we can see several pulses.

Is there any way to connect the output to that oscilloscope? To verify with the same system if it gives the same output?

Also, if you only send the burst, so with no trigger and no original pulse, what is being displayed in labview?

To me it seems that the burst is not equal to the frequency of the original pulse, and thus generating time difference for display. But on the expected video it is. What do you think of this?

I think we should start to verify exactly what is being output on both systems and compare that. Also try to output only one and when those are correct lets try to synchronize them. But first verify without triggers and sync. if they output correctly.

Hope to hear from you!

Best regards,

Collin

[gvanhoeke]

Hi Collin !

Please find my answers in this post in green.

Is there any way to connect the output to that oscilloscope? To verify with the same system if it gives the same output?

Since the "NI TClk Initiate.vi" provides from using the "scope read.vi", this is quite tricky. I am forced to use the "scope fetch.vi" in order to collect data and this provides me only one frozen graph while the vi is running. However, it is already possible to see that the burst is not generated with a constant time delay from the original pulse, anyway.

Also, if you only send the burst, so with no trigger and no original pulse, what is being displayed in labview?

The expected burst, without any problem. May I add 2 things :

1) The graph contained in the "actual" video is not in LabVIEW (but in Tomoview, the software used to control the DUT and to display the data).

2) The burst observed in the video is rectified.

To me it seems that the burst is not equal to the frequency of the original pulse, and thus generating time difference for display. But on the expected video it is. What do you think of this?

Indeed, that's the problem. On the "expected" video, we used a tektronix generator synchronized via its "trigger channel" and that was it ! With NI material, triggering just seems to start the signal generation but it doesn't necessarily implies that the signal generated will be synchronized with the triggering signal, just like if a kind of "repetition frequency" should be tuned as well. If yes, how can we do this ?

I think we should start to verify exactly what is being output on both systems and compare that. Also try to output only one and when those are correct lets try to synchronize them. But first verify without triggers and sync. if they output correctly.

According to the answers above, I think the outputs are understood correctly and I would rather say there is a poor management of "triggering and synchronization" from my side ...

What do you think ?

Kind regards,

Geoffrey

[gvanhoeke · Accepted solution]

For those who might be interested, the problem has been solved (solution proposed by Peter Horn, an AE specialist from NI).

TClk doesn't seem to be the best option for this kind of synchronization, therefore he recommended to simply use a script to continuously trigger the burst generation on a signal sent by the scope in the backplane of the PXI. The delay between the triggering pulse and the response burst is indirectly handled by the number of zeroes inserted in the desired waveform.

Many thanks to you Collin for your help along this issue-solving, and thank you Peter Horn for this easy alternative.

Kind regards,

Geoffrey