Motion Control Bus (MCB) - High speed serial protocol


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.

Main features

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:

Node ID


HeaderConfig dataCyclic data (optional)CRC
AddressCommandPending frame
4 bits12 bits3 bits1 bit4 word0 - 32 word1 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

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. 

HeaderConfig dataCRC
1 word4 word1 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:

Master commands

  • 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

    HeaderConfig dataCRC
    AddressCommandPending frame
  • Write Access 0b010It 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

    HeaderConfig dataCRC
    AddressCommandPending frame
  • 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..78..1314..1516..1818..63MSB (bits)

    SizeData typeCyclic typeAccess typeReserved
    Number of bytesINT16 → 0Config → 0 READ → 3
    UINT16 → 1
    INT32 → 2 Cyclic Tx (drive to master) → 1WRITE → 5
    UINT32 → 3
    FLOAT → 4 Cyclic Rx (master to drive) → 2READ/WRITE → 7
    STRING → 5

    Get info example

    Getting information of register 0x011

    Master request

    HeaderConfig dataCRC
    AddressCommandPending frame

    Slave reply

    HeaderConfig dataCRC
    AddressCommandPending frame
  • 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.

Slave commands

  • ACK access 0b011. Indicates that the request has been processed correctly

    Simple read example

    Successful reply to read access on register 0x10

    HeaderConfig dataCRC
    AddressCommandPending frame
  • 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

    HeaderConfig dataCRC
    AddressCommandPending frame
  • 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

    HeaderConfig dataCRC
    AddressCommandPending frame
  • Idle command 0b111It 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 briefError codeExample description
Unsupported access0x06010000Try to write a read only register
Register doesn't exist0x06020000Register address doesn't exist into dictionary
General error0x08000000Undefined error has been detected
CRC error0x08010040A CRC error has been detected
Invalid command0x08010030Unknown command for the slave

Data field

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 (0x 30 2E 31 2E 32 2E 33 2E 34 2E 35 2E 36 2E 37) is sent by the slave using two frames:

Frame 1

HeaderConfig dataCRC
AddressCommandPending frame

Frame 2

HeaderConfig dataCRC
AddressCommandPending frame

Extended frame

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:

HeaderConfig dataCRCExtended data
0x0B20x30x10x00000000000000C80x36A7200 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:

HeaderConfig dataCRC

The complete command: 0x0001 0FB2 0356 0000 0000 0000 2714

Cyclic access

Cyclic access is the name used to identify cyclic / synchronous requests from master to slave. This access type use the whole frame. 

Cyclic frame
HeaderConfig dataCyclic dataCRC
1 word4 Word0 - 32 word1 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 0x640

(Communication state)

1Config access
2Cyclic access

Cyclic mode

Register at address 0x641 determines the cyclic mode with the following possible values:

Register 0x641

(Cyclic mode)

0Non-sync mode
1Sync enabled

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:

Config mode

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.

Cyclic mode

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:

  1. The protocol is losing the capability of modify a non-cyclic register during cyclic operation
  2. 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.
  3. Unifying the frame makes the communication more deterministic as the transmission time is constant during cyclic operation.

Mapping procedure

To map dictionary registers into a cyclic frame:

  1. Disable cyclic access if enabled
    Set register 0x640 (communication state)

    Config accessCyclic access

    Set it to 1 to disable cyclic access.

  2. 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:

    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.

  3. 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

  4. 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 briefError codeExample description
Incorrect mapping0x06040041Register is not cyclic mappable
Too much mapped registers0x06040042Mapped registers don't fit into Cyclic frame
Invalid cyclic index0x08010000A gap has been detected in the mapped register list
Cyclic state is not reachable0x08010010Cyclic state is not reachable for an unkown reason
Configuration is not allowed0x08010020Something in the mapping is wrong and cyclic mode is not reachable

Frame synchronization

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: