The PLC's brief request sometimes passes between application reads in our FR10 reference-plate inspection cell. I can't find a clear account of who writes or clears each ordinary job signal. Safety functions are independently engineered. How do I get this non-safety interface defined before somebody just makes the pulse longer?
Have both maintainers trace the current writers and clearing conditions first, then propose a retained request and acknowledgement lifecycle. A longer pulse may reduce the symptom under one timing condition while leaving it unclear who owns a request after reconnect or restart.
Include what gets saved before an acknowledgement is sent. Otherwise the PLC can believe the application owns the request when the application has no durable record after a restart.
The PLC holds a job reference elsewhere, but the pulse itself doesn't stay up. The screen shows waiting without saying which side is waiting. Operators call the integrator before retrying; there's no written ownership rule.
Then define the job reference and request state together, including how long that reference stays unchanged and what the acknowledgement confirms. Otherwise the application could observe a retained request with a reference that already belongs to the next job.
And test the exact point between saving the request and acknowledging it. Restarting there must not create a second inspection merely because the PLC correctly repeats what it still considers unacknowledged.
Could the screen name request awaiting receipt separately from request accepted and awaiting result? That would at least stop the word waiting covering every disagreement.
Both maintainers are writing those states into one table. PLC retains the request and its reference; application acknowledgement means the request has been recorded, not that inspection has completed. Restart reconciliation is still being specified.
Important distinction. The table should define the commitment rather than rely on the name. Also state how either side reports it cannot establish the prior state; an unknown request is not automatically new work.
Durably saved is now explicit. The maintainers included a reconciliation hold when identity or retained state doesn't agree. They will test an offline implementation before any live interface change.
Use the real proposed message fields in that test. Hold delivery until after a delayed poll, duplicate it after the save, and restart before the acknowledgement. Check the persistent work list and displayed state, not only how many callbacks ran.
Duty controls owner is named for unresolved reconciliation. Offline delayed-poll and duplicate-delivery tests pass. The restart-before-acknowledgement case currently displays a new request briefly before loading the saved one, so that case is failing.
Keep it failing until startup publishes a state justified by what it knows. A brief wrong state is still wrong, especially if a user or another component can act on it before the saved request is loaded.
After fixing startup, repeat that sequence through the ordinary application entry point, not just the state handler in isolation. The temporary display may come from the surrounding launch path.
Startup now begins in reconciliation hold. Ordinary-launch replay passes delayed receipt, duplicate delivery and restart before acknowledgement, with one saved request and no new inspection dispatched by reconnect. Unknown identity remains held.