Information in this manual is subject to change without notice. No part of this publication may be
reproduced, stored in a retrieval system, or transmitted in any form without written permission
from Watlow Anafaze.
Warranty
Watlow Anafaze, Incorporated warrants that the products furnished under this Agreement will be
free from defects in material and workmanship for a period of three years from the date of shipment. The customer shall provide notice of any defect to Watlow Anafaze, Incorporated within one
week after the Customer's discovery of such defect. The sole obligation and liability of Watlow
Anafaze, Incorporated under this warranty shall be to repair or replace, at its option and without
cost to the Customer, the defective product or part.
Upon request by Watlow Anafaze, Incorporated, the product or part claimed to be defective shall
immediately be returned at the Customer's expense to Watlow Anafaze, Incorporated. Replaced or
repaired products or parts will be shipped to the Customer at the expense of Watlow Anafaze,
Incorporated.
There shall be no warranty or liability for any products or parts that have been subject to misuse,
accident, negligence, failure of electric power or modification by the Customer without the written
approval of Watlow Anafaze, Incorporated. Final determination of warranty eligibility shall be
made by Watlow Anafaze, Incorporated. If a warranty claim is considered invalid for any reason,
the Customer will be charged for services performed and expenses incurred by Watlow Anafaze,
Incorporated in handling and shipping the returned unit.
If replacement parts are supplied or repairs made during the original warranty period, the warranty
period for the replacement or repaired part shall terminate with the termination of the warranty
period of the original product or part.
The foregoing warranty constitutes the sole liability of Watlow Anafaze, Incorporated and the customer's sole remedy with respect to the products. It is in lieu of all other warranties, liabilities, and
remedies. Except as thus provided, Watlow Anafaze, Inc. disclaims all warranties, express or
implied, including any warranty of merchantability or fitness for a particular purpose.
Please Note:
External safety devices must be used with this equipment.
This reference guide is designed to help applications software
programmers with the following tasks:
Interface to Watlow Anafaze MLS300, CLS200, MLS and CLS con-
•
trollers, 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.
Communications Specification 1
Overview
2 Communications Specification
Chapter 1: ANAFAZE/AB Protocol
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:
CodeMeaning
DLE
STX
ETX
ENQ
Escape code
Signals the start of the other control code character sequences.
Start Text
Begins a transmission.
End Te xt
Ends a transmission.
Request Resend
Tells the controller to resend its last ACK or NAK. Host software
sends this command, and the controller responds to it.
Decimal
Value
1610
0202
0303
0505
Hex
Value
Communications Specification 3
Chapter 1: ANAFAZE/AB Protocol
CodeMeaning
ACK
NAK
Acknowledged
Signals that a syntactically correct packet has been received.
Not Acknowledged
Signals that an incorrect, invalid packet has been received.
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.
Decimal
Value
0606
2115
Hex
Value
Send
command
packet
Receive
DLE ACK
Receive valid
reply packet
Send
DLE ACK
(continued on next page)
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.
4 Communications Specification
Send command
packet
Chapter 1: ANAFAZE/AB Protocol
This flowchart 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.)
Wait for DLE ACK
or DLE NAK
Timed out?
NO
Got ACK
or NAK?
ACK
Wait for reply
packet
YES
NAK
Send DLE ENQ
NO
Sent DLE
ENQ
3 times?
Send DLE NAK
YES
NO
NO
Sent packet
3 times?
YES
Done
Timed out?
NO
Packet valid?
YES
Send DLE ACK
NO
Sent DLE
NAK 3 times?
YESYES
Communications Specification 5
Chapter 1: ANAFAZE/AB Protocol
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:
DLESTXDLE ETXBCC/CRC
DATA
DST
SRCCMD
STS
TNSL TNSH ADDL
ADDH
Sending Control Codes
To send a control code, send a DLE before the control code to
distinguish it from data.
Codes in a Packet
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).
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 con-
troller; 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.
6 Communications Specification
SRC
The SRC byte is the device address of the packet’s source. The host
•
software is usually designated address x00.
Chapter 1: ANAFAZE/AB Protocol
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
00The controller has nothing to report, or AB protocol is selected.
01Access denied for editing. The controller is being updated through the
front panel.
02AIM Comm failure.
A0A controller reset occurred.
CxThe controller received a command that was not a block read or block
write. (Command Error)
DxThe block write command attempted to write beyond a particular parame-
ter block boundary, or the host software attempted to access a data table
block that does not exist. (Data Boundary Error)
ExThe Alarm_Status variable has changed. The software should query the
alarm status block to determine the particular alarm flag that changed.
FxThe 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.
Description
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.”
Communications Specification 7
Chapter 1: ANAFAZE/AB Protocol
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.
Error Checking
Block Check Character (BCC)
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:
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)
8 Communications Specification
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.
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.
Chapter 1: ANAFAZE/AB Protocol
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
Communications Specification 9
Chapter 1: ANAFAZE/AB Protocol
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 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.
10 Communications Specification
Chapter 1: ANAFAZE/AB Protocol
The next picture shows the read command.
x10 02 08 00 01 00 00 00 80 02 10 10 10 03 65
DLE
Data (number of bytes
to upload)
DLE
Data table address (LSB first)
Transaction number
Placeholder for status byte
Command (block read)
SRC (Source Device Address)
BCC value
ETX
DST (Destination Device Address)
STX
DLE
The controller sends a DLE-ACK:
x10 06
ACK
DLE
Communications Specification 11
Chapter 1: ANAFAZE/AB Protocol
Then the controller sends its reply:
x10 02 00 08 41 00 00 00 (DATA) 10 03 C3
BCC value
ETX
DLE
Data (see below)
Transaction number
Status (00 = nothing to report)
Command
Source Device Address (controller address + 7)
Destination Device Address
STX
DLE
DATA:
xE2 01 09 02 E4 01 09 02 F1 01 DF 01 28 3C E4 01
Data, transmitted LSB first. Assuming precision for loops is –1:
Loop 1 PV = x01E2 = 482, displayed as 48
Loop 2 PV = x0209 = 521, displayed as 52, etc.
Then the host software sends a DLE-ACK:
x10 06
ACK
DLE
12 Communications Specification
Block Write
Chapter 1: ANAFAZE/AB Protocol
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 x01CA (x01C0 +
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.
Here's a picture of the write command:
x10 02 08 00 08 00 00 00 CA 01 E8 03 10 03 3A
DLE
Data:
100 converts to 1000 = x03E8
(assuming the precision for loop 6 is –1)
Data table address
LSB first; x01CA = setpoint for loop
Transaction number
Placeholder for status byte
Command (block write)
SRC (Source Device Address)
DST (Destination Device Address)
STX
DLE
The controller sends a DLE-ACK:
x10 06
BCC value
ETX
DLE
ACK
Communications Specification 13
Chapter 1: ANAFAZE/AB Protocol
Here’s a picture of the controller’s reply:
x10 02 00 08 48 00 00 00 10 03 B0
BCC value
ETX
DLE
Transaction number LSB/MSB
Status (00 = Nothing to report)
Command (block write)
Source device address
Destination device address
STX
DLE
Message Data
Data for a Read Command
Then the host software sends a DLE-ACK:
x10 06
ACK
DLE
Some messages contain data. What the data is and how much depends
on the command used and the purpose of the message.
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.
14 Communications Specification
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.
Chapter 1: ANAFAZE/AB Protocol
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.
Communications Specification 15
Chapter 1: ANAFAZE/AB Protocol
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.
Unsigned char (UC)1 byte
Signed char (SC)1 byte
Unsigned int (UI)2 bytes
Signed int (SI)2 bytes
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.
Data Type and SymbolData Size
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.
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.
Number
82PV Retransmit Maximum Input4250UIMAX_CH * 4
83PV Retransmit Maximum Output42E0UCMAX_CH * 2
Address
in Hex
39A0UIMAX_CH * 2
3A30UCMAX_CH
3994UCMAX_CH * 8
4200UCMAX_CH * 2
TypeNumber of Bytes
MAX_DIGOUT_BYTES
MAX_SEG
MAX_SEG*
MAX_TRIG
* MAX_EVENT
MAX_SEG
MAX_SEG
Communications Specification 19
Chapter 1: ANAFAZE/AB Protocol
NumberDescription
84PV Retransmit Minimum Input4330UIMAX_CH * 4
85PV Retransmit Minimum Output43C0UCMAX_CH * 2
86Cascade Primary Loop Number4410UCMAX_CH
87Cacade Base Setpoint4440SIMAX_CH * 2
88Cacade Minimum Setpoint4490SIMAX_CH * 2
89Cascade Maximum Setpoint44E0SIMAX_CH * 2
90Cascade Heat/Cool Span4530UIMAX_CH * 4
91Ratio Control Master Loop Number45C0UCMAX_CH
92Ratio Control Minimum Setpoint45F0SIMAX_CH * 2
93Ratio Control Maximum Setpoint4640SIMAX_CH * 2
94Ratio Control Control Ratio4690UIMAX_CH * 2
95Ratio Control Setpoint Differential46E0SIMAX_CH * 2
96Loop Status4730UCMAX_CH
97Output Type/Disable4760UCMAX_CH * 2
98Output Reverse/Direct47B0UCMAX_CH * 2
99Controller T ype47F0UC1
100Ramp/Soak Profile Number4800UCMAX_CH
101Controller Address4830UC1
102Baud Rate4840UC1
Address
in Hex
TypeNumber of Bytes
20 Communications Specification
Chapter 2: Modbus-RTU Protocol
Chapter 2: Modbus-RTU Protocol
Overview
Transactions on Modbus-RTU Networks
Standard Modbus-RTU ports use an EIA/TIA-232C- or EIA/TIA-485/
422-compatible serial interface that defines connector pinouts, cabling,
signal levels, transmission baud rates, and parity checking.
Controllers communicate using a master-slave technique, in which only
one device (the master) can initiate transactions (called “queries”). The
other devices (slaves) respond by supplying the requested data to the
master, or by taking the action requested in the query. Typical master
devices include host processors and programming panels.
The master can address individual slaves, or initiate a broadcast
message to all slaves. Slaves return a message (called a “response”) to
queries that are addressed to them individually. Responses are not
returned to broadcast queries from the master.
The Modbus-RTU protocol establishes the format for the master’s query
by placing into it the device (or broadcast) address, a function code
defining the requested action, any data to be sent, and an error-checking
field. The slave’s response message is also constructed using ModbusRTU protocol. It contains fields confirming the action taken, any data to
be returned, and an error-checking field. If an error occurred in receipt
of the message, or if the slave is unable to perform the requested action,
the slave will construct an error message and send it as its response.
Communications Specification 21
Chapter 2: Modbus-RTU Protocol
The Query-Response Cycle
Query Message from Master
Device Address
Function Code
8-Bit
Data Bytes
Error Check
Device Address
Function Code
8-Bit
Data Bytes
Error Check
Response Message from Slave
The Query
The function code in the query tells the addressed slave device what
kind of action to perform. The data bytes contain any additional
information that the slave will need to perform the function. For
example, function code 03 will query the slave to read holding registers
and respond with their contents. The data field must contain the
information telling the slave which register to start at and how many
registers to read. The error check field provides a method for the slave to
validate the integrity of the message contents.
The Response
If the slave makes a normal response, the function code in the response
is an echo of the function code in the query. The data bytes contain the
data collected by the slave, such as register values or status. If an error
occurs, the function code is modified to indicate that the response is an
error response, and the data bytes contain a code that describes the error.
The error check field allows the master to confirm that the message
contents are valid.
Serial Transmission
22 Communications Specification
Each 8-bit byte in a message contains two 4-bit hexadecimal characters.
This high character density allows better data throughput than ASCII for
the same baud rate. Each message must be transmitted in a continuous
stream.
Coding System
• 8-bit binary, hexadecimal 0 to 9, A to F
• 2 hexadecimal characters contained in each 8-bit field of the message
Bits per Byte
• 1 start bit
Loading...
+ 64 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.