Cross3 Ersatz auf KRC2 / Zugriff auf Variablen

    Hallo zusammen,


    ich stehe demnächst vor der Aufgabe, eines meiner Projekt, welches bereits auf einer KRC1 läuft,
    auf eine neue KRC2 umstellen zu müssen.


    Bei der KRC1 habe ich den regen Variablen-Datenaustauch zwischen meiner Bedienoberfläche (PC)
    und der Steuerung per Cross3-Schnittstelle gelöst. Das funktioniert soweit auch alles recht gut.


    Mit KRC2 habe ich noch nie gearbeitet. Soweit ich weiß, gibt es hier ja kein Cross3 mehr und daher
    suche ich einen gleichwertigen Ersatz für den Datenaustauch (Programm/System-Variablen) zwischen
    PC und KRC. Echtzeit ist nicht erforderlich.


    Ist OPC dafür die erste Wahl, oder gibt es Alternativen ?
    Sind bei OPC Probleme zu erwarten ? Gibt es Einschränkungen im Zugriff ?
    Gibt es für OPC spezielle Anforderungen/Voraussetzungen (Hard-/Software) auf KRC- und/oder PC-Seite ?


    Vielen Dank für Infos oder Erfahrungsberichte jeglicher Art.
    gruß
    addi

    • Schritt für Schritt zum Roboterprofi!

    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

    Einmal editiert, zuletzt von dust2 ()

    Hallo dust2,


    erstmal vielen Dank für deine ausführliche Antwort :supi:


    Ich werde mich zunächst mal mit den Alternativen 1 und 2 beschäftigen bzw. darin einlesen.


    Welche Voraussetzungen brauche ich denn auf der KRC-Seite für DeviceNet, oder ist das
    in der KRC2 standardmäßig enthalten ?


    Danke!
    Gruß
    addi

    Hallo zusammen,


    kurze Frage, wenn jemand von euch die Cross-Schnittstelle unter Visual C benutzt, ist euch das Eventhandling gelungen ? Wenn ja, würde ich mich über einen Tip freuen. Ich habe nämlich so ziemlich alles von Dispatch bis EVENT_SINK etc. ausprobiert. Leider ohne Erfolg. Etwas Sourcecode wäre auch schön.


    Danke im voraus,


    Mitsubishifan

    Hallo Addi,


    DeviceNet-Soft-Controller(MASTER) ist auf MFC-Karte in KRC2 standardmäßig drauf!
    Zur sauberen 24V-Buseinspeisung solltest Du bei KUKA einen DeviceNet-Verteiler (PowerTab-71052237) mitbestellen


    dust2

    dust2,


    vielen Dank für die Info. :danke:
    Werde das mit dem DeviceNet-Verteiler dem Einkauf weitergeben....


    Mitsubishifan
    das ist bei uns nicht in VC, sondern Delphi programmiert worden (hab ich auch nich selbst gemacht)
    (siehe http://www.roboterforum.de/rob…crosscommexe-t6513.0.html)
    insofern würden dir Codebeispiele nichts bringen.
    Selbst wenn ich könnte (hab die Quelltexte nicht), dürfte ich sie auch nicht veröffentlichen weil firmenintern. :sorry:
    Ich kann nur soviel sagen:
    - das Ereignis "SetInfoResult" funktioniert/wird ausgelöst (z.B. Änderung einer KRC-Variablen)
    - Ereignis "BOFKey" (Tastendruck auf der KRC-BOF) haben wir nicht ans Laufen bekommen.


    Gruß
    addi

    Hallo ADDI,


    den Quellcode benötigst Du aber!?
    Eagal ob OPC, seriell oder Feldbus, du musst immer den Kommunikationspart in Deine DELPHI-Anwendung implementieren? Wie steuerst Du deine Greifer EAs?


    dust2

    Hallo dust2,


    dieser Teil wird von einem anderen Programmierer übernommen (der den Quelltext hat) ;)


    Der Delphi-Teil stellt nur eine Benutzer-Schnittstelle dar, von der Prozess-Parameter und dgl.
    in die KRC übertragen werden (per Variablen).
    Alles andere (Greifer-Steuerung usw.) findet komplett in KRL statt.


    Gruß
    addi

    Hallo addi,


    erstmal Danke für deine Antwort. Mit SetInfoResult habe ich noch nicht gearbeitet. Ich benutze ShowVar und SetVar. Du benutzt wahrscheinlich SetInfo vorher, oder ? Kannst du mir sagen, was SetInfoResult an Ergebnissen liefert ? Da gibt es ja die Variable shJob. Müsste ich die Funktion mit dem durch beispielsweise ShowVar zurückgegebnen shJob-Wert aufrufen und erhalte in pbstrResult (ist bei mir ein Pointer) den Bearbeitungsstatus ? Oder wird ein erledigter Job durch den Rückgabewert BOOL angezeigt ?


    Danke für die Hilfe,


    Mitsubishifan

    dust2,


    achso... hatte ich missverstanden.
    Greifer wird (in dem laufenden KRC1-Projekt) direkt per IO angesteuert, kein Bussystem...
    Wie das in dem neuen Projekt mit der KRC2 laufen soll, muß ich erstmal nachfragen,
    vermute zunächst auch direkte IO aber bin nicht sicher...
    Melde mich dazu nochmal.


    Mitsubishifan
    Melde mich später.. hab jetz keine Zeit....


    Gruß
    addi

    dust2
    habe erfahren, dass die Greifer-Steuerung aus Kompatiblitätsgründen auch per direkter IO
    laufen soll. Alle beim Kunden laufenden Anlagen sind dann nahezu baugleich, was ja z.B. aus
    Wartungsgründen (u.a.) auch durchaus Sinn macht...


    Wenn man bei KUKA einen neuen Roboter kauft, hat der dann automatisch eine KRC4-Steuerung,
    oder bekommt man wahlweise auch noch eine KRC2 ? Weiß das zufälligerweise jemand ?


    Mitsubishifan
    also SetInfoResult ist der Name der Funktion die das Interface deines COM-Objektes implementieren muss,
    damit es von Cross3 per Event benachrichtigt wird, wenn sich eine Variable geändert hat (vom Prinzip her wie eine
    Art Callback-Funktion).
    Mit SetInfoOn(...) werden vorher die Variablen benannt, die überwacht werden sollen (nur globale Variablen aus der $config.dat).
    Ich glaube es sind nur 4 Variablen gleichzeitig möglich, weiß aber nicht mehr genau, ist schon länger her....
    Dadurch, dass auch Struktur-Variablen (STRUC) verwendet werden können, kann man mehrere Variablen/Werte zusammenfassen.


    Zu der Variablen shJob kann ich dir leider nichts sagen. Kenn ich nicht...
    Die aufgerufenen Cross3-Funktionen liefern normalerweise True/False als String(!) zurück (also: '0' bzw. '-1' [oder '1' ?]).


    Ich schick dir auch noch eine PN...


    gruß
    addi

    Moin addi,


    KRC2 wird es auch noch in 2012 geben!
    Wieviele Variablen schreibst Du von dem PC zum Roboter?
    Wie oft schreibst Du die Variablen?
    Hast Du negative Werte zu schreiben?
    Hast Du Gleitpunktzahlen zu schreiben, wenn ja wieviele Stellen nach dem Komma?


    dust2

    Moin dust2,


    also die Anzahl der Variablen beläuft sich auf ca. 70, wobei ein Großteil komplexere Strukturen sind.
    Z.B. Parametersätze als Array, wobei die Array-Elemente einzeln übertragen werden.


    Geschrieben/Gelesen werden alle möglichen Typen von Variablen: Strings, Integer, Gleitkomma.
    Natürlich auch negative Zahlen. Bei Gleitkommazahlen reicht eine Genauigkeit von 3 Nachkommastellen.


    Wichtig für die Anwendung ist eine Überwachung von Variablen(-werten), so wie ich das mit SetInfoOn
    bei Cross3 machen kann. (Siehe vorherige Beschreibung für Mitsubishifan).
    Ist so etwas per DeviceNet möglich ?


    Danke und Gruß
    addi

    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

    Einmal editiert, zuletzt von dust2 ()

    Hallo dust2,


    Danke für die Infos.
    Diese Feldbus-Problematik war mir so nicht bewußt, hab halt noch nie damit gearbeitet...


    Möglicherweise ist OPC dann doch die bessere Alternative, weil wir dann an unserer Software am wenigsten ändern müssen.
    Wenn ich das auf seriell oder einen Feldbus umstellen muß, müsste ich beim Kommunikationskern ja quasi bei Null anfangen...


    Der externe PC wird nicht vom Kunden administriert, d.h. es werden keine Betriebssystem- (oder sonstige) Updates gemacht.
    Es handelt sich um eine Insel-Lösung, die nicht am Firmennetzwerk hängt (nur Peer-to-peer zw. PC <-> KRC)


    Deterministisch (oder gar echtzeitfähig) muß das auch nicht sein: ich habe auf Variablen-Ebene eine Art Software-Handshake realisiert (eine Status-Variable wird wechselweise vom Sender/Empfänger getoggelt; notfalls wartet das KRL-Programm
    bis die Kommunikation abgeschlossen ist).
    Ein (geänderter) Parametersatz wird maximal einmal pro Prozess-Zyklus übertragen, so ca. max. alle 15-30 Sekunden,
    je nach Bearbeitungsstrategie.


    Kann man denn per OPC auf geänderte Variablen triggern lassen (Events empfangen o.ä.) ?


    danke u. gruß
    addi

    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

    Zitat von dust2


    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!


    Das stimmt nicht - es können bis zu 4096 sein! Siehe Systemvariable $SET_IO_SIZE.


    $SET_IO_SIZE=1 bedeutet 1024 EAs
    $SET_IO_SIZE=2 bedeutet 2048 EAs
    $SET_IO_SIZE=4 bedeutet 4096 EAs


    OPC ist sehr langsam, vor allem wenn viele REAL-Werte bzw. Doppelwörter übertragen werden. Ich arbeite zwar oft mit OPC, bin aber gerade bei großen Datenmenge schon oft an die Grenzen geraten was die Übertragungszeit angeht.

    Greetings, Irrer Polterer!

    Wie poste ich falsch? Nachdem ich die Suche und die FAQ erfolgreich ignoriert habe, erstelle ich das gleiche Thema in mehreren Unterforen, benutze einen sehr kreativen Titel wie "Hilfe", am Besten noch mit mehreren Ausrufezeichen, und veröffentliche einen so eindeutigen Text, dass sich jeder etwas Anderes darunter vorstellt.


    Life is a beta version. Full of bugs and no Manual.

    Einmal editiert, zuletzt von IrrerPolterer ()

    Hallo,


    voraussichtlich werden wir es (zunächst) mit OPC versuchen, da das Konzept des direkten Lesen/Schreibens
    von Variablen unserem bisherigen Kommunikationskonzept am ähnlichsten ist.


    Zeit spielt dabei eigentlich ein untergeordnete Rolle. Die zu übertragenden Prozessparameter werden nur selten geändert
    und laufen danach u.U. Tage/Wochen unverändert.


    Das Einzige was ich wirklich wissen müsste (ohne die komplette OPC-Doku durchzuarbeiten) ist, ob es möglich ist
    einen Trigger o.ä zu setzen, der bei Variablenänderung auslöst. Ist so etwas möglich, oder muß ich mit dem OPC-Client
    kontinuierlich abfragen (pollen) ?


    Das Projekt wird wahrscheinlich erst nächstes Jahr kommen. Von daher haben wir noch etwas Vorlauf.
    Ich habe mal nach OPC/Delphi gegoogelt und da gibt es schon einige Libraries/Toolkits (kommerziell und OpenSource)
    die zur Verfügung stehen. Hat damit schon jemand gearbeitet und kann evtl. eine Empfehlung aussprechen ?


    dust2
    falls wir nicht anders an die OPC-Doku rankommen, würde ich evtl. gerne auf dein Angebot zurückkommen und
    mich ggfls. per PM bei dir melden.


    Dank nochmals an alle und
    gruß
    addi

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden