RE: SYNC messages in CANopen verses Sync Flags in MilCAN

Please remove us from this.

Thanks
HR

From: [email protected] <[email protected]> On Behalf Of John Dammeyer
Sent: Sunday, March 18, 2018 3:10 PM
To: [email protected]
Subject: RE: [CANLIST] SYNC messages in CANopen verses Sync Flags in MilCAN

Hi Uwe,
I was afraid of that.  We use some products that have passed conformance testing (AFAIK).  So mucking with the SYNC message may well cause problems with them.

I'm probably better off assigning a PDO to hold a MilCAN style sync flag.  My modules can use the receipt of that to trigger a PDO based on the value.  It won't prevent COTS CANopen certified devices from transmitting a periodic PDO or a PDO on change (like an inclinometer) But if I can prevent a run of 24 back to back CAN messages once every 500mS I'm creating a more stable deterministic system.

Really too bad the SYNC message doesn’t have the capability. I've done some MilCAN projects that work well with that approach.

John


From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Koppe (MC)
Sent: March-18-18 11:52 AM
To: [email protected]<mailto:[email protected]>
Cc: canlist; John Dammeyer
Subject: Re: [CANLIST] SYNC messages in CANopen verses Sync Flags in MilCAN

Hello John,

There isn't any data with a SYNC message in CANopen.


Since version 4.1 of the CANopen specification 301 there is an optional SYNC counter. The object 1019h allows
Access to the „Synchronous counter overflow value“. Here is a verbatim copy of the object description:

This object shall indicate the configured highest value the synchronous counter supports. This object shall be implemented by the producer and the consumer, if the synchronous counter is supported by the CANopen device. If the value is greater than 1, the SYNC message shall have a data length of 1 byte. The SYNC consumer shall ignore the value itself. An EMCY message (error code: 8240h – unexpected SYNC data length) may be transmitted by a SYNC consumer in the case the configured data length of the SYNC message does not meet the data length of a received SYNC message.

Hence, if a CANopen device has passed the conformance test and supports object 1019h it will check for the DLC and you have a problem.

And in addition: I do not enjoy a "custom CANopen protocol“ at all. Either it is CANopen, or
it is a custom protocol. I found already enough products on the market that have a hidden warning
label: „Attention - this product may contain CANopen“.



Greetings,
Uwe


---------------------------------------------------------------------
MicroControl GmbH & Co. KG
Junkersring 23, 53844 Troisdorf, Germany

Homepage: www.microcontrol.net<http://www.microcontrol.net>
Facebook: www.facebook.com/MicroControl.net<http://www.facebook.com/MicroControl.net>
Twitter : http://twitter.com/_microcontrol_
---------------------------------------------------------------------


________________________________
Total Control Panel

Login<https://asp.reflexion.net/login?domain=gpsnational.com>


To: [email protected]<https://asp.reflexion.net/address-properties?aID=1779559626&domain=gpsnational.com>

From: [email protected]<mailto:[email protected]>


Message Score: 50

High (60): Pass

My Spam Blocking Level: Medium

Medium (75): Pass


Low (90): Pass

Block<https://asp.reflexion.net/FooterAction?ver=3&bl-sender-address=1&hID=26708708605&domain=gpsnational.com> this sender

Block<https://asp.reflexion.net/FooterAction?ver=3&bl-sender-domain=1&hID=26708708605&domain=gpsnational.com> vector.com



This message was delivered because the content filter score did not exceed your filter level.