Why does our FR10 diagnostic display wait for the log writer?

Developer found reads returning normally during a stall. The display waits for a shared lock held by the log writer. Still checking why the screen needs that lock

Does the display read back from the file, or use the latest value already in memory?

Also check what happens when no new reading arrives. A responsive display can still show an old value without making its age clear.

Victor's point caught us. Our screen stopped freezing after a change, and everyone called it fixed. It was then very smoothly drawing the same old value when communication stopped. Much nicer animation, same wrong impression.

Callum, it uses an in-memory value but shares the writer's lock while taking its snapshot. Developer is separating the display snapshot from file access. Victor, reading age is also being added

Keep the handoff to the writer bounded. Removing the shared wait shouldn't mean accumulating an unlimited backlog whenever the destination is slow. Decide how recording gaps will be reported when it cannot keep up.

Which records are essential, and which are the new verbose diagnostic detail?

Callum, useful question. We had a developer offer to turn off all logging when the extra trace was the noisy part. That cured the performance complaint and removed the evidence we needed for the next one.

Basic sampled values and read outcomes are the normal record. The new trace repeats much more detail. Developer has separated the options so reducing trace doesn't remove the normal record

Does the exported file say when recording was incomplete? Someone may use that file without seeing the warning on your display.

Victor, yes, that needs an answer. A bounded queue protects the application, but the downstream reader still needs to know which interval is missing and why.

Revised export includes recording-gap events. The offline slow-write test keeps the display responsive and reading age current; a delayed-read test makes the age rise even while recording continues normally

Have somebody open the file away from the application. We found our gap explanation depended on a colour key that only existed on screen. The exported text looked like a perfectly ordinary sample with a strange value.

What does it write when the queue actually fills, Maya?

A separate gap record, not a made-up sample value. The reviewer found the affected interval from the exported file alone. We also checked repeated full-queue episodes rather than only the first warning

That is easier to hand over. Did the ordinary launch on the workshop laptop use the revised settings too? Development tests can run with a different trace level.

Normal shortcut checked on the workshop laptop. Same revised settings, live read-only display responsive during the file test, and the exported gap information matched what the reviewer expected

We have closed the shared-lock fault. No replacement laptop. Thanks, Beth, reading the file separately caught a wording problem before the shift lead inherited it

Keep the controlled read-delay and full-queue tests with this version. They cover different failures, even if the original complaint described both as a frozen screen.