S7-1200 PUT/GET通讯避坑指南：DB块配置与自动连接5大关键点

1. 为什么PUT/GET通讯总在DB块上栽跟头

1.1 一个让无数工程师抓狂的现场

S7-1200做PUT/GET通讯，连接组态好了，硬件也下载了，一触发读写就报错。错误代码五花八门，有时候是16#05，有时候是16#0A，有时候干脆连接都建立不起来。你打开TIA Portal的在线诊断，看到一堆状态码，翻手册翻半天，最后发现——问题出在DB块上。

这个场景太常见了。PUT/GET是西门子PLC之间最基础的S7通讯方式，不需要写任何通讯指令代码，只要在硬件组态里建立S7连接，然后在程序里调用PUT和GET功能块就行。听起来简单，但实际操作中，DB块的配置、地址映射、数据类型的匹配，每一个环节都可能埋着坑。

我见过太多项目，通讯程序写得没问题，连接组态也没问题，但就是读不到数据。最后排查下来，要么是DB块没有取消优化访问，要么是偏移地址算错了，要么是绝对地址和符号地址混用导致数据错位。这些问题在手册里都有写，但手册不会告诉你实际项目中哪个坑最容易踩、哪个参数最容易被忽略。

这篇文章就是把这些年我在S7-1200 PUT/GET通讯上踩过的坑、总结的经验，系统地梳理一遍。从DB块复制到自动连接的5个关键点，每一个都配了实操步骤和排查方法。不管你是刚接触西门子PLC的新手，还是做了几年项目的老手，这些内容都能帮你少走弯路。

1.2 PUT/GET通讯的本质是什么

先把概念理清楚。PUT/GET是S7通讯的一种，基于S7协议，用于西门子PLC之间的数据交换。它的核心特点是：不需要在程序中编写通讯指令，通讯的建立和数据传输由PLC的操作系统在后台完成。你只需要做两件事：在硬件组态中建立S7连接，在程序中调用PUT/GET功能块。

PUT是写操作，把本地数据写到远程PLC；GET是读操作，把远程PLC的数据读到本地。两者都是通过S7连接进行的，连接建立在TIA Portal的“设备与网络”视图中完成。

这里有一个关键点：PUT/GET通讯的双方必须都支持S7通讯。S7-1200全系支持，S7-1500也支持，但S7-200 SMART就不行，它只支持S7协议的部分功能。如果你要和S7-200 SMART通讯，得用GET/PUT指令，那是另一套东西。

还有一个容易被忽略的点：PUT/GET通讯是单向的。也就是说，A站调用PUT向B站写数据，B站不需要做任何编程，数据就直接写进去了。同样，A站调用GET从B站读数据，B站也不需要编程。这个特性让PUT/GET非常适合做PLC之间的数据同步，但也意味着B站的数据安全性完全依赖于A站的程序逻辑，如果A站程序写错了，可能把B站的数据覆盖掉。

1.3 为什么DB块是重灾区

DB块在PUT/GET通讯中扮演着核心角色。PUT/GET读写的数据，最终都落在DB块里。但S7-1200的DB块有一个特性：默认是优化访问的。优化访问的DB块，变量没有固定的绝对地址，只有符号名。而PUT/GET通讯需要的是绝对地址，因为通讯双方需要约定好“从哪个字节开始读、读多少个字节”。

这就产生了一个根本矛盾：优化DB块没有绝对地址，PUT/GET需要绝对地址。解决办法只有一个：把DB块改成非优化访问。在DB块的属性里，取消勾选“优化的块访问”，然后编译，TIA Portal会自动为每个变量分配偏移量。

但问题来了。取消优化访问后，DB块的偏移量是TIA Portal自动分配的，你无法手动指定。这意味着，如果你在DB块里加了一个变量，或者改了一个变量的数据类型，整个DB块的偏移量布局可能全部改变。而PUT/GET的地址参数是硬编码的，一旦偏移量变了，通讯就会出错。

这就是为什么很多工程师在调试阶段通讯正常，一旦修改了DB块结构，通讯就挂了。更麻烦的是，这种错误往往不会立即报错，而是读到错误的数据，或者写坏远程PLC的数据，排查起来非常困难。

2. 五个关键点逐一拆解

2.1 关键点一：DB块必须取消优化访问

这是最基础的一步，也是最容易忘记的一步。新建DB块时，TIA Portal默认勾选“优化的块访问”。这个选项在DB块的属性里，右键DB块，选择“属性”，在“属性”选项卡里找到“优化的块访问”，取消勾选。

取消后，编译DB块，TIA Portal会在“偏移量”列显示每个变量的绝对地址。这个地址就是PUT/GET通讯中要用的地址。

注意：取消优化访问后，DB块中的变量不能再使用“符号名”访问，必须使用绝对地址。如果你在程序中用了符号名访问这个DB块，编译会报错。

实际操作中，我建议专门为PUT/GET通讯建立独立的DB块，不要和程序逻辑用的DB块混在一起。这样做的好处是：通讯用的DB块结构稳定，不会因为程序逻辑的修改而变动；程序逻辑用的DB块可以保持优化访问，享受符号寻址的便利。

建立通讯专用DB块时，变量的排列顺序也有讲究。把相同数据类型的变量放在一起，比如所有BOOL放在一起，所有INT放在一起，所有REAL放在一起。这样做的好处是减少偏移量的碎片化，让地址布局更紧凑，也更容易计算。

2.2 关键点二：偏移量计算必须精确到字节

PUT/GET的地址参数格式是：DB号.偏移量，比如DB1.DBX0.0表示DB1的第0个字节的第0位，DB1.DBW2表示DB1的第2个字节开始的字，DB1.DBD4表示DB1的第4个字节开始的双字。

这里有一个非常容易出错的地方：偏移量的单位是字节，不是位。BOOL类型的变量占1个位，但在DB块中，BOOL变量是按字节对齐的。也就是说，如果你在DB块里定义了8个BOOL变量，它们会占用1个字节（8个位）。但如果定义了9个BOOL变量，就会占用2个字节。

更麻烦的是，不同数据类型的对齐方式不同。BOOL按位对齐，BYTE按字节对齐，INT按字对齐（2字节），DINT和REAL按双字对齐（4字节）。这意味着，如果你在DB块里混合定义了不同类型的数据，TIA Portal会自动插入填充字节，保证每个变量都对齐到正确的边界。

举个例子。假设DB块里有以下变量：

Start和Stop各占1个位，共占1个字节（偏移量0.0到0.7）。Speed是INT，需要2字节对齐，所以从偏移量2开始，占用字节2和3。Position是DINT，需要4字节对齐，所以从偏移量4开始，占用字节4到7。

注意偏移量1被跳过了，因为Speed需要2字节对齐，不能从偏移量1开始。这就是填充字节。

如果你在PUT/GET中要读Speed，地址是DB1.DBW2；要读Position，地址是DB1.DBD4。如果你算错了，写成DB1.DBW1，读到的就是错误的数据。

实操心得：在TIA Portal中，编译DB块后，偏移量列会显示每个变量的绝对地址。直接看这个地址，不要自己算。自己算很容易出错，尤其是变量多的时候。

2.3 关键点三：PUT/GET功能块的参数配置

PUT和GET功能块在TIA Portal的指令树里，路径是“指令 > 通讯 > S7通讯 > PUT/GET”。PUT是写，GET是读。

以GET为例，它的参数有：

ADDR_1的格式非常关键。它的完整格式是：DB号.偏移量 数据类型 长度。比如DB1.DBX0.0 BYTE 10表示从DB1的第0个字节开始读10个字节。

这里有几个容易出错的地方：

第一，数据类型和长度必须匹配。如果你写DB1.DBX0.0 BYTE 10，表示读10个字节。如果你写DB1.DBW0 INT 5，表示读5个INT，也就是10个字节。两种写法读的数据量一样，但数据类型不同，远程PLC的DB块中对应的变量类型必须匹配。

第二，偏移量必须和远程PLC的DB块偏移量一致。这是最容易出错的地方。你在本地写DB1.DBW2，远程PLC的DB块中，偏移量2的位置必须是你想读的变量。如果远程PLC的DB块结构变了，偏移量2的位置变成了别的变量，你读到的就是错误的数据。

第三，RD_1的地址必须和ADDR_1的数据类型匹配。如果ADDR_1读的是INT，RD_1也必须是INT。如果ADDR_1读的是BYTE数组，RD_1也必须是BYTE数组。

注意：PUT/GET功能块的REQ参数需要上升沿触发。如果你用常闭触点触发，功能块会一直执行，导致通讯负载过高。正确的做法是用一个时钟脉冲或者手动触发的上升沿。

2.4 关键点四：S7连接的建立与ID号确认

S7连接在TIA Portal的“设备与网络”视图中建立。具体步骤是：打开“设备与网络”，在“连接”选项卡中，选择“S7连接”，然后拖动鼠标从本地PLC的通讯口连接到远程PLC的通讯口。

连接建立后，TIA Portal会自动分配一个ID号。这个ID号就是PUT/GET功能块中ID参数的值。你可以在连接的属性中查看这个ID号。

这里有一个坑：如果你建立了多个S7连接，ID号会不同。比如你建立了两个连接，一个是本地PLC到远程PLC1，另一个是本地PLC到远程PLC2，那么两个连接的ID号分别是1和2。在调用PUT/GET时，必须用对应的ID号。如果用错了ID号，通讯会失败。

还有一个坑：S7连接是单向的。也就是说，你在本地PLC的组态中建立了到远程PLC的连接，这个连接只用于本地PLC主动发起的通讯。如果远程PLC也要主动读写本地PLC的数据，需要在远程PLC的组态中也建立一个连接。

实操心得：在硬件组态中建立S7连接后，建议在连接属性中把连接名称改成有意义的名字，比如“PLC1_to_PLC2”。这样在程序中调用PUT/GET时，不容易搞混ID号。

2.5 关键点五：自动连接与手动连接的取舍

TIA Portal支持两种S7连接方式：自动连接和手动连接。

自动连接是在“设备与网络”视图中，通过拖动通讯口建立的连接。TIA Portal会自动分配连接ID，自动配置连接参数。这种方式简单快捷，适合大多数场景。

手动连接是在程序中通过指令建立连接。这种方式灵活，可以在运行时动态建立连接，但编程复杂，容易出错。

对于大多数项目，我建议用自动连接。自动连接的优点是：配置简单，不容易出错；连接参数由TIA Portal管理，不需要手动干预；连接状态可以在“设备与网络”视图中直观查看。

但自动连接也有一个限制：连接数量有限。S7-1200的S7连接数量取决于CPU型号。比如CPU 1214C最多支持8个S7连接，CPU 1215C最多支持16个。如果你需要连接的设备超过这个数量，就得考虑用其他通讯方式，比如Modbus TCP。

注意：S7连接数量是有限制的，不是无限的。在项目规划阶段就要考虑好需要多少个S7连接，避免后期发现连接数不够用。

3. 完整实操流程：从零建立PUT/GET通讯

3.1 硬件组态与网络配置

假设你有两台S7-1200 PLC，一台作为主站（主动读写），一台作为从站（被动读写）。两台PLC通过以太网交换机连接。

第一步，在TIA Portal中新建项目，添加两台S7-1200 PLC。分别命名为“PLC_1”和“PLC_2”。

第二步，配置两台PLC的IP地址。在“设备与网络”视图中，双击PLC_1的以太网口，设置IP地址为192.168.0.1，子网掩码255.255.255.0。同样，设置PLC_2的IP地址为192.168.0.2。

第三步，建立S7连接。在“设备与网络”视图中，切换到“连接”选项卡，选择“S7连接”，然后从PLC_1的以太网口拖动到PLC_2的以太网口。TIA Portal会自动创建一个S7连接，并分配连接ID。

第四步，查看连接ID。在连接上右键，选择“属性”，在“常规”选项卡中可以看到连接ID。记下这个ID号，后面编程要用。

3.2 从站DB块的建立与配置

在PLC_2中新建一个DB块，命名为“DB_Comm”。右键DB块，选择“属性”，在“属性”选项卡中取消勾选“优化的块访问”。

在DB块中定义以下变量：

编译DB块，确认偏移量列显示正确。

注意：DB块的偏移量是TIA Portal自动分配的，不要手动修改。如果你手动修改了偏移量，编译时TIA Portal会报错。

3.3 主站PUT/GET程序的编写

在PLC_1的OB1中，调用GET功能块，读取PLC_2的数据。

GET功能块的参数配置如下：

• REQ：用M0.0的上升沿触发
• ID：填入S7连接的ID号，假设是1
• ADDR_1：DB1.DBX0.0 BYTE 12，表示从DB1的第0个字节开始读12个字节
• RD_1：DB2.DBX0.0 BYTE 12，表示读到本地DB2的第0个字节开始的位置

这里解释一下为什么是12个字节。Status和Alarm各占1个位，共占1个字节（偏移量0.0到0.7）。Speed是INT，占2个字节（偏移量2到3）。Position是DINT，占4个字节（偏移量4到7）。Temperature是REAL，占4个字节（偏移量8到11）。总共12个字节。

在PLC_1中新建一个DB块，命名为“DB_Recv”，取消优化访问。定义一个BYTE数组，长度为12。GET功能块的RD_1参数指向这个数组。

然后，在程序中把DB_Recv中的字节解析成对应的数据类型。比如，DB_Recv的第0个字节的第0位是Status，第0个字节的第1位是Alarm，第2到3个字节是Speed，第4到7个字节是Position，第8到11个字节是Temperature。

实操心得：解析字节数组时，可以用MOVE指令或者AT覆盖指令。AT覆盖指令更灵活，可以直接把BYTE数组覆盖成结构体，方便访问。

3.4 通讯测试与状态监控

下载程序到两台PLC，然后在线监控。

在PLC_1中，触发M0.0的上升沿，观察GET功能块的DONE和ERROR引脚。如果DONE为1，ERROR为0，说明读操作成功。如果ERROR为1，查看STATUS引脚的状态码。

常见状态码：

如果通讯成功，可以在PLC_1的监控表中查看DB_Recv的数据，确认和PLC_2的DB_Comm数据一致。

4. 常见问题与排查技巧实录

4.1 状态码速查与排查思路

PUT/GET通讯出错时，STATUS引脚会返回一个状态码。这个状态码是排查问题的第一手线索。下面整理了我实际项目中遇到过的常见状态码和排查方法。

16#05：连接未建立。这个错误最常见。原因通常是S7连接没有下载到PLC，或者ID号填错了。排查方法是：在“设备与网络”视图中确认S7连接存在，然后在线查看PLC的连接状态。如果连接状态是“未建立”，重新下载硬件组态。

16#0A：地址错误。这个错误说明ADDR_1的地址格式不对，或者远程PLC的DB块中不存在这个地址。排查方法是：确认远程PLC的DB块已经下载，确认DB块的偏移量和ADDR_1中写的一致。特别注意，如果远程PLC的DB块是优化访问的，PUT/GET会报这个错误。

16#0B：数据类型错误。这个错误说明ADDR_1的数据类型和远程PLC的DB块中对应变量的数据类型不匹配。比如ADDR_1写的是INT，但远程PLC的DB块中对应位置是REAL。排查方法是：核对远程PLC的DB块变量定义，确认数据类型一致。

16#0C：远程PLC未响应。这个错误说明本地PLC发出了请求，但远程PLC没有响应。原因可能是远程PLC不在线，或者IP地址不对，或者网络不通。排查方法是：ping一下远程PLC的IP地址，确认网络连通。

实操心得：PUT/GET的STATUS状态码是十六进制的，在TIA Portal的在线监控中可以直接看到。如果状态码是16#05，先检查连接；如果是16#0A，先检查地址；如果是16#0B，先检查数据类型。按照这个顺序排查，效率最高。

4.2 DB块修改后通讯失效的预防措施

这是PUT/GET通讯中最隐蔽的坑。DB块修改后，偏移量变了，但PUT/GET的地址参数没变，导致通讯读到错误的数据，或者写坏远程PLC的数据。

预防措施有三个：

第一，通讯专用DB块保持稳定。为PUT/GET通讯建立独立的DB块，这个DB块只用于通讯，不用于程序逻辑。这样，程序逻辑的修改不会影响通讯DB块的结构。

第二，DB块修改后重新编译并核对偏移量。每次修改通讯DB块后，重新编译，然后核对每个变量的偏移量。如果偏移量变了，同步修改PUT/GET的地址参数。

第三，用符号名代替绝对地址。在TIA Portal中，PUT/GET的ADDR_1参数支持符号名。比如，你可以写"DB_Comm".Speed，而不是DB1.DBW2。这样，即使DB块的偏移量变了，符号名不变，通讯仍然正常。

但符号名有一个限制：远程PLC的DB块必须是非优化访问的，且符号名必须和本地一致。如果远程PLC的DB块是优化访问的，符号名不可用。

注意：用符号名访问远程PLC的DB块时，符号名必须完全一致，包括大小写。如果远程PLC的DB块中变量名是“Speed”，本地写“speed”，通讯会失败。

4.3 通讯负载与扫描周期的影响

PUT/GET通讯是在PLC的扫描周期中执行的。如果通讯数据量大，或者通讯频率高，会占用PLC的扫描时间，导致扫描周期变长。

S7-1200的通讯负载能力有限。根据西门子的文档，S7-1200的通讯负载不应超过扫描周期的20%。如果超过这个比例，PLC的扫描周期会明显变长，影响程序逻辑的执行。

实际项目中，我建议控制PUT/GET的触发频率。不要用常通触点触发，也不要用高频时钟触发。用1Hz或者更低频率的时钟触发就够了。如果数据量大，可以分多次读写，每次读写一部分数据。

还有一个技巧：把PUT/GET放在OB1的最后。这样，通讯操作不会阻塞程序逻辑的执行。如果通讯超时，程序逻辑仍然可以正常运行。

实操心得：在调试阶段，可以用TIA Portal的“在线与诊断”功能查看PLC的扫描周期和通讯负载。如果扫描周期明显变长，说明通讯负载过高，需要降低通讯频率或减少通讯数据量。

4.4 跨网段通讯的注意事项

PUT/GET通讯默认在同一网段内进行。如果两台PLC在不同的网段，需要配置网关。

S7-1200支持跨网段通讯，但需要在硬件组态中配置路由器地址。具体步骤是：在PLC的以太网口属性中，设置IP地址、子网掩码和路由器地址。路由器地址是网关的IP地址。

跨网段通讯时，PUT/GET的ID号仍然是S7连接的ID号，不需要修改。但需要注意，跨网段通讯的延迟比同网段大，通讯超时时间可能需要调整。

注意：跨网段通讯时，确保网关设备允许S7协议通过。有些防火墙会屏蔽S7协议，导致通讯失败。

5. 进阶技巧：让PUT/GET通讯更稳定

5.1 用心跳信号监测通讯状态

PUT/GET通讯是单向的，本地PLC无法直接知道远程PLC是否在线。如果远程PLC断电或者网络断开，本地PLC的PUT/GET会报错，但错误可能不会立即显现。

解决办法是加一个心跳信号。在远程PLC的DB块中定义一个心跳变量，比如一个INT，每隔1秒加1。本地PLC用GET读取这个心跳变量，如果心跳变量在变化，说明通讯正常；如果心跳变量不变，说明通讯中断。

心跳信号的实现很简单。在远程PLC的OB1中，用一个1Hz的时钟脉冲触发一个ADD指令，把心跳变量加1。本地PLC用GET读取心跳变量，然后比较两次读取的值。如果值变了，通讯正常；如果值没变，通讯中断。

实操心得：心跳信号是监测通讯状态最可靠的方法。比看PUT/GET的ERROR引脚更可靠，因为ERROR引脚只在通讯出错时置位，如果通讯缓慢中断，ERROR引脚可能不会立即置位。

5.2 数据一致性保障

PUT/GET通讯读写的是DB块中的连续字节。如果远程PLC的程序在PUT/GET读写的同时修改了DB块中的数据，可能导致数据不一致。

比如，本地PLC用GET读取远程PLC的DB块中的Speed和Position。如果远程PLC的程序在GET读取Speed之后、读取Position之前修改了这两个变量，本地PLC读到的Speed和Position可能不是同一时刻的值。

解决办法是在远程PLC中加数据锁。在远程PLC的DB块中定义一个BOOL变量作为数据锁。远程PLC的程序在修改数据前，先检查数据锁是否为0；如果为0，置1，然后修改数据，修改完后置0。本地PLC的GET操作在读取数据前，先读取数据锁；如果数据锁为0，读取数据；如果为1，等待。

这个方法增加了程序的复杂性，但对于数据一致性要求高的场景，是必要的。

5.3 通讯中断后的自动恢复

PUT/GET通讯中断后，需要重新触发才能恢复。如果本地PLC的程序只用上升沿触发PUT/GET，通讯中断后不会自动恢复。

解决办法是用定时器周期性触发PUT/GET。比如，用一个1秒的定时器，每隔1秒触发一次PUT/GET。这样，即使通讯中断，1秒后会自动重试。

但要注意，如果通讯持续中断，PUT/GET会持续报错，STATUS引脚会持续输出错误码。这时候需要在程序中加错误处理逻辑，比如通讯中断超过一定次数后，触发报警。

注意：周期性触发PUT/GET时，要确保上一次操作已经完成。如果上一次操作还没完成，下一次触发会被忽略。可以用DONE引脚或者BUSY引脚来判断上一次操作是否完成。

5.4 大数据量通讯的分包策略

S7-1200的PUT/GET单次通讯的数据量有限制。根据西门子的文档，单次通讯的数据量不应超过160字节。如果数据量超过160字节，需要分包。

分包策略有两种：按数据量分包和按数据类型分包。

按数据量分包是把大数据分成多个160字节的小包，依次读写。按数据类型分包是把不同数据类型的数据分开读写，比如先读BOOL，再读INT，再读REAL。

我建议用按数据类型分包。这样做的好处是：数据类型匹配简单，不容易出错；每个包的数据量小，通讯负载低；如果某个包出错，不影响其他包。

实操心得：分包时，建议在DB块中把相同数据类型的变量放在一起。这样，分包时只需要按数据类型分组，不需要逐个变量计算偏移量。

6. 从DB块复制到自动连接的完整检查清单

6.1 项目规划阶段的检查项

在项目规划阶段，需要确认以下事项：

• 确认两台PLC的型号和通讯口数量，确认支持S7通讯
• 确认S7连接数量是否满足需求，S7-1200的S7连接数量有限
• 确认网络拓扑，确认IP地址规划，确认是否跨网段
• 确认通讯数据量，确认是否需要分包
• 确认通讯频率，确认是否会影响扫描周期

注意：S7-1200的S7连接数量取决于CPU型号。CPU 1214C最多8个，CPU 1215C最多16个。在项目规划阶段就要确认连接数是否够用。

6.2 硬件组态阶段的检查项

在硬件组态阶段，需要确认以下事项：

• 两台PLC的IP地址在同一网段，或者网关配置正确
• S7连接已建立，连接ID已记录
• 连接已下载到PLC，在线查看连接状态为“已建立”
• 远程PLC的DB块已建立，已取消优化访问
• 远程PLC的DB块已编译，偏移量已核对

实操心得：硬件组态下载后，建议在线查看连接状态。如果连接状态不是“已建立”，检查IP地址和连接配置。

6.3 程序编写阶段的检查项

在程序编写阶段，需要确认以下事项：

• PUT/GET功能块的ID参数和S7连接ID一致
• ADDR_1的DB号和偏移量和远程PLC的DB块一致
• ADDR_1的数据类型和长度和远程PLC的DB块一致
• RD_1的地址和ADDR_1的数据类型匹配
• REQ参数用上升沿触发，不用常通触点
• 错误处理逻辑已编写，STATUS引脚已监控

注意：ADDR_1的格式是“DB号.偏移量 数据类型 长度”，比如“DB1.DBX0.0 BYTE 12”。格式中的空格和点号不能省略。

6.4 调试阶段的检查项

在调试阶段，需要确认以下事项：

• PUT/GET的DONE引脚为1，ERROR引脚为0
• STATUS引脚的状态码为0
• 本地接收的数据和远程PLC的数据一致
• 通讯负载不超过扫描周期的20%
• 通讯中断后能自动恢复

实操心得：调试阶段建议用监控表实时查看通讯数据。如果数据不一致，先检查DB块的偏移量，再检查数据类型。

6.5 运维阶段的检查项

在运维阶段，需要确认以下事项：

• 通讯状态定期巡检，心跳信号正常
• DB块修改后重新编译并核对偏移量
• 通讯错误日志定期查看，及时发现潜在问题
• 备件PLC的DB块结构和在用PLC一致

注意：备件PLC的DB块结构必须和在用PLC一致，否则备件PLC替换后通讯会失败。建议定期备份PLC程序，包括DB块。

7. 个人实操体会

PUT/GET通讯看起来简单，但实际项目中坑不少。我做了这么多年项目，总结下来，最容易出问题的就是DB块。DB块的优化访问、偏移量计算、数据类型匹配，每一个环节都可能出错。

我的建议是：通讯专用DB块保持稳定，不要频繁修改。如果必须修改，修改后一定要重新编译并核对偏移量。另外，用符号名代替绝对地址，可以大大减少偏移量变化带来的问题。

还有一点，不要忽视通讯负载。S7-1200的通讯能力有限，PUT/GET的频率不要太高，数据量不要太大。如果数据量大，分包处理。如果通讯频率高，降低频率或者用其他通讯方式。

最后，心跳信号是监测通讯状态最可靠的方法。不要只依赖PUT/GET的ERROR引脚，加一个心跳信号，可以及时发现通讯中断，避免数据丢失。

这些经验都是实际项目中踩坑踩出来的，希望能帮到正在做S7-1200 PUT/GET通讯的你。