Echtzeit in CoDeSys-Programmierung, Reihenfolge von FBs

Beck

Level-1
Beiträge
64
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe eine Frage zur Reihenfolge und damit letztlich zur Echtzeitfähigkeit von Codesys-Programmen, konkret FUP-Plänen:
Wenn ich einen FB definiere und von diesem in einem Hauptprogramm drei Instanzen
Code:
VAR
    oDosomething1: FBDoSomething;
    oDosomething2: FBDoSomething;
    oDosomething3: FBDoSomething;
END_VAR
verwende und diese dann in drei Schritten untereinander im Hauptprogramm aufrufe, wird dann oDosomething2 erst gestartet, wenn oDosomething1 komplett abgearbeitet ist (auch, wenn dies ggf. 2 Sekunden dauert)?
Oder werden diese kurz hinter einander gestartet und laufen quasi parallel?

Danke,

Beck
 
willkommmen in der welt der sps :)
so wie die frage gestellt worden ist, kommst aus irgend einer hochsprache (denke ich).
grundgedanke (grob):
ein spsprogramm läuft zyklisch durch alle geschriebenen bausteine und arbeitet diese nacheinander ab.
alle aktionen laufen durch sogenannte akkus(speicherbereiche). diese sind 32/64bit groß und es sind meist zwei oder vier stück und können nach verarbeitung wieder in festen speicher (db/merker) abgelegt werden. desweiteren gibt es einen speicherbereich der das ergebnis als true/false mitschleift und bei bedarf einem festen speicher (db/merker) zuordnet. kurzeitig können werte/vke in dem bausteineigenen bereich(temp) abgelegt werden. diese sind nach dem verlassen des bausteins wieder ungültig.
durch diesen verabeitungsbereich werden alle geschriebenen programmteile durchgedrückt.

wird eine schleife programmiert, welche auf ein ereignis wartet, kann der rest des programms nicht abgearbeitet werden und die sps geht in den zeitüberlauf (absturz).

zu deiner frage:
eine sps arbeitet immer von oben nach unten das programm ab (bei einem task/keinen weiteren ob aufruf) = sogenannter zyklus
peripherie: jeh nach hardware können zustände/werte während eines zyklus gelesen/geschrieben werden. die meisten werte werden am anfang eines programms gelesen und am ende weggeschrieben.
Ausgang_1:=oDosomething1;
Ausgang_1:=oDosomething2;
Ausgang_1:=oDosomething3;
hierbei wird die letzte nutzung (oDosomething3) das signal an den ausgang übergeben, da die ausgänge(bei der meisten peripherie) am ende geschrieben werden.

bei direkten peripherie zugriffen ist es zufall was anliegt, da 90% aller zyklen kleiner sind als die aktualisierungszeit der peripherie. es laufen zwei geräte mit unterschiedlichen verarbeitungszeiten miteinander.

der sogenannte "echtzeitbus" bezieht sich hauptsächlich auf die aktualisierungszeit und der möglichkeit diesen sehr schnell einzulesen/zu zugreifen.

sehr einfache erklärung, wobei viele besonderheiten/wege nicht erläutert worden sind (ja, abeite mehr mit siemens :ROFLMAO: ).

fast gleiche frage:
http://www.sps-forum.de/simatic/64534-scl-zeitverzoegerung-mit-schleifen-step-7-a.html
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Man sollte noch die Unterschiede der einzelnen Steuerungen in Bezug auf die Isochronität beachten. Bei Siemens wird das Programm abgearbeitet und das Prozessausgangsabbild sofort an die Peripherie übertragen, wenn der Programmdurchlauf fertig ist. Daher hängt die Zykluszeit von der komplexität des Programms ab. Benötigt man zeitgleiche Takte muss man hier mit Weckalarmen arbeiten.
Bei anderen Steuerungen (Beckhoff z.B. ) wird die Zykluszeit in den Taskeinstellungen fest vorgegeben. Wenn also ein Task mit 1ms definiert ist, dann läuft das gesamte EVA Prozedere auch in 1ms ab. Unabhängig davon wie umfangreich das Programm ist. Schafft es die Steuerung nicht das Programm innerhalb dieser Zeit zu durchlaufen, geht sie idR in den Störzustand.

SPSen können ihren Zyklus nicht anhalten um auf etwas zu warten. Das müssen sie aber auch nicht, da man alles über Bedingte Aufrufe steuern kann. Es gibt aber auch noch die Möglichkeit Hardware-Interrupts bzw. extern getriggerte Taskaufrufe zu verwenden. Habe ich persönlich noch nie gebraucht und man kann sich damit auch eine Menge Sch.. eintreten.

Hier nochmal das Grundschema eines Zykluses, das jeder Student beigeprügelt bekommt :

Code:
|--------------------Zyklus-------------------|--------------------Zyklus-------------------|
|PEA einlesen |Programmdurchlauf|PAA schreiben|PEA einlesen |Programmdurchlauf|PAA schreiben|
PEA = Prozesseingangsabbild (Zustand der Eingangsbaugruppe + Busdaten)
PAA = Prozessausgangsabbild (Zustand der Ausgangsbaugruppen + Daten die über den Bus rausgehen)
(Die Buskommunikation kann auch unabhängig von Zyklus laufen, bei langsamen Übertragungsraten oder hohen Latenzen kann ein Buszyklus auch mal mehrere SPS Zyklen betragen)
 
Die Aktualisierung der Feldbusdaten, im Vorherigen mit PEA/PAA beschrieben hängt aber auch noch vom eingesetzten Bussystem ab.
Da mittlerweile bei den Beckhoff Steuerungen mehr EtherCAT verwendet wird als ein anderer Bus, muss man sich im Klaren sein, dass nach Programm-Ende das EA-Prozessabbild (PEA/PAA) aktualisiert wird.
 
Zurück
Oben