Anlauf IPC 427C schlägt fehl

[pretender2009]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein Hallo ans Forum,

hat evtl. jemand einen Tipp für folgendes Problem:

SIEMENS IPC 427C, mit PN-Peripherie. Ein Teilnehmer wird über den SFC12 (D_ACT_DP) An- bzw. Abgemeldet. Funktioniert tadellos. Ist jedoch der Teilnehmer Abgemeldet und physikalisch nicht vorhanden und die SPS geht in STOP oder soll von STOP nach RUN bewegt werden, läuft die SPS nicht hoch.
Der Haken in der HW-Config unter Eigenschaften CPU, Reiter Anlauf: Anlauf bei Sollausbau ungleich Istausbau ist gesetzt.
Was gibt es noch für Einstellungen oder Parametrierungen, welche getätigt werden müssten, damit die Anlaufprobleme nicht auftreten?

Danke im Voraus.

pretender2009

 

[borromeus]

Was ist denn genau die Diagnose im Diagnosepuffer?

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich mutmaße jetzt mal:
Bei Stop->Run werden die deaktivierten Teilnehmer auf jeden Fall wieder aktiviert (100% Sicher)

Also wirds vermutlich an einem nicht vorhandenen OB82/86/122 liegen.

Mfg
Manuel

 

[pretender2009]

Hallo borromeus,

genau das ist u.a. ein Problem, der Diagnosepuffer wird nicht beschrieben, da die CPU im Hochlauf stecken bleibt.
Der Teilnehmer ist im beschriebenen Fall (physikalisch) nicht vorhanden, die CPU will ihn jedoch hardwaremässig einlesen. Im Normalbetrieb funktioniert die An-/Abmelderoutine über den SFC12 wie in der Dokumentation (SIEMENS) beschrieben. Wird der Teilnehmer physikalisch mit dem Netz verbunden, dann läuft die CPU ganz normal hoch, ohne eben nicht.

pretender2009

 

[borromeus]

OK, sonderbar... mit "steckenbleiben" fange ich nichts an. Kenne ich nicht.
Ich dachte sie geht im Anlauf auf Stop..... und wenn sie dies macht schreibt sie auch warum.

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das alles ist mit den entsprechenden OBs im Normalfall kein Problem.
Das im Diagnosepuffer nichts steht glaub ich dir ganz einfach nicht.

 

[pretender2009]

Hallo MSB,

der OB86 ist vorhanden und das Verhalten der CPU entspricht dem von mir geschilderten. Die CPU kommt über den Anlaufmodus nicht hinweg.

pretender2009

 

[rostiger Nagel]

Die Soft-SPS läuft auch bei nicht vorhandenen Teilnehmern hoch, wenn
die endsprechenden Fehler OBs vorhanden sind. Schau dir doch noch einmal den Diagnosepuffer an.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das alles ist mit den entsprechenden OBs im Normalfall kein Problem.
Das im Diagnosepuffer nichts steht glaub ich dir ganz einfach nicht.

Möglicherweise einer der "Vorteile", siehe anderen Thread, den die Soft-SPS'n mit sich bringen.

 

[borromeus]

Aber irgendwas muss ja drinnenstehen:
CPU anklicken und Ctrl D

Lasche Diagnosepuffer

 

[Onkel Dagobert]

..Wird der Teilnehmer physikalisch mit dem Netz verbunden, dann läuft die CPU ganz normal hoch, ohne eben nicht..

Hast du lange genug gewartet? Wenn ein Teilnehmer fehlt, dann dauert es erheblich länger, bis die CPU in Run geht. Eine Minute (gefühlte zwei Minuten) sollte man schon warten. Jedenfalls ist es bei Profibus-DP so.

 

[pretender2009]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Onkel Dagobert,

ja auch das zeitliche Verhalten wurde berücksichtigt.

Mittlerweile habe ich parallel mal bei SIEMENS nachgefragt. Hier die Aussage dazu:

Handbuch System- und Standardfunktionen für S7-300/400 Band 1/2"
In Kap. 16.3 auf Seite 299 finden Sie den Hinweis zum Verhalten der SFC bei CPU Anlauf.
(OB 85-Aufruf bei Peripheriezugriffsfehler)

Mal sehen obs damit klappt.

pretender 2009

 

[MSB]

All das würde, wenn überhaupt dann schon im Diag-Puffer stehen.

Mfg
Manuel

 

[rostiger Nagel]

ich kann garnicht verstehen warum er nicht in den Diagnospuffer schaut, dazu brauch
er ja nicht mal ein PG, das kann er ja direkt auf dem IPC.

Ich habe hier im Büro auch einen IPC, wo ich 9 Profibus Teilnehmer Parametriert habe,
aber nicht gesteckt, die CPU läuft einwandfrei an und ballert den Diagnospuffer voll.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

beratungsresistent
;-)

 

[pretender2009]

Hallo an alle USER,

Problem ist gelöst. Hier die Rückmeldung:

• Also, wie bereits beschrieben, der Diagnosepuffer sagte nichts über die Ursache des fehlerhaften Anlaufes aus. Ohne den PN-Teilnehmer blieb die CPU im Anlaufmodus hängen (SF-LED = Dauerlicht, RUN/STOP-LED = Blinkend), unendlich.
• Da es sich um einen Fehler handelte, welcher nicht nur an einer CPU auftrat, lag es nahe, dass es sich um eine Einstellung in der Hardware etc. handeln musste.
• Der entscheidende Tipp kam aus Österreich (siehe Abb.). Der Parameter "Überwachungszeit für Fertigmeldung durch Baugruppen" war das Übel. Einstellung auf 100 vorgenommen, keine gestörtes Anlaufverhalten mehr.

Auf alle Fälle Danke für all die Hinweise zur Problematik. Ach ja, ich bin nicht beratungsresistent. Aber wenn die erforderlichen Informationen (im Diagnosepuffer) nicht vorhanden sind, ...


pretender2009

 

[rostiger Nagel]

schön das du es gelöst hast, aber Beratungsresitent bist du wirklich, weil irgendwas brauchbares steht
immer im Diagnosepuffer und mit dieser Informationen, kann sich der geübte User ein Bild machen.

 

[pretender2009]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo "rostiger Nagel",

sicher, es stand etwas im Diagnosepuffer, nur nichts entscheidendes zu diesem Anlaufproblem. Selbst bei SIEMENS konnte keine Aussage nach zugestelltem Testfile des Diagnosepuffer getätigt werden.

pretender2009

 

[rostiger Nagel]

Auch bei Siemens kannst du mal eine Niete ziehen.

 

[borromeus]

Korrigiere, wenn gestattet :
Selbst bei Siemens kann man mal keine Niete ziehen.