TIA OB100 LED bestimmte Zeit "True"

[Ufreeg]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Kollegen,

ich mochte an einer S7-300 im OB100 bei SPS Start 2 LED für (60sek) auf TRUE setzen. Danach soll er ganz normal in OB springen.
Mein Lösungsanfang mal auf dem Bild, aber irgendwie funzt das nicht.

Ich arbeite mit Zähler und Taktmerker.

Vielleicht kann mir jemand nen weiteren Lösungsansatz geben.
Geht so etwas überhaupt im OB100???

 

[DeltaMikeAir]

Geht so etwas überhaupt im OB100

Nein, der OB100 wird ja auch nur einen Zyklus aufgerufen und dann nicht mehr bearbeitet.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danach soll er ganz normal in OB springen.

Du solltest dich mit der Arbeitsweise einer zyklischen Steuerung einmal beschäftigen.

 

[de vliegende hollander]

OB 100 wird nur 1 mal bearbeitet.

Der Code ist auch viel zu aufwendig.
Benutze den Impuls Timer

 

[DeltaMikeAir]

Erzeuge einen Anlaufmerker ( OB100 Merker setzen und im OB1 ganz unten im Code zurücksetzen ). Dann kannst du mit diesem Merker mit einer Ausschaltverzögerung verknüpfen ( nicht im OB100 )

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mal vom Sinn der Maßnahme abgesehen.

Du könntest im OB 1 den Zähler plazieren und solange der Zähler kleiner 60 ein BEB (Bausteinende bedingt) ausführen.
In AWL :

U Mx.y
BEB

Gibt sicher auch eine KOP-Anweisung dafür.

Alle Anweisungen danach werden dann nicht mehr ausgeführt.
Rücksetzen des Zählers im OB100, bei Start der SPS. (Mal testen, ich weiß jetzt nicht, ob der R-Input des Zählers eine Flane benötigt, dann wird das im OB 100 evtl. nichts!)

 

[Martin Glarner]

Ich löse dies so im OB100 um eine Anlaufverzögerung zu realisieren. Eine LED kann aber erst nach dem OB100 angesteuert werden, somit funktioniert es mit meiner Lösung nicht.

// Startzeit auslesen
#l_iRET_VAL := RD_SYS_T(#l_dtlStartzeit);

REPEAT
// Aktuelle Uhrzeit auslesen
#l_iRET_VAL := RD_SYS_T(#l_dtlAktuell);

// Schleife wiederholen, solange die vorgegeben Anlaufverzögerung noch nicht erreicht wurde
UNTIL #l_dtlAktuell - #l_dtlStartzeit > #e_Zeitverzögerung END_REPEAT;

 

[DeltaMikeAir]

Ich löse dies so im OB100 um eine Anlaufverzögerung zu realisieren

Interessehalber, für was benötigt man dies?

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Interessehalber, für was benötigt man dies?

Wir benutzen auch so ein Art von Anlaufverzögerung.
Es ist ein verlängerte FirstCycle bit.

Nach z.b einschalten der Anlage läuft nicht alles in der gleiche Zeit hoch. z.b. bei uns der Überdrehzahlschutz.
Die Kontakten des üSchutz werden aber im Programm verwendet um Antrieben ein/ aus zu schalten.
Dies wird für die Zeit dann unterbunden.

Da gibt es bestimmt viele ähnliche Anwendungen

 

[rostiger Nagel]

Mir fehlt einfach das Verständnis, die Anlauf OB‘s so zu
verbiegen. Man kann doch Auswertungen im Zyklischen
Programm so gestalten, das es nicht erforderlich ist.

 

[Onkel Dagobert]

Mir fehlt einfach das Verständnis, die Anlauf OB‘s so zu
verbiegen..

"verbiegen"? Mal 'ne Frage in die Runde, wofür ist denn ein Anlauf-OB gedacht?

Es gibt Fälle, "de fliegende hollander" nannte es schon, da sind bei Netzwiederkehr bestimmte Baugruppen noch nicht bereit, während die Abarbeitung des zyklischen Programms bereits beginnt. Ich hatte vor langer Zeit solch einen Fall mal bei einer S7300 in Verbindung mit einen seriellen CP. Die CPU ging beim Neustart/Wiederanlauf auf Stopp, weil der CP noch nicht bereit war. Und vor ca. drei Jahren eine S7-1500, die mit dem zyklischen Betrieb nicht auf die Bereitschaft ihrer IO-Devices (ET200SP mit reichlich analogen Klemmen) warten wollte und schon mal vorzeitig mit dem Programm begann. Das ist so ähnlich, wie wenn die Bahn schon losfährt, während die Fahrgäste noch einsteigen. Diverse Einstellungen halfen hier nicht. Im letzteren Fall hatte ich übrigens viele Stunden investiert, um dem Seelsorger vom Callcenter das Problem zu erklären. Bin leider nur auf Inkompetenz und Desinteresse gestoßen. Vielleicht hatte ich aber auch nur die falsche Nummer gewählt.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die CPU ging beim Neustart/Wiederanlauf auf Stopp, weil der CP noch nicht bereit war.

Man kann doch in der HW Konfig die Wartezeit einstellen, bis wann alle konfigurierten Teilnehmer ansprechbar sein müssen bevor es eine Systemreaktion gibt

 

[DeltaMikeAir]

Die CPU ging beim Neustart/Wiederanlauf auf Stopp, weil der CP noch nicht bereit war.

Bringt da eine OB100 Verzögerungsschleife da überhaupt etwas, die CPU ist doch schon in RUN und es müsste auch so ein Systemfehler kommen.

 

[DeltaMikeAir]

Und vor ca. drei Jahren eine S7-1500, die mit dem zyklischen Betrieb nicht auf die Bereitschaft ihrer IO-Devices (ET200SP mit reichlich analogen Klemmen) warten wollte und schon mal vorzeitig mit dem Programm begann

Auch hier kann man die maximale Wartezeit in der HW Konfig einstellen bzw. verlängern. Dann lässt sie sich mehr Zeit wenn ein Teilnehmer noch nicht erreichbar ist, bevor sie in RUN übergeht.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Onkel Dagobert,
führt für mich zu keinen Verständnis, ich kann den Zugführer
doch sagen das er etwas später losfahren soll bzw. Ein Zeitglied
vor der Auswertung.
Ich nutze die Anlauf OB´s um Voreinstellungen zu machen,
Zeiger auf Register schon einmal vor einzustellen oder irgend
etwas zurück zusetzen.

 

[DeltaMikeAir]

Ein Zeitglied
vor der Auswertung

Ich nutze auch einen Timer für verzögertes Betriebsbereit...

Aber viele Wege führen nach Rom

 

[DeltaMikeAir]

Man kann doch in der HW Konfig die Wartezeit einstellen, bis wann alle konfigurierten Teilnehmer ansprechbar sein müssen bevor es eine Systemreaktion gibt

Dieses Feld meinte ich:


Aus der Hilfe:

Überwachungszeit für:
Fertigmeldung durch Baugruppen (100 ms):

Maximale Dauer für die Fertigmeldung aller konfigurierten zentralen Baugruppen nach NETZ-EIN. Wenn nach Ablauf dieser Überwachungszeit die Baugruppen keine Fertigmeldung zur CPU senden, ist der Istausbau ungleich dem Sollausbau. Die Reaktion der CPU wird daher bestimmt vom Parameter "Anlauf bei Sollausbau ungleich Istausbau".
Innerhalb dieser Überwachungszeit können z. B. bei mehrzeiligem Aufbau oder bei Geräten, die über die DP-Master-Schnittstelle an die CPU angeschlossen sind, alle Stromversorgungen eingeschaltet werden, ohne daß eine Einschalt-Reihenfolge beachtet werden muß.

Übertragung der Parameter an Baugruppen (100 ms):

Maximale Dauer für die "Verteilung" der Parameter an die parametrierbaren zentralen Baugruppen (Zeit beginnt nach "Fertigmeldung durch Baugruppen (ms)"). Bei CPUs mit DP-Master-Schnittstelle stellen Sie mit diesem Parameter auch die Hochlaufzeitüberwachung der DP-Slaves ein. D.h., in der eingestellten Zeit müssen die DP-Slaves hochlaufen und von der CPU (als DP-Master) parametriert sein.
Wenn nach Ablauf dieser Überwachungszeit nicht alle Baugruppen/DP-Slaves parametriert sind, ist der Istausbau ungleich dem Sollausbau. Die Reaktion der CPU wird daher bestimmt vom Parameter "Anlauf bei Sollausbau ungleich Istausbau".

Wiederanlauf (100 ms):

Nicht relevant für S7-300.
Bei S7-400: Wenn die Zeit zwischen NETZ-AUS und NETZ-EIN oder die Zeit zwischen einem STOP-RUN-Übergang länger ist als die eingegebene Zeit, findet bei SIMATIC 400 kein Wiederanlauf statt.
Die CPU verbleibt bzw. geht in diesem Fall in den Stop-Zustand.
Der Wert "0" bedeutet: keine Überwachung.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Delta, vielen Dank für deine Tipps. Die Einstellmöglichkeiten in der Hardware sind mir natürlich bekannt, und ich habe auch viele probiert. Das genannte Beispiel mit der S7-300 liegt schon zwanzig Jahre zurück. Ich würde einräumen, das vielleicht auch nicht mehr so ganz genau in Erinnerung zu haben. Aber das Ding mit der S7-1500 war schon sehr suspekt. Ich kann es euch nicht glaubhaft rüber bringen und probieren kann ich auch nicht mehr. Also glaubt es einfach oder lasst es bleiben.

 

[DeltaMikeAir]

Wie gesagt, viele Wege führen nach Rom. Es gibt immer mehrere Lösungswege.

Aufpassen muss man bei so einer Lösung z.B. auf einer H-CPU. In der zweiten CPU wird der OB100 nicht ausgeführt.

Abhängig vom Startereignis, von der vorliegenden CPU und deren eingestellten Parametern wird der zugehörige Anlauf-OB (OB 100, OB 101 bzw. OB 102) aufgerufen. Darin können Sie durch entsprechende Programmierung bestimmte Voreinstellungen für Ihr zyklisches Programm vornehmen (Ausnahme: Bei einem H-System wird nach dem Ankoppeln auf der Reserve-CPU ein Anlauf durchgeführt, jedoch ohne Aufruf eines Anlauf-OB).

 

[PN/DP]

Ich kenne solche Anlaufverzögerungen ohne Bearbeitung des eigentlichen SPS-Programms fast nur als dauerhafte Notlösungen, wo irgendwann festgestellt wurde daß der Power-On-Anlauf einzelner Anlagenteile etwas länger dauert und man keine Lust/Zeit hatte, an allen relevanten Stellen zusätzliche Verknüpfung(en) einzupflegen. So dauert pauschal jeder STOP-RUN-Übergang so lange wie bei einem Kaltstart nötig wäre. Und wehe, jemand schaltet den Anlagenteil während CPU in RUN aus und wieder ein...

Wie Martin Glarner schon hinwies: so eine Anlaufverzögerung kann nicht ausschließlich im OB100 gemacht werden, wenn man während der Anlaufzeit schon Baugruppen-Ausgänge steuern will. Die erste Zuweisung des PAA an die Baugruppen findet erst nach dem ersten OB1-Durchlauf statt.

Ob dem TE unsere Hinweise und Diskussion was nützen, werden wir wohl nie erfahren. Bisher hat er sich bei seinen Problemen nach der Eröffnungsfrage nie wieder gemeldet.

Harald