Beiträge von rmac

    Hallo PorscheRobAdmin,


    wenn das Minus in der eckigen Klammer weggelassen wird, wäre der Index für den Ausgang (hier "Nr")
    unzulässig, weil < 0, d.h. es würde wahrscheinlich eine entsprechende Fehlermeldung ausgegeben werden
    (vermute ich mal)


    Das "-" (Minus = Multiplikation mit -1) führt zu einer Umdrehung des Vorzeichens ("Minus mal Minus gibt Plus"),
    d.h. aus -100 wird +100 und damit wird der Index wieder zulässig.


    hth
    rmac

    Hallo Martin,


    also ich fände den "Kunstgriff" mit den virt. Ausgang jetzt nicht so schlimm und
    hätte auch keine Skrupel das anzuwenden :grmpf:


    ...aber schlimmstenfalls kannst du das auch mit einer eigenen Funktion selbst
    prüfen. Ist bei einer quaderförmigen WZ ja nicht so schwierig.


    z.B. so:

    Code
    FUNC BOOL TCPInWZBox(POS p1, POS p2)
        POS pCur;
        pCur := CPos(\wobj:=wobj0);
        RETURN (pCur.X >= p1.X) AND (pCur.Y >= p1.Y) AND (pCur.Z >= p1.Z) AND (pCur.X <= p2.X) AND (pCur.Y <= p2.Y) AND (pCur.Z <= p2.Z);
      ENDFUNC


    Aufruf dann entsprechend:

    Code
    if TCPInWZBox(psd_IMM_Area_Corner1, psd_IMM_Area_Corner2) then ....


    Um die Funktion etwas genereller zu gestalten, könnte/sollte man noch das Tool an die Funktion
    übergeben und entsprechend verarbeiten, ansonsten nimmt er halt immer das aktuelle Tool.


    Vielleicht bringt's dir ja was....
    gruß
    rmac

    Auch Moin,


    also habs jetzt mal selbst probiert. Du musst:
    ANIN ON Wert = 1.0 * SENSOR1
    schreiben.
    Insofern war der Tipp von atw11m92 genau richtig.... :applaus:


    Die Variablen müssen aber auch in einer Datenliste stehen,
    sonst kommt Fehler:
    "Keine in der Datenliste vereinbarte Variable"


    Ist zumindest bei mir so (KRC1 4.1)


    gruß
    rmac

    hi,


    also in meiner Doku (4.1) steht:
    "Alle in der ANIN Anweisung verwendeten Variablen müssen in Datenlisten deklariert sein"
    bei dir steh'n die aber lokal in der Routine...


    Vielleicht ist das bei der KRC2 (5.x) anders, :huh: aber probieren kannst es ja mal.
    Deklarier die mal im ".dat" und versuchs nochmal.


    gruß
    rmac

    nabend,


    also in der mir vorliegenden Doku (Ref. Guide 4.1) steht:
    [...] Eingabeparameter (d.h. IN) dürfen keine Felder sein [...]


    ...was dann auch die Fehlermeldung erklärt.


    Wenn du dich auf 3 Komponenten/Dimensionen festlegen kannst,
    pack doch deine Vektoren in einen eigenen Typ:


    STRUC TVEC REAL a,b,c


    GLOBAL DEF VEKTOR_SUB (N:IN, U:IN, V:IN, W)
    DECL TVEC U,V,W


    dann sollte auch das IN funzen.....
    Gruß
    rmac

    Hi,


    leg doch eine globale boolsche Variable an (bVELCPOutEnable oder so), die du im src umschalten kannst.
    In der sub Loop schreibst du dann:

    Code
    IF bVELCPOutEnable THEN
      $anout[1]=$vel.cp
    ENDIF


    gruß
    rmac

    Hallo,


    also laut Ref.-Doku muß
    ANOUT ON Signalname = Faktor * Regelglied
    angegeben werden, der Rest ist optional.


    Ich hab das mal testweise ohne Faktor/Regelglied ausprobiert und bekam entsprechende Fehlermeldungen.
    Faktor muß angegeben werden, kann aber eine Konstante sein, also auch 1.0,
    Regelglied muß schon was "Sinnvolleres" sein....


    Die Frage ist auch, was du damit bezwecken willst. Wie bzw. was soll denn an aoSpeedSystem
    ausgegeben werden wenn du keine entsprechende Zuweisung machst ??? :kopfkratz:


    Gruß
    rmac

    Hallo,


    wie lautet denn die Fehlermeldung ?


    In der Doku (4.1) steht z.B.:
    "Alle in der ANOUT Anweisung verwendeten Variablen müssen in Datenlisten deklariert sein."


    Vielleicht sind "rFactor" und/oder "rDelay" ja direkt im Modul deklariert (?)


    Gruß
    rmac

    Hallo PA,


    ich will ja nicht unhöflich sein, aber ich denke, dass -im Gegensatz zu einigen anderen Fragen hier im Forum-
    mein Betreff und die anschließende Frage doch (eigentlich) recht unmissverständlich formuliert war,
    zumal im KUKA-Ref.-Guide die entsprechende Deklaration auch so beschrieben ist:
    INTERRUPT DECL Prio WHEN Ereignis DO Unterprogramm
    wobei es sich (laut Doku) bei Prio um einen "Arithmetischer Ausdruck, der die Priorität der Unterbrechung
    angibt.
    " handelt.


    Im Übrigen hätte zu deiner Antwort die passende Frage "Wie deklariert man einen Interrupt?"
    lauten müssen. :???:


    Nichts für ungut, trotzdem Danke für deine Beteiligung...
    Gruß
    rmac

    Na supi, das ist mir auch klar... :kiss:


    Die Frage war eigentlich die: ich möchte statt:


    INTERRUPT DECL 10 WHEN not inBMessSens DO IR_BMess()


    lieber


    INTERRUPT DECL CBMESS_IRPT WHEN not inBMessSens DO IR_BMess()


    schreiben, um die Interrupt-Nr zentral in einer symbolischen Konstanten "unterzubringen",
    damit man die bei Änderung nur einmal im Quelltext editieren muß und nicht 50mal in 12 Dateien oder so.
    Zweifelsfrei einer der vielen Vorteile von symbolischen Konstanten..... :ylsuper:


    Das kann eigentlich jede Deppen-Programmiersprache....frage mich nur ob KRL auch dazu gehört.... :huh:


    Gruß
    rmac

    Hi KUKA-Spezies,


    kann es sein, dass man in KRL (4.1) bei:
    INTERRUPT DECL Prio ....
    für Prio nur literale numerische Ausdrücke verwenden darf, also keine symbolischen Konstanten/Variablen etc. ?


    In der Doku steht, dass für Prio ein arithmetischer Ausdruck verwendet werden darf/muß.
    Ein arithmetischer Ausdruck ist (laut KUKA Definition):
    "Ein Ausdruck ist ein Konstrukt aus Datenobjekten und Operatoren und besitzt einen eigenen
    Datentyp und Wert. Ein Ausdruck heißt arithmetisch, wenn sein Ergebnis die Datentypen INT oder REAL
    hat."
    [...]


    Bei mir kommt eine entsprechende Fehlermeldung ("Wert für PRIO nicht zulässig" oder so ähnlich) wenn ich eine symbolische Konstante (oder auch Variable) dafür verwenden will.
    Konstante ist deklariert in der Datenliste z.B. so:
    DECL CONST INT CBMESS_IRPT=10


    Habe schon alles Mögliche ausprobiert (Dekl. in $config.dat, verschiedene Schreibweisen etc.) aber ohne Erfolg.
    Hat das schonmal einer hinbekommen, oder ist die KUKA-Doku diesbzgl. einfach falsch, oder bin ich zu doof ? :wallbash:


    Thx für Aufklärung
    rmac

    Hallo ABB-Anfänger,


    das ist prinzipiell keine triviale Aufgabe.


    Muss das eine Lösung sein, die nur auf der Roboter-Steuerung laufen soll ?
    Wie/wo soll der zu schreibende Text und andere Parameter (Zeichensatz, Schriftgröße, etc.) eingegeben werden ?


    Ich habe mir mal ein kleines PC-Programm (nicht RAPID) geschrieben, das simple Konturen aus HPGL-Dateien (=Plotter) einliest
    und daraus RAPID-Verfahrbefehle erzeugt. Habe dann mit dem Roboter und einem Fräser diese Konturen aus Sperrholz gefräst.
    Die Grafiken (und natürlich auch Text) kann man dann mit einem beliebigen Grafik-Programm (z.B. CorelDraw) erzeugen, es
    muss nur HPGL-Dateien schreiben/exportieren können.
    Das war damals nur eine experimentelle Sache (also nichts was ich ruhigen Gewissens weitergeben könnte), aber vielleicht kannst
    du ja diese Idee aufgreifen.
    Der Vorteil dieser Offline/Post-Prozessor-Lösung ist, dass du mit vielen Programmen HPGL erzeugen kannst (z.B. jedes CAD wird das können) und du dir um Schriftarten/-größen/-formate keine großen Gedanken mehr machen musst.
    Damit sind dann natürlich auch abstruse Spielarten wie geschwungener, d.h. einer Kontur folgender Text usw. möglich.
    Import und Analyse von HPGL-Dateien (=ASCII=Textformat) ist relativ simpel, wenn man sich z.B. erstmal nur auf Liniensegmente
    beschränkt. Pen-Up und -Down des Plotters entspricht dann Fräser-Rauf/-Runter beim Roboter usw.
    Infos zum HPGL-Format findet man schnell im Netz...
    Ich denke man könnte den HPGL-Import auch direkt in RAPID programmieren, würde nur etwas länger dauern...


    Alternativ dazu gäbs natürlich auch die Möglichkeit das alles (Texteingabe, Parameter) nur auf der Rob-Steuerung auszuprogrammieren.
    Abhängig von den Anforderungen (unterschiedliche Zeichensätze, -formate etc.) würde ich mir aber dann an deiner Stelle in
    den nächsten Monaten nicht anderes vornehmen.... :grinser043:


    Wenn es sich nur um eine simple, nichtproportionale (=gleiche Zeichenbreite) Schriftart handelt, nur in verschiedenen Größen (skalierbar) und ohne weitere Formate (fett, kursiv etc.), z.B. zum Beschriften von Bauteilen/Werkstücken mit Serien-Nrn. oder so, dann es der Aufwand natürlich überschaubarer.
    Könnte man dann z.B. so lösen:


      • einmalig für jedes Zeichen im Zeichensatz ein Datenfeld anlegen (bzw. ein zwei-dimensionales für den ganzen Zeichensatz) und mit normierten Vektordaten (nur XY-Werte von 0 bis 1) befüllen (sollte man sich aus CAD o.ä. erzeugen lassen)

      • eine Routine schreiben, die ein beliebiges Zeichen skaliert (=gewünschte Zeichenbreite in [mm] mit normierten XY-Werten multiplizieren) und den Vektorpfad für dieses Zeichen reproduziert (inkl. Vorschub/Speed einstellen, Fräser eintauchen etc.)

      • an den Textursprung auf das Werkstück verfahren

      • den zu fräsenden Text in einzelne Zeichen zerlegen und jedes Zeichen um die Zeichenbreite verschoben (Offset/Displacement) mit der o.g. Routine fräsen lassen

      • wegfahren...fertig


    Ich hoffe das reicht als Ansatz
    Viel Spaß dabei.... :zwink:
    rmac

    Hallo Jungens,


    Wurde wohl in der KRC1-Doku nicht so explizit erklärt.



    Mit der "externen Zustimmung" "unterbrichst" du ja nur die Zustimmung die du über das KCP gibst, und die ist im Automatikbetrieb eh nicht relevant.


    Hab mir schon sowas gedacht...


    Was ist denn die beste / (idioten-)sicherste (bzw. von KUKA gedachte Lösung) zum hardwaremäßigen Absichern einer Zelle
    wenn z.B. durch eine übergeordnete Steuerung/SPS die Freigabe für Roboter-Bewegungen entzogen
    werden soll ?
    Schutzeinrichtung oder ext. Antriebe aus ?
    Nach Möglichkeit ohne anschließend manuell BOF-Meldungen bestätigen zu müssen...


    :danke: vorab
    rmac

    Hi,


    also für die S4C (und möglicherweise auch kleiner), gibt's die Software-Option "PalletWare".
    Ich weiß zwar nicht ob es sowas auch für die IRC5 gibt, vermutlich aber schon.


    Aber ich würde das (wie Robcheck01) auch selber programmieren....


    Gruß
    rmac

    Hi,


    das OfficeLite installiert einen weiteren Netzwerkadapter (Realtime OS Virtual Network) zur Kommunikation mit dem
    Echtzeit-OS.
    Möglicherweise wird das über eine Firewall oder andere Schutzmechanismen geblockt.
    Deaktiviere doch mal temporär alle Firewalls und/oder Viren-Scanner/-Guards und versuchs dann nochmal.


    Vielleicht hilfts.
    Gruß
    rmac