Tecan vs. Hamilton: Why Protocol Scripting Looks So Different Between Platforms

If you've worked across both Tecan and Hamilton liquid handlers, you've probably noticed that a protocol that takes twenty minutes to script in one platform's software can take an hour in the other — even for an equivalent assay. The difference isn't instrument quality. It's how each platform's scripting environment models a pipetting step.

EVOware: step-based, sequential

Tecan's EVOware treats a protocol as a literal sequence of discrete actions — aspirate, dispense, wash, repeat. This makes scripts easy to read top-to-bottom, but it also means that anything conditional (skip a wash step if a plate type is X, adjust volume if a reagent lot changes) has to be handled with separate sub-methods or variables threaded through manually.

VENUS: object- and method-based

Hamilton's VENUS, by contrast, leans on a more programmatic model with reusable methods, labware definitions, and class-like structures. This gives you more flexibility for conditional logic and parameterized protocols, but the learning curve is steeper, and a protocol that looks simple in EVOware's linear view can balloon into several interdependent VENUS methods.

What this means when porting a protocol

• Volume and tip-handling assumptions don't transfer 1:1. A wash cycle tuned for one platform's liquid class behavior will usually need re-tuning, not just re-typing.
• Labware definitions need to be re-validated, since plate and tip rack geometry files aren't interchangeable between EVOware and VENUS.
• Conditional steps need to be re-architected, not just translated line-by-line — EVOware's flat sequence and VENUS's method calls solve the same problem differently.

The practical upshot: porting a protocol between Tecan and Hamilton is closer to a rewrite than a translation. Budget time for re-validating liquid classes and labware on the target instrument rather than assuming a clean copy-paste.