1. 从一次产线停机的排查说起PUT/GET到底卡在哪S7-1200 做 PUT/GET 通讯几乎是每个做西门子 PLC 的工程师都绕不过去的一道坎。我见过太多现场两台 1200 之间、1200 和 300/400 之间、1200 和上位机之间明明网线插好了IP 也 ping 得通TIA Portal 里编译下载一切正常可 PUT/GET 指令就是报错状态字要么是 16#80A1要么是 16#80C3要么干脆连接都建立不起来。更让人抓狂的是有时候改了一个看似无关的参数通讯突然就通了但过两天又莫名其妙断了。这个问题的本质是 PUT/GET 通讯涉及的不只是写一条指令这么简单。它横跨了硬件组态、连接参数、数据块属性、寻址方式、程序调用逻辑五个层面任何一个环节配置不对都会以通讯报错的形式表现出来。而 TIA Portal 的报错信息又相对笼统不会直接告诉你是 DB 块没关优化所以排查起来非常依赖经验。这篇内容适合三类人一是刚接触 S7-1200 通讯、被 PUT/GET 报错卡住的新手二是做过一些通讯但总是能通就行、不知道为什么通的工程师三是需要维护老项目、面对一堆历史配置需要快速定位问题的运维人员。我会从 DB 块复制这个最容易被忽视的起点讲起一路讲到自动连接和轮询调用的关键点把每个环节的为什么讲透让你下次遇到报错时能自己定位而不是靠反复试。需要先明确一个前提PUT/GET 是基于 S7 通讯的、非配对的、单向读写机制。客户端主动发起读写请求服务端被动响应不需要在服务端写接收指令。这个特性决定了它的配置重点在连接和数据区上而不是在收发逻辑上。理解了这一点后面的所有坑就都有了统一的解释框架。2. DB块复制这个动作为什么是PUT/GET报错的第一嫌疑2.1 优化块访问PUT/GET的隐形杀手S7-1200 的 DB 块默认是**开启优化的块访问**的。这个特性本身是好事它让变量在内存中的排列更紧凑、访问更快还支持符号寻址和保持性设置。但问题在于PUT/GET 指令只能访问绝对地址无法访问优化块中的符号变量。当你从别的项目复制一个 DB 块过来或者新建一个 DB 块准备给 PUT/GET 用时如果这个块还是默认的优化访问状态那么你在 PUT/GET 的 ADDR 参数里填DB1.DBX0.0这类绝对地址时指令根本找不到对应的物理地址结果就是报错。更隐蔽的是TIA Portal 在编译时不一定会报错它可能只是给一个警告或者干脆静默通过直到运行时才暴露问题。我遇到过最典型的情况工程师从旧项目复制了一个 DB 块里面变量都定义好了地址也显示DB2.DBW0之类的看起来完全正常。但实际上这个块是优化访问的那些地址只是显示用的偏移量并不是真实的绝对地址。PUT/GET 一调用就报 16#80A1地址错误。排查了半天最后发现只要把 DB 块的优化的块访问勾选去掉重新编译下载问题立刻消失。所以第一个关键点就是凡是参与 PUT/GET 通讯的 DB 块必须关闭优化的块访问。操作路径是右键 DB 块 → 属性 → 属性选项卡 → 找到优化的块访问复选框 → 取消勾选 → 确定 → 重新编译下载。2.2 复制DB块时最容易丢的三样东西即使你知道了要关优化访问从别处复制 DB 块时还有三个东西容易丢每一个都会导致 PUT/GET 失败。第一是绝对地址的连续性。关闭优化访问后DB 块内的变量会按照你定义的顺序分配绝对地址。如果你复制过来的块里变量顺序变了或者中间插入了新变量那么原来 PUT/GET 里写的地址就可能对不上了。比如原来DB2.DBW0对应的是速度设定值复制后这个位置变成了使能标志那读写的就不是你想要的数据了。所以复制 DB 块后一定要重新核对一遍变量的绝对地址必要时在 DB 块属性里勾选显示绝对地址来确认。第二是保持性设置。有些 DB 块变量设置了保持性复制到新项目后如果保持性属性丢失上电后数据会清零。对于 PUT/GET 通讯来说如果服务端 DB 块的数据被清零客户端读到的就是 0看起来像是通讯失败其实是数据被重置了。这个坑在调试阶段特别容易误判。第三是块的编号冲突。复制 DB 块时如果新项目里已经有同号的 DB 块TIA Portal 可能会自动重新编号也可能提示冲突。如果编号变了而 PUT/GET 的 ADDR 参数里还写着旧编号那肯定报错。所以复制后要确认 DB 块的实际编号并同步修改 PUT/GET 指令里的地址参数。2.3 一个快速验证DB块是否可用的方法与其反复猜不如用一个简单方法验证在 OB1 里写一条MOVE指令把 DB 块里的某个变量传送到一个 M 存储区地址然后在线监控。如果能正常传送说明 DB 块的绝对地址是可访问的如果 MOVE 都报错那 PUT/GET 肯定也不行。更进一步你可以用监控表直接监控 DB 块的绝对地址。在监控表里输入DB2.DBW0如果能显示数值说明这个地址是有效的绝对地址如果显示无法访问或类似提示那这个块很可能还是优化访问状态或者地址写错了。这个方法比反复下载测试快得多建议养成习惯。提示关闭优化访问后DB 块的变量不能再使用符号名在 HMI 或 SCADA 中直接访问必须用绝对地址。这一点在做触摸屏通讯时要特别注意很多触摸屏驱动只认绝对地址。3. 连接参数里的五个隐藏开关少一个都不通3.1 硬件组态中的允许PUT/GET通讯访问这是最基础但也最容易被忽略的一个开关。在 S7-1200 的硬件组态中选中 CPU → 属性 → 保护 → 连接机制里面有一个**允许来自远程对象的 PUT/GET 通讯访问复选框。这个选项默认是不勾选的**。也就是说如果你不在服务端 CPU 上勾选这个选项客户端发来的 PUT/GET 请求会被直接拒绝表现为连接建立失败或超时。很多工程师在客户端这边反复检查指令和地址却忘了服务端根本没开权限。这个设计其实是出于安全考虑PUT/GET 允许外部设备直接读写 PLC 的数据区如果不加限制存在被误操作的风险。所以西门子默认关闭需要手动开启。在实际项目中只要涉及 PUT/GET服务端和客户端都要检查这个选项尤其是服务端。3.2 连接类型选未指定还是指定在 TIA Portal 中建立连接时有两种方式一种是在网络视图中手动拖拽建立连接这种方式会明确指定连接的两端另一种是在 PUT/GET 指令的 REQ 上升沿触发时由系统自动建立连接。手动建立的连接连接类型通常是TCP或ISO-on-TCP。这里有个关键点S7-1200 的 PUT/GET 支持 TCP 和 ISO-on-TCP 两种连接类型但两者不能混用。如果客户端用 TCP服务端也必须用 TCP如果客户端用 ISO-on-TCP服务端也要对应。混用会导致连接建立失败。我的建议是如果是两台 1200 之间通讯优先用ISO-on-TCP因为它是西门子自己的协议栈兼容性更好而且支持路由功能。如果是 1200 和第三方设备通讯那要看对方支持什么通常 TCP 更通用。3.3 TSAP地址不填也能通但填错一定不通TSAPTransport Service Access Point是 ISO-on-TCP 连接中的一个参数用来标识连接端点。在 TIA Portal 中手动建立连接时TSAP 会自动分配通常不需要手动填写。但如果你是从旧项目复制连接配置或者手动修改过 TSAP那就可能出问题。TSAP 的格式通常是XX.YY其中 XX 是连接类型标识YY 是连接编号。如果两端 TSAP 不匹配连接就建立不起来。我遇到过一种情况工程师从别人那里拷了一个项目连接配置里的 TSAP 是手动填的结果和实际 CPU 的 TSAP 对不上通讯一直报错。后来把 TSAP 改回自动分配问题就解决了。所以对于 TSAP我的经验是除非对方明确要求指定 TSAP否则一律用自动分配。手动填 TSAP 只在特定场景下需要比如和某些老设备或第三方系统对接时。3.4 连接资源数量别让连接数成为瓶颈S7-1200 的 CPU 支持的连接资源是有限的。以 CPU 1214C 为例它支持的最大连接数是 8 个其中 PUT/GET 连接会占用这些资源。如果你同时建立了多个 PUT/GET 连接再加上 HMI 连接、编程连接等很容易把连接数用满。连接数用满的表现是新的连接建立请求被拒绝PUT/GET 报错但已有的连接可能还在正常工作。这种情况下你会觉得时好时坏其实是连接资源被占满了。排查方法是在 TIA Portal 的在线和诊断中查看连接选项卡看看当前建立了多少连接还剩多少资源。如果接近上限就需要优化连接策略比如减少不必要的连接或者把多个数据交换合并到一个连接里。3.5 客户端和服务端的角色不能搞反PUT/GET 是单向主动的客户端主动发起读写服务端被动响应。所以客户端需要调用 PUT/GET 指令服务端不需要。如果你在两端都调用了 PUT/GET或者把客户端和服务端的角色搞反了通讯就会出问题。判断角色很简单谁需要读/写对方的数据谁就是客户端。比如 A 站要读 B 站的数据那 A 站是客户端调用 GET 指令B 站是服务端只需要在硬件组态里允许 PUT/GET 访问即可。我见过一种错误工程师在两端都写了 PUT/GET想实现双向通讯。结果两边都在主动发起请求连接冲突谁也通不了。正确的做法是如果需要双向通讯就在一端用 PUT 写、另一端用 GET 读或者两端各建立一个单向连接但要注意连接资源。4. 自动连接与轮询调用让PUT/GET稳定跑起来的关键逻辑4.1 REQ触发方式上升沿不是随便给的PUT/GET 指令的 REQ 参数需要一个上升沿来触发。很多新手会用一个常闭点或者时钟脉冲来触发结果要么只执行一次要么频繁触发导致连接混乱。正确的做法是用一个周期性的上升沿来触发比如用一个 1Hz 的时钟脉冲的上升沿或者用一个定时器产生的脉冲。这样既能保证周期性读写又不会因为触发太频繁而占用过多资源。但这里有个细节REQ 上升沿触发后指令需要一定时间来完成通讯。如果在上一次通讯还没完成时又来了新的上升沿指令会忽略新的触发或者报忙错误。所以触发周期不能太短一般建议不低于 100ms具体要看网络状况和数据量。我的经验是对于小数据量几十个字节200ms 到 500ms 的周期比较稳妥对于大数据量几百个字节以上建议 1s 以上。如果通讯频繁报忙就加大周期。4.2 轮询多个从站别让连接打架当一个客户端需要和多个服务端通讯时就需要轮询。比如一台 1200 要读 4 台 1200 的数据就需要建立 4 个连接轮流调用 GET 指令。轮询的关键是同一时间只能有一个 PUT/GET 指令处于激活状态。如果多个指令同时触发连接会冲突导致部分或全部通讯失败。实现轮询的常见方法是用一个步进计数器每个周期只激活一个连接等这个连接完成后再切换到下一个。具体逻辑是用定时器产生周期脉冲用计数器或 CASE 语句选择当前要通讯的站号当前站的 PUT/GET 指令的 REQ 接脉冲上升沿指令的 DONE 或 ERROR 输出触发计数器加一切换到下一站。这样就能保证同一时间只有一个连接在活动避免冲突。轮询周期要根据站数和数据量来定站数越多、数据量越大周期就要越长。4.3 DONE和ERROR的处理别只看ERRORPUT/GET 指令有 DONE、ERROR、STATUS 三个输出。很多工程师只关注 ERROR看到 ERROR 为 1 就去查问题但忽略了 DONE 和 STATUS 提供的信息。DONE 为 1 表示本次通讯成功完成这时候可以安全地读取或写入数据。ERROR 为 1 表示本次通讯失败STATUS 里会有具体的错误代码。STATUS 是一个 WORD 类型的值不同的值对应不同的错误原因。常见的 STATUS 值有STATUS值含义可能原因16#0000无错误通讯正常16#80A1地址错误DB块未关优化访问、地址写错16#80C3连接被拒绝服务端未允许PUT/GET、连接资源满16#80C4连接超时网络不通、IP错误、防火墙16#80D2连接已存在重复建立连接16#80D4连接资源不足连接数超限排查时先看 STATUS 值再对照上表定位方向。这比盲目试错快得多。4.4 连接建立与断开的时机PUT/GET 的连接是按需建立的第一次触发时建立连接之后保持连接直到超时或主动断开。如果网络中断连接会断开下次触发时会重新建立。这里有个坑如果连接断开后没有正确处理可能会残留半开的连接状态导致后续连接建立失败。表现是 STATUS 报 16#80D2连接已存在或 16#80C3连接被拒绝。处理方法是在 ERROR 为 1 且 STATUS 为连接相关错误时先断开连接再重新建立。具体做法是用一个变量记录连接状态出错时复位这个变量下一个周期重新触发 REQ让系统重新建立连接。另外如果通讯长时间不需要建议主动断开连接释放连接资源。可以在程序里加一个逻辑如果连续 N 个周期没有通讯需求就断开连接。5. 从报错代码反推问题一套可复现的排查链路5.1 先确认物理层和网络层不管 STATUS 报什么第一步永远是确认物理层和网络层。具体做三件事ping 测试在客户端用电脑 ping 服务端的 IP确认网络可达。如果 ping 不通先查网线、交换机、IP 配置。在线诊断在 TIA Portal 里在线服务端 CPU查看在线和诊断中的连接选项卡确认是否有来自客户端的连接请求。检查 IP 和子网掩码确认两端 IP 在同一网段子网掩码一致。如果跨网段需要配置网关和路由。这三步能排除大部分完全不通的问题。如果物理层和网络层没问题再往下查配置层。5.2 再查服务端的PUT/GET权限和DB块属性物理层通了之后重点查服务端允许来自远程对象的 PUT/GET 通讯访问是否勾选这是最常见的遗漏点。DB 块是否关闭了优化访问右键 DB 块 → 属性 → 取消优化的块访问。DB 块编号和地址是否正确确认 PUT/GET 的 ADDR 参数里的 DB 编号和地址与实际一致。连接资源是否充足在在线和诊断中查看连接数。这四步能解决大部分能 ping 通但通讯报错的问题。5.3 最后查客户端的指令调用逻辑如果服务端配置没问题再查客户端REQ 触发方式是否正确确认是上升沿触发周期合理。连接类型是否匹配TCP 对 TCPISO-on-TCP 对 ISO-on-TCP。TSAP 是否自动分配除非有特殊要求否则用自动。轮询逻辑是否冲突确认同一时间只有一个指令激活。DONE 和 ERROR 的处理是否完整确认出错时有重连逻辑。5.4 一个真实的排查案例我曾经遇到一个项目两台 1200 做 PUT/GET客户端读服务端的数据。现象是刚下载完程序时通讯正常运行几个小时后开始报错STATUS 是 16#80C4连接超时。重启后又能正常一段时间。排查过程ping 测试正常网络没问题。在线诊断服务端发现连接数在逐渐增加最后达到上限。检查客户端程序发现 REQ 触发周期是 50ms而且没有处理 ERROR 后的重连逻辑。分析原因触发太快连接建立后来不及完成就被新的触发打断导致连接状态混乱旧连接没有正常释放新连接又不断建立最终连接资源耗尽。解决方案把 REQ 触发周期改为 500ms。增加 ERROR 处理逻辑出错时复位连接状态下一个周期重新触发。增加连接数监控如果连接数接近上限主动断开空闲连接。改完后连续运行一周没有再出现超时。这个案例说明PUT/GET 的稳定性不仅取决于配置还取决于调用逻辑。触发太快、没有错误处理、没有连接管理都会导致时好时坏的问题。6. 几个让通讯更稳的实战习惯6.1 给每个连接建一个状态字在程序里为每个 PUT/GET 连接建一个状态字WORD 类型把 STATUS 的值实时存进去。这样在监控时一眼就能看到每个连接的状态不用逐个打开指令块查看。状态字还可以送到 HMI 上显示方便现场人员判断通讯是否正常。6.2 用系统时钟做触发源TIA Portal 里可以组态系统时钟存储器产生不同频率的脉冲。用系统时钟的上升沿做 REQ 触发比用定时器更稳定而且不占用定时器资源。具体路径是CPU 属性 → 系统和时钟存储器 → 启用时钟存储器字节 → 选择频率。6.3 数据量控制在合理范围PUT/GET 单次通讯的数据量不宜过大。S7-1200 的 PUT/GET 单次最大数据量是222 字节对于 GET和212 字节对于 PUT具体取决于 CPU 型号。如果数据量超过这个限制需要分多次读写。我的建议是单次通讯数据量控制在100 字节以内这样通讯时间短出错概率低。如果数据量大就分多个连接或分多次读写。6.4 定期检查连接资源在程序里加一个逻辑每个周期检查当前连接数如果接近上限就主动断开最久未使用的连接。这样可以避免连接资源耗尽导致的通讯失败。6.5 保留一份可用的配置备份PUT/GET 的配置涉及硬件组态、连接配置、DB 块属性、程序逻辑多个层面一旦调通建议把整个项目备份一份。下次遇到类似项目可以直接参考避免重复踩坑。注意PUT/GET 通讯的稳定性是配置逻辑运维三方面共同决定的。配置对了只是基础逻辑合理才能稳定运维到位才能长期可靠。不要指望一次配置就能一劳永逸。7. 写在最后几个我踩过的坑和对应的解法第一个坑DB 块复制后忘了关优化访问。这个坑我踩过不止一次后来养成了习惯凡是新建或复制 DB 块第一件事就是检查优化的块访问是否关闭。如果项目里 DB 块多可以在 DB 块属性里批量设置但要注意批量设置可能会影响其他功能。第二个坑服务端忘了勾选 PUT/GET 权限。这个坑的特点是客户端怎么查都没问题就是不通。后来我总结了一个口诀先查服务端权限再查客户端指令。因为服务端的配置是一次性的容易被遗忘客户端的指令是每次都要写的反而容易记住。第三个坑REQ 触发太快导致连接混乱。这个坑的表现是时好时坏很难复现。后来我把触发周期统一改为 500ms并且加了错误重连逻辑就再也没出现过。第四个坑轮询时多个指令同时激活。这个坑在单站通讯时不会出现一旦扩展到多站就暴露了。后来我用步进计数器严格保证同一时间只有一个指令激活问题解决。第五个坑连接资源耗尽。这个坑在项目初期不会出现运行一段时间后才暴露。后来我加了连接数监控和空闲连接释放逻辑就稳定了。这些坑的共同点是都不是配置错误这么简单而是涉及对 PUT/GET 工作机制的理解。理解了它是单向主动、按需连接、资源有限的机制很多问题就能提前避免。如果你现在正被 PUT/GET 报错困扰建议按这个顺序排查先 ping 通网络再查服务端权限和 DB 块属性然后查客户端指令逻辑最后看连接资源和轮询逻辑。大部分问题都能在这个链路里找到答案。