Why are we still calling two different FR5 handover states ready?

DavidChan1128 · 23 Nov 2025, 20:19 UTC

Closed
DA
DavidChan1128
I have asked for the called routines and the permission definitions this time. We are planning an FR5 sleeve-blank handover, not repairing the teaching example I mentioned earlier. The machine supplier has sent a definition. Its ready response acknowledges our request. Our integrator has written the same word beside permission to enter the loading area. Both have now read the other's page and still say there is no disagreement. How do I get this settled before it becomes a lesson somebody has to unlearn?

13 replies

WI
WillAdams0139
Replying to DavidChan1128

Put the two meanings on separate lines. Ask each team what changes the state and what the receiver may do with it, without using ready in the answer.

7 points
SO
SofiaBrooks0804
Replying to DavidChan1128

We inherited a screen where ready meant the previous job was accepted. The machine was still occupied. The operator caught it before anyone wrote the training notes, but it cost another handover visit.

12 points
DA
DavidChan1128
Replying to WillAdams0139

Will, I have split the lines. Sofia, ours has no screen yet. I want to keep this wording out of it rather than correct it later.

25 points
TH
TheoBarnes0584
Replying to DavidChan1128

Good. But has anyone actually said where the loading permission comes from? Two better labels still leave that job unassigned.

4 points
VI
VictorBell0620
Replying to DavidChan1128

And don't make the eventual operator guess which team's version of ready the screen is showing.

22 points
DA
DavidChan1128
Replying to TheoBarnes0584

Theo, the integrator says it will derive the loading permission from machine states. It has not listed those states yet. The machine supplier only owns the acknowledgement on its page.

12 points
SO
SofiaBrooks0804
Replying to DavidChan1128

Then I would put the missing state list in the integrator's work. Copying the acknowledgement into its drawing is easy. Explaining what happens when the request is received but loading is unavailable takes more effort.

14 points
WI
WillAdams0139
Replying to SofiaBrooks0804

Try that unavailable example in the joint review, David. It gives both teams something concrete to answer instead of another round of vocabulary.

5 points
TH
TheoBarnes0584
Replying to DavidChan1128

Who is checking the safety-related permissions separately? I wouldn't let this ordinary request acknowledgement wander into that role by accident.

23 points
DA
DavidChan1128
Replying to TheoBarnes0584

The cell integrator owns that assessment, Theo. I have asked it to distinguish those conditions in the interface review too. The unavailable example is on the agenda.

15 points
VI
VictorBell0620
Replying to DavidChan1128

Can maintenance explain the proposed states back to them at that review, rather than just watch both suppliers nod?

14 points
DA
DavidChan1128
Replying to VictorBell0620

Maintenance found the gap in the review. The request can be acknowledged while loading remains unavailable, and both suppliers have now said that explicitly. We have separate draft names. Permission conditions and loss-of-permission behaviour still need agreement.

8 points
WI
WillAdams0139
Replying to DavidChan1128

Useful progress. Leave those last two items visibly unfinished in the teaching material; the clearer names will otherwise make the interface look more settled than it is.

19 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .