I added detailed logging to our UR5e inspection monitor to understand a delayed result, and now the laptop display sometimes pauses while the log folder is busy. The cell has separate controls and keeps its own state.
I've probably made the evidence harder to read. What should I measure to tell a slow file write from a late response? I can replay captured messages off-line, but I don't yet have timings around the individual operations.
Yes. Parsing and file writing both happen in the display callback. I put them there because it was a tiny monitor, which is apparently not an architectural argument.
Replay first with the current file writer, then with a controlled slow writer; measure elapsed durations without sending the timing measurements through that same slow path.
Our diagnostic chart once caught up in a rush after a pause and made events look simultaneous. Preserve the message observation time separately from the display time, so the replay does not give you a convincing but reordered story.
The replay reproduces the freeze when the write is delayed. Receipt continues in the captured sequence, but my display callback waits. I've proposed moving file work away from it.
Right, I had drawn an unlimited queue. I'll replace that in the proposal with a bounded queue and an explicit logging-overload indication. Need to agree what may be dropped.
Our technician once waited for a monitor that had simply stopped refreshing. Give them an obvious stale state, not a tiny warning buried where nobody looks.
Lin, maintenance uses it for diagnosis, not cell operation. Nina, we've added a visible stale status to the test version. Writer-delay replay no longer freezes that display, but failed writes still need a clear indication.
Can you recover the original event order from an export of that test? I would compare a short known replay by hand before relying on the larger log files again.
Yes, Jonas, the short replay keeps source order and separate observation and display times. Thanks for catching that. The original live delay remains unexplained; fixing my writer only removes the extra delay I introduced.