Chris, thanks a bunch. In your implementation, did you account for the processors going off line, or id your only update the XSIGs on boot. Just wondering...cause maybe in reality that will cover me for 99% of the situations where the the XSIGS could ever get out of sync.
Great idea though on building my own heartbeat. I'll have to give it a shot.
J
toggle quoted message
Show quoted text
--- In Crestron@..., Chris Niles <chris.niles.crestron@...> wrote:
I did that - I sent the signal to the opposite processor, jammed with
the Xsig_tx$. I used an SIO on startup.
You could implement some sort of heartbeat. OSC tied to an RING tied to
an INIT, sent over the XSIG. On the opposite side, run it through a
Analog One Shot and a Retriggerable One Shot. If the RTOS ever goes low,
the other processor has stopped responding.
Chris
On 2/21/2011 1:34 PM, yellowfin684 wrote:
I have two processors where I am using the XSIG symbols to communicate
between the two. The problem of course with the older XSIG symbol is
that they don't force the signals to stay in sync if one processor
reboots or drops off line. From reading the help doc on the XSIG
symbol, it looks like you can update or clear the values of the XSIG
using \xFD or \xFC respectively. I have been tinker with updating the
signals, but with no luck.
Would anyone have an example program on how to do this properly and
efficiently?
Also, I understand I could issue the update command on system start of
either of the processors, but what about if one of the processors
simply goes off line. Is there a socket signal I can monitor to track
the online status of a processor? I've looked but I must be looking in
the wrong place.
Lastly, is there any reason to use the clear command to clear all the
signals when trying to keep these in sync? Wouldn't I just want to
issue update commands.
Thanks a bunch
[Non-text portions of this message have been removed]
