Beiträge von dust2

    Wir haben einen Roboter IRB660 (RW 5.14.0204). Der Roboter depalalettiert u.a einen Stapel mit Kartonagen und vermisst die gegriffenen Kartonagen am Greifer an drei auf einen Ständer montierten Sensoren! Der Ständer steht 650mm vom Mittelpunkt der EURO-Palette entfernt! Der Greifer ist 700mm breit! Die Anlage lief ein halbes Jahr ohne Probleme, dann plötzlich ein Crash, der Roboter ist auf der Anfahrt zum Stapel in y-Palettenmittelpunkt bei der MoveJ-Fahrt nach unten zu weit nach links ausgebaucht und damit am Ständer hängen geblieben! Bei der darauf folgenden Diagnose per Teleservice wurde festgestellt, das nun auch die Fahrt vom Stapel weg nicht mehr funktioniert, auch hier baucht der Roboter seitlich nun sehr stark in -y(wobjStart) aus und streift den Ständer!


    An und Abfahrt ist realisiert aus Taktleistungsgründen mit MoveJ


    MoveJ Offs(rPos_Start,0,0,pV_Start.z),sVel,z200,tGripper\WObj:=wWobStart;


    pV_Start ist ein Abhebevektor mit berechneten Z-Anzeil je nach aktueller Stapelhöhe - Ausbauchung bei der Fahrt nach oben relativ um 1700mm nun plötzlich zur Seite anstatt von sich weg mit mehr als 500mm seitlich laut Bediener!!!??


    PERS tooldata tGripper:=[TRUE,[[0,0,310],[0,0.707107,-0.707107,0]],[80,[0,0,200],[1,0,0,0],7.26667,15.6,21.6667]]; ! Vaku-Greifer Unterkante


    Eine Überprüfung aller relevanten Daten ergab, das Werkobjekt, Werkzeug, Last und Abhebevekektor ok sind


    Laut Aussage Bediener fährt der Roboter auch bei manuellen Bewegen in wobj und z+ nicht mehr senkrecht sondern im Bogen!?


    Ich habe die Fahrt erstmal in MoveL geändert, nun Fahrt senkrecht linear in z wie erwartet und Beweiß das wobj ok - aber nun Alles langsamer!


    ABB-Hotline sagt: einfach P-Start machen, dann sollte auch MoveJ wieder funktionieren!?
    Ich frage mich aber wie lange und warum?


    Ich vermute das irgendein Antrieb sich verändert hat und dadurch die PTP-Bahn verändert!?
    Backups Zeile für Zeile verglichen, kein Unterschied vor und nach dem Crash!
    Kennt jemand das Verhalten und wie kann man vor Ort weiter diagnostizieren?


    dust2

    Hi Addi,


    "Möglicherweise ist OPC dann doch die bessere Alternative, weil wir dann an unserer Software am wenigsten ändern müssen"


    nicht ganz:
    Dein DELPHI-Kollege muss einen OPC(DA)-Clienten in seinen Code implementieren, siehe dazu meinen ersten Beitrag!
    Falls Ihr dabei Hilfe benötigt, PM an mich!


    dust2

    Hallo Addi,


    du mußt bedenken, das du immer wenn Du per Feldbus in den Roboter rein gehst, zwar schnell bist, aber nur 1024Bit E/As insgesamt!!!! zur Verfügung hast!
    Intergerparameter sind dann als SIGNAL je nach Wertebereich zu deklarieren, negative Zahlen musst du entsprechend bitweise umrechnen, Gleitzahlen als Zweierkomplement oder als multiplizierte Ganzzahl übertragen!
    Bei Strings wird dann ganz umständlich, die kannst Du nur als ASCII-Zeichen übetragen!


    Hier hast Du mit OPC deutliche Vorteile, da Du wie bei CrossOCX direkt auf die KRC-Variablen schreibst!
    ENUMS gibt es als OPC-Datentyp, Arrays wird etwas komplizierter!
    Ich hatte einmal sporadische Verbindungsabrüche in der Produktion, da war eine Netzwerkkarte defekt, so etwas dann zu finden ist auch ein Nachteil von OPC!
    Ach wenn Dein PC vom Kunden administriert wird, kann an einem Tag X plötzlich nichts mehr gehen, weil einer ServicePack aufgespielt hat oder die Firewall umkonfiguriert hat, hier bist Du wieder mit Feldbus auf der sichern Seite!
    Auch wenn Du mit OPC versucht, deterministisch und schnell zu sein, z.B. eine Kamera antriggern, gehst Du baden!



    Falls DU die KUKA-OPC-Doku benötigts, PM an mich!



    Wie gesagt, wenn Du nur selten dafür viel schreibst, scheint seriell immer noch eine interessante Alternative zu sein!


    dust2

    zu OPC:


    du benötigst auf der KRC2 die Option KUKA-OPC-Server und für Deine PC-Applikation musst Du einen OPC(DA)-Client programmieren, ist die Anwendung unmanaged(C++ bzw. VB6) findest Du jede Menge Bespiele im Netz wie man sowas macht!
    Ist oder wird Deine PC-Anwendung irgendwann .Net basierend, kommst Du mit einem OPC-Toolkit (Softing, Matrikon) besser, da musst Du Dich nicht selbst ums Wrapping kümmern!


    Variablen(Tags) Anzahl ist bei OPC(DA) kein Problem, Übertragungszeiten und Zugriff auf Arrays schon, 0.5-1.0sec Lesezeit solltest Du einplanen, alles nicht deterministisch
    bei OPC kann die erforderliche DCOM-Konfiguration auf beiden Seiten Nerven kosten.
    Deshalb gibt es seit einigen Jahren OPC UA, ich weiß nicht, ob das KUKA mittlerweile unterstützt?


    KUKa-OPC-Server, Toolkit und Entwicklungsaufwand ist Alles mit Kosten verbunden!


    Alternativen:
    1. seriell
    für eine einzelne Anwendung mit KRC2 wahrscheinlich der geringste Aufwand und Kosten



    2. eine DeviceNet-Karte von HILSCHER in deinen PC einbauen
    Vorteile_
    - die HILSCHER-API ist sehr gut dokumentiert und lässt sich relativ leicht in die Applikation einbinden
    - Konfiguration mit SYCCON sehr einfach
    - PC ist SLAVE - KUKA ist Master, Bus-Aktualisierungszeit 12ms
    - relativ preiswert
    Nachteile:
    -nicht zukunftsicher wegen KRC4


    3. eine ProfiNet IO Karte in Roboter und PC einbauen:


    Vorteile:
    - Bus-Aktualisierungszeiten <10ms
    - Feldbusverhalten
    - zukunftsicher (KRC4 und alle anderen Robotersteuerungen und auch viele SPSsen)


    Nachteile:
    - teuer, da 1x CP1616 in KUKA KRC2 und eine ProfiNet-Karte im PC (PCI-Slot muss verfügbar sein)
    - Konfiguration der IOs auch nicht ganz ohne- siehe zahlreiche Beiträge in diesem Forum
    - Expertenwissen notwendig um einen ProfiNet-Stack in Deine PC-Anwendung zu implementieren


    Grüße dust2

    Hallo,


    hab es mit Hilfe von SIEMENS hinbekommen, man muss in HW-Konfig zwei SIMATIC-PC-Stationen anlegen, eine für den Controller(KUKA) und eine für die übergeordnete Station (SPS). In der KUKA-Station eine CP1616(Firmwarestand beachten) auf Slot 1, IP-Adresse vergeben und Subnetz anlegen. An dieses Subnetz die E/A-Geräte des Roboters projektieren.
    In der SPS-PC-Station den übergeordneten Controller projektieren und diesen an den gleichen ProfiNetStrang anhängen, wie die KUKA-Station. Nun einen CP1616 aus ProfiNet IO/IO/SIMATIC-PC-CP/CP1616 MIGRATION!!!!!!!! an den Strang ziehen und mit gleichen!!! Gerätenamen wie die CP1616 in der KUKA-Station versehen. E/As in die Karte projektieren, E/A-Abbild des Devices identisch mit dem des übergeordneten Controllers(der SPS)!
    Dann in der KUKA-Station Eigenschaften des Controllers "IO-Device-Betrieb ermöglichen" aktivieren und dort Button Koppeln mit der Device-Konfiguration koppeln. Das ist der Trick, denn damit wird die SPS-Station in die KUKA-Station eingelinkt und nach Speichern+Übersetzen muss man nur die KUKA-Station auf die Karte runterspielen!!
    Wenn die Einträge in iossys.ini und pniDRV.ini zur Konfiguration passen, sollte es laufen...



    ein schönes Wochenende
    dust2

    Hallo,


    bin dabei KUKA KRC2 V5.14 mit CP1616 zu konfigurieren.
    Als Controller funktioniert es nun, nach einem SIEMENS-Firmwareupdate von V2.1 auf 2.2
    Nun soll die Karte aber als Controller und Device laufen. Ich habe eine KUKA-ProfiNet-Doku von 2009 für Firmware 1.0 wo der Vorgang noch vollständig beschrieben ist (so wie es sich gehört) und die KUKA-ProfiNet-Doku 2.2 die in Konfigurationsfragen nur auf eine SIEMENS-Doku verweist, die ihrerseits wieder auf eine SIEMENS-Liesmich verweist (ein Armutszeugnis).


    In der alten Doku wird die Device-Karte in der PC-Station der Controller-Konfiguration an den vorhandenen ProfiNet-Strang angefügt und mit den Device-EAs konfiguriert.
    In der SIEMENSDoku (PG-Schnittstelle einstellen-Schnelleinstieg) wird hingegen eine weitere PC-Station angelegt (also eine für Controller und eine für Device) und diese sollen dann beide nacheinander auf das Zielsystem gespielt werden, wie genau, ist nicht beschrieben!


    Fragen:
    1. Bei Variante 1 überschreibt es mir immer den Gerätenamen des Controllers mit "CP1616" (vorher zurückgesetzt auf Werkseinstellung wie beschrieben) obwohl ich in der Controller Konfiguration den richtigen Gerätenamen angegeben habe (Device hat den selben Namen und IP-von Controller ist deaktiviert)
    2. Bei Variante 2 überbügele ich natürlich beim Runterspielen der 2. Konfigurationh immer die 1. Konfiguration auf der Karte?
    3. Welche Variante führt zum Ziel? Ist das firmwareabhängig?
    4. Gibts irgendwo eine vernüftige Anleitung?



    Danke für Eure Hilfe


    dust2

    Hallo,


    will demnächst auf ProfiNet umsteigen, bei der Gelegenheit (und dann ab KRC4 sowieso) soll das gute DeviceNet wegrationalisiert werde, um die Busvielfalt etwas einzudämmen!
    Will weiterhin nur mit einem Kabel von der KRC2 zum X72 und dann über die 18adrige KUKA(WIELAND)-Multibusleitung hochgehen! Das ganze natürlich wie bisher schleppkettentauglich und torsionsfest!
    Blick ins Internet zeigt diverse ProfiNet-Hybridkabel (LEONI, HARTING). Habt Ihr da schon praktische Erfahrungen sammeln können?
    Wie erfolgt die Aufteilung Bus und 24 V an den beiden Enden, einfach lang abisolieren und verzweigen???
    Ist die KUKA Multibusleitung ProfiNet-tauglich?
    Wie sieht ein geeignetes Verkabelungs- und Steckerkonzept aus?


    Danke für eure Hilfe


    dust2

    Hallo Micky,


    danke für Deine schnelle Antwort:
    Genauso hatte ich es verstanden und ganz am Anfang probiert mit dieser Crossconnection:


    -Res "diPSC1PREWARN" -Act1 "PSC1PREWARN"


    Daraufhin bekam ich folgende Fehlermeldung:
    E/A-Konfiguration einer Querverbindung ist ungültig.
    Die Querverbindung wurde abgelehnt und keine davon abhängigen Funktionen werden funktionieren.
    Der Parameter <Actor 1> einer Querverbindung beinhaltet einen Bezug zu einem undefinierten E/A-Signal <PSC1PREWARN>.


    Deshalb dachte ich, ich muss die Signale irgendwie selbst definieren!?


    Nun habe ich auf Deinen Hinweiß hin nochmal Folgendes gemacht:


    -Res "diPSC1CSC" -Act1 "PSC1CSC"

    -Res "diPSC1MAR1" -Act1 "PSC1MAR1"

    -Res "diPSC1PREWARN" -Act1 "PSC1PREWARN"

    Und siehe da, die Signale PSC1CSC und PSC1MAR1 funktionieren, nur bei PSC1PREWARN kommt wieder o.g. Fehlermeldung?
    Bin der Meinung, die aktuelle Doku zu haben, Signalnamen wie im Zitat oben!?


    dust2

    Hallo,

    ich habe eine Roboter IRC5-RW513.1 mit Option EPS! Habe EPS nach Doku konfiguriert, der Sicherheitskreis ist aktiv und die Synchronisation ist erfolgt!
    Nun vesuche ich die Signale des EPS-Controllers in RAPID auzuwerten. Laut Doku Seite 69 sind alle EPS-Signale digitale Eingänge:


    Die virtuellen Signale können am FlexPendant angezeigt werden. Sie werden jedoch über
    eine Ethernet-Verbindung und nicht über ein physisches Signal übermittelt. Sie zeigen den
    Status der Signale von der Sicherheitssteuerung an und können nicht vom Benutzer gesetzt
    werden. Aus diesem Grund werden sie als digitale Eingänge (DE) dargestellt.
    PSC1CSC Darstellung des Eingangssignals vom Sync-Schalter an die Sicherheitssteuerung.
    PSC1MAR1 Darstellung des MAR1-Signals von der Sicherheitssteuerung.
    PSC1MAR2 Darstellung des MAR2-Signals von der Sicherheitssteuerung.
    PSC1MAR3 Darstellung des MAR3-Signals von der Sicherheitssteuerung.
    PSC1MAR4 Darstellung des MAR4-Signals von der Sicherheitssteuerung.
    PSC1MAR5 Darstellung des MAR5-Signals von der Sicherheitssteuerung.
    PSC1PREWARN Anforderung einer Synchronisierungsprüfung.....




    auf Seite 63 steht aber:"
    Führen Sie die Synchronisierung durch, wenn das digitale Ausgangssignal PSC1CSPREWARN steigt."??????


    OK, ich habe nun versucht, das Signal PSC1PREWARN in der EIO.cfg anzulegen
    weder so noch so funktioniert es!?



    -Name "PSC1PREWARN" -SignalType "DI" -Unit "virt_unit_1" -UnitMap "6"\
    -Access "ALL"


    -Name "PSC1PREWARN" -SignalType "DI" -Unit "PSC_1" -UnitMap "6"\
    -Access "ALL"


    -Name "PSC1PREWARN" -SignalType "DO" -Unit "virt_unit_1" -UnitMap "6"\
    -Access "ALL"



    Wie muss ich die Signale definieren, damit ich sie von RAPID aus lesen kann?


    Danke für Eure Hilfe


    dust2

    Hallo Leute,


    erstmal Danke für die Ratschläge!
    Ich muss jedesmal von 1800mm suchen, wenn ein neuer Stapel einläuft, dann merk ich mir die Höhe und mach dann von der gemessen Höhe weiter!
    Analogsuche mit Ultraschallsensor funktioniert sonst immer prima, hier gehts um Türblätter mit Lichtausschnitten,da ist mehr Loch als Tür, deswegen taktile Antastung per Schaltleiste!
    Habs jetzt mit CSpeedOverride gelöst, je kleiner der Override, desto höher die TCP-Geschwindigkeit als /V Parameter in der SearchL-Anweisung-funktioniert ganz gut!
    Außer wenn der Bediener während der Suchfahrt den Override umschaltet, aber das wird er lernen bzw. merken...


    FAZIT: irgendwie gibts beim ABB für Alles ne Funktion, man findet sie nur nicht immer, obwohl die Doku eigentlich super ist

    Hallo, ich habe eine IRB660 mit IRC5 RW5.13 der depalettiert. Die Antastung des obersten Teils auf dem Stapel erfolgt mit SearchL auf eine taktile Schaltleiste!
    Nun kann man ein wenig mit den Suchfahrgeschwindigkeiten und Sensorabschalteinstellungen spielen, hat aber immer das Problem, das man den am FlexPendant eingestellten Override nicht mit SPEEDREFRESH überschreiben kann(also Suchfahrt immer mit 100% wie beim KUKA). Optimiert man die Suchfahrtgeschwindigkeit für 100% so, das es keine Stunden dauert wenn der 1800mm hohe Stapel nur 50mm hoch ist (v150 mit /SSTOP) und rechnet bei der Sensoreinstellung den Nachlaufweg(bis 3cm) mit ein und der Bediener fährt mit 25% ist der Nachlaufweg fast 0mm und der Roboter stopt über dem Teil und kann es nicht greifen.
    VELSET und SPEEDREFRESH helfen da wenig!?
    Wie macht Ihr sowas?
    Mein Ansatz ist nun, die am FP eingestellten Override auszulesen und abhängig davon verschieden große Nachsetzvektoren an die Suchfahrt anzuschließen, d.h. je kleiner der Override, desto mehr setzt der Roboter nach!
    Nun finde ich aber keine Funktion, die mir den aktuellen Override am Flexpendant bzw. die aktuelle TCP-Geschwindigkeit zurückgibt!?


    Danke und schönes Wochenende...


    dust2

    Hallo,


    Inertia_x/y gibt ja nicht den Schwerpunkt sondern das Trägheitsmoment um die x/y-Achse an! . Und diese müsste bei Karuselllasten doch Null sein, weil sich das KS nur um z dreht!? Die Schwerpunktkkordinaten hab ich schon korrekt angegeben
    Die Doku hab ich vom Roboter der mit Robotware 5.13.01 angeliefert wurde. Ich hatte nur auf meinem Laptop noch eine 5.11er Doku


    Wegen dem Steinersatz werd ich nochmal bei ABB nachfragen!



    dust2