The log gets busy and the status window goes quiet

I've put elapsed timings around each stage. Kept them in memory for the short test. The long gaps line up with writing, while the read call stays fairly steady.

Then you've got a useful suspect. Is the destination local, or are you making the display wait for a network share to feel cooperative?

Test the display against a slow writer too. Otherwise a nice quick local disk can make an unhealthy design look cured.

Fair point. Moving the folder might help today while leaving the same blocking write in the loop for the next machine.

It's a shared folder. I've made an offline test writer that delays, and the display freezes there too. So I can reproduce this without the controller connected.

Useful. Now whoever fixes it has something repeatable, instead of being told to wait beside the robot until the window sulks.

What will the window show if logging falls behind? Moving writes off the display thread helps, but somebody still needs to know whether the diagnostic history is complete. Not an alarm for every slow write, just a clear state.

Would a queued-count display help, or is that just another number nobody will understand?

I'd rather see 'logging delayed' and any lost-record count, with detail available to maintenance. Queue length alone needs context before it means anything to the operator.

Agreed. I've added logging delayed to the draft display, separately from the age of the last controller read. They're different failures even if both used to look like a stuck number.

The queued writer passes the slow-disk test now. We capped the queue and made lost diagnostic records visible. Still testing recovery when the share comes back before putting this on the workshop laptop.

How did the reconnect test go? That's usually when our harmless little diagnostics utility discovers a second career in eating memory.