An FR10 acknowledgement with two possible attempts

ChloeBrooks0831 · 2025年6月26日 03:22 UTC

已关闭

主帖中文翻译暂不可用,以下显示英文原文;回复保留原文。 查看英文原文

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

18 条回复

FE
FelixBaker0458

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分
CH
ChloeBrooks0831

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

18分
CH
ChloeCarter1005

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分
CH
ChloeBrooks0831

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

14分
TO
TobyBaker0492

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

21分
CH
ChloeBrooks0831

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

8分
YA
YasminAdams0093

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分
FE
FelixBaker0458

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分
TO
TobyBaker0492

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分
CH
ChloeBrooks0831

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

10分
CH
ChloeCarter1005

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分
CH
ChloeBrooks0831

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

18分
YA
YasminAdams0093

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分
TO
TobyBaker0492

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分
FE
FelixBaker0458

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分
CH
ChloeBrooks0831

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

11分
YA
YasminAdams0093

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

12分
FE
FelixBaker0458

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分

讨论已关闭

此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .