We have Modbus RTU that locks up if communication is lost between CPU and CM PTP module.

The Modbus is RS485, 9600, N, 8, 1 as a Master. Is reliable until we disconnect the Ethernet cable between the PLC and the Remote IO.  There does not seem to be any way to get the CM PTP to recover from this.  All other remote IO in the system recovers, but the Modbus_Master FB is locked up.  Never times out, just stays BUSY with STATUS 7002.  No DONE, no ERROR.

If I power down system and power back up, Modbus to remote IO CM PTP is reliable again.  But this is not workable: everything else in system will recover from loss of Ethernet communications between PLC and ET200SP except the CM PTP.

We call Modbus_Comm_Load successfully after this condition to make sure the comm module is reconfigured for 9600,N,8,1 (returns with DONE).  But any subsequent call to Modbus_Master just hangs with no ERROR, no DONE, no timeout.

Have tried a manual timeout to remove the REQ to Modbus_Master.  Then call with new REQ, but Master still stays locked up.

Using a CPU1512 with an ET200SP remote IO and a CM PTP module.  Tia Portal V13 SP1 UPD9.

CM PTP is 6ES7 137-6AA00-0BA0

Running Modbus_Comm_Load V3.0 and Modbus_Master V2.3.

Have tried this on two CM PTP modules: both lock up the same way (Modbus_Master no ERROR, no DONE).

In the Hardware config General tab, Receive Buffer, have tried reducing the Receive Buffer length to 1 (from the default 255). Tried turning off  'Prevent Overwriting'.  Tried turning on 'Clear Receive Buffer on Startup'.

Recently tried adding a call to Receive_Reset but that apparently is not for Modbus: it never returns with a DONE or ERROR.  So I presume that Receive_Reset is not available for Modbus.

To reiterate, Modbus working great until we introduce Ethernet comm failure between PLC and CM PTP.   After bringing remote ET200SP back online, Modbus_Comm_Load works, but the Modbus_Master call locks up.

Is there any way to force the Modbus CM PTP to start over from scratch (like a powerup) without having to power the whole system down and back up?

Hello,

I'll be make some little test. Prepare test with set ASCII protocol (if it can be set) and with simple exchange data between ET and PC application (it can be some text exchange). Make needed conditions to prevent some hang up as you expect. Start cyclic exchange data and then unplug/re-plug Ethernet cable. Results?

Thanks Kaulquappe for suggesting I start a support request.  Since I was able to provide a reproducible failure to Siemens, they were fabulous about getting me an answer quickly.

I had poured through the Siemens Support pages and never found anything that explained how to solve this problem and indeed it was apparently a new problem since they had to do a little research to determine the answer.  For other folks that just can't get reliable Modbus RTU when the comms between the PLC and remote IO fail, there is an easy fix when the Modbus_Master locks up:

1) Stop REQ on Modbus_Master

2) Set the variable MB_State in the Instance DB of Modbus_Master to "0"

3) Call Modbus_Comm_Load for reparameterization

4) Call Modbus_Master again to communicate

I am quite familiar with Modbus, have implemented it on many devices, and have previously designed a Modbus communication analyzer so I usually feel confident that I can get Modbus going reliably. But I must admit I found it very difficult to get reliable Modbus communications going in TIA Portal. The above 'fix' is certainly a huge help to get Modbus RTU Master communications working with an S7-1500 and a CM Ptp module, however most of my problems were caused from the fact that I did not understand that communication between the PLC and the CM Ptp comms module is ASYNCHRONOUS.

If I had internalized the important fact that the PLC code is talking to an asynchronous device internally within your cabinets (from PLC to CM Ptp), I would have realized that you have to program Modbus with a different mindset than all other PLC programming.  You need to allow time for things to occur and ensure each interaction between the PLC and the CM Ptp functions is done using the simple semaphores provided in the Modbus_Comm_Load and Modbus_Master functions.  But if you make the mistake of thinking you can do things like a one-shot pulse to the Modbus functions, you will be seriously disappointed in the reliability of your code: you instead need to send a REQ, wait for a DONE or ERROR, turn off the REQ and allow enough time for the CM Ptp to see that REQ de-asserted, then start a new comms with a new REQ.

The other important pointer I got from Siemens support (they are great!) is to be sure to monitor OB83 (pull or plug of modules) and OB86 (rack or station failure) so you know other situations that require you to call Modbus_Comm_Load.  I simply had not found that important gem of information anywhere: it likely exists, but I missed it. 

Given how much time it took me to get the Modbus RTU working reliably, I have decided to attach a complete example Siemens TIA Portal Ladder Logic based Modbus RTU project here. 

Some useful items in this project are the important coding to ensure the Modbus_Comm_Load REQ/ERROR/DONE are handled with timing that ensures relibability, plus the same for Modbus_Master.

My device also output floating point data so that was a bit challenging to figure out how to convert the Modbus words into a real variable on the S7-1500.  So if you look at this attached project  you'll find a very short SCL routine that allows you to take 16 bit words from any Modbus device and assemble them into a Siemens real.

I hope this example project saves other folks the pain and time it has taken me to get this working.  My apologies it is in pdf form rather than .ap13 however a fully minimized TIA Portal project exceeds the maximum upload size allowed here - so hopefully a pdf is sufficient.  

Cheers...

Dear Positize,

Me too I got some issue using CM PtP so I'm reading very carefully your SW example.

In the Networ 12 unfurtunately the final part is not showed, could you kindly tell me if the Reset of the MM_REQ is the right thing to do?

Thanks in advance,

Ric