Re: SYNC messages in CANopen verses Sync Flags in MilCAN

Hello John

As Bertil suggested you should be able to do just what you requested using
the
standard counter in the sync message.

 - Configure the sync period in 1006
 - Configure wraparound for sync counter in 1019 both on producer and
consumer
 - Configure how many syncs to receive before trigging in PDO comm param
subindex 02
 - Configure what counter value is considered the first in PDO comm param
subindex 06

That should let you space out the PDOs with the only limit that the counter
is only 8 bit,
but sending the temperature every 2,56s will probably not overload the bus
anyway :)

Regards,

Simon


Simon Byholm - Software Manager / Quality Manager

Phone: +358 6 357 6306
Fax: +358 6 357 6320
email: [email protected]
web: www.tke.fi

TK Engineering solves your CAN, CANopen, J1939 and NMEA2000 problems by
providing the hardware, software and know-how you need to design,
manufacture and troubleshoot your industrial 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 problems.

On Sun, Mar 18, 2018 at 5:50 PM, Bertil Bäck <[email protected]> wrote:

> 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 <+358%2050%205886895>
>
> 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 <+358%206%203576300> or email [email protected]
> to learn how we can help you solve your CAN related tasks.
>