One FR5 ready entry describes two different events

IsaacBell0694 · 2026年8月1日 03:57 UTC

回复讨论

主帖中文翻译暂不可用,以下显示英文原文;回复保留原文。 查看英文原文

IS
IsaacBell0694
I am documenting an FR5 machined-bush interface for a planned enclosed machining cell. The machine supplier means request received when writing ready; the integrator means loading area available. I need an agreed sequence, not another revised word that leaves those meanings in conflict. What should the teams decide together?

14 条回复

AI
AishaBarnes0605

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分
NO
NoraBell0670

Who asserts and clears the current entry? The answer may already differ between the two documents.

7分
LI
LinBarnes0531

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分
AM
AmyBrooks0815

Lin, be careful with may proceed. This ordinary interface cannot replace the required safety conditions. The document needs to keep those responsibilities separate.

-2分
LI
LinBarnes0531

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分
IS
IsaacBell0694

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分
NO
NoraBell0670

Then pause the wording edit and have both owners walk that example. Which state must remain visible while preparation continues?

3分
AI
AishaBarnes0605

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分
AM
AmyBrooks0815

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分
IS
IsaacBell0694

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分
LI
LinBarnes0531

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分
NO
NoraBell0670

Will maintenance see those waiting reasons in the handover? Otherwise the clarified interface can still leave an unexplained ready message on the screen.

9分
IS
IsaacBell0694

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分
AM
AmyBrooks0815

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分

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 和 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。