SYNC messages in CANopen verses Sync Flags in MilCAN

Hi Everyone,
 
Bear with me for a moment.
 
MilCAN has, as a fundamental feature, a sync frame that contains a Sync Flag
value that increments with each Sync Frame message wrapping around at 1023
to 0.  How often the sync messages are sent is somewhat application
dependent.  Most messages in MilCAN are synchronous which means they are
tied to a specific Sync Flag value.  And messages can be sent after more
than one Sync Flag Value.  Like every 16 flags for example.
 
So imagine you have a Sync Flag message every 10mS.  After 1024 we start
again.  So 10.24 seconds will have gone by when we wrap around.  If we want
a message every 160mS or so we'd send out on every 10th Sync Flag.  And if
you have 10 nodes out there, and each one was doing that with a 10 message
offset we'd see a sync flag and a data message every 10 mS.  The nice thing
about that is the bus is evenly loaded with never more than two messages
back to back.
 
Now MilCAN also has asynchronous messages.  They can happen any time after a
Sync Flag.  By waiting for the Sync Flag message and because they have
higher priority than synchronous messages they are guaranteed to not shift
the timing of the sync flag and they also are there before the synchronous
messages.  Careful message planning never puts more than X messages between
Sync Frames so that the Sync Frames aren't offset in time.
 
Unfortunately CANopen doesn't really have something like that.  It does have
a SYNC message.  On receipt of a SYNC messages all nodes interested in that
will grabinternal  hardware inpu signal levels.  This way they are looking
at data across the network at exactly the same time.  They also transfer any
data they have received into hardware outputs so all motors or relays will
all turn on (if requested) at that same instant that they receive the SYNC
message.
 
There isn't any data with a SYNC message in CANopen.  I'm wondering if
modules that conform to CANopen (have been verified) will care if there's a
16 bit value in the first two bytes of a SYNC message. (0x80)
 
My idea is that I would implement something like the MilCAN approach with an
incrementing Sync Flag value in the CANopen SYNC message.  This would each
custom module to have a table of Sync Flag values and Messages for periodic
broadcasting.   
 
Where normally five modules might have 4 TPDO messages that need to be sent
once every second for a total of 20 messages that could end up as a burst of
20.  The modules could also be receiving RPDOs from the master or other
nodes that produce another 20 RPDO messages.  It's entirely possible that
there could be, over time, a gradual migration of timing to bursts of 40 PDO
messages back to back.  That could overwhelm some nodes that are required to
receive all messages and not be able to use hardware filtering.
 
With careful planning I can set up all the messages so we never have more
than 2 or 3 back to back.  With the right clock values the SYNC message
could be sent once approximately every 10 mS  (0.009765625).  In my system a
hardware message update time of 0.5 or 1.0 seconds has been more than
adequate but that's sometimes all 4 PDOs every 0.5 seconds and if multiple
nodes do it I've seen bursts of 20 messages.
 
The alternative is to assign the TPDOs relative to the SYNC frame Sync Flag
value. If each one occurs every 0.009765625 then we could assign an offset
of  0 .. 7 and mask the sync flag value with 0x007.  If the masked sync
value matches send TPDOn where n is the mask of the Sync Flag value shifted
right 3 bits  masked masked with 0x003 + 1
 
For example: each node will receive the sync flag value 0x135.  Masked with
0x007 we get 5.  ((0x135 >> 3) & 0x003) = 2.  So if this node is marked for
offset 5 it will then generate TPDO3  (n+1) on receipt over every SYNC that
that matches.  
 
There's still lots of time between SYNC messages for asynchronous messages.
And the bus load is no longer in bursts.  Some nodes may only need to supply
a value like Temperature and RH once every 10 seconds.  They could be
programmed to look for Sync Flag value decimal 777 (0x309)for example.  
 
I don't see anything in the CANopen specification that would prevent this
other than the 2 data bytes in the SYNC message.  And clearly any COTS
module that doesn't support this will still asynchronously transmit it's
PDOs.  But if the majority of nodes are running a custom CANopen protocol
then it does avoid long bursts of messages.
 
Thoughts?  Ideas? Comments?
 
Thanks
John Dammeyer
 
 
 
"ELS! Nothing else works as well for your Lathe"
Automation Artisans Inc.
 <http://www.autoartisans.com/ELS/> http://www.autoartisans.com/ELS/
Ph. 1 250 544 4950