Hello everyone.

My setup:

TIA portal V13 SP1 update9

CPU1511-1PN & CM PtP RS422/485 HF_1

No other logic in the CPU then the modbus blocks.

On the communication card of Siemens, an RS485 convertor to my pc with a simple terminal program connected, to see the traffic.

Discription about the modbus protocol:

A master sends a message on the bus, and gives the slaves with a time delay the time to respond on this message.When a slave answers in this time, all is well. If there is no response, a timeout will occur and error will be generated.

My problem:

When polling the Modbus master block, with a "true" bit on the REQ input, the communication card is sending messages in one stream, with NO delay between the messages. The slave can never answer, because it hasn't the time to send a response.

YES, I set the RESP_TO setting on the Comm_load block, on 1000ms.

YES, I set the Comm_load.MODE to 4 -> RS485 2 wire

YES, in the Comm_Load DB I set the RETRIES to 10 (note that in the manual, by default Siemens is talking about 2, when opening this DB, 0 is the real default...)

YES, at every test I did, I restarted the CPU, to correctly initialize the Comm_load block.

Hey, use a positive edge triggered REQ! OK, it will send one message every time I trigger the REQ input. (on 0.5Hz clock signal with RESP_TO at 10 000ms or 10! seconds) Here every time my REQ is triggered, I see a message passing. With the error bit set, ok that's normal, as I have no slave that responds.

What if I set RESP_TO at 1000ms (siemens default)? After 3 messages the block freezes at the "BUSY" state. Disabling and re-initializing all blocks is no solution. The only workaround is to set the MB_State in the modbus master DB to 0 and intitialize all blocks, as descibed here: Topic with same problem?

I put the retries on 10, so I need to see 10 messages before this block may stop polling.Still this is no solution.

So for me, the RESP_TO feature isn't working, it's a timeout that blocks the whole communication.I never saw mutiple attempts what the "RETRIES" should do.

What am I doing wrong? How is this RESP_TO feature working behind the scenes? What logic is behind?

Thanks in advance,

Kind regards,

Tim.

Hello everyone,

Here the solution form siemens technical support:

The line initial state must be initialized in idle state.

This is done by setting the parameter in Comm_load DB -> LINE_PRE to "2".

You can find the description in the help document in TIA portal.

This is not by default! When you have this setting wrong, your communication freezes.

Also, now I can ask the REQ input with a bit always high, and the communication card will send the messages with the interval as configured.

I hope this will help other users.

Many thanks to siemens support team, who helped me with this.