3/13/2017 9:24 AM | |
Posts: 3093 Rating:
|
Hello Positize, Regards, |
3/25/2017 1:06 AM | |
Posts: 3 Rating:
|
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... AttachmentModbusRTUExample.pdf (909 Downloads) |
Last edited by: positize at: 3/25/2017 8:09:42 PM |
|
This contribution was helpful to
10 thankful Users |
Follow us on