Trace应用和场景分析又一例

上图的物理场景：设备的PLC首次上电，初次下载入程序之后。Modbus设备被初次设定参数前后的通信变化。

可以看到，靠近左侧的部分，5个温控器FB实例的MB_Addr都为0，和它们各自正在执行的通信任务序号iJob都为-1。

因为在程序中，这5个设备的从站号和波特率，我都没有写死为固定的数值。完全取决于上电后，操作人员根据现场的实际配置情况，从HMI上为它们分别输入，然后才能上线轮询。

初次上电，这些都为默认值，不会有通信。程序是动态实时在判定参数合法性。

所以在图中靠右侧部分的场景，你看到的含义就是：我在HMI上的每个设备的通信监控页面中，为它们各自分别设定从站号和波特率，它们就依次上线了。当然前提是每个设备的参数设置是正确的才行。

我手头只有两个温控器是连接的，所以在图中你看到，Device0、Device1、Device2它们的从站号都是1，Device3、Device4它们的从站号都是2。

对于PLC程序而言，它们是被当作不同的设备在轮询，而不管我在屏幕上究竟把他们设定为工艺中的哪一个具体设备，这是无关的。每个实例会根据自己被设定的参数，会按照规则自动呈现为它在工艺中应该承担的那个角色。这就像游戏的不同副本，取决于不同玩家一样。

下图物理场景是：首次上电设定的时候，为它们分别设定不同的参数。但其中有3个设备实际是不存在的（2、3、5），也就是这些参数虽然符合协议规则，当时却不符合实际情况是错的，所以它们上线后不久就会被踢下来。

总之，每个设备实例的参数，可以在屏幕上自由更改，自由决定上下线。

这意味着：如果我在PLC程序中预先加载了，更多的不同种类Modbus设备的空实例，如果未来在现场，根据工作需求，打算增加更多的物理Modbus设备，可以由工人在屏幕上直接设定，让它们加入上线通信，而无需程序员介入，完全不用改程序。

这些多出来的空设备实例，在不被初始化设定的时候，它们的实例主体是不会被真实运行的。所以基本不会耗费多少扫描周期中的计算资源。HMI上的设备面板是采用多路复用，也不会增加负荷。

上图是由现场工人为设备分配通道。可以随意更改设备轮询次序，但可以故意把多个设备挤到一个通道。这种自由配置模式下，对于消除因线路内在缺陷而产生的485网络噪声干扰有妙用（打破噪声干扰的相位条件）。如果没这么玩过，根本不会意识到还有这种事情。

上图是由程序自动为每个设备预留一个通道。简单化，且不会有冲突，但也把设备轮询次序固化了。

工人只需为每个设备设定从站号、波特率。并从角色列表中，为每个空实例，确定它在工艺中的角色担当。每个设备实例就会自动上线加入轮询，且在HMI上呈现为所选工艺角色的特定交互样貌。操作简单，符合现场设备的直觉理解。