话说在那篇《一个PROFINET通信受干扰的案例》中，讲到在去某客户现场帮助解决一个涉及PROFINET和故障安全的问题时，意外发现PROFINET网络受干扰的现象。其实当时还有另外一个意外发现，就是在排查文中提到的网络受干扰现象时，发现某类从来没有掉过站的站点竟然有报文莫名其妙的少了，这是怎么回事呢？

当时对于交换机里出现的错误包，由于对应端口在同一电柜里，长约两米，而且是工业以太网线，安装很规范，一开始并没有让人往EMC方向考虑。在检查等电位之前，甚至怀疑会不会是交换机统计错了，于是就想用抓包的方式实际验证一下。由于现场有SCALANCE X200的交换机，因此抓包很容易，通过端口镜像就可以实现。

把最初在CPU侧抓取的数据包过滤，仅留下PNIO报文，为了看是否有丢包，对留下的报文查看统计分析信息，得到下图：

从这个图中可以看到，Address B是PLC，Address A是分布式IO站点，后面的是它们之间往来的报文数统计。请仔细看这些统计数据，理论上讲，正常情况下A发给B的PNIO报文和B发给A的PNIO报文应该数量一致才对，考虑到开始抓包和停止抓包的时间点的随机性，差2个以内可以算正常。差值超过3个以上，可能就有问题了，需要仔细甄别。

从上往下看，第四条的Pilz_41:e9:82这个节点它发送给CPU的比CPU发给它的少了3个报文，而这个节点正是交换机里统计有报文错误的节点。从这点看，交换机的统计是没错的，报文真的是出错了，而交换机把错误的报文丢弃，所以这里数量少了。

在上表中继续往下看，排在后面的MAC地址被解析为Pepperl和SEW的分布式IO站点发送给CPU的PNIO报文比CPU发给它的都少了约10个，这么多，这是什么个情况，报文都去哪了呢？

考虑到这是在CPU侧抓包，CPU的数据要 到达这些站点还经过了几个交换机，会不会是在传输路上跑丢了呢？

为此转换抓包位置，到某一个直接联接了SEW变频器的交换机上针对一台SEW变频器做端口镜像，抓包分析，结果是一致的。这就说明报文并不是在中途传丢了，而是从SEW变频器出来到交换机这一段就少了，而且交换机上相关端口并有任何错误报文统计。

这就怪了，一条条的去看这些报文，很难发现异常在哪里。

求助伟大的EXCEL工具，对A至B的报文和B至A的报文的时间间隔进行分析，可以发现：

CPU发送给SEW变频器的报文时间周期如下表，平均值是组态的刷新时间4ms.

而SEW变频器发送给CPU的报文时间周期如下表，平均值是4.005ms，总体偏慢。

而对比最大值和最小值，都在4ms左右，并没有差到两个两个刷新周期的8ms，因此可以断定，这个过程里面并没有报文丢失，唯一的解释就是SEW发送的报文本来就少。而造成的这个问题的原因，则可能是由于采用不同的PROFINET芯片，芯片性能（譬如时钟的准确性）有差异，某类站点时钟较慢，所以发送间隔偏 长，一段时间的统计结果就是报文发送少了。因为报文没丢，间隔也没有超过看门狗时间，所以也不会掉站。