M340 READ_VAR Fails with 16#0007 Error on Modbus TCP Gateway Communication

[kelvinviroja93]

Hi all,

I'm using a BMEX342020 controller in my project, and I’m not using any physical I/O modules. The task is to read data from several Modbus RTU devices via Modbus TCP gateways.

I’ve used the READ_VAR block to fetch data from the slave devices. The configuration and addressing appear to be correct. However, I’m facing an intermittent issue:

• Sometimes the READ_VAR block succeeds, and I get correct values.

• Most of the time, it fails with error code 16#0007.

• Meanwhile, if I use ModScan or similar tools from my PC with the same gateway and slave, the data is read successfully every time.

Here are some more details:

• PLC: BMEX342020

• Protocol: Modbus TCP to Modbus RTU (via gateways)

• Modbus Gateways: Third-party, configured correctly (as verified with ModScan)

• Using READ_VAR for polling multiple slave IDs

My questions:

1. What exactly does error 16#0007 indicate in this context?

2. Is there any timing or connection-related configuration I might be missing in the READ_VAR setup?

3. Do I need to handle socket disconnections manually in this kind of setup?

4. Could this be related to Modbus response timeout, or gateway holding the socket open?

Any insights or experiences from similar setups would be greatly appreciated.

Thanks in advance!

@Trinxs1 @ciupol @YONGHO-KIM @Hennie_Smith 

[Hennie_Smith]

Hi Kelvin,

There could be various factors but looking at your code I would propose trying:

1. On the network settings, change the Bandwidth to 'MASTERED' which will give the CPU more time to process communication.

2. Depending on your BAUD rate to the Serial devices the Timeout of the GEST you set of the 300ms might be too short (especially if the BAUD rate is 9600), have you tried changing the timeout to 500ms?

3. In CALL_2 to CALL_6 also add the code to increment your scheduler counter if the activity bit change to 0 like you done for CALL_1. That said, in CALL_1 for the increment of the counter, rather only look at the falling edge of the activity bit and don't include the report status (remove GEST[2]=0). 

To answer your specific questions:

1.  Most likely gateway not responding in time.

2. No, connections is managed by the CPU, no configuration in programme

3. No, this is managed by the CPU

4. Yes which is why I propose setting the timeout to 500ms

To have a status bit if the comms to each slave is online you can use a TOF time with GEST[2]=0. Bit will be 1 if comms is healthy

Regards,

Hennie Smith

[YONGHO-KIM]

1) 16#07: Problem in Sending to the Destination
- Please refer to the image below for more details.

2) Ensure Adequate Delay Between READ_VAR Requests
- If the PLC sends requests too frequently, communication errors may occur.
- See the example below for recommended timing.

3) Check Slave Device Response Time and Timeout Settings
- Make sure the slave device is not responding too slowly.
- Also verify that the timeout setting is not too short.

4) Verify Gateway TCP Connection Settings
- Check the TCP connection keep-alive time and the maximum number of simultaneous connections supported by the gateway.