以下内容为个人理解，并不一定对的：

首先Modbus TCP和Modbus RTU是可以互相转换的，TCP代表的是一个并发的理念，而我们古老的485是一种独占的理念，每个485从站都有一个地址作为身份令牌，在MB_CLIENT中那就是MB_Unit_ID。作为TCP它还有一个身份令牌就是IP地址了。在我们的普通Modbus TCP通讯中具备了IP地址那就可以进行通信了，MB_Unit_ID则显得无关紧要，因为已经有识别了，且可以是并发的，因此正常通信是没有问题的。

但是通信设备对象如果是Modbus RTU转成Modbus TCP协议网关的时候，这种通信就存在问题了。因为我们知道一条485总线下面可以带很多台设备，每台设备都有自己一个地址，如果MB_Unit_ID=3时，那就是通信从站地址为3的设备。如果需要对多台设备进行通信，我们就需要改变MB_Unit_ID实现对多从站设备的轮询功能，也就是我们常说的Modbus TCP的轮询功能。

然而在西门子的MB_CLIENT功能块设计中，西门子的工程师可能对Modbus TCP的轮询功能重视不够，此功能块无法完美达到我们像485总线功能块的轮询需求。

主要表现在以下方面：正常我们发送：0103 04 4C 00 01 44 ED

其中01是地址，03是功能码，04 4C是寄存器（我们常用的40001在原始码中就是00 00）

00 01是需要读取数据的长度，44 ED是CRC校验。

收：01 03 02 43 DA 08 EF

正确接收数据的格式：01是地址，03是功能码，02是数据长度，43 DA是数据，08 EF是CRC校验。

由于485的干扰问题，很容易出现错误的数据或错误的数值，因此我们接收数据的时候就需要对地址，功能码，数据长度及CRC校验来判断这串接收到的数据是否是我们需要的正确数据。

然而在MB_CLIENT的功能块中我们只能读取到的数据是43 DA，前面的01 03 02是读取不到的，如果MB_CLIENT能够严格的判断读取的数据是否正确，如果数据正确则DONE=1和STATUS=0也可以放心的进行数据轮询。可是通过简单的测试发现MB_CLIENT的功能块只能对数据是否符合Modbus规约做出一个判断，如果数据符合Modbus规约正确了就认为这串数据是正确了，并没有一个严谨的判断这串数据是否是我需要的正确的数据。

比如我发：01 03 04 4C 00 01 44 ED这时收：02 03 02 43 69 0D 5A那么这时MB_CLIENT接收的数据就是43 69而不是我们需要的43 DA了。

通过以上案例就可以比较清楚的发现当我们使用MB_CLIENT进行轮询的时候，没办法保证数据接收的时候是否会发生串数的可能，因为我们无法接收到从站发给我们的地址，这个时候接收的43 DA的数据就不能确定是哪个设备的数据了。

对于应用MB_CLIENT的轮询功能，之前做了一段时间的测试，正常通信的时候效果还是可以，但并不能保证不会存在串数的可能性，因此也是建议西门子的工程师可以完善此功能块，起码也是可以让使用人员有可以选择是否需要读取接收数据前段的地址码及功能码的选择。

至于ID可以简单理解为需要对两个以上的通信设备进行Modbus TCP通信时需要改成不一样的地址就可以了。相同的ID是不可以通信的。