Posts by Programmiersklave

Naja, wenn mir ein Kunde sagt, er wolle maximal 3 Produkte auf der Anlage fahren, dann hänge ich aus Erfahrung in Gedanken stets zwei Nullen dran... ist einfacher, die Reserve vorher anzulegen.

Grüße,

Michael

Die % ermöglichen den Aufruf über einen String. Die Routine muss dafür nicht gebunden sein und kann sogar zum Zeitpunkt des Programmstarts noch fehlen.

Der String wird bei Dir unmittelbar im Aufruf erst zusammengesetzt. Eine der beiden num muss daher zweistellig sein.

Grüße,

Michael

Quote from INTERRUPT

Wenn man $ACT_TOOL und $ACT_BASE beschreibt sollten 90% Deiner Probleme gelöst sein!

Na, eher 20%. Dann steht da wohl eine Nummer drin, die an den kritischen Stellen auf irgendwas verweist, aber das kann die BAS(#...) genausogut bis besser. Mir geht es eher darum, dass die Programmierkoordinatensysteme nunmehr scheinbar völlig unabhängig vom tatsächlichen $TOOL und $BASE sind. Wenn ich ein Ding habe wie:

$BASE=FRAME1:FRAME2:FRAME3:NOCHEINFRAME
LIN messpunkt
$BASE=GANZANDERERFRAME:NOCHEINFRAME
LIN anderer_punkt

und ich dann bei "messpunkt" einen TouchUp ausführe, dann bezieht sich der auf sonstwas statt auf das aktuelle $BASE. Das kannte ich so bisher nicht und ist m. E. irgendwie stressiger als das alte Verhalten, wo im schlimmsten Falle der Vorlaufzeiger weiter war und schon die Einstellungen für "anderer_punkt" aktiviert worden waren.

Oder kann man das irgendwo umschalten?

Grüße,

Michael

Ist ja auf dem Robbi auch nicht viel besser. Früher konnte man sich (mit ExpertTech) drauf verlassen, dass mit einer $BASE- oder $TOOL-Zuweisung auch das Programmierkoordinatensystem geändert wurde, sei es auch im Vorlauf, was angelegentlich zur Verwirrung führte. Heute hat die $BASE- und $TOOL-Zuweisung nur noch Einfluss auf das Programm, beim Teachen werden hingegen die eingestellten Grund-Koordinatensysteme genommen, die in der Statusleiste des KCP angezeigt werden. Wenn man glaubt, mal eben auf Touch-up drücken zu können, wird man baß enttäuscht sein von dem Ergebnis. Man muss sich also immer erst z. B. das aktuelle $BASE in BASE_DATA[irgendwas] schreiben, und dann mit BAS(#BASE,irgendwas) die Sache wieder zurückholen, um ins Reine zu kommen.

Und die Inlineformulare lassen sich davon erst gar nicht beeindrucken, die nehmen immer stur das zuletzt verwendete. Wohlgemerkt, was wieder nichts mit dem aktuellen Programmierkoordinatensystem in der Statusleiste zu tun hat. Wenn beides nicht gleich ist, hat man ebenfalls ein Problem.

Wie oft ich jetzt schon Punkte vergebens geteacht habe, weil ich da in alter Manier nicht drauf geachtet habe....

Vielleicht hab' ich auch einfach nicht kapiert, was die eigentliche Idee dahinter sein sollte.

Grüße,

Michael

So, Auflösung war: eine XML fehlte. Entweder nachtragen oder besser: Version auf KSS 8.6.6 hochziehen. Jetzt scheint's zu gehen.

Grüße,

Michael

Quote from SJX

Da habe ich Deinen KR30R2100 nicht gefunden.

Wer hat Dir das Ganze verkauft?

Unser lokaler, offizieller KUKA-Vertreter..... das wäre mal wieder der worst case.

Danke erstmal für Eure Antworten, im Moment ist der Customer-Service damit beschäftigt.

Grüße,

Michael

Situation: neuer KR30R2100, KRC4 mit KSS 8.6.5, absolutgenau.

Option PathMode 1.0.0 Build 19 installiert, auf dem Programmierrechner aktuelles WoV 6.0.12, dort natürlich PathMode auch im Optionspaket (entnommen vom KOP auf D:).

Bei Erzeugen des Projektes wird die Option mit Installiert (bzw. eben auch deinstalliert, wenn man sie im Projekt entfernt, was ebenfalls getestet wurde.) Bei hinzugefügtem PathMode jedenfalls wird zum Schluss in der Steu/Mada/$OPTION.DAT die Variable

INSTALLED_MOTION_MODES $INSTALLED_MOTION_MODES={PATH FALSE,DYNAMIC FALSE}

bei PATH auf TRUE gesetzt, was wohl das gewünschte Verhalten sein soll, allerdings quittiert der Rest des Systems das mit 01541 "Maschinendaten nicht korrekt" und vorher 00184 "Motion-Mode Path wird nicht unterstützt".

Wenn ich die Variable händisch auf FALSE setze, wird der Roboter benutzbar, aber natürlich ohne die Option. Die Registry enthält den bei der Installation erzeugten Key und verweist auf die durchaus vorhandene "C:\\KRC_Option\\PathMode\\KrcTech.dll".

Wie kann ich das System überzeugen, mir den Motion-Mode zur Verfügung zu stellen?

Grüße,

Michael

Hm, dann kA. Was wohl auch noch wichtig sei, fällt mir gerade ein: die sicheren Signale müssen im EA-Konfigurator NACH den "normalen" auftauchen. Man kann sich das vertüddeln, so dass die drüber liegen, dann geht es wohl auch nicht.

Grüße,

Michael

Hab mich da auch neulich mal einen Tag lang mit gequält. Es ging nicht in RobotStudio 2020. Mit der 2019.5.3 ging es dann problemlos, weiß der Geier. Musst natürlich auch die Rechte haben, d. h. Sicherheitsinbetriebnehmer-Account anlegen, einloggen etc.

Grüße,

Michael

Quote

zielhöhe=30

while i[4] <(zielhoehe)

Sicher? ö!=oe

Quote from Langebua

Ok das ist definitiv zu Hoch für mich & meine ABB Kenntnisse ..

Muss das alles ins Main ? Kannst du das noch bisschen mehr erklären für abb neulinge ? ..

Nee, eben nicht ins Main.

Du schreibst Dir in irgendein Modul (welches immer im Speicher bleibt natürlich, kein nachgeladenes) eine PROC. In die kommt das aus dem zweiten Block meines Zitates. (Module kannst Du bei ABB kreuz und quer anlegen, und alle Variablen und Procs/Funcs sind taskweit erreichbar, ausser Du schreibst explizit LOCAL davor. Kannst Dir also beliebige Bibliotheken stricken und meinetwegen für dieses Ding hier ein eigenes Modul machen.)

Und außerhalb der Proc, in den Deklarationsteil dieses Moduls, das Zeug aus dem ersten Codeblock. (Es sei denn, Deine Home-Position als Joint ist schon woanders definiert, natürlich. Falls Du als Home ein Robtarget hast, dann setze den AxJoint in der Homefahrroutine direkt dahinter und teache ihn auf dieselbe Stelle.)

So, jetzt musst Du nur noch denAusgang haben, den konfigurierst Du im RobotStudio (Konfiguration - I/O-System-Signale) und setzt ihn am besten noch auf "access-level ReadOnly", damit Du nicht mogeln kannst.

Zusätzlich kommt jetzt noch unter "Konfiguration - Controller - EventRoutine" ein Eintrag hinzu:

Event: PowerOn

Routine: der Name Deiner Routine wie eben besprochen (exakt wie benannt, ohne sonstwas drumrum, ohne Klammern)

Task: die Robotertask

Alles andere nö/0/wie gewünscht.

Dann wird diese eine Routine einmal nach dem Einschalten gestartet, definiert eine Achsstellung mit etwas Toleranz "drumherum" (wie angegeben bei mir in deltaHJoint) und setzt immer und unweigerlich den Ausgang, wenn innerhalb dieses Bereiches.

Neustart nicht vergessen, fertsch.

Was Eingebautes wie bei KUKA gibts nicht so richtig.

Ich mach's so:

- folgende Daten zur Verfügung stellen (AxJoint-Home, achsweise Max-Abweichung, stationäre Weltzone,ein Shapedata, wobei die Shapedata lokal sein darf) und natürlich den Ausgang konfigurieren, hier dov_R1_Home

    CONST jointtarget HomeJoint:=[[2.98903,-28.9556,-17.7245,0,0,182.78],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];
    VAR jointtarget CONF_DeltaHJoint:=[[0.2,0.2,0.2,.2,0.2,0.2],[9E9,9E9,9E9,9E9,9E9,9E9]];
    VAR wzstationary CONF_HomeZone;
    VAR shapedata VolumeHome;

- eine Routine bauen, die als Ereignisroutine mit PowerOn verbunden ist.

- und in jener die achsweise stationäre Weltzone aktivieren:

        WZHomeJointDef\Inside,VolumeHome,HomeJoint,CONF_DeltaHJoint;
        WZDOSet\Stat,CONF_HomeZone\Inside,VolumeHome,dov_R1_Home,1;

Nach dem Umteachen braucht es dann einen Neustart, um die Zone wieder "richtig" zu setzen. Die Abweichungen musst Du natürlich selber kennen (oben: 0.2 Grad in allen Achsen). Ist aber dann zuverlässig AUSSER die Ereignisroutine wurde beim Neustart der Anlage wegen eines Syntaxfehlers irgendwo (irgendwo anders!) nicht gestartet. Deshalb aufpassen bei der Logik: wenn der Ausgang an ist, ist er bestimmt in der HOME-Position. Wenn er NICHT an ist, heisst das aber nicht, dass er nicht DOCH in der Home-Stellung sein könnte!

Grüße,

Michael

Mit Interrupt über CRobT wäre auch eine Möglichkeit. CRobT kann sogar aus einer anderen Task heraus arbeiten, so dass man diese Arbeit auch auslagern könnte - Bewegungstask fährt, und Hintergrundtask reagiert auf Ereignisse und speichert die Positionen.

Grüße,

Michael

Zu bedenken ist auch: Offline-Programmierung ist nicht komplett dasselbe wie Simulation, und man sollte den Einsatzzweck im Blick haben. Für manche Applikationen ist eine nuancierte, vielseitige und anschauliche Manipulation der Bahn wichtig, andere brauchen vielleicht eine eher parametrische Automatisierung bei der Bahnmanipulation, und wieder andere wollen eine naturgetreue Simulation mit 100% passender Taktzeitbetrachtung, Kollisionsschutz, E/A-Simulation und was nicht alles.

Bin durch meine 19jährige Zugehörigkeit zum FAMOS-Universum natürlich vorbelastet, weiß dadurch aber auch, dass so eine Software nicht alles können kann und sollte.

Grüße,

Michael

Well - maybe I'm confusing something, don't memorize details...

I remember a point in the past (in the KRC4 early days) when something was changed in the way how to pass arrays in KRL. That was the moment when these kind of routines didn't work anymore (which did well in KRC2) and I had to rewrite it.

Michael

Quote from Hermann

Why hassling about those functions when the whole thing can be done in one line?

I agree, of course.

It was just a remark in case it's needed, these kind of functions appear in many programs since 20 years or more, and I use them for my own projects up to now.

Michael

For your functions: depending on KUKAs system software it's not possible to pass arrays as OUT-parameters anymore since a decade or so (KRC4), but this should be indicated by an error message. If so, you might redesign the code by using own structures like

GLOBAL STRUC VEC3 REAL e1,REAL e2,REAL e3
GLOBAL STRUC MATR VEC3 x,VEC3 y,VEC3 z

these can be used as OUT anyway:

DEF  RPY_TO_MAT (T :OUT,A :IN,B :IN,C :IN )

DECL MATR T
REAL A,B,C
....

Michael

Quote from Hermann

Why do you think it should be 1?

It can, and should be more than 1.

Because (well, that's my impression of this, as said before, I really don't get the point) he's calculating, changing a TOOL AND also driving one point and doing this point by point inside of a loop for each single target. So all calculations and settings better affects as less as possible. Outside of the loop bounds he should switch back to default.

Preparatory calculations in and around loops might be confusing as soon as you stop and restart.

Michael

I don't get the point of your code, because the loops are senseless so far, you never use the counter in any way. That means, the robot will stop simply because the PTP_REL leads repeatedly to the same position, depending on how big N_Punkte is.

Anyway, the tool assignment should be okay with just $TOOL=... and no load interference. $ADVANCE, of course, should be 1.

Michael

basically $TOOL = TOOL_DATA[5] sets the toolframe to TOOL_DATA[5], that's normally all you need.

BAS(#TOOL,5) does the same, but also checks limits and overwrites the loaddata, and so on...

If you just want to modify the geometry then a bare "$TOOL = TOOL_DATA[5]" should work without stops.

Michael