Beiträge von Programmiersklave

  • Werkzeug ändern

    Wie "Sat"? Verstehe nicht, worum es geht.
    Ein Tool beim ABB ist eine Struktur, die ungefähr so aussieht:
    TASK PERS tooldata Spitze:=[TRUE,[[-299.941,84.5786,130.844],[0.477714,-0.477714,-0.521334,0.521334]],[52.8,[23.4,-15,110.2],[1,0,0,0],2.173,2.55,1.26]];
    und ist erreichbar in der Datenansicht über "Tooldata".
    Wenn Dir das Programm selbst die Tooldaten überschreibt, wird es seine Gründe haben, die ich an Deiner Stelle erst gründlich erforschen würde. Könnte nämlich seinen Sinn haben.


    Grüße,
    Michael

  • Programmzeiger anhalten und auf Bewegungszeiger warten?

    Na ja, da kann man sich ja Notausgänge programmieren. Man muss nur dran denken... blöd, wenn der Kunde anruft, weil sich der Roboter kunstvoll selbst blockiert.


    Es kommt bei der Herangehensweise vielleicht auch darauf an, welches Ziel man verfolgt:
    1.) der Roboter soll so schnell wie möglich und am besten unterbrechungsfrei eine Bahn fahren, deren Freigabe erst im allerletzten Moment erfolgt
    2.) der Roboter soll nicht in einen Bereich einfahren, der durch eine externe Bedingung im allerletzten Moment verboten wird.
    3.) beides


    Für den zweiten Fall kann man sich notfalls eine programmtechnische Abfrage machen, die nicht vollständig synchron arbeitet, jedoch zusätzlich am Programm vorbei mit Weltzonen arbeiten bzw. mit Systemeingängen oder so etwas. Falls etwas schief geht, stoppt die Anlage dann halt hart. Der erste Fall ist einfach nur lästig, geht aber nur im Programm.


    Was die Interrupts angeht, habe ich in der Praxis allerdings selten Probleme gehabt. Im "normalen" Programmablauf verwende ich Interrupts nicht so oft, dass sich da was überkreuzen könnte.


    Grüße,
    Michael

  • Roboter verschieben

    Gegen die Konfigurationsdaten hilft ja auch, sie einfach zu löschen. Macht man aus einem POS einen FRAME, werden auch PTP irgendwie angefahren... nur eben so, wie der Roboter will. Je nach Programmstruktur reicht das aber auch schon.
    Nur was die achsspezifisch geteachten Punkte angeht wüsste ich keinen vernünftigen Rat. Ich würde mir in UltraEdit ein JavaScript für die Ersetzungsaufgabe machen, wenn es sich lohnen würde.


    Im Idealfall lade ich mir die Situation natürlich in ein OLP (in meinem Fall Famos) und erzeuge den ganzen Quatsch einfach neu....


    Grüße,
    Michael

  • Programmzeiger anhalten und auf Bewegungszeiger warten?

    Für Trap-Routinen gelten ja auch wieder ganz andere Einschränkungen, aber prinzipiell geht das. Man hat dann sogar noch extremere Möglichkeiten, weil man den Interrupt auf die fallende Flanke setzen kann und den dazugehörigen virtuellen DO mit einer definierten Zeit pulst und solche Scherze... steigt nur keiner mehr durch.
    Wobei mir die Interruptverarbeitung beim ABB genauso suspekt ist wie der Vorlaufzeiger. Beim KUKA kannste 'ne Priorität festlegen, beim ABB geht das nicht, da werden die Interrupts in einem Stapel gespeichert und nacheinander abgearbeitet. Das heisst, wenn gerade zu der Zeit ein anderer Interrupt aktiv ist, wird der für die Zonenfreigabe erst ausgewertet, wenn der andere fertig ist.


    Grüße,
    Michael

  • Programmzeiger anhalten und auf Bewegungszeiger warten?

    Zitat von Dragon


    Möchte dies verwenden um abzufragen ob eine Kollisionszone frei ist…


    Mit dem Thema ärgere ich mich gerade auch wieder rum. Der Robbi steht im Sägeschnitt und wartet auf die Zone, wobei der Wartebefehl mit der Bedingungsüberprüfung erst programmiert ist, wenn die Sägebahn komplett beendet ist.
    Mit MoveLSync oder MoveJSync würde es vielleicht gehen, aber da wird es wieder hässlich mit der Parameterübergabe...


    Grüße,
    Michael

  • Fehler beim Laden von //MACHINE ( Kuka KR-16 )

    Zitat von m.c.zapp

    Wie gesagt, der Roboter wurde in unserem Hause erstmals eingeschaltet, war noch alles so, wie ihn KUKA ausgeliefert hat.
    Da kann ich mir nicht vorstellen, dass die HDD schon langsam ihr Leben aushaucht!??


    Ist schon 11 Jahre her, aber... drei Kukas in einer Linie erstmalig eingeschaltet, keiner bootete. Bei einem fehlte die HDD ganz, beim zweiten war der Stecker nicht drauf, und was der dritte hatte, habe ich vergessen... von daher...


    Grüße,
    Michael

  • im radius um einen punkt fahren ?? IRC5

    Pass bitte auf bei diesen 180° - Fahrten.
    Die Maßgabe für den Robbi lautet: "fahre von Anfangsorientierung zu Endorientierung". Bei exakt 180.0000 Grad ist sich der Roboter nicht unbedingt sicher, wie herum er diese Orientierungsänderung fahren soll. Der Zwischenpunkt hat dabei keinen Einfluß, deswegen kann da u. U. ne böse Überraschung passieren. Ich präferiere deshalb die Verwendung von mindestens 3 Kreissegmenten.


    Ich würde auch eher ungern mit offs() arbeiten, da sich das auf das Wobj bezieht und nicht auf die Orientierung des Punktes. Weiß ja nicht, was Du als Ausgangsposition benutzt, ich würde halt beim Teachen versuchen, den Punkt senkrecht zur Oberfläche auszurichten. Wenn die Oberfläche allerdings selbst topfeben ist und parallel zum Wobj, dann ist diese Lösung hier eher unbequem, und man sollte Raumbezogen arbeiten (mit offs).


    Wenn ich es machen würde, würde ich zuerst auf Schönheit verzichten und mir die Punkte im Voraus ausrechnen. Dadurch kann man in der Datenansicht beim schrittweisen durchsteppen schon mal schauen, was eigentlich passiert.


    Zwei Arrays mit reichlich Positionsdaten und einer mit Targets, sodann noch ein paar Container:

    Code
    var pose erster_schritt{7};
var pose zweiter_schritt{7};
var pose rechenpose_winkel;
var pose rechenpose_radius;
var pose mittelpunkt;
var robtarget kreispunkte{7};
var byte z;


    Dann für den ersten Schritt:



    An dieser Stelle hast Du einen Array mit dem Mittelpunkt, 6-Fach verdreht um jeweils 60 °. Der letzte um 360° verdreht, der sollte also hinterher genauso aussehen wie der 1., der mit 0° verdreht wurde. Die Poses mit Index 1 und 7 sind somit eigentl. überflüssig, aber es geht ums Prinzip.
    Achso: die Verdrehung geht hier um z des Mittelpunktes, also um den e3-Vektor. Ich gehe hier also davon aus, dass Dein Messer in der Längsachse z ist und x die Schnittrichtung.


    im zweiten Step dann den Radius draufrechnen. Ich mache hier in Y:


    Code
    zweiter_schritt{z+1}:=posemult(erster_schritt{z+1},rechenpose_radius)


    Jetzt hat man die Positionen berechnet, leider kann man eine Pose nicht komplett in ein Robtarget holen. Also einzeln:


    Code
    kreispunkte{z+1}:=pCentrPoint;
 kreispunkte{z+1}.trans:=zweiter_schritt{z+1}.trans;
 kreispunkte{z+1}.rot:=zweiter_schritt{z+1}.rot;


endfor


    Hier endet die FOR-Schleife, und in allen 7 Punkten steht jetzt ein Ziel drin, Natürlich mit falschen Konfigurationsangaben.
    Also ConfL \off und fahren
    movel kreispunkte{1} ... Messer eintauchen
    movec kreispunkte{2}, kreispunkte{3}... erstes Segment
    Dann 4 und 5 zweites Segment
    dann 6 und 7 drittes Segment.
    Auftauchen dann beliebig relTool(0,0,-30) oder so....


    Nur mal so aus der Hüfte geschossen, wenn auch ohne Gew(a)ehr.


    Grüße,
    Michael

  • im radius um einen punkt fahren ?? IRC5

    Zitat von roboprog


    weis jemand von euch ob der abb das überhaupt bringt ?


    Bringen musste das wohl größtenteils selbst. (Wobei, in den uralten Waterjet-Anlagen war schon so 'ne Funktion drin, aber natürlich ohne Umorientierung des Werkzeugs.)
    Ist aber erstmal nicht schwer, würde ich sagen: Eine Routine schreiben, die ein paar Parameterchen haben will, wie Mittelpunkt, Radius, Schnittgeschwindigkeit usw.
    Dann vom Mittelpunkt aus 5 oder 7 Punkte berechnen (Stichwort PoseMult), einen Startpunkt und dann mindestens zwei Kreissegmente, die zusammen 360 Grad machen. Die Orientierung ergibt sich ja aus dem Zielpunkt, dann nacheinander abfahren mit MoveC.
    Entsprechend kann man freilich noch Anfahr- und Rückzugspunkte festlegen.


    Wie immer gibt es mehrere Wege nach Rom, man könnte das vielleicht auch mit offs(..) realisieren oder besser noch mit RelTool(...), das sind ja auch nur Funktionen, die eine Pose zurückliefern; je nachdem, ob die Schnittebene von der Ausrichtung des Mittelpunkts bestimmt werden soll oder eher nicht.


    Wnn man den Luxus liebt, extrahiert man vorher noch aus den Konfigurationsdaten oder aus dem Achswinkel von A6 die nötigen Informationen, ob man rechts- oder linksrum schneiden will bzw. ob man die Achse vorher "aufzieht", da man ja beim Schneiden am Ende +- 360° mehr drauf hat als vorher.


    Grüße,
    Michael

  • Array als : IN uebergeben

    Explizite Ausnahme bei KRC4 sind Zeichenketten (Strings), die darf man auch :IN übergeben; was merkwürdig inkonsequent ist, da jedes Zeichen wieder nur eine andere Darstellung eines Byte ist. Wer's also unbedingt braucht, kann sich auf dem Umweg über Strings eine - wenn auch optisch befremdliche - Notlösung schaffen.


    Grüße,
    Michael

  • WorkVisual - viele Änderungen übertragen, obwohl nix geändert wurde ?!?!

    Zitat von SpeedFreak


    gibts hier noch andere nutzer von workvisual, die ähnliche abenteuer hinter sich haben, oder bin ich der einzige, der zu blöd ist?


    Nein, auch ich bin zu blöd.
    M. E. liegt das (also nicht die Blödheit ;), sondern das Primärproblem) am Umstand, dass dem WorkVisual nicht alle Infos zur Verfügung stehen, die es braucht, und es dann eigenmächtig versucht, die fraglichen Dateien zu ändern.


    Man kann z. B. auf einer Anlage mit Proconos Soft-SPS durchaus im "alten" Stil an WV vorbei über Multiprog die SPS programmieren. WV kriegt davon nichts, gar nichts mit, selbst wenn der Quellcode auf der Steuerung gespeichert wurde, denn das scheint auf andere, externe Projektdateien auf der Steuerung zurückzugreifen. Der nächste, der das WV-Projekt von der Steuerung holt und neu übersetzt, hat dann ins Klo gegriffen. "Zusammenführen" bringt dann auch nix mehr, weil schon die Information darüber, was eigentlich zusammengeführt werden soll, falsch ist.


    Ähnlich scheint es sich zu verhalten, wenn im Ursprungsprojekt eigene Gerätedateien verwendet wurden. Irgendein Buskoppler, der nicht im Standard-WV enthalten ist, wurde eingebunden. Dein WorkVisual weiss davon nur rudimentär, es findet die Dateien natürlich nicht im Projekt, sondern nur die Information, dass diese Datei gebraucht wird. Trotzdem löscht es erst einmal die komplette EA-Konfiguration, die sich auf dieses Gerät bezieht. (So habe ich es jedenfalls mal erlebt, weiss nicht, ob das in den neuen Versionen besser ist.)I
    Das Unheil ist schon geschehen, wenn Du das Projekt öffnest. Später, beim Zusammenführen, scheint da gar nichts mehr auszurichten zu sein.


    Oder es liegt doch an der Blödheit. Dann besäße ich allerdings die Vermessenheit zu behaupten, WorkVisual sei blöd, und nicht wir.


    Grüße,
    Michael