Beiträge von RJust

Jedem EX Submit ist ja ein *.sub Modul zugewiesen. Ein "Abwählen" schmeißt ja nicht das Modul raus. Bei den Submits wird es ja "Zuweisen" genannt.

Also Idee war es, dass man im EX1 verschiedene Module nutzen kann.

Danke!

Und starten wäre dann folgendes?

CWRITE($CMD,STAT,MODE, "START 3")

WAIT FOR ($PROG_INFO[3].P_STATE == #P_ACTIVE)

"3" ist dabei anscheinend der EX1.

Aber wie kann ich ein anderes Modul dem EX1 Submit zuweisen?

Hey zusammen,

kurz vorweg: KRC5, SYS Submit -> sps.sub, EX Submit --> einer der 7 Multisubmits

Lässt sich aus dem SYS Submit ein EX Submit starten? Wenn ja, wie?

Wie lässt sich kontrollieren, ob ein bestimmter EX Submit (EX1-EX7) abgewählt ist (ähnlich zu dem Befehl $PRO_STATE1 <> #P_FREE) oder läuft?

Wie lassen sich einzelne EX Submits stoppen/abwählen?

Mir würden die 7 EX Submits theoretisch locker reichen, jedoch würde es in meinem Fall die Programmstruktur aufräumen, wenn dies möglich wäre.

Gruß

Hallo zusammen,

ich habe ein wenig Ungewissheit und habe ein paar Fragen:

Masse und Schwerpunkt sind klar {M, CM {X,Y,Z}}.

Das Bezugssystem in Inventor entspricht dem Werkzeugflanschkoordinatensystem, welches wiederum exakt dem Flanschkoordinatensystem des Roboters entspricht.

1. Ist das korrekt, dass wenn ich die Trägheitsmomente im Schwerpunkt (Ixx, Iyy, Izz) für {J {X,Y,Z}} verwende, die Orientierung {CM {A,B,C}} nicht mehr beachten muss?

2. Wenn die Hauptträgheitsmomente I1, I2 und I3 verwendet werden, muss dann die Drehung Rx, Ry und Rz beachtet werden?

3. Wie wäre im Fall 2 die Zuordnung?

LOAD_DATA.J.X=I1
LOAD_DATA.J.Y=I2
LOAD_DATA.J.Z=I3
LOAD_DATA.CM.A=Rz
LOAD_DATA.CM.B=Ry
LOAD_DATA.CM.C=Rx

An die Umrechnung von kg*mm² in kg*m² (*10^-6) muss natürlich auch noch gedacht werden.

Über eine Antwort würde ich mich sehr freuen.

RJ

Klingt erstmal ganz einfach. Gibt es irgendwelche Sachen, die beachtet werden müssen oder irgendwelche Nachteile? Was ist zum Beispiel mit den ganzen Maschinendaten (R1 und STEU MADAs). Zeitlich liegt doch etwas zwischen den Steuerungen und die Versionen werden sich unterscheiden.

Zitat von woodys

Ich habe keine ahnung ob ich alles so verstanden habe.....

zum einen solltest du wissen dass eine Kss 8.3 einen neuen Pc benötigt zum upgrade...

Die KRC5 braucht auch ne komplett andere Konfiguration weil auch ne andere Hardware verbaut ist.....

oder stehe ich jetzt auf dem schlauch?

Alles anzeigen

Dass ich das Ganze für die KR C5 neu aufsetzen muss ist mir bewusst. Mir ist wichtig, dass die Vorgehensweise, für dich ich mich entscheide, auch bei der KR C5 anwendbar ist. In der Doku zu "WES7 System Preparation" stand beispielsweise nur "Für KUKA System Software 8.3". Das gleiche für die folgenden Versionen habe ich nicht finden können.

Hallo zusammen,

es wurde bestimmt schon einige male angesprochen aber ich habe leider nicht genug Informationen finden können bzw. habe nicht die richtigen Stichworte parat gehabt.

Ich plane eine Serienfertigung von Robotern. Da die Installationen der Roboter zeitlich etwas auseinander liegen, ist es notwendig, dass die Methode auch mit leicht veränderten Versionsständen funktioniert. Nachdem ich hier ein paar Sachen gelesen habe, sollte man die letzteren 2 Möglichkeiten in dem Fall vermeiden.

Jetzt: KR C4 compact, V8.3.404/KUKA8.5, WV 6.0.9

Zukünftig: KR C5 micro

Alle Möglichkeiten die ich hier aufliste sind Ideen oder habe ich im Forum aufgeschnappt. Ich habe noch nichts selber getestet.

1) Alles via Archivwiderherstellung. Wahrscheinlich bekommt man aber nicht alles widerhergestellt und muss ein paar manuelle Anpassungen vornehmen.

2) "Projekte zusammenführen" in WV. Sieht erstmal ganz gut und umfangreich aus, aber was im Hintergrund genau passiert, ist mir irgendwie unklar und könnte meiner Meinung nach zu Problemen führen.

3) "Master-Image" erstellen, dazu hatte ich mir die Doku "WES7 System Preparation" angeguckt. Sieht vielversprechend aus, aber ich habe keine Erfahrungen gefunden und habe nicht herausgefunden, ob das alles bei abweichenden Versionsständen (und später auch bei der KR C5) funktioniert. Weil das Vorgehen ein Aufsetzten des Systems erfordert, wär es schlecht, wenn dieses "Master-Image" im laufe der Zeit mehrfach generiert werden muss.

4) manuelle Vorgehensweise, Teile in WV ggf. mit "Datei/Import / Export" wiederherstellen

5) einfach fertiges WV Projekt übertragen

6) Image vom fertigen System auf das Neue aufspielen

Der zeitliche Aufwand der Vorbereitung und auch der Installation spielt eine untergeordnete Rolle. Die Installation sollte jedoch einfach und dadurch fehlerunanfällig sein.

Welchen Weg würdet ihr gehen? Vielleicht eine Kombination? Oder ganz anders? Über ein paar Hinweise würde ich mich freuen.

RJ

Zitat von Hermann

Nach Möglichkeit die Rückzugsroutine auch im entsprechenden Programmfile unterbringen, dann brauchts keine globalen Punkte.

Also im Hauptprogramm beim Rückzug schauen in welchem UP man steckt, und die dort untergebrachte, als global deklarierte Rückzugsroutine für diesen Ablauf aufrufen.

Ok, unabhängig davon: Wie nutzt du oft wiederverwendete Position mit ExpertTech?

Einfach die PTPs/LINs mit den Koordinaten kopieren?

Die Gefahr, einen Punkt beim Ändern der Koordinaten zu vergessen, ist relativ groß.

Oder Punkt via ExpertTech teachen, manuell neue POS z.B. in config.dat deklarieren und die Positionsdaten des zuvor erstellten Punktes in die config.dat kopieren? Danach dann die Koordinaten bei der Bewegung durch den Punktnamen ersetzen?

So würde man beim "nachteachen" zwar keinen Punkt vergessen, jedoch ist das nachteachen nicht durch ein "Touch-Up" durchführbar, oder?

Lässt sich zufällig der Name des aktuellen Punktes auslesen? Dann könnte man via submit und und irgendeinem Input die POS_ACT in den aktuellen Punkt schreiben. Also quasi teachen.

Moin Hermann,

vielen Dank für deine Aussage! Genau das sind meine Gedanken gewesen, deshalb habe ich auch ExpertTech installiert. Aber mir fehlt irgendwie noch eine komfortable Möglichkeit, die mit ExpertTech geteachten Punkte global Verfügbar zu machen und wiederzuverwenden. Z.B. für Rückzugsstrategien oder einfach weitere Anlagen.

Wie handhabst du das?

Hey der_max89 , danke für die schnelle Rückmeldung!

Dann hatte ich das tatsächlich zunächst anders vor Augen.

Also du hast quasi eine Datenbank mit ILF erstellten Bewegungen (src)/globalen Punkten (public dat), jedoch ohne Logiken via SPS.

Die eigentlichen Programme für EXT nutzen dann die globalen Punkte und auch die nötigen Logiken, alles mit Expertenbefehlen.

Also wäre der Workflow beim Punkt zur Bewegung im eigentlichen Programm hinzufügen:

Du gehst in die "Datenbank" an die passende Stelle, fügst ein ILF Befehl ein, gehst in die dat um "global" in die DECL zu schreiben. Dann in das eigentliche Programm und den Punkt manuell einfügen?

Ich finde den Ansatz ehrlich gut, aber für meine Anwendung passt es glaube nicht so. Werde es mir aber merken!

Was man natürlich korrekt und umprogrammiert übernehmen muss, sind die ganzen restlichen Bewegungsparameter wie Beschl., Geschw., Überschleifen usw. Oder nutzt du die FDAT und PDAT Daten?

Da fällt mir gerade auf, dass man diese ja auch global machen könnte und dann für die eigentlichen Programme in Form von z.B. BAS(#TOOL,FP1.TOOL_NO) nutzen könnte. Sofern die gleichbleibend sind, könnte man die Parameter von markanten Punkten (hier XP1) in das EXT Programm übernehmen.

Wie sieht das bei dir aus?

Habe gerade das Thema hier gefunden und hatte mir ein paar Fragen gestellt.

Wie würde in dem Falle einer Public .dat mit allen benötigten Punkten (global) tun Beispiel ein teachvorgang aussehen? Also man fährt ein Programm in T1 ab und möchte jetzt ein Punkt neu teachen.

Bzw. zunächst die Frage, wie erstellst du überhaupt die Bewegungsprofile in einem Programm? ILF oder manuell in KRL? Und wie fügt man im Feld einen Punkt zur .dat hinzu?

Ich arbeite im Moment mit KUKA.ExpertTech und mache alles drumherum in Work Visual. Funktioniert, flutscht aber nicht so geschmeidig.

Deshalb würde ich mich über ne Antwort zu dem Workflow mit so einer beschrieben .dat POS Sammlung freuen.

Gruß

Die CYCFLAGs werden im IPO-Takt (12ms) aktualisiert. Somit hätte ich durch ein CYCFLAG (wenn ich es richtig sehe) eine Verzögerung von bis zu 12ms im Gegensatz zur Verwendung eines $INs. Somit versuche ich es erst hiermit:

INTERRUPT DECL 15 WHEN $IN[10+Bereich] DO stop()

Es sei denn es gibt noch eine Andere Idee eurerseits.

Gruß

Danke für den Hinweis. Hatte ich ganz vergessen.

Gibt es eine zugehörige Doku? Suche hautsächlich die Aktualisierungsrate dieser Flags bzw. mit welchem .sub bzw. Interpreter diese aktualisiert werden. Könnte das KO Kriterium sein.

Hallo,

der Roboter soll, je nach Position, durch ein anderes Signal interruptet werden (immer das gleiche Programm). Meine erste Idee war:

config:
SIGNAL Interruptsensor[1] $IN[11]
SIGNAL Interruptsensor[2] $IN[12]
SIGNAL Bereich $IN[1] TO $IN[8]

im Programm:
INTERRUPT DECL 15 WHEN Interruptsensor[Bereich] DO stop()

So lassen sich die Signale aber leider nicht definieren.

Zweite Idee war nur das benötigte Signal zu "vereinbaren":

SWITCH Bereich
   CASE 1
      GLOBAL SIGNAL Interruptsensor $IN[11]
   CASE 2 
      GLOBAL SIGNAL Interruptsensor $IN[12]
   DEFAULT
      GLOBAL SIGNAL Interruptsensor FALSE
ENDSWITCH

Jedoch schließen sich die Orte, an denen man SIGNAL-Vereinbarungen und Switch/Cases nutzen kann ja aus, korrekt?

Und ein Switch/Case mit den Interrupts selbst zu programmieren funktioniert genauso wenig.

Das einzige was funktionieren könnte ist die erste Idee jedoch ohne Signalzuweisung:

INTERRUPT DECL 15 WHEN $IN[10+Bereich] DO stop()

Habt ihr eine andere Idee?

Gruß

Zitat von Roland Keller

Sehr wahrscheinlich in der Config.dat

Das hatte ich eben erhofft. Also dass sich die Gruppierung im Signaleditor und im Verschaltungseditor automatisch irgendwo in einer config/.dat niederschlägt.

Zitat von ottosieben

Moin.

Ich glaube , Du vermischt da was.

Die E/A Verschaltung ist die "Hardware". Die Signaldeklaration beschreibt Variablen für den Zugriff auf die E/A Verschaltung.

Hatte schon im Kopf, dass das zwei Paar unterschiedliche Dinge sind, aber s.o.

Gruß

edit: Die Gruppierung im Signaleditor hat natürlich noch andere Auswirkungen (+/-/ohne VZ)

Hallo Zusammen,

wenn man PROFINET I/Os via Signaleditor gruppiert entstehen beim verschalten mit den KRC I/Os via Verschaltungseditor ebenfalls Gruppen (z. B. $IN[1]#G).

Fange ich erstmal mit den Fragen an:

Lässt sich das z.B. Byte $IN[1]#G nutzen? Oder ist das $IN[1] dann automatisch ein Byte?

Lässt sich die Gruppierung irgendwo finden (Stichwort SIGNAL test_in_byte $IN[1] TO $IN[8])?

WV 6.0

KSS 8.5

Gruß

Zitat von fubini

Ich geh jetzt mal davon aus mit "was ist" meinst du worauf der Prozentwert sich bezieht:

Re: Geschwindigkeit der externen Achse vorgeben

Kenn jetzt noch jede Dokuversion auswendig aber bei $ACC_AXIS ist es definitiv ein Dokufehler. Entweder es muss $ACC heißen oder $ACC_AXIS[1]=const. Was verrät vielleicht der Kontext.

Ne, ich meinte, was der Ausdruck $VEL PUNKT AXIS[4]=10 genau darstellt. Aber anscheinend bin ich in 2 Dokufehler reigeraten...

Danke erstmal.

Zitat von fubini

$VEL sind kartesische Werte

Ja, aber was ist $VEL.AXIS[4]=10? Siehe "KSS_85_SI_de.pdf" S.495 oben im Beispiel.

Maximale Achsbeschleunigungen bei LIN/SLIN?

- Thema $ACC_AXIS: In "KSS_85_SI_de.pdf" S. 489 unten steht jedoch:

$ACC_AXIS[1]={CP 20, ORI1 80, ORI2 80}

Ich dachte $ACC_AXIS[]= wird ausschließlich in Prozent angegeben. Die Werte hier beziehen sich doch eigentlich auf die kartesischen Bewegungen.

Hallo,

ich nutze meist Spline-Einzelbewegungen und somit folgende (hoffentlich korrekte) Syntax (Beispiele):

;SLIN
$ACC={CP 1.0, ORI1 100, ORI2 100}
$VEL={CP 2.0, ORI1 200, ORI2 200}
SLIN P1
$ACC.CP=2.0
SLIN P2
SLIN P3 WITH $VEL.CP=0.1

;SPTP
SPTP P1 WITH $VEL_AXIS[1]=10
$VEL_AXIS[1]=20
$ACC_AXIS[1]=20
SPTP P2

Jetzt muss ich alte Bewegungen programmieren und bin dabei auf mehrere Fragen gestorßen:

- Darf WITH verwendet werden oder geht das nur bei Spline-Bewegungen?

- Was ist der Unterschied zwischen $VEL_AXIS[4]=10 und $VEL.AXIS[4]=10 und wo dürfen diese verwendet werden? .AXIS finde ich in der Struktur komischweise auch garnicht.

- Was ist das: $ACC_AXIS[1]={CP 20, ORI1 80, ORI2 80} ? In der Doku "Systemvariablen" steht nur $ACC_AXIS[Achsnummer]=Beschleunigung

- Sonst ist die Syntax bezüglich Beschl. und Geschw. identisch, korrekt?

Viele Grüße

Oh man wie dämlich. Sollte so funktionieren. Danke!