-
Notifications
You must be signed in to change notification settings - Fork 119
Nimbus Integration: TCP Backend and Interface Introspection #740
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
cmoscy
commented
Nov 4, 2025
- 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.