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.
Our monitor counts a retained PLC signal twice (Fairino FR10)
RaviBell0650 · 2026年5月12日 20:12 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
12 条回复
回复 RaviBell0650
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.
20分It stays high. Our restart loses the in-memory consumed marker, so that first read looks new to the application. Annoyingly simple once it's visible.
10分回复 RaviBell0650
@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.
10分A durable marker needs job identity; persisting a generic consumed flag could suppress a different completion rather than correctly deduplicating this one
14分@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.
18分@AnnaCarter1025 Should reconnect have a reconciliation state before normal monitoring resumes? Otherwise our first sample looks just like any other update.
20分回复 RaviBell0650
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.
5分On my monitor, reconnect reused the startup path and reset the last-seen value. Edge detection then invented an edge nobody had observed
17分回复 LiamChen1186
@LiamChen1186 Would ignoring the first high value fix that? It feels tempting, which probably means I'm missing something.
20分回复 ChenAli0181
An initial high signal might represent a result missing from local history. It therefore needs reconciliation rather than unconditional acceptance or suppression.
9分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.
15分回复 RaviBell0650
Your closure fits the observed mechanism, while the reconciliation result stays conditional on the required checks.
18分