Galil Axis Stage Controller Agent for SO SAT Coupling Optics

[sanahabhimani]

Description

This PR adds a Galil DMC Axis Controller Agent, which provides motion control and readout for the Galil DMC motor controller. This agent was intentionally written for the hardware incorporated into the Simons Observatory SAT Coupling Optics system. When implemented in this way, the agent controls four axes—two linear and two angular—that move the hardware as needed to perform detector passband measurements.

Core updates involved:

• Implementation of driver functions for motion, position, torque, gearing control and more
• Added retry logic for Galil “?” responses
  • we occasionally received “?” responses from the motor controller in an unpredictable manner. While this issue occurred less frequently on the SAT Coupling Optics motor controller, most of the agent development was done using a spare Galil controller, where “?” responses to queries were much more common—so a retry mechanism was implemented to handle those cases.
• Added configuration file support for axis conversions (counts/mm, counts/deg)

Motivation and Context

Introduces a dedicated OCS agent for controlling the Galil DMC stage hardware used in SAT coupling optics measurements.

How Has This Been Tested?

Has been tested on physical hardware in and outside of a docker container.

Note on Integration Tests: Integration tests are still in development, and I’d love some help troubleshooting. At first, I ran into some Mac-related issues—but from past DAQ work, I know the Lakeshore240 and Radiometer tests have run fine on my local setup. When I started writing integration tests for this agent, even those familiar tests were failing, but after stabilizing my environment, I confirmed the issue is specific to this agent. So far, have only written one test --for the init task---and trying to debug before adding on more tests. I suspect the init test failure may be related to how the config file is being used, since the agent relies on it to set parameters and select which axes to publish, though I’m not entirely sure yet. There may also be additional features I need to mock up for the integration tests, which I’d like to brainstorm with the DAQ team. I haven’t pushed the test files yet since I’m still debugging locally, but can push them shortly.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

Miscellaneous Notes from Sanah

• This agent was developed based on existing code that had been handed down from an engineer at UChicago, who uses the same Galil control framework across multiple labs in the department. It wasn’t until later that I learned about the gclib Python package for the Galil motor. I suspect it wasn’t used originally because the engineer primarily operates from a Mac when assisting labs, and gclib isn’t macOS-friendly.
• However, I did take a brief detour to explore the use of gclib, since it’s used by the HWP socs agents. I set up a Windows VM on my Mac to test whether gclib could help address the “?” response issue, but it didn’t provide additional robustness or features that justified rewriting the driver I had already implemented.
• You’ll also note that I integrated the TCPInterface class into the device driver
• Some naming conventions could be improved. These motors will be used exclusively for the SAT Coupling Optics, so I’m unsure what the best instance ID naming convention should be when deploying to the site. There’s also some inconsistency between the directory name (galildmc_axis_controller) and the agent class name (GalilAxisController). But I'm also overall unsure if we want to name this more specifically for the SAT Coupling Optics (I doubt that given how we like to name agents after the specific piece of hardware we're commanding...)

[sanahabhimani]

Alright, as per my usual MO, I have evaded writing tests but am ready for re-review. Holler if tests are still preferred tho---happy to delineate into a separate PR for completeness' sake.

[davidvng]

Thanks, looks great, especially the added documentation. Just some small fixes.

[davidvng]

Great thanks! Will merge now.