The DAQmx and XNET modules within one chassis should already share a timebase, which is in turn synchronized to the timebases of other TSN devices on the network. The only thing you'll need to do is trigger the XNET session appropriately. A good place to start is the "Synchronize C Series CAN with DAQmx Analog Input" shipping example (Help > Find Examples > Hardware Input and Output > CAN > NI-XNET > Synchronization). From there you can make a couple modifications to include an absolute time start trigger. Here's how I modified the example:
This snippet is an example of just one cDAQ chassis with an AI and XNET module. However, you can expand the concept out to as many cDAQ chassis as necessary. Just create an additional DAQmx task and XNET session for your second chassis. As long as they both use the same absolute time start trigger, they'll be synchronized.
An important thing to note is that the trigger routed between the DAQmx task and XNET session is a digital signal on the chassis backplane and is not sent over the network. This means that a DAQmx task must exist on each chassis that you are using an XNET module in. Otherwise, the XNET session cannot be triggered.
In regards to synchronization. What reference clock source should I be using to ensure all tasks are synchronized to the same TSN timebase?
DAQmx Timing Property Node -> More -> Reference Clock -> Source
EDIT: I may have had the wrong node. Would the correct one be DAQmx Timing Property Node -> Sample Clock -> Timebase -> Source
This white paper provides a pretty good explanation:
"The cDAQ-9185 and cDAQ-9189 offer three distinct clocks (10 MHz, 12.8 MHz, and 13.1 MHz) to Delta Sigma and Reference Clocked Modules. When using Delta Sigma or Reference Clocked Modules in these chassis DAQmx will default to using the chassis clocks to acquire or generate signals instead of the clocks onboard the modules.
When the time-aware chassis share the same grand master, all clocks onboard the chassis are synchronized to this grand master. Thus, clocks across multiple chassis are synchronized to each other. This process is done automatically and without user input. Since each module in the chassis will default to using the chassis backplane clocks for generation or acquisition, clocks used by each module (master timebase, sample clock, and/or reference clock) will all be synchronized. To synchronize the module acquisitions or generations between chassis, ensure that the Start Trigger is sent at the same moment."
Ultimately, this means that all the clocks on the chassis are synchronized to the grandmaster. You won't have to manually select the sample clock timebase in order to synchronize, the default timebase source for any given module should work fine. The only thing you'll need to do is share a start trigger.
Is there any way to manually set the Grandmaster clock? I am running into a situation where I am getting "sync lock lost" when starting a secondary task.
Example: I start Test Bay A running DAQmx Task A. A little bit later I go to start Task B and it causes task a to lose sync lock.
After reading an article (see link below), I believe this is due to a different grandmaster being selected when I start Task B, which causes task A to lose sync. Am I right?
One thing to keep in mind keep in mind is that each Ethernet port on the IC is the master for the chain(bay) of cDAQs connected to it. In another words, the industrial controller(4 ethernet ports) acts like a device with four 802.1AS masters or slaves, but in your case always as a master. The only advantage here is that these for "four masters" are running on the same system so they utilize the same internal clock.
Ideally, if you looking to do something very specific with synchronization the best approach is to keep all the cDAQs on the same chain, hence a single GM.
I do NOT need side A and side B to be synchronized or dependent on one another at all. This is because when side A is running a test, side B should be able to have chassis added to its network, performing software calibration on channels, etc. I do not want this behavior on B to impact side A, so I want to keep them as separate as possible.
All that aside, I am still experiencing a sync lock lost error. What could be causing this error to occur, when side A and side B should be completely independent of one another. I guess in general what occurrences in an application can potentially cause a sync lock lost error?
Do you just lose sync lock whenever you add and remove chassis, or do you also lose sync lock when you start a new task without making any hardware changes?
I have been using the VI you have attached here for various testing with the system I am designing. Though, I have hit a snag. The start terminal that is created and sent to the XNet Session is not a te0\StartTrigger, it is an ai\StartTrigger. What is the significance of this? I am attaching a vi and screen shots of execution for a test I ran. The attached vi is a simple example of creating 4 tasks. The fist two tasks being created are associated with modules in chassis 1, and the second two tasks are associated with modules in chassis 2. Now I returned the start terminals that are read for each of the tasks to an array indicator for reference and you can see the readout in the screenshot. The peculiar thing is the first task on chassis 1 returns an ai|\StartTrigger and the second returns a te0\StartTrigger and similarly on the tasks for chassis 2. Any light you can shed on this phenomenon would be appreciated. Thanks.
If you want to talk over the phone at any point, just post an email address and I will send my contact info to you.
The questions dig more deeply into the DAQmx API than the folks that monitor this forum normally cover. (This forum is focused on the networking aspects for communications and synchronization). For application level questions I think you may be best served to open a service request. You can open one on-line if you prefer: