Can I separate FR10 communication time from a slow diagnostic log write?

FionaAdams0151 · 26 Jun 2026, 18:01 UTC

Reply to discussion
FI
FionaAdams0151
Our FR10 trend display began stalling after I enabled detailed logging, especially when the folder is busy. The cell controls are separate. I suspect synchronous writes, but I want a cheap timing check before changing storage or blaming communications.

10 replies

SA
SamAllen0333
Replying to FionaAdams0151

Measure elapsed time around acquisition, parsing, log writing and display delivery separately, using a monotonic clock. Keep that timing evidence away from the same synchronous log path under investigation, or the measurement itself may queue behind the delay you need to see.

18 points
FI
FionaAdams0151
Replying to SamAllen0333

The existing timestamps are written only after the whole update returns. They show a gap, not which stage consumed it. I can ask our developer to add those separate measurements.

10 points
SO
SofiaChen1152
Replying to FionaAdams0151

That gap could include time before acquisition begins. Does the application also record when an update was due and when it actually started?

3 points
LU
LucaAllen0265
Replying to SofiaChen1152

Sofia, good point. If one slow write blocks the next poll from starting, the communication call can be fast and the displayed sample still be old. I'd want sample age visible as well as the duration of the latest call.

6 points
SA
SamAllen0333
Replying to LucaAllen0265

Yes, distinguish scheduling delay from acquisition duration. For a local comparison, replay the same captured input with normal and deliberately slow test storage. Keep the acquisition test separate so that replay does not get presented as a finding about the network.

13 points
FI
FionaAdams0151
Replying to SamAllen0333

Developer added the measurements to the replay harness. With the slow test sink, time accumulates in the synchronous writer and subsequent updates start late; parsing stays short. This reproduces the display stall without a robot connection.

16 points
LU
LucaAllen0265
Replying to FionaAdams0151

That's a useful reproduction, Fiona. Has the proposed fix got a bounded backlog and an explicit response when storage stays slow? Moving the write elsewhere can make the screen look healthy while the logger accumulates an expensive secret.

7 points
FI
FionaAdams0151
Replying to LucaAllen0265

We have a candidate worker with a bounded queue, plus an overflow warning and dropped-diagnostic count. In the slow-sink replay the display keeps updating and the warning appears; we have not yet compared it with the workshop acquisition path.

19 points
SO
SofiaChen1152
Replying to FionaAdams0151

Keep the dropped count separate from missing acquisition samples. A logging overflow should not be reported as a communication loss unless you actually observed one.

16 points
FI
FionaAdams0151
Replying to SofiaChen1152

Agreed. The candidate names it dropped diagnostic records, and shows sample age separately. Replay fix looks useful; communication timing in the workshop remains an open check, not a conclusion from the local test.

7 points

Add to the discussion

Welcome to Application Robot

Everyone can read the forum. Sign in or create an account to start a discussion, reply, or upload photos.

Forgot your password?

By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.