Running the two machines at the same sample time and starting at the same time does not have sufficient synchronization for many applications. The synchronization drift depends on the exact frequency of the crystal in each machine. No two crystals will have the exact same frequency, so some drift is inevitable and on a limitation which exists in the hardware timer. This limitation is discussed in more detail at the end of this note.
For longer runs where drift matters, using an interrupt to force exact synchronization is necessary. This is the recommended way to synchronize multiple targets (by using interrupts and a master/slave concept):
One target is declared as the master. This model (target application) is driven by the default timer interrupt source or possibly an A/D conversion pacing the model. On the master target, I/O is used to notify the slaves that a model step or something else has happened in the master model. This could be accomplished via a digital output line, a CAN message, or a shared memory write access.
All other targets are slaves. The entire model is therefore not paced on the default timer interrupt, but on a specific interrupt coming from the I/O board, which receives the event from the master. To change the timer source of the model, go to RTW Options and select "xPC Target code generation options" in the Category popup. Then, select the appropriate interrupt line and the I/O board causing it.
For example, you could use a single digital I/O line. On the slave system, use the digital I/O board and select the settings described above accordingly. On the master, use a digital I/O board that you may already use for other purposes. Link the two digital lines together. In the master model, use a DO write block being executed as the first block in the model. If the master model gets to a sample hit, it will trigger the slave model execution based on the DO write block.
If the slave needs to run at a slower sample rate than the master, it will need one block that executes at the fastest rate (say, 1 ms) and then other blocks that run at multiples of 1 ms. For instance, with interrupts coming in at 1 ms and the desire to run the model at 5 ms, most of the blocks should set their sample time to 5 ms. At least one block needs to be set to 1 ms; this could be something as simple as a constant block feeding a 1/z unit delay, which then feeds a terminator. Set the unit delay to a sample time of 1 ms. Now, the 5 ms blocks will run every 5 interrupts.
Here is some additional information on a limitation of timing in xPC. Part of the difficulty in achieving synchronous operation is that the sampletime set in xPC Target cannot be exact.
The timer that is used to give interrupts is based on a legacy frequency source. The frequency of this is approximately 1.193e6 Hz. This odd value originates from the design of the first IBM PC in the early 1980's. The designers wanted to use 1 crystal to get all timing, including a source for graphics output. The early monitors used NTSC timing, which depends on the color subcarrier frequency of 3.579545 Mhz. If you refer to this as C, then C/3 = 1.193 Mhz. Also, the CPU frequency is C*4/3 = 4.77 Mhz in the original PC. The 1.193 Mhz counter is the only interrupting source available from a timer in a compatible PC.
In order to work with this odd frequency, xPC counts 1193 counts between interrupts for a sampletime of 1 millisecond. The error if C is exact is about 2/11932.
For a sampletime of 100 microseconds, xPC counts 119 ticks between interrupts and the error is 3/1193. The error depends on the sampletime that is chosen.
Operating systems such as Windows use this timer for the real time clock, but can occasionally tolerate having different clock intervals. Sometimes, they add or subtract an extra tick to make up for drift. xPC Target keeps the interval exactly the same and does not try to hit an average sampletime by periodically adjusting the count. Such adjustments would impact many simulations very badly.
