Opentrons: bug: The timer doesn't start when the protocol run starts

[SyntaxColoring]

Splitting this issue out of #7167.

As reported by @ethanfjones there:

The protocol is running but the timer is not starting on the run. This event seems to happen more when a protocol is restarted vs on a fresh protocol upload.

Event 3.zip

[SyntaxColoring]

CPX should investigate the .zip file and see if we need any further info from Support.

[SyntaxColoring]

@Matt-Zwimpfer said he would look into this and try to find specific steps to reproduce.

[mcous]

Don’t know if it was an overnight protocol or something, but in the linked video, the app says the start time was 5:10 PM but the computer’s clock says the current time is 16:30 (4:30 PM). Seems reasonable that we’d have some code in there to default the time to 0:00 if the run time seemed negative for some reason.

No clue yet _how_ we got a negative run time though.

[SyntaxColoring]

in the linked video, the app says the start time was 5:10 PM but the computer’s clock says the current time is 16:30 (4:30 PM). Seems reasonable that we’d have some code in there to default the time to 0:00 if the run time seemed negative for some reason.

I confirmed that if I start a protocol and then manually set my laptop's system clock back by 1 hour, the run timer stays pegged at 00:00:00.

I also don't know how you could get into that condition under normal circumstances, though.

I tried running this protocol and going crazy with pauses, resumes, cancels, restarts, closing/reopening the app, and so on. But I couldn't reproduce.

metadata = {
    'apiLevel': '2.9'
}

def run(protocol):
    tip_rack = protocol.load_labware('opentrons_96_tiprack_300ul', 8)
    pipette = protocol.load_instrument('p300_multi_gen2', 'left')

    for i in range(10):
        pipette.pick_up_tip(tip_rack.rows()[0][0])
        pipette.drop_tip(tip_rack.rows()[0][-1])
        pipette.pick_up_tip(tip_rack.rows()[0][-1])
        pipette.drop_tip(tip_rack.rows()[0][0])

[ethanfjones]

Hmm, that is strange. The only other thing I could think of would be if the laptop was not connected to an external network and had the incorrect time when the protocol started, then they connected to a network when the protocol was running and the time was set correctly automatically.

This has not come up again and since we are unable to replicate this issues we can close this.

[SyntaxColoring]

If this comes up again, this info would help:

1. Full robot logs from journalctl, which I assume will include time synchronization events.
2. The current time and timezone on the user's computer, and whether it's set manually or automatically.
3. Whether the user has recently traveled with their computer or done anything else that could have affected its system clock.
4. Whether the problem happened near a leap second, transition to or from daylight savings time, or other weird time-related event.