Posts by panic mode

    genau....


    und da Bus zyklus 4ms ist, schneller schreiben von Ausgang in Programm wird nicht hilfreich da Bus ist Flashenhalls und so werden Pulses verlohren.


    Aber mit 5ms warte instruktionen, Zeitschlitz fuer Submit ist immer ueberschritten und damit 12ms IPO wirkt als Flashenhalls. Das bedeuted Ein/Aus Zeit ist 24ms oder laenger.


    Und wehn Drehung ist kurzer als 24ms, wirds ruckelig mit mehrere Umdrehungen.

    Die Schleife läuft die vorher gewünschten Schritte ab und stoppt dann, je nach zu bewegender Distanz sind es mehr oder weniger Schritte.

    So gehts... aber mag zu langsam sein. Die Frage is wie lange so was wirklich dauert und ob Drehungen kontinuirlich order zerstueckelt sind... Mit PTO Klemme gehts immer schneller. 1000 oder 10000 pulse in ein paar ms ist kein Problem

    macht kein Sin... 0,005s ist 5ms. Pulse jede 2ms geht einfach nicht. auch nicht mit SPS staat KRC da Ausgang wird immer TRUE (5ms>2ms).


    auch 5ms geht nicht. Submit lauft auftretend jede 12ms und Zeitschlitz ist sehr eng.


    und wehn jede 12ms Ausgang is ein und ausgeschaltet, bedeuted ein Zeitraum ist 24ms und max 1000ms/24ms=41.67Hz


    so was ist einsaetzbar fuer zehr langsame dinge... kanst vergessen alles <24ms.


    solche Dinge loest mann mit specialle Klemmen wie EL2521. weiss nicht ob die von KUKA untertuetzt sind.

    Wie gesagt schlägt bei dem Roboter der Bremsentest fehl.

    kanst du bitte details erwahnen? roboter hat mehrere Achsen, vieleicht auch zusatz achsen. sind alle achsen betroffen?


    falls test bremsprogram falsch ist, A3 bremsfehler ist absichtlich gesetzt - auch wehn Bremse in ordnung ist. so ueber welchen test wird geredet?


    und was fuer bremstestparameter benutzt sind? was ist MaxSafetyFactor? muss mehr als 1 sein, aber untershied zwischen 1.01 , 1.10 order 1.25 ist ziemlich bedeutsam.


    bremsausfall in einem Jahr ist ... merkwurdig (sehr). auch fuer roboter that funzt 24/7 und Nothalt 10x per Tag ausgeloest ist.

    das war nur ein Fehler...


    Andere Problem hat mit Scope zu tun...

    da ENUM in SRC deklariert ist, es ist nur inerhalb dieser routine bekant. Funktion BEST_MOVE() hat keine Ahnung von FILED_TYPE.


    Da mehr als eine Routine/Funktion mit FIELD_TYPE umgehen, relevante deklarierungen mussen von SRC nach DAT verschiebt sein:


    Code
    ENUM FIELD_TYPE empty, cross, circle
    DECL FIELD_TYPE field_status[3,3]

    mode wechsel um variablen wert bestaetigen?

    warum nicht einfach Variablen Overview nutzen?


    und ist KRC wirklich in EXT?


    z.B der Z Wert wird verarbeitet, d.h wenn ich denn verändere und ein Programm manuell abarbeite ändert er mir den Wert in der Config

    bei dem 0V_PLC aber nicht, also wenn ich EXT Starte und ein durchlauf mache-> wechsel in T1 um zu schauen ob da sich was geändert hat, dann steht da immer 0

    Das heißt doch dass dieses IF nicht ausgeführt wird?


    Nein...


    bedeuted dass OV_VON_PLC ist nicht wirklich von PLC controliert. (falsche deklarierung? EA Bereich?)

    versuche es mit OV_von_PLC als INT. damit kanst du PLC simulieren.

    natuerlich nicht.. Aber da Koordinatensysteme Parallel sind, konversion von CM auf Flange ist einfach (mit "parallel axis theorem")

    Ixx=Lxx+M(Y^2+Z^2)

    Iyy=Lyy+M(X^2+Z^2)

    Izz=Lzz+M(X^2+Y^2)


    wo Lxx, Lyy,Lzz ist inertia um Schwerepunkt

    Ixx,Iyy,Izz is inertia X,Y,Z offset (Flange)

    X,Y,Z ist CM offset

    M is masse


    aber da CAD lastdaten bereits auf Flange bezogen ist, keine offset-umrechnung ist notig (mit offset, inertia ist gosser und werte sind bereits drin). mann muss aber ohne CM distanzen (bereits drin)


    ; Schwerpunkt bezogen:

    LOAD_DATA[n].M=M

    LOAD_DATA[n].J.X=Lxx

    LOAD_DATA[n].J.Y=Lyy

    LOAD_DATA[n].J.Z=Lzz

    LOAD_DATA[n].CM.X=X

    LOAD_DATA[n].CM.Y=Y

    LOAD_DATA[n].CM.Z=Z

    LOAD_DATA[n].CM.A=Rz

    LOAD_DATA[n].CM.B=Ry

    LOAD_DATA[n].CM.C=Rx


    ; Flange bezogen:

    LOAD_DATA[n].M=M

    LOAD_DATA[n].J.X=Ixx ;Lxx

    LOAD_DATA[n].J.Y=Iyy ;Lyy

    LOAD_DATA[n].J.Z=Izz ;Lzz

    LOAD_DATA[n].CM.X=0 ;X

    LOAD_DATA[n].CM.Y=0 ;Y

    LOAD_DATA[n].CM.Z=0 ;Z

    LOAD_DATA[n].CM.A=Rz

    LOAD_DATA[n].CM.B=Ry

    LOAD_DATA[n].CM.C=Rx

    Bin für alle Anregungen und Ideen dankbar.

    Alle Anregungen?


    EKI

    OPC

    durch SPS E/A

    Datai mit CWRITE auslesen

    DirectoryLoader

    Eigene Applikation entwickeln (KVP/KVP C4/C3Bridge)

    RSI

    SPI

    Morse code

    usw.


    Was wäre eurer Meinung nach die einfachste und günstigste Lösung?

    Datai mit CWRITE auslesen ist einfach und günstig da auf allen KRC4/KRC5 schon bei. und TXT/CSV Datai mit program (oder per hand) erstellen ist kein Problem.

    Zeile 8, fehlt Anfuhrungzeichen am Ende. Also RawData ist nur 63 Character lang, nicht 850.

    Zeile 9, nein, so geht es nicht... arrays mit einer Schleife kopieren - oder auch StrCopy() fuer CHAR arrays.

    Zeile 11, nein, Zeichenkette ist in RawData[]


    oder liber so, da Queldata format mehrere Trennzeichen hat:

    Code
    FOR i=1 to slen
    SWITCH RawData[i]
      CASE ",", "(", ")" 
        src[i]=" "
      DEFAULT
        src[i]=RawData[i]
      ENDSWTICH
    ENDFOR

    Gibt es eine Möglichkeit, LIST-Elemente mit SHOWVAR zu aktualisieren? Ziel ist es, einige benutzerdefinierte Inline-Formulare zu erstellen und eine benutzerfreundliche Werkzeug- und Basisauswahl zu ermöglichen. Liste sollte Namen statt Nummern zeigen - auch wenn Namen geändert wurden.


    Code
    DECL PARAM ToolList = {VALUE {LIST : ... }}
    
    
    SHOWVAR(FULLPATH[] "TOOL_NAME[,]", PARAM ToolList )
    ;oder einzeln..?
    SHOWVAR(FULLPATH[] "TOOL_NAME[3,]", PARAM ToolList[3] )
    SHOWVAR(FULLPATH[] "TOOL_NAME[3,]", PARAM ToolList.Item[3] )
    SHOWVAR(FULLPATH[] "TOOL_NAME[3,]", PARAM ToolList.Item[3].Value )
    SHOWVAR(FULLPATH[] "TOOL_NAME[3,]", PARAM ToolList.Item[3].Value[] )

    example showed StatusKey using two scripts - to both set and reset output. programmer can control what is or isn't in those scripts. for example one could not change output state when StatusKey is released


    it should be possible but exact robot position would need many outputs (6 axis * 32 bit/axis = 192 bits). it is recommended to read UserTech description about intended use.


    reboot is not needed unless changes are in the menu (*.config file)


    nobody knows what is inside the program that is not shared

    Von wie vielen Robotern reden wir? kuka-Optionen kosten Geld und müssen an jedem Roboter installiert werden. Wenn die Maschinen bereits mit der SPS verbunden sind, warum nicht einfach mit der SPS kommunizieren?