Our application sometimes counts an old completion again when it reconnects. The PLC signal was already high before the connection dropped. This tracks fixture-check bookkeeping for Universal Robots UR5e in a PLC-coordinated inspection bench, using a fixture-mounted housing.
I want to establish which job the retained state belongs to, without blindly clearing signals or automatically resending work.
Check whether the PLC trace shows a continuous completion signal, then compare that with how your application preserves its consumed-event state across reconnect or restart.
Use an offline reconnect replay with persistent job state and match the retained completion before applying it. Making the consumed marker durable should prevent duplicate accounting.
Correct. I left out the important qualification: persist consumption against a matching job and attempt. If identity can't be established, leave the state unresolved.
@PriyaAllen0307 Should reconnect have a reconciliation state before normal monitoring resumes? Otherwise our first sample looks just like any other update.
@MinaAbbott0076 A reconciliation phase can compare the initial retained state with persistent history before normal processing resumes. Connection recovery alone doesn't establish a new job result.
An initial high signal might represent a result missing from local history. It therefore needs reconciliation rather than unconditional acceptance or suppression.
The retained state in this capture includes a job identity matching our durable record. I haven't verified equivalent identity support across the other interface variants.
You can verify the captured case without claiming all variants are covered. Where the interface can't establish identity, the retained completion should remain unresolved.
@PriyaAllen0307 I've explained why our first read gets counted again: the signal persists while our consumed marker doesn't. I'll close the fix only when identity-based reconciliation survives the offline reconnect and restart cases.