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.

[kelvinviroja93]

@Hennie_Smith @YONGHO-KIM 

Thank you so much for reply.

@Hennie_Smith I have implemented the Bandwidth traffic setting as per your suggestion.

@YONGHO-KIM I have programmed the data poll loop as per your example and its working nicely.

Sometimes "startcomms" bit stays 1. need an additional program that reset it if it stays up for some time. 

[kelvinviroja93]

Dear Sir,

@YONGHO-KIM @Hennie_Smith 

I have implemented your suggestions in the logic.

Now, PLC successfully getting data most of the time, but sometimes anyhow PLC still getting 16#0007 Error on random intervals on random devices. After the data exchange error, in next 1-2 minutes again it is getting healthy.

I have attached the screenshot of data and attached the PLC backup, can you please review and suggest the solution for it ?

[Hennie_Smith]

Good day,

Have you tried slowing the comms down to 500ms instead of 350ms. From the programme it seems you are reading the power meters via a serial to Ethernet gateway, if you poll the gateway to quick, it will not respond if it is still busy on the serial side. 

Is there a specific requirement why you need the power meter info faster than 500ms?

Regards,

Hennie Smith

[kelvinviroja93]

Sir,

I have tried various poll rate and timeout settings, but the result remains the same. At times, the system works flawlessly, but then it generates the 16#0007 error. After a while, it starts working correctly again.

For example, I used a 1-second timer–counter combination to enable each READVAR execution after every 1 second.

What I have observed is that when a READVAR generates the 16#0007 error, that specific READVAR seems unable to send a data request to the slave gateway afterward. In my assessment, this is 99.9% likely related to a PLC firmware issue.

I have also attempted to use the CANCEL function to neutralize the communication after each READVAR execution, but the behavior remains unchanged.

[RoozeeR · Accepted solution]

Hello,

I have checked your application and see some timing issues:

1: the READVAR timeout parameter .._GEST[3] is set to 6 (=600mSec), which is higher than the activation period of 350mSec. Please set the activation time to a value higher then the timeout value, or make use the READVAR activity bit to activate the next READVAR.

2: Each gateway has a Modbus timeout defined which is not visible in your application. This timeout should be lower than the timeout of your READVAR. Make sure that the timeout is long enough for each Modus slave to send an answer in time.

Using the current timeout values and activation timeout is causing problems which get worse in time.

Make sure the vales are in line:

1. Normal worse case response rate of each Modbus device. (example 300 mSec)
2. Gateway Modbus timeout should be higher than (1) (example 500 mS)
3. READVAR timeout  should be higher than (2) (example 700 mS)
4. Activation period as used in your application  should be higher than (3) (example 1000 mS)

When using the activity bit to activate the next READVAR the communication speed can be faster when the Modbus devices respond faster. Check the timings in this example but keep the order as 1-2-3.