Hi Frank, > -----Original Message----- > From: Frank Tkalcevic [mailto:fr...@franksworkshop.com.au] > Sent: August-18-20 3:58 PM > To: 'Enhanced Machine Controller (EMC)' > Subject: [Emc-users] OT: Synchronised motion using RS485/CAN bus motors > > An off topic question, not directly LinuxCNC related... > > How are motors on a serial bus controlled and synchronised? > > My only real control experience is with LinuxCNC with Mesa and parallel port > hardware where commands and feedback and precisely > timed. Sending commands and receiving feedback over a serial link I would > expect to cause synchronising problems, and the > bandwidth would reduce the update rate. > > How are these issues handled? I tried googling this, but didn't find much - > I wasn't sure what to search for.
You subject line says RS485/CAN which are dramatically different from the SPI based synchronous clocked serial interfaces. Even RS485 and CAN are dramatically different. First let's describe the 3 protocols. RS485 is based on a UART and refers to the differential bus signal levels which can be logic high, logic low or high impedance. The drivers allow multi-master communications as long as nodes don't try and send at the same time. UARTs use a bit rate called baud which includes 2 or 3 extra bits called start and stop to allow devices to detect the beginning of a message. So each 8 bit byte actually takes at least 10 bits of signal time or 11 bits (less common) if 2 stop bits are used. Aside from 110 baud the rates are generally multiplied by 2 each time. So 300, 600, 1200, 2400, 4800, 9600 etc. At 9600 there are 960 bytes per second with each byte using 10 bits. CAN bus is a true CSMA/CR system. Collision Sense, Multiple Access with Collision Recovery. Not a true differential signal since the recessive or no signal has both wires at 2.5V relative to ground. Ie. It's a 3 wire system that requires a ground... somewhere... The messages consist of an ID part, length part, 8 bytes of data part and a CRC part plus a few extra bits. The advantage of CAN bus is that it can arbitrate when two messages start at exactly the same time. The message with the lowest value ID part wins and keeps sending while the other node(s) change over to listen mode. A message is considered successfully sent when the sender part of the message called an ACK slot is filled with an ACK bit by any node that correctly received the message. The bit rates for FULL CAN will run up to 1Mbps but of that 64 bits data and 11 or 29 bits of ID the overhead is almost double with an average of 135 bits if there are 8 bytes. Note CAN rates are bits per second. Not baud. Finally SPI is a synchronous master controlled system. The master asserts a chip select and then provides a bit on the MOSI line during a clock bit while reading the MISO signal at almost the same time. So it can be bidirectional. Some SPI can go up to 40MHz but generally runs up to 10MHz. That means if the master was sending 1000 bytes of 8 bits each, the time to do this is 80 uSec. So a controller could provide a number of blocks of step pulses with a system step rate of 1MHz and have plenty of time to also read back all the inputs at the same time. For example: Send out 32 bits representing outputs while reading in 32 bits representing inputs. Do this at 10Mbs the time taken is 6.4uS. And again, not baud. Bits per second. I think Peter Wallace might be able to provide a simple explanation of how and what the system sends to maintain high step rates. John Dammeyer > > Thanks, > Frank > > > > > > > _______________________________________________ > 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
