Posts by Hermann

    Frei nach Radio Eriwan:

    Im Prinzip ja, aber es ist nicht so ganz trivial.

    Fürs erste würde reichen an den Fahrbefehl ein 'c_dis' anzuhängen und vor die Zeilen mit der Eingangsabfrage ein 'continue' zu setzen. Dann hat man aber das Problem, dass der Roboter 'nachläuft', d. h. er stoppt nicht sofort nach Signalwechsel am Eingang, sondern fährt weiter bis der Vorlauf abgearbeitet ist.

    Normalerweise sind das dann noch drei Schritte, kann man über das Setzen der Variablen $Advance auf 1 verringern.

    Um das komplett zu verhindern muss man dann jeweils per Interrupt und Resume die Bewegung abbrechen. Dazu muss man dann aber jeweils die Bewegung in ein Unterprogramm auslagern.

    Also durchaus machbar.

    Morgen, ich habe mir die Deklaration eigentlich von der XHOME kopiert, da steht es so drin.

    Kann nicht sein.

    Bei solchen Problemen ist es deutlich besser die aktuellen Dateien zu posten, und auf keinen Fall nur die betreffenden Zeilen, womöglich noch aus dem Gedächtnis heraus zu zitieren. Da sind Tippfehler und Erinnerungslücken vorprogrammiert.

    In dem konkreten Fall tippe ich auf einen Tippfehler, und zeitweise/partielle Betriebsblindheit, passiert jedem mal ;).

    So ganz grob passt das schon,

    Allerdings frage ich mich warum Du KameraX und KameraY auf den x-Wert addierst und nicht x auf X und y auf Y?

    Code
    Schraube_10.trans.x:=(Schraube_10.trans.x+KameraX);
    Schraube_10.trans.y:=(Schraube_10.trans.y+KameraY);

    Das setzt dann aber voraus, dass Kamera- und WerkobjektKoordinatensystem gleich ausgerichtet sind, die Kamera mm-Werte rausgibt und sauber kalibriert ist.

    Mal noch einen paar generelle Hinweise für das Installieren von neuen Versionen, wie ich da vorgehe:

    1. Image erstellen (KUKA USB-Stick)

    2. Option vom USB auf Festplatte D: kopieren

    3. Dann Installation von D:.

    4. Niemals den USB-Port am SmartPad verwenden, immer den am Schaltschrank. Durch dieses verkorkste Konzept der zwei Windows Systeme in einem Roboter sind die USB-Ports am Smartpad auch über die Remote Desktop Verbindung an den Rechner gekoppelt. Das ist langsam und fordert Fehler geradezu heraus.


    Hatte da bisher nie Probleme, und musste noch nie auf das Image zurückgreifen.


    Da ich da bisher noch nie Probleme hatte, weiss ich jetzt nicht, wie man im Fehlerfall den Start aus dem Hybernate im Fehlerfall verhindern kann. Auf alle Fälle benötigt man da den Bildschirm und eine Tastatur, bei den normalen und älteren Windows Systemen musste man da während des Bootens die Shift- oder Strg- Taste drücken, afair.

    .. alles ausgewählt und hochgeladen.

    Was genau bedeutet 'hochgeladen'? Mit welchen Bedienschritten, und wohin hochgeladen?


    Selbst nach Steuerung AUS/EIN wird immer noch dieser Ladebildschirm angezeigt?


    Smartpad Abziehen/Neustecken bringt in solchen Fällen nix. Im Smartpad steckt ein eigener Rechner mit Windows, der sich per Remote Desktop auf den Roboter einloggt. Wenn auch nach Aus/Ein der Bildschirm noch so angezeigt wird hängt der Rechner im Steuerschrank. Evtl. ist da der Hybernate mode eingestellt, dann speichert der PC beim Ausschalten seinen aktuellen fehlerhaften Stand auf FP, und lädt den dann anschliessend beim Hochfahren wieder --> Murmeltiertag.


    Am besten mal das Smartpad abziehen und vor dem Einschalten der Steuerung einen Bildschirm und Tastatur am PC im Steuerschrank anschliessen.

    Mit dem Error-Handler wirst du nicht weiterkommen, weil damit der Aufrufstapel ja nicht einfach vergrößert werden kann.

    So war das ja auch nicht gemeint, sondern man kann im Errorhandler mittels RAISE die Rekursion elegant beenden und notfalls in den aufrufenden Routinen wieder mit RAISE solange zurückspringen, bis man im Scheduler ankommt (oberste Ebene) und dann wieder entsprechend der aktuellen Fehlernummer den nächsten Anlauf nehmen.

    Aber das ganze bleibt halt durch die schwammige Beschreibung des Vorgangs dann doch eher undurchsichtig.

    Beim ABB sollte sowas machbar sein.

    Da gibt es die schönen Dinger wie error, raise, trynext usw.

    Da müsste man im Fehlerfall einen Fehler generieren, den im Error Handler nach oben durchreichen, und in einer Hautproutine (neudeutsch sowas wie scheduler) je nach Status und Fehler wieder richtig aufsetzen.

    Soviel zu meiner Idee, die dürfte jetzt ungefähr genau so präzise sein, wie Deine Beschreibung des bestehenden Programms. Aber mehr ist da leider nicht drin, mit den vagen Angaben.

    .. Allerdings benötige ich das "ineinander verschachtelte Aufrufen der Routinen.

    Das bezweifle ich.

    Mir stellt sich die Frage, wie ich die Fehlermeldung und vor allem den Verlust des PZ verhindern kann, ohne groß die Verschachtelungen auflösen zu müssen.

    Da wird es keine andere Möglichkeit geben. Zumindest kann man keine aufzeigen, wenn man nicht mal einen kleinen Hinweis hat, wie das Programm aufgebaut ist, und Du der Meinung bist diese Verschachtelung unbedingt zu benötigen.

    Das schöne am ABB ist, dass die ganzen Dateien im Backup lesbarer ASCII Codes sind.

    Da kann man sich die Unterschiede schön im Windiff, Beyond Compare, o. Ä. ansehen und mergen.

    Dann passiert sowas nicht. Ein komplettes Backup würde ich niemals auf einen fremden Roboter spielen, viel zu undurchsichtig was da alles passiert.

    Würde mal sagen, da habt ihr noch mal Glück gehabt, dass nicht mehr verwurstelt war.

    Was ich eigentlich damit sagen wollte:

    Die Anforderung macht m. E. keinen grossen Sinn: wenn man ein Modul über eine parallele Task nachgeladen hat, dann muss man doch hinterher auf jeden Fall die Haupttask starten, sonst hätte man sich das Laden sparen können. Da macht es meiner Meinung nach keinen Unterschied, ob man den Haupttask vorher startet und dort nachlädt, oder über den parallelen Task. Außer dass man sich die m. M. nach unlösbare Aufgabe gar nicht zu stellen braucht.

    Das wäre schon mal die Theorie.

    In der Praxis ist das meistens dann doch wieder nicht ganz so einfach, da die tatsächliche Bewegung dann noch von diversen Parametern abhängt, wie z.Bsp:

    - Lin oder PTP gefahren

    - sind die Punkte als E6POS/POS oder als Frame deklariert

    - von welcher Startposition wird losgefahren


    In den E6POS steckt noch S und T drin, bei LIN wird das nicht beachtet, bei PTP wird S und T verwendet und die Position mit der darin hinterlegten Konfiguration angefahren. Beim Lin nimmt der Roboter einfach den kürzesten Weg (afair).

    Der geometrische Operant ist bei 8.6.x wohl offenbar nicht mehr die erste Wahl

    Warum sollte das nicht der Fall sein?

    Ich vermute mal, dass die Offsets in den Winkeln immer Null sind. Dann braucht es in keiner Version den :Operator. Da ist das Programm unnötig kompliziert gebaut, da man die Winkel auch hätte weglassen können.

    Kommt schon immer drauf an, was man genau ändert.

    If then, else, switch .. das ging noch nie. Bei einfachen Zuweisungen kann ich mich an keine Probleme erinnern.

    Versionsabhängigkeiten sind mir auch noch keine aufgefallen.

    Aber mit Abwählen ist man auf der sicheren Seite.

    Die sache wird wohl etwas aufwändiger...das sich das Image erstellen wohl nicht lohnt!

    Image erstellen lohnt sich bei den alten Kisten auf alle Fälle.

    So aufwändig ist das nicht:

    - Festplatte raus (dauert keine 2 Minuten)

    - über einen USB-Adapter an einen beliebigen PC anschliessen.

    - Image erstellen mit einem Imager eigener Wahl, als da wären acronis, ghost, dd wenn man Linux bevorzugt. .. .

    - Festplatte wieder einbauen.

    Programm abwählen muss man in dem Fall nicht, denke ich mal.

    Einfach die Tastatur hochholen (die Taste links mit dem stilisierten Schreibstift), dann den Text ändern, Zeile verlassen mit Pfeiltaste auf der Tastatur.

    Schulung schadet bestimmt nicht.