Beiträge von [wEm]

Du könntest auch rob_stop() und rob_stop_release() im submit Interpreter versuchen.

Du könntest das Programm duplizieren und den Code den Du nicht haben willst löschen. Ist wahrscheinlich schneller als im Nachhinein .src und .dat zu öffnen und die Punkte umzubenennen

Letztendlich muss Du Dir in C# einen TCP Listener erstellen. Beispiel habe ich keines, aber das ist auch recht schnell in ein paar Zeilen Code erledigt:
https://msdn.microsoft.com/de-…cplistener(v=vs.110).aspx

Ob Du nun XML oder BinaryFixed/Stream verwendest hängt eigentlich ganz von Deinem Geschmack ab. Da Du aber in C# unterwegs bist, würde ich auf XML setzen, denn

• EthernetKRL wird mit Benutzung von XML wesentlich flexibler (z.B. Triggern wenn nur bestimmte Datensätze ankommen)


• EthernetKRL erstellt für jedes XML Element einen eigenen Puffer (in den anderen beiden Formaten gibt es nur einen Puffer für das komplette Telegramm)


• Du hast recht einfach zu bedienende Bibliotheken auf C# bzw. .NET Seite.

Aber nur durch KUKA.CNC wird der Roboter deswegen nicht genauer.
Also bevor Du in CNC investierst solltest Du Dir auf jeden Fall Gedanken machen ob Du mit dem Roboter überhaupt die erwünschte Oberflächenqualität erreichen kannst.

Was hast Du denn für Anforderungen?

Also wenn Deine punkte 0.1mm auseinander liegen dann kann das beim SLIN dazu führen dass es nur als 1 Punkt erkannt wird.
Wie schnell willst Du denn die Bahn abfahren? Nehmen wir mal an, du fährst Die Bahn mit 1m/min ab = 16mm/s.
Der Interpolationstakt des Roboters ist 12ms. In 12ms fährst du mit Deiner Geschwindigkeit 0.2mm. Das bedeutet mit 0.5m/min Vorschub bist Du im Interpolationstakt des Roboters mit 1m/min liegst Du noch darunter. Das macht so keinen Sinn.
Der Grund dass SLIN schlimmer ist liegt wahrscheinlich auch daran, dass er die Punkte einfach hart anfährt. LIN filtert deine punkte noch schön glatt, SLIN versucht den Roboter immer an die physikalischen Grenzen zu bringen. Minimale Höhenunterschiede (gerade wenn diese nicht stetig sind) verursachen also einen recht hohen Ruck und das hört man auch. Dann kommt nocht die 0.1mm Grenze dazu.
Die Einstellung welche Du verbessern müsstest wäre, die Punkte einfach weiter auseinander zu legen. Ich glaube nicht, dass Du so ein komplexes Bauteil hast, dass Du jede 0.1mm einen Punkt brauchst. Versuch es doch mal mit 10mm. Dann noch beim SLIN Beschleunigung und Ruck so setzen dass es nicht zu hart wird und dann sollte es schon besser aussehen.

Was wollt ihr denn damit erreichen? Sind das x-beliebige Servos? Dann brauchst du dazu ja auch noch die entsprechenden Daten, sonst werden die sich nicht sauber bewegen.

Aber du musst doch nach jedem Aufruf von INVERSE den Rückgabewert, welchen Du in CALC_Meldungsnummer speicherst auswerten, sonst überschreibt Dir die INVERSE Funktion in der darauffolgenden Zeile den Wert.

Hallo
du sagst "Die Inverse Funktion gibt keinen Fehler aus"...

An welcher Stelle überprüfst du denn den CALC_Meldungsnummer ob INVERSE auch wirklich durchgeführt wurde.

Hier gibt es ja unterschiedliche Ursachen, die Du nach jedem Aufruf von INVERSE abfragen solltest

Möchte auch noch meinen Senf dazugeben:
Wenn Du das Ganze mit Flag/Ausgang realisierst, dann könntest Du die Daten auch in einem Interrupt auslesen und Dein Robi kann in der Zeit noch was anderes machen.

in den {} erwartet KUKA eine Konstante, also eine Zahl. Variablen gehen an der Stelle nicht.
Demnach kannst Du folgendes machen:

DECL FRAME Hoehe


Hoehe = $NULLFRAME ;(setzt x,y,z,a,b,c auf den Wert 0)
Hoehe.Z = 12
FOR i=1 TO 120 STEP 1
  CIRC {X 42.95,Y 11.2},{X 45.7,Y 13.95} C_DIS
  CIRC {X 42.95,Y 15.7},{X 40.2,Y 13.95} C_DIS
  LIN_REL HoeheC_DIS ;ich würde mal behaupten, Du willst relativ zur aktuellen Position fahren?
Hoehe.Z = Hoehe.Z -0.1
ENDFOR

Simulink-Technisch kann ich Dir zwar nicht weiterhelfen, aber ich hätte da noch eine Frage.
Sollen die Daten zwischen den beiden Systemen in Echtzeit geschickt werden? Dann wäre das Softwarepaket das falsche.

TCP Geschwindigkeit:
Du liest über das RSI Objekt ACTPOS die Positionen X/Y/Z
Dann berechnest Du Dir die Position auf der Bahn
pos_bahn = SQRT(X²+Y²+Z²)
Dann jagst Du diesen Wert durch das D Objekt (=Differenzierer) und fertig.
Kleiner Tip: RSI besitzt kein Mathematisches "Quadratwurzel" Objekt, aber SQRT(x) = x^-0.5 --> Also mit dem POW Objekt arbeiten

Zitat

Mein Roboter steht in einem isolierten Raum der zwischen 5 und 20°hat.

Da solltest Du immer mal wieder drauf schauen. Wenn der Roboter längere Zeit bei 5° C Umgebungstemperatur rumsteht könnte es erforderlich sein, den Wiederanlauf etwas langsamer zu machen, damit sich das Öl in den Getrieben aufwärmen kann.
Ansonsten könnte der Roboter in diverse Überwachungen (z.B. Getriebemoment) reinlaufen und mit einer Fehlermeldung stehen bleiben.
Am besten einfach mal beobachten. Wenn der Robi nach dem Wochenende rumzickt, dann für die ersten Zyklen einfach mit geringerem Override beginnen (oder du erstellst ein Warmfahrprogramm).

Lin {z 231}
Musst noch sicherstellen, dass Base und Tool auch passen.

Das ist so: 10v am Eingang entsprechen 1.0 beim entsprechenden $anin[]. Musst also dein Signal entweder mit 10 multiplizieren, oder auf 0.96 abfragen

Wenn Du einen booleschen Wert in INT konvertierst kommt halt 0 oder 1 raus. Das hilft Dir nicht weiter.
Du musst halt irgendwie folgendes machen (also in etwas so wie Du es schon beschrieben hattest)

If (is_key_pressed(10)) THEN
  $SEN_PINT[1] = 10
ENDIF

Ist vielleicht beim dritten Roboter der Experte als Standard eingestellt? Vergleiche mal die C:\KRC\SmartHMI\Config\authentication.config der Roboter

Naja, per $SEN_PINT[] Array kannst Du schon mal die Werte aus KRL ans RSI übermitteln.
Und dann mit ST_SEN_PINT() in RSI einlesen und ans ST_ETHERNET Objekt anknüpfen und fertig
Du musst also im sps.sub lediglich die Tasten abfragen und dann in die $SEN_PINT[] Variablen schreiben.
Bei der 6D Maus wüsste ich jetzt nicht ob das geht. Keine Ahnung ob es für die Auslenkung der Maus KRL Variablen gibt.

Ok, da es prinzipiell zu funktionieren scheint, ziehe ich meine auf "gefährlichem Halbwissen" basierende Aussage oben zurück

Ich kenn mich mit der 840d jetzt nicht wirklich aus, aber wenn ich mir das auf der Siemens Seite so durchlese, ist die 840d ein ProfiSafe device - dein KUKA dummerweise auch.
Sprich: Du hast zwei Profisafe devices, und die können nun mal nicht miteinander kommunizieren.
Du brauchst ja irgendeine übergeordnete Steuerung die den Devices z.B. mitteilt dass der Bedienerschutz offen ist etc...

Aber das ist nur eine Vermutung von mir