Pretty much every Siemens communications block uses the same control scheme.  Input trigger to send, always on (Enable) to receive - after comms init succeeds..

Then we monitor the send block for Done or Error (pretty much ignore busy has been my experience).

If Done or Error is true, reset the request bit and initiate a new request to send, or enable a new send request - as appropriate for the project needs.  If the error output becomes true, also save the status output word to a global DB tag using a MOVE.

By using that approach, you can handle nearly every communications block Siemens provides.  There are some rare exceptions, but the F1-Help or the library documentation for those blocks describe the inputs and outputs so the send block's control logic can be adjusted to suit.

Do not try another send while a send is busy.  Do not use the send block DB for another send block unless there is no way another send block can be triggered or already sending.  This is an advanced topic, but if your logic uses the send block's DB more than once, you are not setting yourself up for success.  It is far better to use a single send block and swap out the send data DBs data between send requests.  This can be done inside an FC to hide the noise of that activity and ensure it's all done at the same time and right before sending.

Waldek88

Hello
I use S7-1512SP F-1 PN V2.8, and communication module CM PtP V1.0 configured to Freeport/Modbus. TIA Portal V16 update 4.

Communication over Modbus RTU with device working sometimes one week, sometime two weeks.

After hang, I must initialize DB block or restart PLC.

In this FB block i have Modbus_Comm_Load (v3.0) and Modbus_Master (V2.0).

I tried changed version of the communication block but the problem still exist.

Any advice?

Best Regards

Since the status and error outputs are not monitored and saved, you have no real idea if an error actually happened.

Since the error output is only true for a single plc scan, you can use it to save the status output to a global DB tag that you can set to retain so even after a power outage you can see the last error output.

In ladder, a simple NO on the ERROR output and a MOVE the STATUS output to "GlobalDB".last_MB_Master_Error_Status (or something equally useful to you).

Waldek88

Hi

Thx for answer

When is the error, status is 16#7002

Now working one week, but i waiting to hang.

I atached code.

Best Regards