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

the ur5e wrapper guesses its way through both response formats

OmarBrooks0839 · 2026年1月11日 06:23 UTC

已关闭
OM
OmarBrooks0839
Our UR5e monitor handles a good read followed by failure now, but the compatibility wrapper still picks any plausible mode from an unfamiliar response container; how do we stop supporting every version by accident?

6 条回复

CA
CallumAdams0099

Support an explicit set of documented interface versions, with a tested parser for each shape. Unknown versions or malformed responses should be unavailable, not a treasure hunt for a mode value.

22
OM
OmarBrooks0839

Developer found the fallback behind it: if the expected field is absent, scan every value for something mode-like; removing that breaks one old fixture in our test suite, not the installed read

14
CA
CallumAdams0099

Identify what that old fixture represents before replacing it. It might be obsolete, or it might be your only example of a supported response the new parser forgot.

19
IS
IsaacAllen0346

And put the supported versions in the handover. Otherwise the next upgrade inherits a vague yes from the last person who saw the screen turn green.

-1
OM
OmarBrooks0839

Old fixture was invented for the mock and matches neither supported format; replaced with documented success and failure examples, then tested malformed containers, unknown versions and success followed by failure without the guessing fallback

14
OM
OmarBrooks0839

Maintainer's installed read-only comparison matches the expected mode and source version, and the failure display stays unavailable rather than borrowing a value; supported-version note is in the handover, Isaac, so I'm closing this wrapper fix

9

讨论已关闭

此讨论已连续六个月没有活动,现已关闭新回复。 最后活动: .