简介：本资源是一份面向自动化工程师与PLC初学者的西门子S7-1200 PUT/GET通信实战教程，聚焦PROFINET环境下两台S7-1200 PLC间高效数据交互的核心需求。内容覆盖同一项目内与跨项目两种典型场景，完整呈现Step7 V13 SP1软件中从硬件组态、网络配置、S7连接建立（含TSAP设置与本地ID定义），到非优化数据块创建、PUT/GET指令调用及参数配置的全流程操作，并附详细监控验证结果与常见排错提示。资源为1个4.28MB的Word文档（.doc），结构清晰，图文并茂，含10余张关键配置界面截图、功能块参数对照表及通信状态判据说明，便于边学边练、快速复现。目前已有11287人学习下载，是掌握S7-1200单边S7通信原理与工程落地的高实用性参考资料。
1. 西门子S7-1200 PUT&GET通信到底能不能跨项目直连？——不是协议不支持，是TSAP和保护设置卡死90%的现场调试
你手头有两台S7-1200：一台V4.1新CPU做客户端，一台V2.0老CPU做服务器，IP已配通、网线插稳、STEP 7 V13里连接图标也显示绿色，但OB1里PUT指令STATUS一直报16#80C0，GET永远NDR不置位——这不是网没通，是S7通信在“假装握手”。真实情况是：S7-1200的PUT/GET根本不是标准以太网Socket直连，它依赖TSAP地址+固件级访问白名单双重校验。V2.0服务器默认关闭远程PUT/GET入口，V4.0+服务器更强制要求手动勾选“允许远程伙伴访问”；而跨项目场景下，若客户端填错伙伴TSAP（比如该填03.00却填了03.01），连接看似建立，数据却像被黑洞吸走。本教程拆解的正是这两类现场最高频翻车点：同一项目内组态逻辑闭环验证、跨项目时TSAP与保护策略的硬性匹配。适合刚从TIA Portal转回STEP 7 V13的老工程师、产线调试员，以及被客户催着三天内打通两台旧PLC数据通道的FA工程师——所有操作均基于真实硬件（CPU 1214C DC/DC/DC V2.0/V4.1）和可复现工程（STEP 7 V13 SP1），不讲虚的“理论上可行”，只列你下载后打开就能跑通的配置快照、参数值、块属性开关位置。
2. 同一项目内S7通信：从设备组态到PUT/GET调用的完整链路闭环
2.1 设备添加与IP地址固化：为什么必须手动写死IP而非依赖DHCP
在STEP 7 V13 SP1中新建项目后，不能直接拖入CPU设备就完事。关键动作是：右键“设备组态”→“添加新设备”→选择“S7-1200”→在型号列表中精确找到“CPU 1214C DC/DC/DC”并核对固件版本（V2.0或V4.1）。此时设备默认IP为192.168.0.1，必须双击设备进入“属性”→“以太网接口”→取消勾选“使用DHCP”→手动输入静态IP。例如客户端设为192.168.0.10，服务器设为192.168.0.12。原因在于：S7连接在编译阶段即把IP写入连接描述符，若运行时IP漂移（如插拔网线触发DHCP重获），连接状态会瞬间变红且无法自动恢复，STATUS报16#80A1（目标不可达）。这步操作看似简单，却是后续所有调试的前提——我见过三次产线重启后通信中断，查到最后全是DHCP惹的祸。
# STEP 7 V13中设备IP配置路径（非代码，但需你手动点击） 设备组态 → 右键CPU设备 → 属性 → 以太网接口 → 取消"使用DHCP" → 输入IPv4地址/子网掩码提示：IP地址段建议固定用192.168.0.x，避免与工厂主干网10.x.x.x冲突；两台设备子网掩码必须一致（通常255.255.255.0），否则网络视图里设备间连线会显示为灰色虚线，表示L2层不可达。
2.2 网络视图中S7连接创建：主动方/被动方的本质区别与ID号绑定逻辑
进入“网络视图”后，点击左上角“连接”图标，在弹出菜单中选择“S7连接”。此时关键操作是：先单击客户端CPU（V4.1那台），再右键→“添加新连接”。如果反向操作（先点服务器再连），系统会强制你选“被动连接”，但S7-1200作为服务器端根本不支持被动建连——它只响应请求，不发起握手。在“创建新连接”对话框中，“连接对象”必须选中服务器CPU（V2.0那台），“连接类型”保持默认“S7连接”，勾选“主动建立连接”。此时系统自动生成连接名称（如S7_连接_1），并在“本地ID”栏填入W#16#100。这个ID值不是随便写的：它必须与后续PUT/GET指令中的ID参数完全一致，且在同一项目中全局唯一。若你建了第二个S7连接，ID必须改为W#16#101，否则编译报错“连接ID重复”。
# S7连接属性中必须核对的三项（在“连接”列表中双击S7_连接_1打开） 常规 → 本地设备：显示客户端CPU名称及IP（192.168.0.10） 远程设备：显示服务器CPU名称及IP（192.168.0.12） 本地ID → W#16#100（十六进制，对应十进制256） 地址详细信息 → 本地TSAP：03.00（客户端默认值，不可改） 远程TSAP：03.00（服务器侧预设值，见后文说明）注意：TSAP（Transport Service Access Point）是S7通信的端口号概念。S7-1200固件将03.00和03.01预留给S7单边通信，其中03.00用于PUT/GET，03.01用于SFB/SFC通信。跨项目时若填错此处，STATUS会报16#80B2（TSAP不匹配），但连接图标仍显示绿色——这是最坑人的玄学现象。
2.3 数据块DB创建与非优化访问：为什么数组长度必须显式声明且禁用优化
在项目树中右键“程序块”→“添加新块”→选择“数据块（DB）”→命名为DB1。进入DB1编辑界面后，第一件事是点击工具栏“属性”按钮（齿轮图标），在弹出窗口中取消勾选“优化的块访问”。这是硬性要求：S7-1200的PUT/GET指令只能访问非优化DB块，因为优化块会动态重排变量地址、隐藏绝对偏移，导致ADDR_1参数指向错误内存区。接着定义变量：在DB1中添加一行，名称填“Data”，类型选“Array[0..9] of Byte”，即10字节定长数组。同理创建DB2，结构完全一致。注意：不要用“String”或“UDT”，PUT/GET只支持基础数据类型（Byte、Word、DWord、Real等）的连续数组。
# DB块属性设置路径（STEP 7 V13界面操作） DB1编辑界面 → 点击工具栏齿轮图标 → 取消勾选"优化的块访问" → 确定 DB1内部变量定义： Name: Data Type: Array[0..9] of Byte提示：DB块编号无特殊要求，但建议DB1用于PUT发送、DB2用于GET接收，与教程保持一致，避免自己绕晕。若后续扩展为20字节，只需改Array[0..19]，无需动其他参数。
2.4 OB1中PUT/GET指令调用：背景DB、触发沿、地址指针三要素缺一不可
在客户端CPU的OB1中，从指令库拖入“PUT”和“GET”功能块（路径：Instructions → Communication → S7 Communication）。每个指令必须关联独立的背景DB（Background DB），例如PUT用DB3，GET用DB4。绝不能共用同一个DB，否则STATUS状态字会被覆盖，无法独立判断收发结果。触发信号REQ必须接上升沿（如M0.0经FP触发），因为PUT/GET是单次执行指令，持续高电平会导致反复重发。最关键的是ADDR_1和SD_1/RD_1参数：它们必须用P#指针格式，且字节数必须与DB中数组长度严格一致。
// 客户端OB1中PUT指令调用（LAD或FBD均可，此处用ST语法示意） CALL "PUT", DB3 REQ := M0.0, // 上升沿触发，建议用FP(M0.0) ID := W#16#100, // 必须与网络视图中连接ID一致 DONE:= M0.5, // 发送完成标志 ERROR:=M0.6, // 故障标志 STATUS:=MW10, // 状态字，监控用 ADDR_1:=P#DB1.DBX0.0 BYTE 10, // 指向服务器DB1起始地址，长度10字节 SD_1:=P#DB1.DBX0.0 BYTE 10 // 本地DB1发送区，长度10字节 CALL "GET", DB4 REQ := M1.0, // 另一个上升沿触发信号 ID := W#16#100, // 同一连接ID NDR := M1.5, // 新数据接收标志 ERROR:=M1.6, STATUS:=MW12, ADDR_1:=P#DB2.DBX0.0 BYTE 10, // 指向服务器DB2起始地址 RD_1:=P#DB2.DBX0.0 BYTE 10 // 本地DB2接收区逻辑说明：ADDR_1是服务器侧的目标地址，SD_1/RD_1是客户端侧的源/目的地址。P#DB1.DBX0.0 BYTE 10表示“从DB1的DBX0.0开始取10个字节”，其中DBX0.0是字节0的第0位（即第一个字节），BYTE 10明确指定长度。若写成P#DB1.DBX0.0不带长度，编译会报错；若长度写错（如BYTE 11），则可能越界读写，STATUS报16#80C2（地址错误）。
2.5 连接状态与数据监控：在线诊断必须看这三个地方
下载程序前，先确保网络视图中S7连接图标为实心绿色（非虚线）。下载后进入在线模式，按以下顺序排查：
- 连接状态：在“网络视图”中右键S7连接→“显示连接状态”，确认“已建立连接”且“激活”为是；
- PUT/GET状态字：在监控表中添加MW10（PUT STATUS）和MW12（GET STATUS），正常值应为0；若为非零，查 西门子官方STATUS代码表 ；
- DB块实时值：打开DB1和DB2的在线监控，观察客户端DB1.Data[0]~[9]是否被正确写入服务器DB1，客户端DB2.Data[0]~[9]是否被服务器DB2更新。
注意：首次下载后需等待约5秒，S7连接才完成底层握手。若立即监控，NDR和DONE可能未置位，属正常现象。建议在OB1中加一个500ms定时器，让REQ信号每秒触发一次，便于观察循环收发。
3. 跨项目S7通信：当两台PLC不在同一工程文件时的TSAP硬编码与防火墙级放行
3.1 “未知设备”连接创建：为什么必须手动填写IP和TSAP而非搜索
跨项目场景下，服务器PLC（V2.0）已单独下载过程序，其IP和TSAP已固化。此时客户端项目中无法在“网络视图”里看到该设备，因此在创建S7连接时，“连接对象”必须选“未知”。关键操作是：在“创建新连接”对话框中，“站点”栏选“未知”，“地址”栏手动输入服务器IP（如192.168.0.12），“TSAP”栏必须填“03.00”。这里极易出错——有人习惯性填03.01，或留空让系统默认，结果连接看似建立（图标绿色），但PUT/GET始终失败。原因在于：S7-1200服务器固件将03.00硬编码为PUT/GET服务端口，03.01是SFB14/SFB15专用端口，填错即服务不可达。
# 跨项目S7连接属性关键字段（双击连接后查看） 常规 → 远程设备：显示"未知" 地址：192.168.0.12（服务器实际IP） 本地ID → W#16#100（与客户端PUT/GET指令ID一致） 地址详细信息 → 远程TSAP：03.00（必须手动输入，不可为空或03.01）提示：跨项目时客户端和服务器的STEP 7版本必须兼容。V13 SP1可连V2.0服务器，但V15及以上版本需用TIA Portal，本教程限定V13 SP1环境，避免版本混淆。
3.2 服务器侧TSAP与固件版本强绑定：V2.0与V4.0+的配置差异
S7-1200不同固件版本对TSAP的处理逻辑不同：
- V2.0服务器：出厂即开放03.00端口，无需额外设置，只要IP可达即可响应PUT/GET；
- V4.0+服务器：默认关闭所有远程通信入口，必须手动开启。操作路径：在服务器项目中，右键CPU设备→“属性”→“常规”→“保护”→勾选“允许从远程伙伴（PLC/HMI/OPC/...）使用PUT/GET通信访问”。此选项位于“连接机制”区域，若未勾选，客户端PUT会返回STATUS 16#80C3（拒绝访问），GET返回16#80C4（无权限）。
# V4.0+服务器必开选项（STEP 7 V13 SP1界面路径） CPU设备属性 → 常规 → 保护 → 连接机制 → 勾选"允许从远程伙伴...使用PUT/GET通信访问"注意：该设置修改后需重新下载整个CPU程序（包括硬件组态），仅下载块无效。曾有某导师在现场因忘记这步，折腾两小时以为网线坏了。
3.3 跨项目时的IP路由与ARP缓存：为什么ping通不等于S7通
即使客户端能ping通服务器IP，S7通信仍可能失败。根本原因是：S7协议在IP层之上增加了TSAP寻址，且依赖ARP表正确解析MAC地址。若服务器刚上电，客户端ARP缓存中无其MAC，首次PUT会超时。解决方案：在客户端PLC下载程序前，先用笔记本ping服务器IP（如ping 192.168.0.12），确保ARP表已更新；或在客户端OB1中加入ARP刷新逻辑（调用SFB65“TCON”建立TCP连接再断开，强制刷新）。
# 手动刷新ARP的Windows命令（调试时用） arp -d * # 清空ARP缓存 ping 192.168.0.12 # 触发新ARP请求 arp -a # 查看是否已学习到服务器MAC提示：工业现场交换机若启用了端口安全（Port Security），可能限制MAC地址学习数量，导致ARP失败。此时需联系IT人员临时关闭该端口的安全策略。
3.4 跨项目数据块同步：服务器DB必须与客户端定义完全一致
服务器侧只需创建DB1和DB2，结构与客户端完全相同（Array[0..9] of Byte），且同样要取消“优化的块访问”。但服务器DB无需任何调用指令——S7单边通信中，服务器是纯被动数据容器，只负责提供内存区。客户端PUT时，数据自动写入服务器DB1指定地址；客户端GET时，自动从服务器DB2指定地址读取。若服务器DB长度小于客户端指定长度（如服务器DB1只定义了5字节），STATUS会报16#80C2（地址越界）。
# 服务器DB1/DB2创建要点（与客户端镜像） DB1 → 属性：取消"优化的块访问" 变量：Data : Array[0..9] of Byte DB2 → 同上，结构完全一致注意：服务器DB的块编号（DB1/DB2）必须与客户端PUT/GET指令中的ADDR_1参数指向的DB编号一致。若客户端ADDR_1写P#DB3.DBX0.0，但服务器无DB3，则直接通信失败。
3.5 跨项目时的防火墙与端口策略：STEP 7 V13自带的通信端口范围
STEP 7 V13通过S7协议通信时，实际使用TCP端口范围是102~105（S7协议标准端口）。若客户端所在PC装有第三方防火墙（如360安全卫士、Windows Defender高级设置），可能拦截这些端口。解决方案：在防火墙中添加STEP 7 V13安装目录下的s7oiehsx.exe（S7通信服务进程）为信任程序，或开放TCP端口102~105。切勿关闭整个防火墙，这会带来安全风险。
# STEP 7 V13 S7通信相关进程路径（典型安装位置） C:\Program Files\Siemens\Automation\Portal V13 SP1\S7OIEHSX.exe C:\Program Files\Siemens\Automation\Portal V13 SP1\S7OIEHSX64.exe提示：若使用虚拟机调试，需检查VMware/VirtualBox的网络适配器模式是否为“桥接模式”，NAT模式下主机与PLC可能无法双向通信。
4. 避坑：PUT/GET通信中5个血泪教训总结（现象→原因→解决）
4.1 现象：STATUS=16#80C0，连接图标绿色但数据不收发
原因：客户端PUT/GET指令中的ID参数（如W#16#100）与网络视图中S7连接的“本地ID”不一致。常见于复制粘贴时ID被意外修改，或同一项目建了多个连接但ID重复。
解决：在“网络视图”中双击S7连接，核对“本地ID”值；再检查OB1中所有PUT/GET调用的ID参数，确保完全一致。用Ctrl+F全局搜索“W#16#”可快速定位。
4.2 现象：STATUS=16#80B2，连接状态显示“已建立”但NDR/DONE永不置位
原因：跨项目时，客户端S7连接属性中“远程TSAP”未手动填03.00，或填成了03.01/空值。V2.0服务器只监听03.00，填错即服务不可达。
解决：双击S7连接→“地址详细信息”→“远程TSAP”栏手动输入03.00→重新编译下载。
4.3 现象：客户端DB1数据已改，但服务器DB1监控值不变；或GET后客户端DB2值全为0
原因：服务器侧DB块未取消“优化的块访问”，导致PUT/GET指令无法定位到实际内存地址。优化块会将变量重排，ADDR_1指针失效。
解决：在服务器项目中，打开DB1/DB2→点击齿轮图标→取消勾选“优化的块访问”→重新下载DB块（无需重下整个CPU）。
4.4 现象：V4.0+服务器下载后PUT/GET始终失败，STATUS=16#80C3或16#80C4
原因：服务器CPU属性中未开启PUT/GET远程访问权限。V4.0+固件默认关闭此功能，属于安全策略升级。
解决：右键服务器CPU→“属性”→“常规”→“保护”→勾选“允许从远程伙伴...使用PUT/GET通信访问”→重新下载整个CPU（含硬件组态）。
4.5 现象：同一项目内通信正常，跨项目后第一次PUT成功，后续失败
原因：客户端PLC与服务器PLC之间ARP缓存过期，或服务器PLC因看门狗复位导致TSAP服务未及时重启。
解决：在客户端OB1中加入周期性ARP探测（如每30秒调用一次SFB65“TCON”连接服务器102端口后断开）；或在服务器侧增加“冷启动后延时10秒再启用通信”的逻辑（用TON定时器）。
5. 实战验证：用三步法快速定位90%的S7通信故障
5.1 第一步：物理层与网络层双确认（5分钟）
不要一上来就看STATUS，先做两件事：
- 测通断：用笔记本ping服务器IP（如
ping 192.168.0.12），若丢包率>0%，检查网线、交换机端口、IP冲突； - 查ARP：在笔记本执行
arp -a | findstr "192.168.0.12"，确认能解析出服务器MAC地址；若无结果，执行arp -d *清空缓存再ping一次。
这两步耗时不到5分钟，却能排除70%的“以为通了其实没通”的假象。我带过的A同学曾因交换机端口指示灯不亮，硬调了4小时STATUS代码，最后发现是网线水晶头压坏了。
5.2 第二步：连接状态与TSAP交叉验证（3分钟）
进入STEP 7 V13的“网络视图”，右键S7连接→“显示连接状态”，截图保存三个关键字段：
- “已建立连接”：必须为“是”；
- “激活”：必须为“是”；
- “远程TSAP”：必须为03.00（跨项目时尤其重要）。
然后打开客户端OB1，用Ctrl+F搜索所有ID :=，确认值与连接状态中“本地ID”完全一致。若发现不一致，立即修正并重新下载。
5.3 第三步：DB块与指针长度一致性审计（2分钟）
导出客户端和服务器的DB块定义（右键DB→“另存为”→选择XML格式），用文本编辑器对比：
- 变量名是否均为“Data”；
- 类型是否均为
Array[0..9] of Byte（注意上下界数字）； - 是否都取消了“优化的块访问”。
再检查PUT/GET指令中的ADDR_1和SD_1/RD_1参数，确认BYTE 10中的数字10与DB数组长度一致。曾有项目因服务器DB定义为Array[0..9] of Word（20字节），客户端仍按10字节发送，导致STATUS 16#80C2，查了两天才发现类型不匹配。
5.4 进阶技巧：用S7诊断缓冲区抓取原始错误帧
当上述三步仍无法定位，启用CPU内置诊断：在STEP 7 V13中，右键客户端CPU→“在线与诊断”→“诊断缓冲区”，筛选“通信”类事件。若看到“S7连接超时”或“TSAP不可达”，基本锁定网络或TSAP问题；若看到“访问被拒绝”，则直奔服务器保护设置。重点看“事件时间戳”与“模块标识符”——后者能精确定位到哪个PUT/GET指令出错（如“DB3.PUT”）。这个技巧让我在某高校实验室快速揪出一个被误删的背景DB，比查STATUS代码高效十倍。
从那以后我每次新建S7连接，都强制走一遍“ping→arp→连接状态→DB审计”四步 checklist，哪怕只是临时测试。因为S7通信的脆弱性不在协议本身，而在那些藏在UI角落里的开关、默认值和固件版本差异。希望帮到你。
本文还有配套的精品资源，点击获取
