S7 300 geht in Stop , wenn MPI kabel zum PC angeschlossen wird !

Seit wann braucht man einen Fehler OB, um zu verhindern, dass die CPU in STOP geht, wenn man das MPI-Kabel ansteckt?


Auszug aus der Siemens Hilfe:


Kommunikationfehler OB (OB87)

Beschreibung

Das Betriebssystem der CPU ruft den OB 87 auf, wenn ein Ereignis auftritt, das durch einen Kommunikationsfehler ausgelöst wurde.

Wenn Sie den OB 87 nicht programmiert haben und ein Startereignis für den OB 87 auftritt, verhält sich Ihre CPU wie folgt:

· Eine S7-300-CPU geht in den Betriebszustand STOP.

· Eine S7-400-CPU geht nicht in den Betriebszustand STOP.

Ob es jetzt der ist, kann ich nicht mit Sicherheit sagen, aber ich hatte das auch schon - und es war ein fehlender OB. Vielleicht hängt es auch mit einer überempfindlichen MPI-Schnittstelle bei manchen CPU's zusammen. Ich habe seit dem die OB's 80,82,85,86 und 87 immer in meinen 300er CPU's - rein prophylaktisch.
 
Ich habe den OB87 noch nie verwendet und hatte auch noch nie ein Problem mit MPI. DIe Gründe müssen woanders zu finden sein.
@TE
Bist Du an einem Laptop oder an einem PC?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe seit dem die OB's 80,82,85,86 und 87 immer in meinen 300er CPU's - rein prophylaktisch.
Und am besten leer ohne Fehlerauswertung.
Das kann aber mächtig nach hinten losgehen.

Aber ich habe hier auch eine Anlage, wo manchmal ähnliches auf dem dp-bus passiert. ich stecke pg an danach auf den dp-bus.
dann kommt es manchmal zu einem kurzzeitigen zusammenbruch des busses. wenn ich wieder abziehe und erneut draufstecke ist alles gut.
in der nähe des systems befindet sich bei mir eine absaugung mit hochspannungsfiltern. ich vermute, das sich im buskabel eine kapazität aufbaut. ich habe daraufhin den schirm an der et200s schittstelle dort mal zusätzlich geerdet. das hat das problem behoben.
 
Und am besten leer ohne Fehlerauswertung.
Das kann aber mächtig nach hinten losgehen.

Ich lass mich gerne aufklären. Bis jetzt galt mei mir die Devise, lieber einen leeren OB, als ein plötzlicher CPU-Stop. Bei einigen Anlagen, die ich programmiert habe kann ein CPU-Stop richtig Schaden anrichten (> €50000).
 
ja bin mit mein notebook dran, die sps stoppte als ich mpi kabel reinsteckte , und andere seite im usb steckplatz, die verbindung war aber noch nicht hergestellt, bzw, war fehlerhaft, falsche ipadresse oder falscher interrupt stand da. ich kann auch nicht sagen ob ein OB87 programmiert ist, wollte mir ja das programm runterladen ...
 
Dann schau mal im Diagnosepuffer nach, was die Stopursache ist.
Mir hat mein SPS-Lehrmeister auch gesagt, dass wenn sowas auftritt einfach den OB leer einfügen.
Warum auch nicht? Würde mich wirklich interessieren.
Bei PCS7 kann man den nicht leer lassen, da er sonst vom System wieder rausgeworfen wird. Das ist bisher der das einzige minimal böse was mir dabei pasiert ist.
Aber die CPU läuft und läuft.
 
hast du dein mpi-kabel auf die profibus schnittstelle eingesteckt? evtl. wurde der dadurch gestört und dann geht die cpu auf stop
sofern nicht abgefangen durch fehler-ob´s.
lies doch mal den baugruppenzustand aus, da ist die fehlerursache festgehalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
pc hatt ja keine verbindung hergestellt !, bei test der MPI Schnittstelle satnd da falsche ipadresse oder falscher intrupt? aber bei der anlage davor auch eine s7/300 gings... leider steht die maschine sehr selten und sobald ich da wieder rangehe stoppt sie , muss ich also erstmal verschieben :-(, ... nächste woche di kommt vielleicht jemand der sich damit besser auskennt, kenn die anlagen erst seit einer woche... a
aber also wie gesagt OB82-87 sind vorhanden und nicht leer...
 
..Mir hat mein SPS-Lehrmeister auch gesagt, dass wenn sowas auftritt einfach den OB leer einfügen.
Warum auch nicht? Würde mich wirklich interessieren...
Es kann z.Bsp. vorkommen, daß alle angesteuerten Ausgänge anfangen zu flattern. Zumindest, wenn der Profibus betroffen ist. Den Rest kannst du die ausmalen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es kann z.Bsp. vorkommen, daß alle angesteuerten Ausgänge anfangen zu flattern. Zumindest, wenn der Profibus betroffen ist. Den Rest kannst du die ausmalen.

OK, ich habe da jetzt mal ein paar Minuten darüber nachgedacht. Meine Frage - wie gesagt, ich lasse mich gerne aufklären - ist: Wie fängt man das ab, ohne die CPU zu stoppen. Wobei ich schon sagen würde: Das ist ein Extremfall.

Man könnte ja z.B. alle Ausgänge des betroffenen Slaves abschalten, Gibt es dafür eine schöne schlanke Methode, die allein mit dem entsprechenden OB auskommt?
 
..Wie fängt man das ab, ohne die CPU zu stoppen. Wobei ich schon sagen würde: Das ist ein Extremfall...
Meinst du mit "Extremfall" daß die Ausgänge flattern? Extrem ist es, aber nicht selten. Man braucht nur mal an einem ausgereitzen Bus einen Abschlußwiderstand öffnen, oder wie hier eine Stichleitung (PG) anschließen, und schon geht's los.

Normalerweise sollte die CPU in so einem Fall auf Stopp gehen. Nun gibt es natürlich auch Anlagen, bei denen bei Slave-Ausfall der Rest weiterlaufen kann bzw. soll. Solche Anlagen habe ich auch. Ich muß gestehen, ich habe auch noch nichts dagegen unternommen. Bei diesen Anlagen habe ich auch entsprechende OBs im Programm, die den CPU-Stopp verhindern.

Es gibt, glaube ich, eine Systemfunktion mit der man einzelne Busteilnehmer abschalten kann. Im Fehler-OB kann man ermitteln, welche das sind. Ein weiterer Gedanke wäre, die Ausfälle pro Zeit zu ermitteln. Gibt es z.Bsp. innerhalb von drei Sekunden mehrere Ausfälle, könnte man die CPU stoppen. Beim Abschalten eines Slaves passiert dann nichts. Ganz sauber ist das aber nicht. In den drei Sekunden kann schon einiges passieren.

Wie gesagt, ich muß das auch noch umsetzen, suche auch eine einfache Lösung.


Gruß, Onkel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
OK das Flattern tritt aber nicht wegen dem fehlerhaften OB-Abfangen, sondern wegen einer Hardware-Störung am Bus auf.
Das ist natürlich nicht so einfach, denn selbst wenn man den Teilnehmer deaktiviert, kann dies zu einem flattern führen.
Letztendlich müsste man den letzten Wert an den die Baugruppe ausgibt halten. Dies ist aber ohne Kommunikation zu ihr nicht möglich.
Daher dürfte es in diesem Fall bei mir flattern.
 
@TE
Probier mal aus, was passiert, wenn Du Deinen Laptop ans Netz hängst, bevor Du ihn an die SPS ansteckst. Vielleicht hat Dein Rechner irgendeine Spannung auf dem Gehäuse, die sich dann über die CPU entlädt.
 
..Das ist natürlich nicht so einfach, denn selbst wenn man den Teilnehmer deaktiviert, kann dies zu einem flattern führen...
Nein. Wenn der Bus instabil wird, dann kann der Master angesprochende Slaves zeitweise nicht mehr erreichen. Der Slave reagiert darauf und schaltet im Normalfall seine Ausgänge auf false. Da man den Master durch die OB-Aufrufe entmündigt hat, mastert er munter weiter. Ein paar Bus-Zyklen später wird rein zufällig der Slave wieder erreicht und die Ausgänge werden wieder gesetzt. Dieses Spiel setzt sich dann fort. So kommt es zum Flattern. Wenn man den Ausfall jedoch erkennt und den Slave deaktiviert, dann wird er vom Master nicht mehr angesprochen. Dann flattert nichts mehr.

..Letztendlich müsste man den letzten Wert an den die Baugruppe ausgibt halten...
Bei einigen Slaves kann man konfigurieren daß der letzte Zustand bei einem Kommunikations-Ausfall gehalten wird. Das macht der Slave dann selbst, denn ganz so dumm ist er ja auch nicht. In der Regel ist das jedoch noch gefährlicher.
 
Zurück
Oben