search

alejoseb / Modbus-STM32-HAL-FreeRTOS

Modbus TCP and RTU, Master and Slave for STM32 using Cube HAL and FreeRTOS
GNU Lesser General Public License v2.1
519 stars 182 forks source link

Communication frequency on TCP Slave connection. #95

Closed hfelek closed 7 months ago

hfelek commented 8 months ago

Hello

I use my device as TCP slave and a master from a Linux server continuously makes read-write requests to the slave. I use this library on my slave side. I have set up timer in Linux server and that timer measures how long does it take to complete number of scan cycles. I have come to realize NUMBERTCPCONN macro definition in ModbusConfig.h file drastically affects cycle duration.

define NUMBERTCPCONN 1 ---> 10000 cycles takes 3.3 seconds

--

define NUMBERTCPCONN 2 ---> 10000 cycles takes 50 seconds.

--

define NUMBERTCPCONN 4 ---> 10000 cycles takes 150 seconds.

--

In the project its default value is 4. I know it can be LwIP related issue but I think you may have an idea on what is going on. I want to be able handle multiple client requests so defining NUMBERTCPCONN as 1 will not help by itself. Are you aware of the issue and could you help me to have an idea on what is going on?

Another issue I have come to realize when I was testing different configurations, disgraceful disconnections on TCP connection results in faster scan cycles till number of disgraceful disconnections reaches NUMBERTCPCONN . After that point when new connection is tried to be set, Slave rejects connection. I hope this may help as well. Despite the cycle duration, behavior seems to be the expected one. Connections are closed after aging-cycle counts are reached out.

Thanks in advance

hfelek commented 8 months ago

I wanted to add something. In line : https://github.com/alejoseb/Modbus-STM32-HAL-FreeRTOS/blob/a6d78fdefd05ba7cf6d52ec36a8ee5b66b47db18/MODBUS-LIB/Src/Modbus.c#L499

Wouldn't be the correct argument as mentioned below:

if (modH->newconnIndex>=NUMBERTCPCONN) { modH->newconnIndex = 0; }

alejoseb commented 8 months ago

Hi, Regarding your first message. You can try reducing the ModbusH.u16timeOut parameter. Because the timeout for checking for incoming packages increases linearly for every active TCP connection. The current example is 100 ticks so a value of 25 could be starting point. It is expected that after disgraceful disconnection the cycles will be faster because the linear timeout is reduced. Also, new connections must be rejected that is expected till the disconnection is detected or the connection is inactive.

Regarding your second message that is a good catch, and probably the reason for some issues when working with multiple TCP connections. If you can validate the library works after that change please consider to submit a PR to solve the bug.

hfelek commented 7 months ago

Hi again,

Fixing the mentioned bug changes behavior on timings for Modbus read-write operations with TCP connection. In addition timing is dependent on not current connected number of devices but NUMBERTCPCONN( max number of connections allowed).

I couldn't focus on source files in depth but I assume, even there is no connection, device scans whether there are available connections and related modbus operations on each possible slot. This behavior could be coming from LWIP implementation as well. If you have in-depth knowledge, could you validate the behavior.