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 1023. 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 http://www.autoartisans.com > -----Original Message----- > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com] > 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. > > https://www.canopenbook.com/ > > Nice picture, I will try to look at it. > > > Regards Nicklas Karlsson > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
