I'm reviewing an FR10 inspection handshake. PLC sends a request pulse, app sometimes never sees it, operator gets an unexplained wait. Drawing doesn't say who clears the acknowledgement either.
This is ordinary job coordination, separate safety controls already have their own design. I want a signal ownership table before anyone patches in another delay.
Put one writer against each signal and define what event changes it. For a held request, show how acknowledgement lets the sender know it was seen. Include the return to idle too, because that's where our old sequence got stuck.
Found the app clearing request as well as reading it. PLC clears it on its timer. Two owners, neither waiting for acknowledgement. That explains why the drawing was conveniently silent.
That is a clear conflict to remove in the design. Also decide whether acknowledged means received or completed; our operators read the old label as finished even though the inspection hadn't started. A technically working sequence can still give a rotten handover.
Yes, provided the underlying states are real. Don't add two attractive indicators that both follow the same bit. The screen needs to reflect the agreed interface, including a request that has been received but hasn't finished.
Draft now says request owned by PLC, received and completed owned by app. Each clear event specified. No screen changes yet; first we're walking the normal sequence through on paper.
Walk it through with an app restart too. Held signals can be left over from an earlier job. The recovery design needs to decide which request they belong to, not simply see a high bit and announce that the next bracket passed.
What does the PLC currently do if the application reconnects while request is still active? That existing behaviour may explain more than the brief pulse, particularly if the application loses its job context at restart.
It just keeps waiting. App startup writes all three signals low, including the PLC-owned one. Added that to the review. Nobody had tested a restart halfway through an accepted request.
Yep. Normal operation and restart now both have owners and expected states. Still need the controls people to implement and verify it; paper exercise has already found plenty.
Keep the interrupted cases in the eventual acceptance check. I'd like to hear whether that old startup clearing was behind the operator's unexplained waits as well as the missing pulses.