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

Two attempts sharing one label

LouisBarnes0572 · 2026年9月4日 15:03 UTC

回复讨论
LO
LouisBarnes0572
Night-shift handover for our FR5 coupon inspection has one timeout and an acknowledgement nobody can place. Python restarted and reused the label. The three log clocks disagree. I'm reluctant to call either attempt complete.

20 条回复

PA
PavelArcher0353

Leave completion unconfirmed for now. Does either attempt have a distinct sequence value?

21
LO
LouisBarnes0572

Python only wrote the reused label. PLC trace includes a request counter. I'm looking for somewhere that counter reached the application log.

9
PA
PavelArcher0353

Check the raw response capture too, if you retained one.

15
SA
SamBennett0768

Don't merge by displayed time yet; a local sequence can tell you more than three clocks disagreeing confidently.

5
PA
PavelArcher0353

Yes, keep each source in order before trying to align them.

13
LO
LouisBarnes0572

Found a raw capture from before the restart. It contains the PLC counter beside the first label. Nothing equivalent after restart. At least the first request has an identity now.

21
HA
HarishBell0663

What made you call the later entry a second attempt? I ask because our display once called reconnection a retry even though it had only read the existing PLC state. Very economical use of the word retry.

13
TH
TheoAbbott0062

Distinguish intended work from transmitted work. An application retry entry does not establish that a second request reached the PLC. Preserve that uncertainty in the reconstruction until a corresponding transition or message can be identified.

11
PA
PavelArcher0353

Does the PLC counter advance after the restart?

22
LO
LouisBarnes0572

No advance in the captured interval. And the application line says 'retry pending', not 'retry sent'. I shortened that too far in my opening.

20
PA
PavelArcher0353

Then a second executed attempt is not established by those records.

24
SA
SamBennett0768

That removes one mystery cheaply. Still need to tie the acknowledgement to the first request, though.

20
LO
LouisBarnes0572

The PLC trace has acknowledgement changing after that request counter appears. The application saw it later, following reconnect. I'll describe those as separate observations instead of two acknowledgements.

22
HA
HarishBell0663

What will the incoming operator see on the job screen? The log explanation is improving, but they need to know whether that coupon's result is usable without becoming the fourth person interpreting three clocks.

22
TH
TheoAbbott0062

An acknowledgement establishes only what the interface defines it to acknowledge. If it means request acceptance, it does not establish inspection completion or a passing result. That distinction should determine the displayed status.

12
PA
PavelArcher0353

What does your interface document say this acknowledgement means?

22
LO
LouisBarnes0572

Request accepted. No result payload survived in our capture. The screen has been marked awaiting reconciliation by the controls lead; the coupon isn't being counted as inspected from this evidence.

14
SA
SamBennett0768

Worth adding the request counter and application startup identity to future logs. Doesn't mend this record, but avoids the same guessing exercise.

17
LO
LouisBarnes0572

Added both to the logging change request. Handover now says one confirmed accepted request, completion unknown, and no confirmed second request. That's less dramatic than my original version, fortunately.

5
HA
HarishBell0663

That's a handover someone can use. Who covers the reconciliation if the controls lead is away when the next shift starts? The named contact needs a backup, especially for a state that blocks normal work.

20

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。