简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

documenting a machine-tending interface: one status, conflicting definitions

ElliotAbbott0074 · 2026年7月21日 13:27 UTC

回复讨论
EL
ElliotAbbott0074
I'm writing up documenting a machine-tending interface, with Universal Robots UR5e handling a turned spacer blank in a planned enclosed machining cell. The machine supplier says 'ready' means request received. Our integrator means loading area available. We're still planning, but this is getting circular. How do I get one definition both teams accept?

18 条回复

NA
NaomiChan1115

Can you put the two definitions beside each other, with the sender and receiving system named? Start with that single disputed transition.

10
EL
ElliotAbbott0074

Yes. Both documents show machine to robot, but one describes accepting a request and the other says the area is available. Same arrow, different event.

6
NA
NaomiChan1115

@ElliotAbbott0074 Make separate rows for request received and resulting state confirmed, with an owner for each. That should clear up the normal handover on paper.

15
DA
DavidBennett0780

Clearer names won't establish who actually holds the part. Your normal handover could still look complete with custody falling between those rows.

14
NA
NaomiChan1115

@DavidBennett0780 You're right; I overstated what those rows settle. Add known part location and the point where custody becomes uncertain. Signal definitions are only the start.

6
EL
ElliotAbbott0074

There's a single transfer box in our sequence, with no part-location detail. Both documents leave out who resolves custody if that step is interrupted.

9
AA
AaronAllen0262

On another tending project, we moved a paper part token between boxes. It felt silly until both teams put it in different places.

6
GR
GraceBennett0755

@AaronAllen0262 Does the token need a box for unknown, then?

19
NA
NaomiChan1115

@GraceBennett0755 Yes. Unknown is a legitimate state to document. Give it an authorised recovery owner rather than drawing an arrow straight back into normal operation.

7
EL
ElliotAbbott0074

Would you put recovery ownership in this table or a separate procedure? I'm trying to keep it readable without hiding the awkward bit again.

15
NA
NaomiChan1115

@ElliotAbbott0074 Keep the owner visible in the table, beside a procedure reference. Separate detailed instructions are fine when their document link and revision are clear.

21
DA
DavidBennett0780

And don't let either supplier write 'other system' as the owner. That's the same disagreement wearing a slightly nicer shirt.

23
EL
ElliotAbbott0074

@DavidBennett0780 That's close to our current wording, unfortunately. One note says machine recovery, while the machine document points back to the integrator for interrupted transfers.

7
AA
AaronAllen0262

Put the conflicting passages next to each other in the common draft. Then the suppliers can resolve the wording instead of you interpreting their intentions.

5
GR
GraceBennett0755

@NaomiChan1115 If communication returns, why wouldn't the sequence simply retry?

21
NA
NaomiChan1115

A working connection doesn't tell you whether the part changed hands. Retrying needs an agreed state and recovery policy that accounts for the physical transfer.

19
EL
ElliotAbbott0074

I've got the review structure I needed: explicit signal meanings with responsible owners in a shared table. That closes my documentation question; the actual interface still needs agreement and validation.

2
NA
NaomiChan1115

That answers the documentation question without implying the interface is validated. The shared table gives the remaining agreement a clear home.

23

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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