Step 7 CPU E/A Taktzeiten feststellen/ändern

Kehrer

Level-2
Beiträge
441
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
wo kann ich bei einer

6ES7315-2EH14-0AB0​

die Taktzeiten von Eingänge und Ausgänge einstellen bei S7?
Im Tia geht dies ja unter 1729241113430.png

wo kann ich es im S7-Manager anzeigen/ändern?
 
Das ist keine Taktzeit sondern eine Filterzeit

wo kann ich es im S7-Manager anzeigen/ändern?
Es wäre interessant zu wissen um welche Baugruppe es bei dir genau geht.
Generell stellt man dies in der Hardwareconfig direkt an der entsprechenden Baugruppe ein ( insofern sie dies unterstützt ).

Die von dir gewählte Baugruppe ( S7-1200 ) hat Onboard E/A, daher stellt man dies in dem Fall in den CPU-Eigenschaften ein. Die 315ér hat keine Onboard-E/A. Also in dem Fall in den Eigenschaften der E/A Baugruppe schauen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei S7-300 ist die Aktualisierung des Prozessabbildes (*) an die Ausführung des OB1 gekoppelt. Nachtrag: "OB1-PA"
Bei manchen CPU kann man Teilprozessabbilder ("TPA x") projektieren und gesteuert aktualisieren. Alternativ kann man das (Haupt-)Programm im OB3x laufen lassen (wie Codesys-Tasks), anstatt im OB1, dann muss man sich selber um die Aktualisierung des Prozessabbilds kümmern.

(*) Einlesen Peripherie-Eingänge in Prozessabbild der Eingänge (PAE) im Speicherbereich der Eingänge, Ausgeben des Prozessabbildes der Ausgänge (PAA) im Speicherbereich der Ausgänge an Peripherie-Ausgänge
 
Zuletzt bearbeitet:
Das ist keine Taktzeit sondern eine Filterzeit


Es wäre interessant zu wissen um welche Baugruppe es bei dir genau geht.
Generell stellt man dies in der Hardwareconfig direkt an der entsprechenden Baugruppe ein ( insofern sie dies unterstützt ).
1729243648811.png

woher weiß ich dann die "Prellzeit" , also die Geschwindigkeit wie schnell ein Eingang verarbeitet wird in der CPU. Sind das dann bei der 315 150ms?

1729243803591.png
 
wie schnell die Daten in der SPS verarbeitet werden
Verarbeitungszeit des Sensors + Verarbeitungszeit der Eingangskarte + Zykluszeit des SPS-Programms + Verarbeitungszeit der Ausgangskarte + Verarbeitungszeit des Aktors + Verarbeitungszeit der Mechanik

Bei schlechter/ungünstiger Programmierung können das auch mal 2 oder 3 SPS-Zyklen sein.

Datenaustausch kann länger sein

Safetyfunktionen können länger sein

SPS-Zykluszeit kann schwanken

Im SPS-Programm können Verzögerungen programmiert sein.

Meistens wird die Taktzeit einer Maschine ja nicht wesentlich von der SPS beeinflusst, ausser vielleicht bei extrem kurzen Taktzeiten, wie lang ist denn ein Schritt?...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, bei extrem kurzen Taktzeiten muss man aber dann auch genau wissen, was man tut, wenn man an der SPS was optimieren will/muss...
Es sind nicht nur die kurzen Taktzeiten, wo der SPS-Zyklus auffällt.
Nimm ne einigermaßen komplexe Station mit etwa etwa 50 Bearbeitungsschritten.
Zykluszeit 40ms und pro Schritt ca. 2 SPS Zyklen. Dann hast du pro Takt 4s reine SPS-Zykluszeit.
 
Es sind nicht nur die kurzen Taktzeiten, wo der SPS-Zyklus auffällt.
Nimm ne einigermaßen komplexe Station mit etwa etwa 50 Bearbeitungsschritten.
Zykluszeit 40ms und pro Schritt ca. 2 SPS Zyklen. Dann hast du pro Takt 4s reine SPS-Zykluszeit.
ja, 80ms pro Bearbeitungsschritt ist für mich schon ne kurze Taktzeit 😂 aber ja, wir reden schon vom gleichen ;)
 
Verarbeitungszeit des Sensors + Verarbeitungszeit der Eingangskarte + Zykluszeit des SPS-Programms + Verarbeitungszeit der Ausgangskarte + Verarbeitungszeit des Aktors + Verarbeitungszeit der Mechanik
Bei unseren Maschinen wurden diverse Hydraulik-( bzw. Pneumatik-)Zylinder als Aktoren benutzt und als Sensoren, die das Erreichen der EndPositionen melden sollten, wurden DruckSchalter verwendet. Prinzip: Solange der Zylinder in Bewegung ist, bleibt der Druck gering und er steigt erst an, sobald die Bewegung zum Stillstand gekommen ist. Ich habe immer wieder gestaunt, wie (für mich unerklärlich) lange es dauerte, bis der DruckSchalter gemeldet hat!
So richtig wohl war mir bei dieser Art der "getürkten" Rückmeldung allein schon deshalb nicht, weil eine ZylinderBewegung schon vorzeitig (z.B. durch eine Kollision) beendet werden konnte, ohne dass die erwartete EndPosition erreicht wurde.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei meinem früheren Arbeitgeber in der Gießereibranche wurde an einer Anlage auch mal eine schnellere CPU eingebaut und EA-Baugruppen getauscht, um eine ca. 1% höhere Produktionsleistung zu erzielen.
Auf den ersten Blick scheint das unnötig. Aber durch Aufwand-Nutzen-Rechnung kam man schnell zu dieser Entscheidung.
 
Bei unseren Maschinen wurden diverse Hydraulik-( bzw. Pneumatik-)Zylinder als Aktoren benutzt und als Sensoren, die das Erreichen der EndPositionen melden sollten, wurden DruckSchalter verwendet. Prinzip: Solange der Zylinder in Bewegung ist, bleibt der Druck gering und er steigt erst an, sobald die Bewegung zum Stillstand gekommen ist. Ich habe immer wieder gestaunt, wie (für mich unerklärlich) lange es dauerte, bis der DruckSchalter gemeldet hat!
Normalerweise funktioniert es genauso, wie Du es beschrieben hast --> Zylinder erreicht seine Endlage (oder ein Hindernis ) --> Der Druck steigt.
Man muss aber auch Leckagen betrachten. Für den Ernstfall programmiert man eine Laufzeit- Überwachung.
So richtig wohl war mir bei dieser Art der "getürkten" Rückmeldung allein schon deshalb nicht, weil eine ZylinderBewegung schon vorzeitig (z.B. durch eine Kollision) beendet werden konnte, ohne dass die erwartete EndPosition erreicht wurde.
Hmm... Wenn der Zylinder nicht mehr weiterfahren kann (aus welchen Gründen auch immer, steigt der Leitungsdruck ) --> der Druckschalter meldet "OK" - obwohl der Verfahrweg gar nicht erreicht wurde !
Ich mag diese "Rückmeldung" ohne eine tatsächliche Endlagen- Überwachung auch nicht, weil da sehr viel Unfug entstehen kann.
 
Zurück
Oben