Step 7 Wann werden die Sensorsignale gelesen und Ausgangssignale gesetzt?

S

Sawascwoolf

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

ich beschäftige mich gerade mit einem Detail des Ablaufs der Steuerung.

Folgendes Szenario gebe ich mal vor:
* OB1 Zykluszeit ~70ms
* OB35 Taktzeit 5ms

Ich habe nun eine Steuerung von Motoren zur Positionierung von Werkzeugmaschinen. Die Motoren schalten bei Erreichen der Endschalter nicht automatisiert ab, für den rechtzeitigen Stopp ist also meine Steuerung verantwortlich.

Die hohe Zykluszeit des OB1 reicht nicht aus, um die Motoren rechtzeitig anzuhalten, mein Lösungsansatz ist daher die Verwendung des OB35 zum Anhalten der Motoren.

Ohne Verwendung des OB35 ist mir der Ablauf klar:

* Sensorwerte auslesen
* OB1 abarbeiten
* Aktorwerte schreiben


Also habe ich Verhalten A)
* Sensorwerte auslesen
*OB1 starten
*OB35 unterbricht
*OB1 weiter
*OB35 unterbricht
...
*OB1 beendet
*Aktorwerte schreiben

oder Verhalten B)
*Sensorwerte auslesen
*OB1 starten
*Sensorwerte auslesen
*OB35
*Aktorwerte schreiben
*OB1 weiter
*Sensorwerte auslesen
*OB35
*Aktorwerte schreiben
...
*OB1 beendet
*Aktorwerte schreiben


Zusätzlch möchte ich falls Variante B zutrifft wissen, ob die in OB1 verfügbaren Sensorwerte auch aktualisiert wurden.
 
Hängt davon ab wie du deine Sensorwerte liest.
Wenn du vom/zum Prozessabbild (E,A) liest/schreibst machst es im Endeffekt keinen Unterschied.

Wenn du PEW/PAW, also direkt den Peripheriebereich, bearbeitest, macht es einen Unterschied.
Sowohl innerhalb des OB1 als auch des OB35 liest du mit PEW die akutellste Information die dir deine Hardware liefert.
Das selbe gilt natürlich auch für PAWs. Sobald du die schreibst (+ die nötige Verzögerung durch den Rückwandbus und die Karten selbst) landet der Zustand "sofort" am Ausgang. Wann das Signal am physikalischen Ausgang ankommt ist also hier nicht abhängig vom OB1-Zyklus.

Wenn du nicht direkt auf den Peripheriebereich zugreifst also E, EW, A oder AW liest/schreibst, findet die Übertragung zum/vom Periepheriebereich immer am Anfang bzw. Ende des OB1-Zyklus statt.
Liest du also einen E0.0 oder ein EW128 im OB35, ist das nichts anderes als würdest du dasselbe in OB1 machen.

Wenn du also irgendwas beschleunigt im OB35 machen willst musst du auch jeden Fall direkt mit dem Peripheriebereich arbeiten.

Dann gibt es noch was zu beachten.
Du schreibst von einem OB35 Zyklus von 5ms.
Dir ist aber schon bekannt das Standard-DI-Karten eine Verzögerung von 3ms und Standard-AI/AO-Karten oft eine Wandlungszzeit von >50ms haben.
Dazu kommt dann noch die nötige Übertragungszeit von der Karte selbst über einen Rückwandbus oder Peripheriebus an die CPU.
Hast du überhaupt die passende Hardware um eine Signal->Aktions-Kombination im <10ms-Bereich zu realisieren?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo RONIN,

vielen Dank für deine ausführliche Antwort. Aktuell verwende ich noch die E0.0-Variante. Hast du vielleicht einen Link für mich, um mich über PEW zu informieren?

Es geht bei dem Projekt um meine Diplomarbeit, funktionieren tut es mit den 70ms bereits, die Lösung über OB35 ist aber sicherer und wirkt professioneller ;)
 
Sawascwoolf schrieb:
die Lösung über OB35 ist aber sicherer und wirkt professioneller ;)
Zum Vergrößern anklicken....
Eigentlich genau das Gegenteil.
So wie du den OB35 bzw. die EAs vermutlich verwendest ändert es am Ergebnis nichts, verlängert zusätzlich den OB1-Zyklus und schafft womöglich neue Probleme....
(CPU-Stopp bei Code im OB35 >5ms)

Würde also eher nach jemandem aussehen der nicht weiß wie seine SPS arbeitet. ;)

Das ganze läuft in deinem Fall vermutlich so ab:
Code: 
//Beispiel: E0.0 -> Rücksezte A0.0
//A0.0 ist schon 24V und E0.0 ist gerade auf 24V (High) gegangen...

//Spannung des DI geht auf 24V
//Jetzt vergeht je nach DI-Karte ein Wandlungs- und Übertragungszeit bis zur Übertragung
//in das Perpherie-Abbild der CPU (>3ms bei Standard-DI)

[COLOR=#ff0099]L PED0  //Beispiel stellvertretend für Mechanik des Prozessabbildes 
T ED0  //Die Information des Peripherie-Abbildes wird in das Prozessabbild übertragen
          //Erst ab jetzt steht das High-Signal in E0.0[/COLOR][COLOR=#00ff00]

[/COLOR][B][COLOR=#ff0000]//----------------------//Beginn OB1-Zyklus
[/COLOR][/B]
//.............OB1-CODE

[COLOR=#0000ff]//.............OB35-Aufruf
U E0.0
R A0.0  //A0.0 ist jetzt wohlgemerkt nur im Prozessabbild False, am Ausgang ändert das noch nichts
[/COLOR]
//.............OB1-CODE

[COLOR=#0000ff]//.............OB35-Aufruf
U E0.0
R A0.0
[/COLOR]
//.............OB1-CODE

[COLOR=#0000ff]//.............OB35-Aufruf
U E0.0
R A0.0
[/COLOR]
//.............OB1-CODE //Ohne OB35 würde OB1 den A0.0 (immer noch nur im Prozessabbild) rücksetzen.
U E0.0
R A0.0

[COLOR=#0000ff]//.............OB35-Aufruf
U E0.0
R A0.0
[/COLOR]
[B][COLOR=#ff0000]//----------------------//Ende OB1-Zyklus
[/COLOR][/B]
[COLOR=#ff0099]L AD0  //Wieder stellvertretend für den Mechanismus des Prozessabbildes. 
T PAD0[/COLOR][COLOR=#00ff00]
[/COLOR]
//Jetzt vergeht wieder eine Zeit bis die Änderung im Peripheriebereich der CPU (welcher zyklisch und OB1-unabhängig mit
//den DI/DO-Karten abgeglichen wird) auf die DO-Karte übertragen wird und diese die Spannung am Ausgang auf 0V setzt.
Wie du siehst machst es so absolut keinen Unterschied ob du den A0.0 innerhalb des OB35 oder des OB1 rücksetzt.

Die Übertragung der Zustände der Eingänge (PEX0.0 auf E0.0 - Periheriebereich auf Prozessabbild) ist immer am Beginn des OB1-Zyklus
und die Übertragung der Zustände der Ausgänge (A0.0 auf PAX0.0 - Prozessabbild auf Peripheriebereich) ist immer am Ende von OB1.

Du solltest dich also erstmal mit den Begriffen "Peripheriebereich", "Peripherieabbild" und "Prozessabbild" vertraut machen.
Die Begriffe taugen als gute Suchbegriffe, sowohl hier als auch in Google.
Sonst müsste dein Professor dir das auch erklären können.

Verbesserung erreichst du wenn du in OB35 nicht E0.0 und A0.0 sondern PEX0.0 und PAX0.0 (geht nicht direkt), also direkt den Periepheriebereich verarbeitest/ beeinflusst.

"Professionell"...
...würde man sich zunächst wundern was man falsch gemacht hat damit die SPS 70ms Zykluszeit braucht und sich fragen ob man das mitigieren könnte.
  • Programmcode optimieren
  • Gewisse zyklische Aktionen azyklisch ausführen
  • Programmschleifen zyklusübergreifend gestalten
  • etc.

Wenn man das dann tatsächlich nicht verbessen kann, könnte man so eine OB35-Lösung anstreben.
Aber bevor man sich den einfach auf 5ms setzt müsste man sich erstmal überlegen wie schnell denn die verwendetet Hardware die EAs tatsächlich aktualisieren kann.
Wie oben schon erwähnt bringen die 5ms schon nicht viel wenn nur die Eingangskarte eventuell schon 3ms braucht.

Wenn es ganz schnell gehen soll, dann würde man auf Prozessalarme setzen. Braucht aber die passenden DI-Karten
https://support.industry.siemens.com/cs/ww/de/view/23657941

Zusammenfassend:
  1. Versuch deine Zykluszeit zu reduzieren
  2. Falls nicht möglich (was ich kaum glaube) kann man den OB35 einsetzen, muss aber das Prozessabbild umgehen.
 
Zuletzt bearbeitet:
Hi,

die Menge an Code (bzw. die dafür benötigte Zeit) im OB35 wäre nicht das Problem, es müssten nur 8 Signale auf 0 gesetzt werden falls der jeweilige Sensor eine 0 liefert. Also nur 16 Zeilen AWL-Code.

ich habe folgende Konstellation:

Fertigungslinie <-> lokale SPS <--(Internet)--> Cloud SPS

Das Hauptprogramm läuft auf der Cloud und die lokale SPS dient nur zur Datenübertragung (+Endschalter + Not Aus bei Verbindungs TimeOut).


Die lange Zykluszeit entsteht durch eine aufwändige Validierung der empfangenen, sowie durch die Erzeugung entsprechender Redundanz für die zu sendenden Daten.
Dies könnte sicher optimiert und auch auf mehrere Zyklusläufe aufgeteilt werden, aber der Abgabetermin lässt eine so komplexe Änderung nicht mehr zu.
Zudem würde die Aufteilung auf mehrere Zyklen zwar die Zykluszeit der lokalen SPS und somit die Funktion der Endschalter, im Gegenzug jedoch die Antwortzeit der Steuerung (Sensor --> lokale SPS --> Cloud SPS --> lokale SPS --> Aktuator) erhöhen.

Die Anlage läuft problemlos bis zu einer Toleranz von 200ms, Sicherheitsrisiken entstehen erst bei 400ms, somit ist die Zykluszeit im akzeptablen Bereich.

Das die Verwendung des Prozessabbildes im OB35 keine Verbesserung bringt habe ich bereits in deiner ersten Antwort verstanden, daher hatte ich nach PEW gefragt. (Das Peripheriebereich in der Klammer dahinter hatte ich irgendwie übersehen).

Nach deinen Ausführungen werde ich die Idee mit dem OB35 wieder verwerfen, der Zugriff auf den Peripheriebereich sieht eindeutig nach einer Notlösung aus.

Da es meine Intention war "professioneller" zu wirken hat sich das ganze wohl erübrigt.

Vielen vielen Dank für deine Antwort und vorallem auch für deine Meinung zu meinem Vorhaben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sawascwoolf schrieb:
Fertigungslinie <-> lokale SPS <--(Internet)--> Cloud SPS
Das Hauptprogramm läuft auf der Cloud und die lokale SPS dient nur zur Datenübertragung (+Endschalter + Not Aus bei Verbindungs TimeOut).
Zum Vergrößern anklicken....
Das ist eine durchaus ... interessante ... Konstellation.

Sawascwoolf schrieb:
Nach deinen Ausführungen werde ich die Idee mit dem OB35 wieder verwerfen, der Zugriff auf den Peripheriebereich sieht eindeutig nach einer Notlösung aus.
Zum Vergrößern anklicken....
Nun ja, das Prozessabbild hat schon seinen Sinn.
Es hält den Zustand der Eingangssignale die das Programm über einen Zyklus verarbeitet konstant und aktualisiert erst am Ende des Zyklus, quasi mit dem Endergebnis, die Ausgänge. Damit stellen Mehrfachzugriffe aus EAs innerhalb eines Verarbeitungszyklus (wenn auch programmiertechnisch unschön) technisch kein Problem dar.

Wenn man EAs schneller als den OB1-Zyklus beeinflussen will kommt man kaum um die Umgehung des herum.
Ein Hardware-Interrupt liefert bei DI=high zwar sofort den Programmsprung, zum "sofortigen" beeinflussen eines Ausgangs muss man aber immer noch direkt in den P-Bereich schreiben.

Deshalb sind niedrige und vor allem konstante Zykluszeiten das A und O bei Maschinenanlagen.

Der Vollständigkeit halber:
Code: 
//Lesen eines Eingangs direkt vom Peripheriebereich

L PEB0  //Direktes Lesen von P-Bereich
UW DW#16#8
= "E0.3_direkt"
Schreiben eines Ausgangs direkt auf den Peripheriebereich. Hier wird es umständlicher.
Man kann kein einzelnes Bit im P-Bereich lesen/schreiben. Minimum ein Byte.
Man kann vom PA-Bereich auch nicht per Lade-Befehl lesen.
Man muss sich daher die 8-Ausgänge des Bytes intern (z.b auf Merker) umlegen und dann damit immer das ganze Byte aktualisieren.
Code: 
//........Beginn OB1-Zyklus
U Irgendwas
= Merker_A0.0 //(M10.0)
U Irgendwas_2
= Merker_A0.1 //(M10.1)

//.......OB35-Zyklus
U "E0.3_direkt
R Merker_A0.3 //(M10.3)
[COLOR=#ff0000]L MB10
T PAB0  //Direktes Schreiben auf P-Bereich
[/COLOR]
//.......OB1-Zyklus
U Irgendwas_3
= Merker_A0.4 //(M10.4)

//.......Vor dem Ende des OB1-Zyklus
[COLOR=#ff0000]L MB10  //Übertragen der restlichen Ergebnisse auf das Prozessabbild. 
T AB0  //L AB0 -> T PAB0 passiert ja am Ende von OB1 automatisch.
[/COLOR]
PAB0 wird am Ende vom OB1-Zyklus ja nochmal mit AB0 (welches den Zustand von PAB0 bei OB1-Beginn hat) überschrieben.
Man muss also seine Änderungen auch dort platzieren.
Sonst würde der Ausgang welcher in OB35 rückgesetzt wurde möglicherweise nur von dort bis zum Ende von OB1 auf LOW sein.
(Man kann natürlich auch einen Ausgang nehmen der nicht im Prozessabbild ist)
 
RONIN schrieb:
Das ist eine durchaus ... interessante ... Konstellation.
Zum Vergrößern anklicken....

Das ist wirklich eine sehr bluminge Umschreibung dafür.

Wieso lässt du das Programm nicht auf der SPS im Feld laufen und sendest die Daten die du brauchst um das ganze zu Steuern nur auf die Cloud SPS und wieder zurück?
 
Zurück
Oben