Protocol Definition

HCTS2000
High Speed Closed Tube Sorter

LIS communication protocol

Version history

Version Date Author Notes

1.0 10.06.2008 R.Meyer Erstellung
1.0E 03.07.2008 R.Gambill English translation
1.1 30.10.2008 R. Meyer Added Protocol version 1 and example
1.2 18.12.2008 U. Hoffmann Additions for FA 45 sensor
2.0 27.02.2009 U. Hoffmann New section order, new revision off all sections
2.1 12.03.2009 U. Hoffmann Additions to sections 1.1, 1.2, 2.2 and 5.2
2.2 12.03.2009 U. Hoffmann Section 5.2 corrected
2.3 20.03.2009 U. Hoffmann Addition to sections 1.1, 2.2 and 5.4
2.4 08.04.2009 K.Wittmann Separated descriptions of protocol version 1 and 2
Added asynchronous protocol examples
Added LIS programming example
2.5 13.05.2009 R.Meyer Added occurrences field for “m-u-t Link”
2.6 02.11.2009 U. Hoffmann Use of delimiters corrected in sections 4.5 and 6.5

Address: m-u-t AG
Am Marienhof 2
D-22880 Wedel
GERMANY

Phone: +49 (0)4103 / 93 08-0
Fax: +49 (0)4103 / 93 08-99
Internet: http://www.mut-group.com
EMail: info@mut-group.com
Filename: HCTS_LIS_Protokollbeschreibung_V2.5_EN.doc
Document template: mut-Bedienungsanleitung_R2-0.dot
Table of Contents

1 OVERVIEW......................................................................................................................................1
1.1 OPERATIONAL BASICS ..................................................................................................................1
1.2 PHYSICAL CONNECTION ................................................................................................................2
1.3 LOGICAL CONNECTION ..................................................................................................................2

2 LOW-LEVEL COMMUNICATION PROTOCOL..............................................................................3

2.1 FRAMING .....................................................................................................................................3
2.2 ERROR DETECTION AND FLOW CONTROL .......................................................................................3

3 HIGH-LEVEL COMMUNICATION PROTOCOL VERSION 1.........................................................5

3.1 FRAME TYPES ..............................................................................................................................5
3.2 TUBE INFORMATION DATA FRAMES ................................................................................................5
3.3 TUBE INFORMATION FRAME STRUCTURE FOR PROTOCOL VERSION 1 ...............................................6
3.4 TEST REQUIREMENTS DATA FRAMES..............................................................................................7
3.5 TEST REQUIREMENTS FRAME STRUCTURE FOR PROTOCOL VERSION 1 ............................................7

4 HIGH-LEVEL COMMUNICATION PROTOCOL VERSION 2.........................................................8

4.1 FRAME TYPES ..............................................................................................................................8
4.2 TUBE INFORMATION DATA FRAMES ................................................................................................8
4.3 TUBE INFORMATION FRAME STRUCTURE FOR PROTOCOL VERSION 2 ...............................................9
4.4 TEST REQUIREMENTS DATA FRAMES............................................................................................10
4.5 TEST REQUIREMENTS FRAME STRUCTURE FOR PROTOCOL VERSION 2 ..........................................10

5 DATAFLOW EXAMPLES FOR PROTOCOL VERSION 1 ...........................................................11

5.1 SPECIAL CHARACTERS: ..............................................................................................................11
5.2 INITIALIZATION SEQUENCE (START OF SORTING RULE)..................................................................11
5.3 TERMINATION SEQUENCE (HCTS STOPPED)................................................................................11
5.4 INFORMATION TRANSFER FOR EACH TUBE ....................................................................................12
5.5 ASYNCHRONOUS PROTOCOL EXAMPLES ......................................................................................12

6 DATAFLOW EXAMPLES FOR PROTOCOL VERSION 2 ...........................................................13

6.1 SPECIAL CHARACTERS: ..............................................................................................................13
6.2 INITIALIZATION SEQUENCE (START OF SORTING RULE)..................................................................13
6.3 TERMINATION SEQUENCE (HCTS STOPPED)................................................................................13
6.4 INFORMATION TRANSFER FOR EACH TUBE ....................................................................................14
6.5 ASYNCHRONOUS PROTOCOL EXAMPLES ......................................................................................14

7 SIMPLE COMMUNICATION EXAMPLE FOR LIS PROCESSING OF HCTS MESSAGES .......16

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc I
1 Overview

1.1 Operational basics

The HCTS is a device intended to identify and sort sample tubes in clinical laboratories. The
sorting process may use tube inherent information like certain barcode digits, tube shape
classification and tube cap color classification as well as additional data supplied by a host
computer connected to the HCTS (Lab Information System, LIS) to determine the sorting
target for each tube.
The logical combination of the data from these information sources is defined in a parameter
file stored on the HCTS. This file holds up to 10 different sorting rules that can be selected
by the user, as well as a rule independent global parameter section.
Selecting a sorting rule by pressing a button on a touch panel display starts the sorting
process. If the selected sorting rule needs information supplied by the LIS (‘online rule’), the
communication is initiated by sending certain startup frames. For each tube processed by
the HCTS a query frame is sent to the LIS. This frame contains the tube barcode, and,
depending on the HCTS options and firmware version, information about the selected sorting
rule and a code for the tube cap color.
The LIS must respond to each query with a frame containing the tube barcode and an order
list with up to 25 order codes with a length of 8 characters each. These frames do not need
to arrive at the HCTS in the same order as the queries have been sent, as the allocation to
the tubes is done by the barcode. These response frames from the LIS do not replace the
acknowledging that is used to inform the sending side that a frame has correctly been
received (see 2.2). Also the HCTS may send queries for subsequent tubes before receiving
an order list, as it doesn’t pause the processing of tubes while it is waiting for an order list.
If the HCTS is stopped while running an online rule (due to user intervention, lack of tubes or
an error condition), it sends a stop frame to the LIS.
Additionally the HCTS may be configured to send an announcement frame to the LIS. These
frames contain the target bin number in addition to the information already included in the
request and are sent when the tube is pushed into the target bin (so the order of the
announcements is different from that of the requests due to the target dependent travel of
the tubes). If enabled (by parameter 3 in the global parameter section of the parameter file),
this announcements take place for all sorting rules. If an online rule has been selected, two
frames are sent for each tube (request and announcement), if the rule doesn’t need LIS data
(‘offline rule’), only the announcements are sent. The same parameter determines whether
startup and stop frames are sent when running an offline rule.

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 1
1.2 Physical connection
Data transfer between the HCTS and the LIS takes place over a serial RS232 connection.
The connector at the HCTS is a female 25-pin D-Sub with screw lock.
Only 4 pins are used:

25 pin D-Sub pin number signal

1 frame ground
2 TXD (HCTS -> LIS)
3 RXD (LIS -> HCTS)
7 signal ground

No hardware handshaking is implemented, as a flow control mechanism is provided by the

low level protocol (see 2.2).
Port parameters can not be changed and are set to 9600 Baud, 8 databits, 1 stopbit, no
parity (9600 8N1).

1.3 Logical connection

The logical connection is implemented as a combination of two protocol levels. The lower
level supplies framing and error detection to enable flow control and ensure data integrity.
The higher protocol level defines the application data actually transferred.
There are two versions of high-level protocols available. A simple one, called version 1, uses
fixed length fields without field delimiters. The barcode length is limited to 12 characters.
Version 2 supports barcodes with a length of up to 30 characters, variable length fields
separated by delimiters and is available in HCTS firmware versions 2.3.061 and later. The
protocol to be used by the HCTS is configured in the global parameter section of the
parameter file in parameter 14 (“LIS protocol version”, 0 for version 1, 1 for version 2).

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 2
2 Low-Level Communication Protocol

2.1 Framing
Each data transfer takes place within a frame. Each data packet has the following structure:

<STX> FL FN FI [DATA] Checksum <ETX>

<STX> 1 Byte (02hex) Start of frame

FL 3 Byte Frame length, not used currently, filled with blanks (20hex)
FN 2 Byte Frame number, not used currently, filled with blanks (20hex)
FI 2 Byte Frame identifier, only ‘E’, ‘I’, ‘D’ and ‘S’ used for 1. Byte
currently, 2. Byte always blank (20hex)
[DATA] Application data (if present)
Checksum 2 Byte Checksum
<ETX> 1 Byte (03hex) Frame termination

2.2 Error detection and flow control

In order to ensure data integrity, a checksum is transmitted with each frame. This checksum
is calculated by adding the values of all transferred bytes from <STX> to [DATA] (both
inclusive), modulus 100hex. The sum is devided by 10hex. 30hex is added to both the
quotient and the remainder of the division. The results (ASCII ‘0’ to ‘?’) represent the 2-
character checksum. For example, the sum 3f9hex will result in “?9”.
After the listening side has received a valid frame, it sends an ACK (06hex). In the case of a
checksum error, it sends a NAK (15hex). If the sending side gets a NAK, it retransmits the
frame immediately. A retransmission is also initiated if neither ACK or NAK have been
received about 1 sec after the frame was transmitted.
If the HCTS needs to send data to the LIS, a frame is assembled and transmitted even if the
reception of a frame from the LIS is in progress at the same time. The acknowledgement of
the received frame is delayed until the transmit frame has been sent out completely.
However, if the LIS wants to acknowedge a received frame, it may also interleave the ACK
(or NAK) into a frame that is transmitted from the LIS to the HCTS at the same time.
This acknoledgement mechanism is also used to provide flow control. A new frame may be
transmitted by LIS or HCTS not until the preceding one has been acknowledged, so both
sides only need to buffer a single frame. By delaying the ACK communication may be stalled
for up to about 8 seconds. Longer breaks are not possible, as the HCTS stops and signals a

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 3
communication error after 8 frame retransmissons (taking place if the acknowledge timeout
of about 0.8 sec has expired).
No means for delaying the transmission on a character by character basis are implemented.

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 4
3 High-Level Communication Protocol version 1

For information on differences of version 1 and 2 please refer to 1.3 Logical connection.

3.1 Frame types

Four different frame types, coded in the frame identifier field (see 2.1), are used by the
HCTS:

Name Symbol Explanation

Enquiry E Sent from HCTS when the sort function is started. No data is
transmitted with this frame, the data field (see 2.1) is empty.
The function of this frame is to detect if the LIS is online.
Init I Sent from HCTS when the sort function is started after the enquiry has
been ACKed be the LIS. No data is transmitted with this frame, the data
field (see 2.1) is empty.
This frame informs the LIS that the HCTS has been started.
Data D This frame type is used for the actual data transfer between LIS and
HCTS.
Only this type of frame differs for protocol versions 1 and 2 (see 1.3).
Stop S Sent from the HCTS when the sort function has been stopped (see
1.1). No data is transmitted with this frame, the data field (see 2.1) is
empty.

3.2 Tube information data frames

This type of data frame is used to send tube information from HCTS to LIS. It is transmitted
immediately after the HCTS has gathered all tube information despite that supplied by the
LIS (tube barcode, cap color and tube type) to request an order list from the LIS (query
frame).
If announcement frame transmission has been enabled (see 1.1), a tube information frame
is also sent by the HCTS whenever a tube is pushed into a target bin or placed into a rack by
the MK3 system (announcement frame).

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 5
3.3 Tube information frame structure for protocol version 1
Data Tube Sorting Cap Extension Occurrences Target
type barcode rule color channel

Field Length Content

Data type 2 byte ‘BI’ for tube information frames
Tube barcode 12 byte Tube barcode, right aligned with leading ‘0’s (30hex)
Sorting rule 1 byte ‘0’ (corresponding to sorting rule 1) to ‘9’ corresponding to
sorting rule 10) for query frames ,
‘A’ (corresponding to sorting rule 1) to ‘J’ corresponding to
sorting rule 10) for announcement frames
Cap color 2 byte Decimally coded (‘00’ to ‘99’) cap color classification, ‘00’ if
color detection failed or cap color option is not installed
Extension 3 byte Always filled up with ‘0’s (30hex), reserved for future extensions
Occurrences 1 byte Number of occurrence of this tube barcode. ‘1’ for first
occurrence. ‘0’ if unknown. Only used with separate “m-u-t
Link” Software. If occurrences goes beyond 9, used character
is ‘0’ (30hex) plus occurrences.
Target channel 1 byte Always ‘0’ for query frames, ‘A’ to ‘Z’ for announcement of
tubes pushed into target bins, ‘0’ to ‘3’ for tubes placed into
racks by MK3 system

The sorting rule, cap color and target channel fields are available in HCTS firmware versions
2.5.008 and later. In earlier versions these fields are filled with ‘0’s (30hex). The occurrences
field is only used in communication between the “m-u-t Link” software and LIS. Without it,
the occurrences field is filled with ‘0’s (30hex).

Examples for data field content (Barcode ‘XY12345678’, sorting rule 2 selected, cap color
code 14, target bin C)
Protocol version 1 tube information query frame:
BI00XY1234567811400000
Protocol version 1 tube information announcement frame:
BI00XY12345678B140000C

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 6
3.4 Test requirements data frames
Test requirements data frames are sent from LIS to HCTS and contain a list of test codes
the HCTS uses to determine the target bin (or rack). Each test code is limited to 8
characters, the list may hold up to 25 test codes. It is also possible to determine the target at
the LIS side and send a frame with only one test code that actually is a target identifier.
The test requirements data frames also hold the tube barcode to enable the correct
allocation of the requirements list even if the LIS reponds to the HCTS queries in permuted
order.
Test codes may contain digits (‘0’ to ‘9’), all upper- and lowercase characters (‘A’ to ‘Z’ and
‘a’ to ‘z’) and the special characters '+', '-', '_', '=', '?' and '@'.

3.5 Test requirements frame structure for protocol version 1

Data type Tube barcode Extension Test #1 Test #2 ... Test #n

Field Length Content

Data type 2 byte ‘DW’ for test requirements frames
Tube barcode 12 byte Tube barcode, right aligned with leading ‘0’s (30hex)
Extension 28 byte Not evaluated by HCTS, reserved for future extensions,
should be filled with ‘0’s (30hex)
Test #1 ... N * 8 byte List of test codes (25 maximum), each test code may contain
up to 8 alphanumeric characters. Shorter test codes are
Test #n N
expanded to 8 characters with trailing blanks (20hex). No
between
delimiters are used to seperate the test codes.
0 and 25

Example for data field content (Barcode ‘XY12345678’, test codes “HBA1C”, “COTININE”
and “TSH”), the dot symbol ‘·’ denotes a blank (20hex)
Protocol version 1 test requirements frame:
DW00XY123456780000000000000000000000000000HBA1C···COTININETSH·····

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 7
4 High-Level Communication Protocol version 2

The high level protocol version 2 is available in HCTS firmware verions 2.3.061 and later.
For more information on differences of version 1 and 2 please refer to 1.3 Logical
connection.

4.1 Frame types

Four different frame types, coded in the frame identifier field (see 2.1), are used by the
HCTS:

Name Symbol Explanation

Enquiry E Sent from HCTS when the sort function is started. No data is
transmitted with this frame, the data field (see 2.1) is empty.
The function of this frame is to detect if the LIS is online.
Init I Sent from HCTS when the sort function is started after the enquiry has
been ACKed be the LIS. No data is transmitted with this frame, the data
field (see 2.1) is empty.
This frame informs the LIS that the HCTS has been started.
Data D This frame type is used for the acutal data transfer between LIS and
HCTS.
Only this type of frame differs for protocol versions 1 and 2 (see 1.3).
Stop S Sent from the HCTS when the sort function has been stopped (see
1.1). No data is transmitted with this frame, the data field (see 2.1) is
empty.

4.2 Tube information data frames

This type of data frame is used to send tube information from HCTS to LIS. It is transmitted
immediately after the HCTS has gathered all tube information despite that supplied by the
LIS (tube barcode, cap color and tube type) to request an order list from the LIS (query
frame).
If announcement frame transmission has been enabled (see 1.1), a tube information frame
is also sent by the HCTS whenever a tube is pushed into a target bin or placed into a rack by
the MK3 system (announcement frame).

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 8
4.3 Tube information frame structure for protocol version 2
Data Tube Sorting Cap Device
Delim. Delim. Extension Occurrences Target Delim.
type barcode rule color id

Field Length Content

Data type 2 byte ‘BI’ for tube information frames
Tube barcode 1 to 30 Tube barcode
byte
Sorting rule 1 byte ‘0’ (corresponding to sorting rule 1) to ‘9’ corresponding to
sorting rule 10) for query frames ,
‘A’ (corresponding to sorting rule 1) to ‘J’ corresponding to
sorting rule 10) for announcement frames
Cap color 2 byte Decimally coded (‘00’ to ‘99’) cap color classification, ‘00’ if
color detection failed or cap color option is not installed
Extension 3 byte Always filled up with ‘0’s (30hex), reserved for future extensions
Occurrences 1 byte Number of occurrence of this tube barcode. ‘1’ for first
occurrence. ‘0’ if unknown. Only used with separate “m-u-t
Link” Software. If occurrences goes beyond 9, used character
is ‘0’ (30hex) plus occurrences.
Target 1 byte Always ‘0’ for query frames, ‘A’ to ‘Z’ for announcement of
tubes pushed into target bins, ‘0’ to ‘3’ for tubes placed into
racks by MK3 system
Delimiter 1 byte A pipe symbol (‘|’, 7Chex) is used as delimiter
Device id 0 – 30 Optional. Name of the hcts device to discern different devices.
byte Only used with separate “m-u-t Link” Software
Delimiter 1 byte A pipe symbol (‘|’, 7Chex) is used as delimiter, if a device id is
given

As with protocol version 1, the sorting rule, cap color and target channel fields are available
in HCTS firmware versions 2.5.008 and later. In earlier versions these fields and the
extension, occurrences and device id fields are omitted. The occurrences and device id
fields are only used in communication between the “m-u-t Link” software and LIS. Without it,
the occurrences field is filled with ‘0’ (30hex), and the device id field is omitted.
Examples for data field content (Barcode ‘XY12345678’, sorting rule 2 selected, cap color
code 14, target bin C)
Protocol version 2 tube information query frame:
BI|XY12345678|11400000|
Protocol version 2 tube information announcement frame:
BI|XY12345678|B140000C|

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 9
4.4 Test requirements data frames
Test requirements data frames are sent from LIS to HCTS and contain a list of test codes
the HCTS uses to determine the target bin (or rack). Each test code is limited to 8
characters, the list may hold up to 25 test codes. It is also possible to determine the target at
the LIS side and send a frame with only one test code that actually is a target identifier.
The test requirements data frames also hold the tube barcode to enable the correct
allocation of the requirements list even if the LIS responds to the HCTS queries in permuted
order.
Test codes may contain digits (‘0’ to ‘9’), all upper- and lowercase characters (‘A’ to ‘Z’ and
‘a’ to ‘z’) and the special characters '+', '-', '_', '=', '?' and '@'.

4.5 Test requirements frame structure for protocol version 2

Data Del. Tube Del. Ext. 1 Del. Ext. 2 Del. Test Test ... Test Del.
type barcode #1 #2 #n

Field Length Content

Data type 2 byte ‘DW’ for test requirements frames
Tube barcode 1 to 30 Tube barcode
byte
Ext. 1 0 byte Not evaluated by HCTS, reserved for future use
Ext. 2 0 byte Not evaluated by HCTS, reserved for future use
Test #1 ... N * 8 byte List of test codes (25 maximum), each test code may contain
up to 8 alphanumeric characters. Shorter test codes are
Test #n N
expanded to 8 characters with trailing blanks (20hex). No
between
delimiters are used to seperate the test codes. For HCTS
0 and 25
firmware versions 2.6.011 and later the final delimiter
(following Test #n) may be omitted.
Del. 1 byte A pipe symbol (‘|’, 7Chex) is used as delimiter

Example for data field content (Barcode ‘XY12345678’, test codes “HBA1C”, “COTININE”
and “TSH”), the dot symbol ‘·’ denotes a blank (20hex)
Protocol version 2 test requirements frame:
DW|XY12345678|||HBA1C···COTININETSH·····|

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 10
5 Dataflow examples for Protocol version 1

5.1 Special characters:

· Blank (20hex)
<STX> Start-of-Text (02hex)
<ETX> End-of-Text (03hex)
<ACK> Acknowledge (06hex)

5.2 Initialization sequence (Start of sorting rule)

HCTS -> LIS <STX>·····E·07<ETX>
LIS -> HCTS <ACK>
HCTS -> LIS <STX>·····I·0;<ETX>
LIS -> HCTS <ACK>
If an online sorting rule has been selected and the tube announcement parameter in the
parameter file is set to 2, a second initialization sequence is sent by the HCTS:
HCTS -> LIS <STX>·····E·07<ETX>
LIS -> HCTS <ACK>
HCTS -> LIS <STX>·····I·0;<ETX>
LIS -> HCTS <ACK>
All ‘E’ – and ‘I’ – frames are only sent to provide a status information and may be ignored by
the LIS (apart from low level acknowledgement)

5.3 Termination sequence (HCTS stopped)

HCTS -> LIS: <STX>·····S·15<ETX>
LIS -> HCTS: <ACK>

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 11
5.4 Information transfer for each tube
Barcode ‘1234ABC5678’, sorting rule 4 selected, cap color code 5, target bin F, test codes
“CHOL”, “ T2” and “BILI_TOT”

HCTS -> LIS <STX>·····D·BI01234ABC567830500000;3<ETX>

LIS -> HCTS <ACK>
LIS -> HCTS <STX>·····D·DW01234ABC56780000000000000000000000000000
CHOL····BILI_TOT==<ETX>
HCTS -> LIS: <ACK>
Only if tube announcement is enabled the next frame is transmitted when the tube is pushed
into the target bin:
HCTS -> LIS <STX>·····D·BI01234ABC5678D050000F=:<ETX>
LIS -> HCTS <ACK>

For regular operation, the frame order can differ from that shown in the examples, as the
HCTS may send a query before the LIS has responded to the previous one. Tube
announcements are sent several seconds after receiving their order list due to the time
needed for tube transportation, so the order list and the announcement frames for a certain
tube are usually interleaved by numerous frames belonging to succeeding tubes.
It can not be ensured that the ACK (or NAK) is the first data transmitted by the HCTS after a
frame from the LIS has been received. If the HCTS has started sending a frame while
another frame comes in from the LIS, the transmit frame is sent entirely before the frame
received from the LIS is acknoledged (also see section 2.2).

5.5 Asynchronous protocol examples

Please refer to 6.5 Asynchronous protocol examples. The record flow for Protocol version 1
and 2 is identical. Only the data field layout is different.

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 12
6 Dataflow examples for Protocol version 2

6.1 Special characters:

· Blank (20hex)
<STX> Start-of-Text (02hex)
<ETX> End-of-Text (03hex)
<ACK> Acknowledge (06hex)

6.2 Initialization sequence (Start of sorting rule)

HCTS -> LIS <STX>·····E·07<ETX>
LIS -> HCTS <ACK>
HCTS -> LIS <STX>·····I·0;<ETX>
LIS -> HCTS <ACK>
If an online sorting rule has been selected and the tube announcement parameter in the
parameter file is set to 2, a second initialization sequence is sent by the HCTS:
HCTS -> LIS <STX>·····E·07<ETX>
LIS -> HCTS <ACK>
HCTS -> LIS <STX>·····I·0;<ETX>
LIS -> HCTS <ACK>
All ‘E’ – and ‘I’ – frames are only sent to provide a status information and may be ignored by
the LIS (apart from low level acknowledgement)

6.3 Termination sequence (HCTS stopped)

HCTS -> LIS: <STX>·····S·15<ETX>
LIS -> HCTS: <ACK>

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 13
6.4 Information transfer for each tube
Barcode ‘1234ABC5678’, sorting rule 4 selected, cap color code 5, target bin F, test codes
“CHOL”, “ T2” and “BILI_TOT”

HCTS -> LIS <STX>·····D·BI|1234ABC5678|30500000|?7<ETX>

LIS -> HCTS <ACK>
LIS -> HCTS <STX>·····D·DW|1234ABC5678|||CHOL····BILI_TOT|5=<ETX>
HCTS -> LIS: <ACK>
Only if tube announcement is enabled the next frame is transmitted when the tube is pushed
into the target bin:
HCTS -> LIS <STX>·····D·BI|1234ABC5678|D050000F|1><ETX>
LIS -> HCTS <ACK>

For regular operation, the frame order can differ from that shown in the examples, as the
HCTS may send a query before the LIS has responded to the previous one. Tube
announcements are sent several seconds after receiving their order list due to the time
needed for tube transportation, so the order list and the announcement frames for a certain
tube are usually interleaved by numerous frames belonging to succeeding tubes.
It can not be ensured that the ACK (or NAK) is the first data transmitted by the HCTS after a
frame from the LIS has been received. If the HCTS has started sending a frame while
another frame comes in from the LIS, the transmit frame is sent entirely before the frame
received from the LIS is acknowledged (also see section 2.2).

6.5 Asynchronous protocol examples

Barcode ‘1234ABC5677’, ‘1234ABC5678’, ‘1234ABC5679’, sorting rule 4 selected, cap color
code 5, target bin F, test codes “CHOL”, “ T2” and “BILI_TOT”
Checksums are not valid and replaced by ‘??’ in this example .
This example shows some specific data flow which is within the specification of the protocol
and not shown in the more simple examples before.

HCTS -> LIS <STX>·····D·BI|1234ABC5677|30500000|??<ETX>

LIS -> HCTS <ACK>
HCTS -> LIS <STX>·····D·BI|1234ABC5678|30500000|??<ETX>
Comment: HCTS continuous sending barcode information even though it is missing the test
requirements for the previous barcode record
LIS -> HCTS <ACK>

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 14
HCTS -> LIS <STX>·····D·BI|1234ABC5679|30500000|??<ETX>
LIS -> HCTS <ACK>
LIS -> HCTS <STX>·····D·DW|1234ABC5678|||CHOL····BILI_TOT|??<ETX>
Comment: LIS answers with test requirements in different order than it received the barcode
information
HCTS -> LIS: <ACK>
LIS -> HCTS <STX>·····D·DW|1234ABC5677|||CHOL····BILI_TOT|??<ETX>
HCTS -> LIS <STX>·····D·BI|1234ABC5678|D050000F|??<ETX>
Comment: Rather than ACKing the last test requirement record the HCTS sends an
announcement record since the flipping of the tube into the target occurs
asynchronously to the rest of the data flow
HCTS -> LIS: <ACK>
Comment: This is the Ack for DW record for barcode 1234ABC5677
LIS -> HCTS <ACK>
Comment: This is Ack for the Announcement record 1234ABC5678 from the HCTS
HCTS -> LIS <STX>·····D·BI|1234ABC5677|D050000F|??<ETX>
LIS -> HCTS <STX>·····D·DW|123<ACK>4ABC5679|||CHOL··
··T2······BILI_TOT|??<ETX>
Comment: LIS started to assemble the dw record for 1234ABC5679 when it received the
Announcement record for 1234ABC5677. It may embed the Ack into a
normal record (whereas the ACK is not included in the checksum
calculation).
HCTS -> LIS: <ACK>

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 15
7 Simple communication Example for LIS processing of HCTS messages

This code example demonstrates a simple approach to program the logic for the LIS data
handling of HCTS messages. It is valid for both protocol versions 1 and 2.

BEGIN

CONST DATA_FRAME = 1;

int receive(string *frame)

{
char ch;
static char buffer[];
static int i = -1;

if READ(RS232, ch) // check new incoming character on RS232

{
switch(ch)
{
case 'STX':
i = 0;
break;
case 'ETX':
copy (frame, buffer);
i = -1;
return DATA_FRAME;
case 'ACK'
return 'ACK'
case 'NAK'
return 'NAK'
default: // copy char to buffer
if (i >= 0) // copy char only if we received STX before
{
buffer[i] = ch;
i++;
}
// otherwise ignore received char
} // switch
}
return 0;
} // receive

void lis_hcts_communication()
{
TYPE FRAME_T = {String, time};
FRAME_T SEND_FRAME = {"", 0};
const TIMEOUT = 1 s;
int r;
string Frame, buffer;
int wait_for_Ack = false;

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 16
 int frame_received = false;

while(true) // endless loop

{
r := receive(buffer);

if (r == DATA_FRAME)
then
{
copy(Frame, buffer);
frame_received = true;
}

if (r == 'ACK')
then wait_for_Ack = FALSE;

if (r = 'NAK' AND wait_for_Ack)

then{
Send SEND_FRAME.string on RS232;
SEND_FRAME.time = current time;
}

if (frame_received and not wait_for_Ack)

{
// process received frame only if we got our last ACK
frame_received = false;
Calculate checksum of Frame
if (checksum NOT OK)
then Send 'NAK'
else{
Send 'ACK'
if (Frame Type is 'Data')
then {
if ('Sorting Rule' is in '0' .. '9') // Query Frame
then{
Evaluate list of tests for Barcode;
SEND_FRAME.string = Requirement Frame with
Data Type 'DW';
Send SEND_FRAME.string on RS232;
SEND_FRAME.time = current time;
Wait_for_Ack = true;
}
if ('Sorting Rule' is in 'A' .. 'Z') // Announcement Frame
then{
Process Announcement Frame
}
}
// ignore other Frame types
}
}

// check for timeout while waiting for Ack for last frame sent
if (wait_for_Ack == TRUE AND SEND_FRAME.time + TIMEOUT < current time)

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 17
 then{
Send SEND_FRAME.string on RS232;
SEND_FRAME.time = current time;
}

} // while
}//lis_hcts_communication
END

HCTS_LIS_Protokollbeschreibung_V2.6_EN.doc Seite 18