Add Coherent HOPS / Verdi-G (Genesis CX-Vis) laser driver, DLL and native pyftdi

[dccote]

Summary

Use at your own risk: reverse-engineered without Coherent

Adds computer control for the Coherent Vergi G laser (the 532 nm pump). It presents as a "Verdi-G" but is actually a Genesis CX-Vis (head G532) on a HOPS (High Output Power Supply) whose USB is not a serial port: the FT2232 is driven as bit-banged I2C, so no serial framing ever answers. Two working control paths are provided for the same laser.

All the work here was obtained by reverse engineering the windows CohrHOPS.dll provided by Coherent. I want to use macOS or Linux, so I created this pure-Python version (with the help of Claude and no help from Coherent). Thank you to https://github.com/AllenNeuralDynamics/coherent-lasers which gave me critical information to get started. Using Claude is a great way of getting things done, but Claude is not the greatest for architecture, therefore I iterated several hours to get clean code that was easy to use and followed the PyHardwareLibrary strategy.

Why a driver is needed

You can't talk to the laser directly and send text commands for the Verdi G series. The computer reaches an FTDI FT2232 over USB, and that device is connected (through the I2C protocol) to other chips/devices (identified with a number 0x29, 0x48, etc...) that provide services or information; its channel A is an I2C master, and all control lives on that one I2C bus — power DAC 0x29, ADC 0x48, and the shutter/enable/remote I/O expander 0x25 in the supply, plus the head's identity/calibration EEPROM 0x52 across the umbilical, inside the laser head. There is no serial/host path to the head, so every command must speak HOPS: through Coherent's CohrHOPS.dll, or natively over pyftdi I2C.

Strategy

For the details on how I reconstructed from the sniffed I2C traffic; see hardwarelibrary/manuals/Coherent-HOPS-3-I2C-Wire-Protocol.md.

Since I had a working Windows DLL, I used AllenNeuralDynamics code to talk to the Verdi, but I intercepted the calls and dumped the parameters of the functions that were called. This allowed me to decode the ASCII commands and the corresponding I2C devices/registers to create a Pure-Python version without the need for this Windows-only, binary, proprietary-for-no-reason DLL.

Since everything goes through the High Output Power Supply (which I suppose is a very general device that Coherent reuses on many systems and then connects various things through I2C to it), the trick is to create a "HOPS Interface" using either the coherent-provided DLL or pure-Python. Then the LaserSourceDevice:VerdiGDevice creates one or the other, and will use the appropriate one but will otherwise be unaware of the details.

What's added

• sources/verdig.py — VerdiGDevice (+ DebugVerdiGDevice) and the abstract
  HOPSInterface. VerdiGDevice combines OnOff / Shutter / Power / Interlock and
  delegates every hook to whichever transport it holds;
  VerdiGDevice(interface="auto") tries native first, then the DLL (or force one
  with "native" / "dll" / an instance).
• sources/hopsnative.py — HOPSNativeInterface (+ HOPSNativeI2C,
  MockHOPSBus): the pure-Python pyftdi I2C transport, no DLL, so the laser
  runs natively on macOS/Linux.
• sources/hopsdll.py — HOPSDLLInterface (+ the CohrHOPS ctypes
  binding): the transport over Coherent's CohrHOPS.dll (Windows/Linux).
• manuals/ — a HOPS USB-protocol reference; a reproducible runbook for the
  macOS-writes / Windows-runs / Parallels workflow used to reach the laser; a
  decode of the HOPS I2C protocol sniffed with a logging CohrFTCI2C.dll proxy;
  and the bus diagram (SVG + PNG).
• Tests — testVerdiG.py: 22 tests (the 3 hardware tests skip when no laser is attached).

Verification status

• Native path (HOPSNativeInterface, the default): hardware-confirmed end to
  end on the lab Genesis CX-Vis via interface="auto" (identity, on/off,
  shutter, remote write+read, power setpoint, power=0, temperature).
• DLL path (HOPSDLLInterface): hardware-confirmed for the read path and the
  REM/PCMD write path; the emission-enable (KSWCMD) and shutter (SHCMD)
  writes are per the DLL spec but not yet exercised.
• Documented gaps (not yet reverse-engineered) on the native transport: the
  full ?FF fault/interlock decode, ?PLIM, and the ADC power-read scale — so
  VerdiGDevice keeps InterlockControl in its capabilities but interlock() /
  faults() raise HOPSInterface.NotSupported on native, and the temperature
  calibration is a two-point fit valid only ~32-40 C.

Notes

• pyftdi claims the FT2232 on macOS/Ventura without unloading Apple's VCP driver. This is new: if you are running on an older OS, this will fail.
• The vendor DLLs, capture logs, and reverse-engineering prototypes live in a gitignored scratch-hops/ and are intentionally not part of this PR.
• The untested Verdi V-series (V-2/V-5/V-6) RS-232 driver was intentionally left out: no such hardware is available to validate it.

Generated with Claude Code
https://claude.ai/code/session_01841beMNdCw3zYf6fdBUoy7