Zykluszeit Siemens SPS

Raphael1990

Level-1
Beiträge
8
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Miteinander,

ich bin neu hier und hoffe mir kann weiter geholfen werden. :)(y)

Ich hätte eine Frage bezüglich Zykluszeit.

Ich arbeite momentan an einer Anlage mit einer ET200 1512-F CPU. Wir sind alle noch nicht so erfahren bei uns in der Firma und haben uns für diese Steuerung entschieden da wir dachten das sie stark genug ist. Wie sich jetzt herausgestellt hat, haben wir den Umfang doch ein wenig unterschätzt.
Und nun habe ich ein Zykluszeitproblem. Ich habe es jetzt geschafft mit diversen Jumps im Programm und teilweise ohne Aufrufe von Bausteinen wenn sie nicht benötigt werden auf eine Zeit von ca. 50ms zu kommen. Teilweise sind halt Spitzen drinnen wo zum Beispiel 60ms zustande kommen.

Das wäre für die Anlage an sich ok.

Nur ich muss bei einem Arbeitsgang eine Breite von einem Blech messen. Und das wird so gemacht das ein Greifer das Blech gespannt hat und eine Servoachse das Blech zieht und über dieser Station hängt ein Galgen wo Lichtschranken befestigt sind. Mit diesen Sensoren erhalte ich jeweils beim Durchziehen am Anfang ein Flankensignal und am Ende ein Falnkensignal. Mit diesen Signalen merke ich mir die Servopositionen und kann mir daraus die Breite ausrechnen.

Das funktioniert grundsätzlich gut. Nur durch die relativ hohe Zykluszeit und die gelegentlichen Sprünge hat das Messergebnis des öfteren Abweichungen.

Meine Frage wäre jetzt wie ich diesen Abweichungen entgegenwirken könnte.
Wäre es noch eine Möglichkeit den Baustein zum messen in einen Weck Alarm OB zu packen?

Die Steuerung zu tauschen wäre nicht wirklich eine Option.
 
Meine Frage wäre jetzt wie ich diesen Abweichungen entgegenwirken könnte.
Wäre es noch eine Möglichkeit den Baustein zum messen in einen Weck Alarm OB zu packen?

Die Steuerung zu tauschen wäre nicht wirklich eine Option.
Das mit dem Weckalarm kannst du im Prinzip machen - du mußt hier nur beachten, dass in diesen OB's das Prozess-Abbild nicht aktualisiert wird - du mußt hier also die zugehörigen Eingänge aus der Perepherie einlesen (was dann wieder bei einem entsprechenden Takt deine Zykluszeit in die Höhe treibt).

Ganz grundsätzlich bist du aus meiner Sicht, da du ja schreibst, dass du schon viel indirekte Bearbeitung in deinem Programm hast, mit der 1512 komplett falsch aufgestellt. Vielleicht denkst du über diesen Punkt dann doch noch mal nach ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Oder vll. eine HF Eingangskarte verwenden die einen Interrupt OB aufruft.
Und wenn du mit den 50-60ms zufrieden bist kannst du ja bei der sps bleiben.
 
SPS werden wir erst bei der nächsten Anlage eine andere verwenden. Nächstes Jahr werden wir das selbe nochmal bauen. Die Anlage läuft ja auch schon seit letztem Sommer. Und da hab ich das mit der Zeit im Griff gehabt. Da war ich permanent auf ca. 40ms. Nur jetzt sind noch einige Sachen dazugekommen.
Dadurch ist die Zeit wieder gestiegen.

Wie gesagt, die 50 - 60 ms reichen im Allgemeinen, nur für das Messen ist es eben nicht zufriedenstellend.

Die Signale werden jetzt über eine Profinet Device von Festo eingelesen. Ist eine Standartkarte.

Das würde ja ebenfalls was nützen wenn ich diese in dem Interrupt OB auslese oder?
Und im Grunde muss ich dann den Servo Baustein, von dem ich ja die Positionswerte bekomme auch in diesen OB tun.
 
Das würde ja ebenfalls was nützen wenn ich diese in dem Interrupt OB auslese oder?
Und im Grunde muss ich dann den Servo Baustein, von dem ich ja die Positionswerte bekomme auch in diesen OB tun.
Das kommt darauf an wie schnell das Festo-Device seine Signale liefern kann - in jedem Fall solltest du es aber mal versuchen ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich bin jetzt nochmal auf etwas gestoßen. Es wäre doch auch eine Möglichkeit, dass ich die Sensoren, es sind in diesem Fall 6 Stück und je nach typ brauche ich immer 2 davon, nicht über das Prozessabbild sondern als Perepheriezugriff einlese.
Im Anhang ist der Baustein der alles verarbeitet. Diesen Baustein tue ich wie gesagt in den OB 30 und den rufe ich alle 10 oder 20 ms auf. Aber nur wenn ich ihn brauche. Ein Blech wird ca. alle 30 sec je nach typ gemessen.

Was eventuell auch noch helfen würde, dass ich den aktuellen Positionswert direkt vom Technologieobjekt nehme. Verfahre die Achsen mit Telegramm 105.

Das wäre ein gangbarer Weg denke ich?
 

Anhänge

  • Unbenannt.PNG
    Unbenannt.PNG
    39,7 KB · Aufrufe: 91
So in der Art habe ich es schon mal gemacht ... Das mit dem Perepheriezugriff hatte ich dir aber im Beitrag #2 auch schon mal geschrieben ...

Du könntest ja die Bearbeitung im Zeit-OB (10 ms hört sich nicht schlecht an - du kannst ja aber auch noch schneller werden) auch nur freigeben wenn du wirklich messen willst (hast du wahrscheinlich sowieso vor).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit dem Perepheriezugriff hatte ich dir aber im Beitrag #2 auch schon mal geschrieben ...
Ah stimmt. Sorry, hab ich überlesen und bis heute gar nicht gewusst das das geht.
Du könntest ja die Bearbeitung im Zeit-OB (10 ms hört sich nicht schlecht an - du kannst ja aber auch noch schneller werden) auch nur freigeben wenn du wirklich messen willst (hast du wahrscheinlich sowieso vor).
Ja so hätte ich es vor. Mit der Zeit selber kann ich dann noch experimentieren.

Werd ich am Montag mal so probieren
 
Danke für eure Inputs.

Ich hätte gleich noch eine Frage.
Es geht um de selbe Anlage aber anderes Thema.

Wie oben schon erwähnt sind ja jetzt noch ein paar Sachen dazugekommen.

Und zwar sind zwei E-Zylinder von Festo dazugekommen. Angesteuert über IO-Link mit einem Murr Impact 67.
Zylindereinheit ist die Festo-EPCS-BS.

Das Ansteuern und Verfahren geht ohne Probleme. Müssen gleichzeitig verfahren um Zeit zu sparen. Nur die Azyklische Kommunikation geht immer nur bei einem. Ich muss es bei dem anderen immer unterbinden. Ich muss nämlich Parameter umschreiben wegen unterschiedlicher Typen.

Ist das normal so oder sollte das schon auch gleichzeitig funktionieren.
Verwenden tu ich den SMS Baustein von Festo. Angemerkt ist nur mit einem Festo Modul geprüft seitens Festo
 
Wie wäre es, die Zeitmessung nicht in der CPU zu machen, sondern in der Karte.
Ich bin mir gerade nicht sicher, welche Karte das bei Siemens wäre: sind das Counter-Eingangskarten?
Dann bist Du völlig unabhängig von der Zykluszeit der CPU und kannst Zeitdifferenzen zwischen zwei Signalen direkt aus der Karte lesen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wie wäre es, die Zeitmessung nicht in der CPU zu machen, sondern in der Karte.
Ich bin mir gerade nicht sicher, welche Karte das bei Siemens wäre: sind das Counter-Eingangskarten?
Dann bist Du völlig unabhängig von der Zykluszeit der CPU und kannst Zeitdifferenzen zwischen zwei Signalen direkt aus der Karte lesen.
Was meinst du mit Zeit messen

Ich will ja keine Zeit sondern, ein Maß messen
 
SPS werden wir erst bei der nächsten Anlage eine andere verwenden. Nächstes Jahr werden wir das selbe nochmal bauen. Die Anlage läuft ja auch schon seit letztem Sommer. Und da hab ich das mit der Zeit im Griff gehabt. Da war ich permanent auf ca. 40ms.
dieses Jahr kommt die neue CPU Reihe von Siemens am Markt. Also entweder die 1512 nochmals probieren oder gleich auf die 1514 umsteigen
 

Anhänge

  • 20230325_212419.png
    20230325_212419.png
    217 KB · Aufrufe: 90
Zuviel Werbung?
-> Hier kostenlos registrieren
Das mit dem Weckalarm kannst du im Prinzip machen - du mußt hier nur beachten, dass in diesen OB's das Prozess-Abbild nicht aktualisiert wird - du mußt hier also die zugehörigen Eingänge aus der Perepherie einlesen (was dann wieder bei einem entsprechenden Takt deine Zykluszeit in die Höhe treibt).

Das ist doch das grundsätzliche Vorgehen. Langsame Dinge in OB1 oder langsamen Weckalarm, schnelle Dinge in einen schnellen Weckalarm. Für diese IOs in den Weckalarmen gibts Teilprozessabbilder TPA.
Das mit dem bedingten Aufrufen von Programmbausteinen ist so ne Sache. Dann ist das Programm meistens schnell, ausser manchmal. Davon würd ich in der Regel die Finger lassen.
Weierhin beeinflusst die Kommunikation zum HMI oder PG auch die Zykluszeit. Ansonsten, was ist beim F-Teil für eine Zykluszeit eingestellt?

Und welche Zykluszeit wird eigentlich für das Standardprogramm benötigt?
 
Das ist doch das grundsätzliche Vorgehen. Langsame Dinge in OB1 oder langsamen Weckalarm, schnelle Dinge in einen schnellen Weckalarm. Für diese IOs in den Weckalarmen gibts Teilprozessabbilder TPA.
Das mit dem bedingten Aufrufen von Programmbausteinen ist so ne Sache. Dann ist das Programm meistens schnell, ausser manchmal. Davon würd ich in der Regel die Finger lassen.
Weierhin beeinflusst die Kommunikation zum HMI oder PG auch die Zykluszeit. Ansonsten, was ist beim F-Teil für eine Zykluszeit eingestellt?

Und welche Zykluszeit wird eigentlich für das Standardprogramm benötigt?
Ja leuchtet eigentlich e ein, hab die Weck OBs bis jetzt noch nie gebraucht.

Bei der Anlage sind einige Sachen dabei die nur für einen Typwechsel notwendig sind, oder nur wenn am Tag produziert wird. Es gibt auch für die Nacht eine mannlose Produktion da sind zum Beispiel einige Sachen ausgeblendet. Das denke ich ist vertretbar.

Kommunikationslast habe ich schon ganz runtergestellt. Beim F-Teil sind 100ms eingestellt

Wie gesagt die 50- 60 gehen voll in Ordnung. Werde ich denke ich auch mit der Mindestzeit festlegen. Dann sind nicht immer die Sprünge drinnen.
Sorry, hatte ich falsch verstanden gestern, ich dachte, zu bestimmst die Breite über die Verzögerung der Signale... beim nochmaligen Lesern habe ich verstanden, dass Du das über die Servo-Positionen machst.
Ja mach ich mit den Servopos.
Aber mit der Zeit wär eigentlich auch eine gute Idee gewesen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kommunikationslast habe ich schon ganz runtergestellt. Beim F-Teil sind 100ms eingestellt
Auch schon die Sendetakt der CPU hochgeschraubt? Haben bei unseren Anlagen standardmäßig 1ms drin. Als wir bei einer Zykluszeitprobleme bekommen haben, hat es geholfen den Sendetakt auf 2ms zu stellen. Gab eine 25% kürzere Zykluszeit.
 
Auch wenn es ein alter Thread ist:

Ich würde entweder die Positionserfassung per Touchprobe im Umrichter machen (Lichtschranken an Umrichter) oder in einer Zählerkarte, auf die Lichtschranken und (zusätzlicher) Inkrementalgeber verkabelt sind.
Das ist wesentlich genauer als jede Lösung aus Umrichter + SPS. Schließlich hat jeder Umrichter auch seine Zykluszeit und die Servoposition über Profinet oder so auszulesen dauert auch. Manche FU liefern auch nur alle 50ms (z.B. SEW UHX-System) oder langsamer neue Daten über den Bus, auch wenn dieser mit 1ms läuft. Das heißt ja nur, daß über den Bus alle 1ms ein Wert vom FU eingelesen wird. Wenn der FU seine Ausgangsdaten im Profinetstack nicht aktualisiert hat, kommt eben nichts neues.
Da lohnt es sich, mal eine Testtask anzulegen, meinetwegen mit 1ms und das TPA für den FU damit zu koppeln und über über einen Trace festzustellen, wie oft wirklich neue Werte kommen.
Und dann hilft nur rechnen, ob man mit diesen Aktualisierungsraten hinkommt.
 
Zurück
Oben