PAC R1 - Modbus Error -216, Register stuck at 32767 / 0 - PC1 Pressure Value Issue

PAC Project
1

Hi Team,

We have SNAP PAC R1 (PAC Control R10.4) with pressure controller on Modbus TCP.

We use:
O22Modbus03ReadHoldingRegistersAsInt(CommHandlePressureControl,…, 32, nt03HoldingRegAsIntReturnValues, 1, n03AsIntStatus)

Problem:

  • n03AsIntStatus = toggles 0 and -216 timeout
  • nt03HoldingRegAsIntReturnValues[0] = 32767 (stuck) → HMI shows 1010 mbar
  • Now after some changes value became 0, and PAC cannot go online / debug.
  • PC2 (analog input) shows 212 mbar correctly, so vacuum pump is OK.

Questions:

  1. What does error -216 exactly mean?
  2. Why register returns 32767?
  3. How to fix intermittent Modbus TCP timeout?

We checked cable and power cycled pressure controller.

Please help. Attached screenshot.

Thanks,
Vijaya Shanthi
Chennai, India

2

-216 is the subroutines timeout error code - it sent the request and did not receive a response within whatever timeout setting you have set in the ntParameters.

Had this system worked before or is this something new you are working on?
Can you communicate with the pressure controller using a utility like Modbus poll?

I don’t know why your register returns 32767 as I don’t think the Modbus subroutines would put that value in there - that could be coming from your pressure controller.

Not being able to reach the PAC Controller is another concern - if you are opening and closing a lot of TCP comm handles in your strategy then that could happen - what else do you have running on this controller? You also could have a network issue of some kind.

3

pdate:
The Modbus Master chart is now successfully Running in PAC Control! However, n03AsIntStatus is still returning a -216 timeout error.

The communication handle value is configured as: tcp:192.168.1.2:22522.

Since the status is still -216, could this be a Unit ID (Slave Address) parameter mismatch inside the integration kit, or is the controller dropping packets because of the custom port 22522 instead of standard 502? Any advice on what to verify next on the controller side while the client is setting up the hardware reboot?

4

You didn’t answer all of my questions, but I have a couple more now:

Are you using a serial module? Do you have your Modbus parameters set for Modbus RTU or TCP?

5

This is an existing system, and the pressure controller is communicating with the SNAP PAC R1 over Ethernet using Modbus TCP. We are not using a serial module, and the Modbus parameters are configured for TCP, not RTU.

The communication handle is:
tcp:192.168.1.2:22522

The issue is intermittent: sometimes the Modbus read works, but n03AsIntStatus changes between 0 and -216 timeout.

Could the custom TCP port 22522 or any Modbus TCP configuration on the pressure controller be related to this timeout? Please let me know what parameters or diagnostics you recommend checking next.

6

I would increase the timeout, and if that doesn’t work, get a wire shark trace to see what is happening on the network.

7

Thank you for the suggestion.

I increased the Modbus timeout in my strategy from 500ms to 2000ms and added a retry with a small delay. The n03AsIntStatus = -216 timeout is now much less frequent, but it still happens intermittently.

You are right about Wireshark. I will take a Wireshark trace on 192.168.1.2 port 22522 to check if the pressure controller is closing the TCP socket or not responding to the Modbus TCP query. I will also check the pressure controller’s side for Modbus TCP server settings - max connections and response delay for this custom port 22522.

Thanks again for pointing me in the right direction. I will update the thread once I have the trace results.

Thanks..

8

You may want to add a ClearCommunicationReceiveBuffer(chCommHandle); before you call the modbus subroutine as well in case a response came in after the timeout and is sitting in the buffer before the next request.

9

Thank you, that makes sense. Good point about the late response staying in the buffer.

I will add ClearCommunicationReceiveBuffer(chCommHandle); right before I call the Modbus subroutine, like this:

ClearCommunicationReceiveBuffer(chCommHandle); n03AsIntStatus = O22Modbus03ReadHoldingRegistersAsInt(...)

This should clear any stale response that came in after the -216 timeout, so the next request starts clean.

I have also increased the timeout to 2000ms with a retry, and will get a Wireshark trace on tcp:192.168.1.2:22522 if it still happens.

Thanks again for both suggestions!