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

Response packet structure

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:

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