Thread Subject: Synchronizing two or more xPCs?

Is it possible to synchronize the start of two or more xPCs loaded with models? Both of my xPC systems have a shared memory device (Scramnet). Therefore, they can share memory space and exchange data pretty much instantaneously. I need to have both xPCs start at the exact same time. Is it possible to have them block on a boolean in the shared memory, basically waiting to "go" and once that boolean is set to true externally, they should all start at the same time. I just don't know how to get them to align perfectly.

Any thoughts on this?

Thomas,

Even if you start them at exactly the same time, unless you
have them repeatedly synchronize, they will get out of sync.

The interrupting timer for each PC is based on it's own crystal
oscillator. There is a tolerance in the exact frequency and
two different crystals will always drift with respect to each
other. That means the execution times will drift.

One way to do it is to run both from the parallel port interrupt
and feed the same signal to both machines. You would need to
gate that signal on once both machines are started and waiting
for the interrupt. The signal source would be completely
independent of the target machines. You can't use either to
enable this source since neither runs until it's enabled.

Another possibility is to use a digital output on target 1 to
pulse it's output and have that connected to an interrupting
input on target 2. This has the disadvantage of leaving some
time offset from target 1 to target 2. The exact offset will
jitter by several microseconds because of cache stalls that won't
be the same in both.

I hope this gives you an idea on how you can do it.

Gordon Weast
xPC Target Development
The MathWorks

Thomas Marullo wrote:
> Any thoughts on this?

Thanks, Gordon. Some good info here. The timing on this doesn't have to be to the microsecond. I envision running one xPC with a base sample rate of 1kHz running a control model. The second one, or slave model, will run at 0.1kHz and feed data across the shared memory. And the process won't last longer than a few minutes, realistically. Therefore, microsecond drifts are acceptable.

The most important thing is that I can start them at the same time since the modeling is based on convergence algorithms and without proper data for at least one step of 0.1kHz will result in instability.

I typically use xpcexplr to start my target or just enter "start" at the xPC terminal. However, if I want to start two or at the same time, is there a better way to do this so they start without any significant phase offset with respect to each other? I define significant phase offset as anywhere more than 10% of the base sample rate.

Per your last paragraph, I suppose I could use an address on the shared memory as the interrupt. If I have the slave(s) start first, is there a way to have them "wait" or block on a variable until the control model triggers that variable and then run its process? I've never experimented with "blocking" or interrupting real-time models.

Gordon Weast <gweast@mathworks.com> wrote in message <hmhaau$5e9$1@fred.mathworks.com>...
> Thomas,
>
> Even if you start them at exactly the same time, unless you
> have them repeatedly synchronize, they will get out of sync.
>
> The interrupting timer for each PC is based on it's own crystal
> oscillator. There is a tolerance in the exact frequency and
> two different crystals will always drift with respect to each
> other. That means the execution times will drift.
>
> One way to do it is to run both from the parallel port interrupt
> and feed the same signal to both machines. You would need to
> gate that signal on once both machines are started and waiting
> for the interrupt. The signal source would be completely
> independent of the target machines. You can't use either to
> enable this source since neither runs until it's enabled.
>
> Another possibility is to use a digital output on target 1 to
> pulse it's output and have that connected to an interrupting
> input on target 2. This has the disadvantage of leaving some
> time offset from target 1 to target 2. The exact offset will
> jitter by several microseconds because of cache stalls that won't
> be the same in both.
>
> I hope this gives you an idea on how you can do it.
>
> Gordon Weast
> xPC Target Development
> The MathWorks
>
> Thomas Marullo wrote:
> > Any thoughts on this?

Gordon,
Any final thoughts on how "process blocking" works with an xPC model? Can models be held until an interrupt happens?

Thanks,
Thomas

"Thomas Marullo" <tmm3@lehigh.edu> wrote in message <hmhviv$ora$1@fred.mathworks.com>...
> Thanks, Gordon. Some good info here. The timing on this doesn't have to be to the microsecond. I envision running one xPC with a base sample rate of 1kHz running a control model. The second one, or slave model, will run at 0.1kHz and feed data across the shared memory. And the process won't last longer than a few minutes, realistically. Therefore, microsecond drifts are acceptable.
>
> The most important thing is that I can start them at the same time since the modeling is based on convergence algorithms and without proper data for at least one step of 0.1kHz will result in instability.
>
> I typically use xpcexplr to start my target or just enter "start" at the xPC terminal. However, if I want to start two or at the same time, is there a better way to do this so they start without any significant phase offset with respect to each other? I define significant phase offset as anywhere more than 10% of the base sample rate.
>
> Per your last paragraph, I suppose I could use an address on the shared memory as the interrupt. If I have the slave(s) start first, is there a way to have them "wait" or block on a variable until the control model triggers that variable and then run its process? I've never experimented with "blocking" or interrupting real-time models.
>
> Gordon Weast <gweast@mathworks.com> wrote in message <hmhaau$5e9$1@fred.mathworks.com>...
> > Thomas,
> >
> > Even if you start them at exactly the same time, unless you
> > have them repeatedly synchronize, they will get out of sync.
> >
> > The interrupting timer for each PC is based on it's own crystal
> > oscillator. There is a tolerance in the exact frequency and
> > two different crystals will always drift with respect to each
> > other. That means the execution times will drift.
> >
> > One way to do it is to run both from the parallel port interrupt
> > and feed the same signal to both machines. You would need to
> > gate that signal on once both machines are started and waiting
> > for the interrupt. The signal source would be completely
> > independent of the target machines. You can't use either to
> > enable this source since neither runs until it's enabled.
> >
> > Another possibility is to use a digital output on target 1 to
> > pulse it's output and have that connected to an interrupting
> > input on target 2. This has the disadvantage of leaving some
> > time offset from target 1 to target 2. The exact offset will
> > jitter by several microseconds because of cache stalls that won't
> > be the same in both.
> >
> > I hope this gives you an idea on how you can do it.
> >
> > Gordon Weast
> > xPC Target Development
> > The MathWorks
> >
> > Thomas Marullo wrote:
> > > Any thoughts on this?

Thomas,

You can run the model from an external interrupt instead of from
the timer. In the Configuration parameters dialog for the model,
go to the xPC Target Options page. In the Execution options section,
you can change the interrupt source (the IRQ) and you can specify
which board is generating the interrupt. The board has to be on the
list, or we don't have the interrupting driver for it. The parallel
port is a good choice if you just have a TTL level pulse.

I don't catch all xPC Target queries here, calling tech support
will usually work better.

Gordon Weast
xPC Target Development
The MathWorks

Thomas Marullo wrote:
> Gordon,
> Any final thoughts on how "process blocking" works with an xPC model?
> Can models be held until an interrupt happens?
>
> Thanks,
> Thomas
>
> "Thomas Marullo" <tmm3@lehigh.edu> wrote in message
> <hmhviv$ora$1@fred.mathworks.com>...
>> Thanks, Gordon. Some good info here. The timing on this doesn't have
>> to be to the microsecond. I envision running one xPC with a base
>> sample rate of 1kHz running a control model. The second one, or slave
>> model, will run at 0.1kHz and feed data across the shared memory. And
>> the process won't last longer than a few minutes, realistically.
>> Therefore, microsecond drifts are acceptable.
>> The most important thing is that I can start them at the same time
>> since the modeling is based on convergence algorithms and without
>> proper data for at least one step of 0.1kHz will result in instability.
>> I typically use xpcexplr to start my target or just enter "start" at
>> the xPC terminal. However, if I want to start two or at the same time,
>> is there a better way to do this so they start without any significant
>> phase offset with respect to each other? I define significant phase
>> offset as anywhere more than 10% of the base sample rate.
>>
>> Per your last paragraph, I suppose I could use an address on the
>> shared memory as the interrupt. If I have the slave(s) start first, is
>> there a way to have them "wait" or block on a variable until the
>> control model triggers that variable and then run its process? I've
>> never experimented with "blocking" or interrupting real-time models.
>>
>> Gordon Weast <gweast@mathworks.com> wrote in message
>> <hmhaau$5e9$1@fred.mathworks.com>...
>> > Thomas,
>> > > Even if you start them at exactly the same time, unless you
>> > have them repeatedly synchronize, they will get out of sync.
>> > > The interrupting timer for each PC is based on it's own crystal
>> > oscillator. There is a tolerance in the exact frequency and
>> > two different crystals will always drift with respect to each
>> > other. That means the execution times will drift.
>> > > One way to do it is to run both from the parallel port interrupt
>> > and feed the same signal to both machines. You would need to
>> > gate that signal on once both machines are started and waiting
>> > for the interrupt. The signal source would be completely
>> > independent of the target machines. You can't use either to
>> > enable this source since neither runs until it's enabled.
>> > > Another possibility is to use a digital output on target 1 to
>> > pulse it's output and have that connected to an interrupting
>> > input on target 2. This has the disadvantage of leaving some
>> > time offset from target 1 to target 2. The exact offset will
>> > jitter by several microseconds because of cache stalls that won't
>> > be the same in both.
>> > > I hope this gives you an idea on how you can do it.
>> > > Gordon Weast
>> > xPC Target Development
>> > The MathWorks
>> > > Thomas Marullo wrote:
>> > > Any thoughts on this?