Inhaltsverzeichnis
Werbung
148/169
Bosch Rexroth AG
Programmierhinweise
7.5.10
Fehlerhandling
7.5.11
Codeoptimierung
Anforderungen an das Echtzeit‐
verhalten der Applikation
Tasksystem
Stringverarbeitung
Rexroth HydraulicDrive Rexroth IndraMotion MLD (2G) ab HDx-18
3
Flankengesteuerte Bausteinbearbeitung wurde unterbrochen
Abb. 7-5:
Signal-Zeitverhalten von flankengesteuerten Funktionsbausteinen (mit
Eingang "Execute"); bei Einzelachsen wird der Ausgang "Active" nicht
gesetzt!
Das Fehlerhandling ist für Funktionsbausteine von Bosch Rexroth standardi‐
siert; es ist in drei Diagnosestufen eingeteilt:
●
Stufe 1: Der Ausgang "Error" zeigt an, dass ein Fehler ansteht, wenn er
TRUE ist. "Error" ist vom Typ BOOL.
●
Stufe 2: Ein Enumerator ("ErrorID") gibt Grobinformation über den Feh‐
ler (grobe Zuordnung)
●
Stufe 3: Für Detailinformationen gibt es eine Struktur ("ErrorIdent"), in
welcher der Fehlerursprung sowie der genaue Fehlercode ausgelesen
werden kann.
Siehe auch
Kap. 4.6 "Fehlerbehandlung der IndraMotion MLD" auf Seite 59
Antriebsregelung und antriebsintegrierte SPS teilen sich die Rechenleistung
des Antriebs, wobei die Antriebsregelung einen Großteil der Rechenleistung
des Antriebs einnimmt. Um die verfügbare Rechenzeit optimal ausnutzen zu
können, ist zunächst zu prüfen, welche Anforderungen an das Echtzeitverhal‐
ten der Applikation gestellt werden:
●
Welche Funktionalitäten müssen in bestimmten Zeitabständen oder bei
bestimmten Ereignissen aufgerufen werden?
●
Was geschieht, wenn eine Funktion nicht zum gewünschten Zeitpunkt
beendet ist?
●
Ist es notwendig eine FKM-synchrone oder CCD-synchrone Task einzu‐
setzen?
Aus den Anforderungen an das Echtzeitverhalten der Applikation ergibt sich
ein erster Ansatz an die Taskkonfiguration der Applikation. Generell sollten
mehrere Tasks dazu eingesetzt werden, um Funktionen mit großen Laufzei‐
ten von Funktion, die in Echtzeit laufen müssen, zu trennen. Jede Task benö‐
tigt Rechenzeit für die Verwaltung und Steuerung des Tasksystems. Je mehr
Tasks konfiguriert sind, desto mehr Rechenzeit muss für die Verwaltung der
Tasks aufgebracht werden.
Generell sollte in zeitkritischen Tasks nur der notwendige Code durchlaufen
werden. Auf zu kurze Intervalle bei den Tasks sollte verzichtet werden.
Eine Aufteilung in verschieden schnelle Tasks ist nur sinnvoll, wenn relativ
wenige Aktionen sehr schnell abgearbeitet werden müssen und andere Aktio‐
nen in einer langsameren Task laufen (z. B. eine Task mit t#1ms und eine
Task mit t#10ms).
Außerdem ist zu prüfen, ob bei einmaliger Tasküberschreitung bereits ein
Watchdog ausgelöst werden muss oder dieser toleranter sein kann.
Alternativ zu einem Mehrtasksystem können in einer Task zu‐
nächst alle schnellen Aktionen durchgeführt werden und dann je‐
weils nur eine langsamere Aktion (CASE-Anweisung).
Wenn allerdings die langsameren Aktionen mehr Rechenzeit be‐
nötigen, ist es notwendig, sie in einer eigenen Task auszuführen.
Die Verarbeitung von Strings ist relativ langsam. Bei schnellen Taskzyklen
möglichst vermeiden.
DOK-HYDRV*-MLD3-**VRS*-AP01-DE-P
Werbung
Inhaltsverzeichnis
