TCP communication problem of R1 controller

The R1 controller (firmware r9.5g) is used to collect the data of the thermometer and hygrometer (model: apem5900-th) through TCP protocol. After working normally for a period of time (one day or several hours), the communication is over. I use the method of restarting R1 or apem5900-th, which can run normally for a period of time, and there is a problem again.

When something went wrong, I found a problem with the tracker. When “open outgoing communication” is used, the command returns the value "TH5900_ TCP_ stat“ is equal to 0. Doesn’t that mean success? But next I’ll use “communication open?” When checking, the return value is 0, and the communication is not established.

Why? How to solve it?How to confirm that the communication is established normally?

When returning Stat = 1 it “usually” means that the comm is open and connected.

Are you saying that the condition for Comm Handle Open? is not met and it returns to opening the port?

Are you closing the outgoing TCP connection again after failure?

I mean, this command does not correctly reflect the status of the TCP connection. Is it a connection? Or disconnected?
This is the command below.
Communication Open?
Communication Handle TH5900_ TCP_ Interface

apologies I made a typo above, I should have checked, your comm is not opening it seems. See below:

Communication Open?

IsCommunicationOpen(Communication Handle)

if (IsCommunicationOpen) then

This is a function command; it returns a value of true (non-zero) or false (0). The returned value can be consumed by a control structure (as in the example shown) or by a variable, I/O point, and so forth.

Communication Open?

  • Using TCP, this command will return a true (non-zero) even if the other side has closed. This situation is called a “half open” connection. Even though the other side has closed, there may still be characters buffered by the control engine. Make sure the characters are received (and the communication handle closed, if appropriate) so that sessions aren’t used up by a half-open state.

  • When using TCP/IP, use this command to evaluate if the command Open Outgoing Communication has been called on this handle. To evaluate the status of the handle later, use the response of the command Get Number of Characters Waiting . This command will indicate if a remote host has issued a message to close the session.

Are you using the “Get Number of Characters Waiting” command?

Please share the following:

Your TCP comm handle (it should look something like this - tcp: )

I see, thank you!

The data of 50 such thermohygrometers (APEM5900-TH) need to be collected, Modbus / TCP communication protocol. I plan to handle it with a communication handle. This requires frequent opening, closing and modifying the value of the communication handle. Will this cause TCP resources to be heavily occupied? Where can I see the usage of TCP resources?
Please give me a suggestion, thank you very much!

This is the core of your problem.
Please review page 263 of the PAC Control Users Guide (doc 1700 - from PAC Control, click on Help, then Manuals).
It describes your problem. You are running out of TCP sockets. The only way to get them back is wait, or cycle power to the controller.

Your chart is too aggressive in opening and closing connections.

The only way to see the number of connections is to use SNMP which is not really straight forward.

thank you! This is indeed the core of the problem.
If I use a communication handle to handle only one device, each communication handle will not be opened and closed frequently, but 50 communication handles are required.
Don’t know if this is feasible? How will you solve this problem?

Don’t open and close.
Open and use.

50 is hard, but not impossible.

1 Like

Is there any way to release the resources of TCP stack as soon as possible? :grinning:

Yes, thats the page I suggested you read.
handles are meant to left open as long as possible

Thank you. I’ll try 50 handles instead

No. I would not do that.
If you cant do one for more than 24 hours, 50 will only make things (much) worse.
Get your chart for one comm handle sorted. Then add more. Slowly.

That’s fine. Thank you!

Are UDP communication handles also limited by this stack? :grinning:


Extra words to allow post. Ignore.

If the UDP communication handle is not limited by the stack, can the UDP communication handle be opened and closed frequently?. Then I can use a UDP communication handle to collect data from 50 devices, and the device also supports Modbus / UDP communication mode.
Is this feasible?

I would not open and close frequently, but you are welcome to try that method.