Modbus server times out
Our project uses Modbus TCP both as client and server (to two different devices). Client seems to work well.
However, when I add the Modbus_TCP_Server3 block to my existing project, I have to set the timeout to 2000 ms in order for it to work with few interruptions, but if the Modbus master writes something, most of the times there is a Time Out.
As an experiment to test if the CPU was overloaded, I removed all the other logic from my project and the result was the same: Time Outs.
As yet another experiment, I created an empty project, with just the Modbus Server block and this time it did not Time Out!
So there must be something on my original project that caused a delay on the Modbus_TCP_Server3 block, and even after deleting everything (I think) it remained.
How do I go about solving this issue?
Thanks
Comments
Hi Alex,
Do you see the same behaviour when using the latest versions of PLCnext Engineer, PLC firmware, and Modbus library?
If the behaviour does not occur with the latest version, which versions does this behaviour happen with?
~ Martin.
Hi Martin,
Yes, I forgot to add this info.
PLCNextEngineer: 2020.3
PLC FW: 2020.3
Modbus TCP Library: Version 6.
Also, probably I posted this question on the wrong forum, feel free to move it.
Thanks.
Hi Alex,
(The PLCnext Engineer topic is the correct one in this case, since the problem appears in the PLCnext Engineer Function Block "Modbus_TCP_Server").
Does the same behaviour occurs with the latest version of firmware (2020.6.1) and Modbus TCP library (version 7)?
Regards,
Martin.
Hi Martin,
We ugraded PLCNextEngineer and PLC FW to 2020.6, and the Modbus library to 7, but the result is the same, when trying to write a coil or a register, there is a Time-Out error.
What else can we do?
Thanks.
BTW: when we hover the pointer on the library it says Version: 1.4.16.0
Hi Alex,
A test has been performed here with PLCnext Engineer 2020.6.2 and AXC 2152 FW 2020.6.1
The project has one MB Client instance and one MB Server instance.
Scanrate/Pollingtime ca 100ms of an external Modbus Client (Modbus Poll FC4 ) to the AXC 2152 MB Server FB
Pollingtime of the MB Client (FC3) ca 250ms to an external MB Server (modRsim)
See wireshark image in attachment
Client:
Server: does not use Timeout for the MB Server (see help description for the timeout behaviour)
Hi Martin,
The timeout issue for the write command to the PLC seems to be solved after tTimeout is set to 0.
However, the slow response for the Modbus command stays the same. Between the poll and the response from the PLC, there is a minimum 2000ms delay. If the response time is set to 1800ms or less, there will be the timeout error or the transaction ID error.
I am attaching the project for you to test. The project includes only one "MB_TCP" page and the page has only a "MB_TCP_Server_4" block.
When you try to do the test, go to online mode, set "strPLC_IP" to the IP address of the PLC and set "xActivateServer" to TRUE in the "MB_TCP" page.
I used the "Modbus_Poll" as the master to do the test.
Remember the attached project is trimmed down from my real project.
If a new project is created and "MB_TCP_Server_4" is added (I tested for the previous version, the "MB_TCP_Server_3), there won't be a slow response. The Modbus behaves the same as you had written above.
Martin,
System doesn't allow me to attach the zip or project file. Do you think if there is another way that I can send you the project file for troubleshooting? It is a very simple project including one block only.
Thanks
Jason Qiping Li
Hi Jason,
Thanks for sending your PLCnext Engineer project.
In that project, the MB Server is being executed in a task that is run every 1 second (1000ms). This means the server can only process requests and/or send replies once every second.
If the task Interval value is changed to 10ms, the response time changes to 20ms.
~ Martin.
Hi Martin,
Thank you for the help. Modbus server in our project is working good now.
I have around 200 registers for the Modbus server currently, plus a lot of data format conversions. The watchdog timer has to be set to 12ms since occasionally PLC will stop if the timer is lower than 12ms.
What will be the watchdog timer suppose a project has over 2000 registers? Will the timer grows up to 120ms? If the minimum watchdog timer is 120ms, I think the reasonable interval time should set to 200ms. That would mean the response timeout has to be set to 400ms and I think it will be a bit slow for some applications.
Does it mean a separate hardware Modbus module is required if a project has thousands of registers?
Jason Qiping Li
Hi Martin,
I see there is a new Modbus TCP library version 8 now. What changes does it have? Something that might benefit us over using 7?
Thanks
Hi guys,
Sorry for the delay.
For a Modbus server, the number of registers will not influence the cycle time; rather, the frequency of queries that are hitting the server will influence the cycle time. Each client request will take a similar amount of time to execute regardless of whether the request is for one register value or 2000 register values. If the client is requesting each of the 2000 register values individually in 2000 different requests, then that will take much longer for the server to process than a single request for 2000 register values.
Tasks on each ESM (core) are executed linearly, based on the Priority that you set - higher priority tasks will always interrupt lower priority tasks, and tasks with the same priority will not interrupt each other.
The difference between versions 7 and 8 are listed in the Change Notes, in the documentation that accompanies the library.
Martin.
I am confused with the time response from the wireshark.jpg attached by you above.
Currently I have a POU page including two FC3, two FC1, one FC16 and one FC15 to read a third party Modbus server. They have to be arranged with different iMT_ID input values. When I included this page to a 1000ms task, I count it takes nearly 20s to execute the first FC3 reading.
I found that the FC blocks are executed one after another, and one FC block takes almost 3s (Does it take 3 cycles to do a poll reading? like 3*1000ms?). The total time will be like 6 (FC blocks) * 3s = 18s, in my case it is almost 20s.
Please teach me if my understanding above is correct or not.
Thanks
Jason Qiping Li
I forgot to mention that the tUpdateTime for all the FC blocks is set to 0s.
Jason
Actually I found it takes 4 cycles time to execute one FC block. The FC16 or FC15 is not always executing in my POU. Most of time there are 5 FC blocks are executing so the time will be 4 * Cycle time * 5 FC = 4 * 1000ms * 5 = 20s.
Please correct me if my understand is not right.
If My understand is correct, it will be hard to get a quick Modbus Poll response for third party Modbus Server. I have to put the POU into a 10ms task to get a 200ms poll rate but I doubt if I will get a watch dog timeout for a 10ms task.
We need a faster poll response so that we can average the process value in a few seconds.
Thanks
Jason
If the Modbus server accepts multiple client connections (e.g. on different port numbers), then you should be able to send multiple requests in parallel.
It might also be possible to change the arrangement of data in the server, so that all data can be read with one request.
You can set the task cycle time to the smallest value you are comfortable with, using the task execution duration (in the ESM data) as a guide to how long the Modbus TCP FBs take to execute. Depending on what PLC you are using, 10ms does not sound like an unreasonably short task cycle time. The Modbus FBs don't do a lot of processing themselves, and if your own application does any time-consuming processing then that could be done in a task with a longer cycle time.
~ Martin.