Which ready signal acknowledges our FR5 loading request?

FelixBaker0458 · 28 Nov 2025, 09:29 UTC

Closed
FE
FelixBaker0458
I put both suppliers' sequence notes side by side. The machine supplier sets ready when it receives a loading request. Our integrator waits for ready to mean the loading area is available. Neither description mentions the other event. This is the ordinary job interface, not the safety permissions. I need the two teams to stop approving the same word while describing different sequences.

14 replies

SA
SamBell0681
Replying to FelixBaker0458

Ask them to name request receipt and loading availability separately, with the owner of each value. Then walk one request through both descriptions. Can either team show which request the acknowledgement belongs to?

18points
FE
FelixBaker0458
Replying to SamBell0681

Not in the present sheet. It lists request and ready as bits with no attempt identity. The integrator thought the machine would retain the request until completion.

18points
BE
BethArcher0411
Replying to FelixBaker0458

What does the machine actually do with the request, Felix? Their observed sequence, not the integrator's assumption.

14points
PA
PavelChan1049
Replying to FelixBaker0458

I'd have both authors explain the normal sequence in one meeting before anybody adds more bits. If their definitions disagree, extra signals can give you a larger disagreement with nicer names.

-2points
SA
SamBell0681
Replying to PavelChan1049

Pavel, yes. The table should describe that agreed sequence, not replace the conversation. Ownership and clearing still need writing down afterwards.

9points
FE
FelixBaker0458
Replying to BethArcher0411

Beth, the machine clears its received state on its next internal transition. The integrator had assumed it would remain until the application acknowledged completion. We have a joint walkthrough arranged.

18points
NI
NinaBrown0936
Replying to FelixBaker0458

We once had a walkthrough stop at the successful load. Nobody asked what a timeout meant until the operator met one. Include no reply, delayed reply and reconnect while work is outstanding, not just the path everyone hopes to see.

15points
BE
BethArcher0411
Replying to FelixBaker0458

And who may cancel an outstanding request? That's another place two teams can each think the other owns it.

19points
FE
FelixBaker0458
Replying to BethArcher0411

Cancellation is not defined yet. The walkthrough now includes it and Nina's interruption cases. Our lead integrator owns the combined interface decision.

14points
SA
SamBell0681
Replying to FelixBaker0458

Bring the intended operator display into those cases too. A correct exchange can still be taught badly if the page calls request received ready to load.

16points
PA
PavelChan1049
Replying to SamBell0681

I'd keep an unresolved outcome visibly different from a rejected request. Otherwise someone may think the obvious fix is to ask again when the first job could still exist.

10points
FE
FelixBaker0458
Replying to PavelChan1049

The draft now separates receipt, availability and outcome. Both authors have agreed who writes each. Clearing after interruption and cancellation remain under review; no revised interface tested yet.

9points
NI
NinaBrown0936
Replying to FelixBaker0458

That's an honest stopping point for the design note. Don't let somebody remove the open items because they spoil a tidy handover diagram.

18points
BE
BethArcher0411
Replying to FelixBaker0458

Who is updating the machine supplier's copy after the clearing rules are agreed?

14points

Discussion closed

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