Hi Fandu,
I have completed the preceding steps plus I have updated the firmware on the TStat10.
and
Using the Modbus Poll tool, I get the following from Wireshark 4.06:
We are also not able to connect with the ICC Modbus tool and get the following from Wireshark:
Did I miss an installation step? Did you miss a step? Did your commit not make it into the build?
I am not sure of the cause, but I do not see what you demonstrated in your last post.
Thanks,
Jason
I also changed the Modbus Poll shown in the following image, and the Tool appears fine using wireshark as shown by my screenshots.
I would like to know what kind of software ICC Modbus tool you use.
Can you give me the download link? Or I can use remote assist to see what’s going on at your site.
Hi Fandu,
The ICC Modbus tool is downloadable from
but I am not sure if that is the problem because I am getting the invalid message format with the Modbus Poll tool as well whereas you are not. There seems to be a difference in software between our two installations.
The Modbus Poll does not appear to get version tracking updates because when I check the version it shows as:
This ICC Modbus Master Tool software works with the VFDs from 2 suppliers as well as an ethernet to Modbus gateway that we use.
Also, since the TStat10 is understanding the invalid message from the Modbus Poll tool, I would have expected the TStat10 software to be updated as well for the new message format. I was not expecting only an update to the T3000 software portion. In the Modbus Poll output, I noticed that your firmware version indicates 63 in register 5 whereas I am now at version 64.
Jason
We also found the cause of the problem using the ICC Modbus Tool. The third-party software sends the read data immediately after establishing the TCP connection without any delay, causing the wifi module to fail to recognize the first packet of requested data. All other Modbus tools are at least 20ms delayed. We will modify the firmware to be compatible with this ICC modbus tool. You will be notified as soon as the new firmware is tested. Thank you！
Hi Fandu,
Do you have an estimate when you think the changes might be ready?
Jason
We have made some improvements in new firmware rev14.1, but the results are not very good, take a look at the comparison of the two software results.
modbus Poll.exe scan rate == 1000, and the scan rate can be modified,the commuincation is very good
ICC modbus, littl delay. It is not good. There is little delay between each packet, and the next packet is sent after a response is received.Under normal circumstances, there should be no problem with such scan rate, but our Airlab uses a UART-TO-ETHERNT module, serial port forwarding will slow down the speed, and if the scan rate is too fast, the communication will deteriorate.
Hi Chelsea,
I did try the firmware update. It is certainly having problems. I am only able to connect on 1 of 5 to 1 of 10 attempts. Does the code use interrupts to receive each byte? We have some products using the ESP32 and interrupts are the only reasonable way to handle the bytes being received rapidly. I am not sure if that is possible with the ESP module that your team is using.
Jason
Hi Chelsea,
Is this issue being actively worked to root cause at this time? I would be willing to test if it helps since we need the MODBus capability before we can install the thermostat to customer sites.
Thanks,
Jason
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
Chelsea will help out asap
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
They are the normal ACK package in ModbusTCP protocol
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
