An FR10 acknowledgement with two possible attempts

ChloeBrooks0831 · 26 Jun 2025, 03:22 UTC

Closed
CH
ChloeBrooks0831
Our inspection job label repeats after restart. Three clocks disagree. The acknowledgement cannot be assigned from timestamps alone.

18 replies

FE
FelixBaker0458
Replying to ChloeBrooks0831

Keep the raw files and lay out each source in its own order. Which events are definitely before or after the application restart, without relying on a clock comparison?

20 points
CH
ChloeBrooks0831
Replying to FelixBaker0458

Python timeout precedes restart. Its new request follows. PLC acknowledgement position against them is uncertain.

18 points
CH
ChloeCarter1005
Replying to ChloeBrooks0831

On one investigation the file modification time was mistaken for the event time, so I would first identify what each timestamp represents before estimating any clock offset

15 points
CH
ChloeBrooks0831
Replying to ChloeCarter1005

These are recorded event times. Original exports preserved. No measured offset between the clocks.

14 points
TO
TobyBaker0492
Replying to ChloeBrooks0831

Does the acknowledgement carry anything besides that reused label? A run number or item reference might help even if the clocks don't.

21 points
CH
ChloeBrooks0831
Replying to TobyBaker0492

Only the label. No run number or item identity in that message.

8 points
YA
YasminAdams0093
Replying to ChloeBrooks0831

Then I would leave the acknowledgement unassigned in the incident report, with the two possible attempts shown, rather than choosing the order that looks most likely

24 points
FE
FelixBaker0458
Replying to YasminAdams0093

Agreed. But keep looking for independent evidence, such as an application receipt record or an operator observation tied to one physical item. Missing clock alignment need not make every other source useless.

16 points
TO
TobyBaker0492
Replying to FelixBaker0458

Was anyone at the station when the app restarted? They may remember whether a result was visible before it closed, though I'd label that as recollection.

24 points
CH
ChloeBrooks0831
Replying to TobyBaker0492

Operator remembers a result, but cannot say whether it was fresh. Screen retained its previous value.

10 points
CH
ChloeCarter1005
Replying to ChloeBrooks0831

That recollection cannot establish a new result without the value's observation time, and I would check whether the displayed timestamp changed on refresh even when the underlying observation did not

6 points
CH
ChloeBrooks0831
Replying to ChloeCarter1005

It did. Display time was refresh time, not observation time. Separate defect logged.

18 points
YA
YasminAdams0093
Replying to ChloeBrooks0831

Useful finding even if the old acknowledgement remains ambiguous; it explains why a person could reasonably remember seeing something the incident record cannot confirm as new

6 points
TO
TobyBaker0492
Replying to ChloeBrooks0831

Will the replacement screen show when the value was actually observed? That would help the next operator describe the event without having to know the logging code.

6 points
FE
FelixBaker0458
Replying to ChloeBrooks0831

And give attempts a persistent identity through the exchange. The display fix improves the evidence people see, but the repeated job label still lets different attempts look identical to the software.

20 points
CH
ChloeBrooks0831
Replying to FelixBaker0458

Both repairs assigned. Original acknowledgement remains unassigned. No result credited to either attempt from it.

11 points
YA
YasminAdams0093
Replying to ChloeBrooks0831

Will you post whether any independent evidence turns up? Interested in the original event as well as the proposed repair

12 points
FE
FelixBaker0458
Replying to ChloeBrooks0831

For the new tests, deliver an old acknowledgement after restart deliberately. That will show whether the identity change actually prevents the association that the historical record cannot settle.

6 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .