IRC5 Fehler: zu hohe CPU-Auslastung

[Hermann]

Hallole,
hatte vor kurzem folgenden Phänomen:
Roboterprogramm läuft in einer Endlosschleife in der eine ganze Reihe Eingänge
abgefragt werden, abhängig davon welche Eingänge gesetzt sind werden
verschiedene Aufgaben ausgeführt.
Soweit nichts besonderes.
Aber im Moment ist nichts zu tun, also steht der Roboter nur blöd in der Gegend rum ... und wartet halt.

Dann reagiert das Flex-Pendant nicht mehr, ich daddle rum und mach und tu, nix passiert.
Denke schon daran die alt bewährte Methode AEG anzuwenden, da erscheint folgende Meldung :

Meldung 40231: Zu hohe CPU-Auslastung
Das ausgeführte Programm enthält möglicherweise zu viele nahe beieinander liegende Roboterpositionen.
Es kann ausserdem zu viele logische Instrutkionen enthalten, die nicht durch eine ausreichend grosse zeitliche Verzögerung getrennt sind.

Da brat mir einer einen Storch. Muss ich jetzt schon Warteanweisungen zwischen einzelne logische Anweisungen einfügen?
Gibt es da einen Anhaltspunkt wie oft, wieviele und wie lange?
Warum ist das ein Problem?
Ist der Roboter mit dem Abfragen von ein paar Eingängen überfordert?

Gruss Hermann

[Sven Weyer]

Hi Hermann,
versuch es am Ende der Endlosschleife mit einem WaitTime 0.1. Hat bei der S4 ,S4c und S4c+ auch geholfen. Aber innerhalb der Schleife. 

Sven

P.S.: Ist ein Problem der Rechenzeitaufteilung.

[stefanM]

Hi Hermann,

hab zwar von ABB null Ahnung. Aber das hoert sich nach Multitasking an.
Ich kenn die Geschichte von unserem hauseigenen Controller - die Problematik ist genau die selbe.
Drueber sitzt ein Scheduler, dem man mit Wartezeiten unter die Arme greifen muss.
Mit I/O - Zugriffen kann man die Kiste in die Knie zwingen.

Bei Adept verhaelt sich das ganz aehnlich.

Gruss Stefan

[stromer]

Hi Hermann,

ich denke auch dass Dir ein WaitTime hilft. Bei Multitasking muss man den sogar einbauen (laut ABB) aber auch wenn die Haupttask ohne alles nur durchrennt kann es zu Problemen kommen (nicht nur bei ABB).

Gruß
Stromer

[Sven Weyer]

  Genau, obwohl ich auch schon S4c+ Steuerungen gehabt habe die dieses Problem nicht hatten

Sven

[Hermann]

Danke für die vielen Ratschläge mit dem waittime,
steht ja auch schon so in der Fehlermeldung, hat auch geholfen.

Aber vertehen kann ich das Problem nicht. Und bei anderen
Steuerungen ist mir das Problem noch nie untergekommen.
Würde echt gerne wissen was die da intern machen.

Anfangs habe ich da jede Menge waittime-Anweisungen eingefügt,
bei der aktuellen Anwendung spielt es keine Rolle,
Roboter hat ausnahmsweise mal genügend Zeit.

Aber anscheinend reicht ein einziges waittime 0.1 am Ende
der Endlossschleife, hab's gestern geändert und läuft jetzt auch
mit nur einer Wartezeit.

Hermann

[Sven Weyer]

Hi Hermann
ich versuch es mal:
Normalerweise vermeidet man in einem Hintergundtask Warteanweisungen da durch das warten auf ein bestimmtes Ereignis die anderen Bedingungen nicht mehr abgearbeitet werden. Und somit Dein Hintergrundtask je nach ablauf anfängt zu hinken. was für eine zuverlässige Abarbeitung nicht schön ist.
Zu der eingefügten Wartezeit von 0.1 sec. Bei nicht benötigter Rechenleistung bekommt diese ein Task zugeteilt welches diese benötigt. Nun musst Du die vorstellen das Dein Hintergrundtask ständig in einer Schleife läuft un immer wieder versucht etwas zu tun, dabei zählt schon das setzen eines Signals als nicht benötigte Rechenleistung, da dies ein anderer Prozessor übernimmt. So nun ist Dein Hauptask aber auch am Geschehen beteiligt bekommt aber keinerlei Rechenleistung freigegeben da der Hintergund die gesamte Leistung schon benötigt für das finden einer Entscheidung und somit für das freigeben von Ressourcen.
Hauptsache die Rechenzeit kann für eine bestimmte Zeit von einem anderen Task verwendet werden. Darum ist es auch problematisch mehrere Task zu verwenden. Ich sehe immer zu das ich für den Hintergund ein Task verwende so gestaltet sich die Aufteilung der Rechenzeit einfacher und es läuft stabiler.

Sven

[Hermann]

Schöner Text,
danke, aber leider habe ich nur eine Task am Laufen, nämlich das Hauptprogramm.
Ansonsten läuft da gar nichts (jedenfalls nicht von mir oder irgend einem anderen Anwender programmiert).

Habe nur ein einziges Programm, das als Endlosschleife aufgebaut ist,
in der werden ein paar Eingänge bzw. Variablen abgefragt, und je nach Status der Eingänge
werden unterschiedliche Aufgaben erledigt.
Genau den selben Programmaufbau habe ich schon mit
Kuka-, Bosch-, Fanuc-, weiss nicht was noch für -Roboter programmiert,
und nie ein ähnliches Problem gehabt.

Habe während des Studiums auch schon mal im Roboterbetriebssystem rumprogrammiert (Bosch) und kann mir da einfach keinen Reim drauf machen.

Hermann

[stefanM]

Hi Hermann,

auf Anwender Ebene gibt´s bei KUKA nur zwei Tasks - brauch ich dir ja nicht zu erzaehlen. Ich denke, der Grund ist klar.

Gruss Stefan

[gucky35]

Hallo Herman

Das Problem mit der CPU Auslastung ist das selbe wenn du ein PC Programm schreibst. Wenn du unter Windows oder Linux ein Programm mit einer „Endlosschleife“ schreibst, jagst du die CPU Auslastung auch auf 100%. 
Übertragen auf den ABB bedeutet das wenn du in deiner Schleife nur ein paar Eingänge oder Variabeln abfragst, ist das Rapid so schnell das, das Betreibsystem (VX-Woerks) nie den internen TASK zurück erhält und der Prozessor ständig auf 100% läuft.
Mit einem Waittime, Waituntil oder WaitDI übergibst du den Zugriff über den Prozessor wieder an das VX Works zurück.
Die alten Steuerungen wie S4 oder S4C wahren so langsam  in der Abarbeitung von I/O oder Variabeln das, das Problem nicht aufgetaucht ist.
Ich hoffe das klärt deine Frage.

Gruss

[Hermann]

Hallo gucky35,
wenn ich ehrlich sein soll, dann klärt das meine Frage nicht.
Besser gesagt, wenn es so wäre, dann bin ich etwas enttäuscht von dem
Echtzeitbetriebssystem, das ABB verwendet (VXWorks), bzw. von der Art,
in der es von ABB verwendet wird.

Soweit ich das in Erinnerung habe sollte VXWorks präemptives Multitasking beherrschen,
d.h. ich kann eine Endlosschleife programmieren, aber das Betriebssystem behält IMMER
die Kontrolle über die Rechenzeitverteilung der einzelnen Tasks.
Bei Windows und Linux erwarte ich das nicht, aber bei einem Echtzeitbetriebssystem
erwarte ich das schon.

Hat denn schon mal jemand irgend einen Hinweis zu der Sache in der Doku gefunden?

Hermann

[SJX]

Hallo Hermann,
in internen Dokus gab es früher zum Teil Hinweise auf diese Problematik.
Schon zur guten S4 mit Robware 2.0 Zeiten.
Man konnte in den Systemparametern gewisse Werte ändern, um dem leicht entgegenzuwirken.

Aber im Prinzip lebe damit.

Übrigens läuft beim KUKA wie diversen anderen Robotersystemen auch VxWorks drunter.
Bei KUKA auch schon solche Phänomene gesehen, nur da verabschiedet sich Windoof oder Bedienung wird sehr..... langsam.

Gruss SJX

[Hermann]

Ja klar kann ich damit leben, hatte nie etwas anderes vor.

Ich kenne einfach ganz gerne mal die Hintergründe, da hab' ich dann irgendwie ein besseres Gefühl, um Probleme zu erkennen und zu umgehen. Und ausserdem bin ich schon mein ganzes Leben lang extrem neugierig (kann ich jedem nur empfehlen  ).

Hermann

[gucky35]

Hallo Hermann
Du hast recht man sollte immer neugierg sein ! 
Deshalb hab ich ein bisschen gegoogelt  und mein DOKU durchwühlt.
Du hast recht VX Works ist ein präemptives Multitasking system (im übrigen Windows NT/ 2000 und Linux auch) aber es wird beim ABB von der Taskpriorität  gesteuert so viel ich weiß.
Nun besitzt der ABB intern 2 Hauptaskts 1. der Motion Task und 2. der I/O Task (Info von meiner letzten ABB Schulung). Der Motion Task hat die prio 1, wenn der Roboter da steht und auf ein Eingang wartet „schläft“ dieser Task. Aber der I/O Task arbeitet das Rapid ab. Das Betreibsystem gibt natürlich dem I/O Task die CPU da er sie ja ständig anfordert mit einer Endlosschleife. Wenn du jetzt über das PHG Eingaben machst werden diese vom PHG an den I/O Task weiter geleitet der aber immer noch mit der Schleife beschäftigt ist.
So weit meine Theorie.
Was ich noch im Internet gefunden habe ist das man bei Echtzeitsystem generelle ein Pollen vermeiden sollte. In einem C++ Buch wahr es recht treffend beschrieben. „Es ist blöd wenn eine Weich erst dann gestellt wird wenn das Pollinterwall abgelaufen ist.“
Macht auch irgendwie Sinn 
Ich glaube es ist besser wenn man Ereignisgesteuert programmiert. Ich  habe es fast immer mit Waituntil oder WaitDi hinbekommen. Das schöne am Waituntil ist, das man logisch Operanten wie „AND“ oder „OR“ verwenden kann und sich damit viele „IF  THEN“ und Schleifen sparen kann.
Ich gebe zu manchmal ist die Anforderung so komplex das es mit einer Schleife einfacher ist, bevor man sich ein wildes Konstrukt an Waituntil, TEST CASE oder  Prozeduraufrufen überlegt, wo sowie so keiner mehr durchsteigt. Vor allem wenn man kein Strukturgram hat. Aber mal ehrlich wer schreibt schon Strukturgrame . Es sei den der Kunde will es unbedingt haben .

Gruss