I enabled detailed logs on our read-only FR10 monitor and the screen now pauses when the shared folder is busy; the cell controls are separate, but this makes a useful maintenance display look dead, and I want to find out whether file writes or the status requests are eating the time before asking for a rewrite.
Time request start, response arrival, display update and file-write completion separately, using something that doesn't wait for that same file; the order the lines finally appear in the folder won't tell you where the application was blocked
Developer captured those stages separately: the status reply is back, then the screen waits while the write finishes; we can reproduce that delay with the slow test destination, without changing the status source.
If they move writing out of the display path, ask what happens when the writer falls behind or cannot write at all, rather than giving it an unlimited queue.
Make missing diagnostic records visible too. A responsive screen is useful, but maintenance may later ask for history that was never saved. I would want the person using the display told when the record is incomplete, without confusing that with a failed status request.
Keep the original observation times when records finally reach the file; otherwise the queue can turn a delay in saving into an apparent delay in the equipment response.
Last value just sits there, Elena, with no age; that's getting changed too, and Mia's point is in the file format review so the eventual write time won't replace the observation time.
Luis, I agree about missing history, but would you really show all the writer detail on the main screen? The operator needs to recognise stale status quickly, and another block of diagnostic information could make that harder
Two short states would do me: current reading unavailable, or diagnostic record incomplete. Different problems. Keep the detailed writer complaint somewhere I can open when I need it.
Isabel, Jane's split is close to what I meant. I want the loss visible, not the whole queue printed beside the status value. Maintenance can have the detail behind it. The screen still needs to make the reading's age easy to find.
We've agreed that split with the maintenance lead: age beside the reading, a separate record-incomplete indication, and writer detail behind it; developer is adding bounded buffering with an explicit gap when records cannot be retained.
New writer is in and the slow-destination test no longer blocks updates; denied writes and a deliberately full buffer also leave the display responsive, with the missing-record interval reported instead of silently pretending everything was saved.
Yes, that was in the same check set: failed read at startup, then failure after a good reading, both with healthy logging; current data becomes unavailable while the last observation stays labelled with its time, and the record-incomplete indication stays clear.
Thanks for the actual test results, Sam; I can see which problem each indication describes now, and the separate observation time is the bit I'd want preserved in the maintainer's examples.