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?
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
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).
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.
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
Thanks I will give it a try
In Modbus TCP there is no such setting:
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.
Sorry it took a while. But is it possible that this functionality got lost because of the latest updates? I watched a tutorial on Youtube, describing how to merge projects. But every time, when I open an additional project, it will be show in the top tab row, but not additionally in the project tree. So I will never get the option to merge the projects.
OK I will give it a try. I didn't know that cloning a templete would work in this way.
Customer support service by UserEcho