Our separate monitoring laptop pauses its inspection-status display when detailed logging is busy. Cell controls are separate. I suspect synchronous file writes, but the timing evidence is not there yet. What should I measure before calling the UR5e connection unreliable?
Measure the application stages first: request, receipt, parse, write and display, using a monotonic clock. We found a writer queue useful in our other test build, but that doesn't diagnose your machine. Replay captured input locally and compare the logging paths.
Developer can replay the saved input without a controller connection. I will ask for the stage times as well as a video of the paused window. Easier to compare than my impression that the folder looked busy.
Our slow-folder replay kept it updating and counted dropped diagnostics. Network delay remains a separate test in that work. You're right to ask about age; queue performance alone is not a current-data guarantee.
Our replay shows the read callback waiting on a log flush before it hands data to the display. With detailed writes disabled, the same input does not pause there. That is the local delay identified; no new queue implementation yet.
Temporary diagnostic comparison only, Robin. Sofia, the maintainer wants event details retained and losses visible. Developer is proposing bounded background writing with stale-data indication. We have not tested that proposal or delayed incoming data yet.
Then you have isolated flush blocking, not finished the monitoring change. Include stalled storage, overflow, shutdown and incoming-data delay when reviewing the test scope; each can leave a different gap behind a screen that seems fine.