Question

I need to send alarm SMS from the RUT955. I have configured ModbusTCP communication with S7-1200 (MB_SERVER). It did not work. I got failure status 16#80c4 or 16#80c5 in the S7-1200. I tried a ModbusTCP client (master) simulater with S7-1200 and it works well. Now I have only one alarm configured (and no request configuration) and the problem is still same. Where can be a problem?

Answer 1

Hello,

Thank you for reaching out!

I've tested this configuration and everything seems to be working correctly.

I'd like you to try to configure a request for the needed information and see if it will receive the correct information.

• First, in the WebUI, navigate to Services → MODBUS → Modbus TCP Master;
• In the created slave device, please verify that:
  • Slave ID, IP address, and port are set correctly. The slave ID and port must match the one set on S7-1200.
• Make sure, that the instance is enabled;
• Create a new request;
• All of the required data here is dependent on the slave device. However, for your PLC, the correct function seems to be "Read holding registers (3)". The first register number depends on what data needs to be read. Register count simply tells the master how many registers to read from the specified first register.
• Enable the request;
• Lower in the page, you'll see the "Request Configuration Testing" section. Here, select the created request, and press the test button.
• If the data shown below is incorrect:
  • Wrong format/nonsense data: check the selected data type in the request configuration;
  • Received too much data/data at the end only contains 0: decrease the register count;
  • Not enough data is received: Increase the register count;
  • "connect: Operation in progress" message is received: check the IP address, port, Slave ID, and settings on the PLC. This means that the slave device is unreachable;
• If data is received, we can continue with Alarm Configuration;
• Create a new alarm;
• Function code: same as in the request configuration;
• Register: register with the relevant data;
• Specify the condition, value, and frequency.
• Optionally specify redundancy protection to prevent the device from sending the same message too often;
• Action: SMS;
• Message: Specify the text message to send. Do not leave empty;
• Specify the phone number to send the messages to. Use country code prefix (+1 for USA, +370 for Lithuania, etc.)
• Enable the instance and press "Save & Apply"

This should be it for the configuration. Of course, SIM card must also not be data-only. This can be tested by navigating to Services → Mobile Utilities → Messages → Send Messages.

Let me know if any more help is needed!

Best regards,

DaumantasG

Comments

Btw I tried to send a testing message over Services -> ... ->Send Messages and I got this message two times...

Answer 2

Thank you for answer,

Everything is setup as you wrote. Please see attached pictures. But when I set more alarms (in holding registers of PLC) then some alarm is sent two times (with option First trigger) and some of them is not sent at all. 

Comments

Thank you for the information!

Perhaps it would be possible to increase the slave device reading period to 10 seconds for testing purposes?

Also, when you sent the message via mobile utilities, did you send the message once and received it twice, or sent it twice and received it twice?

Best regards,

DaumantasG

---

Would be possible to change delay between alarm requests (not communication period) in one communication block? Reason: to finnish previous communication with S7-1200. Or still keep connection between RUT955 and S7-1200 (without disconnection after every request).

Answer 3

The situation is same with communication period 10 seconds. 

I pressed the button of mobile utilities only once, but the message was delivered twice.

Now I tested communication between the RUT955 and my laptop with ModbusTCP slave (server) instead of the S7-1200 and it works very well. Right messages were sent. So it means that there is some problem between RUT955 and S7-1200. The S7-1200 ModbusTCP master failure status shown me error code 16#80c4 (Temporary communication error: The connection cannot be established at this time. or The connection cannot be established because the firewalls on the connection path are not open for the required ports. The interface is currently receiving new parameters. or The configured connection is currently being removed by a "TDISCON" instruction.) or failure 16#80c5.

So I think that a problem can be between sending requests from RUT955 to S7-1200. A new request from the RUT955 is faster then finishing (disconnecting) of the previous session request.

Comments

It seems like this error is shown when new data is requested and the old one has not been sent yet. To avoid this issue, different instances could be used for each alarm with different periods. This way risk of collisions would be minimized.

To achieve this, navigate to Services → Modbus → Modbus TCP Master and create 4 new instances (each for different alarms) with different periods. The same IP, ID, and port could be used for multiple instances.

Hope this helps!

---

Yes, it could help, but I need to send approx. about 30 different SMS and in this case it would be very complicated. I tried to leave enabled only one alarm request (all others were disabled) but I still got failure status 16#80c5

---

Is it related to a certain register or does it happen randomly? It seems like this is quite a common issue in the Siemens forum.

This error would require troubleshooting from Siemens PLC itself, and I'd recommend checking the error code in the manual for the Siemens device.

In the v7.3 update of RutOS, which is planned to be released until the New Year, there are a lot of improvements in the Modbus service, which might rectify this issue or provide workarounds.

Best regards,

Daumantas G.

---

Yes, of course I saw a lot of topics regarding 80c5, but in this case I think it is caused by fast communication. By my testing communication it looks that the RUT955 opens and closes TCP connection for each alarm. I think that the RUT955 should open connection on the beginning of periodical communication (with first alarm request), communicate all alarm requests and then close it. Or open connection and keep it all the time.

---

In v7.3 an option to add delay after the connection is established will be added, so that may help.

Best regards,

DaumantasG

---

ok, great. Maybe would be good to add option to open and keep connection permanently:-)

Would be possible to get some beta version for testing with Simatic?

Thank you, BR Jiri

---

Sent via private messages.

Best regards,

DaumantasG