Siemens S7 Ethernet Problem

S7Guy

Member
Join Date
Nov 2003
Location
Dayton, Ohio
Posts
1,250
I ran into a very strange problem recently.

I was at a site that has eight S7-416s. They are all connected via Ethernet to one central server running Windows 2000. There are also seven other HMI consoles running NT, plus three more Simatic TI PLCs. Siemens Softnet runs on the server, and provides the connection between the PLCs and the consoles.

Well, I was called into the plant because all of the consoles suddenly became non-responsive. As part of my troubleshooting, the first thing I did is try to ping the various devices in case some piece of hardware failed (i.e. a hub loses power). This is what I found: I could ping all of the consoles and the TI PLCs from the server, but none of the Siemens PLCs. I went to a console, and could ping the server, the TIs and the other consoles, but still not the S7 PLCs. I use static IP addresses on the server and consoles, and I did an IPCONFIG to verify that nothing had changed.

I opened the cabinets on the PLCs, and there were no fault lights. I powered one off and on again, and I was then able to ping it. I did this to each PLC, and they were back in business within a few minutes.

Afterwards, I checked the Module Diagnostics, and there were no power outages or anything else out of the ordinary in the event history.

Can anyone thing of anything that would cause ONLY the Siemens S7 PLCs to become disconnected? The plant had been operational for years, so there aren’t any IP or MAC address conflicts for sure (I did all of the programming and configuration). The only hint that I have is that it’s possible that someone in the IT department was doing maintenance on other computers on the same network (it was on a Saturday), but I can’t imagine there is anything they could have done to cause this behavior.
 
Yes, I've seen it. My guess is, you are calling FC5&6 or 50&60 from OB1, with no delay. I have seen where there is so much communication on the network and sending data TO the CP441 card that the buffer in the CP fills and slows down and sometimes quits communicating. If you go to the support page http://www4.ad.siemens.de and put this number in the "search" box, 15259232 you will see the same message. I usually put the receive block, where it is scanned every scan and the send block is triggered from a 100ms or longer trigger bit. The receive block will keep the buffer purged and the send will not overflow the buffer.
 
Thanks for the reply.

I am not using any communication functions, so that wouldn't be the cause. But, the symptoms look the same, so maybe there was something happening on the network that caused all of the receive buffers to overflow. The strange thing is that it happened between shifts, when no one is doing anything at any of the GUIs, so the traffic between the server and PLCs should have been at a minimum. I'm going to dial in and look at the server's event log again.
 
It sounds like you are using S7 functions to communicate from the HMI. Who's HMI are you using? Are you using OPC? Who's driver?
 
Hello,
The other day I had the same with some communication modules. I expanded an existing Profibus network with 1 new S7-315-2DP. Therefor I downloaded the network configuration, but i had a failure in it. (Wrong baudrate or something) Later I corrected this one, but all the other communication modules where not responding. When I turned the modules off and on again, after I had the right configuration, everything was working OK again.
So maybe, someone from the IT department made some change to your network, causing the communication module to go offline(stop).

Groeten Jarno
 
It sounds like you are using S7 functions to communicate from the HMI. Who's HMI are you using? Are you using OPC? Who's driver?

There are no functions in my project, nor are there even any connections defined in the Netpro connection table (all I do is give the CP443-1 an IP address and add an ethernet network). The HMIs are home grown, but the PLC doesn't connect to them directly anyway. The connection to the PLC is configured in COML S7, and another propriatary app uses SAPI to talk to the PLC, and moves data back and forth between the PLCs, HMIs, and other server apps. It works very nicely, and like I say, I haven't had a problem like this in years. Whatever happened, it selectively took out only the Siemens S7 PLCs, so there must be some rare condition that freezes them up unconditionally. Of course, I don't expect it to happen again, but I still would like to know what caused it.
 
Just curious about this.

Hey, I am new to this, I find this really interesting, I was just wondering how many times it happened, When you say you ping all IP address, You do it from your server or anywhere else, also wondering if you are using a CP1613.
 
broadcast storm?

Is it possible that the way in which you caused this problem with a broadcast storm, i.e. during maintenance on the network, someone introduced a loop into the network. A loop will cause broadcast packets to multiply, thereby causing the network to get flooded.

If you can overwhelm the buffers on the S7-400, maybe this was the route. I am not a siemens person, but I have run into issues with broadcast storms bringing nodes offline.
 

Similar Topics

Hello, I have connected ethernet cable with my laptop and the s120 control unit. setup my laptop ip 169.254.11.1 and subnet mast 255.255.0.0 ...
Replies
20
Views
5,406
One of our guys have setup a computer with Simatic Step 7, WinCC Flexible and a few other soft from Siemens Since im not the one who have...
Replies
6
Views
5,105
We want connect our application to a Siemens S7 400 by using an OPC server. We tried the Kepware and the Applicom Direct-Link OPS servers that are...
Replies
3
Views
10,841
Hi, I have a 1214 on ip 192.168.0.100. This is connected to other modules through a switch on same network. I need to connect this to a company...
Replies
1
Views
95
Can I open a Port from a Siemens PLC to an ethernet device Device will be at 192.168.0.1 and I need to open port 2112 (Upd?) Then once the...
Replies
0
Views
295
Back
Top Bottom