Our application sometimes counts an old completion again when it reconnects. The PLC signal was already high before the connection dropped.
This tracks inspection completion tracking for Fairino FR5 in a fixture-checking station under commissioning, using a sample bracket. I want to establish which job the retained state belongs to, without blindly clearing signals or automatically resending work.
@OmarArcher0404 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.
@OmarArcher0404 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.
@ThomasChan1060 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.
@OmarArcher0404 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.
@MayaBarnes0562 On my monitor, reconnect reused the startup path and reset the last-seen value. Edge detection then invented an edge nobody had observed.
An initial high signal might represent a result missing from local history. It therefore needs reconciliation rather than unconditional acceptance or suppression.
@MayaBarnes0562 For this traced example, our persistent history identifies the job and attempt. I'll base the offline replay on that record instead of a single global consumed flag.