In trying to use Modbus TCP with the TStat10, we have encountered communication errors preventing us from interacting with the thermostat either with our software our with different 3rd party tools that work with Modbus/TCP. We decided to use the Wireshark protocol analyzer and it showed the following problem:
In the preceding image, you can see that none of the incoming messages (from Modbus Poll software
at 192.168.1.244 to TStat10 at 192.168.1.228) is interpreted as Modbus/TCP. However, the response sent back is in the appropriate format and is tagged by Wireshark as being Modbus/TCP format.
In contrast, the ICC Modbus Master test tool which we use with numerous Modbus devices (from ICC Modbus Master at 192.168.1.244 to TStat10 at 192.168.1.228) does show a valid Modbus/TCP request. Unfortunately, the TStat10 does not understand the request message and fails to send a valid Modbus response:
The IP address of Tstat10 is 192.168.1.218. wireshark does not send any data packets to 192.168.1.218. Did you write it wrong? Is the IP address of Tstat10 192.168.2.228.Right?
Can you send me a specific wireshrak data screenshot? You need to confirm that the modbus ID you sent to Tstat10 is correct, otherwise the Modbus device will not answer.
Thanks for the highlighting the IP address error. The .218 was a typo that I cut and paste. The correct IP address is .228 and I have modified the original description. The Wireshark tool monitors network traffic and breaks it down into the original bytes. It doesn’t send or receive the messages. It only monitors the packets on the network.
The Modbus id is 7 and can be seen in the TStat10 response as “Unit: 7” in the first capture image and the ICCModbus Master tool outgoing message in the second is sending to “Unit: 7” as can be seen in the second capture image.
The key detail here is that the Wireshark trace is not seeing the outgoing message from the Modbus Poll tool as a Modbus message which means it is not constructed correctly. Yet the TStat10 understands the message and sends a valid response.
The protocol displayed as TCP on the wireshark is abnormal. We will analyze and fix the protocol display problem. This will not affect your communication.
So do you still have a problem that you cannot read Tstat10 data over Wifi when using ICC Modbus Tool?
In your first picture, I can see that Tstat10 has a response length of 263, which indicates that Tstat10 can reply normally.
Thanks！
We cannot read the TStat10 data with either the ICC Modbus tool or our own software. In both cases, we get no response. These same software applications work fine with other Modbus devices.
The TStat10 does seem to respond with valid Modbus TCP messages, but seems to be responding to an invalid incoming message because Wireshark does not recognize it.
Fandu will fix the issue about Wireshark displaying packets as TCP. Can you clarify what you mean there with the second sentence, copied below.
The TStat10 does seem to respond with valid Modbus TCP messages, but seems to be responding to an invalid incoming message because Wireshark does not recognize it.
Maurice, for the sentence that you copied, my point is that both the TStat10 and the Modbus Poll tool seem to be working with an invalid message for TStat10 inbound messages. The Modbus Poll tool is sending an invalid message that it thinks is Modbus TCP format. The TStat10 is accepting this invalid message that it thinks is Modbus format. Wireshark does not recognizing this message as Modbus TCP.
I am wondering if there is an understanding of the problem at this point and an ETA can be provided for solution or at least an ETA for when investigation will be complete.
Please Update your T3000 software to fix these bugs .
Help->Check for updates ->Update T3000 .
If you still have problems you can let us know.
We fixed an issue where the protocol was displayed as “TCP”, now it is displayed as “Modbus/TCP”
Thanks!
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.
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.
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！
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.
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.
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.
