Synchronisationsaufgabe zweier ET200S in 2ms

merless · 6 Oktober 2009

Hallo Community,

Ich bin neu hier im Forum und hoffe mal, dass mir hier vielleicht jemand bei folgendem Problem helfen kann:

Ich suche nach einer Möglichkeit zwei Peripheriebaugruppen ET200S, genauer ET200S IM151-8 PN/DP CPU, miteinander zu synchronisieren. Beide haben die Aufgabe jeweils einen Geber auszulesen und den Werten entsprechend jeweils einen Aktor zu regeln. Beide Aktoren beeinflussen aber das selbe mechanische System. Auf beiden Prozessoren läuft im schnellsten OB (35) das gleiche Programm mit einer Zykluszeit von 2ms. Auf 1ms geht die CPU in den STOP - erstmal egal. Es gibt keine höherprioren Interrupts die den OB35 unterbrechen könnten.
Nun sollen diese Prozessoren aber zur selben Zeit ihren jeweiligen Geber auslesen, müssen das Programm also parallel abarbeiten. Die ET200 kommunizieren nämlich auch untereinander und brauchen beide zur selben Zeit die AKTUELLEN Werte der jeweils anderen ET. Das maximale Alter der Daten sollte also im Bereich der Datenlaufzeit über Profinet liegen, genauer über einen PN/PN-Coupler.
Die Kommunikation der beiden untereinander ist bereits realisiert und die Datenlaufzeit beträgt kleiner 1ms.
Kurzgesagt ich brauche eine Möglichkeit entweder mit Triggern untereinander oder Triggern von extern, beide OB 35 bzw. beide ET200s und damit deren Programmabarbeitung gleichzeitig zu starten.

Hat dazu jemand eine Idee? Für jede Anregung wäre ich dankbar. Bisher stellt es sich so dar, dass die beste Synchronisation mit +/- einem Zyklus machbar ist, was aber leider immernoch zu viel ist.

Ich hoffe mal ich habe nicht total verloren

Aber wenn jemand meint, es geht 100%ig nicht, dann auch mit Begründung eine Antwort hinterlassen

Dankeschön schonmal.

Gruß

merless

Bernard · 6 Oktober 2009

Mit dem OB 35 wird Dir das nicht gelingen.

Versuch es mit dem OB40 Interupt und der Baugruppe
6ES7 131-4BD01-0AB0.Diese Baugruppe kann auf Impuls eines Einganges dann den ob 40 starten.Die Syschronsierung erfolgt von extern mittelsTaktgenerator z.B 500 HZ.

merless · 6 Oktober 2009

Vielen Dank für die flotte Anwort Bernhard!

Diese Idee hatte ich auch schon. Habe hier ein 8DI DC24V 6ES7 131-4BF00-0AA0. Sollte damit ja auch gehen denke ich. Problem dabei ist, dass zwischen der Triggerung Werte verloren gehen können. Es müsste also so sein, dass der OB40 auf beiden ETs einmal getriggert wird und danach selbständig zyklisch weiterläuft. Soweit ich weiß ist dies aber nicht der Fall und der OB40 reagiert erst wieder bei neuer Triggerung. Trotzdem werde ich mir das nochmals genauer anschauen. Vielleicht kann ich synchronitätsrelevanten Code dahin auslagern und anderen eher zeitrelevanten Code weiterhin im OB35 belassen. Vorausgesetzt die CPU kommt damit von der Rechenleistung her klar.

Gruß

merless

Markus · 6 Oktober 2009

wie hast du das aufgebaut?
ich würde einen der antriebe als master und einen als slave definieren.

der master schickt zyklisch seinen positosistwert an den slave, und dieser muss sich selber darum kümmern diesem zu folgen. dann müsste der "regeltakt" nicht zwangsläufig synchron sein...

2ms ist schon flott, was hast du für aktoren? kommen die damit überhaupt zurecht?

Markus · 6 Oktober 2009

Markus schrieb:
der master schickt zyklisch seinen positosistwert an den slave, und dieser muss sich selber darum kümmern diesem zu folgen. dann müsste der "regeltakt" nicht zwangsläufig synchron sein...

wenn der slave zu weit hinten dran hängt, dann sollte das aber konstant sein. somit könntest du den schleppabstand reduzieren indem du auf den istwert vom master ( also sollwert vom slve) einen offset addierst. bzw. den p-regler etwas höher nimmst.

etwa so:

stellwert_slave = P(istpos_master - istpos_slave)

Bernard · 6 Oktober 2009

Ich glaube du bringst da etwas durcheinander.
Folgendes,der OB 40 hat eine Priorität von 16 der OB 35 von12 somit
wude der OB40 den OB 35 jederzeit Unterbrechen.Mit der Taktung auf 500HZ erzeugst du einen sysnchron Laufenden Pseudo_ob_1 innerhalb beider Syteme.Mehr Geschwindihkeit kannst mit dieser CPU Type sicherlich nicht erreichen.

Blockmove · 6 Oktober 2009

Also 2ms sind meines Erachtens schon sehr grenzwertig für eine S7 ET200S-CPU mit Profinet. Wieso müssen es überhaupt 2 CPUs sein? Kannst du das ganze nicht in eine einzige packen? Dann hättest du "nur" noch die Zykluszeit und den PN-Takt.

Gruß
Dieter

Bernard · 6 Oktober 2009

Also 2ms sind meines Erachtens schon sehr grenzwertig für eine S7 ET200S-CPU mit Prof

Die Summe der SPSen spielt keine Rolle,eine einzelne wir auch nicht schneller sein.
Zugegeben viel code kann man bei 2ms im OB 40 nicht erstellen

merless · 6 Oktober 2009

Hallo nochmal,

Dass der OB40 höhere Priorität hat als der OB35 hatte ich gar nicht bedacht! Da hast du recht.
Grenzwertig ist es, die 2ms. Aber ich komme nicht drum rum. Außer mit stärkerer und teurerer Hardware natürlich.
Die zu regelnden Geräte sind im übrigen Servoventile die durchaus in der Lage sind so schnell zu schalten und auch müssen.
Die Sensoren sind absolute Positionsgeber.
Zwei Prozessoren sind nötig, da das Programm das darauf läuft so schon ziemlich genau an die Grenze des machbaren stößt. Wie gesagt, wenn ich die Zykluszeit auf 1ms stelle stoppt die CPU. Wenn eine CPU also beide Sensoren auslesen müßte und beide Ventile regeln müßte würde die schnell ins straucheln kommen. Außerdem sollen die ETs im späteren Betrieb auch bestimmte Testmodi fahren, bei denen auf einer ein geringfügig anderer Code läuft als auf der anderen. Diese Cases sind aber bereits implementiert und funktionieren.
Viel Code naja... Ich habe fast alle externen Bausteine die während des Programmablaufs aufgerufen wurden in das Programm hart reingecodet. Dadurch wurde eine so kurze Zykluszeit überhaupt erst möglich. Wie gesagt klingt das mit dem OB40 zumindest so überzeugend, dass ich das morgen nochmals genauer prüfen werde. Zum Beispiel von der einen ET die dann weiterhin im OB35 läuft über einen DO auf die andere ET mit einem DI die im OB40 läuft. Wäre dann sowas wie eine Master-Slave-Verschaltung... Die eine triggert quasi die andere. Mal sehen mal sehen...
Aber danke an alle soweit! Wem noch was dazu einfällt immer gerne

Da hab ich noch eine andere Idee. Gibt es eine Möglichkeit die genau Programmlaufzeit herauszufinden? Das Programm läuft zwar in einer Zeitscheibe von 2ms sollte ja aber logischweise schon früher fertig sein und nicht genau 2ms brauchen... Mit der genauen Zeit könnte ich bei einer Programmlaufzeit von bspw. 1,78ms auch einen externen Trigger für den OB40 mit t=1,80ms auf beiden ETs einstellen statt glatten 2ms. Nur befürchte ich, dass alles was in dieser Hinsicht zu messen ist nur mit einer Auflösung von 1ms machbar ist. Mit Timern o.ä... Da eine Idee?

Gruß

merless

Bernard · 6 Oktober 2009

Also 2ms sind meines Erachtens schon sehr grenzwertig für eine S7 ET200S-CPU mit Prof

ich würde den Ob35 vergessen.Auch das Weitergeben eines Taktes,halte ich für Unklug.Nimm einen externen Takt beschalte, diesem Takt Pro SPS auf einen Interrupt fähigen Eingang.Schon hast du zwei sysnchron laufende Pseud

B_1 in den SPSen.Wenn du den Takt nur weitergibst und über DO/DI arbeitest,also über die Prozessabilder werden deine Programme niemals sysnchron sein.Ausserdem ist die maximale Reaktionszeit auf eine Eingangsänderung 2 Zyklen lang.
Zum auslesen der Laufzeiten eines Zykluss kann man relativ gut SFC64 verwenden.Allerdings nicht bei diesen Kleinen Zeiten und dieser doch recht langsammen SPS.

Blockmove · 6 Oktober 2009

Bernard schrieb:
Die Summe der SPSen spielt keine Rolle,eine einzelne wir auch nicht schneller sein.
Zugegeben viel code kann man bei 2ms im OB 40 nicht erstellen

Der Synchronisationsaufwand entfällt. Du kannst die Geber zyklisch einlesen. Bist also quasi taktsynchron.
Das ganze auf einer schnellen CPU (317 oder evtl. Vipa) sollte bei entsprechender Programmierung eine konstante und kurze Zykluszeit ergeben.
Somit kann evtl. auch die Alarmbearbeitung entfallen.

Gruß
Dieter

Bernard · 6 Oktober 2009

Der Synchronisationsaufwand entfällt. Du kannst die Geber zyklisch einlesen. Bist als

Ich geh mal davon aus das Die SPSen schon vor Ort sind.

merless · 7 Oktober 2009

Das ist richtig, die SPSen sind schon hier.

Bzgl. dem Interrupt über den DI habe ich nun vor Ort erkannt, dass die 8DI DC24V keine Möglichkeit bietet einen Hardware-Interrupt auszulösen. Mal sehen ob ich irgendwo die von Bernard empfohlene 4DI DV24V HF herbekomme. Glaube ich aber eher weniger

Habe hier aber eine Analogbaugruppe 2AI 4Wire HS die die Möglichkeit von Hardware-Interrupts bietet. Vielleicht lässt sich das damit bewerkstelligen...

Bernard · 7 Oktober 2009

Die kann es auch nicht
2AI 4Wire HF Könnte es

merless · 7 Oktober 2009

In den Properties der HS gibt es aber einen eigenen Reiter unter "Parameters" der "Hardware Interrupt" heißt. Konnte das aber heute noch nicht testen.

Bernard · 7 Oktober 2009

Endschuldige du hast recht!

merless · 19 Oktober 2009

Hi,

Bin nun dazu gekommen, es über die analoge Karte zu realisieren. Ich frage mich nun allerdings, wie das mit dem OB40 ist. Wenn der getriggert wird bevor das Programm fertig abgearbeitet ist, wird dann ein Fehler ausgegeben? Oder startet der einfach von vorne? Ich versuche nämlich gerade herauszufinden, ob der OB40 wirklich dem Triggertakt folgt oder nicht.

Gruß

merless

P.S. und danke nochmal für die Hilfe bisher!

rostiger Nagel · 19 Oktober 2009

merless schrieb:
Hi,

Bin nun dazu gekommen, es über die analoge Karte zu realisieren. Ich frage mich nun allerdings, wie das mit dem OB40 ist. Wenn der getriggert wird bevor das Programm fertig abgearbeitet ist, wird dann ein Fehler ausgegeben? Oder startet der einfach von vorne? Ich versuche nämlich gerade herauszufinden, ob der OB40 wirklich dem Triggertakt folgt oder nicht.

Gruß

merless

P.S. und danke nochmal für die Hilfe bisher!

Verhalten von Prozessalarmen.
Auslösung bei S7-300
Tritt während der Bearbeitung eines Prozessalarm-OBs ein Ereignis ein,
das den gerade bearbeiteten Prozessalarm erneut auslösen würde, geht
der Prozessalarm verloren, wenn das Ereignis nach der Quittierung nicht
mehr ansteht. Hierbei spielt es keine Rolle ob das Ereignis von der Bau-
gruppe kommt, deren Prozessalarm gerade bearbeitet wird, oder von einer
anderen Baugruppe.

merless · 26 Oktober 2009

Ich habe jetzt zwei 2DI DC24V HF Baugruppen hier (Order#: 6eS7 131-4BB01-0AB0) und schalte eine Flanke auf. Habe in der HWKonfig auch soweit die Interrupts eingestellt. Es tut sich am OB40 allerdings nichts. Laut Anleitung liegt das wohl an Folgendem:

Prozessalarm: Nur bei Interfacemodul IM151-1 HIGH FEATURE und IM151-7 CPU parametrierbar

Also falsche CPU? Das bedeutet dann wohl oder übel, dass auf der ET200S IM151-8 PN/DP CPU nur ein analoger Trigger möglich ist oder gibt es da eine Möglichkeit drumherum?

Gruß

P.S. das gilt wohl auch für die hier Empfohlene 4DI...

rostiger Nagel · 26 Oktober 2009

lt. Handbuch kann die IM151-8 PN/DP CPU Prozessalarm. Wie hast du denn
deine Alarmbeobachtung gemacht. Zyklisch beobachten ist da nicht.
Schreib doch mal eine Code in den OB40 wo du ein Merker setzt.

Code:

SET
= M 10.0

Den M10.0 dann über Variable Tabelle beobachten.

Synchronisationsaufgabe zweier ET200S in 2ms

merless

Guest

Level-2

merless

Guest

Administrator

Administrator

Level-2

Supermoderator und User des Jahres 2019

Level-2

merless

Guest

Level-2

Supermoderator und User des Jahres 2019

Level-2

merless

Guest

Level-2

merless

Guest

Level-2

merless

Guest

Forums-Knochenbrecher

merless

Guest

Forums-Knochenbrecher

Similar threads

Wir schützen deine Privatsphäre