MODBUS通讯是大家经常接触到的一种通讯方式，但MODBUS的通讯性能究竟如何，其通讯时间到底如何计算？这个问题大家在做项目过程中可能会受到一些困扰。这里通过一次现场服务，来介绍一下如何对MODBUS的通讯周期进行计算，希望对大家有所帮助。

        国内某用户赢得了一个大型的输油管道项目，并该项目中采用了西门子的冗余控制系统（S7-400H系统）。由于实际项目中有大量的管道阀门需要控制，而该阀门只能通过串口采用MODBUS协议进行通信的，因此该用户在西门子系统中还选用了CP341做为MODBUS通信主站来对现场的阀门进行数采和控制。

        由于现场需要控制的阀门比较多，平均每个CP341需要连接多达26个阀，因而在项目实施过程中，根据用户的实际测试，每个CP341采集单个从站数据的时间在400ms左右，这样每个CP341采集所有从站数据大概就需要10.4秒，这个时间用户觉得太长，他们希望将每个阀门的通讯时间降到100ms，但这个指标能否达到呢？这就需要对MODBUS通讯的时间进行计算，但到底如何计算呢？由于项目实施已经迫在眉睫，于是用户求助于西门子，希望我们到现场进行实际的交流和测试，尽快帮助他们解决这个问题。

        其实，一开始听到这个需求的时候，我也不知道这个指标能否达到，只是根据经验，感觉应该是达不到这么快，另外，尽管跟客户有所交流，但现场到底是什么情况、阀门的通讯状态也都不是很了解，因此也是觉得有点手足无措。但这个客户是西门子的大客户，而且这个项目也是西门子在该领域内的一个非常重要的项目，因此也只得硬着头皮奔赴现场。
       但去之前，我根据用户的实测的情况进行了一个分析：由于系统采用的是H系统通过DP总线连接ET200M从站，CP341都安装在ET200M的从站上，因此该数据采集的周期总的来讲包括以下三个部分，及程序扫描周期+DP通讯周期+MODBUS通讯周期。因此我初步决定，通过调整程序、修改通讯波特率等方式，看是否可以将MODBUS的最终通讯时间间减少。

        到了现场，看到了用户的测试系统（图1）。

测试系统是H系统中通过ET200M从站连接CP341，由于测试现场由于没有实际的阀门，因此用户工程师是采用MODBUS从站软件进行数据采集测试的。

        通过现场与工程师的交流，发现目前主要的问题是解决数据采集的时间过长的问题，因此我们主要对通讯时间进行了测试。

        用户工程师向我演示了他们的测试过程。从他们使用的MODBUS从站软件上可以看到，从CP341向其MODBUS从站软件发出一个“Read”请求，到CP341得到反馈数据，时间刚好是400ms。而其软件对于CP341的Read指令的响应时间是1~2ms，因此，该软件本身是没有问题的。

        用户希望能够将400ms减少到100ms。

        根据之前的分析，现在需要了解每个阶段所用的时间，但程序周期和DP通讯的时间我心里都有数，唯独对MODBUS的数据交换时间不确定，而且如果这部分的时间过长，则总时间将很难降低。因此我们需要首先对MODBUS的通讯时间进行一个测试。可这个时间怎么测？不是已经知道了吗？是400ms，但这400ms都有哪些部分组成？是否可能降低？

        经过仔细的分析，我们认为，首先应该搞清楚，MODBUS总线的物理层传输时间。

        在CP341的参数设定中，我注意到有一个“Reply Monitor Time：The reply monitoring time is the time spent by the master waiting for a reply message from the slave after output of a request message.”的参数，该参数是用来检测MODBUS报文传输时间范围的看门狗时间，因此，通过该参数，就可以了解MODBUS的报文传输用了多少时间。

        经过测试，我们发现，当该值设定小于50ms时，通讯会报错，因此，在该项目中，MODBUS信号的最小传输时间可以认为是50ms（图2）。

  因此，根据之前的分析，可以认为，当前的MODBUS的数据交换时间为：程序扫描周期+DP通讯周期+MODBUS通讯周期（50ms）=400ms。

        因而程序扫描周期+DP通讯周期应该为350ms。由于DP通讯的周期基本上是固定的，而且修改DP周期影响并不大（最多只有十几毫秒），因此接下来我们主要测试了用户程序对该通讯时间的影响。

        首先我们对程序进行了修改。原程序是在OB35中调用MODBUS的“Send”和“Receive”的，而OB35的调用周期被设置为50ms，为了加快程序的运行，我们将这部分程序移到了OB1中进行执行。另外，为了测试需要，我们暂时将其他与通讯无关的程序都删掉。

        在程序中，我们增加了对通讯时间的测试程序。通过程序检测，可以得到MODBUS通讯一次（即MODBUS完成一次收发）的周期为200ms（图3），其中M89.0为接收块“Done”位的状态。同时，通过在PC机上的MODBUS从站软件测得的一次报文收发的时间也是200ms。

  而此时，经检测，每个OB1的循环周期为3ms左右。因而多出来的时间，应该是MODBUS主站（CP341）在处理通讯的过程中需要的时间。

        在CP341 MODBUS主站的手册中，有这样的参数：当调用功能码FC01时（读输出线圈）的处理周期为（ms）。

   从参数表中可以看到，读取10个字节时，CP341的处理时间为33ms，执行Job时间为8ms，即此时CP341将占用41ms用来处理通讯；而从站处理也将占用一定的时间（例如PC机的MODBUS软件响应时间），再加上DP传输的时间，该时间应该刚好就是100ms，而200ms又刚好是一个完整收发周期的时间。

        为了验证我们的想法，我们又对发送功能的时间进行了测试（图5）：

   此时，M89.0为发送块的“Done”位的状态。可以看到，一次发送完成所花费的时间为100ms。因此，可以得到CP341在作为MODBUS主站时，如果波特率为9.6K，当读取10个字节的输出线圈状态数据时，一次收发的时间应该是200ms左右（一部分时间取决于从站的处理时间）。

        而如果未来采用实际的阀，则未来真正的系统通讯的时间又是多少呢？

        关于从站的处理时间，同样在阀的说明书上可以查到相关的参数（图6）：

   在9.6K的波特率下，该阀的处理时间为24ms，因此，如果将来CP341连接了实际的阀，则MODBUS通讯的最快时间为：

        Tmodbus = 2x程序处理时间（33ms+8ms+3ms）+从站响应时间（24ms）+ 2xMODBUS传输时间（50ms）+ 2xDP传输时间（15ms）=88ms+24ms+100ms+30ms=242ms。

         经过分析和实测，我和用户对MODBUS的通讯机理都有了一个较为深刻的理解，并且能对未来的实际通讯的效果有一个大致的了解，因此在这里将我们得出的结果也分享给大家，供大家讨论，也期望对大家有所帮助。

         另外，在测试过程中，我们也发现了另外一个问题，即在程序中我们并没有设定任何的中断，但每发送8个周期，MODBUS就会出现一次发送停止，时间间隔为500ms，出现的频率和持续的时间基本固定。特别是通讯站点数越多时，现象越明显。

        经过测试，我们发现将接口参数修改为None后，该现象消失（图7）。

   关于如何与阀进行MODBUS通讯的冗余，我们建议用户将参数设定中关于RS485的操作模式选择为“Normal Operation”（图8）。

   因为在该模式下，模板会对断线以及错误报文进行检测，一旦发现错误或通讯中断，将会在系统块中报错，便于进行通讯的诊断。用户可以根据相应的错误来对通讯的状态进行判断，从而对通讯数据进行选择。