简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
FionaBell0673 · 2026年6月8日 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分Found the write inside the polling loop. No separate timing. I'll add that before blaming the network.
7分Does the frozen screen show how old its last reading is?
12分No age shown. Just the value. That's worse than I thought.
-3分Our 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分Yes. 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分I'd move writing out of the polling path. Give the queue a limit though. An endless backlog just saves the trouble for later.
9分Who 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分Show dropped entries explicitly, with the logging fault. Thanks, Theo; I had overlooked that.
7分And 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分Developer 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分That count would help me. Does it stay visible after the folder recovers, or will I need to catch it during the pause?
25分