S7-1200通过FB284控制V90伺服与FANUC机器人DP通讯的实战解析

做自动化这些年我越来越觉得“多设备协同”才是项目调试里最考验人的环节。这个项目属于典型的机加工自动线场景西门子S7-1200做主控PLC通过PROFINET总线用FB284SINA_POS功能块控制3台V90伺服负责工件的位置调整和旋转角度修正视觉相机把检测到的角度偏差发给PLCPLC把偏差折算成伺服的位置修正量同时PLC通过DPPROFIBUS-DP和FANUC机器人交换握手信号让机器人准确地取走修正后的工件。整套配置听起来就是“PLC伺服视觉机器人”的标准四件套但真跑起来报文选错、PZD映射错位、DP从站掉线、握手时序卡死任何一环出问题都能让整线停摆。这篇文章把我从选型、组态、接线到联调的完整过程梳理出来重点把FB284的配置细节和DP通讯的坑讲透给正在做或准备做类似项目的同行一个能直接参考的底稿。1. 项目架构与通讯选型为什么PROFINET跑伺服、DP接机器人1.1 设备清单与系统拓扑先摆一下这套系统的实际配置方便后面讲细节时对照。主控PLCS7-1215C DC/DC/DC自带2个PROFINET口固件4.4以上伺服驱动3台SINAMICS V90 PN配1FK2系列电机功率都在1kW以下机器人FANUC R-30iB控制器带PROFIBUS DP从站选件和对应的DP接口卡视觉系统智能相机Cognex或Keyence这类通过PROFINET或以太网TCP和PLC交换数据DP扩展模块CM 1241-5插在PLC左侧扩展槽作为DP主站网络拓扑很清晰3台V90直接挂在S7-1200的PROFINET口上中间加一台普通交换机也无所谓反正三台伺服加起来的数据量不大FANUC机器人那头从CM 1241-5引出PROFIBUS-DP总线机器人作为DP从站挂在总线上相机走独立以太网或直接也挂PROFINET看选型。要注意的是S7-1200本体没有DP口想和FANUC机器人走PROFIBUS-DP就必须加CM 1241-5没有别的捷径。这个项目现场还有一个特点是老线改造原来机器人的DP接口已经在那条产线上跑了好几年稳定性经过验证所以机器人侧接到DP总线上是很自然的选择。伺服侧就不一样了V90 PN本身就是自带PROFINET的走DP反而需要额外加网关纯属多此一举。1.2 通讯方案选型的底层逻辑选PROFINET带伺服核心原因是实时性和数据量。现场3台V90要做的是位置同步动作PROFINET的等时同步模式能把总线周期压到1ms甚至更低位置设定值、实际位置、状态字这些数据每个周期都要刷新一遍PROFINET的带宽和刷新能力完全够用。而FANUC机器人这边的交互本质上是数字量级别的握手信号比如“允许取料”“取料完成”“报警复位”这些再配几个字节的状态数据用DP通讯绰绰有余。杀鸡不用牛刀机器人走DP成本低、稳定还省PLC的PROFINET资源。再说深一层为什么不把机器人的开集信号直接用硬接线解决因为除了开关量还需要传故障代码、节拍计数、工件ID这类数据硬接线只能传个通断传不了数据。DP通讯传32字节输入输出什么状态位、报警码都能塞进去后续扩展也不用在柜子里加线。硬接线只留了急停和门锁这种安全回路数据交互全部走总线这个原则我一直坚持。2. FB284控制3台V90从报文到参数一次讲透2.1 FB284SINA_POS到底是什么FB284在西门子的库里叫SINA_POS是专门给SINAMICS系列驱动用的位置控制功能块。它做的事情就是把你想要的“位置、速度、运行模式”打包成SINAMICS标准的PZD报文通过PROFINET发给V90再把V90返回的状态字、实际位置、实际速度解包出来。V90工作在EPOS基本定位模式下内部自己完成位置环和速度环的闭环PLC只负责下命令和读状态。有人可能会问为什么不自己拼PZD字我也试过技术上完全可行但自己拼报文要处理控制字的每一位、状态字的每一位还要同步发送接收逻辑一个位搞错设备就报故障。FB284把这些封装好了你只要管“模式、位置、速度、使能、复位”这几个接口就行省下的时间够你调好几轮视觉了。从西门子官网或者TIA的库里拖出FB284就能用库版本要和你TIA版本匹配这个细节别忽略。2.2 V90驱动器侧的关键配置V90侧的配置是很多新手栽跟头的地方。我建议用V-ASSISTANT这个软件来做比在Startdrive里折腾更直观。流程是这样的V90断电状态下接好PROFINET线打开V-ASSISTANT在线连接驱动器给每台驱动分配PROFINET设备名称和IP地址比如v90-axis1、v90-axis2、v90-axis3设备名就是后面TIA里组态要用的名字千万别重复把工作模式设为“位置控制EPOS”报文类型选SIEMENS telegram 111这是FB284做位置控制时最常用的报文设置机械参数电机每转的LU数、负载齿轮比。举例来说旋转轴直接带工件转台减速比10:1电机每转10000 LU那负载转一圈就是100000 LU1 LU对应0.0036度参数下载到驱动器后断电重新上电才完全生效这里有个残酷的现实教训我第一次配的时候忘了给V90分配设备名称TIA里怎么都找不着设备在线诊断一直报“设备名称不匹配”。V90对设备名称极其敏感名称不一致就是通讯不上没有商量余地。2.3 TIA Portal里的FB284调用与参数映射TIA侧的事情分两步先在设备视图里组态3台V90把GSDML文件装好把设备拖到PROFINET网络里分配好设备名然后在程序里调用FB284。调用FB284需要给每一台V90准备一组轴数据我习惯建一个全局DB里面放3个相同的结构体每个结构体包含AxisIn、AxisOut、ConfigEPos、Status这些要素。这样3台伺服的数据结构一眼就能对上查故障的时候不用翻三个不同的DB。FB284的调用SCL写出来大概是这个样子// 轴1调用示例绝对定位模式 FB284_Axis1( EnableAxis : Ctrl.Axis1_Enable, ExecuteMode : 2, // 2绝对定位1相对定位3连续速度 Position : VisionDB.Theta_Target, // 目标位置单位LU Velocity : 9000, // 运行速度单位LU/min OverV : 100, // 速度百分比 ErrorAck : Ctrl.Axis1_ErrorAck, AxisIn : AxisData.Axis1.AxisIn, AxisOut : AxisData.Axis1.AxisOut, Config : AxisData.Axis1.ConfigEPos );注意几个关键输入的含义。EnableAxis要用上升沿触发我踩过坑一直给高电平设备偶发重新上电后轴没反应就是因为使能信号保持但功能块内部状态没复位。ExecuteMode选择上角度纠偏我推荐用绝对定位mode 2因为它不会累积误差每轮视觉检测完直接发绝对目标位置干净利落。Position的单位是LU不是电机转数这个要结合V90组态里的LU设置一起理解。Velocity给的是LU/min同样别和rpm搞混。2.4 多轴数据组织与使能细节3台V90分别用3个FB284实例背景DB如果用单独的背景块会占很多DB资源建议用多重背景方式或者像我一样搞一个全局轴数据DB把3套轴的所有数据都放进去。这样程序里做“三轴全部到位”的判断也很方便整个数据块变量一次看完。使能时序上我习惯在PLC启动后做一个统一的轴使能逻辑急停回路OK、驱动无故障、抱闸打开这三个条件全部满足后才给EnableAxis上升沿。调试阶段最烦的就是驱动报抱闸故障其实往往是使能时序没理清V90的抱闸逻辑和使能信号之间的配合要按手册来。另外轴数据的掉电保持非常重要特别是用到绝对定位的项目恢复供电后PLC里断电丢失的轴位置和V90内部的位置不一致第一轮定位就会出问题。把轴数据DB属性里的“保持”勾上免得吃暗亏。3. 三轴联动与相机角度修正的实现逻辑3.1 三台伺服的分工与坐标换算这套系统的3台伺服不是3个一模一样的轴而是有明确分工的。轴1和轴2负责XY平面内的位置调整把工件搬到视觉检测的理想位置附近轴3是旋转轴也就是θ轴专门负责绕工件中心旋转来消除角度偏差。位置偏差和角度偏差是两类不同的修正量放在不同轴上去执行逻辑上互不干扰也方便单独调试。坐标换算方面关键是搞清楚LU和实际角度的关系。前文设了电机每转10000 LU负载减速比10:1所以负载旋转轴转一圈对应100000 LU。相机给的角度偏差如果单位是度换算公式就是修正位置 角度偏差 / 360 × 100000。比如相机测出工件角度偏了2.5度那旋转轴需要走的位置就是2.5 / 360 × 100000 ≈ 694.4 LU。V90的位置设定只接受整数LU取整到694 LU剩下的0.4 LU折算成角度也就0.0014度左右对这个场景完全够用。3.2 相机拍照、角度偏差计算与补偿写入相机和PLC的配合是这套系统的灵魂。我用的方案是PLC硬接线给相机一个触发输入工件被XY轴搬到拍照位停下后PLC输出一个10ms左右的触发脉冲。相机识别出工件轮廓计算角度然后通过交换数据区把角度值写回PLC。PLC这边在视觉DB里做一个“数据有效”标志相机写完数据就把标志置TRUEPLC看到标志才去读角度读完清零。这样保证PLC读到的永远是新鲜数据不会读到上一轮的旧值。这里有一个特别容易忽略的细节相机坐标系和伺服旋转方向可能不一致。相机里的角度正方向如果和轴3的实际旋转方向相反直接套公式会让偏差越纠越大。我第一次联调就遇到了相机显示正2度轴3往正方向转了结果工件更歪了。解决办法是做个符号翻转在换算公式里乘一个方向系数正负取决于现场安装。更稳妥的做法是做一个反方向校准程序手动给轴3一个固定角度偏差拍照确认方向再把方向系数固化到视觉DB里。角度修正的执行我坚持用绝对定位。有些同行喜欢用相对定位做增量修正每轮只转Δθ看似简单但一旦某轮视觉误判增量方向反了后面所有轮次都会在错误的基础上继续累积最终角度乱套。绝对定位每一轮都以“0度”或者某个固定基准角为参照视觉数据出问题顶多当前周期位置偏了下一轮还能纠正回来。3.3 节拍优化与多轴到位判定节拍是整个自动线的生命线。我做的第一个版本是工件到位→拍照→计算→伺服动作→机器人取料一套流程走下来节拍偏慢。后来改成流水线式上一件工件在机器人手边取料的同时相机已经在拍下一件工件了。只需要把相机的触发时间点提前到工件还在XY轴上的时候并把角度值缓存到视觉DB等上一件处理完直接读取缓存的角度做修正。这样拍照时间被完全掩盖在机器人取料节拍里整线节拍大概提了20%。多轴到位判定也是容易出问题的地方。3台伺服同时启动因为负载不同、加减速参数不同到位时间本来就不会完全一致。机器人放行信号不能只看某一根轴到位必须等3个轴的“到位”状态全部为真。我在PLC里写了一个简单的与逻辑轴1到位 AND 轴2到位 AND 轴3到位再输出“放行允许”。而且FB284里面判断到位用的是AxisBusy信号下降沿或者直接读状态字的“定位完成”位这两个方式都要经过实际验证我遇到过AxisBusy已经变FALSE但实际位置还没稳的情况把定位完成位加上一起判断更可靠。4. DP通讯控制FANUC机器人的实施记录4.1 S7-1200挂DP主站与GSD安装FANUC机器人要走DP通讯PLC侧先要把CM 1241-5模块组态成DP主站。TIA里添加模块后设置波特率和站点参数波特率一定要和机器人侧设成一致这个看起来无脑但我真见过两侧一个设1.5M一个设12M怎么都连不上的情况。然后是GSD文件。FANUC机器人当DP从站需要机器人控制器的Profibus从站GSD文件这个文件通常在FANUC机器人随机资料里或者机器人系统软件的光盘/U盘中有实在找不到可以联系FANUC售后服务获取。在TIA里安装GSD文件后把FANUC从站拖到DP总线上分配一个站号比如3号站然后配置I/O长度。我这边的做法是PLC输出32字节给机器人机器人输入32字节回PLC够传状态位、报警码和简单的数据了。4.2 FANUC机器人从站配置与地址映射FANUC机器人侧硬件上要装Profibus DP从站接口卡软件上要选装“DP SLAVE”功能选项不是标配功能采购的时候要提前确认。在机器人示教器上进入Profibus设置界面把站号、波特率设置成和PLC侧一致然后做IO映射把DP数据区映射到机器人的内部寄存器或IO。这里我吃过大亏FANUC的Profibus从站I/O映射和PLC组态的字节偏移可能对不上。PLC组态的输出第0字节是“启动信号”机器人映射表里第0字节可能被系统预留了真正应用数据从第16字节开始。联调时一定要先在机器人示教器上查看实际映射表和PLC侧组态的I/O地址逐字节核对。我建议做一张信号对照表写清楚PLC地址、机器人地址、信号名称、方向双方调试工程师一人一份能省掉大量扯皮时间。4.3 握手状态机与联调时序机器人交互最忌讳你发一个“允许取料”信号机器人那边还没反应过来PLC又因为超时把信号收回了。我后来在PLC里写了一个简单的状态机用Step变量管理整个交互流程Step 0等待机器人发“就绪Ready”信号Step 1PLC检查三轴到位、相机OK、无报警置位“允许取料AllowPick”Step 2机器人收到AllowPick后开始取料完成后发“取料完成PickDone”Step 3PLC收到PickDone复位AllowPick同时给下一轮修正信号Step 4机器人回到等待位置发“已就位HomeOk”PLC把Step清零循环这套状态机的关键是信号的方向和时序必须严格一致谁先谁后错一步都会卡死。我在联调时遇到过最典型的死锁PLC在Step 2等PickDone机器人却因为在Step 1没等到AllowPick的下降沿而一直不动作。双方都在等对方的信号本质上是信号动作沿没对齐。解决办法是全部用脉冲沿触发在PLC侧用上升沿检测机器人信号机器人侧也要求它对PLC信号做沿触发避免电平互锁。调试DP通讯时发现一个实用技巧TIA在线诊断里看CM 1241-5下的从站状态如果显示“无响应”先别怀疑机器人用万用表量一下DP总线A、B线之间的终端电阻确认总线头尾终端电阻是否都打到ON。DP总线对终端电阻的敏感程度远超你的想象。5. 常见故障与排查技巧实录5.1 伺服与PROFINET链路问题先说V90在TIA设备列表里显示黄色感叹号的问题。这百分之八九十是设备名称不一致用V-ASSISTANT重新分配一次设备名断电重启V90再在TIA里在线分配一次基本能解决。FB284报错是另一个高频问题。ErrorID如果指向“驱动未使能”这一类的排查顺序是急停回路是否闭合、驱动是否有报警、EnableAxis是否有上升沿。我遇到过现场电工接错急停线路导致驱动一直处于禁止使能状态FB284看得见但就是使能不了。还有一个常见错误码是通讯超时多半是PROFINET电缆太长或者用了劣质网线V90这级别对网线质量要求不低省线缆钱的教训至今难忘。位置漂移的问题也值得说一下。表现为轴实际走过的位置和PLC下发的位置总差一截通常是LU换算或齿轮比设错。V90组态里“电机每转LU数”和“负载齿轮比”这两项任何一个不对位置都会偏。用绝对定位模式时如果PLC侧断电保持没做重新上电后位置基准丢失也会出现位置突然不对的现象这个前面强调过再提一次。5.2 DP通讯与机器人交互问题DP从站掉线的经典原因我见过几种波特率不一致、总线终端电阻没设、屏蔽层接地不良、两个从站的总线距离太长且没有中继器。FANUC机器人和PLC之间如果距离超过100米建议加DP中继器现场实际距离不长的话把屏蔽层单端接地做好就够。还有一种情况不是真掉线而是机器人侧Profibus接口卡的后备电池没电了。FANUC的Profibus从站设置有时存在电池供电的RAM里电池没电重启后站地址变成默认值或丢失PLC这边就看着从站像掉线了一样。这个坑很隐蔽排查到最后发现是电池问题换个电池重新设一遍地址就好。机器人和PLC的交互数据映射错位也是排队遇到了几次。现场改了机器人IO表但PLC侧的组态没同步更新两边地址对不上表现为“有信号没反应”或者“没动作却收到信号”。所以每次改机器人程序或PLC组态都要拿信号对照表重新核对一遍这个动作千万别省。5.3 视觉纠偏与协同逻辑问题拍照超时是视觉协同里最闹心的问题。常见原因是触发信号被噪声干扰或者相机曝光时间太长。我在相机触发输出端加了一个24V继电器中转再给PLC输入做硬件滤波超时次数明显减少。如果相机通讯本身不稳定要在PLC里做超时处理到时间没收到有效数据直接判不良品不许伺服动作防止视觉数据缺失导致设备乱跑。角度偏差方向相反的问题前文提到过核心是坐标系对齐。我当时用了一个笨办法在工件上画一条明显基准线手动旋转轴3正方向10度拍照看一下相机输出的角度是正还是负。一旦确认方向在换算公式里加一个符号系数并把这个系数写进参数表后续换相机或者改造都不用再改程序。还有一个视觉和伺服之间的系统误差问题。相机检测角度、伺服定位、机械夹具夹持这三者之间会有一个固定的机械误差和通讯延迟误差。相机和PLC交换数据有几十毫秒的延迟伺服执行也有建立时间这些加起来会形成角度偏差的固定偏置。解决办法是做一个静态补偿跑几个标准工件算出平均误差把它作为补偿值写进视觉DB实测下来纠偏精度能提一个档次。5.4 调试工具与通用排查思路调试这套系统我常用的工具是TIA在线诊断加变量监控表。V-ASSISTANT拿来监控V90内部的当前报文能看到PLC到底发了哪些数据过来机器人示教器上看机器人的IO状态页三方对照信息就很全了。排查顺序我固定在先通讯后运动先确认PROFINET和DP链路是通的再确认每个轴的数据交换是正常的最后才让设备跑起来。链路不通就去查物理层数据不对就去查组态和映射表不要一上来就怀疑程序逻辑。程序逻辑通常是最后才发现的问题前面大多数坑都在通讯和配置上。我个人在实际调试中的体会是这种多设备协同项目最值钱的就是信号对照表和时序状态机。把每一条通讯信号、每一个Step转换条件都写成文档前期花半天整理后面联调能省好几天。最后再分享一个小心得每次改完配置PLC程序和所有设备的备份一定要按日期命名存好现场版本的混乱比设备故障更可怕这个习惯救过我很多次。