Hard to say what the issue is without seeing the error codes from  the blocks.

Would need to see ERROR, DONE, BUSY and STATUS.

Be aware, you will have to store these as they are only valid for 1 PLC cycle.

Along the lines of:

IF STATUS <> SAVED_STATUS THEN
    SAVED_STATUS := STATUS;
END_IF;

The Modbus blocks MUST be producing some values on the block status outputs.

Without this information it is not possible to say what the issue is.

The error code decodes as:

What type and structure is data block DB3?

What are the settings for the other parameters to the block (e.g. MODE, DATA_ADDR)? 

There still seems to be something wrong with your DATA_PTR:

This post might help

https://support.industry.siemens.com/forum/nl/en/posts/modbus-tcp-error-818b/288740

I see that you are asking for 10 registers (DATA_LEN = 10). This will require storage space of at least 20 bytes. You have also chosen to start writing the data in DB address 12 of DB3 (P#DB3.DBX12.0). How big is DB3? What is the structure of DB3? I suspect that DB3 does not have enough space to hold the data.

I think I may have found your problem.

According to the help, the data type for the storage area HAS to be a 16-bit type. You have used a USINT which is an 8-bit type. Try making the type a UINT.

Data block structures for the DATA_PTR parameter

• These data types are valid for reading words of the Modbus address range (DATA_PTR) 30001 to 39999, 40001 to 49999 and 400001 to 465535 as well as for writing words to the Modbus address range (DATA_PTR parameter) 40001 to 49999 and 400001 to 465535.
  • -Standard array of data types WORD, UINT or INT
  • -Named structure of the WORD, UINT or INT type in which each element has a unique name and a 16-bit data type.
  • -Named complex structure in which each element has a unique name and a 16-bit or 32-bit data type.

I'm not sure the blocks are working, as the BUSY output is true and the DONE output is false.
However, as it is an image, it might be that the snapshot just so happened to catch it between states.

When a transaction has completed successfully you should see the BUSY output go false and the DONE output go true. You would have to monitor these online and note the sequence of the BUSY, DONE, ERROR and STATUS outputs in real time. The best way I find to do this is to open the instance data block for the function block and go online with it and use the monitor / modify view.

I am not sure what you are referring to by the word network. Network normally refers to another physical network. However, I suspect that you mean data request when you say network (i.e. data from a different slave device or data of another type or from a different address in the same slave. The correct terminology for these would be telegrams or polls.

You will have to schedule each request to each telegram (network).

So setup the Modbus request details for first telegram (network), toggle the REQ input high then low.

Then wait for the BUSY output to be false and the DONE or ERROR output to be true.
This will be the condition that indicates that the transaction has finished (successfully or otherwise).

If DONE is true and ERROR is false the transaction was successful, so go onto the nest telegram request (network).

If ERROR is true and DONE is false, the transaction failed. What you do now is up to you. You can repeat the telegram or maybe take so other action such as skipping it.

When you have finished with telegram (network) #1, you would then setup the Modbus request details for nest telegram (network) and repeat. This is what is known as a telegram / poll cycle.

It would look something like this:

For each telegram (network) (1 to n)
Set REQ equal to false
If BUSY equals false then
Setup telegram details for this telegram (1 to n)
Set REQ equal to true
Wait until BUSY goes true
Set REQ equal to false
Wait until BUSY equals false and (DONE or ERROR) equals true
Take action if ERROR is true
Next telegram

Hello,

if I could say my opinion to this problem, I see in your screenshots the first and important problem:

More Master blocks with different instance DBs.

eeeeh very sry but your intentions and prj expactations are not clear to me, why you  have this idea about more Master blocks. I think that your first and only problem lies here, you  do probably some wrong programming steps generally.

Hello,

very sry in this case, also I don't have your TIA version. Again if you want some help from me, pls try better explain what you want to do, maybe we can find some other way but your problem looks to me like this I've described. Simply, I expect one Master block with only one its instance DB, joined to Comm_Load. Then only after collect data from ex. one Slave you stop execution of block and change other parameters you require, then start execution with next Slave in case and again from first after that. Prior change parameters you need stop execution of block with REQ input, hope yo do this. I can imagine more Master blocks but then you can have coordination problem and some collission can occur running 2 Master blocks at one time. try imagine this...