4. PLC编程环境

在施耐德机器人与PLC协同控制的项目中,EcoStruxure Control Expert(下文简称 Control Expert)是M580、M340等Modicon系列PLC的官方编程与组态平台。机器人协同控制的成败,往往在写第一行逻辑之前就已经被决定:CPU型号是否选对、通信模块是否插在正确的槽位、IP地址是否与机器人控制器处于同一网段、变量是否按数据类型规范命名、通信功能块是否被正确实例化。本节围绕“硬件组态—变量定义—通信功能块调用”这条主线,把Control Expert中真正需要动手做的关键环节讲清楚。

一、硬件组态:先把“物理存在”映射成“软件对象”

硬件组态的本质,是在Control Expert的项目浏览器 → 配置 → 0:PLC总线中,把实际机架上的模块逐一“声明”出来。以典型的M580单机架为例:槽位0固定为CPU(如BMEP582040),槽位1可放以太网通信模块(如BMENOC0301),后续槽位放DI/DO/AI等I/O模块。每添加一个模块,Control Expert都会为其分配一个逻辑地址,例如数字量输入模块的通道地址形如 %I0.2.0,其中0表示机架号、2表示槽位号、最后的0表示通道号。这个地址规则是后续变量定义和程序引用的基础,必须先理解再动手。

机器人协同控制最关键的组态对象是以太网通信。若使用Modbus TCP,通常由CPU自带的以太网口或BMENOC模块承担;若使用EtherNet/IP与机器人(如部分施耐德/第三方机器人控制器)通信,则需要选择支持EtherNet/IP的通信模块。组态时需要设置:模块的IP地址、子网掩码、网关,以及是否启用DHCP。工程实践中强烈建议关闭DHCP、使用静态IP,因为机器人控制器侧的连接参数通常是固定配置的,PLC侧若动态获取地址会导致连接不稳定。

IP规划示例(教学假设):PLC通信模块 192.168.10.10/24,机器人控制器 192.168.10.20/24,两者同网段、无网关跨网段需求。子网掩码统一为255.255.255.0。这类参数属于示例,实际项目须以现场网络规划为准。

组态完成后,必须执行“生成 → 重新生成项目”或直接“生成全部”,让Control Expert校验配置一致性。若模块型号与实际不符、槽位冲突或地址越界,生成阶段就会报错,这是最早、成本最低的纠错时机。

Control Expert 机器人协同控制组态与通信链路 0:PLC总线(机架) 槽0 CPU BMEP582040 槽1 以太网 BMENOC0301 槽2 DI 16点 %I0.2.0~ 槽3 DO 16点 %Q0.3.0~ 以太网通信参数 PLC IP:192.168.10.10 / 24 机器人 IP:192.168.10.20 / 24 协议:Modbus TCP / EtherNet/IP DHCP:关闭(静态地址) 变量定义(数据字典) 名称 类型 地址/说明 Robot_Start BOOL %M100 启动命令 Robot_Ready BOOL %M101 就绪反馈 Robot_Pos_X REAL %MD200 X坐标 Robot_Speed INT %MW300 速度% Robot_Status WORD %MW302 状态字 Robot_Alarm BOOL %M102 报警位 通信功能块调用 READ_VAR / WRITE_VAR Modbus TCP 读写机器人寄存器 OBJ: {‘0.1.0’} · 从站地址 · 寄存器号 DATA_EXCH / SEND_REQ EtherNet/IP 显式报文交换 连接路径 · 服务码 · 数据区 输出:Done / Error / CommError 变量 绑定

二、变量定义:让程序“看得懂”机器人数据

硬件组态完成后,进入数据编辑器定义变量。Control Expert支持直接地址变量(如 %M100)和符号变量(如 Robot_Start)。工程上推荐“符号名 + 地址”双轨方式:符号名用于程序可读性,地址用于与机器人寄存器建立确定映射。变量类型必须与机器人侧数据严格对应——机器人发送的32位浮点位置数据,PLC侧应定义为REAL并占用 %MD 双字;机器人状态字若为16位,则定义为WORD或INT并占用 %MW 单字。类型不匹配是通信“看似连上、数据却乱跳”的最常见原因。

建议按功能分区命名,例如以 Robot_ 前缀统一标识机器人交互变量,以 Cell_ 前缀标识工位变量。这样在功能块调用时,输入输出引脚能一眼对应到物理含义,减少接线式排错时间。

三、通信功能块调用:把变量真正“送出去、收回来”

Control Expert中Modbus TCP通信最常用的是 READ_VAR 和 WRITE_VAR 功能块。以读取机器人当前位置为例,调用形式如下:

READ_VAR(
  ADDR := '0.1.0',        (* 机架0.槽1.通道0 以太网口 *)
  OBJ  := 'MBS',          (* Modbus 从站对象 *)
  NUM  := '192.168.10.20',(* 机器人控制器IP *)
  NB   := 4,              (* 读取4个寄存器 *)
  REG  := 100,            (* 起始寄存器号 *)
  DATA := %MW400:4,       (* 接收数据区 *)
  DONE => Robot_Read_Done,
  ERROR => Robot_Read_Err
);

这里 ADDR 的写法必须与硬件组态中通信模块的实际位置一致,NUM 是机器人控制器的IP,REG 与机器人侧寄存器映射表对应,DATA 指向PLC内部数据区。功能块执行后,通过 DONE 和 ERROR 两个输出引脚判断本次通信是否成功。若 ERROR 为1,还需读取 CommError 或功能块管理字进一步定位是超时、从站无响应还是寄存器越界。

功能块调用必须放在周期性执行的任务(如MAST)中,且同一通信链路不宜在同一扫描周期内并发发起过多请求。建议用状态机或轮询方式分时调用,避免通信资源争用导致间歇性超时。

四、从组态到联调的判断依据

完成上述三步后,可按以下顺序验证:第一,生成项目无错误;第二,将程序下载到PLC并切换到运行;第三,在Control Expert的动态数据表中监视 Robot_Ready、Robot_Status 等变量是否随机器人状态变化;第四,观察 READ_VAR 的 DONE 位是否周期性置位、ERROR 是否保持为0。若 DONE 始终不置位且 ERROR 为1,优先检查IP连通性(可用ping测试)和 ADDR 地址是否与组态一致;若 DONE 置位但数据异常,则回到变量类型与寄存器映射表核对。这套“组态—变量—功能块—监视”的闭环,是机器人协同控制能否进入下一步逻辑编程的判定门槛。