LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Proving synchronisation

I am new to labview. In my project, my primary task is to have synchronised transmission and reception using ports of same NI board usb 6356. I have used "dev 3 ao sample clock" for the input port of the same board. You can see this in picture attached.
This method of using same clock for input and output ports is standard method suggested on the NI website.

But before setting up my hardware system, my team and me want to see whether this method is working correctly over long period of time (2 or 3 hours).
How can I prove that there is no mismatch in synchronisation even after running my code for long time???

Aim of my code: To transmit different signals through the output port into the waterpipe and start acquiring the signal (in the input port of same board) in synch with the transmission. Both transmission and reception should start at same time and should remain synchronised untill the end of the experiment. 

 

Please give the answer in detail.

 

Thank you.

0 Kudos
Message 1 of 7
(2,990 Views)

Please do not attach pictures of VIs (especially not .jpgs) -- attach the actual VI so that we can closely inspect and "play" with it.

 

Bob Schor

Message 2 of 7
(2,943 Views)

Sorry

I have attached the vi.

Actually my problem is not related to my vi. It is related to the standard method of synchronization (as suggested by NI : ie sharing clock of output port with input port). I want to prove that this method really gives synchronized results. 

0 Kudos
Message 3 of 7
(2,934 Views)

@Amartansh13 wrote:

Actually my problem is not related to my vi. It is related to the standard method of synchronization (as suggested by NI : ie sharing clock of output port with input port). I want to prove that this method really gives synchronized results. 


What do you mean by "prove that this method really gives sychronized results"?  If you mean "Do an experiment using external measuring devices, like oscilloscopes, to show the results are synchronized", then the best you can do is to disprove this by showing a single example (perhaps with a 0.00001 probability) where the signals are not synchronized (you only need a single example to disprove something, but it is much harder to test the infinity of outcomes to be sure they all "match").

 

On the other hand, if you are arguing logically about design, and say something like "I have a clock signal that goes to two devices, I've asked those two devices to count those signals and, on the basis of that count, take appropriate actions", then the "proof" comes down to (a) knowing that you gave the correct instructions (i.e. you didn't tell one to go at 100 Hz and the other at 101 Hz), (b) knowing that you started them appropriately (both on the same trigger edge, for example), (c) knowing that you haven't put an "impediment" in front of one of them (having a "data flow" problem) to slow it down, and (d) doing a test to convince yourself that you haven't made some silly programming error ("Trust, but Verify", as a former President once said).

 

Bob "IMHO" Schor

Message 4 of 7
(2,910 Views)

NI has tested those boards.  If you command the AI and AO to use the same clock (which you did), then how could they not be synchronized?  If you set something up wrong, you will get an error.  So what part of the system do you not trust?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 7
(2,886 Views)

One simple way to prove your synchronisation is a direct reading of your AO with an additional (spare) channel. 

 

In a real world mechanical system your analog output goes into a transducer and other transducers produce a voltage output you want to capture. These transducers will add some (hopefully constant) groupdelay. 

 

With a 50kHz Sine and 1MSPS  and tone detection to measure the phase differences, you can measure the length of your connecting cables   (~4-5 ns/m)  🙂

 

Greetings from Germany
Henrik

LV since v3.1

“ground” is a convenient fantasy

'˙˙˙˙uıɐƃɐ lɐıp puɐ °06 ǝuoɥd ɹnoʎ uɹnʇ ǝsɐǝld 'ʎɹɐuıƃɐɯı sı pǝlɐıp ǝʌɐɥ noʎ ɹǝqɯnu ǝɥʇ'


Message 6 of 7
(2,877 Views)

Amartansh13,

 

I would suggest that you run your experiment in a manner that you know what the result should be (i.e. repeating an experiement that has already been done).  If the results check out, you can assume that your system is working as expected.  If the results don't check out, start troubleshooting.

 

-DR2

Message 7 of 7
(2,840 Views)