Modbus TCP Driver polling too limited

Hello.

Set the desired polling time in the Update Time parameter. Read more here.

Hi,

Problem is that this value isn't changing its behavior the minimum time between each poll is 40ms, or more, that is depending on the Update Time setting, but never less. What happens is, that 64 registers starting from register 1000 is read, then 40 ms later 64 registers from 1064 and so on and so on. In short when you have a large amount of registers the Update Time setting isn't doing what it is meant to do. 

There should be an interval between frames. In Modbus RTU, it can be set manually in the "Silent Period" parameter, but only in the range 0 ... 20.

In Modbus TCP there is no such setting:

Use the Modbus RTU Network driver:

Wait for data - the time to wait for a response from the bus before showing the Offline driver.

Update time - the frequency of polling devices in the bus.

Send wait time - Maximum time to wait for a response from a packet (def 12000).

Thanks I will give it a try

I am sorry, but that didn't help. First of all the Modbus RTU network does not use protocol TCP, but TCP Gate. I've tried it but it won't start communication with the PLC. Instead of that I tried it with Modbus TCP Network, what corresponds to your screenshot. But even that didn't help. For more information I included a test project and a Wireshark capture, hopefully this explains the behavior a bit more.IM_ModbusTCP_Test.pcapng 
test.sirpz

Hello.

In Modbus RTU, you have the wrong host specified.

In the dump, the polling interval in betrayed 50 ms. This corresponds to the Update Time parameter in the driver.

Hello,

I can see only +/- 25 messages per second, so that is 40 ms.

But what does Update Time means? I would expect that every 50 ms ALL registers are polled. Now only 64 registers are polled every 40 ms. When I put Update Time to i.e. 10 ms, the polling rate stays at 40 ms. 

Hello.

Multiple registers can only be requested if 2 conditions are met:

1) The addresses in the tags are consecutive, without omissions (1000, 1001, 1002 etc.).

2) The Multiple parameter is enabled.

If there is an interval of 100 addresses between the addresses, then Multiple will not work, Single is enabled (i.e. all registers are polled one by one).

Hello,

Yes, I understand, this is just a test project. In the project where I found this issue, I use 1773 registers, almost all consecutive. Modbus_import_EIB678.csv This is the import file I used to create the driver. 

What I try to point out is that the iRidium Mobile driver reads a maximum of 64 registers per poll. There is no posibility to lower the poll time than 40 ms. So when looking to this list, the total time to read out all these registers would be >1 sec., while the Update Time setting is 250 ms, or 50 ms, it doesn't matter. What I would expect from Update Time, is that when you put in 250ms, that all 1773 registers are read every 250 ms. And when I put in 50 ms, all 1773 registers are read every 50ms. 

I've included a new Wireshark file, this is from the real project. Update Time 250ms: IM_ModbusTCP_EIB678.pcapng

As you can see in the Wireshark file the complete list of registers is read once about +/- 1 sec.

In this Wireshark file you can also see that the Function Code 3 of the Modbus Protocol is used (Read Multiple Registers).

Which Modbus client did you compare our Modbus driver to? What example should we start from?

Hi Vladimar,

I think best is to look at software like CitectSCADA. That is what we use on our boats to design our Alarm&Monitoring system. CitectSCADA can read large amounts of registers every cycle, but it also works with a caching system. But besides this, it is clear that there is a fixed Request Interval of 40 ms inside the driver which performs one request of 64 register per Request Interval. My humble request would be to increase the request speed in such way that it correlates to the Update Time.

Request Interval = Update Time / Register Blocks

Hello.

Thank you for the information you provided. We will investigate the Modbus TCP driver in comparison with CitectSCADA and let you know if it is possible to implement similar functionality in i3 pro.

Hi Vladimir,

I saw the item "Drivers. Modbus fixes" in the change log. I immediately started testing. But this had not the outcome I prefered. I presume the Modbus fixes do not reflect the issues I reported?

Hello.

We have investigated the problem, but cannot offer a solution in the current product architecture. The fixes include optimization of the polling queue, but this will not affect the speed in your case. Unfortunately, we can't offer a solution yet.