1. 两台PLC合并为一台到底在解决什么问题车间里设备越加越多控制柜里的PLC从一台变成两台、三台这种情况太常见了。最初一台1214可能只控制一条输送线后来旁边加了台包装机又塞了一台1214进去再后来要加视觉检测、要加机器人对接柜子里已经快放不下了。两台PLC各自为政数据不通操作工要跑两个触摸屏维护人员要连两根网线程序改一处还得两边同步——这种日子过久了谁都会想能不能把两台并成一台来用这个需求的核心其实不是物理上把两个CPU模块焊在一起而是让两台PLC在逻辑上像一台那样协同工作。操作层看到的是一个统一的画面控制层的数据是打通的维护层只需要面对一个编程入口。而实现这个目标最直接、最经济的手段就是利用PLC自带的PN通讯PROFINET通讯能力把其中一台配置成智能IO设备挂到另一台下面当从站。这里涉及几个关键词需要先理清楚。PN通讯是西门子主推的工业以太网标准1214这款CPU自带PN接口支持实时通讯和智能设备功能。智能IO是PROFINET里的一种设备角色它本身是一个可编程的CPU但在通讯关系上作为IO设备挂到另一个控制器下面。UDT则是用户自定义数据类型在合并过程中用来统一两边数据结构的利器。这几个概念串起来就是两台1214合并成一台的完整技术路径。适合读这篇内容的人我大致分三类一是手上正好有两台1214需要整合、不想换CPU的现场工程师二是刚开始接触PROFINET智能设备配置、想找个完整案例练手的编程人员三是做系统集成方案、需要评估这种合并方式可行性和工作量的技术人员。不管你是哪一类下面的内容都会从原理到操作、从配置到避坑一步步拆开讲。注意本文以西门子S7-1200系列1214C DC/DC/DC为例展开固件版本建议V4.0以上TIA Portal版本V15及以上。不同固件和软件版本在菜单名称上可能有细微差异但核心逻辑一致。2. 为什么选智能IO而不是其他合并方案2.1 几种常见合并思路的对比在动手之前先把可选路径摆出来对比一下免得走弯路。两台PLC要“合并”业内常见的做法有这么几种方案实现方式优点缺点适用场景智能IO设备一台作控制器另一台作智能设备挂载实时性好编程统一无需额外硬件需要配置传输区数据量受限于IO通讯两台距离近数据交互频繁PUT/GET通讯两边都作控制器通过指令读写配置简单不需要改设备角色实时性差编程量大需处理握手数据交互少非实时场景Modbus TCP通过开放式通讯建立连接跨品牌兼容需要额外编程实时性一般不同品牌PLC之间换一台大CPU直接替换成1500或更大规格一劳永逸成本高程序移植工作量大预算充足长期规划从表里能看出来智能IO方案在实时性、编程统一性和成本之间取得了最好的平衡。两台1214本身就有PN接口不需要加任何硬件配置工作量主要集中在TIA Portal里的几步设置上。而且一旦配好从站CPU的IO数据会像本机IO一样出现在控制器的地址区里编程体验几乎和一台PLC无异。2.2 智能IO的底层逻辑智能IO的本质是让一个CPU在PROFINET网络中扮演双重角色。它既是一个可独立编程的CPU能跑自己的程序同时又是一个IO设备接受控制器的数据交换请求。控制器和智能设备之间通过传输区来交换数据传输区本质上就是一块映射地址控制器这边看到的是输入/输出地址智能设备那边看到的也是输入/输出地址两边地址一一对应。举个例子控制器要把一个启动信号发给智能设备就在控制器侧定义一个输出传输区在智能设备侧定义一个对应的输入传输区。控制器写这个输出地址智能设备就能在自己的输入地址里读到。反过来智能设备采集到的传感器信号通过它自己的输出传输区发给控制器控制器在自己的输入地址里就能读到。这种机制的妙处在于编程时不需要关心通讯细节。你不需要写通讯指令不需要处理握手数据就像本机IO一样自动刷新。对于习惯直接读写IO的工程师来说几乎没有学习成本。2.3 1214做智能设备的限制条件不过1214做智能IO设备有几个硬性条件需要提前确认。第一固件版本必须支持智能设备功能V4.0以上都支持但早期V3.x可能没有这个选项。第二智能设备功能需要授权在某些TIA Portal版本里智能设备功能属于选件需要确认你的授权包含这一项。第三传输区数据量有限制1214作为智能设备时输入和输出各最多1440字节对于大多数应用来说绰绰有余但如果要传大量数据需要评估是否够用。还有一个容易被忽略的点智能设备不能同时作为控制器和智能设备与同一个控制器通讯。也就是说如果1214A已经作为智能设备挂到了1214B下面那1214A就不能再作为控制器去控制其他设备了——至少在这个PN网络中是这样。这一点在规划网络拓扑时要提前想清楚。3. 从零开始配置两台1214的PN智能IO通讯3.1 硬件接线与网络规划先做物理层的事情。两台1214C各有一个PN接口RJ45用标准网线把两台PLC的PN口连起来就行。如果现场有交换机也可以都接到交换机上但直连是最简单可靠的方式少一个故障点。网络规划方面建议给两台PLC分配同一网段的固定IP。比如控制器1214A192.168.0.1子网掩码255.255.255.0智能设备1214B192.168.0.2子网掩码255.255.255.0提示不要用DHCP工业现场固定IP更可靠。IP地址规划好之后在TIA Portal里直接设置不要依赖路由器分配。设备名称也很关键。PROFINET靠设备名称来识别设备所以两台PLC都要起一个有意义的名字比如“PLC-Main”和“PLC-Expansion”。设备名称在TIA Portal里设置下载后生效。3.2 在TIA Portal中组态智能设备打开TIA Portal新建项目添加两台1214C。假设我们把1214A作为控制器1214B作为智能设备。第一步配置1214B的智能设备功能。在设备视图中双击1214B的PN接口找到“操作模式”选项卡勾选“IO设备”选项。这时会出现一个“已分配的IO控制器”下拉框先不选等会儿在控制器那边分配。第二步定义传输区。在1214B的PN接口下找到“智能设备通讯”或者直接在设备概览里添加传输区。传输区的定义方式是选择方向输入/输出设置地址和长度。比如传输区1控制器输出到智能设备输入地址IB100长度10字节传输区2智能设备输出到控制器输入地址QB100长度10字节这里的地址是智能设备侧的地址控制器侧的对应地址会在组态时自动生成。第三步配置1214A。在1214A的设备视图中打开“设备与网络”视图把1214B拖到1214A的PN接口上。这时TIA Portal会自动建立控制器与智能设备的连接关系。然后在1214A的智能设备属性里确认传输区的对应地址。3.3 传输区地址的对应关系传输区地址的对应关系是初学者最容易搞混的地方。我用一个表格来说明方向智能设备侧地址控制器侧地址数据流向控制器→智能设备输入IB100输出QB100控制器写QB100智能设备读IB100智能设备→控制器输出QB100输入IB100智能设备写QB100控制器读IB100注意两边地址看起来一样但方向是相反的。控制器侧的QB100对应智能设备侧的IB100控制器侧的IB100对应智能设备侧的QB100。这个对应关系在组态完成后TIA Portal会自动在控制器侧生成系统常数编程时直接用这些常数就行不需要记地址。3.4 下载与在线验证配置完成后分别下载两台PLC。下载顺序建议先下载智能设备再下载控制器。下载智能设备时TIA Portal会提示是否分配设备名称确认分配。下载控制器后在“在线与诊断”里查看两台PLC的通讯状态。如果一切正常控制器侧的智能设备图标会变成绿色表示通讯建立。这时可以在控制器程序里写一个测试把QB100的第一个字节置1然后在智能设备的监视表里看IB100的第一个字节是否变成1。如果变了说明通讯链路通了。注意下载智能设备程序时如果设备名称没有正确分配控制器会找不到设备。这时需要在“在线访问”里手动分配设备名称或者检查两台PLC是否在同一网段。4. UDT在合并过程中的实际用法4.1 为什么需要UDT两台PLC合并之后数据交互会变得频繁。如果每次传输都用一个字节一个字节地拼程序会变得又长又乱。UDT的作用就是把一组相关的数据打包成一个类型在两边定义相同的UDT然后传输区直接映射这个UDT编程时按结构体访问清晰又高效。举个例子智能设备那边有10个气缸每个气缸有“伸出”和“缩回”两个信号还有“伸出到位”和“缩回到位”两个反馈。如果不用UDT传输区里要定义40个位编程时得记住每个位的含义。用UDT的话定义一个“气缸控制”类型包含4个布尔量然后定义一个包含10个该类型的数组传输区直接映射这个数组编程时用“气缸[3].伸出”这样的方式访问一目了然。4.2 定义UDT的步骤在TIA Portal的项目树里找到“PLC数据类型”双击“添加新数据类型”命名为“typeCylinder”。然后添加四个布尔变量extendCmd、retractCmd、extendedFb、retractedFb。保存后这个UDT就可以在程序里使用了。在智能设备侧定义一个DB块比如“DB_CylinderData”里面放一个“typeCylinder”的数组长度10。在控制器侧也定义一个同名的DB块结构完全一样。然后在传输区里把智能设备的输出传输区映射到“DB_CylinderData”控制器侧的输入传输区也映射到对应的DB块。4.3 UDT使用中的坑UDT用起来方便但有几个坑要注意。第一两边的UDT必须完全一致包括变量名、数据类型、顺序。如果一边改了另一边没改通讯数据会错位而且不会报错只是数据不对。第二UDT的版本管理如果项目后期要修改UDT两边必须同时修改并重新下载否则会出现数据解析错误。第三UDT不能包含复杂数据类型比如字符串、数组嵌套等在智能设备通讯里支持有限建议只用基本数据类型。我个人的经验是在项目初期就把UDT定义好并且写一个文档记录每个UDT的用途和对应关系。后期维护时这份文档能省很多事。5. 合并之后程序怎么改才不乱5.1 程序结构的重新划分两台PLC合并之后程序结构需要重新梳理。原来的两台PLC各自有主程序、子程序、中断程序合并后如果直接把两套程序塞进一个CPU会非常混乱。建议按照功能模块重新划分而不是按照原来的设备归属划分。比如原来1214A负责输送线1214B负责包装机。合并后可以分成“输送控制”、“包装控制”、“通讯管理”、“报警处理”几个功能块每个功能块内部再细分。这样程序结构清晰后期扩展也方便。5.2 智能设备侧程序的注意事项智能设备侧的CPU虽然作为从站但它仍然在跑自己的程序。这意味着智能设备侧的扫描周期和控制器是独立的。控制器写过来的数据智能设备要等到下一个扫描周期才能读到智能设备写出去的数据控制器也要等到下一个周期才能读到。这个延迟通常在几毫秒到十几毫秒之间对于大多数应用来说没问题但对于高速同步要求的场景需要评估是否满足。另外智能设备侧的程序里不要直接读写传输区地址而是通过DB块来访问。这样如果传输区地址变了只需要改DB块的映射不需要改程序逻辑。5.3 控制器侧程序的统一入口控制器侧的程序是主程序所有逻辑判断、人机交互、报警处理都在这里。智能设备侧的数据通过输入传输区进来控制器处理后通过输出传输区发回去。建议在控制器侧写一个专门的“通讯处理”功能块把所有传输区的读写都封装在里面其他功能块只调用这个功能块的接口不直接访问传输区地址。这样做的好处是如果以后传输区地址调整了或者增加了新的传输区只需要改这一个功能块其他程序不受影响。6. 实测中遇到的典型问题与排查过程6.1 通讯建立但数据不刷新第一次配置的时候我遇到过通讯状态显示正常但数据死活不刷新。在线诊断里看智能设备是绿的连接也建立了但控制器写QB100智能设备IB100就是不动。排查过程是这样的先确认传输区地址有没有写错检查了一遍没问题。然后怀疑是DB块映射的问题把传输区直接映射到物理地址不经过DB块发现数据能刷新了。这说明问题出在DB块的优化访问上。1214的DB块默认是优化访问的优化访问的DB块不能直接用于传输区映射需要把DB块的属性改成“非优化访问”或者使用绝对地址访问。改完DB块属性后数据刷新正常。这个坑我踩过不止一次后来养成了习惯凡是用于通讯映射的DB块一律取消优化访问。6.2 设备名称冲突导致无法连接还有一次现场有两台1214设备名称都叫“PLC_1”结果控制器怎么都连不上智能设备。PROFINET靠设备名称识别名称冲突就会导致连接失败。解决办法是给每台PLC起唯一的名字并且在下载时确认设备名称已经正确分配。如果现场已经下载了错误的名称可以在TIA Portal的“在线访问”里找到对应的网卡扫描设备然后手动分配设备名称。这个过程不需要重新下载程序只需要分配名称即可。6.3 传输区数据量超限1214作为智能设备时输入和输出各最多1440字节。有一次项目里要传一个2000字节的数据块配置的时候没注意下载后通讯直接起不来。后来查手册才发现超限了。解决办法是把数据拆成两个传输区或者压缩数据格式减少字节数。提示配置传输区之前先算一下总字节数留出20%的余量避免后期加数据时超限。6.4 扫描周期不同步导致的逻辑问题智能设备和控制器的扫描周期是独立的这意味着控制器发出的指令智能设备可能在一个扫描周期后才响应。如果程序里有依赖即时响应的逻辑比如“发出指令后立即检查反馈”可能会误判。解决办法是在控制器侧加一个延时或者用状态机的方式处理不要依赖即时反馈。我在一个项目里就遇到过这个问题控制器发出气缸伸出指令然后立即检查伸出到位信号结果因为扫描周期差异反馈还没回来程序就报警了。后来改成发出指令后等50ms再检查问题解决。7. 这种合并方式的边界与替代思路7.1 什么时候不适合用智能IO合并智能IO方案虽然好用但也不是万能的。以下几种情况建议考虑其他方案数据量特别大如果两台PLC之间要传几千字节的数据传输区可能不够用或者刷新周期会变长。实时性要求极高比如运动控制同步智能IO的通讯延迟可能满足不了需要考虑用IRT等时同步实时或者其他方案。两台PLC距离很远如果两台PLC不在同一个控制柜里走PN通讯需要布线成本可能比换一台大CPU还高。需要冗余智能IO方案没有冗余控制器挂了智能设备也跟着挂如果系统要求高可用性需要另外考虑。7.2 替代方案简述如果智能IO不合适可以考虑PUT/GET通讯。两边都作控制器通过PUT/GET指令读写对方的数据。这种方式不需要改设备角色配置简单但实时性差编程量大需要处理握手和错误。适合数据交互不频繁的场景。另一种思路是换一台1500 CPU把两套程序合并到一个CPU里。这样一劳永逸但成本高程序移植工作量大。如果项目长期规划里有扩展需求可以考虑这个方案。7.3 合并后的维护建议合并完成后维护方式也要相应调整。建议做好以下几件事文档更新把新的网络拓扑、IP地址、设备名称、传输区地址都记录下来更新到图纸和文档里。程序备份两台PLC的程序都要备份并且标注版本号和日期。监控画面调整原来两个触摸屏的画面要合并成一个或者至少让操作工在一个画面上能看到所有设备状态。报警统一两边的报警要统一到一个报警系统里避免操作工漏看报警。我在实际项目里合并完成后会做一个简单的“通讯健康检查”程序定期检查传输区的数据刷新是否正常如果超过一定时间没有刷新就触发报警。这个小功能在后期维护中非常有用能提前发现通讯故障。8. 写在最后的一点个人体会两台1214通过PN通讯合并成一台这个方案我在多个项目里用过整体来说稳定可靠配置也不复杂。最关键的是前期规划要到位IP地址、设备名称、传输区地址、UDT定义这些在动手之前就想清楚后面能省很多事。另外TIA Portal的版本兼容性要注意。不同版本的TIA Portal在智能设备配置界面上有差异建议团队统一版本避免互相打不开项目。如果现场有老版本的1214固件升级也要提前做不然智能设备选项可能出不来。最后分享一个小技巧配置完成后在控制器侧建一个监视表把传输区的输入输出地址都放进去在线时一眼就能看到数据刷新情况。这个监视表在调试阶段能帮你快速定位问题比一个个查DB块快得多。