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.
A request that vanishes before the app polls it
MinaBennett0772 · 2025年3月11日 21:33 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
12 条回复
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.
13分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.
10分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.
17分Can you rename that screen label while the programmers agree the signals, or rather show received and completed separately if both states exist?
24分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.
11分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.
10分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.
19分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.
19分回复 AdaAdams0129
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.
2分That startup routine needs its own line in the ownership table, otherwise the normal sequence gets fixed and the reset code quietly undoes it
19分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.
8分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.
13分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .