LP-AM243: ModbusTCP Server does not update the data registers (coils, discrete inputs) in real time

Bayu Eko

Part Number: LP-AM243

Hi, I have a problem with the Industrial Modbus TCP Server example.

I am using:

ind_comms_sdk_am243x_2025_00_00_08
mcu_plus_sdk_am243x_11_01_00_19

Previously, I already asked a related question on this thread:
LP-AM243: How to improve Modbus TCP server response time performance? - Processors forum - Processors - TI E2E support forums

I already tried the suggested workaround by adding:

#define TCP_TMR_INTERVAL 10

to the lwipopts.h file in the lwIP library:

C:\ti\mcu_plus_sdk_am243x_11_01_00_19\source\networking\lwip

Then I recompiled the library successfully and included it in the Industrial Communications Modbus TCP Server example.

However, when I tested it, the result was still the same.

I tested several Modbus functions such as:

Read Discrete Inputs (FC 2)
Write Multiple Coils (FC 15)

I used several Modbus TCP client applications on my computer and monitored the traffic using Wireshark. I calculated the time difference between the request and response packets.

The response times are:

FC 2: around 1 ms
FC 15: around 14 ms

However, the strange thing is that the data values are not updated simultaneously. The data only gets updated after around 200 ms.

Could you help explain what may cause this delay and which part of the example project or stack should be checked?

2 months ago

0 Teja Rowthu 2 months ago

TI__Genius 9040 points

Hi Bayu,

I am checking through the code, and will re-assign to the corresponding expert if required. Please expect a response in 1-2 working days.

Thanks and regards,
Teja.

0 Ayuf Basthomi 2 months ago

Prodigy 30 points

Additional data

Wireshark Tapping
-Only read discrete input using Qmodmaster (as modbus TCP slave)

Result : from request until respond take around 1ms

-Only write multiple coil using Qmodmaster (as modbus TCP slave)

Result : from request until respond take around 14ms

Then we tried to create python program to read Discrete input then directly write Multiple coils, but the delay from read Discrete Input until write Multiple Coils it take more than 200ms, below the python code

0 Bayu Eko 1 month ago

Prodigy 101 points

Hi Teja Rowthu Is there any update about this?

0 Christof Vogt 1 month ago in reply to Ayuf Basthomi

TI__Prodigy 710 points

HI,

can you also share more details how you measure the 200ms.

Is this the time from "read response" to "next write"?

can you share a wireshark and point to the frames?

Regards

Christof

0 Ayuf Basthomi 1 month ago in reply to Christof Vogt

Prodigy 30 points

Hi Christof
As you can see in the picture diagram, this test measures response time by giving a signal to the digital input (DI) and checking how long it takes for the digital output (DO) to follow. The PLC program is just input = output, so when DI turns ON, DO also turns ON. An oscilloscope is used to measure the time difference between the input signal and the output signal.

0 Christof Vogt 1 month ago in reply to Ayuf Basthomi

TI__Prodigy 710 points

Thanks for clarification.

Can you share as well a wireshark recording from your test?

Regards

Christof

0 Ayuf Basthomi 1 month ago in reply to Christof Vogt

Prodigy 30 points

ah sorry I missed it before, here it is
RespondTime_Test.txt

for the file .pcapng you can access this drive, because I unable to upload it here
https://drive.google.com/drive/folders/1VVYqLKZ5utNOvSiWGz1T7F_Vg71W_Hcj?usp=sharing

0 Christof Vogt 1 month ago in reply to Ayuf Basthomi

TI__Prodigy 710 points

Hi,

thanks for the recording. Looks that the delays are still in lwip.

We have a solution for that in our next release, but our release cycle brings this not before october.

So another suggestion for workaround:

1. add to lwipopts.h: #define LWIP_TCP_NODELAY 1
this disables nagle algorithm.

2. modify the function tcp_write in tcp_out.c. Add "tcp_output(pcb);" before return of the function. This enforces sending without waiting for more data.

recompile lwip lib.

Regards

Christof

0 Bayu Eko 1 month ago in reply to Christof Vogt

Prodigy 101 points

Hai Christof,

we will try the workaround. This is how i re-compile the LWIP lib.

0 Bayu Eko 1 month ago in reply to Bayu Eko

Prodigy 101 points

Hi Christof Vogt , my colleague Ayuf Basthomi , already re-tested it, but the result is still the same. Are you sure it's the lwIP library? I tried the EtherNet/IP protocol, which also uses lwIP, and the result was good. Could you send us the .lib file that was tested?

0 Christof Vogt 1 month ago in reply to Bayu Eko

TI__Prodigy 710 points

the tcp_output you need to place a bit above before "return ERR_OK;" line 800

0 Bayu Eko 1 month ago in reply to Christof Vogt

Prodigy 101 points

Okay. We will try again.

0 Bayu Eko 1 month ago in reply to Bayu Eko

Prodigy 101 points

hI Christof Vogt can you send us the file that you have compiled?

0 Christof Vogt 1 month ago in reply to Bayu Eko

TI__Prodigy 710 points

Sorry, I can not provide the library.

Code fixes we provide only in our regular releases or for customer with a premium support agreement.

So far I can just provide you possible workarounds.

If you are interested in premium support, you can contact your local TI sales representative

Regards

Christof

0 Bayu Eko 1 month ago in reply to Christof Vogt

Prodigy 101 points

Hi Christof,

Can you check the picture showing how I applied the workaround? I already tried everything you suggested.

I will attach my recompiled library. Could you help me check it?

In my opinion, this problem is not caused by the LWIP library, because I am also using the same library for EtherNet/IP and it is working well.

I think the issue is somewhere in the Modbus library. From what I noticed, the register data synchronization is not working properly. We already know that the response time for reading discrete inputs is around 1 ms, while writing a single coil takes around 14 ms.

When the Modbus TCP client reads the discrete inputs, I pass the digital input values, and when the user writes a single coil, I trigger the digital output pin. However, when I measure the timing between the digital input signal and the digital output signal, the delay is around 200 ms.

What is your analysis of this issue?

lwip-freertos.am243x.r5f.ti-arm-clang.debug.lib lwip-freertos.am243x.r5f.ti-arm-clang.release.lib

0 Bayu Eko 1 month ago in reply to Bayu Eko

Prodigy 101 points

Hi Christof Vogt is there any update on this topic?

0 Bayu Eko 1 month ago in reply to Christof Vogt

Prodigy 101 points

Hi Christof Vogt Could you explain more about the premium support? What kind of support does it provide? Does it also include training materials or guidance for customers and help the customer during the development?

0 Christof Vogt 1 month ago in reply to Bayu Eko

TI__Prodigy 710 points

Hi Bayu,

sorry for the delay.

Key points of premium are

- Immediate bug fixes (not wait for next release)

- Support is handled on higher priority and guarantee for reaction times.

- Includes 40 hours direct support (e.g. online sessions or fixing customer specific problems)

- additional features (not relevant for modbus)

Training material is not included. This would be an add on service on request.

Most likely the issue is already fixed with the upcomming release. You are right that the issue is not in LWIP. Doing changes in LWIP as proposed here is just a workaround which might allow to fix the issue.

Regards

Christof