Re: SYNC messages in CANopen verses Sync Flags in MilCAN

Hi,
I just read your mail briefly don't know if I get everything :)

I think there was a update to CiA 301 that introduces a counter value to
sync frames. There is also a feature for TPDOs to send them with
corresponding counter value.

https://www.can-cia.org/can-knowledge/canopen/special-function-protocols/

"By default, the SYNC message does not carry any data (DLC = 0).  Devices
that support CiA 301 Version 4.1 or higher may optionally offer a SYNC
message, which provides a 1 byte SYNC counter value. Therefore synchronous
behavior of several devices can be coordinated more comfortably."

It's only one byte, but it's something.

Br,
Bertil





On 16 March 2018 at 18:27, John Dammeyer <[email protected]> wrote:

> 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/
>
> Ph. 1 250 544 4950 <(250)%20544-4950>
>
>
>
>
>



-- 
Bertil Bäck
R&D Manager, Hardware
+358505886895

https://tke.fi/contact-us/

TK Engineering solves your CAN, CANopen, J1939 and NMEA2000 needs by
providing the hardware, software and know-how you need to design,
manufacture and troubleshoot your industrial- marine- and heavy machine CAN
networks. Call +358 6 357 6300 or email [email protected] to learn how we can
help you solve your CAN related tasks.