Beiträge von MaBo

    Hi Leute,


    ich suche gerade eine Möglichkeit eine Steuerung eindeutig identifizieren zu können um das Programm an diese koppeln zu können. Leider ist ja die Seriennummer in der MOC änderbar, weshalb das nicht weiterhilft.
    Gibt es die Möglichkeit z. B. die MAC Adresse eines Netzwerkadapters oder die ID des SMB Boards aus Rapid heraus auszulesen, um eine Steuerung bzw. Roboter eindeutig identifizieren zu können.


    Es soll verhindert werden das ein Programm fälschlicherweise auf eine andere Steuerung gelangt und dort womöglich Schaden anrichtet.


    Gruss Matze

    Hi Leute,
    ich suche eine Möglichkeit eine Position (robtarget) das in einem Werkobjekt definiert ist rechnerisch auf ein anderes Werkobjekt zu übertragen, ohne das es sich Räumlich ändert. Also nicht einfach das robtarget mit einem anderem Werkobjekt anfahren. Da würde die Position nicht mehr an der selben Stelle sein, sondern Rechnerisch auf ein anderes Werkobjekt übertragen.


    Ich denke irgendwie das Werkobjekt herrausrechnen und im Anschluss das neue herreinrechnen.


    Habt Ihr das schonmal gemacht oder gibt es in Rapid eine Funktion dafür?


    z. Beispiel:


    newRobtarget:=Function(oldRobtarget,oldWorkobject,newWorkobject);



    Vielen Dank schon mal für eure Mühe.

    Hi,
    ich kann deine Argumente verstehen. Bei Fanuc z. B. wird das auch so Praktiziert.
    Dort muss ich vorweg das UTool und das UFrame angeben, da die Bewegungsbefehle diese Informationen nicht beinhalten. Das birgt allerdings die Gefahr, das wenn jemand eine Änderung am Programm vornimmt und dazu das Tool oder Frame oder sogar beides wechselt und dabei nicht sorfältig arbeitet das es dann zu Fehlern kommt. Leider erhalte ich häufig Support anrufe die auf solchen Fehlern beruhen.


    Wenn ich aber mit jedem Fahrbefehl diese Information mitgebe, dann kann man solchen Problemen vorbeugen, und Änderungen am Programm von unerfahrenen Programmierern sind dadurch leichter realisierbar.


    Zu deinem zweiten Punkt geb ich dir grundsätzlich Recht. Man könnte die geometrische Addition auch im Bewegungsbefehl machen. Da einige schwierigkeiten damit haben wie herum die Addition angeordnet werden muss um ein Tool Offset oder ein Frame Offset zu erhalten, schien die Lösung über eine Funktion vorteilhafter. Man erkennt am Namen der Funktion welche Offsetberechnung statt findet.


    Zu deiner ersten Frage was mich stört ist die fehlende Flexibilität die die ILFs mit sich bringen. Ausserdem möchte ich vermeiden das man vor dem ausführen der Bewegung etliche Variablen befüllen muss bzw. Berechnungen durchführen muss bevor der eigentliche Bewegungsbefehl kommt. Mein Ziel ist es alles erforderliche in eine Zeile zu bekommen. Dadurch wirkt das Programm aufgeräumter und kann leichter gelesen werden. Und dennoch gewinne ich mehr flexibilität, so meine Zielsetzung.


    Zu deiner zweiten Frage die teilweise schon Oben beantwortet habe. Soviel flexibilität bei der definition einer Bewegungsanweisung wie möglich mit dem Ziel das alle Parameter und Informationen mit einer Zeile realisierbar ist. Also auf Folds und ausschweifenden Parameterbehandlungen zu verzichten. Desshalb geeignete Datentypen die namentlich zeigen welche Einstellung getroffen werden und diese als Paramter beim Ausführen der Bewegung übergeben.

    Hallo an alle Roboterkollegen,


    ich zerbreche mir seit einiger Zeit den Kopf wie man die Bewegungsbefehle im KUKA flexibler gestalten kann. Die Inlineformulare sind ja schön und Gut. Aber sie sind weit von einer Flexibilität entfernt, die man als Professioneller Programmierer gerne wünscht. Oft findet man dann auch Kuriose Lösungsansätze für Offset Berechnungen oder Bewegungsbefehl Lösungen.


    Daher hab ich überlegt wie das ganze schöner und flexibler machbar ist. Da ich nicht nur KUKA Programmiere, sondern auch FANUC, ABB, Stäubli und Mitsubishi ist mir natürlich nicht entgangen das es auch professionellere Lösungen dazu gibt.
    Das Programmbeispiel hier ist nur als Diskussionsgrundlage gedacht und keines wegs erprobt oder getestet. Kritik ist erwünscht, und vielleicht entwickelt sich dabei etwas was uns allen nützlich sein könnte.


    Hier der erste Vorschlag. Schaut es euch an, und lasst uns darüber diskutieren. ;)



    Erst mal das SRC File:



    Dann das DAT File:


    Vielleicht hat jemand ja auch eine Möglichkeit das ganze zu testen und kann uns von seinen Erfahrungen zu berichten. ;)


    Grüsse Matze


    Edit: Ich hätte ja gern alle Files hochgeladen. Aber irgendwas stimmt mit dem CMS hier nicht.

    Ich würde mal schauen was für eine CPU von Siemens du hast, welche Bussysteme sie unterstützt. Andererseits kannst du mal schauen ob schon ein Controller für Profibus oder Profinet im KUKA verbaut ist.
    Wenn für dich eine hohe Performance - Übertragungsrate entscheident ist, dann solltest du auf Profinet setzen.

    Hi,
    um jetzt vorhandenes zu verwenden ohne jetzt ein Tool oder sonstiges zu schreiben, könntest du 6 Analogeingänge definieren um Realzahlen zu übertragen (1. Eingang X Koordinate, 2. Eingang Y Koordinate, 3. Eingang Z Koordinate, 4. Eingang A Rotation, 5. Eingang B Rotation und 6. Eingang C Rotation). Das Ganze mit einem Toggle in ein Positions Registerarray schreiben z. B. im SPS Submit. Dann im Robotertask die Arrays einzeln anfahren.
    Damit das Halbwegs funktioniert sollten mindestens 10 Positionen vorraus übertragen werden. Kommt auch darauf an wie schnell du das alles übertragen bekommst.
    Das ganze kannst über Device Net machen. Hat der Kuka ja onboard. Wenn du Siemens verwenden willst, dann ist Profibus eine gute Wahl. Profinet ist denke ich auch möglich. Benötigt halt zusätzlich Controller Karten in der Kuka Steuerung.

    Hi,
    die Register bei Fanuc ist wohl den CNC Ingenieuren zu verdanken die aus einer CNC Steuerung eine Robotersteuerung gebastelt haben statt eine gescheite Programmiersprache wie Rapid bei ABB.
    Im Grunde wird für dich bei ABB alles besser. Das deklarieren und benennen von Variablen (Fanuc nennt das Register) hast du viel mehr Freiheiten und vor allem keine Limits der Menge, wie bei Fanuc das der Fall ist. Auch der Speicher ist viiiiiiiiiieeeeel Grösser als bei Fanuc. Im Grunde hast du nur Vorteile. ;)

    Das Problem kann ich nicht nachstellen.
    Hab die Letzten Wochen mit IRB140, IRB2600, IRB6700 zu tun gehabt. Mal mit SafeMove Classic mal mit SafeMove Pro. Aber der Bremsentest hat keinerlei Probleme gemacht. Verwedet wurde Robotware 5.15, 6.02, 6.03, 6.04 - keine Auffälligkeiten.
    Mal eine andere Frage. Hast du bei der IBN irgendwelche alte Konfigurationsdateien von älteren Anlagen reingewürgt. z. B. die MOC? Weil dann würde das auch so einiges erklären. Die sind teilweise nicht mehr abwärtskompatibel. Und das kann auch solche beschriebenen Auswirkungen haben.


    Gruss Matze

    Hi,


    das geht wenn du auf deinem Roboter die Option Weltzonen verwendest. Dort kannst du dann deine Homepositionen auf verschiedenste Art und Weise überwachen und als Signal an deine SPS weiterleiten. Von Haus aus ist dort keine Fertige Überwachung vorgesehen.


    Gruss Matze

    Hi,
    ich bin vermutlich späth drann dein Problem zu beantworten.


    Folgendes solltest du bitte überprüfen. In welcher Stellung wird der Bremsentest durchgeführt, hängt die Hand des Roboter herunter oder ist sie Ausgestreckt? Also kann der Bremsentest Lastneutral durchgeführt werden oder nicht? Welche Werte hast du in der SafeMove konfiguration eingestellt? Sind es die Standard Werte oder hast du sie optimiert?


    Ist die Überwachungsschwelle 0,02 Radiant und die Stillstandstoleranz 2,0 Radiant? Hast du externe Fremdachsen die den Bremsentest negativ beeinflussen können im Einsatz? Die Stillstandstoleranz kann man im Bedarfsfall auch ein wenig erhöhen, wenn vertretbar. Niemals den Bremsentest deaktivieren so lange SafeMove für eine Aktive Sicherheit verwendet wird.


    Das Ausführen des Bremsentests, wurde ja weiter oben schon etwas erläutert, sollte niemals abgebrochen werden. Die Auswirkungen sind ja bekannt ;) . Ganz schlecht ist es den Bremsentest im Editor über das Testmenü Routine aufrufen auszuführen. Immer den Bremsentest über eine Aurufende Routine (Proc Call) ausführen. (Warum könnte ich erklähren, würde aber den Rahmen sprengen.)
    Probleme mit dem Bremsentest sind meistens durch den Inbetriebnehmer verursacht. Daher muss das ganze mit grösster Sorgfalt durchgeführt werden.


    Gruss Matze

    Hi,
    du kannst natürlich mit Robot Studio 6.04 den alten SafeMove konfigurieren. Besser ist 6.04.01 da Fehlerbereinigt. Dazu natürlich den Visual SafeMove Konfigurator verwenden. Man muss sich umgewöhnen, aber es es geht. Alles was man benötigt ist da. Beim ersten mal öffnen kann eine Fehler Meldung aufpopen, das noch keine konfiguration existiert. Darauf hin eine neue anlegen und mit dem konfigurieren beginnen. Der Rest sollte bekannt sein.
    Gruss Matze

    Hi,


    also ich habs hinbekommen. Aber dein Tip war nur die halbe Wahrheit. Man muss in allen Min und Max Feldern die gleichen Werte eintragen, sonst geht es nicht und das System erzeugt irgend einen Blödsinn.


    Beispiel:
    Maximum Logical Value = 180000
    Maximum Physical Value = 180000
    Maximum Physical Value Limit = 180000
    Maximum Bit Value = 180000
    Minimum Logical Value = -180000
    Minimum Physical Value = -180000
    Minimum Physical Value Limit = -180000
    Minimum Bit Value = -180000


    Wird das so ausgefüllt dann passt alles und die Sim Werte ebenso. Allerdings konnte ich keine Doku finden die das Erklährt. Die einzige Doku die ich in meiner Sammlung habe die etwas über Signal beschreibt sagt etwa soviel aus wie, ja wir können auch Signale.
    Sehr schlaue Aussage!? :uglyhammer_2: :uglyhammer_2:

    Hi Leutz,


    ich plag mich mal wieder mit Analogwerten rum. Leider hat die Forumsuche nicht weiter geholfen.


    Folgendes:
    Kamera schickt Verdrehungswerte zwischen -180000 - 180000 Milligrad. Ich muss also durch 1000 dividieren um den echten Grad Wert zu erhalten.
    Auf der Schnittstelle arbeite ich mit einen Doppelwort.
    Ist bis hier hin auch kein Problem.


    Mit Gruppen Eingängen geht es nicht, da ich nur Positive Zahlen erhalte. Das ganze als Analogeingang funktioniert.


    Jetzt kommt der Haken. Da der Empangene Wert zurück gespiegelt werden soll muss dazu ein Passender Analogausgang definiert werden.
    Wenn ich jetzt bei der Min und Max Wertanagabe in der Signalkonfiguration 0 stehen lass, dann kann ich den Wert über das Programm zurück Schicken.
    Aber wenn man testweise ein Wert setzen möchte dann geht das nicht, weil ja 0 im Min und Max Wert Fenster stehen.
    Wenn ich jetzt dort Minwerte und Maxwerte eintrage, dann scheint die Steuerung die Werte zu wandeln und es wird nicht mehr der Richtig Wert gesendet.


    Gibt es irgend eine Vorgehensweise oder einige Dinge die beachtet werden müsssen bei der Grenzwert Festlegung. Hab schon etliches ausprobiert. Nur wenn 0 in den Minwert und Maxwert Fenstern stehen wird der Korreckte Wert gesendet.


    Hat jemand ne Idee, oder liegt es am Montag morgen!?


    Gruss Matze