A R1 controller and 10 temperature and humidity modules communicate through Ethernet. The control strategy in R1 uses an Ethernet communication handle to connect different temperature and humidity meters by changing the parameters of the communication handle. The R1 controller is the client of TCP communication. To test the effectiveness of TCP communication, I set the polling interval to 100ms, so there is no need for such fast polling during normal use. R1 has been running normally for several days, and the data obtained is normal. But there is a strange phenomenon that when I use the Debug mode in PAC Control Pro 9.6 on a PC to track, the communication between the PC and the controller is interrupted, making it impossible to track. The R1 controller must be restarted to restore normal operation. I have tried this situation multiple times, but it has always been a problem.
A couple of things:
If this is a test you are doing, why aren’t you testing using the latest firmware and PAC Control software to do the test. Latest firmware for the PAC-R1 is Version R10.4E.
PAC Control is now at Version R10.5C.
There have been several improvements and fixes especially to the communication handling.
You are communicating to 10 different devices via TCP communication handles in a 100msec poll rate, and the same time you are opening PAC Control Debug mode while the debugger performance is set to “High”.
Beside having a lot of communication going over the Ethernet interface, you are hammering the port with the debugger the same time.
What error message do you get when the communication is interrupted?
Perhaps you need to increase the timeouts and the retries in the control engine configuration. Also, set the debugger performance to a lower value.
You should update the system and test with parameters that reflect your application needs.
What is the polling interval you need for the “normal use” of your setup?
Is there a HMI or SCADA software connected as well that displays the temperature readings?
So you are closing and opening the communication separately to each device? Don’t do that. You are using up all the network stack resources and this is why you lose communication in debug.
Create a comm handle for each device. Do not close the communication handles, just leave them open.
Debug mode requires “extra” processor time and it is common for it to degrade other communications.
You can try setting your debug performance to minimize the impact. Or if you want to use debug then slow down the rate you scan other devices.
The firmware version of this R1 controller is R9.5g, and the PAC Control I am using is R9.6e, both of which are relatively old. Because this PAC Control 9.6 is a Pro version, I have been using it all along. Next, I will download the latest R1 firmware and PAC Control Basic to try and see if it can solve this problem.
Previously, the PAC Control Debug mode was not set to “High”, but it will be changed to “High” in the next step.
The error message that appears when interrupted is the same as the prompt message when the network cable is disconnected, and there is nothing special about it.
I don’t have specific data on the traffic on the R1 network port.
The polling time for the normal operation of the temperature and humidity meter is only one minute, but I only set it to 100ms for testing in the office.
The HMI or SCADA uses groov, and a PC displays this data. It has been running for a week now and there are no issues.
Thank you very much!
Hello!
I’m glad you still remember this. It was indeed a help message I sent, and I discovered this phenomenon at that time. Because the customer only provided a few days, TCP was not used in the end. Instead, each device was assigned a separate UDP communication handle, which was kept open. Over 20 UDP communication handles were used. The controller polls devices through these UDP communication handles to meet user functional requirements. Since adding these features in 2021, they have been running normally ever since. I now want to use a communication handle to achieve the same function.
It may be easier to communicate with multiple devices using a UDP handle, as UDP does not need to consider each other’s state.
Thank you very much!
Hello!
Yes, I do need to frequently open and close communication ports, isn’t that okay? The communication between the RS485 module and the serial interface device has always been done in this way, which is quite good. The communication between PC and server is also used in this way, but there is no such frequent polling time.
Is it necessary to have a communication handle for each device? I also use it this way now, with one device equipped with a UDP communication handle, it’s okay.
Thank you very much!
Not ideal for TCP. Every connection opening and closing has a setup and tear-down process involving several network packets. It’s better to just leave it open if you expect to need more information in the future. Even if the polling rate is 1 minute, I recommend leaving the connection open to each device.
UDP (connection-less) and serial (no setup or tear-down) are different and you can open and close all you want even if it is unnecessary.
The manual contains the “Get Number Of Character Waiting” command to detect the status. I tried and it was indeed like this, but I don’t understand how this command detects it? I used Wireshark to track the TCP communication packets between R1 control and TH5900. I can see the three TCP connection handshakes initiated by the OpenOutgoingCommunication command, the two ModBus/TCP packets, and the four disconnection handshake signals initiated by the CloseCommunication command, all of which are very clear.
But “Get Number Of Character Waiting” did not issue any command, how did it know that the other party was not online?
Thank you very much for your guidance!
“Get Number Of Character Waiting” tells you how many characters/bytes are in the local receive buffer. The data packet will have already been received by the controller’s network stack for this command to be positive.
