最近有客户也遇到类似的问题，原拓扑如下图所示：

NG_Topology.jpg

按余工的解决办法，修改拓扑后，网络正常了，修改后的拓扑如下：

OK_Topology.jpg

另外，PN设备名称和转换的名称中。转换的名称只支持四种字符：小写字母、数字、英文减号-、英文点. ，很多时候组态有问题，都是 设备名称 转换的名称 分配的名称不统一造成的。

补充：

因为不在现场，所以只能借余工的图作了简单分析，

NG analysis.png

OK analysis.png

通过搜到的资料里PTCP两种解释：1. Precision Time Control Protocol (PTCP)，主要基于链路层来同步多个PLC的时钟/时间信号；2. Precise transparent clock protocol, 作用同1，主要完成同步和测量延时时间。两种解释感觉差别不大。

NG OK 图片里，主要三种报文 Delay.Req、Delay.Rsp、DelayFuRsp。这里涉及到延时响应机制，如下图：

Delay Request-Response Mechanism.png

T2=Offset+T1+Delay; T3+Delay=T4+Offset. 二元一次方程，可求得Offset跟Delay。这里重点就来了，这offset跟delay不是白算的，请求不是白发的，发了肯定是要修正同步时钟的NG里面有PLC的一组测试报文，那PLC的同步时钟会不会有改变就不知道了。

NG的图中我理解，同步时钟是从连接PLC的第一个交换机开始建立的，而交换机无法了解PLC的主要地位，所以也在测试PLC的Offset跟Delay，PLC很可能会根据测试结果来修改自己同步时钟，从而使IRT的同步时钟也乱了。

而OK的图中，同步时钟就是PLC先修ET200SP（报文看不到）然后ET200SP修其它设备，逻辑清晰，PLC主要地位明显，没有报文去修改PLC的同步时钟，使得IRT同步稳定！

后补的纯属个人分析，肯定有错的，不要被我带沟里，还希望专家及时来指正！