Kuka KRC4 richtiger Programmablauf nur in Einzelschritt möglich

Moin,

ich bin gerade dabei während ich in der Firma bin eine alte Messeanlage neu zu Programmieren (KRC4 compact 8.3.29) bei dem Programm werden Stifte zwischen verschiedenen Nestern hin und her Sortiert. In der Variable i[1-30] wird gespeichert ob ein Stift vorhanden ist. Die einzelnen Nester werden weiter oben (außerhalb des Ausschnittes) abgefahren und bereits Vorsortiert (i[1-30] ist resettet und wieder gefüllt worden) für das gesamte Sortieren werden alte Programmteile wieder verwendet, im Einzelschritt (also Zeile für Zeile) funktioniert das ganze auch zuverlässig, in den beiden anderen Durchlaufarten des Teach-Betriebes (also Normal mit GO oder mit Stopp nach der nächsten Bewegung) aber nicht, keine Ahnung warum... ich habe bereits versucht in den Schleifen Wartezeiten zu verbauen (0,05s), leider ohne Veränderung. Ist euch sowas schonmal passiert? Hab ich irgendeinen Fehler in meinem Programm der sowas verursachen könnte?

;Check ob umsortiert werden muss

FOR fach = 1 to 20

hilf1 = fach-10

;Greifer öffnen

IF di_b_greifer_zu AND NOT di_b_greifer_offen THEN

    do_b_Greifer_schliessen = FALSE

    do_b_Greifer_oeffnen = TRUE

ENDIF

;Check ob umsortiert werden muss

IF i[fach] == 0 THEN

Diese If-Bedingung funktioniert im Einzelschritt, im normalen durchlauf ist sie immer falsch

    i[fach] = 1

    fachz = 20

    fachs = 0

;z Fächer zurück legen

WHILE fachs == 0

IF i[fachz] == 1 THEN

        fachs = fachz

ELSE

        fachz = fachz-1

ENDIF

ENDWHILE

IF hilf1 == fachs THEN

;

ELSE

      BASE_DATA[30] = BASE_DATA[1]

      i[fachs] = 0

      fachs = fachs-10

WHILE fachs > 1

        BASE_DATA[30] = BASE_DATA[30]:{x 0, y 45, z 0, a 0, b 0, c 0}

        fachs = fachs -1

ENDWHILE

;Aufnahmepunkte (fachs), Vorpunkt, Aufnahmepunkt

;FOLD LIN P105 Vel=2 m/s CPDAT13 Tool[1]:STIFTGREIFER Base[30];%{PE}%R 8.3.43,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P105, 3:, 5:2, 7:CPDAT13

;FOLD LIN P104 Vel=2 m/s CPDAT12 Tool[1]:STIFTGREIFER Base[30];%{PE}%R 8.3.43,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P104, 3:, 5:2, 7:CPDAT12

;Greifer schliessen

      do_b_Greifer_oeffnen = FALSE

      do_b_Greifer_schliessen = TRUE

WAIT FOR di_b_greifer_zu AND NOT di_b_greifer_offen

;Ausheben des Stifts

;FOLD LIN P105 Vel=2 m/s CPDAT13 Tool[1]:STIFTGREIFER Base[30];%{PE}%R 8.3.43,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P105, 3:, 5:2, 7:CPDAT13

ENDIF

;FOLD PTP HOME Vel= 50 % DEFAULT;%{PE}%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:HOME, 3:, 5:100, 7:DEFAULT

;Ablage Nest4

;IF fach>11 THEN

;Ablageframe

    BASE_DATA[30] = BASE_DATA[4]

WHILE hilf1 > 0

      BASE_DATA[30] = BASE_DATA[30]:{x 0, y 45, z 0, a 0, b 0, c 0}

      hilf1 = hilf1 -1

ENDWHILE

;Anfahrt ablagepunkt (fach)

;FOLD LIN P0 Vel=2 m/s CPDAT0 Tool[1]:STIFTGREIFER Base[30];%{PE}%R 8.3.43,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P0, 3:, 5:2, 7:CPDAT0

;

;Ablagepunkt

;FOLD LIN P4 Vel=2 m/s CPDAT6 Tool[1]:STIFTGREIFER Base[30];%{PE}%R 8.3.43,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P6, 3:, 5:2, 7:CPDAT6

;

;Greifer öffnen

    do_b_Greifer_schliessen = FALSE

    do_b_Greifer_oeffnen = TRUE

WAIT FOR NOT di_b_greifer_zu AND di_b_greifer_offen

;

;Greifer freifahren

;FOLD LIN P5 Vel=2 m/s CPDAT7 Tool[1]:STIFTGREIFER Base[30];%{PE}%R 8.3.43,%MKUKATPBASIS,%CMOVE,%VLIN,%P 1:LIN, 2:P5, 3:, 5:2, 7:CPDAT7

;ENDIF

;FOLD PTP HOME Vel= 50 % DEFAULT;%{PE}%MKUKATPBASIS,%CMOVE,%VPTP,%P 1:PTP, 2:HOME, 3:, 5:100, 7:DEFAULT

ENDIF

ENDFOR

Achso was ich noch dazu sagen sollte i[1-30] wird bisher nur von 1-20 genutzt und ist global, die anderen Variablen (fach, fachs, fachz, hilf1, hilf2, hilf3 (nicht alle verwendet) sind lokal definiert.

Danke im Voraus, falls ich es selbst noch rausfinden sollte melde ich mich hier nochmal

Zitat von elchi2018

Also ich kann der Logik im Code nicht ganz folgen. Können andere hier im Forum eventuell besser. Du verschleifst ziemlich viel und ich meine, dass auch gewisse Anweisungen fehlen und Verschleifungen nicht eindeutig beendet sind.

Für Deinen Fall würde ich erstmal die nötigen Bewegungsabläufe definieren, was soll er wohin tun und dann die übergeordnete Logik aufbauen und aus dieser heraus die einzelnen Schritte, sprich DEF's aufrufen.

Aber, KRL ist offen .. darf jeder, wie er will .. fast

das mit den vielen schleifen ist nur damit der Code modular anwendbar auf 3 Nester ist (die Speicher Variable ob ein Stift vorhanden ist wird als einziges getauscht bzw. der Bereich im Array eigentlich sogar nur (i[1-10] -> Nest 1; i[11-20] -> Nest 2; i[21-30] -> Nest 3). Die schleifen funktionieren, die sind nämlich alle Copy and Paste von dem Sortieren der einzelnen Nester 1 & 2, nur sollen hier halt Nest 1 und Nest 2 zusammen bearbeiten werden (zu Beginn sind die Stifte unsortiert in Nest 1 und Nest 2 gelegt, diese werden dann so sortiert, dass sie jeweils von i[1](Nest 1) bzw. i[11](Nest 2) aufwärts ohne Lücke liegen. Der Teil vom Code, der jetzt ignoriert wird sobald man keinen Einzelschritt fährt, ist nur für das Lückenfüllen gedacht wenn man Nest 1 & 2 zusammen Betrachtet (es werden also die restlichen Lücken in i[1-20] gefüllt.

ich hoffe damit wird die Funktion klarer.

Zitat von Martl

Was mir aufgefallen ist:

1. Greifer öffnen ganz oben => da wird die Greiferstellung nach dem Öffnen nicht mehr abgefragt

2. Grundsätzlich würde ich für jedes Nest eine eigene Zähl-Variable nehmen

3. alles in einem Base (Base [30]) zu fahren wird zu Vorlaufstops führen

4. Greifer lösen/spannen zur Übersichtlichkeit in Unterprogramme packen.

5. Unterschiedliche Nester? Ich sehe nur zwei Unterschiedliche Bases (1 und 4) die dann in Base 30 geschrieben werden (und dort wird bei manchen Variablenzuständen in Y 45 draufgerechnet)

6. Anfahrbewegungen beim Abholen/Ablegen evtl. nur als Offsetpositionen anfahren oder vorher berechnen

z.B.: xP0 = xP4

xP0.z = xP0.z + 50 ;=> P0 wäre dann um 50 mm in Z höher als P4

7. Variablennamen sinnvoll deklarieren => iZaehler_Nest_1, iLagenzaehler ect. => du hast 24 Zeichen zur Deklaration.

Gruss

Martl

Alles anzeigen

Also dann nehme ich mal Bezug auf deine Punkte
1. ist mir bewusst habe ich zwischenzeitlich wieder vergessen gehabt... (ändere ich besser mal direkt)

2. ich wollte extra eine Variable für alle nehmen, da das im nachhinein Vorteile für andere Unterprogramme bringt, funktioniert ja im einzelschritt auch

3. ist bzw. war mir nicht bewusst bei Kawasaki hab ich damit keine Probleme, da Shifte ich immer nur Lokal erstellte Punkt Variablen um z.B. int*x (wird natürlich anders geschrieben) Infos über eine Solche Funktion konnte mir keiner geben... (der Punkt soll nicht direkt angefahren, sondern erst berechnet werden)

4. ja könnt ich machen, mache ich dann jetzt vllt. direkt mit 1. zusammen

5. ja base1 / base4 sind die beiden äußeren Nester (einmal links und einmal rechts neben dem Robi, vor dem Robi ist noch ein drittes Nest, welches an zwei Positionen stehen kann (einfache Lineareinheit) welches dann entweder Base2 (linke Endlage) oder Base3 (rechte Endlage) ist.

6. die Anfahrpositionen werden ja gewissermaßen über die Base-Verschiebung berechnet, wie bereits gesagt habe ich keinerlei Infos darüber bekommen ob man Punkte berechnen kann, daher habe ich die Base berechnet (darüber waren Infos zu finden) einen Programmierkurs für Kuka hat bei mir in der Firma leider keiner, weshalb mir auch keiner so wirklich weiterhelfen kann... (ich selbst habe nur einen Kawasaki Kurs, der Rest ist in Eigenarbeit und mit Hilfe von alten Programmen entstanden)

7. ist mir bewusst, allerdings bin ich Schreibfaul und als Zählvariable gibt es nur i (integer), b & p (bool) und jetzt gibt es auch nur noch eine variable die gespeichert werden muss (früher gab es Bleistifte oder Kulis, jetzt nur noch Kulis)

Zitat von SJX

Würde auf Vorlauf-Thematik hindeuten.

Im Einzelschritt gibt's kein Vorlauf.

Mal die ganze FOR-Schleife einfach mal getestet mit $ADVANCE=0 anstatt 3 ?

Danke, den Vorlauf hatte ich auch als Verdacht, kenne es aber nur von Kawasaki mit dem BREAK Befehl, dann wartet der Vorlauf auf den Ablauf, diese Funktion habe ich bei Kuka aber nirgends gefunden... der Steht sicherlich in der Config, oder? Ich gehe dann mal auf die Suche wo das Steht, wenn es funktioniert gebe ich nochmal Rückmeldung

MfG

Jo, ich hab's schon gefunden falls es noch wer sucht: bei mir ist es in System/bas.src (Zeile 80), da wird es allerdings über eine Variable gesetzt.

in System/config.dat wird in Zeile 14 die Variable INT DEF_ADVANCE=3 Initialisiert und dort kann man dann den Vorlauf einstellen

Zitat von Hermann

Ist egal wo der steht. Kann man einfach im Programm zuweisen:

Code

$advance=0

Oder meinst du damit es wäre sinniger das ganze nur für den nicht Funktionierenden Programmteil auf 0 setzen (also unten auf =0 setzen und oben im Main Programm (nach dem Programmablauf springt er dorthin zurück) wieder auf 3 setzen

Also, ADVANCE für den Problemteil =0 zu setzen hat nichts geändert... also zurück auf Anfang -.-

Zitat von Martl

"FOR fach = 1 to 20" => du hast doch 30 Plätze (Nest 3)

müsste doch

"FOR fach = 1 to 30" => oder?

und in der IF-Schleife

    fachz = 20 => 30 oder?

Alles anzeigen

zu diesem Zeitpunkt werden nur 2 Nester á 10 Stifte sortiert deshalb ist fachz=20 insgesamt gibt es aber 3 Nester á 10 Stiften, das dritte Nest ist aber erstmal außen vor.

Ich den Fehler gefunden... ich fühl mich gerade so dumm ich habe nach der Prüfung ob das Jeweilige Fach leer ist bereits reingeschrieben, dass es nicht mehr leer ist, im ersten durchlauf funktioniert das ganze trotzdem nur halt im zweiten nicht mehr weil dann logischer weise auch die leeren Fächer als voll gespeichert sind... im Einzelschritt hat es nur dank meiner Faulheit funktioniert (ich hab die Überprüfung ob umsortiert werden muss übersprungen...) danke für eure Hilfe, den $ADVANCE Befehl werd ich mir mal sicherheitshalber merken, das kann nicht schaden zu wissen.

zusätzlich geändert ist jetzt, dass der Greifer nach der Ansteuerung über Unter Programme immer abgefragt wird und die Variable heißt nicht mehr i[] (hätte in Anbetracht des gefundenen Fehlers ja vermutlich auch funktioniert) sondern pen[]