Step 7 Frage zur Zykluszeit bei S7 300

[SPS-freak1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten abend,

Ich habe heute begonnen eine neue Steuerung in betrieb zu nehmen. Dabei habe ich 28 SEW Movimot Antriebe über den Profibus projektiert. Dabei lade ich die projektierten Antriebe per PEW/PAW Zugriffe in einen Datenbaustein. Aktuell sind leider, da die Elektriker nicht hinterher kommen noch kein Profibus aktiv. Die Steuerung bleibt aber durch denn OB 121/122 am leben. Nun ist mir heute aufgefallen, dass die Zykluszeit bei 78ms liegt. Schmeiß ich den Aufruf aus dem OB1 so habe ich 1ms Zykluszeit. Die CPU ist ein 314 PN/DP. Da das unsere Standard CPU ist und wir damit schon viel größere Projekte projektiert haben kommt mir das ziemlich komisch vor.

Nun zu meiner Frage : kann es sein, das durch die fehlenden Profibus Slaves irgendwie jeder PEW Zugriff einen kurzen Fehler inklusive Zyklusverzögerung auslöst?

Hoffe ich konnte mich halbwegs verständlich ausdrücken. Möchte eigentlich ungern die CPU tauschen.

Gruß SPS-Freak

 

[SoftMachine]

.
Schau mal in deinen Diagnosepuffer, was der sagt.


.

 

[SPS-freak1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja der sagt logischerweise Zugrifffehler Adresse 300 etc. Meine frage ist ja, ob das die Zykluszeit explodieren lässt.

 

[MSB]

Kannst ja deine PEW/PAW Zugriffe mal durch EW/AW ersetzen, ist bis auf sehr wenige Ausnahmen sowieso besser.
P-Bereich in der HW-Konfig vergrößern ... hat so nebenbei noch den Vorteil, das der Diag-Puffer nicht zugemüllt wird.

Es wäre durchaus vorstellbar, das dieses permanente OB-Aufrufen in Verbindung mit dem bezogen auf die Zykluszeitbelastung sowieso langsamen Peripheriezugriff schon einiges in der Zykluszeit ausmacht,
wobei mir jetzt gerade ein wenig die Bemessunggrundlage fehlt wie viel genau das denn ausmachen würde.

Auf der anderen Seite: 78 ms Zykluszeit sind gemessen an dem was man von so mancher S5 oder Prozessleitsystem kennt sowieso noch Ultra-High-Speed.

Mfg
Manuel

 

[SoftMachine]

.
Durchaus, aber in welchem Umfang weiss ich nicht.

Nimm´ doch einfach mal nur 3 Antriebe in den OB1 und schau dann nach.

Wenn du die Anzahl der Antriebe dann Stück für Stück erhöhst und deine Zykluszeit steigt, hast du die Antwort.

Aber dein Datenbaustein ist auch in der Steuerung drin, oder ?

.

 

[SPS-freak1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also wir haben die 314 PN oft im Einsatz und sind da nie oft über 10ms.
Ich dachte immer die Belastung für die SPS höher wenn ich das Abbild größer mache. Hab mich mit meinem Baustein am Standard SEW Baustein orientiert und der arbeitet auch mitn Peripheriezugriffen.

 

[SPS-freak1]

Ja das habe ich auch schon gemacht. Jeder antrieb macht mindestens 5 ms aus. Wobei der Rangier FC nur jeweils 4 Zugriffe lesend bzw schreibend hat. Kann es an dem einem DB Aufruf als Block_DB liegen um die temporären Daten wieder in den zugehörigen FC zu bekommen? Also ich mache in den FC einen DB auf und schreibe die Statusworte in den DB des Antriebs.

 

[SoftMachine]

.

.

Nimm´ doch einfach mal nur 3 Antriebe in den OB1 und schau dann nach.

Wenn du die Anzahl der Antriebe dann Stück für Stück erhöhst und deine Zykluszeit steigt, hast du die Antwort.

Aber dein Datenbaustein ist auch in der Steuerung drin, oder ?

.

Ja das habe ich auch schon gemacht. Jeder antrieb macht mindestens 5 ms aus.

Ich würde vorschlagen, du wartest mal auf deine Elektriker aus Beitrag #1 und schaust dann, wo du liegst.

Anschliessend postet du hier nochmal deine Beobachtungen.


.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
die genannte 314er CPU ist sicherlich nicht der Renner - ich würde mir hier also die Frage stellen, was das SPS-Programm sonst noch so macht. Nach meiner Meinung werden sich die fehlenden PB-Slaves nicht in dieser Form auf die Zykluszeit auswirken. Eine Vergrößerung des Prozessabbildes (sofern diese CPU das überhaupt kann) würde das Ganze auch nur dann verbessern, wenn das aktuelle Programm mit Perepherie-Zugriffen "herum-aast" - werden aber die Regler-Daten "nur" in einen DB geladen und die Steuer-Informationen aus einem DB geschrieben (je 1 mal im Zyklus) so sollte das gar keinen Unterschied ausmachen.

Das, was du in deinem Beitrag #7 schreibst, gibt mir ein wenig zu denken, da ich das so nicht zuordnen kann. Kannst du so einen Baustein mal exemplarisch posten ?

Gruß
Larry

 

[MSB]

Also wir haben die 314 PN oft im Einsatz und sind da nie oft über 10ms.
Ich dachte immer die Belastung für die SPS höher wenn ich das Abbild größer mache. Hab mich mit meinem Baustein am Standard SEW Baustein orientiert und der arbeitet auch mitn Peripheriezugriffen.

Also der Zyklusoverhead wird mit Sicherheit ein wenig ansteigen, bei größerem Prozessabbild, dafür ist dann aber der konkrete Zugriff auf EW gegenüber PEW um ca. Faktor 300 0,05us ggü. 15us schneller (bei einer exemplarischen 317er), bei deiner 314Cer musst du halt nachschauen.

Zum Standard-SEW-Baustein:
Diese Bausteine sind ca. 100 Jahre alt, sprich zu der Zeit als die erstellt wurden ging es schon aus rein technischen Gründen nicht anderster.

Zu deinem Beitrag 7:
Der ist brutal wirr geschrieben ... so dass ich mir, ähnlich wir Larry da 0,garnix drunter vorstellen kann.

P.S. Wobei wie gesagt der größte Vorteil für mich darin liegt, das a) das ganze automatisch konsistent ist, b)Diagpuffer, c) sogar Sachen wie SFC20 problemlos funktionieren.

Mfg
Manuel

 

[PN/DP]

Gerätehandbuch CPU 31xC und CPU 31x: Technische Daten 03/2011
Tabelle 6- 8 Typische Zyklusverlängerung durch Fehler

CPU 314C-2 : 150µs je Fehleralarm + ...µs OB-Programmlaufzeit (vermutlich leerer OB122 --> 0µs)

28 Antriebe je 4 PEW/PAW-Zugriffe * 150µs = 16,8ms zusätzliche Zykluszeit durch die Peripheriezugriffsfehler

Bei Vergrößerung des Prozessabbildes (*) und dadurch systemseitiger Aktualisierung des Prozessabbildes ist standardmäßig eingestellt, daß kein Fehler-OB85 aufgerufen wird --> keine Verlängerung der Zykluszeit durch Peripheriezugriffsfehler.

(*) und Zugriff auf PA (EW../AW..) statt Peripherie (PEW../PAW..)


Vorteil der systemseitigen Aktualisierung des Prozessabbildes:
+ Transferzeit für das Prozessabbild: 0,5μs je PEW/PAW-Wort --> 56µs für 28 Antriebe
(Tabelle 6- 4 CPU 31xC: typische Transferzeit für das Prozessabbild)
+ keine Verlängerung der Zykluszeit bei Peripheriezugriffsfehlern und keine Diagnosepuffereinträge
- zusätzliche Laufzeit für Operandenzugriff auf PEW/PAW: 4,1µs --> 460µs für 28 Antriebe
(Operationsliste S7-300-CPUs, 9.31.4 Ausführungszeiten für Operandenzugriffe auf Peripherie)
- Verlängerung der Zykluszeit bei Peripheriezugriffsfehlern und Vollmüllen des Diagnosepuffers entfällt


PS: "Rangier-FC"
Für nur 28 Antriebe würde ich nicht 28x einen FC mit indirekter Adressierung aufrufen, sondern in nur einem FC linear hintereinanderweg 112 L/T zwischen E/A und DB schreiben. Ist auch besser für die Referenzdaten.

Harald

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke PN/DP, sehr aufschlussreich.

Insofern ist es also gar nicht so unvorteilhaft die Peripheriegeäte ins Prozessabbild zu nehmen.
Wie hälst du es eigentlich in der Praxis? Ich versuche eigentlich so viel wie möglich mit den SFCs zu arbeiten und nur wenn ich muss PEWs/PAWs zu verwenden.

- zusätzliche Laufzeit für Operandenzugriff auf PEW/PAW: 4,1µs --> 460µs für 28 Antriebe

Den Satz hab ich aber nicht ganz verstanden. Inwiefern beinflusst die Vergrößerung des Prozessabbildes die Zugriffszeit auf den Peripheriebereich?

- Verlängerung der Zykluszeit bei Peripheriezugriffsfehlern und Vollmüllen des Diagnosepuffers entfällt

Sollte das nicht ein Pluspunkt sein?

 

[vollmi]

Sollte das nicht ein Pluspunkt sein?

Ich denke er meint das die Verlängerung der Zykluszeit bei Zugriffsfehlern wegfällt. Wie auch die lange Zugriffszeit auf Peripherie entfällt.

mfG René

mfG René

 

[PN/DP]

Ist wohl etwas missverständlich geworden beim Versuch, die Vorteile und Nachteile und zusätzlichen Zeiten und wegfallenden Sachen kompakt darzustellen.
So war es gemeint:

Vorteil der systemseitigen Aktualisierung des Prozessabbildes:
+ Transferzeit für das Prozessabbild: 0,5μs je PEW/PAW-Wort --> 56µs für 28 Antriebe
(Tabelle 6- 4 CPU 31xC: typische Transferzeit für das Prozessabbild)
Diese 56µs dauert die Zykluszeit zunächst länger (+ Mehrzeit) als die herkömmliche Lösung.
+ Verkürzung der Zykluszeit um 460µs (- Minderzeit) durch Änderung der Zugriffe von PEW/PAW auf EW/AW.
+ keine Verlängerung der Zykluszeit bei Peripheriezugriffsfehlern und keine Diagnosepuffereinträge

Nachteil der herkömmlichen direkten Peripheriezugriffe:
- längere Laufzeit für Operandenzugriff auf PEW/PAW: 4,1µs --> 460µs für 28 Antriebe
(Operationsliste S7-300-CPUs, 9.31.4 Ausführungszeiten für Operandenzugriffe auf Peripherie)
- Verlängerung der Zykluszeit bei Peripheriezugriffsfehlern und Vollmüllen des Diagnosepuffers


So oder so müssen einmal die Peripherieeingänge gelesen und die Peripherieausgänge geschrieben werden.
Der Zeitaufwand für die reinen Kopier/Transferoperationen ist unvermeidlich und daher relativ uninteressant.

Peripherie im Prozessabbild benötigt für 28 Antriebe 56µs mehr als die L/T-Operationen.

//systemseitiges Kopieren Peripherie <--> PA benötigt zusätzlich 56µs
// PEW256 --> EW256  dauert 0,5µs
// AW256 --> PAW256  dauert 0,5µs
// ...

L EW256
T DB1.DBW0

L DB2.DBW0
T AW256

...

Herkömmliches direktes Zugreifen auf Peripherie benötigt für 28 Antriebe 460µs mehr als die reinen L/T-Operationen.

L PEW256    //4,1µs erhöhter Zeitaufwand gegenüber L EW256
T DB1.DBW0

L DB2.DBW0
T PAW256    //4,1µs erhöhter Zeitaufwand gegenüber T AW256

...

Ich lege Peripherie soweit möglich ins Prozessabbild. (also PA vergrößern)
Dann braucht man sich außerdem nicht um konsistenten Zugriff auf Peripherie kümmern (man braucht keine SFC14/SFC15)

Harald

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aja, jetzt hab ich auch kapiert wie du das meintest.

Insofern verwende ich die SFCs gerne weil man ein Verbindungsproblem schnell und einfach am Fehlercode erkennen kann. Sonst muss man mit den OBs oder Diagnose-Fcs/Fbs arbeiten.

Die Argumente für das vergrößern des PA sind aber auch schlüssig.
Wieder was gelernt.