Posts by Kevin97

    Vielleicht ist die Lösung auch zu simple gedacht aber schreib doch einfach jedes mal die entsprechenden Tool Daten um ?

    In die Config:
    DECL REAL TD_Kamera_X=0.0
    DECL REAL TD_Kamera_Y=0.0
    DECL REAL TD_Kamera_Z=0.0
    DECL REAL TD_Kamera_A=0.0
    DECL REAL TD_Kamera_B=0.0
    DECL REAL TD_Kamera_C=0.0

    ;Die Signale der Kamera einmal auswerten und jeweils beschreiben:
    TD_Kamera_X=giTD_Kamera_X
    TD_Kamera_Y=giTD_Kamera_Y
    TD_Kamera_Z=giTD_Kamera_Z
    TD_Kamera_A=giTD_Kamera_A
    TD_Kamera_B=giTD_Kamera_B
    TD_Kamera_C=giTD_Kamera_C

    ;Werkzeugdaten beschreiben:
    TOOL_DATA[1].X=TD_Kamera_X
    TOOL_DATA[1].Y=TD_Kamera_Y
    TOOL_DATA[1].Z=TD_Kamera_Z
    TOOL_DATA[1].A=TD_Kamera_A
    TOOL_DATA[1].B=TD_Kamera_B
    TOOL_DATA[1].C=TD_Kamera_C

    ist es dann dann so, dass man z.B. GripperTech nicht mehr bräuchte? Kannst mir nur gerade schwer vorstellen.

    Hat denn jemand auch Erfahrung, ob das Recovery (Grundstellungsfahrt) gut naschträglich zu implentieren geht (KSS 8.6.6)?

    Nein, wenn du GripperTech Funktionen nutzen möchtest (Statustasten usw.) brauchst du natürlich auch das Optionspaket.

    Kommt drauf an was du unter nachträglich verstehst bzw. ob ich dich jetzt richtig verstanden habe. Wenn du eine schon komplett fertige/funktionsfähige Anlage hast, würde ich davon abraten nachträglich AppTech zu installieren. Wenn man AppTech nutzen möchte weil man z.B. die Recovery Funktion haben möchte dann am besten schon von Anfang an ab Projekt Start.

    Sowohl AppTech als auch die Recovery Funktionen bauen nämlich darauf auf auch die jeweiligen AppTech Templates und Strukturen verwendet zu haben.

    Kontrollier mal das die 3-4 Ausgänge die für die Betriebsart vom Fronius zuständig sind, nicht vom Roboter in irgendwelchen anderen Hintergrund Programmen aufgerufen und fälschlicherweise umgeschrieben werden.
    Das war bei uns schon an mehreren Anlagen der Fall.

    Die Programmnummer erhältst du im Regelfall von der SPS.

    Da müsstest du dich mit dem SPS Programmierer kurzschließen über welche Programmnummer ihr den welches Programm aufrufen wollt. Wichtig dafür ist aber auch das ihr die AutoExtern Signale bzw. die Signale für die "PGNO" vernünftig verschaltet habt, sofern ihr diese verwenden wollt. (Stehen Default im Cell).


    Das Interrupt ON und OFF so wie die IF Anweisung mit der Grundstellungsfahrt kannst du ignorieren

    Moin,

    jap. Passiert leider häufiger als das es noch lustig ist.

    Auch gerne an der KRC5.

    C -> KRC -> SmartHMI -> SmartHMI.exe (KSS 8.7.5)

    Ansonsten einfach mit der Bildschirmtastatur im Suchfeld nach Smarthmi.exe suchen

    Dann sollte das HMI wieder starten.

    Aber Achtung, wirklich helfen kann nur ein Neustart, denn es kann vor kommen das manche Funktionen nicht mehr nutzbar sind wenn du das HMI so wieder gestartet hast

    Jetzt stellt sich mir noch die Frage mit welcher Geschwindigkeit hier der Roboter fährt?
    Grundsätzlich funktioniert das so, das hab ich grade am Robi getestet.

    Du kannst die Geschwindigkeit für die Lin-Fahrt vorher beschreiben wenn du den Punkt nicht per ILF aufrufst.

    $VEL.CP=0.5 ;gewünschte Geschwindigkeit

    LIN Xziel:Offset

    Bei "WAIT FOR Input1 AND Input2 AND Input3" ist es egal in welcher Reihenfolge die 3 Signale auf TRUE gehen. Du sagst dem Robi ja nur, warte bis die Bedingung erfüllt ist. Da ist die Reihenfolge egal.

    Wenn man es genau nimmt hast du ja mindestens 8 Optionen.

    Wie mein Vorredner schon sagte, wäre Option 2 die Reihenfolge dann egal ....

    Ja also das die Reihenfolge wie ich den Befehl aufschreibe egal ist, ist mir klar, was ich aber eigentlich wissen wollte war mehr im Sinne von es sind als Beispiel 3 Eingänge von 3 Greifern.

    Greifer 1 ist so gedrosselt eingestellt das er 50 Sekunden zum öffnen braucht.

    Greifer 2 und 3 brauchen nur 20 Sekunden

    Weiß der Roboter bei Option 2 denn jetzt nach 20 Sekunden schon das zwei Bestandteile der "Gesamtbedingung" erfüllt sind und hat es sich doof gesagt schon "gespeichert" oder kontrolliert er diese beiden Bestandteile erst nach 60 Sekunden nachdem der erste Eingang da war ?

    Wie gesagt, das er auf die Gesamtbedingung wartet ist mir klar, ich wüsste halt nur für mich gerne ob er bei Option 2 trotzdem eine Reihenfolge einhält in der er prüft oder es ".sub mäßig" immer wieder durchkontrolliert wird bis irgendwann alle Bestandteile erfüllt sind ^^

    Hallo zusammen,

    bei mir ist letztens eine Frage aufgekommen auf die ich bisher keine wirkliche Antwort finden konnte...

    Es ist eine ziemlich banale Frage, aber trotzdem, wie ist die Bearbeitungsreihenfolge von "WAIT FOR" Befehlen ? ^^

    Was genau meine ich..

    Wenn ich zum Beispiel auf 3 Eingänge warten will habe ich theoretisch ja mal zwei Optionen:

    Option 1:

    Code
    WAIT FOR Input_1
    WAIT FOR Input_2
    WAIT FOR Input_3

    Hier ist die Reihenfolge in der die Befehle abgearbeitet werden ja klar.

    Option 2:

    Code
     WAIT FOR Input_1 AND Input_2 AND Input_3

    Spielt hierbei jetzt die Reihenfolge eine Rolle bzw. was ist die Reihenfolge in der die Signale geprüft werden ?

    Also klar, es wird darauf gewartet, dass die "Gesamtfunktion" True ist, aber kontrolliert die Steuerung hier auch erst Input_1 und erst wenn dieser dann True ist Input 2 und dann 3 oder passiert das Schreibreihenfolgen unabhängig ? :/

    Das Optionspaket "AppTech" z.B. muss übrigens tatsächlich lizensiert werden. Man erhält beim Kauf von Kuka eine Lizenz dabei. Die muss sich auf der Steuerung befinden und wird immer wieder im Hintergrund überprüft.

    Ist die Lizenz abgelaufen und/oder nicht vorhanden, wird der EXT Modus gesperrt und man kann den Roboter nur noch in T1/T2 bedienen.

    Denke mal das sowas auf Dauer bei mehreren neuen Optionspaketen folgen wird..

    Wenn ich mich nicht täusche benötigte man für OfficeLite ja auch eine gültige Lizenz.

    Für alle die eventuell auch nochmal das Problem haben..

    Vorgehensweise:

    > Dateien in Template-Ordner kopieren

    > Auf Win wechseln, C:\KRC\UTIL\KRCCONFIGURATOR\KrcKonfigurator aufrufen, Reiter "Templates, Templates list"

    > Neues Template Definieren (Name, -> Add to all…

    > Enable for Directory (Directory Default ist nicht ausreichend! -> Program usw. extra einrichten!, Vergleich mit den bestehenden Templates)

    > Full path setzen (es muss natürlich das betreffende neue src/dat-File im Template-Ordner vorhanden sein.

    > Define for users

    > Apply

    Bin zwar aus der Kuka-Sparte aber finde die Idee grundsätzlich gut, bin eh ein Freund davon eher einen "vernünftigen" Dauerlauf zu haben als eine bis ans Ende ausgereizte Taktzeit mit dafür häufig verbundenen Fehlern.

    Ein weiterer Vorteil wäre nach außen hin natürlich aus der der Roboter "keine Stillstands Zeiten" mehr hat, was ja alle immer gerne sehen wollen.

    Sehe nur auf Dauer ein Problem von eventuell anderen abhängigen Anlagenteilen...seien es Sensoren die wegen gewissen Bauteilen früher/später kommen oder Mechaniken die verschleißen und mal länger brauchen können.

    Dann fängst du nach einem "langsamen" Prozess an nach unten zu regeln, wobei der nächste aber wieder so schnell ist das die Anlage sogar auf den Roboter wartet :/

    Vielleicht wäre es ja eher eine Idee mal z.B. 100 oder 1000 Durchgänge zu beobachten und dann gewisse Geschwindigkeiten & Beschleunigungen einfach Dauerhaft zu reduzieren wenn immer die nahezu selbe Stillstands Zeit besteht ^^