1500/1200中的Modbus TCP（MB_CLIENT）可以轮询吗

实际需求：现场电力仪表通过八串口Modbus协议转换网关将Modbus RTU转成Modbus TCP由PLC1500或1200进行采集数据。每个485口下面计划带10台设备，总共计划可带80台设备。

PLC程序编写：PLC采用MODBUS TCP指令中的MB_CLIENT进行编写。

实际问题：在编程的过程中，由于需要改变MB_Unit_ID对485设备进行轮询通讯，发现MB_CLIENT接收的数据中没有485设备返回数值中最初始的地址码，功能码及数据长度的信息，只有485设备的数据值。通过串口调试工具发送错误指令，发现MB_CLIENT接收的数据DONE和STATUS都是成功的，并没有一个错误的筛选。那么就会产生一个严重的问题，比如我当前要查询的是07的地址，刚好是地址是06的数据返回了，那么就会将06的数据吴认为是07的数据了。

想问一下各位大神有没有做过类似的Modbus TCP轮询程序，是用MB_CLIENT进行编写的吗？在实际应用中是否可能存在错误？

数量很多的可以轮询，只有几个设备或者几个地址段的时候可以同时读写。

举个简单的Modbus案例

发：01 03 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的功能块只能对数据长度做出一个判断，如果数据长度正确了就认为这串数据是正确了，并没有一个严谨的判断这串数据是否是我需要的正确的数据。

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

可以轮询，参考官方《S7-1200例程合集V1.0》。

多谢提供案例，现在要出去开台了，回来有时间认真研究一下。有时间大神们也可以研究一下MB_CLIENT这个块，看有没有办法解决此类问题。

很详细，学习了

经过测试，在MB_CLIENT的功能块中接收数据时只要数据符和Modbus规约即认为接收数据成功，并没有辨认该数据是否为当前所请求的数据。如发03 03 00 0D 00 22 55 F2，此时接的是01 03 02 43 6A 09 5B那么MB_CLIENT也是认为接收的数据是正确的。

因此如果需要确保轮询正确就需要保证在一个通讯周期内只发送一次数据，接收完成后或者通讯超时后再发送下一次数据。

经过一段时间的模拟测试，MB_CLIENT功能块如果需要进行轮询编程时需要注意以下几点问题。

1.     MODBUS从站地址MB_Unit_ID需要进行一个通讯超时自动轮询下一个地址的设定，简单的可以采用一个定时器进行一个自加1的控制，延时建议为500MS。如果有设备通讯（DONE）成功则自加1，定时器重新计时。

2.       REQ必须采用脉冲控制，当MB_Unit_ID改变时REQ置1，经过MB_CLIENT功能块后复位。

3.       Rcv_Timeout默认2S，需要改成0.5S和通讯超时定时器时间设置一致。

4.       如果轮询的设备数据的长度不一致时建议每次通讯成功后将MB_DATA_PTR数据清0。

经过以上设置可实现通讯超时500MS，通讯成功时立刻进行下个设备通讯。由于保证了每个通讯周期只发送一次数据请求，那么在该通讯周期中接收的数据必然是正确的数据。

多个客户端连接

Modbus TCP 客户端可以支持多个 TCP 连接，连接的最大数目取决于所使用的 CPU。一个 CPU 的总连接数，包括 Modbus TCP 客户端和服务器的连接数，不能超过所支持的最大连接数。Modbus TCP 连接还可由“MB_CLIENT”和/或“MB_SERVER”实例共用。

使用各客户端连接时，请记住以下规则：

每个“MB_CLIENT”连接都必须使用唯一的背景数据块。

对于每个“MB_CLIENT”连接，必须指定唯一的服务器 IP 地址。

每个“MB_CLIENT”连接都需要一个唯一的连接 ID。

该指令的各背景数据块都必须使用各自相应的连接 ID。连接 ID 与背景数据块组合成对，对每个连接，组合对都必须唯一。

根据服务器组态，可能需要或不需要 IP 端口的唯一编号。

您好，这个是帮助的描述，我有点不太确定，是不是1500作为modebus tcp客户端读取10个仪表，需要建立10个背景数据块。。。

另外要给问题就是，你提到的 2.       REQ必须采用脉冲控制，当MB_Unit_ID改变时REQ置1，经过MB_CLIENT功能块后复位。

Modbus 设备检测：

Modbus TCP 服务器使用其 IP 地址寻址。因此，寻址 Modbus TCP 时不会使用 MB_UNIT_ID 参数。

MB_UNIT_ID 参数对应于 Modbus RTU 协议的从站地址域。如果 Modbus TCP 服务器用作 Modbus RTU 协议的网关，则可以使用 MB_UNIT_ID 标识串行网络中的从站设备。这种情况下，MB_UNIT_ID 参数会将请求转发给正确的 Modbus RTU 从站地址。

请注意，某些 Modbus TCP 设备可能要求 MB_UNIT_ID 参数在有限的值范围内进行初始化。

根据前面楼主的工作测试过程，推断楼主用的是“八串口Modbus协议转换Modbus TCP网关”，这意味MB_CLIENT读取的已经是网关轮训后的归集数据了。因此，楼主也就无法针对单一从站进行轮训了。

要针对单一modbus从站进行轮训，就需要一拖多的modbus转PN的网关。

所以，上面轮训的非常规状态不是 S7-1500的“无能”，是中间模块特性所致。

首先，我们的目标是485的MODBUS设备，这些设备通过485转TCP的协议转换器转换成TCP的方式与PLC进行通讯，那么协议转换器只是一个媒介。如果你的TCP客户端是一个单口的485转TCP，485下面带10个仪表那么就不需要建立10个背景数据块，只需要轮询时修改MB_Unit_ID即可。8口的TCP有8个IP地址，那么就需要创建8组MB_CLIENT进行通讯，这样至少可以通讯80个485设备。

 REQ必须采用脉冲控制,在MB_CLIENT通讯案例中 REQ是一直置1的，如果一直置1的话程序在一个通讯周期内就会发生多次数据请求，这样就有可能导致采集数据时并不是你所需要的数据，有可能是上一个表的数据。

由于MB_CLIENT接收数据时认为只要符合MODBUS RTU规约的数据都是正确的数据，且接收回来的数据并没有数据的地址码之类的标志，那么我们就必须保证在一个通讯周期内只能下发一次指令，在该通讯周期内接收到的数据必然是一个正确的数据。如果没有数据反馈就等待通讯周期结束跳到下一个设备采集数据。

因此

1. MODBUS从站地址MB_Unit_ID需要进行一个通讯超时自动轮询下一个地址的设定，简单的可以采用一个定时器进行一个自加1的控制，延时建议为500MS。如果有设备通讯（DONE）成功则自加1，定时器重新计时。

2.REQ必须采用脉冲控制，当MB_Unit_ID改变时REQ置1，经过MB_CLIENT功能块后复位。

3.Rcv_Timeout默认2S，需要改成0.5S和通讯超时定时器时间设置一致。

这几个步骤就是要保证一个通讯周期内只能下发一次指令，同时在通讯成功后能够快速通讯下一个地址，经过测试此通讯速度和我们日常用的MODBUS 485通讯速度可以保持一致。

多谢推荐，此贴我个人认为也是很有必要的，因为使用范围很广，属于一个常用的功能之一。