Keeping diagnostic output from holding up the display (controller availability logging)

HanaArcher0361 · 16 May 2026, 18:10 UTC

Reply to discussion
HA
HanaArcher0361
I enabled detailed logging for controller availability logging, and now our diagnostic display sometimes stops updating while the log folder is busy. We're watching Universal Robots UR5e in a workshop telemetry desk, with a fixture block as a reference. The cell controls are separate. I suspect synchronous file writes, but I haven't ruled out communication delays.

17 replies

DA
DavidAbbott0084
Replying to HanaArcher0361

Can you replay saved responses offline with a slow log destination? Measure receipt and processing separately.

15 points
HA
HanaArcher0361
Replying to DavidAbbott0084

It does. My replay keeps supplying responses, but processing stops inside the file write. Finally, something I can reproduce.

13 points
DA
DavidAbbott0084
Replying to HanaArcher0361

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.

3 points
AN
AnikaBaker0508
Replying to DavidAbbott0084

@DavidAbbott0084 A bounded queue fills. You can't promise the whole diagnostic story survives. What happens when storage stays blocked?

4 points
DA
DavidAbbott0084
Replying to AnikaBaker0508

You're right about my preservation claim. The design needs a deliberate overflow policy and visible dropped-sample counts so missing diagnostics aren't concealed.

3 points
HA
HanaArcher0361
Replying to DavidAbbott0084

Can routine samples be dropped but error summaries kept? I don't need endless identical status lines.

9 points
DA
DavidAbbott0084
Replying to HanaArcher0361

@HanaArcher0361 Yes, with explicit limits for both. Error summaries still need a failure path if storage remains unavailable.

13 points
LI
LinBaker0444
Replying to DavidAbbott0084

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.

-1 points
IS
IsabelArcher0387
Replying to LinBaker0444

So where does that warning go? Another log sounds like the same problem twice

19 points
DA
DavidAbbott0084
Replying to IsabelArcher0387

Expose a counter or health state directly in the application. Include it in exports when writing is possible again.

16 points
HA
HanaArcher0361
Replying to DavidAbbott0084

@DavidAbbott0084 I'll make logging health visible beside our monitor status. A moving display shouldn't quietly imply complete logs.

8 points
AN
AnikaBaker0508
Replying to HanaArcher0361

@HanaArcher0361 Are you displaying when the application observed the sample or when the writer saved it? A delayed writer makes those different events.

17 points
HA
HanaArcher0361
Replying to AnikaBaker0508

Written, currently. That's awkward. Our charts could make a disk pause look like a late robot response.

12 points
DA
DavidAbbott0084
Replying to HanaArcher0361

Record when the application receives the observation and measure the later write delay independently, making the chart's chosen time field explicit.

10 points
IS
IsabelArcher0387
Replying to DavidAbbott0084

Could the controller still be late, though? The replay only proves the disk can cause it

10 points
DA
DavidAbbott0084
Replying to IsabelArcher0387

The replay establishes that synchronous logging can stall this application. It doesn't establish the absence of communication delays in the real diagnostic session.

11 points
HA
HanaArcher0361
Replying to DavidAbbott0084

Right. I'll label this as the reproduced logging stall, not the explanation for every delay we've seen.

8 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.