It appears the Duration of 0.001 results in a 0 in the Duration field of the Protocol as read in Excel.

[ericweiner]

It appears the Duration of 0.001 results in a 0 in the Duration field of the Protocol as read in Excel. A Protocol will Run with a Duration of 0.001 if set at runtime and even Saved but cannot be reloaded. It displays the attached error message. It would be best to have hours:minutes:seconds for both Interval AND Duration. 1 second can be the minimum for both.

Originally posted by @EtalumaSupport in #567

[ericweiner]

Fix shipped -- ready for bench verification

Root cause: Sub-second durations (e.g. 0.001 h) were rounded to 0 in the Excel-readable TSV export. The protocol JSON kept the precision but the human-readable export lost it.

Fix: modules/protocol.py:358-359 -- increased duration rounding from 2 to 6 decimals so sub-second protocols round-trip through TSV correctly.

SHA: b89bce3 on 4.0.0-beta (current tip 4b972e9, 4.0.0-beta14 build).

Regression test: tests/test_protocol_roundtrip.py covers duration roundtrip.

Retest signal:

1. Create a protocol with Duration = 0.001 (or 0.0001).
2. Save the protocol; open the TSV in Excel.
3. Expected: the Duration field shows the actual value (0.001), not 0.
4. Reload the protocol in LVP -- duration is preserved.

EtalumaSupport, please download the latest beta build and verify the fix. Then either close this issue if fully resolved, or add a note describing what is still happening.

[ericweiner]

I don' t think this quite worked?

LVP_Log.zip

[ericweiner]

Ready for bench verification

The earlier rounding bump (b89bce3) stopped the save/reload crash, but a short Duration still reloaded + displayed as 0.0 -- the load path rounded to 2 decimal hours, so a 1s duration (~0.000278 h) showed 0.0.

Fix (minimal):

• floor_protocol_time enforces a 1-second minimum on both Interval and Duration (the 0 single-scan marker is preserved).
• the reload display now rounds to 6 decimals, so short values no longer collapse to 0.0.

SHA: 7df355d5 on 4.0.0-beta (tip a7ae4e36). Test: test_issue_568_protocol_time_floor.

Retest: set a short Duration (e.g. 0.001 h), save, reload in LVP -- it shows the actual value, not 0.0; values below 1s are clamped to 1s.

Note: decimal-hours is still awkward for short durations. The cleaner end-state -- H:M:S entry for Interval + Duration -- is tracked as a follow-up (not blocking this issue).

Eric, please verify on the next beta build.

[EtalumaSupport]

Saving a Protocol with 0.001 as Interval, making another Protocol with 10 Interval and saving it, then Loading the 0.001 Interval Protocol results in an Interval of 0.02 in the Interval field.