Nimbus Integration: TCP Backend and Interface Introspection #740
Conversation
cmoscy
commented
Nov 4, 2025
cmoscy
commented
- Added TCP I/O protocol with the Hamilton specific TCPBackend supporting Nimbus (and possibly Prep) specific communication and introspection through their IP->Harp2->Hoi2 protocol.
- Currently includes basics of instrument connection, introspection.
- Can use HamiltonCommand to construct message to run instrument commands while managing any responses received from the instrument.
…ugh Hamilton .NET firmware interface. TCP connection works through proxy to log direct communication.
- Added tcp_comlink_proxy for setup of Nimbus Comlink instance. Manages TCP communication through .NET firmware libraries - Removed setup.py in favor of pyproject.toml for package management. - Updated pyproject.toml with project metadata, dependencies, and optional dependencies.
- Updated `README.md` to include instructions for using the test notebook and requirements for DLL dependencies. - Introduced `dll_comlink_test.ipynb` to demonstrate TCP communication with Hamilton Nimbus instruments, including connection setup, module discovery, and pipettor operations. - Added `nimbus-connect-validation.json` as logging and validating TCP communication example - Fixed `firmware_assemblies.py` to load required Hamilton.Components.TransportLayer.Protocols.dll
…port - Introduced `tcp_codec.py` for Hamilton protocol communication, implementing a three-layer packet structure (IpPacket, Harp2, Hoi2) and associated message builders for command execution.
- Introduced a new Hamilton TCP backend with connection management, message routing, and command execution capabilities. - Implemented a layered architecture for the Hamilton protocol, including packet structures (IpPacket, HarpPacket, HoiPacket) and message builders (CommandMessage, InitMessage). - HoiParams for automatic DataFragment wrapping in command parameters.
- Added HamiltonIntrospection class for dynamic discovery of instrument capabilities (Thanks Piglet for showing that pattern). - Implemented commands for retrieving object interfaces, metadata, method signatures, enums, and structs. - Example in nimbus_connection_test.ipynb demonstrates finding an interface (Doorlock in this case), and then constructing the corresponding commands to check status, lock, unlock, etc.
1. Improved HoiParameter handling for more efficient use 2. Updated nimbus_connection_test.ipynb to show pipettor introspection, and initialization + park execution 3. Restored original project setup.py and pyproject files for consistency. 4. Moved all DLL related features to separate branch
|
My fault with the typing/linting. Cleaning this up and will update shortly |
|
it's fine to do those things last for linting but otherwise don't bother making tests pass every revision, it's more about content than style at this point |
|
do you think it would be possible to load some commands like aspirate and dispense and implement them in python in PLR? |
|
Got it! Was pretty minor to get it to pass. That's definitely possible! Primary bottleneck for me has been handling that Nimbus has several deck/waste block configurations. Pretty sure there's a way to detect a lot of this so there's no potentially dangerous assumptions made. Could add basic instrument control into a NimbusBackend pretty easily in the next 1-2 days (User would have to specify coordinates themselves until we get a deck layout defined). Tip pickup, drop, aspirate, dispense, initialization, and door control seem like a good minimal implementation? Anything else that would be worth prioritizing? |
|
those "big four" + setup are the most important, everything else is nice to have. appreciate it! for the stars the user has to specify some things about their deck layout, like where the core grippers are if they have them. after that it's just modeled through the universal resource model. we could have a similar thing for the nimbus deck = NimbusDeck(
trash_pos = "option a"
) |
…ecodes and displays command args and return values into their corresponding types.
|
Sounds good, thanks for the example. Checkpointed the cleanup and improved the introspection to help me put all that together next! |
…ls for testing. Example notebook with NimbusBackend Examples. ! Corrected message parsing for array types in HoiParamsParser.
- Added NimbusTipType enumeration for mapping tip types to Hamilton protocol commands. - Implemented InitializeSmartRoll, SetChannelConfiguration, PickupTips, DropTips, and DropTipsRoll commands for Nimbus backend. - Updated NimbusBackend setup process to include channel configuration and tip presence checks. - Enhanced NimbusDeck to create default long waste block and associated waste positions. - Improved error handling and logging for tip pickup and drop operations.
…handling - Added IsInitialized command to check if the instrument is initialized. - Updated NimbusBackend setup to include initialization status checks and conditional initialization of NimbusCore. - Introduced _build_waste_position_params method for constructing waste position parameters. - Enhanced error handling and logging during setup and command execution. - Updated NimbusDeck to store waste type for waste position lookup.
|
Almost there, work got busy but just some testing on aspirate and dispense left! |
|
man this is so fk cool |
2. Implemented parameter assignment and logging enhancements in Hamilton commands
Added logging to tcp_introspection commands
…. Logging included to show command with params.
|
Aspirate and dispense implemented! cLLD and pLLD params can be passed to the interface, but so far I've only validated fixed height operations on hardware. Example notebook run in nimbus-dev attached. Logging is verbose so you can see wired commands and their params easily. aspirate_dispense_demo.mp4 |
|
legend some high level comments:
|
|
Thanks for taking a look:
|
…Removed "TCP" - Implemented `read_exact` method in `Socket` - Moved error handling for connection closure and timeout scenarios to TCP Backend.
|
Swapped to the refactored "Socket" interface. Passes tests on my hardware and runs that same example notebook. Might give adding the CORE plate motion commands a go this week/weekend. But everything else is good to go / should pass gh tests. |
2 participants
