Ethernet control of Gamma vacuum quad ion pump controller

Disclaimer / Warning: Please note that this page is in no way associated with Gamma vacuum. Everything here has been discovered while hacking around with their product and might also be totally wrong, only partially complete or inaccurate. It just worked for us.

Introduction

This is a short blog post that describes on how to talk to Gamma vacuum ion pump controllers (in particular their QPC quad pump controller) using Ethernet to query parameters and adjust settings. Particularly we’re using this to monitor the pressure inside a vacuum chamber that has no additional pressure gauge.

There is some official documentation on the used protocol in some manuals - but that’s mainly oriented towards the serial (RS232 or RS485 / modbus) interface. To help ourself with development (and provide some kind of documentation for hacking around later on) I decided to write down our collected - incomplete - information.

Serial port command packet structure

As one can see they applied somehow everything required for a stable serial link though not being the most beautiful ASCII based protocol (I personally do prefer binary protocols so that doesn’t mean much):

• There is a synchronization pattern in form of the ASCII tilde (0x7E) that is used by the client to detect a potential packet start. This symbol does not occur anywhere except on packet start.
• Since the size of the packet is not known and not encoded there is an end of packet marker in form of the carriage return 0x0D. After the system has received the start of packet and end of packet marker it tries to verify the checksum that’s built by simply summing all bytes (in binary notation).
• To avoid any collisions with synchronization and termination patterns and to allow manual usage all numbers are encoded as ASCII Hex characters, arguments are separated by spaces

This protocol can be used either on RS232 or ModBus - in case of ModBus the configuration of the unit address is crucial. Any malformed packets are simply ignored by the device.

Request packet structure

Length	Content	Description
1 Byte	Start character	Always 0x7E
1 Byte	Space	Always 0x20
2 Byte	Address	Address of the device on the serial bus (RS485 / Modbus). 2 Hexadecimal ASCII characters.
1 Byte	Space	Always 0x20
2 Byte	Command	2 Hexadecimal ASCII characters
1 Byte	Space	Always 0x20
optional	Data fields	Data payload, always terminated by 0x20
2 Byte	Checksum	Add all fields exclude start, checksum and terminator modulo 256 - simply add and ignore overflow
1 Byte	Terminator	0x0D

Response packet structure

Length	Content	Description
2 Byte	Address	Address of the remote unit
1 Byte	Space	Always 0x20
2 Byte	Status	Literals OK or ER
1 Byte	Space	Always 0x20
2 Byte	Response code	2 Hex characters
1 Byte	Space	Always 0x20
optional	Data fields	Data payload, always terminated by 0x20
2 Byte	Checksum	Add all fields exclude checksum and terminator modulo 256 - simply add and ignore overflow
1 Byte	Terminator	0x0D

Ethernet (Telnet) Commands

The documentation for the Telnet protocol is not that good but orients itself at the serial protocol. It misses all of the synchronization patterns (Start character) as well as the checksums - it relies on TCP for that. It’s built around an interactive Telnet-like session without Telnet features. It’s just a TCP connection that shows an greater than sign > with code 0x3E whenever it accepts input. All commands seem to be prefixed by spc - which seems to stand for single pump controller - even for their quad pump controller. This has been the hard part to decode. Despite of this one can use the same commands as over the serial interface:

Command	Meaning	Sample request	Sample response	Comments
0x01	Get Model Number	spc 01	OK 00 DIGITEL QPC	Just some identification for the model
0x02	Get firmware version	spc 02	OK 00 FIRMWARE VERSION: 1.38	Identifies the firmware running on the pump controller
0x07	Master reset	spc 07	Not tried yet	Performs a full software reset
0xFF	Legacy master reset	spc FF	Not tried yet	Performs a full software reset
0x91	Set arc detect	spc 91 1 YES	OK 00	Sets the arc detection mode
0x92	Get arc detect	spc 92 1	OK 00 YES	Gets the arc detection mode (yes or no)
0x0A	Get current	spc 0A 1	OK 00 1.4E-06 AMPS	Reads the current currently flowing through the pump
0x0B	Read pressure	spc 0B 1 or spc 0B 2	OK 00 1.6E-08 MBAR	Gets the pressure reading calculated from the flowing current
0x0C	Read voltage	spc 0C 1	OK 00 6970	Gets the current applied voltage in volts (in the sample nearly 7 kV)
0x0D	Read supply status	spc 0D 1	OK 00 RUNNING 00 or for example OK 00 PUMP ERROR 00	A human readable string that’s also shown on the pump controller itself
0x0E	Set pressure units	spc 0E M	OK 00	Sets the unit to be used for pressure (M is millibars, T is torr, P pascal)
0x11	Get pump size	spc 11 1	OK 00 100 L/S	Reads the configured pump size.
0x1D	Get calibration factor	spc 1D 1	OK 00 1.00	Reads the calibration factor for pressure estimation
0x33	Set auto-restart	spc 33 1 YES	OK 00	Sets auto restart enabled or disabled
0x34	Get auto-restart	spc 34 1	OK 00 YES	Gets auto restart status
0x37	Start pump	spc 37 1	OK 00	Starts the specified pump
0x38	Stop pump	spc 38 1	OK 00	Stops the specified pump

Get Model Number (0x01)

The get model number command can be used to identify the type of the ion pump controller.

• Request: spc 01 followed by a carriage return 0x0d
• Example response: OK 00 DIGITEL QPC followed by two carriage returns and one linefeed (0x0d 0x0d 0x0a) - it seems someone just takes the response message from the serial port and appends an 0x0d 0x0a at the end.
  • This means the command succeeded (OK)
  • The response code is 00
  • And there are additional data arguments that reflect the product ID

Get firmware version (0x02)

The get firmware version command identifies the installed firmware.

• Request: spc 02 followed by a carriage return 0x0d
• Example response: OK 00 FIRMWARE VERSION: 1.38

Since I personally don’t know if this format might change in future my library tries to parse the last argument as MAJOR.MINOR version pair but also keeps the strings - the version is not checked by my personal implementations.

Master reset (0x07, 0xFF)

There are two firmware reset commands available - the legacy one 0xFF does exactly the same thing but is a remaining opcode from some older protocol versions.

• Request: spc 07 followed by a carriage return 0x0d
• Example response: OK 00

Set arc detection (0x91)

This enables or disabled arcing detection of the pump. If arc protection is enabled the ion pump controller reduces the voltage of the pump during arcing. It should usually be enabled.

• Request: spc 91 1 YES followed by a carriage return
• Example response: OK 00

Get arc detection (0x91)

Tells the status of arc detection (see above for a general description).

• Request: spc 92 1
• Example response: OK 00 YES

Read pressure (0x0B)

Reads pressure of the specified pump. The data field is the index of the pump (for example 1 or 2)

• Request: spc 0B 1 followed by a carriage return 0x0d (or for example spc 0B 2 for the second pump)
• Example response: OK 00 1.6E-08 MBAR.
  • The response again succeeded OK with code 00
  • The pressure value is written in scientific floating point notation in this case (1.6E-08)
  • The unit is millibars (MBAR)

Fetching pressure using Python

I’ve built a small Python module that’s also used by our labs environmental monitoring system to log data (and then visualize using Grafana). This module including an example program is available as a GitHub GIST.

In addition to this module an object oriented version has been developed that also includes a mini CLI utility for remote control of the QPC that’s also available on GitHub

This article is tagged:

• Python
• Physics
• Vacuum
• Hardware
• Measurements