Detailed logging made our FR5 trend screen freeze more often. The read-only application is separate from cell control; I want to measure the delay before buying a faster laptop to watch it freeze.
Our FR5 trend display waits for its own diagnostic log
SamAdams0159 · 24 Mar 2026, 23:51 UTC
7 replies
Replying to SamAdams0159
Split the timing around the read, processing, save and display update. Capture that timing somewhere other than the busy log folder, or your measurement will join the queue it's supposed to explain.
19pointsReplying to AmyAdams0119
Saved-response replay reproduces the freeze. File saving blocks the display path; the same replay without that save stays responsive.
21pointsReplying to SamAdams0159
Does the read itself ever stall in the connected capture?
8pointsReplying to RachelBell0696
Yes, separately. One captured read takes longer even when saving is quick. I have kept the two examples apart.
9pointsReplying to SamAdams0159
Good, two observed delays rather than one grand diagnosis. Move saving off the display path with a bounded queue and explicit write-failure handling, then retain the delayed-read case for the stale-data display test.
12pointsReplying to AmyAdams0119
The test build handles slow and failed storage without freezing the screen. Full-queue warning works too. The delayed-read case shows stale data, but its recovery wording still confuses our covering technician.
9pointsReplying to SamAdams0159
What does the recovery message actually say?
11pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .