Anlauf IPC 427C schlägt fehl

pretender2009

Level-1
Beiträge
68
Reaktionspunkte
6
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
 
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
 
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
 
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.
 
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
 
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.
 
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


 
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.
 
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





Eigenschaften.jpg
 
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.
 
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
 
Zurück
Oben