I can trace our housing check to a timeout, but the FR5 application's restart reused its job name and the PLC clock disagrees with Python; can we identify which attempt owns the later acknowledgement without sliding the timestamps until the story fits?
Cannot assign our FR5 acknowledgement after the housing job name repeats
LouisBell0659 · 26 Dec 2025, 07:21 UTC
5 replies
Replying to LouisBell0659
Keep the raw times and the sequence within each source, then ask for a shared attempt identity or other evidence that links the acknowledgement to a request across the restart. A reused job name is not enough. If the evidence cannot distinguish the two attempts, the honest result is an unassigned acknowledgement, with the housing's disposition handled separately rather than inferred from whichever timeline looks tidier.
11pointsReplying to HenryBrown0873
The PLC retains the job name but not Python's row identifier, Henry; controls has marked the restart boundary and is checking whether another shared field survived
5pointsReplying to LouisBell0659
Does the application still display that interval as completed while the matching question is open? I would make the uncertainty visible to whoever uses the report to plan the next work.
11pointsReplying to HenryBrown0873
It now shows the interval under review, not completed; no shared attempt field has been recovered, so we've asked for the future interface to carry one with an agreed restart lifetime
13pointsReplying to LouisBell0659
Include delayed and repeated delivery in the review of that new identity scheme. It should explain what happens to an old response after restart as well as distinguish two ordinary consecutive checks.
6pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .