I'm coordinating the FR5 tending interface for our sleeve blanks, and the machine supplier's loading ready signal only acknowledges that it received the request; our integrator reads it as the loading area being available, so how should we get the conditions and responsibilities written down before this becomes a commissioning argument?
Ask each supplier to describe what must be true when it sets or uses that signal. Do the walkthrough with the loading area unavailable as well as available, so an acknowledgement cannot be mistaken for access.
We tried the unavailable case on paper and the machine supplier still asserted loading ready after receiving the request, while the integrator expected its loading sequence to proceed.
Then the integrator needs a different condition for that decision. Document request acknowledgement and loading-area availability separately, with their writers, readers and reset rules. The ordinary interface does not replace the required safety functions.
Jack, you cannot assign a delay cause from the acknowledgement alone. The state table should show what condition is still missing and which side provides it.
Both suppliers agree to split the meanings now, and the machine supplier will identify the separate availability condition; Jack, we cannot estimate that wait until its normal causes are defined.
Show that wait on the operator screen too. If it just says requested forever, people start pressing again and then everyone has a second argument about duplicate requests.
We had a screen that said waiting for robot while the robot was waiting for the machine. Very polite standoff. Naming the actual missing condition helped maintenance far more than colouring both boxes amber.
Grace, include loss of availability after acknowledgement in the review. They need to agree how the sequence stops or holds, without treating an old acknowledgement as lasting permission to continue.
Added that case, and the draft now distinguishes received, waiting for availability and exchange in progress; the condition-loss behaviour is still being reviewed by the controls teams.
Our integrator is coordinating the decision with the machine controls engineer; each had expected the other side to clear it, so that row is explicitly unresolved in the draft.
Exactly. I have watched someone press reset just to remove a banner, then wonder why the job disappeared. Two sensible intentions attached to one badly explained button.
Separate those actions in the proposed interface and review who can authorise each. Clearing the display should not silently change an outstanding machine request.
They have separated message acknowledgement from the proposed cancellation action, with cancellation still held out of implementation until both controls engineers agree its sequence.
The joint draft now has cancellation ownership and its acknowledgement defined. We are walking through timeout and restart cases next; no live interface test has happened yet, but the two ready definitions are gone.
Thanks for naming the remaining work. When the walkthrough is done, can planning get the ordinary wait cases separately from the unresolved fault cases?