Beiträge von Programmiersklave

Zitat von buschke

Schon mal was damit gemacht?

Ja, Anlagenselbststart via SPS.SUB, und vermutlich ist es genau das, was man bei KUKA verhindern will.
Den Treiber muss man sich von einer älteren Anlage kopieren, die INI auch, aber da steht eh nix drin. In der iosys.ini dann den Eintrag unter [DRIVERS] anlegen (ist ja nicht mehr auskommentiert schon dort)

O2I=31,o2iInit,o2i_drv.o

und dann die Konfiguration unter [O2I] à la

[O2I]
INW0=0       ;$IN[1-16]
OUTW0=0      ;$OUT[1-16]

was im Beispiel das erste Ausgangswort auf das erste Eingangswort mappt.

Funktional den gleichen Dreck mache ich mit ABB's Hintergrundtasks und Cross-Connections auch, und ob mir ein SPS-Programmiergott wahnsinnige Signale liefert oder ich mir den Code selbst schreibe.. darauf kommt es wohl auch nicht an.

Grüße,
Michael

Ist das das Ding mit dem Mauszeiger-Move? Ja...
Der archiviert seit einem Jahr treulich bei 6 Robotern jeden Tag um 14:11 Uhr (warum nicht um 14:11? Ist genausogut wie jede andere Zeit) alles auf die Festplatte, entsprechende Einstellung im Konfigurator und im Taskplaner vorausgesetzt.
Das andere habe ich noch nicht gebraucht, da man im Konfigurator die Archivierungsfunktion so einrichten kann (zumindest bei den aktuellen Kukas), dass automatisch eine Sicherungskopie erzeugt wird mit Datumsnamen, und davon maximal 10. Die jeweils älteste wird automatisch gelöscht.

Grüße,
Michael

Zitat von Morusa

- Besteht überhaupt Bedarf an so einem Programm?

Halte ich für eher unwahrscheinlich.

Zitat

- Wenn ja: In welchen Situationen / zu welchem Zweck würde man es einsetzen?

Mir fällt keiner ein.

Schließlich sind die Punkte ja schon vorhanden.
Umgekehrt wird was draus - das nähert sich dann Richtung Offline-Programmierung. Mit FAMOS z. B. lese ich ja auch bestehende Programme ein und sehe dann in einer 3D-Ansicht den Weg des TCP. Aber dann muss es das irgendwann auch umgekehrt tun, der Roboter ist ja eine Bewegungsmaschine...
Und schließlich sind die Orientierungen ja auch nicht gerade so unwichtig, dass man sie komplett unter den Tisch fallen lassen dürfte

Ich könnte mir vielleicht eine Meßanwendung vorstellen - mit einer Meßmaschine fährt man ja auch vorgegebene Punkte an und protokolliert dann die Abweichung. Das werden dann aber schwerlich Roboterpositionen; bzw. da gibt es dann *zig bessere Möglichkeiten.

Grüße,
Michael

http://www.roboterforum.de/rob….0.html;msg17452#msg17452

Auf der mitgelieferten CD ist RobotStudio (wenn es sich um einen neuen Robbi handelt). Das brauchst Du sowieso (selbst wenn es hinterher nur noch die eingeschränkte Version ist). Dessen Hilfe-System (Fragezeichen rechts oben - dann Rapid Referenzhandbuch) erklärt eine Menge!

Grüße,
Michael

Stichwort WaitSyncTask, der sollte das eigentlich tun... aber...
ich hatte schon mal Probleme, wenn man diesen Synchronisierbefehl ganz am Anfang nach dem Start verwendet.
Tatsächlich wird "WaitSyncTask" ignoriert, wenn einer der Tasks nicht läuft. Weil die Tasks aber nicht exakt gleichzeitig loslegen, kann es passieren, dass der erste schon durchgerauscht ist, ehe der zweite in die Gänge kommt. Für zwei Robbis hatte ich dann immer so einen Handshake gemacht, der über virtuelle Ausgänge funktionierte. Bei mehr als zwei würde ich etwas Ähnliches machen: für jede Task einen virtuellen Ausgang, der sogleich nach dem Start für 1 Sekunde auf high gepulst wird. Dann eine Cross-Connection, die alle verUNDet, und jede Task wartet dann auf den Resultant. Anschließend kann man ziemlich sicher sein, dass alle laufen.
Sollte die Startzeitdifferenz mehr als eine Sekunde betragen, ist sowieso was faul.
Oder so.

Grüße,
Michael

Zitat von WolfHenk

Die Bremsen kommen sofort und hart....

Meiner Kenntnis nach bremst er vorher aber noch generatorisch.

Grüße,
Michael

Wenn die Programme erst geladen werden müssen, mache ich mir ein Modul mit einer Hauptschleife, die immer läuft und in der die übergeordnete Logik steckt, auch die zur Kommunikation mit der SPS. Anschließend werden mit "später Bindung" die benötigten Module geladen und deren Bearbeitungsroutine aufgerufen.

if (prg_intern > 0) then
            Load "HOME:P"+programmname{prg_intern}+".MOD";
            Load "HOME:D"+programmname{prg_intern}+".MOD";
            Load "HOME:F"+programmname{prg_intern}+".MOD";
  else
          TPwrite"Achtung! Kein Programm angewaehlt!";	
  endif

Ein bisschen knifflig ist die (sichere) Entfernung geladener Module, insbesondere, wenn man nicht ganz sicher ist, was jetzt eigentl. geladen ist. Vielleicht gibts da inzwischen was, ich hab es damals mal so gemacht:

!!####################################################################################
!!-->Alle Programme entladen
!!####################################################################################
proc rUnloadAll() 


var byte iii;
var num fk;


iii:=1;
while (iii<=20) do
				unload \save, "HOME:P"+programmname{iii}+".MOD";
				unload \save, "HOME:F"+programmname{iii}+".MOD";
				unload \save, "HOME:D"+programmname{iii}+".MOD";
				incr iii;
ENDwhile


 Error
      test ERRNO 
        case ERR_MOD_NOT_LOADED:
          !Im Falle, dass das Modul nicht geladen ist (in 19 von 20 faellen das normale)
          TryNext;
        case ERR_NOTSAVED:
          !Sollte eigentlich nicht vorkommen, zumal die Option nicht gewaehlt ist
          TryNext;
        case ERR_UNLOAD:
          !Problematisch!
          if (programmname{iii} = programmname{Prg_old}) fehler "Kann nicht entladen", "Das Modul "+programmname{iii}+" konnte nicht vollstaendig entladen werden.";
          trynext;
        default:
          fehler "Unbekannter Entladefehler", "Beim Entladen der Module entstand ein unbekannter Fehler.";
          trynext;
      endtest
endproc

.

Wenn die Module im Speicher bleiben können, ist es eh egal, und man kann die benötigten Programme einfach aufrufen, auch wieder mit %"string_selbstgestrickter_Routinenname%;

Grüße,
Michael

Interrupts funktionieren in allen Tasks unabhängig, soweit ich das kenne, ohne Probleme.
Man muss bei dieser Anwendung aber dann dafür sorgen, dass die anderen Tasks nicht einfach weiterlaufen, wenn man mit einem eine Grundstellungsfahrt macht, logisch.

Grüße,
Michael

Ich würde beim Messen werkstückführend fahren ($IPO_MODE=#TCP), und so aus dem eingemessenen TCP ein BASE machen und aus dem fotografierten Punkt ein TOOL. Dann den Punkt teachen, und die Abweichung steht unmittelbar im geteachten Frame. Oder?

Grüße,
Michael

Hallo,

Zitat von Pooltechnik

keinerlei Kenntnisse [...] Freiformfräsen [...] mit KRC1 Steuerung [...] CAD-Daten

DIE Kombination klingt für mich übrigens so richtig schlecht.
Die KRC1 ist eine Zicke, die muss man sehr liebevoll behandeln, damit sie überhaupt was macht. Freiformfräsen nach CAD-Daten hört sich nach "sehr viele Bahnpunkte" an, was die KRC1 aber gar nicht mag; da wären wohl wieder Spezial- und Bastellösungen gefragt. Es schreit ebenfalls nach OLP, aber ein Programm dafür müsste man sich selbst schreiben, wenn es kostenlos sein soll.
Je nach Anwendungsfall gibt es im NC-Bereich für 3-Achser ein paar Freeware- und Billigware-Programme, deren Output man mit einem geeigneten Script vielleicht nachträglich robotertauglich bekäme, nur wäre das Ergebnis wohl weder schön noch gut.
Die Aufgabenstellung würde ich nicht haben wollen....

Grüße,
Michael

Hab' keinen Nerv, die Sache bis ins Letzte verstehen zu wollen, aber kann es sein, dass einer der Kreise dann "umklappt", der Bogen zu groß wird oder gar andersrum angefahren werden will? In Deiner Rechenschleife sind ja nur zwei MoveC, der Ausgangspunkt gehört aber immer dazu. Könnte mir vorstellen, dass in dieser Hinsicht was schiefgeht.
Lass Dir den berechneten Punkt doch mal anzeigen in der Datenansicht, bevor der Fehler erscheint, und schau, wo die Berechnung hinfahren möchte, dann siehst Du mehr....

Grüße,
Michael

Fehler würde ich das jetzt nicht nennen, denn prinzipiell macht jeder seinen Part richtig, aber...
ich kämpfe immer mal wieder gern mit der Achskonfiguration. Im Roboter ergibt sich die ja quasi "automatisch" nebenher, wenn man ein Programm teacht, der Arm steht "irgendwie", und man sieht, das ist gut so. In der Simulation muss etwas Vergleichbares passieren - es ist aber nicht immer gegeben, dass dasselbe passiert wie im Roboter.
Ein ähnliches Schlachtfeld existiert in der Nähe von Singularitäten, insbesondere, wenn man im realen Roboter veränderliche Toolmaße hat. Eine gute Simulation warnt in der Nähe von Singularitäten.

Schlecht simulieren lassen sich Kabelführungen, Schläuche etc., so dass man in der echten Zelle gelegentlich Kabelsalat produziert, wenn man sich blind auf die OLP verlässt.

Gerne vergessen wird der Einfluss der Peripherie in der echten Zelle auf die Zykluszeit, wenn man mit der Simulation knapp kalkuliert. Simulierte Zykluszeiten sind mit Vorsicht zu genießen.

Grüße,
Michael

haben die Fächer regelmäßige Abstände? Dann ohne "if". Am besten immer ohne "if"-Verschachtelungen. Case dürfte auch unnötig sein. Du brauchst bei dieser Sache eigentlich keine Fallunterscheidungen, weil Du einen leicht interpretierbaren Input bekommst.
Einfach die Position errechnen und zuweisen, je nach Ausgabe der SPS. Im allerschlimmsten Fall, wenn die Fächer unregelmäßig angeordnet wären, könnte man sich einen 2-dimensionalen Array machen, in welchem die Positionen hinterlegt sind, und dann auf diese Tabelle zugreifen.
Und dann einfach hinfahren.
Die Bewegung innerhalb der Fächer würde ich relativ machen. Im Idealfall also verschiebt man einfach nur das aktuelle BASE vor/in das gewünschte Fach und lässt den Roboter zusehen, wie er hinkommt.

Grüße,
Michael

Zitat von Paulaner

Bei solchen Meldungen kann auch dein Syntaxfehler vor der eigentlichen Zeile sein.

Müsste sogar, sonst würde die Fehlermeldung nicht lauten: "unerwartet".
Der Compiler wird von diesem Ausdruck also überrascht, weil er sie nicht erwartet hat. Erwartet hat er was anderes.
Zu bedenken ist, dass dem ABB Zeilenumbrüche egal sind. Man kann innerhalb von "Programmzeilen" Umbrüche machen. Befehle werden abgeschlossen durch ";". Weitere Klammern sind die bekannten Schlüsselwörter, die Schleifengrenzen oder Funktionsgrenzen definieren.
Es reicht also, wenn irgendwo oberhalb was falsch geschachtelt ist.

Grüße,
Michael

An manchen Stellen ist eine Zufallszahl echt hilfreich, um einer Programmlogik auf die Sprünge zu helfen.
Ich hab' mir schonmal Istwerte der Achsen ausgelesen, die letzte anzeigbare Stelle nach dem Komma, und dann rechnerisch verhudelt. Da schwankts ja immer ein bisschen.

Grüße,
Michael

Zitat von bumblebee

Ist es so zu verstehen wie die Offs?

Es gibt halt viele Wege nach Rom....
Meine Anregung war, die Verschiebung nicht auf den Punkt draufzurechnen, sondern auf das zugrundeliegende Basiskoordinatensystem. offs() rechnet eine Verschiebung auf ein Robtarget, geht auch, geht gut, kein Problem. Man könnte auch mit PDispSet etc. arbeiten, zum Beispiel.
Ich halte solch reine Verschiebungsaufgaben gerne aus dem Bewegungsprogramm raus, das simplifiziert die Sache manchmal etwas. Das OFrame des Werkobjekts ist ungefähr für diesen Zweck gut geeignet.
Meine Variable "XShift" ist an sich verzichtbar, man könnte natürlich auch direkt dem woTemp.Oframe.Trans.X einen Wert zuweisen, aber mit einem kleinen Zwischenschritt wird's manchmal besser verständlich. [size=6pt](Und über MEINE Variablennamen sollte man sowieso besser nicht nachdenken. Hier im Forum halte ich mich zurück, aber in meinen realen Steuerungen kann ein Merker auch schon mal "Herr_Schroeder" heissen.... großer Hassfaktor, aber genialer Wiedererkennungswert.)[/size]

Grüße,
Michael

Zitat von bumblebee

Wie ist es eigtl., wenn ich zuerst eine position programmiere und dann kreise,
werden diese zwei routinen dann nacheinander abgearbeitet?

Man muss schon eine Schleife aussenrum programmieren.

proc schleife()
var num z;
var num Xshift;
var num Yshift;
var num wdh;


!X und Yshift muss natürlich jetzt irgendwie zugewiesen werden, wie auch immer
xshift:=2.5;
yshift:=0.0;
!die Anzahl der Wiederholungen könnte man sich ja auch berechnen, wie man will
wdh:=14


 woTemp:=woArbeitstisch;


!optional
 MoveL startposition,....\wobj:=woTemp;


for z from 0 to wdh do
  kreisroutine(startposition, durchmesser);
  !Werkobjekt verschieben
  woTemp.Oframe.trans.x:=Xshift*z;
  woTemp.Oframe.Trans.y:=Yshift*z;
endfor


!Durch die Zuweisung vorher nicht explizit nötig, aber zur eigenen Erinnerung vielleicht, dass man die Verschiebung wieder ganz zurücksetzt:
woTemp.Oframe.Trans:=[0,0,0];


endproc








proc kreisroutine(robtarget anfpos, num dia)


!ich mach immer gern was, um groben Unfug von vornherein zu unterbinden:
  if (dia<1.0 or dia>100) return


!und jetzt eben:
  moveL anfpos,....\Wobj:=woTemp;
  moveC offs(anfpos,(dia/2),(dia/2),0),offs(anfpos,0,dia,0),...\wobj:=WoTemp;
  moveC offs(anfpos,(dia/-2),(dia/2),0),anfpos,...\wobj:=WoTemp;
!Hier sind wir wieder am Startpunkt
endproc

Das Ganze dann beliebig kompliziert machen.

Grüße,
Michael

Zitat von titan72

mit Weltzonen für die Absicherung und den zusätzlichen Signalen zur Anforderung, Sperrung und Freigabe der Bereiche

Man denkt sich im Laufe der Jahre ganz dolle Sachen aus, solange man nur ZWEI Roboter gegeneinander verriegelt. Die meisten davon sind allerdings wenig wert, wenn man dann mal DREI oder mehr in demselben Arbeitsbereich hat. Der Aufwand wächst quadratisch mit der Zahl der beteiligten Manipulatoren. Am Ende denkt man sich dann, dass vielleicht doch eine Sicherheit ausreicht, die nur 99,5 Prozent aller denkbaren Fälle abdeckt.

Grüße,
Michael

Wenn es jetzt eine industrielle Anwendung wäre, würde ich sagen: mach 'ne Unterroutine, in welcher Zwischenpunkt und Endpunkt von beiden Kreissegmenten berechnet werden (bezogen auf die Istposition oder mit offs(..)), fahr irgendwo hin, und rufe von da aus diese Routine zyklisch auf. Nach jeder Bearbeitung verschiebst Du das Gebrauchswerkobjekt im OFrame in die Richtung, die Du gerne hättest, fertig.
Eine Spirale ist das ja auch nicht, das sind nur überlappende Kreisbahnen, die mit einem kurzen LIN-Stück hintereinanderhängen.

Grüße,
Michael