100/180 mm PAPERLESS GRAPHIC RECORDER: USER GUIDE
HA028910
Issue 13 Sep 16
User Guide
Page 329
8.4.9 Permanent ID table
This table contains information relating to the recorder, and also gives the start address of the feature
identifi cation table (FIT).
Table 8.4.9 Permanent ID table
FFF0
0500
FFF1
FFF2
FFF3
FFF4
6100 or 6180
0001
CC26
HHHH
Product ID
Version ID
FIT start address
Checksum
Company ID
8.5 DATA TRANSMISSION
Each message (request or response) is packaged in the (MODBUS) frame shown below. The messages
consist of a 7 byte prefi x, followed by the function code (in hex), followed by the relevant data bytes, the
number and content of which depend on the function code, as described in subsequent sections.
Figure 8.5 MODBUS package
Byte 0
Transaction
identifier
(usually 00)
Transaction
identifier
(usually 00)
Protocol
identifier
(00)
Protocol
identifier
(00)
Byte 1
Byte 2
Byte 3
Byte 4
Number of
bytes fol-
lowing
Byte 5
Always 00
Byte 6
Recorder
Modbus
address
Byte 7
Modbus
function
code (hex)
Bytes 8 onwards
Data
(Depends on
function code)
Notes:
1 The transaction identifi er has no active function - the recorder just copies the bytes from the
request message to the response message.
2. The protocol identifi er bytes are always zero.
FUNCTION CODES AND EXCEPTION CODES
Refer to
section 8.2.1
for lists of function codes and exception codes supported.
TEXT STRINGS
When sending text strings, such as Batch fi elds, the fi nal character must be followed by one or two ‘Null’
characters. The number of bytes in the text string (including the null) must be even, even if this means
adding two nulls at the end of the message instead of one.
For example, the text string: “Batch Number’ should be sent as
Ba tc hSpace Nu mb er NullNull
, or
Ba tc hSpace Nu mb er SpaceNull
where each pair of characters occupies on 16-bit word. Similarly, the text string ‘Batch Number:’ would be
sent as
Ba tc hSpace Nu mb er :null
,
but only one Null character is required to provide an even number of bytes.
