Simplifying Control Protocols

One of the core elements of a motion control device is the way that you interact with it. This is most apparent when sending commands to a controller and reading the responses that it returns. Every motion controller will have its own command protocol, or series of rules for the communication, that dictates the format of this conversation. This command protocol will affect:

1. How intuitive the controller is to use.
2. How quickly the controller can communicate.
3. The type of devices with which the controller will be able to communicate.

There are a wide variety of options for the communication standard, the format in which the information is sent, and the connector that is used to send it. All of these are a part of the command protocol. Having an open, consistent, and easy-to-use format allows devices to be integrated quickly into an application, allows users to get the most out of the device, and reduces the time it takes to become proficient with the controls. The command protocols of Zaber Technologies' stepper motor controllers were designed with these traits in mind.

Zaber Technologies produces a range of high-precision motorized positioning devices, including linear actuators and stages, rotary devices, and optic mounts. Many of these devices have integrated stepper motor controllers and drives, providing compact, turn-key solutions. One of our focuses when designing all our devices is to maintain ease of use without sacrificing functionality. This focus also cascades to the command protocols that the devices use.

Zaber's devices use two command protocols: an ASCII protocol and a 6-byte binary protocol. Each of these protocols work within the RS-232 serial communication standard. This standard was chosen because it is open, reliable, and widely-used. Additionally, the serial communication allows multiple controllers to be daisy-chained together so that you can communicate with more than one device over a single serial port. Figure 1 presents a simple comparison of the two protocols.

A COMPARISON OF COMMAND PROTOCOLS
	BINARY		ASCII
CONTROLLER SERIES	X-Series A-Series T-Series		X-Series A-Series
COMMAND STRUCTURE EXAMPLES
Move to home position Command 1:	1, 1, 0, 0, 0, 0	⌄ ⌄ ⌄	/home
Move forward 1000 microsteps Command 2:	1, 21, 232, 3, 0, 0	⌄ ⌄ ⌄	/move rel 1000
PROS	Short, simple, consistent Easy parsing of information	⌄ ⌄ ⌄ ⌄ ⌄	Simple to use Easy to pick up Compatible with many devices More support for new features & commands
CONS	Limited expandability & complexibility of commands list All data values must be converted to 4 bytes	⌄ ⌄ ⌄ ⌄ ⌄	Length of a command varies between commands

Zaber has three series of controllers available: the X-Series, the A-Series, and the T-Series. While each of the series can use the 6-byte binary communication protocol, the X-Series & A-Series can also use an ASCII command protocol. These controllers share many of the same features; however, we have introduced a number of new commands, settings, and features on the X-Series & A-Series, which can also accept a wider range of input voltages and communication speeds.

The 6-byte binary communication protocol is a simple method designed to relay commands in a consistent and compact format. Every command that is sent and every response that is received back from the controller contains three pieces of information: the device number executing the command, the number of the command or setting that is executed, and a data value. The device number is one byte, the command number is one byte, and the data value is four bytes. The device number is necessary for indicating which device in a daisy-chained series should respond to the command. The meaning of the data value will depend on the command.

For example, if you wanted to send a command to the first device in the series (device number 1) to find the home position (command number 1) and then send another command to move forward relative to that position (command number 2) by 1000 microsteps, you would send the following two commands:

  Command 1: 1, 1, 0, 0, 0, 0
  Command 2: 1, 21, 232, 3, 0, 0

In the first command, the data value is 0 because the home command does not need any additional information to run. In the second command, the relative movement command, the four data bytes are arranged in order of least significant byte to most significant byte. Each time a command completes, the controller will send back a response in the same format. You can see a complete explanation of the 6-byte binary protocol in our Binary Protocol Manual.

This protocol is short, simple, and consistent. Having a list of command numbers keeps the commands concise so that a large amount of information is fit into each communication. The consistent length of the commands and responses allows for easy parsing of the information as well.

One disadvantage of this simplicity is that it limits the expandability and complexity of the command list. It doesn't allow for commands that may require multiple parameters or non-numerical parameters. Some other disadvantages are that using commands numbers require referencing the list of commands, and that the data value has to be converted into four bytes. Both of these can be managed by programs designed for sending these commands. Some options for control software will be discussed later.

The ASCII protocol, available on Zaber's A-Series devices (firmware version 6.06+), allows you to communicate between a computer and the controller using plain text. For example, to command a device to move to a position 1000 microsteps forward from the current position, then return to the absolute 0 position, you would send the following commands:

  Command 1: /move rel 1000
  Command 2: /home        

The controller will respond with information letting you know that the command has been received and that it will be executed or whether there were any errors.

There are a number of benefits to this protocol. Firstly it is a simple to use command protocol because it is text based and designed to be easily readable. A new user will be able to pick up the communication quickly. Also using ASCII characters for control will allow compatibility with a wide variety of devices such as PLCs (programmable logic controllers). Faster communication speeds are supported by this protocol, which further increases this compatibility. Finally the protocol adds support for new features and commands, such as multiple limits, programmable actions, and I/Os, all of which are available in Zaber's X-MCC controllers.

A complete description of the ASCII protocol including all of the available commands and settings is available in our ASCII Protocol Manual.

Software is typically used to facilitate the use of these command protocols. Zaber provides free, open-source software, called the Zaber Launcher, to easily control and automate devices. Most programs or devices that can send RS232 serial commands can also communicate with the controllers, and Zaber can provide technical support for a variety of these.

One common program is LabVIEW, for which Zaber has drivers available. You can view details and examples of some of the software options for controlling the devices on Zaber's software support page. Customer support can be contacted at contact@zaber.com if you have any questions about the command protocols or about the software options.