简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

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

讨论已关闭

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