IRC5 Fehler: zu hohe CPU-Auslastung

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.

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

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

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

Sven

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

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

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 :sleep: in der Abarbeitung von I/O oder Variabeln das, das Problem nicht aufgetaucht ist.
Ich hoffe das klärt deine Frage.

Gruss

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

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