跳到主要内容

配置 Object 与设备

Object 把寄存器、协议、设备 SDK 和连接细节封装为 App 可以理解的业务能力，例如“读取工位状态”“轴回零”或“执行检测”。Page 负责呈现和发出操作意图，QG (.qg) 负责步骤、等待、超时和恢复，Object 负责与具体能力交互。

什么时候需要这页​

  • 为 App 接入 PLC、机器人、Motion、Vision 或外部数据能力；
  • Object 类型缺失、属性无效或引用断开；
  • 设备配置已保存，但现场行为没有变化；
  • 规划低风险联调、故障测试和交付验收。

完整的 Motion、Vision 和 Safety 配置步骤见配置 Object、Pulsar、Vision 与 Safety。

常用入口​

任务编辑器入口
新增、编辑或删除 ObjectResources → Objects；右键 Objects 新增，选中后在 Properties 编辑
创建 QG 程序Resources → Scripts → 新建 QG 程序
创建 App 内 C# ProviderResources → Scripts → 新建 C# Provider
安装或检查功能包Settings → 功能包
启用 Motion 或 VisionSettings → 常规
配置 Pulsar 总线、轴、组和 IOSettings → 轴/IO
配置 Camera 和 InspectionResources → Vision
配置工程联锁Resources → Safety

选择正确的能力​

需求优先选择
EtherCAT 运动、轴、插补和 IOMotion 模块与 theseus.pulsar.controller
相机采集和视觉检测Vision 模块与 theseus.vision.runtime
Modbus TCP / RTUtheseus.modbus.tcp-master / theseus.modbus.rtu-master
S7-200 Smarttheseus.siemens.s7-200-smart
Omron Host Linktheseus.omron.hostlink
Epson RC+ 7.3 Remote Ethernettheseus.epson.rc7
AUBO i 系列 ARCStheseus.aubo.i-series
App 内轻量表格安装 Table Store，再使用 theseus.table-store.table
非标协议或客户设备高级：自定义 C# Object 能力
App 内纯逻辑能力QG (.qg)

不要因为名称相似就替换 Provider。先在新增 Object 对话框中阅读能力描述，再确认现场协议、控制器版本和所需方法。

Object 配置原则​

通过 Resources → Objects 新增和维护 Object，在 Properties 中填写参数并选择其他 Object 引用。日常操作不需要手写配置文件。

每个 Object 都应使用唯一、稳定且能表达工艺含义的 ID 和名称。选择能力时以新增 Object 对话框中的描述、现场协议和设备版本为准，不要修改系统标识、猜测方法，或用名称相似的能力代替。

推荐配置流程​

1. 先做设备清单​

记录设备型号、固件 / 控制软件版本、协议、网络或串口参数、地址范围、单位、方向、限位、超时和安全前置条件。把“已确认”和“待现场确认”分开，不要让默认值代替工程结论。

2. 添加 Object 实例​

  1. 在 Resources → Objects 右键选择新增对象。
  2. 从当前 App 可用的 Provider 中选择精确能力。
  3. 使用能表达工艺含义的 Object id 和名称。
  4. 填写 Properties；有引用字段时选择已存在的目标 Object。
  5. 保存并立即处理红色字段、缺失类型和引用错误。

Object 的显示位置用于导航，Properties 中的引用才表示实际依赖。删除或重命名 Object 前，先搜索 Page、QG 和其他 Object 的引用。

3. 把底层能力封装成业务动作​

Page 和 QG 应调用“启动检测”“读取工位状态”这类语义方法，而不是在多处复制寄存器地址。需要重复使用的设备步骤、等待、重试限制、超时和恢复分支放到 QG 或自定义 C# Provider；Page 只触发动作并显示进行中、成功、失败和恢复状态。

4. 保存、Build，再创建新运行实例​

Object、设备参数和 QG 的保存只更新源工程，不会热替换当前运行实例。完成配置后：

  1. Stop 并等待状态变为 Stopped；
  2. 保存所有相关文件；
  3. 执行 Build，修复 Problems 中的 Object、引用、模块或源码错误；
  4. 用 Start 或 Debug 创建使用新部署版本的实例；
  5. 从只读状态开始验证，再逐步开放真实输出。

Start、Debug 和 Preview 都不会隐式采用未保存的设备配置。

自定义 C# Provider​

只有现成功能包无法表达厂商 SDK、非标协议或客户设备时，才为当前 App 创建自定义 C# Provider。它应向 Page 和 QG 提供稳定、业务化的方法，并在一个明确边界中管理连接、取消、资源释放和持久状态。

普通时序和状态组合优先使用 QG。需要编写自定义类型、方法和 Object 引用时，进入高级：自定义 C# Object 能力；本页不展开源码约定。

Motion 与 Pulsar​

在 Settings → 常规启用 Motion 并保存后，通过 Settings → 轴/IO维护总线、轴、组和 IO。App 只使用固定的 pulsar Object 调用 Controller 能力，并显式传入轴、组或 IO 点位编号。

推荐的在线顺序是：

  1. 确认 Runtime target、许可证、总线和驱动器状态；
  2. 只读检查位置、限位、使能和 IO 反馈；
  3. 在低速、低风险、可立即停止的条件下验证单个动作；
  4. 再验证 QG 的组合步骤、超时和恢复；
  5. 记录轴方向、单位、限位和异常后的人工恢复方式。

关闭 Motion 后，本地配置可以保留供以后编辑，但不会进入禁用模块的 Build。重新启用后必须重新 Build 和验收。

外部 PLC 与机器人​

通信 Provider​

Modbus、S7-200 Smart 和 Omron Host Link 都要求现场人员确认地址、数据类型、字节 / 字顺序、站号、串口或网络参数和超时。先做只读调用，再做幂等写入；非幂等写入不要盲目开启自动重试。

连接或调用被取消、超时或断开后，不要假设设备状态。重新读取显式状态，并按 Provider 要求重新连接或重新 Start / Debug。

Epson RC+ 7.3​

使用 theseus.epson.rc7 前，在 RC+ 中确认 Remote Ethernet 端口、终止符、超时、密码和 Control Device。该能力面向 RC+ 7.3；不要把后续版本状态位或其他远程接口当成兼容项。命令发送后若连接中断，结果可能未知，不能自动重放；通过显式状态和现场反馈确认。

AUBO i 系列 ARCS​

theseus.aubo.i-series 面向运行 AuboStudio / ARCS 的现代 i 系列控制器，默认使用 9012 JSON-RPC 接口，不兼容旧 8899 接口。先探测控制器和机器人名称，再读取工作、安全和运行状态，最后才验证 Power、程序控制和 IO。超时后把结果视为未知，不能根据机械臂型号猜测协议或自动解除保护状态。

危险

网络控制、Stop、Abort 和软件联锁都不是硬件急停。机器人、运动和真实输出必须由独立安全回路、控制器安全功能、限位和现场风险评估保护。

Vision​

在 Settings → 常规启用 Vision，然后从 Resources → Vision 新建 Camera 和 Inspection。新建 Camera 后先完成连接和采集验证；新建 Inspection 时可选择在线 Camera 或离线样本。

Inspection 进入生产前必须按顺序完成：

  1. 创建或编辑草稿版本；
  2. 使用有代表性的 OK、NG 和边界样本运行验证集；
  3. 由视觉或工艺负责人检查误检、漏检和边界结果并人工批准；
  4. 只激活已批准版本，再 Build 并部署；
  5. 在新运行实例中复测 Page / QG 使用的检测结果和异常分支。

OK / NG 是业务结果，不是服务健康状态。相机断开、服务不可用、算法异常和结果无法解析必须显示为错误，不能伪装成 NG 或沿用上一次结果。

Safety​

Safety 依赖已经确认的 Motion 配置。按 Safety Inputs、Safety Outputs、Safety Interlocks 的顺序建立工程联锁。保存只更新源工程；显式 Build 才会把已保存规则纳入部署，并把问题写入 Problems。

危险

Theseus Safety 是工程联锁，不是认证安全控制系统，不能替代硬件急停、安全继电器、安全 PLC 或经过认证的机器人安全功能。

现场验收顺序​

  1. 离线审查：核对 Provider、属性、引用、单位、范围和凭据处理。
  2. 构建审查：Build 成功，Problems 无阻断项，Git diff 只包含预期源码。
  3. 只读联调：验证连接、身份、版本、状态和数据类型，不发送输出。
  4. 单动作联调：在受控条件下验证单个输出、运动或任务，并确认超时和取消。
  5. 流程联调：用 Debug 验证 QG 正常路径、设备故障、通信中断和恢复。
  6. 运行验收：用 Start 和实际 Page 验证权限、防重复操作、错误文案和人工恢复。
  7. 留证：记录参数基线、测试结果、负责人和未解决风险。

验收清单​

  • Object id、名称和说明能被工艺与现场人员理解；
  • Object 列表中只有预期能力，属性和引用均有效；
  • Page 与 QG 调用业务方法，没有散落的设备地址；
  • 连接、超时、取消、断线、重复操作和恢复路径都已验证；
  • Motion、机器人和真实输出从只读到低风险动作逐级放行；
  • Vision 生产版本有验证集、人工批准和激活记录；
  • Safety 与独立硬件安全回路分别有验收证据；
  • 配置修改后执行了 Stop → Build → Start / Debug，没有把保存误认为运行更新。

常见问题​

新增 Object 时找不到需要的 Provider​

检查对应模块是否启用、功能包在 Settings → 功能包中是否准备成功，以及自定义 C# Provider 是否 Build 成功。不要用相似 Provider 临时替代；记录缺失的精确 ID 和原始错误。

Object 显示缺失类型或 Properties 无法保存​

先处理重复 Object ID、无效属性和断开的引用。Object 配置无效时，Page 和 QG 的相关补全与 Build 也会停止；不要用空类型或手写字段绕过。

配置已保存，在线行为没有变化​

当前运行实例不会热替换 Object 或设备配置。Stop 后重新 Build，再用 Start 或 Debug 创建新实例。确认操作的是正确 Runtime target。

QG 找不到 Object 或方法​

确认使用的是已经配置的 Object 实例，并先修复类型、引用和 Build diagnostics。重新打开 QG 后使用当前补全，不要手写猜测方法名。

删除 Object 后 Page 或 QG 报错​

恢复该 Object，或明确迁移所有 Page、QG 和 Object 引用后再次 Build。删除前先搜索引用可以避免这类问题。

设备超时后不知道动作是否执行​

把结果标记为“未知”，阻止自动重复动作，读取独立状态并要求现场反馈。只有证明操作幂等且项目明确允许时，才能重试。

AI 可以怎么帮​

AI 可以只读整理设备清单、检查引用、生成配置草案和测试用例。例如：

只读检查当前 Object、Motion、外部设备和 Vision 配置。按设备语义、缺失引用、单位或范围风险、待验证动作分类，不要连接设备或执行输出。

AI 生成或修改的设备、Vision 和 Safety 内容都必须由对应专业人员复核，AI 不能批准现场动作或安全设计。

相关内容​