Edwards and the Edwards logo are trademarks of Edwards Limited.
D397-30-880 Issue H
CAUTION
1Introduction
1.1Scope
This manual provides Operation instructions for serial interface communications to the Edwards Turbo Instrument
Controller product range, part numbers:
DescriptionItem Number
TIC Instrument ControllerD397-00-000
Before using these instructions, ensure that you have a good understanding about the operation of the
controller.
Introduction
1.2Message basics
The communications to the TIC work on a master/slave principle. The TIC is the slave and will only transmit a message
in response to one sent to it. The master, a PC for example, must always start the conversation.
A conversation consists of a message to the TIC and its response b ack. Having sent a message to the TIC, wait for the
reply before continuing.
There are two basic types of message sent to the TIC:
Command sending information to the TIC (!).
Query requesting information from the TIC (?).
All messages end with a carriage return.
In multi-drop mode, the ? and ! are preceded by the addressing information.
Characters not enclosed by start (!?) and end (cr) characters will be ignored. Incomplete messages will be ignored if
a new start character is received.
1.2.1Commands
Commands send information to the TIC. These can be literal commands such as 'turn pump on' or setups to be stored
by the TIC. Setups hold information about how the TIC should behave such as the conditions under which the vent
valve should open.
1.2.2Queries
Queries request information from the TIC. These can be direct queries of the value of a parameter such as pump
speed, or reading the setup value currently in the TIC.
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 guara ntees 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 requ ested.
1.2.4Setup
Some objects have more than one setup, for these objects the config type is sent and returned as the first paramete r
in the data field.
1.3DX, 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 pum p 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.4Communications timings
Because of the complexity of the product precise message timings are not defined, however, the following are
provided for guidance:
Basic messagesless than 100 mSecs
Messages to DX, nEXT or nXDS (dependent on DX or nEXT behaviour)less than 200 mSecs
Suggested timeout in master500 mSecs
Upload Turbo (DX/nEXT)less than 2 secs
Download Turbo (DX/nEXT)less than 4 secs
1.5Object 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(;).
Edwards and the Edwards logo are trademarks of Edwards Limited.
D397-30-880 Issue H
A returned response code consists of 1 or 2 characters representing a number between 0_99. A code of '0' always
means 'OK'. Other codes can be used to indicate various error conditions:
Where several items are linked together using multiple RS232 lines radiating from a hub, a 'multi-drop' identifier is
prefixed to each message. It is composed of a '#', followed by a 2 character Destination ID, a colon, and a 2 character
Source ID:
1.6TIC serial protocol messages
GENERAL COMMAND
NORMAL (or ERROR) RESPONSE
Introduction
NORMAL (or ERROR) RESPONSE
1.6.1TIC serial protocol - multi-drop prefix to a message
SETUP COMMAND
QUERY SETUP
ERROR RESPONSE
NORMAL RESPONSE
QUERY VALUE
ERROR RESPONSE
NORMAL RESPONSE
1.6.2PC serial
This covers operations specific to the PC serial link covering control, monit orin g a n d se tup of all sections of the TIC
and the attached pumps.
Objects in the DX, nEXT or nXDS pump can be read via the TIC at their normal object ID and the TIC will pass the
messages on and return the reply, refer to DX, nEXT or nXDS requirements Section 1.3. Wait for the reply before
sending in another message even if the new message is for the TIC or 'other' pump.