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