最近在昆山力格样机中遇1515F+V90PN_IRT无法通讯问题

系统配置：1515F + 71个V90PN + 10个ET200S + 11个第三方PN_IO设备 +8个 菲尼克斯交换机。

网络结构：1515F.X1.P1串联所有交换机，IO设备再于交换机连接；1515F.X1.P2 连接8个V90走IRT。    

?起始V90PN全部使用Epos功能，设备通讯OK。后来由于工艺要求，8个V90PN需要齿轮同步，更改为工艺对象控制，并使用IRT方式，组态完下载后就通讯异常。难道是IO设备太多，影响IRT通讯，查看手册，此CPU支持IO设备数量最大值256个，其中包含IRT最大值64个，这个参数完全cover这个样机的配置，因为之前都是RT的通讯是可以的，感觉是IRT增加了网络负荷，于是手动更改RT的刷新时间，增大IRT同步时间，问题都无法解决，此时处于深深的绝望之中。

不行抓个包呗，于是在1515F.X1.P1口处的交换机端口进行抓包，瞬间出现超多PN-PTCP协议帧，突然想到好像和论坛里的问题一样啊，到论坛一看，果然和论坛里是同一类型的问题,结合之前论坛跟帖，IRT通讯异常的原因是菲尼克斯交换机不能对报文进行处理，CPU会同时收到RT和IRT的两侧的多个PTCP报文，导致CPU在做时间同步计算的时候就会出现错误。

处理方式：1515F.X1.P1和交换机之间插入ET200站进行“隔离”。

抓包_NG.png，

抓包_OK.png，

网络拓扑_更改.png

困惑：1，PN_TCPN 目标地址是LLDP_Multicas就是组播，那是如何分组的？看抓包数据感觉有点像多对一的单播。

           2，抓包里的源MAC地址在Pronate里居然找不到，数值上差1。

 补充说明：

因为Pronaeta不识别Phoenix交换机，使用了OK的拓扑图。拓扑图里红框为抓包位置

NG_PN-PTCP.png

NG_拓扑.png

通过上面2张图可以看出，因为Phoenix交换机不能处理PN_PTCP报文，从而导致PN_PTCP报文被组播到了PLC端口。

OK_PN-PTCP.png

OK_拓扑.png

 通过上面2张图可以看出，使用ET200进行交换机隔离，其他Phoenix交换机上的PN_PTCP报文已无法到达PLC端口。

关于MAC地址问题，一个模块的接口一般有2个MAC地址，而且是地址连续的，一个给Pronata，  DCP, ICMP用，一个给LLDP或者PTCP等协议使用。所以在抓包里的MAC地址与Pronata里的相差1个。

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

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同步稳定！

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