2. RobotStudio工程与现场控制器对应关系

做现场程序迁移时,最容易出问题的往往不是程序本身,而是“虚拟”和“真实”之间的对应关系没有理清。RobotStudio 里的一个工程,看起来只是几个文件,但它实际上是对现场一台真实控制器的完整描述:虚拟控制器代表哪台柜子、系统版本是否一致、RobotWare 选项是否匹配、I/O 配置是否对得上。只要其中任何一项错位,迁移后的程序就可能出现指令无法识别、信号找不到、运动配置报错等问题。因此,理解这套映射关系,是迁移与校核工作的第一步。

一、虚拟控制器与真实控制器的对应

RobotStudio 中的虚拟控制器(Virtual Controller,简称 VC)是真实控制器(IRC5 或 OmniCore)在软件中的镜像。它并不是一个“随便建的空壳”,而是由系统版本、RobotWare 选项、机器人型号、附加轴配置、I/O 配置等共同定义出来的。现场控制器的这些属性,必须能在虚拟控制器中找到对应项,迁移才有意义。

对应关系可以从三个层面理解:

  • 身份对应:虚拟控制器对应现场哪一台柜子,通常用控制器名称、序列号或工位编号标识。多台机器人共线时,必须一一对应,不能混用。
  • 系统对应:RobotWare 主版本与修订版本要一致,例如现场是 RW 6.08.01,虚拟控制器也应基于同一版本创建,否则部分指令和系统参数会不兼容。
  • 配置对应:机器人型号、附加轴、选项、I/O 板卡与信号定义,都要与现场保持一致。

实际工作中,推荐的做法是:从现场控制器直接创建虚拟控制器,而不是在 RobotStudio 里手动新建。RobotStudio 提供“从控制器创建”或“从备份创建”的方式,可以把现场的系统版本、选项和配置原样带入虚拟环境,这样对应关系天然成立,后续迁移风险最小。

二、系统版本与 RobotWare 选项的映射

系统版本决定了控制器能识别哪些指令、支持哪些功能。RobotWare 选项则是在系统版本之上,进一步决定“这台控制器具备哪些能力”。常见的选项包括:

  • 运动类:如 Additional Axis(附加轴)、MultiMove(多机器人协调)、World Zones(工作区监控)。
  • 通信类:如 PC Interface、Fieldbus(Profibus、Profinet、EtherNet/IP)、Socket Messaging。
  • 应用类:如 Arc、Spot、Paint、PickMaster 等工艺包。
  • 安全类:如 SafeMove、Electronic Position Switch。

迁移前必须核对:现场控制器上启用了哪些选项,虚拟控制器是否同样启用。如果现场用了 MultiMove,而虚拟控制器没有该选项,那么包含多机器人协调指令的程序在虚拟环境中根本无法通过语法检查;反过来,虚拟控制器多启用了现场没有的选项,也可能让程序“看起来能跑”,但下载到现场后报错。

核对选项时,不要只看选项名称,还要看选项的版本号。例如 PC Interface 在不同 RobotWare 版本下接口行为可能不同,版本不一致时通信相关程序需要重点复查。

三、I/O 配置的映射关系

I/O 配置是迁移中最容易“看起来对、实际错”的部分。它包含三层:

  1. 硬件层:现场用的是哪块 I/O 板卡,如 DSQC652、DSQC1030,安装在哪个总线节点上。
  2. 信号层:每个信号的名字、类型(Digital Input/Output、Analog、Group)、对应板卡通道号。
  3. 逻辑层:信号在程序中的别名、单位、量程、交叉连接(Cross Connection)。

虚拟控制器中的 I/O 配置必须与现场一致,程序里的 SetDO、WaitDI、SetGO 等指令才能正确对应到实际信号。如果现场把夹爪信号命名为 gripClose,而虚拟控制器里叫 DO1,程序迁移后就会出现“信号未定义”或“信号接错”的问题。

建议在迁移前导出现场控制器的 I/O 配置文件(EIO 文件),与虚拟控制器的 EIO 文件做对比。RobotStudio 的“I/O 配置”界面可以直接查看信号列表,也可以导入导出 EIO 文件进行比对。

四、映射关系总览

下面这张图把虚拟控制器与真实控制器之间的对应关系整理成一张映射图,重点表现“现场侧—虚拟侧”的对应层次,以及迁移前需要逐项核对的四个维度。

虚拟控制器与真实控制器映射关系 现场真实控制器 IRC5 / OmniCore 控制器身份 名称 / 序列号 / 工位编号 系统版本 RobotWare 主版本 + 修订号 RobotWare 选项 运动 / 通信 / 工艺 / 安全 I/O 配置 板卡 / 信号 / 交叉连接 RobotStudio 虚拟控制器 Virtual Controller (VC) VC 身份标识 与现场控制器一一对应 系统版本 与现场保持同一版本 选项配置 与现场启用项完全一致 I/O 配置 EIO 文件与现场一致 身份核对 版本核对 选项核对 I/O 核对 推荐做法:从现场控制器或备份直接创建虚拟控制器,使四项映射天然一致

五、迁移前的核对清单

把上面的映射关系落到操作上,可以整理成一份核对清单。建议在每次迁移前逐项确认,避免遗漏。

核对项 现场侧查看方式 虚拟侧查看方式 不一致时的处理
控制器身份 示教器“系统信息”或柜体标签 RobotStudio 控制器属性 重新命名 VC,确保一一对应
RobotWare 版本 示教器“系统信息—系统属性” VC 创建时选择的版本 用相同版本重建 VC
RobotWare 选项 示教器“系统信息—选项” RobotStudio“控制器—选项” 在 VC 中启用缺失选项
I/O 板卡与信号 示教器“输入输出—信号” RobotStudio“I/O 配置” 导入现场 EIO 文件覆盖 VC 配置
机器人型号与附加轴 示教器“系统信息—机器人” VC 运动配置 按现场实际重建运动配置

六、常见错位与判断依据

实际迁移中,以下几种错位最常见,也最容易造成“虚拟能跑、现场报错”:

  • 版本错位:虚拟控制器用了较新的 RobotWare,程序里出现了旧版本不支持的指令。判断依据是现场示教器报“指令未知”或“语法错误”。
  • 选项错位:现场没有 MultiMove,但虚拟控制器启用了,程序里写了多机器人协调指令。判断依据是现场系统启动时选项校验失败。
  • I/O 错位:信号名或通道号不一致,程序运行时 WaitDI 一直等待或 SetDO 无输出。判断依据是示教器 I/O 界面中信号状态不变化。
  • 运动配置错位:附加轴数量或减速比不一致,导致运动范围或速度异常。判断依据是现场手动运行附加轴时方向、行程与虚拟仿真不符。
迁移前不要只依赖“程序能通过语法检查”作为判断依据。语法检查只验证指令是否被当前系统识别,不验证 I/O 信号是否真实存在、选项是否与现场一致。必须结合上面的核对清单逐项确认。

理解虚拟控制器与真实控制器的映射关系,本质上是在迁移前建立一份“对应基准”。只要身份、系统版本、选项、I/O 配置四个维度都能对齐,后续的程序迁移、仿真验证和现场下载就有了可靠的基础。反之,任何一项错位都可能在现场表现为难以定位的故障,排查成本远高于迁移前的核对成本。