Step 7 SPS in Stop durch Profinet Unterbrechung

[S7Anfänger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,
Ich habe mal wieder ein Problem.
Und zwar verwende ich eine ET200S (IM151-8 PN/DP CPU) An der CPU sind über Profinet an Port 2 2Stück Frequenzumrichter ATV320 von Schneider Angeschlossen.
Da die Anlage erst durch die SPS gestartet wird, werden auch erst dann die Frequenzumrichter mit Spannung versorgt.
Jetzt habe ich das Problem, das die SPS in STOP ist, und ich einen Profinet Fehler habe. Der Fehler kommt von den Frequenzumrichtern, da diese nicht gestartet sind. diese kann ich aber erst starten, wenn die SPS in RUN ist.
Wie bekomme ich die SPS in RUN, obwohl ich einen Profinet Fehler auf Port 2 habe.
Kann ich den Fehler ausblenden?

Bitte Bitte Helft mir.

Ach so. ich Programmiere in FUP wäre nett wenn die Hinweise dann auch in FUP sind.


Besten Dank
Hagen

 

[Mich89]

Hi!

Du musst nur den OB87 (denke ich) anlegen, der ist für Kommunikationsfehler zuständig.
Du musst nichts reinschreiben, im Fehlerfall wird nur der OB aufgerufen und du bekommst einen Busfehler, aber die CPU bleibt in RUN.

In der Hilfe findest du unter "OB" die Liste der betreffenden Bausteine, und wann sie ausgeführt werden.

mfG
Michael

 

[ThomasM]

Zuviel Werbung?
-> Hier kostenlos registrieren

Edit: Alles weg, übershen dass es STEP7 und nicht TIA ist

Der SFC12 sollte dir zusätzlich auch weiterhelfen, damit kann man IO Devices aktivieren/deaktivieren.
Und ja OB87 ist für Kommunikationsfehler.

Gruß ThomasM

 

[S7Anfänger]

Danke für die schnellen Antworten.
Also nur die OB87 Anlagen hilft leider nicht. Die SPS bleibt in STOP.
Wie mache ich das mit dem SFC12? Wo muss ich diesen aufrufen? einfach am ende das OB1? Wie muss ich diesen dann beschalten? Habe mir den Baustein mal in der Hilfe angesehen und steige dort nicht wirklich durch.

Beste Grüße
Hagen

 

[vollmi]

Welchen OB fordert denn die CPU an? Das siehst du im Diagnosebuffer.

mfG René

 

[Mich89]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi!

Ich hoffe du hast den OB87 auch in die CPU geladen, und nicht nur angelegt ^^

Wenn die CPU in Stop ist, könntest du unter Zielsystem->Baugruppenzustand (STRG+D) in der Diagnose nachlesen, ob dort ein OB vorgeschlagen wird, bzw was dort die Hilfe sagt.

mfG
Michael

 

[ThomasM]

Könnte natürlich auch sein, dass die CPU den OB86 (Baugruppenträgerausfall) fordert und nicht den OB87.
Ich hab leider grad kein Step7 da um mir den SFC12 anzuschauen, hatte den nur noch irgendwo in den Grauen Zellen gespeichert.

Gruß ThomasM

 

[S7Anfänger]

Natürlich habe ich den OB87 auch in die CPU geladen.

Ich habe hier mal ein par Bilder von den Fehlermeldungen. Vielleicht helfen die ja weiter.

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da siehst du doch welcher ob ihm noch fehlt. Da du auf die peripherie zugreifst und diese nicht vorhanden ist fordert er noch OB122 an.
Es ist übrigens sinnvoll auch mal die Uhr zu stellen, dies hilft später bei der Fehlersuche wenn man nicht alles zurückrechnen muss.

mfG René

 

[S7Anfänger]

Der OB 122 hat geholfen. Bin zumindest im RUN.

Vielen dank für die Hilfe

 

[MSB]

Im Prinzip solltest du auch noch OB82/86 mit einfügen.

Außerdem kannst du den Altivar auch relativ sicher mit externen 24V versorgen, wodurch das Busmodul unabhängig von der Leistungsteilversorgung wird, und dein Problem in der Form gar nicht erst entstehen würde.

Mfg
Manuel

 

[Typson]

Zuviel Werbung?
-> Hier kostenlos registrieren

Noch ein kleiner Hinweis:

Der OB122 wird nur aufgerufen wenn du mit z.b. PEW/PAW direkt auf die Peripherie zugreifst ( das macht dein FC3 an Bausteinadresse 24). Das ist keine schöne Art der Programmierung, daher wird der OB122 oft von Maschinenbtreibern verboten. Entweder du schiebst die E/As deiner ET200s in das OB1-Prozessabbild und greifst mit EW/AW zu oder noch besser symbolisch.

 

[vollmi]

Der OB122 wird nur aufgerufen wenn du mit z.b. PEW/PAW direkt auf die Peripherie zugreifst ( das macht dein FC3 an Bausteinadresse 24). Das ist keine schöne Art der Programmierung, daher wird der OB122 oft von Maschinenbtreibern verboten. Entweder du schiebst die E/As deiner ET200s in das OB1-Prozessabbild und greifst mit EW/AW zu oder noch besser symbolisch.

Soweit kommts noch, das einem jemand anders Verbietet einen OB einzusetzen.
Und wieso ist das eine schlechte art der Programmierung auf die Peripherie zu schreiben? ggf will man ja ein aktualisiertes Resultat haben.
Und ob man Symbolisch programmiert hat keinen Einfluss darauf ob man auf Prozess oder Peripherie zugreift.

mfG René

 

[PN/DP]

@vollmi
*ACK*

Harald

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist keine schöne Art der Programmierung, daher wird der OB122 oft von Maschinenbtreibern verboten.

Das halte ich für ein Gerücht - oder verwechselst Du da was, vielleicht mit OB121?

Und kleiner Hinweis: Wenn der Profinet-Teilnehmer schon beim Einschalten der SPS fehlt, dann geht es fast gar nicht ohne OB122, weil OB86 gar nicht kommt. Dann dürfte das SPS-Programm erst nach einer Teilnehmer-Diagnose auf den Teilnehmer zugreifen. Die E/A-Adressen ins Prozessabbild verschieben bringt im Grunde auch nichts, weil dann wird statt OB122 der OB85 angetriggert.

Harald

 

[Typson]

Soweit kommts noch, das einem jemand anders Verbietet einen OB einzusetzen.

Soweit ist es doch schon lange und es wird immer schlimmer.
Der OB121 (Programmierfehler) ist zumindest bei Daimler und VW verboten.
Der OB122 darf nur mit Sonderfreigabe eingesetzt werden, z.B. wenn durch den Prozess ein Teilnehmer abgeschalten wird (Wechselgreifer am Roboter). Es werden die Diagnose-OBs 82,83,86 verwendet.
Bei vielen anderen Konzernen wird da nicht so genau hingeschaut, hauptsache die SF-Lampe ist und bleibt aus.
Da ich mich selten in anderen Branchen als Automotiv und Batterien bewege, weiß ich nicht wie das z.B. bei einem Klärwerk gehandhabt wird.

Und wieso ist das eine schlechte art der Programmierung auf die Peripherie zu schreiben? ggf will man ja ein aktualisiertes Resultat haben.

Sagen wir: "Man sollte es vermeiden." Wenn du nicht gerade eine Reglung machst und den Prozesswert mehrmals in einem Zyklus brauchst, dann brauchst du doch auch den direkten Zugriff nicht. Bei Busausfall hast du den Nachteil, dass bei jedem Zugriff auf den Teilnehmer der OB122 aufgerufen wird. Das kann schnell zu Zykluszeitproblemen führen.
Gibt es einen Vorteil für direkten Zugriff ausser, dass man den Datenbereich nicht im Prozessabbild definieren muss?

Und ob man Symbolisch programmiert hat keinen Einfluss darauf ob man auf Prozess oder Peripherie zugreift.

Du hast Recht, man kann auch in der Symboltabelle angeben, dass ein direkter Zugriff erfolgen soll (PEW/PAD).
Das war mehr ein Hinweis, dass man zusätzlich zur Vermeidung von direkten Zugriffen gleich symbolisch programmieren könnte... aber das ist wohl eher Geschmackssache.

 

[vollmi]

Soweit ist es doch schon lange und es wird immer schlimmer.
Der OB121 (Programmierfehler) ist zumindest bei Daimler und VW verboten.
Der OB122 darf nur mit Sonderfreigabe eingesetzt werden, z.B. wenn durch den Prozess ein Teilnehmer abgeschalten wird (Wechselgreifer am Roboter). Es werden die Diagnose-OBs 82,83,86 verwendet.
Bei vielen anderen Konzernen wird da nicht so genau hingeschaut, hauptsache die SF-Lampe ist und bleibt aus.
Da ich mich selten in anderen Branchen als Automotiv und Batterien bewege, weiß ich nicht wie das z.B. bei einem Klärwerk gehandhabt wird.

Nun mir fällt einfach kein Vernünftiger Grund warum man egal welchen OB verbieten sollte.
Will man eine CPU in Stop überführen kann man das auch im OB machen, hat dann aber noch die Möglichkeit Das Fehlerabhängig zu machen.
Wie will man sonst im Fehlerfall eine Maschine im Tipbetrieb weiterfahren?
Und wenn man darauf besteht das die SF Lampe aus bleibt solange die CPU rennt hat man das Konzept des Systems einfach nicht verstanden. Sorry dann ist der Regelersteller ein Depp. Das kann man ihm ja auch mitteilen, vielleicht etwas Gefühlvoller.

Mit solchen komischen Verboten oder Geboten schränkt man ja nur den Entwickler ein, ohne irgendeinen Gewinn davon zu haben.

Sagen wir: "Man sollte es vermeiden." Wenn du nicht gerade eine Reglung machst und den Prozesswert mehrmals in einem Zyklus brauchst, dann brauchst du doch auch den direkten Zugriff nicht. Bei Busausfall hast du den Nachteil, dass bei jedem Zugriff auf den Teilnehmer der OB122 aufgerufen wird. Das kann schnell zu Zykluszeitproblemen führen.
Gibt es einen Vorteil für direkten Zugriff ausser, dass man den Datenbereich nicht im Prozessabbild definieren muss?

Der Vorteil wäre z.B. einen aktualisierten Zustand.
Es geht auch nicht darum es geht darum das es durchaus Sinn machen kann. Aber ob es Sinn macht kann man...
1. nicht pauschal sagen
2. Sicher keinem nicht Programmierer überlassen
3. schon garnicht als allgemeine Regel.

Der Programmierer sollte halt wissen warum und wann er so programmieren will. Aber Schlecht ist der Stil dadurch ganz bestimmt nicht. Schlecht ist der Stil erst wenn man nicht weiss was man da warum tut. Aber man sollte dann auch wissen warum man etwas ins Prozessabbild nimmt und warum nicht.

Du hast Recht, man kann auch in der Symboltabelle angeben, dass ein direkter Zugriff erfolgen soll (PEW/PAD).
Das war mehr ein Hinweis, dass man zusätzlich zur Vermeidung von direkten Zugriffen gleich symbolisch programmieren könnte... aber das ist wohl eher Geschmackssache.

Ich bin durchaus der Meinung das die Symbolische Programmierweise die vorzuziehende ist und es eigentlich keinen Grund gibt Programmintern etwas absolut zu adressieren. Aber dieses Thema hat einfach so überhaupt nix mit dem Tread zu tun.

Und um nochmal zu den OBs zurückzukommen. Gilt das OB verbot deiner Vorgesetzten auch für die 1500er Generation? Dann frag sie mal warum!

mfG René

 

[Typson]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nun mir fällt einfach kein Vernünftiger Grund warum man egal welchen OB verbieten sollte.

Der Grund ist ganz einfach:
Der Maschinenbetreiber (z.B. Mercedes) geht richtiger Weise davon aus, dass man diese OBs vermeiden kann, wenn man sich ans Lastenheft hält, welches für Software ca. 2500Seiten hat. Mit dem Verbot der OBs bzw. Kontrolle der SF-Lampe (und das sind nur 2 von ca. 100 Checklisten-Punkten) kann man schnell erkennen, ob die Programmierrichtlinien des Lastenhefts eingehalten wurden und die Software dem Kundenwunsch entspricht.
Ja, die Kreativität des Programmierers wird eingeschränkt, aber genau das ist notwendig wenn 3 Jahre später die eigene Instandhaltung an die Maschine ran muss...

Wie will man sonst im Fehlerfall eine Maschine im Tipbetrieb weiterfahren?

Wenn die CPU in Stop geht hast du verloren. Todesurteil!
Du musst tatsächlich alle möglichen Fehler vermeiden oder abfangen. Die Projekte sind dementsprechend aufwendig.

Gilt das OB verbot deiner Vorgesetzten auch für die 1500er Generation? Dann frag sie mal warum!

Bisher werden die Maschinen nach mit S7-Classic bestellt. Das dauert ne Weile bis TIA in den Konzernen angekommen ist. Daher weiß ich dahingehend noch nichts.
Passt zwar auch nicht zum Thema, aber: Wieso? Ist da was besonderes anders?

 

[vollmi]

Der Grund ist ganz einfach:
Der Maschinenbetreiber (z.B. Mercedes) geht richtiger Weise davon aus, dass man diese OBs vermeiden kann, wenn man sich ans Lastenheft hält, welches für Software ca. 2500Seiten hat. Mit dem Verbot der OBs bzw. Kontrolle der SF-Lampe (und das sind nur 2 von ca. 100 Checklisten-Punkten) kann man schnell erkennen, ob die Programmierrichtlinien des Lastenhefts eingehalten wurden und die Software dem Kundenwunsch entspricht.

Nun dann sind die Programme sehr sehr klein.
indem man OBs und SF Lampe überprüft kann man genau garnix erkennen wie das Programm programmiert wurde.
Ein OB kann ja jederzeit durch einen Programmierfehler ausgelöst werden der vielleicht erst in einigen Jahren auftritt z.B. weil ein Pointer durch ein Datum falsch gesetzt wird.

OBs und SF Leuchte sind wichtige Werkzeuge. Diese zu verbieten mit dem Gedanken das man so eine Fehlerquelle beseitigt ist ein ganz ganz übler Trugschluss.

Ja, die Kreativität des Programmierers wird eingeschränkt, aber genau das ist notwendig wenn 3 Jahre später die eigene Instandhaltung an die Maschine ran muss...

Gerade die Instandhaltung sollte über eine Durchdachte Fehlerauswertung mithilfe der OBs jubeln.

Du musst tatsächlich alle möglichen Fehler vermeiden oder abfangen. Die Projekte sind dementsprechend aufwendig.

Und die Programme müssen entsprechend klein sein. Wie man z.B. ein 16 MB Programm durchtestet das man sichersein kann dass da kein Fehler drin ist, ist mir schleierhaft. Und wegen eines Fehlers z.B. eines Treibers für die Energiedatenauslesung eines Energiezählers lasse ich doch keine Produktive Maschine in stop gehen. Da schreibe ich mithilfe des OBs das Ereignis aus. Die CPU lass ich möglicherweise in Stop gehen wenn die Auswertung einen Fehler im Maschinenkritischen Bereich liefert.

Bisher werden die Maschinen nach mit S7-Classic bestellt. Das dauert ne Weile bis TIA in den Konzernen angekommen ist. Daher weiß ich dahingehend noch nichts.
Passt zwar auch nicht zum Thema, aber: Wieso? Ist da was besonderes anders?

die 1500 er gehen von sich aus nicht so schnell in Stop, die muss man aktiv in Stop überführen wenn man es für angebracht hält.

mfG René

 

[Typson]

indem man OBs und SF Lampe überprüft kann man genau garnix erkennen wie das Programm programmiert wurde.
Ein OB kann ja jederzeit durch einen Programmierfehler ausgelöst werden der vielleicht erst in einigen Jahren auftritt z.B. weil ein Pointer durch ein Datum falsch gesetzt wird.

Nunja, man kann schon was erkennen, aber bei weitem nicht Alles. Dafür gibt es dann die anderen 98 Punkte auf der Checkliste. Und auch danach gibt es noch viele Fehlermöglichkeiten. So große Programme mit 16MB gibt es da natürlich nicht, ich schätze mal max. 2MB.
Und ja, es passiert regelmäßig (bei mir zum Glück noch nie), dass beim Scannen eines DMCs die CPU während der Produktion in Stop geht. Das ist die Konsequenz wenn der Programmierer dem Druck des Kunden nachgibt ohne zu wissen was er da eigentlich tut.

Einigen wir uns also beim OB121 auf "anwendungspezifisch einzusetzen"