Our diagnostic application watches Fairino FR5 for read-only diagnostic sampling in a workshop telemetry desk, using a fixture block as a reference. Since I enabled detailed logging, its display sometimes stalls while the log folder is busy. Cell controls are separate from this application.
Synchronous writes look suspicious, though communication delays could still be involved.
Try a controller-free replay of saved responses with a delayed log destination, measuring receipt separately from processing. Does the display still stall?
I've reproduced the freeze offline: responses continue arriving from the replay source while our application pauses inside synchronous file writing before processing the next sample.
@FelixBarnes0545 Move the replay's file writing behind a bounded queue and let a separate writer handle it. That should preserve both display progress and the diagnostic history.
@BrunoAllen0278 Your proposed queue has a limit, so preserving the entire history isn't guaranteed. A persistent storage blockage needs an explicit overflow policy.
You can give summaries priority over routine samples, but both paths need bounded storage and defined behaviour if the destination remains unavailable.
My setup originally queued its overflow warning through the writer that was already full, so the warning disappeared along with the samples it was meant to explain.
@BethCarter1020 The application can maintain a visible health state or drop counter independently of file writing, then include that information in an export when the destination recovers.
@FelixBarnes0545 Are you displaying when the application observed the sample or when the writer saved it? A delayed writer makes those different events.
The replay establishes a logging stall, which answers what I needed to isolate. A completed fix still depends on continued processing with delayed storage and explicit reporting of diagnostic loss.