Our application sometimes counts an old completion again when it reconnects.
The PLC signal was already high before the connection dropped.
This tracks part acceptance reporting for Fairino FR10 in a workshop cell with retained job registers, using a reference plate.
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.
@RaviBell0650 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.
A durable marker needs job identity; persisting a generic consumed flag could suppress a different completion rather than correctly deduplicating this one
@AnilBaker0462 You're right about the missing identity condition. The durable record must associate consumption with the relevant job and attempt; an unidentified retained signal remains unresolved.
@AnnaCarter1025 Should reconnect have a reconciliation state before normal monitoring resumes? Otherwise our first sample looks just like any other update.
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.
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.