fix(app,api): Display thermocycler profile cycles

[sfoster1]

We identified a simple bug with the app: it displays wonky numbers for thermocycler profile cycles:

This wouldn't repeat anything at all, what's going on?

Well, it turns out that when Protocol Designer added thermocycler support, they wanted something a bit more in depth than the Python protocol API's "list of steps, number of times to repeat the cycle" format. They wanted users to be able to add single steps and cycles, in arbitrary order.

To make the two styles work with the engine, we made the engine's thermocycler/runProfile command take a flat list of steps - any of the structure of repeated commands was removed. In the app's CommandText display, we then had to fix up the way we displayed profiles to remove references to a repetitions value that now didn't exist... and we just didn't, instead setting the repetitions element to just be the number of steps in the profile.

Fixing this ended up being a bit involved.

summary

• ad17260 Make a new interface for the hardware controller execute_profile function of the thermocycler, since it's important that thermocycler cycles execute inside an asyncio worker so that they won't be interrupted by e.g. pausing. This new interface takes the PD style of protocol. It relies under the hood on the same function that actually sends stuff to the thermocycler, so there shouldn't be any functional execution changes.
• 335e25a Make a new thermocycler/runExtendedProfile command in the protocol engine, that takes as its parameters a structured list of either steps or cycles, adhering to PD's expectations since the PAPI's expectations are a strict subset of PD. This implements its command by using the new hardware controller.
• e842a2a Use the new structured data to implement a command text for the new command that can render the equivalent of what PD makes (and, again, what the PAPI does, which is a strict subset)
• e842a2a Also make the old command text not use a "repetitions" keyword that doesn't exist
• 0043ab7 Switch the PAPI to emitting the new command in api 2.21

new UI

These UI changes will be on https://s3-us-west-2.amazonaws.com/opentrons-components/rqa-2771-thermocycler-extended-profiles/index.html?path=/docs/app-molecules-command-commandtext--docs for the desktop and general text and https://s3-us-west-2.amazonaws.com/opentrons-components/rqa-2771-thermocycler-extended-profiles/index.html?path=/docs/app-molecules-command-command--docs for the ODD colored-background elements whenever they upload. Here's a screenshot of what they were like when the PR was opened:

CommandText of thermocycler/runProfile :

Note the change to the first line. This needs wordsmithing.

CommandText of thermocycler/runExtendedProfile:

Note the two-level rendering. The common case will probably be that there's only cycles

todo

• wordsmith
• [ ] add to PD? no, but structured in a way that it will be easy eventually
• Test. Oh boy

Closes RQA-2771

[sfoster1]

After those latest fixups, a protocol like this displays as above:

requirements = {
    "robotType": "Flex",
    "apiLevel": "2.21"
}

def run(ctx):
    tr = ctx.load_labware('opentrons_96_tiprack_1000ul', 'D2')
    instr = ctx.load_instrument('flex_1channel_1000', 'left', tip_racks=[tr])
    tc = ctx.load_module('thermocyclerModuleV2')
    tc.load_labware("nest_96_wellplate_100ul_pcr_full_skirt")
    tc.close_lid()
    tc.execute_profile(
        steps=[{'temperature': 30, 'hold_time_seconds': 10},
         {'temperature': 50, 'hold_time_minutes': 1},
         {'temperature': 60, 'hold_time_seconds': 15}],
        repetitions=5,
        block_max_volume=100
    )
    instr.pick_up_tip()
    instr.return_tip()

with the following M104 (set temp) commands for the first couple reps of the profile

Oct 04 13:41:26 002504 opentrons-api-serial[324432]: /dev/ot_module_thermocycler1: Write -> b'M104 S30.0 H10.0 V100.0 \r\n'
Oct 04 13:41:41 002504 opentrons-api-serial[324432]: /dev/ot_module_thermocycler1: Write -> b'M104 S50.0 H60.0 V100.0 \r\n'
Oct 04 13:42:54 002504 opentrons-api-serial[324432]: /dev/ot_module_thermocycler1: Write -> b'M104 S60.0 H15.0 V100.0 \r\n'
Oct 04 13:46:58 002504 opentrons-api-serial[324432]: /dev/ot_module_thermocycler1: Write -> b'M104 S30.0 H10.0 V100.0 \r\n'
Oct 04 13:47:51 002504 opentrons-api-serial[324432]: /dev/ot_module_thermocycler1: Write -> b'M104 S50.0 H60.0 V100.0 \r\n'
Oct 04 13:49:03 002504 opentrons-api-serial[324432]: /dev/ot_module_thermocycler1: Write -> b'M104 S60.0 H15.0 V100.0 \r\n'

[sfoster1]

A test PD protocol using the old command now looks like this:

so at least it says the correct number of things
tc test.json

[SyntaxColoring]

The backend bits all look good to me, as discussed in Slack and on a call. TY!

[sfoster1]

The same protocol but manually modified to use the new command. Here's the protocol; it implements the same thing as the previous protocol but using the real command. Don't try and view this in PD though

https://github.com/user-attachments/files/17260291/tc-test-extended.json

[mjhuff]

App side looks good! Thanks for tackling this one...definitely not the innocuous UI bug as it first seemed.

Oh yeah, and thanks for adding the new commandText kind

[ncdiehl11]

Assessing this from a PD perspective, this looks good and shouldn't cause a big headache on our end. The main implication will be in thermocyclerFormToArgs to maintain a cycle profile step's dimensionality (and repetitions property) rather than flattening it into its comprising steps.

[ncdiehl11]

👍

[ecormany]

🫡 🔡 ⚒️ wordsmith reporting for duty

[ecormany]

It's good timing for wordsmithing here, because I'm taking a look at our other command text across PD and opentrons_simulate as well.

My suggestions here are based on these general factors:

• We prefer "-ing" forms of verbs (which are present here already).
• We generally describe steps as doing something to a module (direct object) rather than as the module doing something (subject). The existing TC step is an outlier in that regard.

In addition, I think that the top level should look very similar regardless of whether it has the flat or embedded structure.

Suggested change

	"tc_starting_extended_profile_cycle": "A cycle of {{repetitions}} repetitions of the following steps:",
	"tc_starting_extended_profile": "Thermocycler starting {{elementCount}} element profile composed of the following elements:",
	"tc_starting_profile": "Thermocycler starting {{stepCount}} step profile composed of the following:",
	"tc_starting_extended_profile_cycle": "{{repetitions}} repetitions of the following steps:",
	"tc_starting_extended_profile": "Running thermocycler profile with {{elementCount}} total steps and cycles:",
	"tc_starting_profile": "Running thermocycler profile with {{stepCount}} steps:",

Something about line 74 strikes me as very "here is some data" instead of plain English, too. Pros and cons of going with something like "{{seconds}} seconds at {{celsius}}°C" instead:

• It sounds more like a human.
• Except it counts everything in seconds, and these could be long spans of time. Pop quiz: how long is 2700 seconds? Hours, minutes, seconds would be cool but probably a refactor for another day.
• Variable length cycles will make the output less tabular, and potentially harder to scan.

Bare minimum let's capitalize the T in Temperature, either in the string or with a transformation.

[sfoster1]

I like the suggested changes and will apply.

I think for changing the individual step texts, definitely sentence capsing, but I agree about the variable length thing, and temperatures should be a lot less variable.

For timestamps, we can pretty trivially transform them to nicer durations - do you prefer mm:ss, [mm minutes ] ss seconds, something else?

[ecormany]

Two unambiguous options:

• 0:01:02
• 0h 01m 02s

Even though it raises the question of "does this need to be i18n'd?" I like including the literal text h, m, s because it reduces mental burden of going "wait, which units is that colon separating?"

[sfoster1]

yeah, I agree, and yeah, it would need to be i18n'd but that's just incremental work and c'est la vie. Will do!

[sfoster1]

So that will be Temperature: {temperature}°C, hold time: {hh}h {mm}m {ss}s? Something else?

[sfoster1]

Actually, since it looks like we use durations in other places that we'll have to fix, let's just specify it as a duration in the i18n strings

[sfoster1]

@ecormany ok here's where we are now, what do you think

for extremely long times, hours will just be extended - so you'd have 25h, not 1d 1h

[ecormany]

for extremely long times, hours will just be extended - so you'd have 25h, not 1d 1h

I think if anything, times will tend to be on the short side of an hour. Nit, but a single 0 instead of 00 would probably suffice for any sub-hour time. If you get ragged text because you have a step that exceeds 10h, so be it.

[sfoster1]

How's this @ecormany

[ecormany]

Command text is good. 🚢