LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Could someone please provide feedback on if I have programmed timing with RTSI cable corectly?

Solved!
Go to solution

Hi everyone,

 

I have been trying to get the AIs on Dev0 and Dev1 synched using the RTSI cable, which has been configured in MAX... Is the below code sufficient to synch the signals across both devices? Or do I still need a digital trigger?

 

I was using a digital trigger with a flat sequence etc as per the Labview example (hence the master and slave labels still remaining in the code), but I couldn't get Dev0:ao0 to write when "Waveform" was selected at the timing source for AO channel... I kept getting an error saying the refclocksoruce was already in use (or something to that effect)..

 

Any comments would be greatly appreciated.

 

Regards,

Jack

Picture1.png

0 Kudos
Message 1 of 10
(3,723 Views)

Anything on a card that uses a sample clock must use the same sample clock.  So you need to set your AO to use the sample clock and clock rate as the AI tasks.

 

Edit:  Nevermind.  It's the reference clock that all of the card's tasks need  to be the same.


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
0 Kudos
Message 2 of 10
(3,715 Views)
Ok... Thanks... Making more sense now..

But are the AIs on dev0 and dev1 using the same clock in my earlier code? Or do I need set the source clock on dev0 to "onboard clock" refclk on dev1 to rtsi0?

Regards,
Jack
0 Kudos
Message 3 of 10
(3,707 Views)

Hi jcannon,

 

Please refer to the example "Multi-Device Synch-Analog Input-Cont Acquisition.vi" from Help>>Find Examples>>Hardware Input and Output>>DAQmx>>Synchronization>>Multi-Device.  This offers a way to synchronize analog input on two X Series (PCIe) cards by sharing a reference clock and immediate start trigger from the master.  Alternatively, you can export the ai sample clock from the master as you have done and use the same trigger sharing mechanism as in the example.  For tighter synchronization, I would recommend using the latter method.  Good luck! 

Brian G.
0 Kudos
Message 4 of 10
(3,684 Views)

HI Brian,

 

Thanks for the feedback... I have tried doing what you suggested, but my selected timing source constants for the Dev3 and Dev4 are not compatiable and I am getting errors...I have tried a number of different combinations...? Not sure exactly what i am doing here?

 

Any chance you can take a look?

 

Regards,

Jack

 

 

0 Kudos
Message 5 of 10
(3,677 Views)

Hi Brian,

 

I did some more work on this... This works... Does this look ok?

 

Picture1.png

 

Regards,

Jack

0 Kudos
Message 6 of 10
(3,662 Views)

Hi Jack,

 

The method used in the first attached VI should work without issue.  It would be helpful to know what errors you were receiving while using this code.  In the second screenshot you posted, there are many redundant Tasks being created.  You should only need one DAQmx Create Channel VI for each card.  

 

I just remembered that since you are using X Series DAQ cards you can do channel expansion with your RTSI cable.  This allows you to combine the same type of Tasks from multiple cards into a single synchronized Task.  The below Knowledge Base article shows you how this can be done. 

 

Synchronizing DSA, S Series, and X Series Devices With a Single NI-DAQmx Task

 

 

Brian G.
0 Kudos
Message 7 of 10
(3,653 Views)

Hi Brian,

 

Thanks for getting back to me... I understand your point about redundancy... I made the expanded attachment for myself to help get my head around what I am doing... Without regard the redundancies, have I used the triggering correctly?

 

Also, I found this http://www.ni.com/white-paper/4322/en Figure 2 shows another example for synchronisation, but no trigger is used... Can you please explain the significance of the trigger?

 

Regards,

Jack

0 Kudos
Message 8 of 10
(3,644 Views)
Solution
Accepted by jcannon

Hi Jack,

 

Yes, the trigger routing you are doing is correct.  In fact, it corrects the problem with your first attached VI.  In that case the exported destination terminal (/Dev3/RTSI0) did not match the source terminal in the second task (/Dev4/RTSI0).  If you make these the same (i.e. /Dev4/RTSI0) you should get the desired result.

 

In regards to the synchronization examples you posted, without a start trigger the tasks will simply share a sample clock, but not a common starting point.  In most synchronization cases you will want to share both the sample clock and a common start trigger.

 

 

Brian G.
0 Kudos
Message 9 of 10
(3,640 Views)

Thank you Brian...

 

Very much appreciated...

 

Kind regards,

Jack

0 Kudos
Message 10 of 10
(3,637 Views)