Instrumented those stages. In the captured stall, reply receipt is prompt but the write completion is late, and display update follows it. Some other requests are slow before receipt. Looks like two delays, not one.

Keep those two classes in the report. Moving logging off the display path may address the first without improving the second. I would also show sample age, so a responsive window cannot make an old reading appear current.

If you add a writer queue, what happens when it fills rather than drains?

A bounded queue and visible logging loss need an explicit policy; otherwise the backlog just becomes the next place the application stalls or consumes memory.

Revised monitor has a bounded writer queue, sample age and a logging-loss indicator. Slow-destination test keeps acquisition and display running while showing dropped diagnostic entries. The independently slow requests still produce stale status when their age exceeds the agreed limit.

Did you test destination failure as well as slowness? A failed write can take another error path, and silently retrying forever would be a different problem from the queue-full case.

Tested a failed destination: warning remains visible and retries are bounded under the logging policy. The capture distinguishes write failures from dropped entries. No changes to robot or cell controls.

Who sees the warning after you leave the maintenance desk?

Duty maintainer has the warning in the agreed diagnostic review. The write-induced display block is fixed in these tests; communication-delay investigation stays open with its separate captures. Not calling the controller offline from either symptom alone.