Modbus Request Protocol Format Error in TStat10/Modbus Poll

The latest firmware for TSTAT10 is REV64.1. I’m sorry that I got the two products wrong, and I just uploaded the latest firmware

I am getting “Can’t find the firmware on the website” after trying multiple times. The T3000 software indicates that it is up to date. Was the firmware upload successful? And, did you have luck in getting the ICCModbus tool to connect consistently?

I tried again and was able to get the software so it may have been uploading when I tried

The ICCMODBus Master tool now connects reliably but cannot get much for data without timeout. Is this issue being actively worked to root cause at this time?

However, it does seem to get one byte so I can work around for now. What is the required time delay between bytes to avoid hitting the issue in the mean time?

Isn’t your product TSTAT10? I just tried it again myself and it was successfully downloaded from FTP

As stated, I was able to download eventually.

The ICCMODBus Master tool now connects reliably but cannot get much for data without timeout. Is this issue being actively worked to root cause at this time?

However, it does seem to get one byte so I can work around for now. What is the required time delay between bytes to avoid hitting the issue in the mean time?

I replied about the reason for ICC software timeout before. The interval is too small. If it can be adjusted, please set it to 1s

Hi Chelsea,

One second seems very long.

What you did not answer was this question: “The ICCMODBus Master tool now connects reliably but cannot get much for data without timeout. Is this issue being actively worked to root cause at this time?” Are you working to speed up the MODBus response time?

Thanks,

Jason

Hi Maurice, Chelsea,

One of the things that we noticed in the last couple weeks is that it appears as if the responses from the TStat10 are not all in Modbus/TCP format and that there might be some sort of remnant TCP message being sent by the TSTAT10. The message is sent consistently from the TSTAT10 in response to a query and is directed back toward the 502 port so I would expect it should be Modbus/TCP or should not exist at all.

The same also appears to occur from the T3000 software to the TStat10

I have the actual capture if that helps.

Thanks,

Jason

1 Like

Chelsea will help out asap

1 Like

Due to the wifi module used in our previous TSTAT10, the interval between packets should not be too short. Therefore, if the software you use can adjust the polling speed, please adjust it slower

1 Like

They are the normal ACK package in ModbusTCP protocol

1 Like

Hi Chelsea,

If that is what they are, then the problem is that the they may not be compliant to the MODBus protocol. They are showing as TCP rather than MODBus according to WireShark. It also might explain some communication issues that we hit because with different MODBus clients we get a reproduceable timeout even though the connection is good.

I think the message format needs to be analyzed to determine how the messages differ from what is expected by MODBus TCP. If this is a normal type of follow on message, then I am not familiar with it

Thanks,

Jason

1 Like

This is a normal packet, Other non-wifi products are also similar TO packets. I have explained that the communication of WIFI products will be slower than that of normal network products because the RS485 to WIFI module is used. Our new TSTAT10 will no longer use modules.

1 Like

Hi Chelsea,

We have already implemented long delays between messages many months ago, but continue to face connection issues with strong connections. That is not the same as what we see here.

Can you reword the phrase “This is a normal packet, Other non-wifi products are also similar TO packets.” because I do not know what you are attempting to tell me. What do you mean by normal and TO packets? My point is that I would expect the ACK packet to be a MODBus packet.

The TStat10 is the only MODBus TCP product we use that makes the client application and routers unhappy so I am wondering if there are protocol issues.

Thanks,

Jason

1 Like

Hi Chelsea,

Can you please reply.

Thanks,

Jason

1 Like

As I explained before, our TSTAT10 uses RS485 TO WIFI module, so the polling speed cannot be too fast. The software you used is ICC Modbus Master, which I actually tested and sent very fast, but TSTAT10 could not reply in time. As for ACK packets, these are sent by the software itself. I compared the sending logs of different software, Modbuspoll is sent once every 1s, and the basic communication is good.
IP165 is TSTAT10



IP191 is our another ethernet device

As you can see from these logs, if the ICC polling software can’t be slowed down, our TSTAT10 really can’t meet your needs. We will replace the module with real wifi in the new TSTAT10.

1 Like

Hi Chelsea,

We stopped using the ICCModbus software long ago as it was only a test tool. We now poll with some of our own software and we use 500ms delays. The problem that we hit is that single writes fail at a high rate even with the 500ms delay and one second between writes is too long of a delay The T3000 software polling also results in issues making it now unusable.

All that said, we will move to the ESP32-based TSTAT10. My concern is that if the issue is at all software related with invalid protocol implementations, then it will likely persist even with a different chip set.

Can you address why the ACK packets sent by both the T3000 software and TStat10 when communicating are not Modbus TCP format according to the protocol decoding of Wireshark? Your comment about “As for ACK packets, these are sent by the software itself” does not provide an explanation about these packets.

Thanks,

Jason

1 Like

wireshark classifies it as TCP, we dont have a lot of control over how wireshark classifies it. We support modbus/tcp and BacnetIP, this has been debugged in hundreds of environments and can be trusted, That said we’re always on the lookout for exceptiions.

As shown in the screenshot we use modbuspoll.exe, seems it communicates well at scan rate 500ms. Use the block read command to reduce the number of packets, this will get you more registers per second overall.

1 Like