ARTISTIC HEALTHCARE SEATING PTY LTD
Agilia Syringe Pumps
Agilia Connect Serial Export Protocols Various Agilia Models Revision List Feb 2015
Revision List
43 Pages
Preview
Page 1
Serial Export Protocol FOR AGILIA RANGE
Revision list Informations in this document only refer to devices belonging to the following devices: -
Agilia SP
-
Agilia SP MC
-
Agilia SP MC WIFI
-
Agilia SP TIVA
-
Agilia SP TIVA WIFI
-
Agilia VP
-
Agilia VP MC
-
Agilia VP MC WIFI
-
Agilia Link+
Date
Rev.
Feb, 20th 2015
0
Modifications First issue Subject to modification. Dedicated to :
th
Mar, 30 2016
2
1
-
Pump Software version v01.0
-
Link+ BW_rel_D11 software version
Change cover images to display Agilia V2 product
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
Table of contents 1.
INTRODUCTION ... 4
2.
PHYSICAL LINK ... 4
3.
2.1
SERIAL ... 4
2.2
TCP ... 4
DATA LINK ... 5 3.1
FRAME FORMAT ... 5
3.2
ENCODING ... 6 3.2.1 3.2.2
3.3
CRC8 ... 8
3.4
CRC16 ... 9
3.5
EXAMPLE OF COMPLETE FRAME ... 11
3.6
FRAME EXCHANGE ... 12 3.6.1 3.6.2 3.6.3 3.6.4
4.
DEFINITION ... 12 COMMUNICATION PARAMETERS ... 14 RECOMMENDED COMMUNICATION PARAMETERS ... 17 RECOMMENDATIONS WHEN USING PUMPS PLUGGED ON A LINK+... 17
APPLICATION LAYER – MESSAGE EXCHANGED ... 18 4.1
SESSION LAYER ... 18 4.1.1 4.1.2 4.1.3
START OF COMMUNICATION ... 18 END OF COMMUNICATION ... 18 ERRORS MANAGEMENT... 18
4.2
COMMANDS AND MESSAGES DESCRIPTION ... 19
4.3
PROTOCOL ... 20
4.4
DEVICE STATUS ... 22 4.4.1 4.4.2 4.4.3
DEVICE STATUS COMMON ... 22 DEVICE STATUS LINK+ ... 24 DEVICE STATUS PUMP ... 25
4.5
DEVICE INFORMATION ... 34
4.6
ADDITIONAL INFUSION INFORMATION ... 35 4.6.1 4.6.2
5.
UNITS ENCODING ... 6 DATES ... 7
ADVANCED DATA INFUSION READING ... 35 LIST OF DATAID ... 36
4.7
IP ADDRESS ... 38
4.8
ERROR CODES ... 39
4.9
TYPES OF VARIABLES ... 40
LOCAL CONTACTS FOR SERVICING ... 42
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
3
1.
INTRODUCTION
This guide is intended for the non-Fresenius Kabi personnel who want to communicate with the Agilia range devices. It describes the communication system used between a device and a host device (computer, …) and gives a list of all the available commands and information. In case of clustered architecture, the host can communicate with each of the devices via the Link+ accessory. The Link+ is fully transparent in the communication. The reliability of the communication system is based on the definition of 4 distinct communication layers:
A Physical Link Layer to describe the type of signals and their parameters.
A Data Link Layer to specify the character frame construction mechanisms.
A Session Layer through which communication is established.
An Application Layer which describes the syntax of the message exchanged between the two systems (host/device). This layer is the only visible one and it must be treated separately from the other ones. The application layer informs the errors detected by the other layers.
The following functions are available:
Setting (Silence alarm…)
Information request (Infusion status…)
2.
PHYSICAL LINK
The communication protocol can be used with the appropriate cable accessories only. Please refer to the IFU of the devices for the required accessory references.
2.1
Serial
The serial communication uses the standard following configuration (cannot be modified), when using a Link+ or directly to the pump:
Baud rate : 115200
Data bits : 8
Parity bit : no
Stop bit: yes (1 stop bit)
RTS (Request To Send) : enabled
DTR (Data Terminal Ready) : enabled
2.2
TCP
The TCP communication uses the standard following configuration, when using a Link+:
IP of the Link : configured in Link+’ Web Interface ( default 192.168.0.1 )
Protocol : TCP
Port : configured in Link+ Web Interface ( default 52000 )
See Link+ Technical Manual for further information.
4
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
3.
DATA LINK
3.1
Frame format
Whatever the transfer direction (Host to Device or Device to Host), the frames are always built as follow: START
TYPE
NO
ACK
SZ
CRC8
ID
DATA
CRC16
Description of the different fields of such a frame:
Type
Name
Description
BYTE BYTE BYTE BYTE BYTE
START TYPE NO ACK SZ
BYTE
CRC8
BYTE
ID
BYTES
DATA
WORD
CRC16
Start of frame : 0x1B (ESC) see Definition below Frame number (0x01..0xFF) Number of the last acknowledged frame (0x01...0xFF) Size of the ID and DATA fields CRC (8 bits) computed from the TYPE, NO, ACK and SZ fields Frame Id (if SZ is different from 0) Data: from 0 to 254 characters (if SZ is different from 0) CRC (16 bits) computed from the ID and DATA fields (if SZ is different from 0)
The data are systematically written using the big endian format.
Definition of field Type : For communication with:
Spontaneous Frames
Pump (direct Serial Connection)
Link+
Pump plugged on Link+
0x60 (‘`’)
None
0x61 (‘a’) : Pump 1 (lowest slot on Link+) … 0x68 (‘h’) : Pump 8 (upper slot on Link8+)
Standard Frames
0x40 (‘@’)
0x40 (‘@’)
0x41 (‘A’) : Pump 1 (lowest slot on Link+) … 0x48 (‘H’) : Pump 8 (upper slot on Link8+)
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
5
3.2
Encoding
3.2.1
Units Encoding
3.2.1.1
Regular Format
+----+----+----+----+-------------+-----------+---+-------+-------+---+ |
0 |
0 | dec|surf|
prefix
|
unit
| w | time
| dil.
|pla|
+----+----+----+----+-------------+-----------+---+-------+-------+---+ | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +----+----+----+----+-------------+-----------+---+-------+-------+---+
bit 0 : plasma : 0:1 : '/ml plasma' bits 1-2 : dilution : 0:1 : '/ml' 2 : '/l' 3 : '/Xml', a WORD that contains the volume of dilution is added after the unit bits 3-4 : time : 0:1 : '/min' 2 : '/h' 3 : '/24h'
6
bit 5 : weight : 0:1 : '/kg'
bit 12 : surface : 0:1 : '/m²'
bits 6-8 : unit : 0 : 'g' 1 : 'l' 2 : 'U' 3 : 'mol' 4 : 'cal' 5 : 'Eq' 6-7 : forbidden
bit 13 : number of decimal places : 0 : 2 decimals 1 : 3 decimals
bits 9-11 : prefix : 0 : 'p' 1 : 'n' 2 : 'µ' 3 : 'm' 4:5 : 'k' 6 : 'M' 7 : 'G'
bits 14-15 : always 0
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
3.2.1.2
Extended Format
+----+----+----+----+----+----+---+---+---+---+---+-------------------+ |
0 |
0 |
0 |
1 |
0 |
0 | 0 | 0 | 0 | 0 | 1 |
unit
|
+----+----+----+----+----+----+---+---+---+---+---+-------------------+ | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | +----+----+----+----+----+----+---+---+---+---+---+-------------------+
bits 0-4 : unit : 1 : flow drop/min, 1/1000 drop/min
bits 6-11 :
bits 13-15 :
always 0
always 0
bit 12 :
-
2 : pressure, mmHg 3 : pressure, kPa 4 : pressure, 1/10 PSI 5 : patient weight, g 6 : patient height, cm 7 : patient surface, 1/1000 m² 8 : patient age, mois 9 : dilution volume, ml 16 : patient gender 17 : duration, s bit 5 : always 1 (extended format)
3.2.2
always 1 (extended format)
Dates
Dates are encoded within 4 bytes (32 bits). The value corresponds to the number of seconds passed since January the st 1 of September 1970.
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
7
3.3
CRC8
The CRC8 is calculated for the header of every packet. The bytes computed are TYPE, NO, ACK and SZ fields, so the 4 bytes next to the start byte (ESC). START
TYPE
NO
ACK
SZ
CRC8
The algorithm use an array of 256 constants values and is described below : CRC = 0 FOR EACH byte_to_compute CRC = ConstArray[ byte_to_compute XOR CRC ]
Implementation in C : static const BYTE k_abyCrcArray[256] = { 0x00, 0x5e, 0xbc, 0xe2, 0x61, 0x3f, 0xdd, 0x83, 0xc2, 0x9c, 0x7e, 0x20, 0xa3, 0xfd, 0x1f, 0x41, 0x9d, 0xc3, 0x21, 0x7f, 0xfc, 0xa2, 0x40, 0x1e, 0x5f, 0x01, 0xe3, 0xbd, 0x3e, 0x60, 0x82, 0xdc, 0x23, 0x7d, 0x9f, 0xc1, 0x42, 0x1c, 0xfe, 0xa0, 0xe1, 0xbf, 0x5d, 0x03, 0x80, 0xde, 0x3c, 0x62, 0xbe, 0xe0, 0x02, 0x5c, 0xdf, 0x81, 0x63, 0x3d, 0x7c, 0x22, 0xc0, 0x9e, 0x1d, 0x43, 0xa1, 0xff, 0x46, 0x18, 0xfa, 0xa4, 0x27, 0x79, 0x9b, 0xc5, 0x84, 0xda, 0x38, 0x66, 0xe5, 0xbb, 0x59, 0x07, 0xdb, 0x85, 0x67, 0x39, 0xba, 0xe4, 0x06, 0x58, 0x19, 0x47, 0xa5, 0xfb, 0x78, 0x26, 0xc4, 0x9a, 0x65, 0x3b, 0xd9, 0x87, 0x04, 0x5a, 0xb8, 0xe6, 0xa7, 0xf9, 0x1b, 0x45, 0xc6, 0x98, 0x7a, 0x24, 0xf8, 0xa6, 0x44, 0x1a, 0x99, 0xc7, 0x25, 0x7b, 0x3a, 0x64, 0x86, 0xd8, 0x5b, 0x05, 0xe7, 0xb9, 0x8c, 0xd2, 0x30, 0x6e, 0xed, 0xb3, 0x51, 0x0f, 0x4e, 0x10, 0xf2, 0xac, 0x2f, 0x71, 0x93, 0xcd, 0x11, 0x4f, 0xad, 0xf3, 0x70, 0x2e, 0xcc, 0x92, 0xd3, 0x8d, 0x6f, 0x31, 0xb2, 0xec, 0x0e, 0x50, 0xaf, 0xf1, 0x13, 0x4d, 0xce, 0x90, 0x72, 0x2c, 0x6d, 0x33, 0xd1, 0x8f, 0x0c, 0x52, 0xb0, 0xee, 0x32, 0x6c, 0x8e, 0xd0, 0x53, 0x0d, 0xef, 0xb1, 0xf0, 0xae, 0x4c, 0x12, 0x91, 0xcf, 0x2d, 0x73, 0xca, 0x94, 0x76, 0x28, 0xab, 0xf5, 0x17, 0x49, 0x08, 0x56, 0xb4, 0xea, 0x69, 0x37, 0xd5, 0x8b, 0x57, 0x09, 0xeb, 0xb5, 0x36, 0x68, 0x8a, 0xd4, 0x95, 0xcb, 0x29, 0x77, 0xf4, 0xaa, 0x48, 0x16, 0xe9, 0xb7, 0x55, 0x0b, 0x88, 0xd6, 0x34, 0x6a, 0x2b, 0x75, 0x97, 0xc9, 0x4a, 0x14, 0xf6, 0xa8, 0x74, 0x2a, 0xc8, 0x96, 0x15, 0x4b, 0xa9, 0xf7, 0xb6, 0xe8, 0x0a, 0x54, 0xd7, 0x89, 0x6b, 0x35, }; BYTE Comm_CalcCrc8( const BYTE * i_pbyBuffer, int i_iSize ) { BYTE byCRC = 0; int i;
8
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
for (i=0 ; i<i_iSize ; i++) byCRC = k_abyCrcArray[ (i_pbyBuffer[i] ^ byCRC) ]; return byCRC; }
3.4
CRC16
The CRC16 is calculated for the data part of a packet if there is one. The bytes computed are ID and all data bytes, so it is the number of bytes indicated by the SZ field. START
TYPE
NO
ACK
SZ
CRC8
ID
DATA
CRC16
SZ bytes…
The public domain CRC algorithm used come from Ross Williams ([email protected]) and is dated 3 June 1993. This is the implementation (.c) file for the reference implementation of the Rocksoft^tm Model CRC Algorithm. For more information on the Rocksoft^tm Model CRC Algorithm, see the document titled “A Painless Guide to CRC Error Detection Algorithms” by Ross Williams. This document is likely to be in “ftp.adelaide.edu.au/pub/rocksoft”. The most recent home (2007) for Ross Williams documentation is : http://www.ross.net/crc/
The algorithm used is described below : CRC = 0 FOR EACH byte_to_compute CRC = ConstArray[(byte_to_compute XOR CRC) AND 0xff] XOR (CRC >>8)
Implementation in C: #define CRC_UPDATEBYTE16( i_byVal, i_wCrc ) (kg_crc_awTable16[((i_wCrc)^(i_byVal))&0xff]^((i_wCrc)>>8)) typedef unsigned long DWORD; WORD const kg_crc_awTable16 [256] = { 0x0000, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241, 0xC601, 0x06C0, 0x0780, 0xC741, 0x0500, 0xC5C1, 0xC481, 0x0440, 0xCC01, 0x0CC0, 0x0D80, 0xCD41, 0x0F00, 0xCFC1, 0xCE81, 0x0E40, 0x0A00, 0xCAC1, 0xCB81, 0x0B40, 0xC901, 0x09C0, 0x0880, 0xC841, 0xD801, 0x18C0, 0x1980, 0xD941, 0x1B00, 0xDBC1, 0xDA81, 0x1A40, 0x1E00, 0xDEC1, 0xDF81, 0x1F40, 0xDD01, 0x1DC0, 0x1C80, 0xDC41, 0x1400, 0xD4C1, 0xD581, 0x1540, 0xD701, 0x17C0, 0x1680, 0xD641, 0xD201, 0x12C0, 0x1380, 0xD341, 0x1100, 0xD1C1, 0xD081, 0x1040, 0xF001, 0x30C0, 0x3180, 0xF141, 0x3300, 0xF3C1, 0xF281, 0x3240, 0x3600, 0xF6C1, 0xF781, 0x3740, 0xF501, 0x35C0, 0x3480, 0xF441, 0x3C00, 0xFCC1, 0xFD81, 0x3D40, 0xFF01, 0x3FC0, 0x3E80, 0xFE41, 0xFA01, 0x3AC0, 0x3B80, 0xFB41, 0x3900, 0xF9C1, 0xF881, 0x3840, 0x2800, 0xE8C1, 0xE981, 0x2940, 0xEB01, 0x2BC0, 0x2A80, 0xEA41, 0xEE01, 0x2EC0, 0x2F80, 0xEF41, 0x2D00, 0xEDC1, 0xEC81, 0x2C40, 0xE401, 0x24C0, 0x2580, 0xE541, 0x2700, 0xE7C1, 0xE681, 0x2640, 0x2200, 0xE2C1, 0xE381, 0x2340, 0xE101, 0x21C0, 0x2080, 0xE041, 0xA001, 0x60C0, 0x6180, 0xA141, 0x6300, 0xA3C1, 0xA281, 0x6240, CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
9
0x6600, 0xA6C1, 0xA781, 0x6740, 0xA501, 0x65C0, 0x6480, 0xA441, 0x6C00, 0xACC1, 0xAD81, 0x6D40, 0xAF01, 0x6FC0, 0x6E80, 0xAE41, 0xAA01, 0x6AC0, 0x6B80, 0xAB41, 0x6900, 0xA9C1, 0xA881, 0x6840, 0x7800, 0xB8C1, 0xB981, 0x7940, 0xBB01, 0x7BC0, 0x7A80, 0xBA41, 0xBE01, 0x7EC0, 0x7F80, 0xBF41, 0x7D00, 0xBDC1, 0xBC81, 0x7C40, 0xB401, 0x74C0, 0x7580, 0xB541, 0x7700, 0xB7C1, 0xB681, 0x7640, 0x7200, 0xB2C1, 0xB381, 0x7340, 0xB101, 0x71C0, 0x7080, 0xB041, 0x5000, 0x90C1, 0x9181, 0x5140, 0x9301, 0x53C0, 0x5280, 0x9241, 0x9601, 0x56C0, 0x5780, 0x9741, 0x5500, 0x95C1, 0x9481, 0x5440, 0x9C01, 0x5CC0, 0x5D80, 0x9D41, 0x5F00, 0x9FC1, 0x9E81, 0x5E40, 0x5A00, 0x9AC1, 0x9B81, 0x5B40, 0x9901, 0x59C0, 0x5880, 0x9841, 0x8801, 0x48C0, 0x4980, 0x8941, 0x4B00, 0x8BC1, 0x8A81, 0x4A40, 0x4E00, 0x8EC1, 0x8F81, 0x4F40, 0x8D01, 0x4DC0, 0x4C80, 0x8C41, 0x4400, 0x84C1, 0x8581, 0x4540, 0x8701, 0x47C0, 0x4680, 0x8641, 0x8201, 0x42C0, 0x4380, 0x8341, 0x4100, 0x81C1, 0x8081, 0x4040 } ;
/*---------------------------------------------------------------------*/ /* Crc 16 Calculation
*/
/* - <i_pbyBuf> buffer address
*/
/* - <i_dwSize> buffer size (bytes)
*/
/* Out :
*/
/* - Crc16
*/
/* Calculation Crc : x16 + x15 + x2 + 1 (0x8005)
*/
/*---------------------------------------------------------------------*/ aWORD crc_C_Calc16( BYTE C* i_pbyBuf, DWORD i_dwSize ) { return crc_C_Update16( i_pbyBuf, i_dwSize, 0 ) ; } /*--------------------------------------------------------------------*/ /*--------------------------------------------------------------------*/ aWORD crc_C_Update16( BYTE C* i_pbyBuf, DWORD i_dwSize, aWORD i_wCrc ) { aBYTE byVal ; while ( i_dwSize != 0 ) { byVal = *i_pbyBuf++ ; i_wCrc = CRC_UPDATEBYTE16( byVal, i_wCrc ) ; --i_dwSize ; } return i_wCrc ; }
10
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
3.5
Example of complete frame 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ESC
@
00
00
0B
C0
70
01
08
08
00
13
88
4E
20
FF
FF
8C
68
Frame description (see frame 0x70 § 0 for the data description): 1
ESC
Start of the frame
2
@
Frame type: “classical” frame (not spontaneous)
3
00
Frame number = 0
4
00
Number of the last acknowledged frame = 0
5
0B
Size of the ID and DATA fields = 10 bytes
6
C0
CRC (8 bits) computed from the TYPE, NO, ACK and SZ fields
7
70
Frame Id = Opening/closing of a communication session (see § 0)
8
01
Frame Data: Mode = opening of a communication session in Full Duplex mode
9
08
Frame Data: Size of the host “window” of communication = 8 messages
10
08
11
00
12-13
13 88
Frame Data: Value of the PacketRepeatTimeout_ms 3.6.2.2)
14-15
4E 20
Frame Data: Value of the PacketMinRate_ms
16-17
FF FF
Frame Data: 3.6.2.3)
18-19
8C 68
CRC (16 bits) computed from the ID and DATA fields = 35944
Frame Data: Size of the device “window” of communication = 8 messages
Frame Data: Unused
Value
of
the
parameter (see §
parameter (see § 3.6.2.1)
DisconnectTimeout_ms
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
parameter
(see
§
11
3.6
Frame Exchange
3.6.1
Definition
Before any message exchange, it is necessary to open communication session with the device. Similarly, at the end of the dialogue, the communication session must be properly closed. However, some frames can be spontaneously sent by the device to the host out of a communication session. The Agilia devices periodically sends a Device status frame to the host when the communication session is closed. The exchange of frames follows an acknowledgement protocol based on a “window” mechanism that allows to transmit several frames before the first acknowledge is received. The number of frames of a “window” to transmit must be configured at the opening of the communication session. With this system, the frames can be acknowledged one by one (one acknowledgement frame sent for one frame received) or all together (one acknowledgement frame sent for all the frames received). If one frame of a “window” has not been acknowledged, all the frames that follows this frame in the “window” are repeated automatically. According to the type of frame sent by the host, the device can send a frame as a response but also either a list of frames or no frame at all. The device and the host have their own frame numbering. Example: window 4/4 Host sends frames 14, 15, 16, 17; Device answer with frames 7, 8, 9, 10. Example of the “window” mechanism with a “window” which contains 4 frames:
HOST
Frame1 Frame 1 Frame2
SERIAL LINK
DEVICE
PROCESSING
TX
Frame1 Frame 1 Frame2
Frame1 Reply1
Reply1 Ack1 Ack2
Frame3
Frame3 No Reply
Frame4
Frame4 Reply
RX
Frame3 Frame4
Reply1 Ack1 Ack2
Frame2 No Reply
Ack3 Reply4 Ack4
(the frames are acknowledged one by one)
Ack3 Reply4 Ack4
If the frame is empty (size = 0), the frame number is ignored and only the acknowledge number is taken into account. If a non empty frame (size > 0) with a frame number null is received, the list of received messages is flushed. 12
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
Same example in the case of a packet loss:
HOST
SERIAL LINK
Frame1 Frame 1 Frame2 Frame3 Frame4
DEVICE
RX
TREATMENT
TX
Frame1 Frame 1
Frame1 Reply1
Reply1 Ack1
Frame2 lost
Frame3 ignored Frame4 ignored
Reply1 Ack1
Automatic repetition of frames 2, 3 and 4
Frame2 Frame3 Frame4
Ack2
Ack2 Frame2
Frame2 No Reply
Frame3
Frame3 No Reply
Frame4
Frame4 Reply4
Ack3 Reply4 Ack4
Ack3 Reply4 Ack4
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
13
3.6.2
Communication Parameters
In order to maintain the connection between the host and the device, some parameters can be configured at the opening of the session. These parameters are used to configure disconnection of the communication and the repetition of the frames transmission.
Note :
Be very careful when configuring those parameters if you don’t want to have any trouble in the communication between the host and the device.
In the following paragraphs are described those parameters, and their recommended values in different configurations.
3.6.2.1
PacketMinRate_ms
If there is no communication between the host and the device during the time defined by PacketMinRate_ms, the host and the device send an empty frame to each other to maintain the connection.
HOST
ESC
@
DEVICE
03
… ESC
@
…
03
PacketMinRate_ms
Treatment of frame #03 ESC ESC
@
04
03
@
04
03
…
…
... ESC
@
00
03
PacketMinRate_ms
Transmission of a empty frame, without frame number, to maintain the connection. The last acknowledged frame number is inserted. …
The same for DEVICE
ESC
@
Time
14
00
…
Time
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
3.6.2.2
PacketRepeatTimeout_ms
Each frame that is emitted must be acknowledged. If the device which has emitted a frame has not received an acknowledgement before the end of the duration defined by PacketRepeatTimeout_ms, it emits the frame an other time.
Example of a communication without re-emission of the frame: HOST
ESC
@
DEVICE
01
00
… @
01
00
…
ESC
@
01
01
…
t
PacketRepeatTimeout_ ms
ESC
ESC
@
01
01
…
Reception of the acknowledgement of the frame #01 t < PacketRepeatTimeout_ms no re-emission of the frame
Time
Example of a communication with re-emission of the frame: HOST @
02
01
… ESC
@
02
01
…
ESC
@
02
01
…
t
PacketRepeatTimeout_ms
ESC
DEVICE
ESC
@
02
01
…
Reception of the acknowledgement of the frame #01 ESC
@
02
01
…
Re-emission of the frame
Time
t > PacketRepeatTimeout_ms re-emission of the frame
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
15
3.6.2.3
DisconnectTimeout_ms
If no data are received by the host from the device during the time defined by DisconnectTimeout_ms, the session is automatically closed.
HOST
ESC
@
01
02
00
01
…
ESC
@
01
00
…
ESC
@
02
01
…
ESC
@
01
00
…
ESC
@
02
01
…
…
PacketRepeatTimeout_ms
PacketRepeatTimeout_ms
DisconnectTimeout_ms
ESC
@
DEVICE
Bad CRC the frame is not taken into account (frame not acknowledged)
ESC
@
01
00
…
Re-emission of the frame #01
DISCONNECTION (CLOSING OF THE SESSION) ESC
@
02
01
Re-emission of the frame #02
…
Time Example of bad frame reception: incorrect CRC
16
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
3.6.3
Recommended Communication Parameters
The following values are recommended to have a robust communication: Parameter
Value
Host “window”
8
Device “window”
8
PacketMinRate_ms
20000ms
PacketRepeatTimeout_ms
3000ms
DisconnectTimeout_ms
60000ms
The PacketRepeatTimeout_ms ensures that a full “window” (almost 8*270 bytes) can be emitted even if the transmission time is long. The DisconnectTimeout_ms ensures that a packet can be re-emitted several times. The PacketMinRate_ms parameter is above the PacketRepeatTimeout_ms and below the DisconnectTimeout_ms.
3.6.4
Recommendations when using Pumps plugged on a Link+
The developed application/driver communicating with Agilia devices shall not exceed 10 frames per second, spread over the connected pumps, and mixing request or spontaneous messages. Examples: - If 1 pump is to be monitored : 10 requests on pump 1 - If 2 pumps are to be monitored : 6 requests on pump 1 and 4 requests on pump 2
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
17
APPLICATION LAYER – MESSAGE EXCHANGED
4.
The messages exchanged between the host and the device must respect the mechanism previously described to ensure a perfect comprehension of each other.
4.1
Session Layer
4.1.1
Start of communication
All communication between the host and the device must begin with the opening of a communication session between them (frame ID: 0x70). Any message sent before the session is opened generates an error message. Only the device can send spontaneous messages out of a communication session. These messages are not sent during the communication session. The emitted frames out of a communication session are not numbered (number of frame = 0)
4.1.2
End of communication
Similarly to the opening of a communication session, when the host wishes to end communication, it must close the communication session (frame ID: 0x70). The session is automatically closed in the following cases:
Physical disconnection of the device
No reply of the device during DisconnectTimeout_ms
4.1.3
Errors management
All errors are sent by the device to the host through a NACK frame (frame ID: 0xFF) whose one of the parameters indicates the type of error. This frame and all error codes are described later in the present document.
18
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
4.2
Commands and messages description
The commands are divided in 2 groups: those which are emitted by the device (DeviceHost) and those which are emitted by the host (HostDevice). These commands cannot be used in all the functional modes of the device. Here are the different functional modes in which the device can work:
Code (hexa)
Functional Mode
01
Idle mode : device in idle mode
02
the device is switched on
Here is the list of commands and messages:
ID (HEXA)
Description
PROTOCOL 70h
Request for opening/closing a communication session (HOST DEVICE)
F0h
Opening/closing a communication session (DEVICE HOST)
71h
Request for NOP (HOST DEVICE)
F1h
Reply for NOP (DEVICE HOST)
FFh
NACK (DEVICE HOST)
DEVICE STATUS 00h
Request for Device status information (HOST DEVICE)
80h
Device status information (DEVICE HOST)
5Fh
Request for Advanced Infusion Data (HOST DEVICE)
DFh
Advanced Infusion Data (DEVICE HOST)
40h
Request for device information (HOST DEVICE)
C0h
Device information (DEVICE HOST)
64h
Request for IP address (HOST DEVICE)
E4h
IP address (DEVICE HOST)
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc
19
4.3
Protocol
As described before, the session opening allows to specify the size of the communication “windows” and the value of the parameters used to configure the connection (PacketMinRate_ms, PacketRepeatTimeout_ms, DisconnectTimeout_ms…). The host send a frame to ask the device to open a session (frame ID: 0x70). Then, the device reply with a frame (frame ID: 0xF0) with the parameters of the connection established. These parameters are the real parameters. They can differ from those sent by the host. If the session cannot be opened, the device reply with a NACK frame (frame ID: 0xFF). A frame sent to open a session has its number set to 0. All the frames that have not been sent yet are lost. In a same way, all the frames that are waiting for a treatment by the device (even those received after the request for opening the session) are lost. A frame sent to close a session can have its number set to 0. In this case, all the frame that are waiting for a treatment are lost. On the other hand, if this number is different from 0, the frame will be taken into account only when all the previous frames will be treated. In the both cases, the reply is sent with a frame number set to 0 and all the frames that have not already been sent are lost.
FRAME ID: 0x70 – Request for opening/closing a communication session (HOST DEVICE)
Injectomat / Volumat / Link+ (version id=0x12): TYPE
Name
Description
BYTE
Mode
00 : Closing the session 01 : Opening session in Full duplex mode
BYTE
HostWindow
Size of the “window” of messages requested for the host (1..126)
BYTE
DeviceWindow
Size of the “window” of messages requested for the device (1..126)
BYTE
Unused
Shall be set to 0
WORD
PacketRepeatTimeout_ms
Value of the PacketRepeatTimeout_ms parameter in ms (1-65535)
WORD
PacketMinRate_ms
Value of the PacketMinRate_ms parameter in ms (0 deactivated, 1-65535)
WORD
DisconnectTimeout_ms
Value of the DisconnectTimeout_ms parameter in ms (1-65535, 0 forbidden)
20
CC9554-1_V2Y_SPEC_SW_Serial_Export_Protocol.doc