WATLOWCLS200, MLS300, and CAS200 Communications Specification

This reference guide is designed to help applications software

programmers with the following tasks:

• Interface to Watlow Anafaze MLS300, CLS200, MLS and CLS controllers, and the CAS200 and CAS scanners via serial communications.

• Modify the communications Anafaze protocol driver in the Watlow 

Anafaze Communications Driver Kit. (If you have the communications driver kit, you don’t need to read this manual unless you want 

to modify the communications driver.)

In This Manual

The following sections are included in this guide: 

Chapter 1: Anafaze/AB Protocol. Gives an overview and explanation

of the Anafaze/Allen Bradley communications protocol.

Chapter 2: Modbus-RTU Protocol. Gives an overview and

explanation of the Modbus-RTU communications protocol

Chapters 1 and 2: Data Table Summary. Provides standard controller

data table maps for the parameters (one for each protocol).

Chapter 3: Parameters Description. Describes each parameter.

Appendix A: Communications driver.

Glossary: Explanation of commonly used terms and acronyms.

NOTE

This reference guide is not a tutorial. It does not explain

how to use the controller; it is not a programming reference; it also does not explain PID control, alarms, linear

scaling, or other topics that are explained in detail in the

controller manuals. If you need additional information

about a topic covered in this reference guide, consult the

documentation included with your controller.

Chapter 1: ANAFAZE/AB Protocol

This section explains the ANAFAZE/Allen Bradley protocol used in

Watlow Anafaze MLS, CLS, and CAS devices. These controllers

operate on serial communications links (EIA/TIA-232 or EIA-TIA-485)

at either 2400 or 9600 baud. They use 8 data bits, one or 2 stop bits, and

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.

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

Control Codes

Watlow Anafaze abbreviates control codes this way

Chapter 1: ANAFAZE/AB Protocol

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.

The following flowchart shows a transaction with no error handling.

NOTE

Due to the difference between the processing speeds of the

controller and PCs, it may be necessary to delay the computer's acknowledgement (ACK) in order for the controller

to receive it. A delay of 200 ms should suffice

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 an x10, (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

• The DLE STX byte signals the beginning of a transmission. Every 

packet of information starts with the control codes DLE STX. 

DST

• The DST byte is the address of the destination device (usually a controller; the first Watlow Anafaze controller is at x08).

NOTE

When host software communicates with an MLS, a CLS, or

a CAS in 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

• The SRC byte is the device address of the packet’s source. The host 

software is usually designated address x00.

DLE STX DLE ETX BCC/CRC

DST SRC CMD STS TNSL TNSH ADDL ADDH DAT

CMD

• The CMD byte indicates the command that the host software sends 

to the controller. The software sends a read (x01) or write (x08). 

When the controller replies, it returns the read or write command 

with the 7th bit set—in other words, it sends an x41 or x48.

STS (The Status Byte)

• The controller uses the status byte, or STS, to return general status 

and error flags to the host software. (The controller ignores the status 

byte in the host software's command packet.) The next table shows 

status byte values and definitions. 

• An “x” 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 (Fx) and the controller is being 

updated through the front panel (x1).

Status

in Hex Description

00 The controller has nothing to report, or AB protocol is selected.

01 Access denied for editing. The controller is being updated through the 

front panel.

02 AIM Comm failure.

A0 A controller reset occurred.

Cx The controller received a command that was not a block read or block 

write. (Command Error)

Dx The block write command attempted to write beyond a particular parameter block boundary, or the host software attempted to access a data table 

block that does not exist. (Data Boundary Error)

Ex The Alarm_Status variable has changed. The software should query the 

alarm status block to determine the particular alarm flag that changed.

Fx The controller altered shared data, either internally (from the firmware) or 

externally (from the keyboard). The host software should read the Data 

Changed Register to determine which data has been altered and update 

its own run-time memory

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

• Every packet of information must end with the codes DLE ETX. 

These codes signal the end of a transmission.

BCC or CRC

• Communications packets include a 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.

Watlow Anafaze recommends that you use the default error check

method, BCC. It is easier to implement than CRC, and it 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 an x10 as data (by sending DLE x10) only one of the 

DLE data bytes is included in the BCC’s sum (the DLE = x10 also).

For instance, the block read example shown in the examples section, 

adds x08 00 01 00 00 80 02 10. Note that the x10 representing DLE 

has been left out of the calculation. The sum should come to x9B.

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 ExclusiveORed with the constant value xA001. After the ETX value is

transmitted, the CRC value is sent, least significant byte (LSB) first.

Below is a 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

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 earlier in this chapter.

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 

x0280.

• Character values are represented in hex. 

• The sender is device address 0. 

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

• The software sends transaction number 00

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

In order 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 x05A0. 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.

Figure 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. Figure block size

for such a parameter this way:

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

One exception is the units for each loop. Figure 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 table below

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.

Data Type and Symbol Data Size

Unsigned char (UC) 1 byte

Signed char (SC) 1 byte

Unsigned int (UI) 2 bytes

Signed int (SI) 2 bytes

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.

Anafaze/AB Protocol Data Table

Number Description Address 

in Hex Type Number of Bytes

0 Proportional Band/Gain 0020 UC MAX_CH * 2

1 Derivative Term 0060 UC MAX_CH * 2

2 Integral Term 00A0 UI MAX_CH * 4

3 Input Type 0120 UC MAX_CH

4 Output Type 0180 UC MAX_CH * 2

5 Setpoint 01C0 SI MAX_CH * 2

6 Process Variable 0280 SI MAX_CH * 2

7 Output Filter 0340 UC MAX_CH * 2

8 Output Value 0380 UI MAX_CH * 4

9 High Process Alarm Setpoint 0400 SI MAX_CH * 2

10 Low Process Alarm Setpoint 04C0 SI MAX_CH * 2

11 Deviation Alarm Band Value 05A0 UC MAX_CH 

12 Alarm Deadband 0600 UC MAX_CH

13 Alarm Status 0660 UI MAX_CH * 2

14 Not used 06A0 128