-
Notifications
You must be signed in to change notification settings - Fork 2
Communication layer likes and dislikes (protocol, new devices)
This page documents an "idealised" communication protocol for communicating with new sample environment drivers at ISIS. It is intended as a useful starting point if new protocols are being developed from scratch and as a set of nice-to-haves for new equipment being purchased.
This is the most common transport layer at ISIS. Serial settings are flexible in all of our drivers but the most common configuration is:
- Baud rate: 9600
- Data bits: 8
- Parity: None
- Stop bits: 1
- Flow control: Off
RS232 is preferable, RS422 and RS485 are avoided as far as reasonable. Note that distances can be extreme if higher baud rates are required.
Ethernet is a commonly used and well-supported transport layer at ISIS using RJ45 ports. Any other port type is to be avoided. It is also preferable that devices use DHCP to find their IP address rather than a static IP.
USB devices are difficult to implement for ISIS, and we prefer not to have to use USB wherever possible.
We prefer not to use these interfaces, however, in some cases, we may be able to work with these types of interfaces.
Modbus is more difficult for us than ASCII protocols but we can deal with this if absolutely necessary.
It is very helpful for devices to terminate their messages with a unique set of characters that do not appear elsewhere in the message. A common example of a terminator is a carriage-return line-feed pair (HEX: 0D 0A).
Commands to a device are ideally human-readable so that they can be used via terminal emulators. Many protocols use an ASCII encoding.
For example, a temperature controller might implement commands similar to the following:
Driver to device:
temp?<CR><LF>
(HEX: 74 65 6D 70 3F 0D 0A)
Device to driver:
temp=30.5<CR><LF>
(HEX: 74 65 6D 70 3D 33 30 2E 35 0D 0A)
All commands to a device should return some form of reply. This helps the control system to distinguish between a device which is unplugged and an incorrect or invalid command.
Where no data needs to be returned, a device could generate an "ACK" or "OK" or similar response. Commands which are invalid or rejected could return a "NAK" or "NOK" or "error" or similar responses.
We prefer not to receive unsolicited messages. It is better for a driver to explicitly ask for a parameter each time the driver wants to read it.