Task #2953
openTask #2941: Detailed Design
Task #2952: Embedded SW-Development
Task #3032: GW2.0 Codebase readiness(Release 1.0)
Modbus-TCP
Added by Thomas Joseph 2 months ago. Updated about 1 month ago.
Files
| Send_success.jfif (59 KB) Send_success.jfif | Channamallikarjuna Mattihalli, 12/01/2026 03:51 AM | ||
| modbus_tcp_log (5.07 KB) modbus_tcp_log | Channamallikarjuna Mattihalli, 12/01/2026 03:54 AM |
TJ Updated by Thomas Joseph 2 months ago Actions #1
- Parent task changed from #2952 to #3032
CM Updated by Channamallikarjuna Mattihalli about 2 months ago Actions #2
- File Send_success.jfif Send_success.jfif added
- File modbus_tcp_log modbus_tcp_log added
- Status changed from New to In Progress
- % Done changed from 0 to 70
Modbus TCP development is ~80–85% complete.
Ethernet, IP, ARP, and TCP layers are fully working (connect + send success confirms this).
State machine and polling design are correct (init outside loop, poll inside loop).
The remaining 15–20% gap is protocol correctness at Modbus level:
Unit ID / MBAP length / register address validation
RX timeout + error handling
Proper response parsing and retry logic.
The code and logs were shared with Venu sir on Saturday, and we are currently awaiting his feedback.
CM Updated by Channamallikarjuna Mattihalli about 2 months ago Actions #3
- Status changed from In Progress to Resolved
- % Done changed from 70 to 100
Working
VS Updated by VenuMadhav S about 2 months ago Actions #4
- Status changed from Resolved to In Progress
- % Done changed from 100 to 80
TJ Updated by Thomas Joseph about 2 months ago Actions #5
- Due date changed from 09/01/2026 to 16/01/2026
Due date extended to reflect integration, review and testing
SV Updated by Sunder Venugopal about 2 months ago Actions #6
- Related to Task #2954: TCP Over 4G added
SV Updated by Sunder Venugopal about 2 months ago Actions #7
- Precedes Task #3027: RTC BACKUP added
SV Updated by Sunder Venugopal about 2 months ago Actions #8
- Related to deleted (Task #2954: TCP Over 4G)
SV Updated by Sunder Venugopal about 2 months ago Actions #9
- Precedes Task #2954: TCP Over 4G added
TJ Updated by Thomas Joseph about 2 months ago Actions #10
- Due date changed from 01/01/2026 to 20/01/2026
Due date extended to 20/01/2026
SV Updated by Sunder Venugopal about 2 months ago Actions #11
- Precedes deleted (Task #3027: RTC BACKUP)
SV Updated by Sunder Venugopal about 2 months ago Actions #12
- Precedes deleted (Task #2954: TCP Over 4G)
TJ Updated by Thomas Joseph about 2 months ago Actions #13
TJ Updated by Thomas Joseph about 1 month ago Actions #14
- Due date changed from 20/01/2026 to 26/01/2026
Issue reported on 26th thru Teams
we are having a SERIOUS timing issue with Config packet reception/handling
it is taking between 3-5mins to receive a full packet size of 2k (127 signals)
we havenot been able to run a end to end to test to check the E-remos and data.
with limited signals, we are able to run end to end. (we NEED to deliver with all the signals enabled as per client)
Options
1. Hardcode all the signals in the device (Fixed configuration) - Malli to test
fix modbus tcp issues if any.
2. USB tool to provide all the modbus registers to read
Greeshma, do we have GUI to add/edit registers to read ? possible ?
3. Need Wireshark logs in the Local Server. Neha talk to Bhanu and get a us a log.
Need TCP server logs too, to assess the delay
4. Prakash, pls get a timestamp in linux and provide a log.
TJ Updated by Thomas Joseph about 1 month ago Actions #15
- Priority changed from Normal to Urgent
USB integrated, 2 more issues pending , hard coded config pkt is not getting fully, looks like memory alignment due to compiler, it resets and socket receive from tcp modbus is NOT happening, wireshark shows data response..
Greeshma/Devipriyaa, pls check the extract_tcp_config() function, after 20 entries update, no error but data update doesn't happen.
TJ Updated by Thomas Joseph about 1 month ago Actions #16
1. memory alignment issue fixed, linker issue.
2. currently signals are hardcoded
have asked Malli to check with Neha/prakash and ensure all signals are included
data read from the modbus are updated in device and posted to cloud.
Greeshma to support malli
3. Modbus read, socket read issue fixed.
Malii to debug the reset issue after 10-12 modbus read
4. Malli to perform basic posting, sending '0' (zeroes) to cloud.
5. Malli to perform modbus read and verify the data with simulator
6. Malli to update code and Greeshma to help in end to end testing
7. fix issues if any.
TJ Updated by Thomas Joseph about 1 month ago · Edited Actions #17
Modbus Latency Issue :
What protocol says =>
Transaction/invocation Identifier (2 Bytes): This identification field is used for transaction pairing when multiple messages are sent along the same TCP connection by a client without waiting for a prior response.
With traditional serial Modbus, a client can only send one request at a time and must wait for an answer before sending a second request. However, *Modbus TCP/IP devices may send several requests to the same server without waiting for the prior response* . In this instance, the transaction identifier is use to match a future response with its originating request and must be unique per transaction. It is commonly a TCP sequence number driven by a counter that is incremented by each request. The maximum number of client transactions will vary from device to device, but is generally a number from 1 to 16. Likewise the maximum number of server transactions also varies.
Source : https://www.prosoft-technology.com/kb/assets/intro_modbustcp.pdf
(copy here=> https://elpisit-my.sharepoint.com/:b:/g/personal/satish_sl_elpisitsolutions_com/IQDVAU42jhiNQ7fIGo5ZIHILAdXpGkt4lpJrp8SS6tMbRKQ?e=dXtCIe)