remove unneeded commands from ThermocyclerBackend

[rickwierenga]

the following don't have to be methods of a thermocycler backend since there are ways to retrieve this data:

• get_block_target_temperature (by querying stage/step)
• get_lid_target_temperature (by querying stage/step)
• get_total_cycle_count (just cache running protocol)
• get_total_step_count (just cache running protocol)

[rickwierenga]

get_hold_time is vague

is it current or remaining?

it should be renamed

[codewithdaniel1]

Hi! I’m a student in the CodePath AI301 Open Source program and I’d like to work on this issue. I’ll start by tracing the ThermocyclerBackend interface and its implementations, then remove the unneeded methods and update any references or tests accordingly. Please let me know if there is a preferred migration approach for any existing callers.

[rickwierenga]

oh cool thanks for the interest!

at this stage, I think making this work on the v1b1 branch is best. See this thread: https://discuss.pylabrobot.org/t/updating-plr-api-for-machine-interfaces-discussion/445/. We are refactoring the APIs to be device-centric with different capabilities as attributes. This solves many problems (see the forum post for motivation). There isn't a thermocycling capability yet, so if you wanted to take a stab at that that would be awesome! This would be a good place to fix everything that's wrong with the current Thermocycler class, like what I described in this issue. The capabilities are based on the v0 frontend classes, but not necessarily identical. Doing it through that new branch would automatically provide a migration path. How does that sound? Happy to talk more :)

[codewithdaniel1]

Thanks for the context! I looked at the v1b1 branch and the capabilities folder. A few questions before I start:

1. Should I model thermocycling as a single ThermocyclingCapability class, similar to how TemperatureControlling works in capabilities/?
2. For the methods being removed (get_block_target_temperature etc.) — should these live purely as cached Python state on the capability (derived from the running protocol), or do some still need a hardware call?
3. For get_hold_time, should I rename it get_remaining_hold_time or get_current_hold_time?
4. Is there an existing thermocycler backend/device I should migrate as a concrete example, or should I just create the abstract capability and leave concrete implementations for later?

[codewithdaniel1]

Opened PR here: #1097

I kept this PR as a narrow cleanup against main based on the original issue scope, but I saw your note about v1b1 and the capabilities refactor. Happy to adjust direction or move future work toward v1b1 if that is preferred.