现场一台1511-1PN（后悔选小了），带了G120PN和第三方的PN设备（伺服和扫码枪）。现在偶尔在第三方伺服通信这边会报IO设备故障，目前CPU扫描周期二十几毫秒，工作内存占用70%。这么长扫描周期是不是对PN通信也有影响？准备降低PN通信周期设置，把网线也升级下，实时IO设备换西门子交换机。

@yming

     非常感谢能把我带入这个贴子的讨论里来！

@ 刚刚入门

    首先，现场CPU的型号没有选小，若是选小了造成通信的问题，那出现故障的设备就不只是第三方的伺服设备，我们西门子的设备也同样会出现掉站的现象的。

    其次，根据你对现场情况的的描述，出现故障现象有可能需要从下面两个方面 排查：

      1、现场网络连接的设备比较多，但网络没有进行规划，以至于出现瞬间大量网络数据广播，进而使得第三方的设备的不正常工作（西门子的设备对瞬间大的广播做了限流处理，所以不会出现掉站的现象）

    2、可能是现场的某一段网线受电磁干扰，，以至于其后所连接的设备会出现偶然掉站的故障现象。

处理故障的方法：

     针对1的故障原因：可以了解一下现场的网络联网情况，然后再通过网络抓包分析数据流量情况，已经在网络上跑的协议有哪些。若确实存在此情况，建议通过三层交换机来划分VLAN，进而隔离其它网络的广播数据。

     针对2的故障原因：可以查看交换机的端口的统计信息，看有没有CRC校验的计数器一直在增加，若增加说明此网线受到了电磁干扰。建议移除干扰源或者是线缆的敷设方式改变一下。

   最后，修改CPU的扫描周期是不会影响到PROFINET的通信的，因为PN的通信是用的自己专用的通信处理器，而不是用的PLC CPU的通信资源。S7的通信或TCP/IP的通信用的是PLC CPU的通信资源，S7通信有问题时，可以修改CPU的扫描周期来改善通信。

若您确实着急且有需要的话，我们可以免费帮您到现场诊断和分析故障原因。

@yrxb_w

首先，感谢你提出了一个非常好的且大家会经常遇到的问题。

• 你描述的这个问题，其实与TCP/IP协议的工作机制有关。TCP/IP协议栈在通信的时候其实采用了如下的两个数据缓冲区进行数据的缓冲（你可以理解为计算的CPU与硬盘交换数据的时候不是直接交换的而是通过了中间内存进行数据的缓冲交换）,一个是 Shadow Buffer；一个是Stack Buffer。也正是由于这两个数据缓冲区的存在，使得发送数据和接收数据有时候周期是不一致的（即发送伙伴已经发送了数据，但接收伙伴没有接收到数据，数据在两伙伴之间的4个缓冲区中的一个缓冲区里，还没有被接收伙伴从接收伙伴的Shadow Buffer取到应用程序中，所以你看到的现象是数据通信周期不一致）。

Shadow buffer

• 调用TSEND，通信资源会分配相应的Shadow buffer且与发送DB大小一致

• 调用TRCV，通信资源会分配相应的Shadow buffer且与接收DB大小一致

• 禁止功能块，Shadow buffer不会消失

• 位于ISO的第7层，由通信资源维护，随通信资源的释放而释放 

Stack buffer

• 用于流量控制，理论上限制值从2~64K（最新的产品支持32K）

• 位于ISO的第4层，由通信资源维护并分配大小（未必是最大值）

• 随通信资源的释放而释放

1、当发送DB长度=接收DB长度

• Shadow Buffer的大小与数据DB的大小一致

• CPU2的 Stack Buffer中按照TCP的序号的先后顺序进行填充

• 数据缓冲区=Stack Buffer + Shadow buffer

• CPU2的DB读取Shadow Buffer中的数据

• 读取shadow buffer的数据后，该缓存标记为空，新的数据从Stack Buffer中推入

• 新数据从Stack Buffer推入到Shadow buffer的大小与Shadow buffer的大小一致

• CPU2读到第三次是CPU1本次发送的数据

• 由于编程时发送方的发送数据长度和接收方的接收长度一致， CPU2可以获取正确的数据

2、发送DB长度<接收DB长度

• CPU2的Shadow buffer大小是CPU1的发送数据的一倍

• CPU2的数据缓冲区=Stack Buffer + Shadow buffer

• 只有当CPU2的Shadow buffer满，即=DB长度，PLC才获取数据

• CPU1发送2次才能填满接收Shadow buffer区，此时读数据才有显示

• 获取正确的数据需要人为判断

3、发送DB长度>接收DB长度

• CPU2的Shadow buffer大小比CPU1的发送数据的小一半

• TCP的TPDU的数据最大Segment为1460bytes，那么2000bytes的数据会被分为2个包，分别为1460bytes和540bytes

• 由于Shadow buffer=1000bytes，那么Stack Buffer中只有前1000bytes写入Shadow buffer中

• 当Buffer被写满=DB长度，DB从Buffer中读取数据，PLC获取数据

• 数据被读取后，Stack Buffer中的数据再次写入Buffer，此时包括前一个报文剩余的460bytes+第二包数据540bytes

• 第一次的数据会立即被第二次的数据所覆盖，这意味着接收方很难判断数据的正确信息

2的“发送DB长度<接收DB长度” 和 3的“发送DB长度>接收DB长度 "都会造成数据不一致的情况。

解决办法

在接收方的 TRCV 功能块的管脚 ADHOC 设置为1 如下图：

这样发送伙伴通过Stack Buffer 传来一包数据后，接收伙伴的 Shadow Buffer 就动态创建对应数据长度大小的缓冲区来接收数据到DB块中。实现了变长数据发送和接收且保证数据周期的一致性。

@yming 版主

您的理解非常正确

您提到“要是有个软件可以仿真计算网络负荷”西门子还真有一个软件来进行网络负荷的仿真计算，在网络设计阶段就可以避免由于网络架构设计不合理造成的网络数据的拥堵。这个软件为 SINETPLAN，下载链接地址如下（激活临时试用授权可使用21天）：

https://support.industry.siemens.com/cs/ww/en/view/109763136

有关这个软件的使用的视频可以在1847学习平台上学习（可以快速入门），链接如下：

https://1847.siemens.com.cn/course/detail/1/18080/5002

希望您能使用它对您的网络架构进行自我评估。