Skip to content

Conversation

@cmoscy
Copy link

@cmoscy cmoscy commented Nov 4, 2025

  1. 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.
  2. Currently includes basics of instrument connection, introspection.
  3. Can use HamiltonCommand to construct message to run instrument commands while managing any responses received from the instrument.

cmoscy and others added 18 commits August 6, 2025 23:22
…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
@cmoscy
Copy link
Author

cmoscy commented Nov 5, 2025

My fault with the typing/linting. Cleaning this up and will update shortly

@rickwierenga
Copy link
Member

it's fine to do those things last

for linting make format might do a lot easily

but otherwise don't bother making tests pass every revision, it's more about content than style at this point

@rickwierenga
Copy link
Member

do you think it would be possible to load some commands like aspirate and dispense and implement them in python in PLR?

@cmoscy
Copy link
Author

cmoscy commented Nov 5, 2025

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?

@rickwierenga
Copy link
Member

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"
)

cmoscy and others added 2 commits November 4, 2025 20:43
…ecodes and displays command args and return values into their corresponding types.
@cmoscy
Copy link
Author

cmoscy commented Nov 5, 2025

Sounds good, thanks for the example. Checkpointed the cleanup and improved the introspection to help me put all that together next!

cmoscy and others added 4 commits November 4, 2025 20:56
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants