WATLOWCLS200 Communications Specification Includes CLS200, MLS300 and CAS200

Overview

This reference guide is designed to help applications software programmers interface with Watlow®

CLS200 and MLS300 controllers and CAS200 alarm scanners via serial communication.

The following chapters are included in this guide:

• Anafaze/AB Protocol—gives an overview and explanation of the Anafaze/Allen Bradley 

communications protocol

• Modbus®-RTU Protocol—gives an overview and explanation of the Modbus®-RTU 

communications protocol

• Data Table Summary—provides standard controller data table maps for the parameters (one for 

each protocol)

• Parameters Description—describes each parameter

• Glossary—explanations of commonly used terms and acronyms

Chapter 1: Anafaze/AB 

Protocol

This chapter explains the ANAFAZE/Allen Bradley protocol.

Anafaze/AB Protocol Basics

This protocol is used with a serial communications link (EIA/TIA-232 or EIA-TIA-485) configured as 

follows:

• 2400 or 9600 baud 

• 8 data bits

• One or 2 stop bits

• No parity

Protocol Syntax

The controllers use a half-duplex (master-slave) protocol to interface to high-level software. The host 

software is considered the “master” and the controller is considered the “slave.” In other words, the 

software can request information from the controller or download information to the controller. The 

controller can only respond to communications transactions initiated by the host software. The controller 

cannot initiate communications.

Control Codes

The controller and host software communicate by sending and receiving information in a “packet” 

format. A packet consists of a sequence of bytes in a specific format; it can be as large as 256 bytes of 

data. (For more information about packets, see the Packet Format section later in this chapter.)

The numbers in the packet are sent in binary format. However, our examples show bytes in hexadecimal 

forma

Control code abbreviations in this manual

Transaction Sequence

Here are the four steps in a transaction between the host software and the controller. The following 

example shows the transaction as an exchange of packets. The example also assumes that there are no 

communication errors in the exchange.

1. The host software sends a packet that contains a read command or write command.

2. The controller sends a DLE ACK to the host software.

3. The host software receives a reply packet from the controller.

4. The host software sends a DLE ACK.

Transaction flow with no error handling

NOTE Due to the difference between the processing speeds of the controller and PC, it may be 

necessary to delay the computer's acknowledgement (ACK) in order for the controller to receive it. 

A delay of 200ms should suffice.

The flowchart below shows one way for the host software to handle error checking. If you are writing 

simple software, you don't necessarily need to use error handling routines as complete as these

Transaction flow with error handling

Packet Format

Messages are transmitted in the form of packets. Command and reply packets specify the source and 

destination addresses, whether to read or write, the block of data to read or write, etc.

A packet contains a sequence of binary bytes formatted this way:

Sending Control Codes

To send a control code, send a DLE before the control code to distinguish it from data.

Sending a DLE as Data

When you send a byte with 0x10, (a DLE), the controller and software interpret it as a command. 

Therefore, to send a DLE as data, send another DLE immediately before it (DLE DLE).

Codes in a Packet

This section describes the sequence of bytes in a packet, in the order the host software or controller 

sends them

DLE STX (byte) signals the beginning of a transmission. Every packet of information starts with the 

control codes DLE STX.

DST (byte) the address of the destination device (usually a controller; the first CLS200 controller is at 

0x08).

NOTE: When host software communicates with a CLS200 controller via the ANAFAZE or AB 

protocol, it does not send the controller’s actual address. Since the protocol reserves device 

addresses 0 to 7, the host software sends the value (controller address + 7), instead of the actual 

device address.

SRC (byte) the device address of the packet’s source. The host software is usually designated address

0x00.

CMD (byte) indicates the command that the host software sends to the controller. The software sends a 

read (0x01) or write (0x08). When the controller replies, it returns the read or write command with the 

7th bit set—in other words, it sends 0x41 or 0x48.

STS (byte) indicates the controller’s general status and error flags to the host software. The controller

ignores the status byte in the host software's command packet. The table below lists status byte values 

and definitions.

An “n” in the status bytes below indicates that the associated nibble may contain additional information. 

In most cases, the status byte is composed of two independent nibbles. Each nibble is independent so 

that two codes can return at once. For example, status code F1 indicates that data has changed (Fn) and 

the controller is being updated through the front panel (0x1).

TNSL least significant byte of the transaction number. This is the first half of a “message stamp.” The

controller sends back the TNSL and TNSH exactly as it received them, so host software can use the 

TNSL and TNSH bytes to keep track of message packets.

TNSH most significant byte of the transaction number. This is the second half of the “message stamp.

ADDL the low byte of the beginning data table address of the block of data to read or write.

ADDH the high byte of the beginning data table address of the block of data to read or write.

DATA the new values to be set with a write command, or the requested data in a response to a read 

command.

DLE ETX ends every packet of information. Signals the end of a transmission.

BCC or CRC one or two-byte error check at the end of the packet. There are two error check methods: 

Block Check Character (BCC), which requires 1 byte, and Cyclic Redundancy Check (CRC), which 

requires 2 bytes.

Error Checking

The default error check method, BCC is easier to implement than CRC, and is acceptable for most 

applications.

Select one error check method and configure both software and controller for that method, or they will 

be unable to communicate.

The error check methods work this way:

Block Check Character (BCC)

BCC checks the accuracy of each message packet transmission. It provides a medium level of security. 

The BCC is the 2’s complement of the 8-bit sum (modulo-256 arithmetic sum) of the data bytes between 

the DLE STX and the DLE ETX. (1’s complement +1)

• BCC does not detect transposed bytes in a packet.

• BCC cannot detect inserted or deleted 0 values in a packet.

• If you have sent 0x10 as data (by sending DLE 0x10) only one of the DLE data bytes is included in 

the BCC’s sum (the DLE = 0x10 also).

For instance, the block read example shown in the examples section, adds 0x08 00 01 00 00 80 02 10. 

Note that the 0x10 representing DLE has been left out of the calculation. The sum should come to 0x9B.

1001 1011 = 0x9B

0110 0100 = 1’s complement

______ +1 = 2’s complement

0110 0101 = 0x65

Cyclic Redundancy Check (CRC)

CRC is a more secure error check method than BCC. It provides a very high level of data security. It can 

detect:

• All single-bit and double-bit errors.

• All errors of odd numbers of bits.

• All burst errors of 16 bits or less.

• 99.997% of 17-bit error bursts.

• 99.998% of 18-bit and larger error bursts.

The CRC is calculated using the value of the data bytes and the ETX byte. At the start of each message 

packet, the transmitter must clear a 16-bit CRC register.

When a byte is transmitted, it is exclusive-ORed with the right 8 bits of the CRC register and the result 

is transferred to the right 8 bits of the CRC register. The CRC register is then shifted right 8 times by

inserting 0’s on the left.

Each time a 1 is shifted out on the right, the CRC register is Exclusive-ORed with the constant value 

0xA001. After the ETX value is transmitted, the CRC value is sent, least significant byte (LSB) first. 

Structured English procedure from AB Manual

data_byte = all application layer data, ETX 

CLEAR CRC_REGISTER

FOR each data_byte

GET data_byte

XOR (data_byte, right eight bits of CRC_REGISTER) 

PLACE RESULT in right eight bits of CRC_REGISTER

DO 8 times

Shift bit right, shift in 0 at left 

IF bit shifted =1

XOR (CONSTANT, CRC_REGISTER) 

PLACE RESULT in CRC_REGISTER

END IF

END DO

END FOR

TRANSMIT CRC_REGISTER as 2-byte CRC field

Examples

The host software sends two kinds of commands: block reads and block writes. This section shows 

examples of both commands.

Note: If you read data from a loop set to SKIP, the controller will send an empty packet for that loop.

This section does not show how to calculate the error check value included with every packet. For help 

calculating the error check value, see the section on BCC or CRC.

Block Read

This example shows the block read command the host software sends, the controller’s responses, and the 

software's acknowledgment.

Situation: Read process variables for loops 1 to 8.

• 8 process variables 2 bytes each = 16 bytes from data table address 0x0280.

Block Write

This section describes the block write command.

This example shows the block write command the master sends, the controller's responses, and the 

master's acknowledgment:

Situation: Write setpoint of 100 to loop 6.

• 1 setpoint 2 bytes per setpoint = 2 bytes to address 0x01CA (0x01C0 + xA, a 10-byte offset).

• Character values are represented in hexadecimal.

• The sender is device address 0.

• The destination is device address 8 (controller address 1).

• The software sends transaction number 00.

Message Data

Some messages contain data. What the data is and how much depends on the command used and the 

purpose of the message.

Data for a Read Command

For a block read command, the data block consists of one byte that indicates the number of bytes to read 

(up to 244 bytes of data). The controller sends back a packet with a data block that contains the 

requested bytes.

Data for a Write Command

For a block write command, the block contains the bytes to write (up to 242 bytes of data). The 

controller sends back a message packet without data.

Two-Byte Data Types

For two-byte data types, like process variable and setpoint, the controller or host software sends the data 

in two-byte pairs with the least significant byte first.

Figuring Block Size

To read parameter values, you must know how many bytes to request. Parameter values are stored 

contiguously such that the setpoints for all the loops are stored together and in loop number order. For 

example, to read the deviation alarm deadband value for loops one to five, you would read five bytes 

starting at 0x05A0. Some parameters, such as setpoint, require two bytes of memory to store. So, for 

example, if you want to read the setpoint for four loops, you must read eight bytes.

Calculate total block size in bytes for most loop parameters this way (do not forget the pulse loop):

(Data Size) * (Number of Loops)

Some parameters have values for both heat and cool. Calculate block size for such a parameter this way:

2 * (Data Size) * (Number of Loops)

One exception is the units for each loop. Calculate the data size for the units this way:

3 * (Number of Loops)

Parameters that are not loop parameters (like system status, digital inputs, or digital outputs) have 

specific data sizes. These data sizes are listed in the data table in the next section.

Anafaze/AB Data Table Summary

Each address holds one byte of data. Each parameter value requires one or two addresses to store 

depending on the type of data. The tablebelow indicates the number of bytes for each data type. The 

data type for each parameter is indicated in the tables on the following pages.

Because each loop is individually configurable, the number of instances of many parameters depends on 

the number of loops in the controller. Therefore, the number of bytes for these parameters is listed in the 

tables on the following pages in terms of the number of loops in the controller.

The storage requirements for some parameters depend on the number of digital inputs or digital outputs 

in the controller (MAX_DIGIN_BYTES and MAX_DIGOUT_BYTES). The storage of ramp-soak 

profile parameters depend on the number of profiles (MAX_RSP), the number of segments per profile 

(MAX_SEG), the number of triggers per segment (MAX_TRIG) and the number of events per segment 

(MAX_EVENT).

The table below shows the values for each of these factors. Use them to calculate the number of bytes 

for each parameter.

Ordering of Heat and Cool Channel Parameters

For parameters that have both heat and cool settings the heat values are stored in the first registers and 

the cool values are stored in the registers starting at the listed address plus MAX_CH.

Note: Data table parameters 46 to 60 and 100 are ramp-soak parameters. They are only used in 

controllers with the ramp-soak option. Parameters 81 to 95 are enhanced features and only available in 

controllers with the enhanced features option.

Ordering of Ramp-Soak Profile Parameters

Ramp-soak profile parameters are ordered first by profile, then by segment where applicable. So, for 

example, the first eight bytes of the Ready Events parameter are the ready segment event states for the 

first profile (profile A) and the next eight bytes are for profile B and so on. In the case of the segment 

triggers, the first byte contains the first trigger setting for the first segment of profile A, the second byte 

contains the settings for the second trigger for the first segment of profile A, the third byte contains the 

settings for the first trigger for the second segment of profile A and so on.