Tecan EVO - Air LiHas

dev discussion
1

Is anyone using PLR with air lihas? I’ve been digging in again and with Claude’s help, ID’s a few issues that make the current backend incompatible with the air lihas.

Attached are claude’s analysis and implementation plans. The big change would be:

AirLiHa_Implementation_Plan.pdf (45.8 KB)

AirLiHa_Investigation.pdf (51.2 KB)

Recommended: EVOBackend Subclass (AirEVOBackend)

Rationale:

  • The Air LiHa differs from syringe LiHa in init sequence, conversion factors, and per-operation commands — these are all EVOBackend-level concerns

  • Subclassing keeps the existing EVOBackend completely untouched

  • Clean separation: syringe users use EVOBackend, air users use AirEVOBackend

  • The ZaapMotion configuration is specific to the Air LiHa hardware variant

  • TipType.AIRDITI already exists in the codebase — just needs liquid class data

Please reach out if you’re using the air liha, I’d appreciate your take. And if anyone has advice/guidance on if the new backend is the right approach, I’m all ears on that too.

2 Likes
2

not currently as far as I am aware

this is kind of a big ask and expanding the scope, but I believe it’s the most robust path: how about we use this opportunity to refactor the evo backend into the capability architecture?

a PIPBackend can be the superclass for LiHa AND AirLiHa which would be completely independent. Both would take driver: EvoDriver.

_aspirate_airgap and stuff shouldn’t really exist on the EVOBackend, we should put them on the LiHa classes.

3

ok. I’ll take a look at the v1b1 branch and see what I can get claude to do. I think i’ve just about got the air_liha subclass working on my local fork. There’s still a lot of emprical testing, but i can convert to the new capability model.

2 Likes
4

sweet! thank you so much!

don’t hesitate to post/reach out if there’s something I can help with. v1b1 is good enough for basic star stuff so should be fine, but definitely a bit of a Wild West right now :slight_smile: