Motion Control Bus is a high speed serial protocol designed for getting low latency and high determinism in motion control systems where control loops works at high update rates (tens of kHz) . It takes elements from different known and reliable industrial protocols such as EtherCAT and CANopen.
This protocol takes into account the next limiter elements for reaching low latency and high determinism:
- Physical layer. Max achievable baud-rate, synchronisation elements, etc.
- Frame process time. Sometimes the limitation is produced by a complex frame parsing.
- MCU peripherals capabilities. Selected MCU/MPU requires to implements a minimum set of peripheral functionalities.
So some of the keypoints are:
- Fixed frame size. DMA or enhanced buffers can be used efficiently and execution time is more constant.
- Use full duplex feature every time is possible
- Frame fields are as simple as possible.
- Very small header. Determinism and low latency is reached by using small messages. Then data efficiency is kept high using a header as smaller as possible.
- Reliability. Reached by using common CRC checksum and other synchronisation strategies from the physical layers.
- It is based on master - slaves topology
MCB frame is composed by 4 fields:
|Header||Config data||Cyclic data (optional)||CRC|
|4 bits||12 bits||3 bits||1 bit||4 word||0 - 32 word||1 word|
Node ID. It is used to identify the destination device in multi-axis solutions. This addressing might be included inside the frame or using additional signals such as chip selects in case of SPI communications.
Node ID is not included in the below descriptions because is not always included into the communication frame.
- Header. It includes the master and slave commands
- Config data. Contains data from configuration access. If data is higher than 4 words, fragmentation is applied (see below).
- Cyclic data. Contains data from cyclic access. This field is by default disabled.
- CRC. CRC-CCITT (XModem) polynomial is used.
Configuration access is the name used to identify acyclic / asynchronous requests from master to slave. This access type doesn't use the cyclic data field.
|1 word||4 word||1 word|
Address field from header is used to indicate the register to be accessed of the servo drive dictionary. As mentioned into the dictionary documentation, the maximum supported register are 2048 (11 bits) so the first bit of the field is reserved for future use and must be kept to 0.
The protocol is based on master-slave communication and all the commands sent by a master are confirmed by the slave, indicating the result of the operation. So every configuration is composed by two frames: Request from master to slave, and reply from slave to master. The available commands are:
Read Access 0b001. It is used to get a value from a drive register. Slave must reply with an ACK or Error on read (see below)
Simple read example
Read access to register 0x10
Header Config data CRC Address Command Pending frame 0x010 0b001 0 0 0xA922 0x01020000000000000000A922
Write Access 0b010. It is used to set a value of a drive register. Slave must reply with an ACK or Error on write (see below)
Simple write example
Write access to register 0x10
Header Config data CRC Address Command Pending frame 0x010 0b010 0 0x0006000000000000 0x528F 0x01040006000000000000528F
Get info command 0b000. It is used to obtain all the information of a register available on the MCB slave. Slave will reply with an ACK or Error . Data field from slave is coded in the next way:
LSB (bits) 0..7 8..13 14..15 16..18 18..63 MSB (bits) Size Data type Cyclic type Access type Reserved Number of bytes INT16 → 0 Config → 0 READ → 3 UINT16 → 1 INT32 → 2 Cyclic Tx (drive to master) → 1 WRITE → 5 UINT32 → 3 FLOAT → 4 Cyclic Rx (master to drive) → 2 READ/WRITE → 7 STRING → 5
Get info example
Getting information of register 0x011
Header Config data CRC Address Command Pending frame 0x011 0b000 0 0x0000000000000000 0x7FB5 0x011000000000000000007FB5
Header Config data CRC Address Command Pending frame 0x011 0b011 0 0x4102000300000000 0x28C1 0x0116410200030000000028C1
Idle command 0b111. It is used every time the master needs to send a frame without any configuration access.
MCB over SPI uses this command to generate a dummy master frame to be able to read the slave request. See MCB over SPI
When cyclic communication is enabled, if the master doesn't need to generate a configuration access the header must use this idle command to indicate to the slave that only cyclic data has to be processed. See cyclic communication part for further details.
ACK access 0b011. Indicates that the request has been processed correctly
Simple read example
Successful reply to read access on register 0x10
Header Config data CRC Address Command Pending frame 0x010 0b011 0 0x0006000000000000 0x94E8 0x0106000600000000000094E8
Error on read 0b101. Indicates that the read request has not been executed correctly. Config data includes an error code to indicate the reason.
Simple error on read
Error reply to read access on register 0x10
Header Config data CRC Address Command Pending frame 0x010 0b101 0 0x0607001000000000 0x304C 0x01090607001000000000304C
Error on write 0b110. Indicates that the read request has not been executed correctly. Config data includes an error code to indicate the reason.
Simple error on write
Error reply to write access on register 0x10
Header Config data CRC Address Command Pending frame 0x010 0b110 0 0x0607001000000000 0x4780 0x010C06070010000000004780
- Idle command 0b111. It is used to indicate that slave reply is still being processed. It is used if configuration access is done when cyclic mode is enabled. See configuration access over cyclic section.
Error access codes
The possible error codes when a wrong access is detected are:
|Error brief||Error code||Example description|
|Unsupported access||0x06010000||Try to write a read only register|
|Register doesn't exist||0x06020000||Register address doesn't exist into dictionary|
|General error||0x08000000||Undefined error has been detected|
|CRC error||0x08010040||A CRC error has been detected|
|Invalid command||0x08010030||Unknown command for the slave|
Data field contains the data from a read or write request. It is sent word by word (independent of the used physical layer) and in LSW (least significant word first). Whenever it is possible, the words are sent in MSB (Most significant bit first).
Data 1311768467463790320 (0x123456789ABCDEF0) is sent in this order through data field:
0xDEF0 9ABC 5678 1234
The MCU / MPU used to develop this protocol are little endian and have peripherals able to work directly in words. Then swaps and extra framing process are avoided, getting an optimised communication.
Fragmentation or data extension
If data field is higher than 4 words (for example for ID registers that contains strings) the message might be fragmented of extended in function of the physical layer used. For high speed and low latency communication interfaces such as SPI where the time between transfers is low and the header is minimal, fragmented solution is considered. For low speed or interfaces where by default their headers are bigger than a MCB frame (such as Ethernet) extended solution is applied.
Both solutions uses pending frame to indicate that a special frame is transfered.
A configuration frame is divided into the needed number of configuration frames. All the frames, except the last one, enable the pending frame bit indicating to the remote device that there is more frames to be read.
The string 0.1.2.3.18.104.22.168 (0x 30 2E 31 2E 32 2E 33 2E 34 2E 35 2E 36 2E 37) is sent by the slave using two frames:
A extended configuration frame is generated indicated by the pending frame bit. When this bit is enabled, first word of the config data contains the extended data number of bytes.
Reading the 0x0B2 register (Monitor Data), reply from slave:
|Header||Config data||CRC||Extended data|
|0x0B2||0x3||0x1||0x00000000000000C8||0x36A7||200 B of data|
The complete command: 0x0001 0FB2 00C8 0000 0000 0000 36A7 ...
By default the slave will try to send 512 bytes of extended data, but this behavior is configurable through request frame, writing the amount of bytes to receive as extended part in the config data:
Master request to read 854 bytes of extended data:
The complete command: 0x0001 0FB2 0356 0000 0000 0000 2714
Cyclic access is the name used to identify cyclic / synchronous requests from master to slave. This access type use the whole frame.
|Header||Config data||Cyclic data||CRC|
|1 word||4 Word||0 - 32 word||1 word|
Enabling cyclic access
Even in cyclic access mode, the size of the frame remains fixed. Cyclic mode is enabled by sending a command to a reserved dictionary register, then the drive checks the size of the new cyclic frame by checking the mapped registers and finally modifies the expected frame size.
The reserved register is located at the address 0x640 and there are two possible values:
Register at address 0x641 determines the cyclic mode with the following possible values:
What does it mean dictonary register?
This procotol is optimized to work with the dictionary implemented for summit drives. Cyclic access requires additional configuration from the user and the method to set it up is through a reserved registers from the mentioned dictionary.
What does it mean mapped registers?
The key of the cyclic access is that the drive doesn't need to process the header of the frame. A previous configuration of the cyclic data is done during the cyclic mode activation. A set of reserved dictionary registers are used to indicate to the network which register values are expected to be into the cyclic data field.
Difference between config and cyclic
Register 0x010 - Control word is going to be accessed:
Master will send the command 0x01040006000000000000528F (see Master commands examples) . The slave will need to check the header, identify the address and the command, then look for the address into its internal dictionary, access to the internal variable and finally reply to the master request.
Network is already configured and register 0x010 is mapped into the cyclic data. Then the master sends the next command 0x000E0000000000000000000633BC. This frame has a void config frame. The slave just need to take the word from the cyclic data 0x0006 and copy it into the internal variable because it already knows that belongs to the register 0x010.
Why config frame is still sent in cyclic mode?
Config access is needed to enable and disable the cyclic mode. Furthermore, other configuration registers might be modified during cyclic operation.
It looks like that removing the config access part will do the communication more efficient. However there are some important drawbacks:
- The protocol is losing the capability of modify a non-cyclic register during cyclic operation
- If config and cyclic modes frames coexists as different frames (with different sizes), the devices cannot use their "HW accelerators" such as DMAs or enhanced buffers because it cannot expect the size of the next frame.
- Unifying the frame makes the communication more deterministic as the transmission time is constant during cyclic operation.
To map dictionary registers into a cyclic frame:
Disable cyclic access if enabled
Set register 0x640 (communication state)
Config access Cyclic access 1 2
Set it to 1 to disable cyclic access.
Write dictionary key and its size into the desired cyclic mapping register.
Rx mapping registers (from master to slave) start at key 0x651 and finish at key 0x658
Tx mapping registers (from slave to master) start at key 0x661 and finish at key 0x668
The value to be written should be 32 bits and should have the following structure:
MSWord LSWord Register Size (in bytes) Register Key
To map key 0x38 that occupies 2 words, the mapping value should be 0x00040038.
When mapping the drive will check if the key exists and if the size matched with the provided one. If not, an error will be returned and the object will not be mapped.
- Write number of entries of mapped registers to let the drive know how many registers should be processed.
Rx mapped registers: 0x650
Tx mapped registers: 0x660
Enable cyclic access by setting key 0x640 to 2.
A validation of the current mapping configuration will be performed. If it is considered valid, the communications will allow cyclic access messages. Otherwise an error will be returned and the drive will remain in configuration access mode.
The drive will reply the 0x640 write request using the config access frame. Once is replied, size of the frame will change to the cyclic one. This is critical in interfaces such as SPI where the reply is sent using a idle frame from the master.
Master must wait to the drive reply before changing to cyclic access mode to verify that the new mode has been reached correctly.
Configuration over cyclic access
Some considerations has to be taken into account if configuration access is executed during cyclic mode:
- Header and config data field works exactly like the description above
- Cyclic mode is used to send data cyclically to allow to an external master implement high level control loops / complex profiles. Therefore cyclic access is faster than configuration access, so the drive will reply to cyclic frame as fast as possible. Then if master sends a configuration request when cyclic mode is active, the slave reply might contain an empty configuration frame because it needs more time to process it. Next diagram shows the workflow in case the configuration request cannot be replied in the next cyclic frame:
- If there isn't a configuration frame to be sent, the master must sent idle commands to indicate to the slave that there is nothing to process.
Cyclic error codes
During mapping or enabling the cyclic mode, the next errors indicates a wrong use:
|Error brief||Error code||Example description|
|Incorrect mapping||0x06040041||Register is not cyclic mappable|
|Too much mapped registers||0x06040042||Mapped registers don't fit into Cyclic frame|
|Invalid cyclic index||0x08010000||A gap has been detected in the mapped register list|
|Cyclic state is not reachable||0x08010010||Cyclic state is not reachable for an unkown reason|
|Configuration is not allowed||0x08010020||Something in the mapping is wrong and cyclic mode is not reachable|
Motion control bus is designed to work with the most common interfaces: UART, SPI, USB, Ethernet, etc. However, in order to get the maximum capabilities of each interfaces, the frame synchronization is not defined in this level, instead each interface implements its own method. Further information is available on the next links: