I need a cheap way to locate this delay before blaming the network. Since I enabled detailed logging, my UR5e inspection-status display sometimes stops refreshing while its log folder is busy. This is the telemetry desk, separate from cell controls. I suspect file writes, but communication delay is still possible.
The developer added a small in-memory timing trace. During one pause the response had arrived, then the file write occupied the same thread before the display update. That supports the logging suspicion for that occurrence, not every pause.
Show the reading's age independently of whether a new reading has arrived, otherwise the display can keep its old healthy-looking colour precisely when it has stopped learning anything.
Don't just switch logging off and call it done. Sorry, I mean that as a limit on any comparison, not something Ravi said he'd done. You still need diagnostics afterwards.
The proposed change writes logs in a background worker with a bounded queue. The display keeps its own update path and shows the age of the last received value. We are testing slow storage before using it as the normal desk monitor.
Give the logger its own health indication, separate from status freshness. A trainer should be able to explain that values may be current while the log has gaps, and that a healthy logger does not prove a fresh controller response.
Offline delay tests passed for both paths. Slow writing leaves the display responsive; queue overflow raises a visible diagnostic-gap count. A delayed status response makes the reading age visibly without being relabelled as a new result. The trace still records the separate timings.
Check the ordinary launch and loss of the log destination as well. Those are the conditions the next shift will encounter, without the developer's temporary test setup around it.
Those checks are complete on the desk monitor. An unavailable log destination now shows logging unavailable while the read path continues; a failed read shows no fresh value even with healthy logging. Thanks, Jamie, timing the stages found the shared-thread write instead of leaving us with two competing guesses.