FionaBell0673 · 8 Jun 2026, 15:35 UTC
Time the write and the status request separately. Otherwise a slow disk gets to impersonate a robot fault, which is a fairly expensive disguise.
7 pointsFound the write inside the polling loop. No separate timing. I'll add that before blaming the network.
7 pointsDoes the frozen screen show how old its last reading is?
12 pointsNo age shown. Just the value. That's worse than I thought.
-3 pointsOur display once kept a green status through a disconnected cable. Showing the last update time made that obvious; does yours have room beside the value?
12 pointsYes. Added age to the draft screen. Timing capture also shows long file writes during two pauses. Status reads weren't slow in those two.
21 pointsI'd move writing out of the polling path. Give the queue a limit though. An endless backlog just saves the trouble for later.
9 pointsWho gets told if that queue fills? I do not want to be the person collecting a whole shift of useful diagnostics and finding an empty file at handover.
6 pointsShow dropped entries explicitly, with the logging fault. Thanks, Theo; I had overlooked that.
7 pointsAnd decide whether a full queue drops old entries or new ones. Both lose something. The person reading the log needs to know which history survived.
20 pointsDeveloper has a bounded writer queue in the test build. It drops new diagnostic entries when full and shows the count. Slow-folder replay keeps the display updating. Network delay test still outstanding.
13 pointsThat count would help me. Does it stay visible after the folder recovers, or will I need to catch it during the pause?
25 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.