T-Series/RS-232 Communications Protocol/motion products

Control Through The RS-232 Serial Port

All T-Series devices use the same RS232 communications protocol. Your communications settings must be: 9600 baud, no hand shaking, 8 data bits, no parity, one stop bit. The yellow LED will light when there is activity on the RS232 lines. You may use this feature to determine which COM port you are connected to. We recommend using the Zaber Console that you can download from our web site. The source code is also available for you to use as an example for writing your own custom code. See the troubleshooting section later in this manual if you have trouble communicating with the device.

Important: The first time you connect a device to your computer you must issue a renumber instruction to assign each device a unique identifier. This should be done after all the devices in the daisy-chain are powered up. In older firmware versions (prior to version 5xx) you must issue a renumber instruction after each powerup. In firmware 5xx and up, the device number is stored in non-volatile memory and will persist after powerdown, so you need only issue the renumber instruction when you add new devices to the chain, or rearrange the order of the devices, however it does no harm to issue the renumber instruction after every powerup. You must not transmit any instructions while the chain is renumbering or the renumbering routine may be corrupted. Renumbering takes less than a second, after which you may start issuing instructions over the RS232 connection.

All instructions consist of a group of 6 bytes. They must be transmitted with less than 10 ms between each byte. If the device has received less than 6 bytes and then a period longer than 10 ms passes, it ignores the bytes already received. We recommend that your software behave similarly when receiving data from the devices, especially in a noisy environment like a pulsed laser lab.

The following table shows the instruction format:

Byte 1 - Device #
Byte 2 - Command #
Byte 3 - Data - Least Significant Byte (LSB)
Byte 4 - Data
Byte 5 - Data
Byte 6 - Data - Most Significant Byte (MSB)

The first byte is the device number in the daisy-chain. Device number 1 is the closest device to the computer and device number 2 is next and so on. If the number 0 is used, all the devices in the chain will process the accompanying command simultaneously.

The second byte is the command number. Bytes 3, 4, 5, and 6 are data in long integer, 2’s complement format with the least significant byte transmitted first. How the command data are interpreted depends on the command. Complete details are given in the command reference on the following page.

Examples

All devices renumber: 0, 2, 0, 0, 0, 0
All devices home: 0, 1, 0, 0, 0, 0
All devices return firmware version: 0, 51, 0, 0, 0, 0
Device 1 move to an absolute position (command 20) of 257 microsteps: 1, 20, 1, 1, 0, 0
Device 2 move to a relative position (command 21) of -1 microstep: 2, 21, 255, 255, 255, 255

Most instructions cause the device to reply with a return code. It is also a group of 6 bytes. The first byte is the device #. Byte #2 is the instruction just completed or 255 (0xFF) if an error occurs. Bytes 3, 4, 5 and 6 are data bytes in the same format as the instruction command data.

Data Conversion Algorithms

If you are writing software to control Zaber products, you'll likely need to generate data bytes 3 through 6 from a single data value, or vise versa. The following pseudo-code can be used as a model.

Converting command data into command bytes to send to Zaber products


If Cmd_Data < 0 then Cmd_Data = 256^4 + Cmd_Data                                        'Handles negative data

Cmd_Byte_6 = Cmd_Data / 256^3

Cmd_Data   = Cmd_Data - 256^3 * Cmd_Byte_6

Cmd_Byte_5 = Cmd_Data / 256^2

Cmd_Data   = Cmd_Data - 256^2 * Cmd_Byte_5

Cmd_Byte_4 = Cmd_Data / 256

Cmd_Data   = Cmd_Data - 256   * Cmd_Byte_4

Cmd_Byte 3 = Cmd_Data

Converting reply bytes into a single reply data value


Reply_Data = 256^3 * Rpl_Byte 6 + 256^2 * Rpl_Byte_5 + 256 * Rpl_Byte_4 + Rpl_Byte_3

If Rpl_Byte_6 > 127 then Reply_Data = Reply_Data - 256^4                                'Handles negative data

Sample Waveforms

If you are designing hardware to interface with Zaber products, it may be useful to see some sample waveforms.

This image shows an instruction (top waveform) and a reply (bottom waveform).
This is a closeup of the instruction bytes. Note that the voltage swing of the instruction waveform is about +/-10V. This is typical of the USB to RS232 converter to which the device is connected. The instruction bytes are 0, 51, 0, 0, 0, 0 indicating the instruction: Device: All, Command: Return version, Data: 0.
This is a closeup of the instruction byte 2. The "S" on either end represents the start and stop bits respectively. The start bit is always positive and the stop bit is always negative. The bit sequence is Start, 0, 1, 2, 3, 4, 5, 6, 7, Stop. The data is output with the least significant bit first, so the byte shown is actually 00110011 in binary or 32+16+2+1 = 51 in decimal. It's a good idea to do a timing "reality check" whenever viewing a waveform such as this. The bit rate should be 9600 bits/second. The time scale in the image is 200 us/division. Since a byte consists of 10 bits (start, stop, plus 8 data bits) and the bit rate is 9600 bits/s, the duration of a single byte should be 1.04 ms (10/9600 seconds) or about 5.2 divisions at 200 us/division. It can be seen in the image that this is the case.
This is a closeup of the reply bytes. Note that the voltage swing of the reply waveform is about +/-8V. This is a typical output from the RS232 driver chip used in Zaber devices. The instruction was to all devices. Only a single device is present so there is only one reply. The reply is 1, 51, 252, 1, 0, 0 indicating the reply "Device: 1, Reply: Firmware version, Data: 508". The data is the last 4 bytes combined, with least significant byte first. In this case the data is 0256^3 + 0256^2 + 1*256 + 252 = 508. This indicates a firmware version of 5.08 since according to the instruction specification a decimal is assumed before the last two digits. The time scale in this image is 1 ms/division. As noted above, at a bit rate of 9600 bits/second each byte should take 1.04 ms. Therefore a 6 byte reply should take 6.24 ms. It can be seen in the image that this is the case.