Beiträge von stoeven

    Kommt CONT nur bei C_DIS rein oder auch bei anderen? :denk:


    Bei PTP kann ich laut Handbuch auch schreiben:

    Zitat

    PTP PUNKT3 C_PTP C_ORI

    Wie sieht das im Fold aus wenn mehrere Parameter angegeben werden? Und was mit C_VEL? Kann ich das auch da hinten dranschmeißen? Wie würde es dann aussehen mit dem Fold? :kopfkratz:


    So vielleicht (für C_VEL, C_ORI, C_DIS ?


    Was passiert mit der DAT wenn ich anstatt wie oben (C_DIS) jetzt C_PTP, C_ORI, C_VEL verwende (Für PTP, CIRC, LIN)?


    Vielen Dank für eure Hilfe!! :zwink:


    EDIT -> Aus dem ReferenceGuide der Steuerung: "In der PTP-Anweisung programmieren Sie nun das Schlüsselwort C_PTP und für die FEstlegung des Überschleifens eines der Schlüsselwörter C_DIS (Default), C_ORI oder C_VEL."
    Damit hat sich die Frage nach den Parametern bei PTP geändert: Wie sieht das aus wenn ich C_PTP und zb C_VEL hinschreibe (für SRC und DAT)?


    EDIT2: Bei LIN-PTP Überschleifen kann man C_PTP und C_DIS/C_VEL/C_ORI verwenden, oder? Bei LIN-LIN/LIN-CIRC kann man ja nur eines verwenden C/DIS/C_ORI/C_VEL!

    Hallo an alle Leser!


    Folgende Ausgangssituation:
    Ich habe eine SRC- und eine DAT-Datei in der lesbarer und vom Roboter verwertbarer KRL-Quellcode ist. Die Datei soll nun trotzdem durch einen Postprozessor laufen -> die Befehle sollen in die FOLD-Technik übersetzt werden.


    Ein einfaches Beispiel. Folgende Zeile wird gelesen:

    Code
    LIN P2 C_DIS

    Anmerkung: Anstatt C_DIS gibt es auch nach Benutzerhandbuch C_ORI, C_VEL.


    Dann wird jetzt aus

    Code
    LIN P2

    zu

    Code
    ;FOLD LIN P2 Vel=2 m/s CPDAT1 Tool[1]:Gripper Base[0];%{PE}%R 5.5.31,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P1, 3:, 5:2, 7:CPDAT1
    $BWDSTART = FALSE
    LDAT_ACT = LCPDAT1
    FDAT_ACT = FP2
    BAS(#FRAMES)
    LIN XP2
    ;ENDFOLD


    Was geschieht aber mit "C_DIS" und Co? Wie übersetze ich das?


    In der DAT steht:

    Code
    DECL E6POS XP2={X 1248.0,Y 6.92704475E-07,Z 1320.01099,A 47.3372688,B 89.9959183,C 47.3372688,S 6,T 50,E1 -0.000119416603,E2 0.0,E3 0.0,E4 0.0,E5 0.0,E6 0.0}
    DECL FDAT FP2={TOOL_NO 1,BASE_NO 0,IPO_FRAME #BASE,POINT2[] " ",TQ_STATE FALSE}
    DECL LDAT LCPDAT2={VEL 2.0,ACC 100.0,APO_DIST 100.0,APO_FAC 50.0,ORI_TYP #VAR,CIRC_TYP #BASE,JERK_FAC 50.0}


    Im Prinzip müsste das ja nach den Versionen (hier R 5.5.31) unterschiedlich gehandhabt werden (Also der FOLD sieht ja je nach Version "anders" aus...). Wie könnte ich das selber auf dem KCP ausprobieren (falls das geht, falls der mir das automatisch iwie übersetzt; ExpertTech ist installiert auf KRC2)?


    Wenn ich "C_ORI", "C_DIS" und Co wandeln will, muss ich aber wissen wie das in der FOLDer Technologie übersetzt wird :huh:


    Reicht es hier aus, wenn ich in ind DAT schreibe: DECL LDAT LCPDAT2 mit: APO_DIST 100.0 ? Irgendwie bin ich ratlos. Weiß nicht wo und wie das übersetzt wird. Jedenfalls darf das doch nicht verloren gehen, wenn ich die FOLD-Beispielzeile von oben nehme?!


    Vielen Dank für eure Hilfe vorab!


    Beide Lösungen erfordern den Umbau des Postprozessors, oder einen zweiten nachgeschalteten.


    Ja und Ja!!!!! Und jaaa endlich... es scheint angekommen. So wie ich das seh, muss ich entweder einen neuen nachgeschalteten Postprozessor schreiben (Szenario1), oder eine zweite Variante finden wo das Programm auf dem Setup vor Ort (Zelle) übersetzt wird (Szenario2).


    Und nix mit PowerPoint. Das ist bitterer Ernst! Ich MUSS eine Lösung finden, vorschlagen, umsetzen und testen bzw. vorzeigen.



    Bleiben nur die beiden Vorschläge mit den Konfigurationsdateien oder dem Werker, der Lesen und Schreiben kann.


    Stellt euch doch einfach mal vor, dass es in kleinen und mittelständischen Betrieben keine festangestellten Programmierer gibt. Was ist daran denn bitte so unklar, dass man das Szenario hier verniedlichen muss und meinte "Lernt Schreiben und Lesen" ....


    Ich MUSS dafür Sorge dafür tragen und mir einen Kopf machen darüber, dass es auch in Zukunft möglich ist (in verschiedenen kleinere Firmen), eine Veränderung am Roboterprogramm vornehmen zu können .


    Hast du denn eine andere, bessere, konkrete, einfachere Lösung als ich, Urmel? Von mir aus kannst du meine Szenarien-Beschreibung vergessen. Die Ausgangssituation und das Ziel sollte klar sein. Alles was dazwischen liegt, ist verhandelbar! Nur die beiden Szenarien sind mein Ansatz bzw. Ansätze das Problem zu lösen.


    Generell find ich es schade, dass sich nicht noch mehr Leute an der Diskussion beteiligen. Vll. liegts auch daran, dass hier schon so viel geschrieben wurde..... :(


    Wenn man nicht alle Roboterprogramme neu schreiben will, braucht man ja irgendwo einen Anfang.


    Wieso "neu schreiben"? :huh:



    Für Variante 1 muss man dann sehen, dass man Roboterprogramme generieren kann, die den vorhandenen nahe kommen.


    Wir gehen mal davon aus, dass es eine Simulationssoftware gibt, die lauffähigen KRL-Code produziert. Ob ein Postprozessor einen "universellen" AblaufCode in zB KRL-Code wandelt, ist relativ egal. Ich komme da nicht ran, da ich nicht die API hab und auch selbst wenn ich sie hätte nicht öffnen will.



    In der zweiten Variante muss man die Roboterprogramme auf den Zielsystemen entsprechend umbauen und sehen, dass das mit den generierten Programmen zusammenpasst.


    In jedem Fall muss ich "Mache dies und das" dem Roboter beibringen können. Wie das geht, ist erstmal für mich egal.



    Einfacher hat man es sicher, wenn man nur mit neuen Systemen anfängt. Auf jeden Fall wird man dann Zugriff auf entsprechende Robotersysteme brauchen, um sein Produkt dann auch zu testen.


    Das ist für mich wichtig... zu wissen: Was macht weniger Aufwand? Was lässt sich auf viele Fälle beziehen, wo Zellen einen gleichen Aufbau haben? Was kann ich jetzt für eine Lösung vorschlagen, so dass ich ein erstes Ergebnis ziemlich schnell vorführen könnte?


    Was für mich wichtig ist bei der Auswahl eines Szenarios: Wie schaffe ich es am Einfachsten, ein Roboterprogramm zu "updaten", nachdem erkannt wurde, dass dort ein Teil des Codes angepasst werden muss - unter der Voraussetzung das der Anwender DIES NICHT KANN!
    Es geht dabei ausschließlich um Technologiebefehle (externe zusätzliche Prozessparameter).

    Ich weiß jetzt nicht genau was du mit Offline-Tool meinst, aber in der Entwicklungsumgebung des Roboterprogrammes gibt es auf jeden Fall einen Postprozessor der KUKA KRL unterstützt (einige wenige Versionen...) (via VBA-Script).


    Anpassung des Codes soll wohl auf jeden Fall Offline passieren. Naja, der Anwender an der Maschine versteht den Code ja wohl nicht - insofern kanns ka nur Offline vom Experten aus Externshausen passieren.


    2 ist dann entweder eine Art Interpreter, der eine Scriptsprache abarbeitet, oder ein Programm vom Typ 1, dass für bestimmte Funktionen auf Bibliotheken zurückgreift, die schon auf dem Zielsystem vorliegen.


    Genau!


    Ich sehe die beiden Wege, ... gibt es noch andere?


    Welches Szenario macht nun mehr Sinn? Welches wäre wahrscheinlich (mit eurer Erfahrung) einfacher umzusetzen?



    Schon klar, aber die beiden Ansätze widersprechen sich nicht wirklich, in unserer Software tauchen sie beide gemeinsam auf.

    Höh?? SW? Wie? Was? ... :huh: Welche SW?


    Ok, wir gehen davon aus, dass das entwickelte Roboterprogramm auf den IR in der Zelle passt. Das ändert eigentlich nichts an meiner Frage. Das Problem bezieht sich explizit nur auf die weiteren Prozessparameter (bzw Technologieparameter!), wie eben ein angeschlossenes Gerät (Schweißanlage, Kleber, Fräser, usw.). Da der externe Programmierer zwar den Roboter kennt, aber nicht die einzelnen angeschlossenen Ein/Ausgänge, kann er nicht sagen wie er das Gerät steuert


    Beispiel:
    --> er kennt bspw nicht die Bitreihenfolge von der Schweißanlage, um den Drahtvorschub zu ändern. Er verwendet den Befehl im Programm "Erhöhe Strom um 5V" (Strom und Drahtvorschub hängen immer zusammen).
    Im Szenario1 wird mittels der Zellkonfig das direkt in einen Befehl umgewandelt den die Schweißanlage versteht (richtiges Absenden einer legalen Bitreihenfolge). Im Szenario2 müsste das vor Ort geschehen. "Erhöhe Strom um 5V" ist dort bekannt und wurde in einer cfg entsprechend vereinbart und ist bekannt.


    Ich hab mich doch extra bemüht, nicht grob zu sein. :angel:


    Und extra nichts dazu geschrieben, dass "eine externe Firma ein unspezifisches Roboterprogramm entwickelt". :mrgreen:


    Ich wollte damit sagen, dass das entwickelte Programm nicht speziell auf einen spezifischen Hersteller ausgerichtet ist. Sondern erst im Nachhinein mittels eines Prostprozessors zugänglich gemacht wird für einen speziellen IR.

    Angenommen: Es gibt eine Zelle. 1 Roboter, 1 Schweißanlage. Dieses Setup ist mehrmals verkauft worden und bei mehreren Kunden im Einsatz. Der Kunde selber hat nun mehrere Programme mit denen er Roboter und Schweißanlage bedienen kann. Der Anwender bekommt das Programm, lädt es, und das Setup erledigt den Rest (die eigentliche Arbeit).


    Nun ist die Ausgangslage aber so, dass der Anwender eigentlich keine Ahnung hat wie ein Roboterprogramm aufgebaut ist. Er kann es starten und stoppen - kann Technologieparameter (falls diese nicht 100%ig stimmen) nicht ändern.


    Der externe Programmierer weiß ja letztlich nicht wie das in Realität funktioniert. Simulationsumgebung entsprechen nie 100%ig der Realität. Es kann also sein, dass der Drahtvorschieb an der Positiion XY geändert werden muss, weil die Schweißnaht nicht "gut" ist.


    Es gibt zwar nur 1 Roboterprogramm, dass die SPS "steuern" kann, aber es gibt 2 Wege um bis dahin zu kommen: 2 Szenarien.


    Szenario1: Entwickler hat komplette Entwicklungsumgebung (Konfigurationsdatei der Zelle, Welcher Roboter? Welche Sprache? Welche Ein/Ausgänge? Wie steuer ich die Schweißanlage? etc..). Mit diesem Wissen kann er an alle Kunden mit dem gleichen Hardware-Setup das Programm schicken. Vor Ort muss nichts konfiguriert werden.


    Szenario2: Der Entwickler weiß nicht wie er die Ausgänge ansteuert um zB den Drahtvorschub einer angeschlossen Schweißanlage zu manipulieren. Daher verwendet er eine vereinbarte Konvention: Variablendeklaration, diese ist auf jeder Maschine bekannt. Im Szenario2 werden also nur "allgemeingültige" Variablen verwendet, und die SPS kennt sie, weil diese vor Ort vereinbart wurden.


    Ist das ein wenig besser rübergekommen... ich weiß sonst nicht wie ich das klar machen soll :-|


    PS: Ich greife ein Problem auf, dass viele kleine Betriebe haben, die sich einen Programmierer oder eine Fortbildung nicht leisten können. Das Szenario an sich, die Tatsache dass vor Ort niemand da ist um etwas zu ändern - BITTE NICHT ANZWEIFELN... das ist nun mal so bei Aufgabenstellungen. Das bitte hinnehmen als Bedingung beim Suchen einer Lösung.

    Hallo Forum-Gemeinde,


    ich richte eine erweiterte theoretische Aufgabenstellung an euch. Ich habe ein Problem und bin so langsam eine Lösung näher gekommen. Das Problem wurde hier schon einmal aufgefasst: http://www.roboterforum.de/rob…-krc1/msg53884/#msg53884.


    Ein Besitzer einer Roboter-Zelle und dazugehöriger weiterer Prozessparameter (zB eine Schweißanlage, Fräsanalge o.ä.) ist nicht in der Lage ein Roboterprogramm zu manipulieren, dahingehend dass er nicht weiß wie man zB einen Schweißstrom/Drahtvorschub o.ä. ändert. Er sieht letzten Endes nur am gefertigten Prozess, dass an einer Stelle eine Änderung von Prozessparametern (Technologiebefehle) geändert werden müssen. Da er nicht weiß wie das geht, gibt er beim Entwickler an. an welcher Stelle es hakt und der Entwickler schickt den aktualisierten Programmteil zurück.


    Es entstehen zwei Szenarien, die sich nun gegenüberstehen und wo ich eure Hilfe brauche. Ich muss mich für eins entscheiden und umsetzen und begründen können warum ich den Weg so gehe!


    Szenario 1:
    - Externe Firma mit eigener Entwicklungsumgebung (CAx), grober Ablauf des IR wird geplant, unspezifisches Roboterprogramm wird entwickelt
    - eine "Zellenkonfiguration" wird geladen (sie enthält Manufactor IR, RobotLanguage, Ein-/Ausgänge des IR usw)
    - externer Postprozessor übersetzt das Programm in die gewünschte Form, die der IR laut Zellkonfig erwartet
    - Programm kann so - OHNE Vorkonfiguration des IR/SPS etc. gestartet werden


    Szenario 2:
    - wie im Szenario eins entwickelt eine externe Firma ein Roboterprogramm (zunächst universell, dann mittels Prostprozessor in gewünschte Sprache des IR)
    - angesteuerte/überwachte Ausgänge/Eingänge werden durch Variablen angefahren
    - es existiert keine Zellkonfiguration, kein Postprozessor, der weiß welche Ausgänge wie anzusteuern sind
    - der Roboter muss vorkonfiguriert werden -> wird im Roboterprogramm ein Zugriff auf ein Ausgang vereinbart so muss das in einer Konfiguration stehen
    - im Prinzip übersetzt die Robotersteuerung den Befehl und weiß anhand der Deklarationen wie die Ein/Ausgänge anzusteuern sind



    Ich hoffe, dass was ich meine, wird hier klar. Im Prinzip entspricht das den zwei bekannten Wegen einem Roboter beizubringen welche Ein-/Ausgänge anzusteuern sind. Der Unterschied in den Szenarien besteht nun darin, wo ich mein Code übersetzen lasse.


    Im Szenario1 weiß der Entwickler genau Bescheid darüber, wie die Zelle aussieht, anhand einer Zellkonfigurationsdatei. Das Programm kann so wie es ist, dem Robter zugeführt werden. Im zweiten Szenario hat der Entwickler keine Ahnung über externe Prozessparameter. Er kennt zwar meinetwegen die Sprache (Sprachversion etc), aber nicht die externen Komponenten. Er verwendet "allgemeingültige" vereinbarte Variablen (o.ä.) wie zB. "Greifer öffnen" etc. Im zweiten Szenario wüsste der Roboter schon was sich dahinter verbirgt...


    Ich hoffe auf eine rege Diskussion :hilfe:


    Vielen Dank vorab für jede Idee Eurerseits :danke:


    Grüße :zwink:

    Erst einmal Danke an die bisher vorgeschlagenen Ideen und an Ihre Poster! Vielen vielen DANK!! :danke:


    UserTech ist in der Tat ein Möglichkeit auf dem KCP das Menü zu ändern, dahingehend dass ich bestimmte Befehle als Macros/InlineFormulare in dem Menü einfügen kann. UserTech müsste aber an jeder Maschine installiert werden und kostet zudem ein kleines Sümmchen.


    Meine Aufgabe war eine Lösung zu finden, in der erstmal keine Zusatzsoftware installiert werden soll. Das heisst UserTech-Lösungen oder andere via bspw. OPC-Server gehen nicht/dürfen nicht (vorerst) angewandt werden.


    Es geht darum, dass jemand an einen Roboter ein externes Zusatzgerät installiert hat (Fräse, Schweißmaschine etc.). Das Roboterprogramm kann vom Bediener gestartet werden. Jedoch verfügt der Benutzer in dem Szenario nicht über die nötigen Kenntnisse im Roboterprogramm die entsprechenden Bits zu ändern, um bspw. eine Schweißanlage zu manipulieren. Eine Manipulation über die Schweißanlage selbst ist sicherlich denkbar (auch ein Bedienpanel, Display ...), aber eine Wiederholung/Automatisierung/Fortführung unter veränderten Parametern ist NICHT mehr gegeben. Es muss eine Änderung der Parameter im Roboterprogramm geben, der Benutzer verfügt aber nicht über das Wissen, wie er das machen soll.


    HABT IHR WEITERE IDEEN? Ich habe keine Ahnung wie ich die Aufgabe lösen soll.....


    Ich bin über JEDEN VORLSCHLAG froh und glücklich - wirklich!!


    Grüße! :-|

    Hallo,


    habe ebenfalls KRC1, aber keine Install-CD mehr. Kann mir jemand das bitte schicken? :roll:


    Und ja, sry, ich weiß ja dass der Thread URALT ist :angel: