One FR5 ready entry describes two different events
IsaacBell0694 · 2026年8月1日 03:57 UTC
主帖中文翻译暂不可用,以下显示英文原文;回复保留原文。 查看英文原文
14 条回复
Ask what each side would do after receiving ready while preparation is incomplete. That example exposes the disagreement without debating which supplier owns the English word.
24分Who asserts and clears the current entry? The answer may already differ between the two documents.
7分I would write a small event sequence with both teams, beginning with a request and an explicit receipt acknowledgement. Then show the separate condition they need before loading can proceed. For each, record who produces it, what evidence makes it true and what the receiver may do. The useful question is whether both suppliers predict the same next action, not whether the signal names look tidy.
15分Lin, be careful with may proceed. This ordinary interface cannot replace the required safety conditions. The document needs to keep those responsibilities separate.
-2分Yes, I meant the process sequence only. Safety permissions and protective functions remain their own assessed design. I'll spell that out rather than leave proceed doing too much work.
10分Their current descriptions would produce different actions in Aisha's incomplete-preparation example. The integrator would interpret receipt as available space. We have not agreed clearing behaviour either.
20分Then pause the wording edit and have both owners walk that example. Which state must remain visible while preparation continues?
3分Include a delayed reply to an earlier request. A correctly defined event can still be applied to the wrong cycle if the correspondence is unspecified.
5分And a restart while waiting. Or more precisely, a restart on either side, since they may preserve different state. Has anyone written that case?
25分Not in the original notes. We have now agreed that receipt acknowledgement and loading-area availability are separate process meanings. The revised sequence still needs request correspondence, clearing and restart cases before I can accept it.
7分For the restart walkthrough, write what each side actually knows on return, including any retained request or acknowledgement. Then ask each supplier what they would publish and what action they would wait for. A blank startup diagram can conceal the old state you are trying to reconcile. You do not need to invent new signals during the meeting; first establish the behaviour the design has to support.
19分Will maintenance see those waiting reasons in the handover? Otherwise the clarified interface can still leave an unexplained ready message on the screen.
9分Maintenance is reviewing the waiting descriptions with us. The normal sequence is clearer, but fault and restart responses remain open. I have not treated the renamed entries as completed interface acceptance.
12分I'd be interested in the delayed-old-reply result when the teams reach it. Agreement on the happy path is common; the unresolved correspondence is where your new definitions will be tested.
21分