Beiträge von zteve

    Hallo zusammen.


    Habe leider gerade keinen Rob zur Verfügung.


    Weiß jemand oder kann jemand ausprobieren, ob es nötig ist bei einer KRC4 nach einem Wiederherstellen > Programme, die Steuerung neu zu starten?


    In der Doku steht, pauschal bei allen Wiederherstellprozeduren "Steuerung neu starten".


    Ich möchte diesen Schritt gerne einsparen.

    Laut doku gibt es diese Funktion (hab ich aber noch nie getestet).


    Auszug Doku:
    "Grenzen für das Umteachen festlegen:
    Beschreibung Wenn diese Funktion aktiv ist, dürfen bestehende Punkte von den Benutzergruppen Anwender und Bediener nur noch innerhalb der festgelegten Grenzen umgeteacht werden......


    .... Im Hauptmenü Konfiguration > Extras > Korrekturgrenze Punktkoordinaten wählen............."


    etc.

    Habe ich mir fast gedacht - die Meldungssyntax verträgt % nicht als erstes Zeichen. Darum mein Vorschlag mal mit einem Leerzeichen vor % zu testen.


    Ich orakle mal: das P_0 könnte für "Parameter X hat keinen Wert, bzw. ist nicht initialisiert" stehen.


    Dann müßte nach meiner Annahme und mit meinem anderen Vorschlag:


    [ltr]Parameter[1] = {Par_Type #Key, Par_txt[] "Init"}
    Parameter[1].Par_txt[] = stText[][/ltr]


    statt "TestP_0" > "TestInit" ausgegeben werden.


    Wäre klasse, wenn du uns über die Antwort von KUKA auf dem Laufenden hältst.


    Gruß, Stefan

    Ich hab noch einen Vorschlag zum Ausprobieren:


    Parameter[1] = {Par_Type #Key, Par_txt[] "Init"}
    Parameter[1].Par_txt[] = stText[]


    Auf diese Weise machst du das auch bei Parameter 2 - ist ein Versuch wert.



    Solltest du es nicht schon probiert haben, versuchs mal nur mit Parameter 1.
    Und teste mal mit einem Leerzeichen vor %1 (MSG.MSG_TxT[] = " %1")



    Du schreibst: "Es wird nur nicht der Text aus der Datenbank ausgegeben."


    Was wird denn ausgegeben? Ist der Platz leer oder wird %1 angezeigt....?

    Anhand des "#key" sollte doch der Text in der Datenabnk gefunden werden oder nicht?


    Es reicht nicht nur den Key anzugeben, es muss auch der Name der Datenbank (Modul), in der der Schlüssel steht, angegeben werden.


    In deinem ersten, funktionierenden Beispiel heißt die kxr-Datei "Test", die darin enthaltene Moduldeklaration ist: <module name="Test">
    Und im Meldungsaufruf ist die Modulbezeichnung: MSG.Modul[]="Test".


    Versuch mal in deinem 2. Beispiel ebenfalls: MSG.Modul[]="Test", oder lege eine neue kxr-Datei "VELOPACK" an.


    Nach meiner Erfahrung funktioniert der Datenbankzugriff nur, wenn:


    [ltr] - die kxr-Datei mit der Modulbezeichnung beginnt (z.B. "Velopack_Sonstwas.kxr").


    - die Moduldeklaration in der kxr-Datei die Modulbezeichnung hat (z.B. <module name="Velopack">).


    - es je kxr-Datei nur eine Moduldeklaration gibt.[/ltr]


    - die Meldung mit der passenden Modulbezeichnung aufgerufen wird (z.B. MSG.Modul[]="Velopack").



    Vielleicht liegt es ja an einem dieser Punkte.


    Btw: Sollte die Deklaration von "Zaehler" nicht INT Zaehler lauten? (Geht aber wohl auch so - du schreibst ja, daß dieser Teil funktioniert)

    Hallo Kollegen


    Ich sammle gerade erste Erfahrungen mit Ethercat und Beckhoff-Hardware am KRC4.


    Stecke ich das Ethercat -Kabel zu einem EP2318-Modul, das als Device am Kuka hängt aus und wieder ein, erholt sich der Bus nicht von selbst.


    Fehler 13068: <SYS-X44> - EtherCAT-Teilnehmer EP2318-0001 4 K.Dig. Ein, 10us, 4K. Dig, ist nicht am Bus angeschlossen.
    Fehler 00099: Fehler beim Lesen/Schreiben: SYS-X44


    Auch nach einem kurzen Spannungsabfall kleiner 3 Sekunden (Steuerung ist nicht heruntergefahren), blieb ein Busfehler anstehen.


    Nur ein Reset im EA-Treiber-Menü startet jeweils den Extension-Bus wieder.
    In der WV-Buskonfiguration gibt es keine Einstellmöglichkeiten für z.B. Hochlaufeigenschaften des EtherCAT-Geräts.


    Ist das Verhalten normal? Wenn ja, wie handelt ihr das?


    Grüße, Stefan

    Habe den Vorschlag von Twister getestet und siehe da, es funktioniert.


    Hab mir vermutlich mit $Pos_Act aus Versehen ne POS in meine Verschiebungen geholt. Was ich ja eigentlich vermeiden wollte.



    Bei der Verkettung mit einem Frame sollte das Ergebnis schon ein Frame sein, somit S und T eigentlich keine Rolle spielen.


    Laut Doku ist das Ergebnis eine POS:
    Eine Frameverknüpfung wird von links nach rechts ausgewertet. Das Ergebnis hat immer den Datentyp des am weitesten rechts stehenden Operanden.
    FRAME : POS -> Ergebnis POS


    Das könnte erklären warum es nach der Umwandlung $Pos_Act zu Frame funktioniert.


    Vielen Dank für eure Beiträge!

    Hallo Kollegen


    Kann sich jemand folgendes Verhalten bei einer Relativbewegung mit dem geometrischen Operator erklären?


    Wenn sich die Achse 6 vor folgendem PTP-Befehl im Bereich -0,01° bis -1,40° befindet kommt die Meldung "Unerreichbarer Punkt Softwareendschalter A6".


    Das Verhalten ist unabhängig der anderen Achsstellungen.





    Steht die Achse 6 beim Start auf z.B. -1,45° fährt der Rob die Bewegung und sie steht dabei am Ende bei ca. +1,9°. (Bsp. 2: Start -2,5° -> Ende +1,0°)


    Vergrößere ich den Wert von X auf z.B. -20 kommt die Meldung nur noch zwischen -0,01° und -0,30°.
    Bis bei X -10 alles problemfrei läuft.



    Habe ich hier was nicht verstanden und ne wichtige Regel für die Manipulation mit dem geometrischen Operator missachtet?


    Vielleicht erkennt ja jemand die mögliche Ursache!? (Übrigens keine Singularitätsstellung und kein Tool-/Basewechsel)


    Gruß, Stefan

    $BRAKETEST_REQ_INT
    Wird TRUE wenn Bremsentest angefordert ist.


    Kann man auch einem Ausgang zuordnen. In der KRC:\STEU\MADA\Machine.dat. Dort gibts insgesamt 6 Variablen für den Bremsentest.
    Die genaue Erklärung findest du in der Doku für Systemintegratoren

    Die GSD "Kuka_EL6695sec.xml" findest du im WV-Installations-Verzeichnis "DeviceDescriptions\ESISec\".
    Die GSD "Kuka_EL6695prim.xml" im Verzeichnis "DeviceDescriptions\ESI\".


    Habe gerade heute ähnliche (TC2) Konstellation in Betrieb genommen. WV 4.0.10 hat sich durch mehrere Abstürze gewehrt die neuste Version und die Byte-Anzahl-Änderungen anzunehmen. Nach Löschen der vorkonfigurierten Geräte und zig Neustarts hat es dann doch noch geklappt.


    Es gibt übrigens eine extra KUKA-Doku für die EL6695.

    @ Roland


    Warum nicht einfach:


    Weil bGrp_closed sich nicht mehr ändert.


    Zyklisch beschreiben geht nur im Sub oder auch mit Zyklischen Flags (s.u.).


    Code
    SWITCH gripper_name
       CASE Grp1
          $Cycflag[1] = diGrp1_closed
       CASE Grp2
          $Cycflag[1] = diGrp2_closed
    ENDSWITCH
    
    
    WAIT FOR ($Cycflag[1]==TRUE)


    Edith: 3 Dollar spendiert

    Ich kann dir keine genauere Erklärung geben, aber ich weiß, daß eine Änderung von A meist auch auf B und C wirkt.
    Drehreihenfolge: A (um Z) - B (um die neue Y-Achse) - C (um die neue X-Achse)


    Daher: Für deine Berechnung würde ich den Geometrischen Operator verwenden.


    Ungefähr so:


    DECL FRAME Hilfsframe
    Hilfsframe = $NULLFRAME
    Hilfsframe.A = PLC_ANGULAR


    CALCULATED = CALCULATED:Hilfsframe