3. 虚拟控制器架构解析

ROBOGUIDE 的虚拟控制器(Virtual Controller,简称 VC)并不是一个“简化版仿真器”,而是把真实 R-30iB / R-30iB Plus 控制器的软件内核移植到 PC 上运行。理解它的架构,关键不在于记住菜单在哪,而在于搞清楚一件事:虚拟控制器里哪些东西和真机一一对应、哪些东西是仿真环境额外补上的、哪些东西必须由我们手工配置才能与真机一致。只有把这三类分清楚,后续做离线编程、节拍评估、I/O 联调时,结果才具备可迁移性。

一、虚拟控制器与真实控制器的映射关系

真实控制器的运行依赖三块硬件:CPU 主板(运行系统软件与运动内核)、伺服放大器与电机(执行运动)、I/O 板卡与通信板卡(连接外围设备)。虚拟控制器用软件模块替代了这些硬件,但保留了相同的软件层次结构。

最底层是虚拟机器人本体与伺服模型。ROBOGUIDE 用运动学模型加动力学近似来替代真实伺服环,因此它能算出关节角度、TCP 位姿和大致节拍,但不会产生真实的伺服刚性、振动和跟随误差。这意味着:虚拟控制器验证的是“逻辑与几何正确性”,不是“动态精度”。

中间层是系统软件与运动内核,包括 TP 程序解释器、宏指令、KAREL 运行时、运动规划器。这一层与真机高度一致,所以 TP 程序、寄存器运算、位置寄存器、用户坐标系、工具坐标系的行为可以直接迁移。

最上层是外围接口层,包括 I/O 配置、现场总线、以太网通信、视觉接口等。这一层是虚拟与真实差异最大的地方:真机通过物理板卡收发信号,虚拟控制器则通过软件映射把信号接到仿真场景中的设备模型或外部程序上。

虚拟控制器与真实控制器映射架构 真实控制器(R-30iB Plus) 应用层 TP程序 / KAREL / 宏指令 系统软件与运动内核 运动规划 / 插补 / 系统变量 伺服放大器 + 电机 真实电流环 / 编码器反馈 I/O板卡 + 通信板卡 物理DI/DO / DeviceNet / EtherNet-IP 虚拟控制器(ROBOGUIDE VC) 应用层(完全一致) TP程序 / KAREL / 宏指令 系统软件与运动内核(一致) 运动规划 / 插补 / 系统变量 虚拟伺服模型(近似) 运动学 + 动力学近似,无真实刚性 软件I/O映射 + 通信仿真 映射到场景设备 / 外部程序 直接迁移 直接迁移 近似替代 需手工配置 蓝色实线 = 行为一致可直接迁移 橙色虚线 = 存在差异需重点核对

二、系统变量:虚拟与真实共享的“状态数据库”

系统变量是虚拟控制器与真机之间最可靠的桥梁。它们以 $ 开头,存放在控制器的系统数据区,虚拟控制器完整实现了这套变量体系。常用的几类包括:

  • 位置与坐标系类:$MNUTOOL[1..10] 工具坐标系、$MNUFRAME[1..9] 用户坐标系、$SCR_GRP 屏幕显示组。这些变量在虚拟控制器中修改后,可以直接导出到真机。
  • 运动控制类:$SPEED_OVR 速度倍率、$MOTYPE 运动类型、$AP_LD 负载设定。注意 $SPEED_OVR 在虚拟控制器中影响节拍计算,但真机还受伺服能力限制。
  • I/O 与通信类:$IO_ASG 相关配置、$RACK 机架分配、$DO[] / $DI[] 数字量状态。
  • 系统状态类:$MODE 运行模式、$ALARM 报警状态、$SHELL_CFG 配置参数。

实操中一个高频动作是:在虚拟控制器里用 SHIFT + COORD 或系统变量界面查看 $MNUTOOL[1],确认工具坐标系数值,然后与真机 MENU → 6 SETUP → 3 Frames 中的值逐项比对。如果虚拟端 TCP 的 X/Y/Z 与真机差了几毫米,离线程序里的接近点就会整体偏移。

三、I/O 配置:虚拟端必须“手工搭桥”

真机的 I/O 是物理存在的:一块 Process I/O 板插在机架上,RACK 0 SLOT 1 对应一组 DI/DO。虚拟控制器没有物理板卡,所以它用软件 I/O 映射来模拟:在 I/O Config 中把某个 RACK/SLOT/START 点分配给一个虚拟信号,再把这个虚拟信号绑定到仿真场景中的设备模型(如气缸、传感器、传送带)或外部程序变量。

典型配置示例(教学假设值):

RACK 0  SLOT 1  START 1  →  DO[1]  夹爪闭合
RACK 0  SLOT 1  START 2  →  DO[2]  夹爪打开
RACK 0  SLOT 1  START 3  →  DI[1]  工件到位传感器
RACK 0  SLOT 1  START 4  →  DI[2]  夹爪确认信号
RACK 1  SLOT 1  START 1  →  GI[1]  视觉系统工件编号

配置完成后,在虚拟 TP 上手动置位 DO[1],应能看到场景中夹爪模型动作;反之触发场景传感器,DI[1] 状态应变为 ON。这个“置位—观察—反馈”的闭环,就是虚拟 I/O 是否配置正确的判断依据。若信号无反应,优先检查 RACK/SLOT 是否与真机一致、信号是否被重复分配、以及仿真设备模型是否绑定了该信号。

四、运动学参数:决定虚拟轨迹是否可信

虚拟控制器的运动学参数主要来自机器人本体模型文件,包括各轴连杆长度、关节限位、最大速度、减速比、耦合关系等。这些参数在创建 ROBOGUIDE 工作单元时由所选机器人型号自动带入,但以下三类需要人工核对:

  1. 工具坐标系(TCP):虚拟端 $MNUTOOL[1] 必须与真机一致,否则所有基于 TCP 的路径都会偏移。
  2. 负载与重心:$AP_LD 中的质量、重心位置影响虚拟控制器的节拍估算和部分报警判断。
  3. 关节限位与软限位:虚拟端默认使用型号标准限位,若真机做过限位调整,需在虚拟端同步修改,否则会出现“虚拟能走、真机超限”的情况。

判断运动学参数是否可信,可以做一个简单验证:在虚拟控制器中让机器人以 JOINT 方式走到一个已知关节角组合,记录 TCP 位置;再切换到 WORLD 或 TOOL 方式走同一位置,比较两者是否一致。若偏差明显,说明工具坐标系或用户坐标系设置有误。

五、通信接口:虚拟端支持的仿真通道

虚拟控制器支持多种通信仿真方式,常见的有:

  • EtherNet/IP 与 PROFINET:通过 ROBOGUIDE 的通信仿真模块,把虚拟控制器作为从站或主站接入仿真网络,与 PLC 仿真软件(如 Studio 5000、TIA Portal)交换 I/O 数据。
  • Socket Messaging / TCP-IP:虚拟控制器可以像真机一样通过 OPEN、WRITE、READ 指令与外部程序通信,适合验证上位机与机器人的数据交互逻辑。
  • OPC UA:部分版本支持,用于与 MES 或数据采集系统对接。

通信配置的关键是端口号、IP 地址、数据长度和字节序四项必须与真机一致。虚拟端调试通过后,把配置导出为 .IO 或 .CFG 文件,再导入真机,可以大幅减少现场调试时间。

虚拟控制器与真机的一致性检查,建议按“系统变量 → 工具/用户坐标系 → I/O 映射 → 通信参数”的顺序逐项核对。前三项决定程序能否正确运行,第四项决定能否与外围设备联调。
虚拟控制器的节拍结果不能直接当作真机节拍。虚拟伺服模型没有真实加减速能力和机械刚性,通常虚拟节拍会偏乐观。若用于产能评估,建议在虚拟节拍基础上乘以 1.1~1.3 的修正系数,并以真机实测为准。

把以上五块内容串起来看,虚拟控制器的架构本质是:软件层与真机同源,硬件层用仿真替代,接口层靠手工映射。凡是与程序逻辑、坐标系、系统变量相关的,可以放心在虚拟端验证;凡是与伺服动态、物理 I/O、实时通信相关的,必须明确虚拟端的近似边界,并在真机上做最终确认。