
D397-30-880 Issue H
Page 2 © Edwards Limited 2012. All rights reserved.
Edwards and the Edwards logo are trademarks of Edwards Limited.
Introduction
1.2.3 Responses
Responses from the TIC contain either the data requested (=) or the status of the command (*). Note that for
commands such as Upload/Download, the action will continue after the response has been received. Also detailed
checking is performed by the objects themselves so a good response only guarantees that the message was accepted
by the serial communications, correct behaviour must be checked by querying the appropriate attribute. For example
write a setup, read it back and check the updates are as requested.
1.2.4 Setup
Some objects have more than one setup, for these objects the config type is sent and returned as the first parameter
in the data field.
1.3 DX, nEXT and nXDS pumps
The TIC will pass messages to the DX, nEXT or nXDS pump and return the replies. It limits some of the commands that
can be sent directly as the TIC must take account of setups and inputs connected to it. For example, if SYSI is set
into the fail condition; the turbo pump must not run so on/off commands directly to the DX, nEXT or nXDS are always
ignored, use the TIC turbo object instead.
Under a fault condition the DX and nEXT move through their state machines slightly differently. The TIC adjusts the
information from the nEXT so the TIC’s states move like the DX for both pump types. On fault the TIC shows both
pumps as fault braking until a stop command is issued. At this point the fault is cleared from the pump object 904
and the front panel.
When not using the TIC the main visible difference is that the DX clears its fault bits and fault LED when a stop
command is issued. The nEXT does not clear them until both a stop and then a start command are issued.
1.4 Communications timings
Because of the complexity of the product precise message timings are not defined, however, the following are
provided for guidance:
1.5 Object IDs
This sub-section summarises the protocol, based on the use of object IDs, to identify sources and destinations in
messages.
Objects can be physical items such as gauges and pumps, or virtual items such as software modules and data records.
Each object is allocated a unique identification number, although two instances of a particular item will both have
the same ID. In a message, the Object ID consists of 1 - 5 ASCII digits representing a number between 1 - 65535, as
shown below:
Data fields contain command codes, parameter values or response codes, and will vary in length and format according
to the message type. If there is more than one item in the data field, each item is separated by a semi colon(;).
Basic messages less than 100 mSecs
Messages to DX, nEXT or nXDS (dependent on DX or nEXT behaviour) less than 200 mSecs
Suggested timeout in master 500 mSecs
Upload Turbo (DX/nEXT) less than 2 secs
Download Turbo (DX/nEXT) less than 4 secs