PG/PC配置对实际通信的影响

背景

用step7组态时，需要分配设备名，需要扫描设备，分配设备名字，如图：

刚入行的时候，有时候自己用扫描在线网络节点的时候有些时候扫出来一片空白。百思不得其解，当时常常怀疑step7是不是有什么问题了。
后面工作久了，这个问题反而不常遇到了。也就没有机会重新再看看这个问题到底是怎么产生的。
久而久之，只当是自己记忆出了偏差。
如今，在研究另外一个问题的时候，好像探到这个问题产生的原因，故记录如下，以防再忘。

从PG/PC讲起

不管是用step7还是博图，第一步总是先去设置PG/PC，有了正确的网卡设置之后，组态工具才能正常的和现场设备通信，才能正常的时候下载/上载/监控等等功能。
那么，如果PG/PC被设置错误了，那结果又是怎样的呢？朴素的理解中，错误的设置直接结果就是设备不能正常连接。确实当我们忘了选择网卡，确实是这样的。
但是在另一个情况下的错误设置，反而让结果变得不那么清晰：

• 当电脑存在两个网卡，网卡A和网卡B，PG/PC设置使用网卡A，但是实际物理层却连接网卡B。这种情况下，结果究竟是怎么样的呢？

原因探究

在西门子的组态工具中，这种设置A实际B的情况，实际上可能会出现：

• 某些场景看起来是正常的，比如组态下载，比如在线监控
• 某些场景失效，比如设备名称分配，比如设备名称查找，比如PDM上载设备信息

原因如下：

• 下载、在线访问、块传输这类操作，很多是走三层IP路径，Windows网络栈有机会根据路由表把流量从真正可达的物理网卡发出去。
• 设备名称分配、设备名称查找这类操作，核心依赖的是二层DCP，它绑定的是具体网卡的以太网发包能力，不能像IP那样靠系统路由自动“绕到别的网卡”。

抓包现象

依旧设置A实际B，使用wireshark抓取从电脑到PLC的链路。

• 当下载组态时，发包都是IP层的，PN-CM都存在，每一个request都有响应的response。
• 当使用扫描设备节点时，没有抓到任何看起来和扫描相关的包。把PG/PC恢复正常，再次抓包，可以看到设备扫描的关键帧都是DCP帧。
• 在PDM操作时有同样的情况：PDM上传设备信息虽然是通过S7Comm（IP层）,但是上传之前，会首先进行一轮DCP identify。错误的配置导致PC端一帧也没从物理网口中发出去。

总结

在Siemens组态工具中，PG/PC 接口配置错误并不一定立即导致所有在线功能失效。对于基于IP 的通信功能，例如硬件组态下载、部分在线访问和S7通信操作，只要Windows网络路由仍能将数据包转发到实际连通现场网络的物理网卡，这些操作仍可能正常执行。
但对于依赖DCP的功能，例如设备查找、设备名称读取和名称分配，由于DCP工作在以太网二层，报文直接绑定到所选PG/PC网卡发送，无法依赖三层IP路由进行出口修正。因此，一旦PG/PC选择了错误网卡，DCP 报文将无法进入正确的现场二层网络，从而导致这些功能失败。