No it's not but that's because MilCAN breaks a very fundamental rule of the CAN 
bus protocol.  A bit of background.

CSMA/CD used in the original coax based Ethernet stands for Carrier Sense, 
Multiple Access with Collision Detection.  Each node would listen on the bus 
and if free would start to transmit.  If another node also started to transmit 
at exactly the same time they would both back off for a random time and retry.  
This worked well up to about 50% bus utilization and then resulted in a 
saturated bus with very little data getting through.  

CAN bus also does carrier sense but starts off sending with an ID portion that 
is either 11 bits or 29 bits.  The rule for CAN is no device may transmit the 
same ID and the lower the ID in value the higher the priority.  So if two nodes 
start transmitting at exactly the same time the moment one of the ID bits 
transmitted is a 1 but is read back as a 0 that node backs off and switches 
into receive mode. Once the message is finished it tries again.  That's called  
Collision Recovery hence the CSMA/CR.  I'll see if I find a scope grab of that 
and post it.

The CAN bus protocol also detects errors in the bit pattern and any node that 
detects and error can destroy the message forcing the sender to retry.   It's 
done with bit stuffing and a sequence of bits longer than the stuff interval 
(called an Error Flag).

Anyway.  Back to MilCAN which doesn't allow retransmission of a message when 
it's been flagged as bad.  Not all CAN hardware even supports that.   And the 
system master that sends this SYNC FLAG includes a counter from 0 to 1023 that 
is incremented with each message wrapping around to 0 after the one that has 

There are both synchronous and asynchronous messages in MilCAN.  The 
Synchronous ones are programmed to be sent during a specific SYNC FLAG value or 
multiple of.  So say every 16 or 8 or 32 along with an offset.  So one message 
might be sent every 16 SYNC FLAGs offset by 3. So on 3, 19, 35, ...
Another might also be every 16 but offset by 5.  So 5, 21, 37,...  The system 
architect designs and allocates the messages in such a way that the messages 
never really arbitrate so they never need to retry and if they are corrupted 
they wait until the next SYNC FLAG.

What you have then is each device receiving a SYNC FLAG and if it matches it 
immediately sends what's it's programmed to send.  The system architect must 
not pack in too many messages in one SYNC FLAG interval.  That's because you 
also need to deal with ASYNC messages like alarms.  But even those are throttle 
by the SYNC FLAGS.  They are only allowed onto the bus after a SYNC flag is 
received.  That prevents the SYNC FLAG message from ever being arbitrated or 
held off because another message has control of the bus.  The CS part of the 
Carrier Sense isn't really required for the SYNC MASTER.

And that's why the ERROR flags and retries aren't allowed.  Under this protocol 
it would be illegal for a message to show up at the end of the SYNC FLAG period 
and overlap into the next.  Either by being sent or being retried.  On one 
project I was require to delay the synchronous messages after a SYNC FLAG by 
about 1/3 of the SYNC Period.  That was to allow no arbitration for the ASYNC 
messages that might show up at the beginning of the interval.   Not only that, 
I had to track where I was within the SYNC FLAG frame and if asynchronous  
messages had shifted my starting point for my synchronous message I wasn't 
allowed to transmit any that might overlap the time point where the next SYNC 
FLAG would be sent.  

So CANopen is way different.  Far more jitter.  If you figure that the average 
8 byte CAN message is really closer to 135 bits with bit stuffing and CRC each 
message at 1Mbps is 135 uS.   That's only 7.4khz.   Even if you used less data 
and managed to keep the bit stuffed messages under 64 bits that's still 64 
microseconds and 15.6kHz.  Not fast enough for step/direction messages.

John Dammeyer

> -----Original Message-----
> From: Nicklas Karlsson []
> Sent: March-09-19 8:37 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] CANopen: SOEM/SOES, CANfestival, anything
> more?
> > ...
> > For more hard real time applications the MilCAN protocol is more ideal
> because all the messages are synchronized to SYNC FLAG messages and the
> arbitration is limited to within a SYNC FLAG period avoiding jitter on
> messages.  But there's pretty well nothing available commercially for
> MilCAN unfortunately.
> CANopen have a SYNC message, this is not as good as SYNC FLAG?
> >
> > Where CAN bus systems really excel in automation is for things like tool
> changers and part loaders/unloaders, control of coolant and other devices
> etc.
> Sound reasonable. I plan to use it over Ethercat, its just to get some kind of
> standarized message for configuration or whenever there is a need to
> communicate with the device.
> > Still one of the best books on CANopen is this one.  Looks like it's back in
> print too.  I've used it to create a master CANopen Stack.
> >
> Nice picture, I will try to look at it.
> Regards Nicklas Karlsson
> _______________________________________________
> Emc-users mailing list

Emc-users mailing list

Reply via email to