恒美微站
首页
关于我们
建站服务
主题模板
案例展示
资讯中心
联系我们
S7-1200 PUT/GET通信全解析:从组态到避坑的实战指南
首页
资讯中心
/
S7-1200 PUT/GET通信全解析:从组态到避坑的实战指南
S7-1200 PUT/GET通信全解析:从组态到避坑的实战指南
发布时间:2026/10/15 5:35:20
简介这是一份西门子S7-1200 PLC间通过PUTGET协议实现S7通信的图文教程面向自动化工程师、PLC编程人员及工业现场调试人员重点解决S7-1200之间跨CPU数据交换的组态与编程问题。文档基于Step7 V13软件完整梳理了同一项目内和不同项目下两种S7连接建立方式涵盖网络视图配置、S7连接属性设置、非优化数据块创建以及PUT/GET指令调用等关键环节并附有功能块参数说明和监控结果示意便于读者对照练习。资源为单个doc文档压缩包大小4.28MB内容结构清晰从硬件软件准备到连接配置再到程序编写逐步展开尤其对TSAP号、本地ID等易错参数给出了明确指导。目前已有11276人学习浏览适合需要快速掌握S7-1200之间S7通信操作的工程师参考。1. S7-1200的PUTGET是什么一条不必在对方CPU里写程序的S7通信通道两台S7-1200之间要交换数据很多现场把Modbus TCP、TCP Socket试了一圈最后又绕回PUT/GET。原因很直接PUT/GET是S7通信里最省事的点对点读写服务主动方CPU发起调用直接读或写对端CPU的DB块对端不需要为这条链路写一行通信代码。如果你面对的是同品牌PLC之间、几十到几百字节的中小数据量交换PUT/GET能让你在一个小时内打通链路把精力留给业务逻辑而不是报文解析。这篇笔记按“选型→准备→调用→调优→避坑→模板”的顺序展开新手可以照步骤复现熟手可以直接跳到参数和坑那一章。2. 开工前的三件套通信选型、连接资源与DB块访问属性2.1 跨CPU数据交换选型PUT/GET、Modbus TCP与TCP Socket怎么选不同方案的差异不在“能不能通”而在“通得有多麻烦”。下面的对比表是我平时做方案时用的对比项PUT/GETS7通信Modbus TCPTCP Socket编程量低地址字符串直接指到对方DB中需要组态MB块、维护寄存器映射高要自己组帧、拆帧、处理粘包对方CPU代码不需要只做访问授权需要做从站或服务器逻辑两端都要写收发程序数据量适合几百字节以内适合批量寄存器数据适合自定义协议、大数据量实时性受PLC程序扫描周期影响受主站轮询周期影响最灵活但全看程序怎么写主要坑优化块访问、连接资源、REQ触发寄存器地址映射、字节序断线重连、报文校验、粘包PUT/GET的原理可以理解为主动方CPU里运行一个“读写请求”通过组态好的S7连接把本地数据区写到伙伴CPU指定存储区或者把伙伴CPU指定存储区读回本地。伙伴CPU只负责“允许访问”不参与数据装配所以它那边没有通信程序。这个方案最适合的场景是两个或几个S7-1200之间互传设备状态字、浮点参数、批次号这类中小数据量数据。如果数据量到了K字节级别或者需要跨品牌通信我不建议硬用PUT/GETModbus TCP或Socket更合适。2.2 把连接资源算清楚PUT/GET占的是S7连接资源不是普通TCP连接S7-1200的每个通信实例都会消耗CPU的连接资源。PUT/GET每建立一条链路占用一个S7连接连接资源总数由CPU硬件决定不同型号的S7-1200可同时保持的连接数不一样1211C、1212C这类小CPU明显偏少。现场如果同时跑着HMI连接、编程器在线连接、其他通信任务PUT/GET可能因为连接资源不足而报错。我一般会在选型阶段先查订货号对应的技术数据表确认当前CPU最多支持多少个S7连接再减去HMI、编程器这些在线连接占用至少给PUT/GET留两到三个连接余量。拿不准时就在TIA Portal里组态完连接后把CPU在线打开“在线与诊断”的通信连接列表看连接是否建立成功、是否被拒绝。通信这块还有一个核心概念通信负载。CPU在扫描周期里会分出一定比例的时间给通信任务这个占比叫通信负载。占比越高通信吞吐越流畅但扫描周期越容易波动。占比太低PUT/GET会明显变慢。这一项先不急着调默认值通常够用等到后面调优阶段再根据现场表现去改。2.3 被访问侧的DB块必须取消“优化的块访问”这是PUT/GET做不起来时最高频的根因而且是那种“查了一天最后发现是自己没勾掉一个复选框”的坑。TIA Portal里新建的DB块默认勾选“优化的块访问”。优化块访问意味着DB按符号寻址变量在物理存储里的偏移量是由编译器自动分配的外部指令拿到的不一定是连续可寻址的物理布局。而PUT/GET的地址字符串是“DB块号字节偏移”这种格式比如DB5,DW0它要求目标块是固定的物理可寻址布局。目标DB是优化块时通信指令根本定位不到数据。操作步骤很简单在项目树里找到被访问的DB块右键打开“属性”。在属性窗口里找到“优化的块访问”取消勾选。编译这个DB块并下载到对应的CPU里。打开DB块确认变量列表里有“偏移量”这一列并且每个变量都有具体的地址偏移说明物理布局已经生效。注意取消优化块访问是在被访问方CPU上做不是在主动方。两个CPU都要做不只有提供数据给对方读写的那个CPU需要取消。取消优化之后变量名仍然可以用但布局固定了。定义变量时要注意数据类型对齐BOOL和Byte会连续紧凑排布不要凭感觉猜偏移直接看偏移量列最靠谱。2.4 组态S7连接与访问授权两个CPU都要做程序调用PUT/GET之前必须在TIA Portal里先把两个CPU之间的S7连接建立起来。连接组态是图形化操作过程如下打开网络视图把两个CPU拖到同一个画面里。从主动方CPU的以太网接口拖一条连接线到被动方CPU松开鼠标后选择“S7连接”。在连接属性里确认“本地端点”和“伙伴端点”各指向哪个CPU记下本地连接ID后面程序里要用。分别打开两个CPU的属性找到“防护与安全”下的“连接机制”勾选“允许来自远程对象的PUT/GET通信访问”。编译整个项目分别下载到两个CPU。很多人在第4步翻车只组态了连接却没有在伙伴CPU上勾选访问授权结果主动方一直报连接失败。这里补一句S7-1200的固件V4.0以下不支持PUT/GET如果你手里有老固件CPU要么升级固件要么改用其他通信方式这一点在选型阶段就要确认。3. 从零调用PUT与GET指令参数、地址字符串与触发方式3.1 在主动方调用PUT把本地数据写到对端DB调用PUT之前先建好本地数据区。常见的做法是建一个独立的通信DB把要发送的数据集中放在一起避免散落在各个DB里不好维护。下面是一个典型的PUT调用// PUT调用示例将本地 CommData.SendData 写到对端 DB_Target.DW0 #rTrigPut(CLK : #clock1Hz, // 1Hz周期脉冲输入 Q #putReq); // 上升沿触发脉冲输出 PUT_DB(REQ : #putReq, // 触发信号上升沿启动一次写操作 ID : #connId, // 与TIA组态S7连接里的本地连接ID一致 ADDR_1 : DB_Target,DW0, // 对端CPU里的目标地址字符串 SD_1 : CommData.SendData, // 本地的发送数据区 LADDR : #hwId, // 本地硬件标识符来自系统常量 DONE #putDone, // 本次传输完成标志 ERROR #putErr, // 本次传输错误标志 STATUS #putStatus); // 状态代码报错时查这里这段代码里REQ是触发信号我用R_TRIG把1Hz的时钟脉冲转换成上升沿这样每个脉冲周期只启动一次写任务。ID必须跟TIA Portal里组态的S7连接本地ID一致填错就连不上。ADDR_1是字符串格式的远端地址格式固定是“DB块号,DW偏移”偏移按字节算。SD_1是本地数据区它和远端目标区的数据长度要匹配长度不一致会报错。LADDR是本地硬件标识符在PLC变量的“系统常量”里能找到。参数方向说明REQ输入上升沿触发不要常通ID输入S7连接的本地ID和组态对应ADDR_1输入对端地址字符串如“DB_Target,DW0”SD_1输入本地数据区变量长度需与对端一致LADDR输入本地硬件标识符系统常量里选DONE输出本次任务成功完成置1ERROR输出本次任务出错置1STATUS输出具体状态代码查故障用第一次跑通PUT建议只传一个字节或一个字确认通路没问题再扩大数据块。不要一上来就传几十个字节出了问题不好定位是地址偏移的问题还是长度的问题。3.2 在主动方调用GET把对端DB读回本地GET和PUT的调用格式几乎一样只是SD_1变成了RD_1语义从“发送”变成“接收”// GET调用示例将对端 DB_Target.DW0 的数据读回本地 CommData.RecvData #rTrigGet(CLK : #clock1Hz, Q #getReq); GET_DB(REQ : #getReq, ID : #connId, ADDR_1 : DB_Target,DW0, RD_1 : CommData.RecvData, LADDR : #hwId, DONE #getDone, ERROR #getErr, STATUS #getStatus);GET和PUT可以在一个CPU里共用同一个S7连接ID填同一个值。很多项目就是一个CPU里同时调PUT和GETPUT负责把自己的数据发给对方GET负责把对方的数据收回来双方数据互不干扰。这里要强调一点S7-1200的PUT/GET访问对端时能访问的存储区只有DB和M区不能直接读I/Q区。如果对方数据在I/Q区里必须在对方程序里做一次映射把I/Q信号复制到DB或M区然后这边再通过GET去读。这个限制在1200之间互访时特别容易踩很多人想直接读对方的输入点结果发现地址字符串怎么填都不对。3.3 REQ触发和轮询为什么不能让REQ长期置1新手常见的写法是把REQ直接连一个常1位结果通信功能块每个扫描周期都在启动新任务通信负载飙升STATUS状态跳来跳去CPU扫描周期也跟着变长。正确做法是让REQ只在需要的时候产生一个上升沿。常见手段有三个用R_TRIG把1Hz时钟脉冲转成上升沿适合周期性同步的数据。自己写一个定时器每N个扫描周期翻转一次布尔位。在状态机里手动控制当前任务完成后再触发下一个。当一个连接上要传输多个数据块时就要用到轮询。核心原则是同一时刻只触发一个传输任务等它的DONE或ERROR出现后再切换到下一个任务。把所有传输任务串行化能明显降低通信负载避免多个PUT/GET同时抢资源。4. 把通信调稳通信负载、调用位置与STATUS诊断4.1 通信负载与调用位置影响扫描周期的两手调法PUT/GET跑通之后下一步是让它跑得稳。影响稳定性最明显的两个因素一个是通信负载一个是调用位置。通信负载在CPU属性里有专门设置项默认值通常能满足中小数据量场景。如果现场出现扫描周期明显波动而通信任务又没那么重我会把通信负载调低一些给扫描周期让路。反过来如果数据同步延迟明显先看是不是负载设得太低再考虑调高。调用位置方面我一般把PUT/GET放在OB1里调用前提是项目对通信实时性要求不苛刻。放在OB1里有好处通信任务和主程序在同一个扫描周期里调度逻辑清晰不会出现中断里通信占用时间导致中断超时的问题。如果确实需要固定周期执行通信可以放到一个周期中断OB里但要注意给通信任务留足时间预算不要在同一个周期中断里同时做大量PUT/GET和其他耗时指令。整体规律是通信调用越频繁数据新鲜度越高但CPU开销越大。轮询是摊薄开销的有效手段把多个任务排成串行队列每个扫描周期只处理一个或两个任务负载自然降下来。4.2 DONE、ERROR与STATUS组合诊断PUT/GET运行过程中判断任务状态主要看三个输出位状态组合含义处理建议DONE1ERROR0本次传输完成切换到下一个任务或等待下次触发DONE0ERROR1本次传输出错查STATUS代码定位错误原因DONE0ERROR0STATUS0无活动任务等待REQ触发DONE0ERROR0STATUS≠0任务进行中或等待中不要重复触发等结果ERROR置1时STATUS会返回一个十六进制状态码。这个码对应的具体含义在TIA Portal的指令帮助里有完整列表。我的习惯是先把状态码记下来再去帮助里查而不是直接复位重启CPU。如果连接根本建立不起来程序里可能看不到有效状态码这时要去“在线与诊断”里看诊断缓冲区。诊断缓冲区会记录连接被拒绝、连接超时这类底层事件比程序里的STATUS更直接。验证通信通没通最朴素的办法是两端CPU各建一个监控表一边改本地发送区的值一边看远端接收区变没变两个方向都验证过才算真正跑通。4.3 与S7-300、S7-1500混用时的差异点S7-1200的PUT/GET经常要跟S7-1500、S7-300混着用这三者之间有几处明显差异S7-1500的DB默认也是优化块访问被S7-1200的PUT/GET访问前同样要取消优化。如果对方是1500且已经用了优化DB要么在1500侧新建非优化DB要么把1500内部的数据通过S7通信透传到非优化DB里再让1200来读。S7-300没有优化块访问这个概念DB默认就是物理地址布局用PUT/GET访问300的DB是最省心的。数据格式方面S7 CPU之间通信都是大端字节序同品牌互通不需要处理字节序转换。但如果对端是第三方设备那就要自己确认字节序PUT/GET不是干这个的。5. PUTGET避坑指南现场翻车率最高的五个坑5.1 现象一ERROR常亮连接建立失败现象主动方CPU里PUT/GET的ERROR位始终为1STATUS指向连接类错误在线诊断里能看到连接被拒绝的记录。原因最常见的是TIA Portal里没有组态S7连接或者组态了连接但伙伴CPU的“允许来自远程对象的PUT/GET通信访问”没有勾选。另一个隐蔽原因是连接资源被占用现场HMI、编程器在线、其他通信任务把连接数吃满了PUT/GET抢不到资源。解决先回网络视图确认S7连接存在且处于在线状态再检查两个CPU的属性确认访问授权都已勾选最后打开“在线与诊断”的连接列表看当前连接资源占用情况。按这个顺序排查半小时内能定位。5.2 现象二连接正常但数据一动不动现象通信链路建立成功DONE偶尔也会出现但远端DB里的数据就是不变或者值始终是初始值。原因八成是目标DB的“优化的块访问”没有取消。PUT/GET的地址字符串是按物理偏移寻址的优化DB没有固定偏移通信指令定位不到变量自然不会报明显的连接错误但数据就是写不进去。解决在提供数据的CPU侧右键目标DB取消“优化的块访问”重新编译并下载。下载后打开DB确认变量列表里出现“偏移量”列数据再接进去就正常了。5.3 现象三两端都写同一块DB数据偶发错乱现象两个CPU互相对同一个DB区域做PUT和GET数据偶发出现不同步、覆盖、跳变而且不是每次都会出现定位很费劲。原因数据所有权没有划清。A往DB10写B也往DB10写同一片存储区有两个写入方写入时序稍微错开就会互相覆盖。解决明确数据流方向同一片DB只允许一个写方。常见做法是A只PUT、B只GET或者反过来。如果确实需要双向那就把DB分成两段A写前段B读前段B写后段A读后段互不交叉。更稳妥的做法是加上心跳字和序列号接收方校验序列号连续变化超过一定次数不变化就判定通信异常。5.4 现象四程序规模一大扫描周期明显拉长现象项目后期程序块越来越多CPU扫描周期从原来的几毫秒涨到十几毫秒甚至触发看门狗超时。原因PUT/GET的REQ常通只是其中一个因素更常见的是多个通信任务同时触发通信负载被堆满。通信负载过高时CPU在每个扫描周期里要处理大量通信任务扫描周期自然被拉长。解决把所有的PUT/GET改成轮询同一时刻只允许一个任务在工作。REQ必须用上升沿触发不要常通。如果扫描周期仍然紧张去CPU属性里调低通信负载设置。另外检查一下通信调用放在程序哪个位置把它挪到OB1靠后的程序段避免影响前面的工艺逻辑。5.5 现象五断电重启后通信不恢复现象现场断电再上电后PUT/GET通信没有自动恢复必须手动复位CPU或重新下载程序才恢复。原因两个CPU的上电时序不一致主动方先进入运行状态被动方还在启动中主动方首次连接失败后程序又没有重试逻辑就一直卡在失败状态。另一个可能原因是重新下载配置时“允许来自远程对象的PUT/GET通信访问”这个勾选项被覆盖掉了。解决在主动方程序里加一个启动延时上电后先等几秒再开始通信避开被动方的启动窗口。同时给通信任务加上错误重试逻辑ERROR出现后自动复位隔一段时间重新触发。程序下载后重新检查一遍两端CPU的访问授权确保还在勾选状态。6. 把PUT/GET封装成自己的通信模板轮询、心跳与验证技巧通信任务一多重复写PUT/GET调用很容易出错。我的做法是做一个统一模板把轮询、触发、错误重试都封装在一个函数块里每次新项目直接改地址和数据区就能用。核心思路是维护一个任务索引和忙标志空闲时启动当前索引对应的任务任务完成后索引加1所有任务走一遍后回到第一个。下面是模板的核心逻辑// 通信调度模板同一时刻只执行一个PUT/GET任务 #pulseTrig(CLK : #clock1Hz, Q #cyclePulse); IF NOT #busy THEN // 空闲状态启动下一个任务 #idx : #idx 1; IF #idx 2 THEN #idx : 0; END_IF; #busy : TRUE; #req : TRUE; ELSE // 任务执行中等待完成或错误 IF #done OR #error THEN #req : FALSE; #busy : FALSE; END_IF; END_IF; // 根据任务索引选择对应的GET/PUT调用 CASE #idx OF 0: GET_DB(REQ : #req, ID : #connId, ADDR_1 : DB_Target,DW0, RD_1 : CommData.RecvData[0], LADDR : #hwId, DONE #done, ERROR #error, STATUS #status); 1: GET_DB(REQ : #req, ID : #connId, ADDR_1 : DB_Target,DW20, RD_1 : CommData.RecvData[1], LADDR : #hwId, DONE #done, ERROR #error, STATUS #status); 2: PUT_DB(REQ : #req, ID : #connId, ADDR_1 : DB_Target,DW40, SD_1 : CommData.SendData, LADDR : #hwId, DONE #done, ERROR #error, STATUS #status); END_CASE;模板里值得注意的几点CASE分支里的GET和PUT可以根据需要任意组合不要求全是GET或全是PUT。每个任务用独立的ADDR_1和RD_1/SD_1互不干扰。任务索引#idx在空闲状态才递增避免了触发器被重复扫描。#req在每个任务启动时置位在完成或错误时复位不会出现REQ常通的问题。心跳字是这个模板里必带的一项。我在通信数据区里固定放一个递增计数器发送方每轮数据把它加1接收方判断它的变化。如果连续几个扫描周期心跳值都不变接收方就置一个“通信断开”标志上位机或工艺逻辑可以用它做安全联锁。这个做法比单纯看DONE位可靠得多DONE只代表一次任务完成不代表数据链路持续健康。验证新模板时我习惯按三步走第一步只传一个字节确认方向对、地址对、授权对第二步在两端各开一个监控表一边改值一边看另一边有没有变化双向都验一遍第三步再扩大数据块同时观察CPU扫描周期变化。三步走完通信这块基本就稳了。有一次做现场改造两台S7-1200隔了几十米A往B传数据死活不通程序和连接查了个遍都没问题最后发现是B侧那个DB建的时候没有取消优化访问。从那以后我每做一个S7-1200的PUT/GET项目第一件事就是打开被访问DB的属性确认“优化的块访问”是灰色未勾选状态省掉后面一大半排查时间。希望帮到你。本文还有配套的精品资源点击获取