TIA Beim Hochlaufen der CPU alle Teilnehmer überprüfen

Outrider

Outrider

Level-1
Beiträge
745
Reaktionspunkte
5
Zuviel Werbung?
-> Hier kostenlos registrieren
wie kann ich im OB100 überprüfen ob alle Teilnehmer da sind, damit die CPU in RUN übergeht.
Bei einigen CPU's gibt es eine einstellbare Zeit in den Eigenschaften, das möchte ich aber nicht !
Es soll per Softwarelösung überprüft werden.
Gruß
 
Zuletzt bearbeitet:
CPU ? Welche Teilnehmer? Profinet oder Profibus? Per CP an der CPU oder direkt?
Da fehlen noch ein paar Angaben um helfen zu können.

Gruß Käse
 
Den OB100 per Diagnose-/Warte-Schleife um ..zig Sekunden bis Minuten verlängern ist ein sehr unübliches Vorgehen. Was soll das "nicht in RUN gehen wenn nicht alle Teilnehmer da sind" bringen? Hast Du spezielle Teilnehmer die sowas erfordern?
Die Teilnehmer können auch später im RUN ausfallen und auch damit muß Dein Programm klarkommen. Schickst Du die CPU dann in STOP? Die CPU in STOP schicken ist eine ziemlich unintelligente und endgültige Reaktion, sie nimmt jegliche Chance auf das Problem programmgesteuert zu reagieren.

Harald
 
@PN/DP
Die CPU wird zuerst eingeschaltet mit dem Hauptschalter (sei dahingestellt ob das Klug ist, ist aber Kundenvorgabe), danach gibt es ein Schlüsselschalter mit dem 24V geschaltet werden, somit auch die restlichen PN-Teilnehmer !
D.h. es kann schon dauern bis vom Schalten des Hauptschalters und des Schlüsselschalters Zeit vergeht.
Umgekehrt ist es aber auch so dass nur der Schlüsselschalter ausgeschaltet wird, und die CPU nicht in Stop gehen soll.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Outrider schrieb:
Umgekehrt ist es aber auch so dass nur der Schlüsselschalter ausgeschaltet wird, und die CPU nicht in Stop gehen soll.
Zum Vergrößern anklicken....
Dann werden alle PN-Teilnehmer ausfallen, Deine CPU wird aber nicht wieder in den OB100 gehen, weil sie ja schon in RUN ist. Das Warten im OB100 ist in dem Fall dann nutzlos.

Die S7-1500 kenne ich nicht genug, bei einer S7-300/400 würde ich mit SFC51 RDSYSST eine Teilnehmerdiagnose im OB1 programmieren und auf Teilnehmerausfälle reagieren, egal ob sie beim STOP/RUN-Hochlaufen fehlen oder später ausfallen.

Harald
 
Was passiert:
Die CPU geht in RUN, auf der CPU blinkt die rote Lampe, ergo nur ein optisches Problem.
Diagnose kannst du ganz normal im zyklischen Programm mit dem Baustein "DeviceStates" (Erweiterte Anweisungen - Diagnose) machen, und dann melden, Stoppen, oder sonstwas tun.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie die Hardware-Diagnose bei der 1500 geht, kannst du dir an dem Beispiel (wenn auch ewig aufgeblasen) anschauen...
https://support.industry.siemens.com/cs/ww/de/view/98210758

Da steht allerdings auch...
Anwendungsbeispiel schrieb:
Hinweis
Die Diagnose im Anwenderprogramm ist für Safety-Module nicht möglich
Zum Vergrößern anklicken....
Gute Frage was das heißt, denke das bezieht sich nur auf F-bezogene Zustände.

Wobei, wenn du nur den CPU-Stop beim Schlüsselschalter-Aus verhindern willst, reicht der leere OB auch schon.
 
Im OB1 oben erst abfragen ob alle Teilnehmer da sind und dein "Interner Anlauf" ansteht und wenn nicht alle Teilnehmer da sind den OB1 nicht weiter bearbeiten.
Wenn alle Teilnehmer kommunizieren den OB1 nicht mehr verlassen und am ende deinen "Internen Anlauf" zurücksetzten.

Gruß

Jens
 
DOD666 schrieb:
Im OB1 oben erst abfragen ob alle Teilnehmer da sind und dein "Interner Anlauf" ansteht und wenn nicht alle Teilnehmer da sind den OB1 nicht weiter bearbeiten.
Zum Vergrößern anklicken....
Sooo einfach wird das leider nicht funktionieren: Wenn irgendein Teilnehmer später ausfällt, dann auch den OB1 nicht mehr weiter bearbeiten und z.B. alle Antriebe so laufen lassen wie sie sind?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein Teilnehmerausfall muss natürlich auch im laufenden Betrieb weiter überwacht werden um adäquat darauf reagieren zu können.
Deswegen erst mal der Fall beim Anlauf.
Ich habe mich rein auf die Frage bezogen.

Gruß

Jens
 
Krumnix schrieb:
Erstell mal den OB86 und lad den rein. Wenn dieser nicht vorhanden ist, geht die CPU in Stopp.
Zum Vergrößern anklicken....
Bei einer 3/400er ja, bei einer 12/1500er ist das nicht mehr so, ein leerer OB ist also so sinn- wie nutzlos.

Praktisch würde ich hier nur die Meldung "Teilnehmer xxx" ausgefallen halt für Zeit x nach Schlüsselschalter Ein verhindern.
Danach hat ja ohnehin erstmal die Reintegration sämtlicher Safety-Baugruppen zu erfolgen, wobei das bei einem Kompletthochlauf der externen Station evtl. nicht mal nötig ist.
Den Anlagenstart kann man ja dann auch erst freigeben nachem alle benötigten Teilnehmer ihrerseits den Hochlauf beendet haben, feststellbar mit Device States.

Mfg
Manuel
 
Frage zum Thema

Die folgenden Grafiken zeigen die Defaulteinstellungen einer S7-1500 und (weil heute Sonntag ist ;-) )die dazugehörige Onlinehilfe.

2017-11-19_104900.png2017-11-19_114755.jpg

Ich habe an dieser Stelle ein kleines Verständnisproblem und hätte dazu gerne mal ein paar Meinungen von euch gehört.

Was macht die CPU nach Ablauf der eingestellten Parametrierungszeit, wenn die Kompatibilität aller Baugruppen gegeben ist, ein IO-Device jedoch aufgrund seines etwas umfangreicheren Ausbaus mit dem Hochlauf noch nicht fertig ist?

  1. Geht die CPU nach Ablauf der Parametrierzeit in RUN?
  2. Geht die CPU nach Ablauf der Parametrierzeit in STOP?
  3. Wartet sie bis alle Teilnehmer hochgelaufen sind und geht dann in RUN?

Vermutlich wird es so sein dass nach Ablauf der Zeit, noch nicht hochgelaufende Baugruppen als "nicht kompatibel" gewertet werden?

Was würde sich an den drei Punkten ändern, wenn "Anlauf der CPU nur bei Kompatibilität", die ja eigentlich gegeben ist, eingestellt wird?


@Outrider
Wie hast du deinen Fall gelöst?


Gruß, Onkel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast du irgendeinen Fehler vor dem Netzaus der dir deine CPU in STOP versetzt , kannst du die Maschine nicht einfach mit Neustart der Maschine neu starten. Du musst extra die CPU wieder manuell in RUN versetzen. Anfangs war das bei uns auch so eingestellt, bis ich mal nach England musste nur um die Maschine wieder zu starten ;)
Diese Wartezeit beschreibt Punkt 3, wenn ich mich nicht irre. Wenn du zum Beispiel Frequenzumrichter hast die auf eine interne 24V zurückgreifen und über BUS kommunizieren kann es eine Zeit dauern bis sie kommunikationsfähig sind nach Netz ein. Das kannst du mit der Wartezeit dann abwarten. Sonst würde die CPU in Stop gehen weil die Eingänge vom BUS fehlen und wenn Anlauf nur bei Kompatibilität eingestellt ist. Es wird aber die eingestellte Zeitabgewartet und nicht bis alle Teilnehmer da sind, beispielsweise nach 25s.
Wenn du jetzt einstellst Anlauf auch bei Nicht-Kompatibilität würde auch die CPU glaub in RUN gehen wenn nicht alle Teilnehmer vorhanden sind. Ist nur die Frage, ob sich dadurch nicht andere Probleme ergeben.
 
Credofire schrieb:
.. Wenn du jetzt einstellst Anlauf auch bei Nicht-Kompatibilität würde auch die CPU glaub in RUN gehen wenn nicht alle Teilnehmer vorhanden sind. Ist nur die Frage, ob sich dadurch nicht andere Probleme ergeben.
Zum Vergrößern anklicken....
Genau diese "anderen Probleme" habe/hatte ich. Die CPU geht nach den eingestellten 60s in RUN. Zwei etwas größere ET200SP-Anschaltungen benötigen offensichtlich etwas länger als 60s bis sie betriebsbereit sind. Aufgefallen ist es u.a. dadurch dass ein Quittierimpuls beim Anlauf nicht an der Hardware ausgegeben wurde, einfach deshalb, weil die Peripherie mit dem dig. Ausgang noch nicht bereit war. Ebenso wurden bei CPU-Anlauf zahlreiche Störmeldungen aktiv, weil bei CPU-Start die entsprechenden Eingänge fehlten. Diese Störmeldungen haben quasi ebenfalls den Quittierimpuls verpasst. Soweit die Theorie. An der Anlage bin ich demnächst wieder und teste das noch mal durch.
 
Ich bin jetzt noch nicht so der Crack. Ich vermute mal, dir bleibt erstmal nichts anderes als die Zeit hoch zu setzen.
Oder du deaktivierst diese Teilnehmer im Hochlauf und und aktivierst die Teilnehmer wieder wenn du weist das sie da sind. Aber damit hab ich auch noch kaum Erfahrung. Ich deaktiviere nur wenn Teilnehmer optional nicht da sind, oder fürs Büro.
Oder aber du wartest mit dem Quittieren bis du weist, dass alle Teilnehmer da sind. Quasi nach dem Schema Quittieren := NOT FirstRun AND TeilnehmerX.StatusOK ...
 

Similar threads

F
Step 7 Profinet Teilnehmer werden über Ethernet erreicht aber in Hardware Konfiguration sind diese "projektiert, aber nicht vorhanden"
Antworten
4
Aufrufe
418
DCDCDC
D
J
TIA Erreichbare Teilnehmer bei Benutzerwechsel checken
Antworten
12
Aufrufe
735
PN/DP
PN/DP
O
TIA CP1543-1 IPv4 Forwarding
Antworten
3
Aufrufe
521
DCDCDC
D
.K.
TIA PLCSIM V18 beim Laden werden keine Erreichbaren Teilnehmer gefunden
Antworten
10
Aufrufe
2K
ChristophD
ChristophD
M
TIA TIA findet meine CPU nicht
Antworten
18
Aufrufe
2K
DerStilleBeobachter
D
Zurück
Oben