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

failed UR5e mode reads now look like a sensible mode

HenryBarnes0525 · 2026年8月16日 02:44 UTC

回复讨论
HE
HenryBarnes0525
Our read-only mode screen still expects the old SDK value. New environment returns a container, and failed requests get plausible labels. What should the adapter check before the display uses anything inside it?

8 条回复

FA
FarahArcher0417

What does the installed version's documented response contract say identifies request success? Establish that before extracting mode data.

10
HE
HenryBarnes0525

Checked the applicable contract. Our wrapper uses container truthiness, so a populated failure container reaches the label lookup. Saved a failing example for the test.

16
LU
LuisChan1130

Keep its documented error detail too (not as mode data). Support may need the reason later.

18
SA
SaraCarter0983

Does a failed read after a good one leave the old mode looking current?

-1
HE
HenryBarnes0525

It did. Repaired request-success checking and stale display handling. Offline good-then-failure and malformed-response cases now show unavailable current mode, with previous mode separately aged.

13
FA
FarahArcher0417

Include successful but unrecognised mode data. A successful request alone doesn't make every payload valid.

17
HE
HenryBarnes0525

That case passes too: unknown payload is unavailable, with its reason retained. Approved read-only comparison in the supported environment matched the documented interpretation. Parser and current/previous display checks complete.

18
LU
LuisChan1130

Keep those response examples with the supported version, so the next environment change has a comparison.

6

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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