Siemens
Siemens

Digital Industries, Motion Control, Machine Tool Systems

5-Achsprogrammierung / TRAORI, ORIVECT verhält sich (scheinbar) wie ORIAXES

Beitrag 26.11.2018, 19:55 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
Hallo zusammen!

Ich versuche mich gerade ein wenig in die 5-Achs-Programmierung einzuarbeiten, speziell mit TRAORI.
Dazu habe ich mir die Testversion von Sinutrain installiert.

Ich möchte aus einem Quader einen (nicht quadratischen) Pyramidenstumpf herstellen. An den Ecken sollen statt scharfen Kanten, Radien entstehen. Die Neigung der Seitenflächen beträgt 15°.
Länge=250/228 mm (Unterseite/Oberseite)
Breite=140/118 mm
Höhe 50 mm
Nullpunkt in der Mitte der Quaderseite.

Mit Ausnahme der Radien ist dies also quasi das Gegenstück zu der in den Dokumentationen oft als Beispiel herangezogenen Tasche mit schrägen Wänden.

Die Schräge wird wir durch folgendes rechtwinkliges Dreieck abgebildet:
AK=41.05
GK=11
HT=42.5

Nun das Programm

CODE
Vertikale Fräsmaschine mit Schwenktisch

/_N_MPF_DIR/_N_TRAORI_BSP_08_MPF

25.11.2018 11:53

E_HEAD(268443647,-127,-72,5,254,144,-55,71,17,2,100,1,1,20,,1,7,6,100);*RO*
T="CUTTER 20" D1
M6
S4000 M3
F600
TRAORI()
ORIVECT
ORIWKS
CUT3DC
ISD=0
G0 X135 Y0
G0 Z-42
G1 G41 X125 Y0 Z-42.5 A3=-11 B3=0 C3=41.0526 T="CUTTER 10"
Y-62.27 A3=-11 B3=11 C3=41.0526
ORICONCW
G2 X117.27 Y-70 CR=8 A3=-11 B3=11 C3=41.0526 A6=-11.282 B6=11.282 C6=41.0526
ORIVECT
G1 X-117.27 A3=11 B3=11 C3=41.0526
ORICONCW
G2 X-125 Y-62.27 CR=8 A3=11 B3=11 C3=41.0526 A6=11.282 B6=11.282 C6=41.0526
ORIVECT
G1 Y62.27 A3=11 B3=-11 C3=41.0526
ORICONCW
G2 X-117.27 Y70 CR=8 A3=11 B3=-11 C3=41.0526 A6=11.282 B6=-11.282 C6=41.0526
ORIVECT
G1 X117.27 A3=-11 B3=-11 C3=41.0526
ORICONCW
G2 X125 Y62.27 CR=8 A3=-11 B3=-11 C3=41.0526 A6=-11.282 B6=-11.282 C6=41.0526
ORIVECT
G1 Y-1 A3=-11 B3=0 C3=41.0526
G1 G40 X140 A3=0 B3=0 C3=1
G0 Z250 A3=0 B3=0 C3=1
TRAFOOF
E_END(0,1,0);*RO*
M30;#SM;*RO*


Prinzipiell funktioniert die Sache auch schon ganz gut, auch mit den Radien.

Mein Problem ist jedoch, dass das Ergebnis genau so aussieht, als wäre hier ORIAXES am Werk gewesen.
Das Beispiel mit der Tasche mit schrägen Wänden wird in verschieden Dokus herangezogen, um den Unterschied zwischen ORIAXES und ORIVECT zu verdeutlichen.
Bei ORIAXES ensteht durch die lineare Interpolation der Linear- und Rundachsen eine bauchige Kontur an den Seitenwänden. Die Kanten am Taschenboden sind jedoch Geraden.
Bei ORIVECT wird durch die Vektorinterpolation eine Ebene zwischen Start- und Endvektor aufgespannt. Die Verbindungen zwischen den beiden Vektoren sind also beides Geraden.

Ich habe ein Bild meines Ergebnisses angehängt.

Ich stelle mir nun die Frage woher dies kommt. Ich habe schon alles mögliche ausprobiert. Das Ergebnis bleibt grundsätzlich immer so "bauchig".
Zum Einen könnte es sein, dass ich noch grundsätzlich etwas falsch mache bei der Programmierung.
Zum Anderen könnte es aber auch an Sinutrain liegen. Ich benutze die "mitgelieferte" "Vertikale Fräsmaschine mit Schwenktisch" (XYZAC)
Möglicherweise ist diese ja nicht richtig konfiguriert um dieses Beispiel korrekt zu simulieren. Ich musste z.B. auch erst ein MD setzen um überhaupt TRAORI im G-Code nutzen zu können.


Ich bin dankbar für jeden Hinweis und jede Anregung.

Gruß
Alex
Angehängte Datei(en)
Angehängte Datei  DG_1.JPG ( 85.37KB ) Anzahl der Downloads: 93
 
   
Beitrag 27.11.2018, 11:16 Uhr
zmudason
zmudason
*Registered User*
*
Gruppe: Mitglied
Mitglied seit: 07.01.2011
Beiträge: 1
Hallo Alex!

Habe momentan auch ein Problem mit der Simulation in Zusammenhang mit TRAORI.
Du schreibst, Du musstest ein MD setzen. Welches war das?

Grüße,
Stephan
   
Beitrag 27.11.2018, 18:54 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
Hallo Stephan,

das war MD21104. Ich bin darauf gekommen, weil ich folgende Fehlermeldung hatte:

14134 [Kanal %1: ] Satz %2 G-Code für Orientierungsinterpolation nicht erlaubt: Fehler Nr. %3
Parameter: %1 = Kanalnummer
%2 = Satznummer, Label
%3 = Fehler Nummer
Erläuterung: Der Alarm kann unterschiedliche Ursachen haben, die durch die angegebene Fehlernummer unterschieden werden:
Es gibt folgende Werte der Fehler Nummer:
1: Die Programmierung eines G-Codes der 51. G-Code-Gruppe ist nur erlaubt, wenn das MD21104
$MC_ORI_IPO_WITH_G_CODE auf TRUE gesetzt ist.


Gruß
Alex
   
Beitrag 27.11.2018, 19:37 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
Mich wundert, dass die Endorientierung bei Kegelmantelorientierung gleich der Startorietierung (= Endorientierung im Vorgängersatz) sein soll, z.B. direkt hier nach dem G41-Satz:
CODE
Y-62.27 A3=-11 B3=11 C3=41.0526
ORICONCW
G2 X117.27 Y-70 CR=8 A3=-11 B3=11 C3=41.0526 A6=-11.282 B6=11.282 C6=41.0526

Das kann ja eigentlich nicht richtig sein.

Um sich mal an das richtige Ergebnis heranzutasten, würde ich mal folgendes probieren:
- Werkzeugradiuskorrektur ausschalten.
- Die Sätze mit der Kegelmantelinterpolation durch Sätze mit ORIVECT ersetzen und überprüfen, ob dann der erwartete Pyramidenstumpf in der Simulation erscheint. Dass dann die Ecken nicht so aussehen, wie sie sollen, ist klar, stört aber zunächst ja mal nicht. Man könnte damit aber das Problem evtl. auf die ORICONCW-Programmierung eingrenzen.
   
Beitrag 27.11.2018, 20:01 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE (CNCFr @ 27.11.2018, 20:37 Uhr) *
Mich wundert, dass die Endorientierung bei Kegelmantelorientierung gleich der Startorietierung (= Endorientierung im Vorgängersatz) sein soll, z.B. direkt hier nach dem G41-Satz:
CODE
Y-62.27 A3=-11 B3=11 C3=41.0526
ORICONCW
G2 X117.27 Y-70 CR=8 A3=-11 B3=11 C3=41.0526 A6=-11.282 B6=11.282 C6=41.0526

Das kann ja eigentlich nicht richtig sein.


Meine Radien sind der zylindrische Spezialfall des Kegels. Aus diesem Grund sind die Endorientierung gleich der Startorientierung aus dem Vorgängersatz, nur örtlich verschoben bzw. um die Zylinder(Kegel)-Achse rotiert

QUOTE
Um sich mal an das richtige Ergebnis heranzutasten, würde ich mal folgendes probieren:
- Werkzeugradiuskorrektur ausschalten.
- Die Sätze mit der Kegelmantelinterpolation durch Sätze mit ORIVECT ersetzen und überprüfen, ob dann der erwartete Pyramidenstumpf in der Simulation erscheint. Dass dann die Ecken nicht so aussehen, wie sie sollen, ist klar, stört aber zunächst ja mal nicht. Man könnte damit aber das Problem evtl. auf die ORICONCW-Programmierung eingrenzen.


Das habe ich beides auch schon ausprobiert, leider ohne Erfolg (siehe Bild).

Trotzdem Danke.

Gruß Axel
Angehängte Datei(en)
Angehängte Datei  DG_2.JPG ( 91.72KB ) Anzahl der Downloads: 49
 
   
Beitrag 27.11.2018, 21:08 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
QUOTE (pbv0411 @ 27.11.2018, 21:01 Uhr) *
Meine Radien sind der zylindrische Spezialfall des Kegels. Aus diesem Grund sind die Endorientierung gleich der Startorientierung aus dem Vorgängersatz, nur örtlich verschoben bzw. um die Zylinder(Kegel)-Achse rotiert.

Dann kannst du dir in den Kreissätzen die Orientierungsänderung ja komplett sparen, wenn die Orientierung konstant ist. Oder ist das nur als Vorbereitung für die Zukunft gedacht, wenn an den Ecken mal echte Kegel entstehen sollen? Aber das hat mit deinem eigentlichen Problem ja nichts zu tun.

Ändert sich das Bild denn, wenn man ORIVECT durch ORIAXES ersetzt, oder ist das Bild nur ähnlich?
In dem ersten Bild fällt auf, dass die Orientierung in der Mitte der einen Schmalseite anscheinend OK ist. Dort ist ja der Anfahrpunkt und die Orientierung ist explizit programmiert. An den anderen Seiten ist die Orientierung anscheinend falsch. Wenn ich es richtig sehe müsste in den Seitenmitten die A-Achse immer exakt die gleiche Position haben. Das deutet nun auch wieder darauf hin, dass aus irgend einem Grund die Rundachsen linear interpoliert werden.
Noch eine letzter Versuch: Ändere mal das MD21102 $MC_ORI_DEF_WITH_G_CODE von 0 auf 1 bzw. umgekehrt.
   
Beitrag 27.11.2018, 22:10 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE (CNCFr @ 27.11.2018, 22:08 Uhr) *
Dann kannst du dir in den Kreissätzen die Orientierungsänderung ja komplett sparen, wenn die Orientierung konstant ist. Oder ist das nur als Vorbereitung für die Zukunft gedacht, wenn an den Ecken mal echte Kegel entstehen sollen? Aber das hat mit deinem eigentlichen Problem ja nichts zu tun.

Hmmh...ja das könnte ich wohl. Ich gehe da aber immer lieber auf Nummer sicher und schreibe etwas doppelt. Zumal wenn man sich nicht sicher ist was nötig ist und was nicht. Ist so ein Tick von mir, mache ich auch oft bei XYZ, auch wenn sich nur eine Koordinate ändert. Der Code sieht dann nicht so "zerrupft" aus. Es entsteht ein gewisses Schema.

QUOTE
Ändert sich das Bild denn, wenn man ORIVECT durch ORIAXES ersetzt, oder ist das Bild nur ähnlich?

Nein. Das hatte ich auch schon probiert.

QUOTE
In dem ersten Bild fällt auf, dass die Orientierung in der Mitte der einen Schmalseite anscheinend OK ist. Dort ist ja der Anfahrpunkt und die Orientierung ist explizit programmiert.

Richtig.

QUOTE
An den anderen Seiten ist die Orientierung anscheinend falsch. Wenn ich es richtig sehe müsste in den Seitenmitten die A-Achse immer exakt die gleiche Position haben.

Korrekt. Immer 20.754°.

QUOTE
Das deutet nun auch wieder darauf hin, dass aus irgend einem Grund die Rundachsen linear interpoliert werden.

Genau. Nur wodurch....

QUOTE
Noch eine letzter Versuch: Ändere mal das MD21102 $MC_ORI_DEF_WITH_G_CODE von 0 auf 1 bzw. umgekehrt.

Bringt leider auch nichts.


Ich muss jetzt ins Bett, aber Danke für die Mithilfe.

Der Beitrag wurde von pbv0411 bearbeitet: 27.11.2018, 22:16 Uhr
   
Beitrag 28.11.2018, 15:13 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
QUOTE (pbv0411 @ 27.11.2018, 23:10 Uhr) *
Korrekt. Immer 20.754°.

Das ist allerdings der Winkel an den Ecken. In den Seitenmitten muss der Winkel der A-Achse 15 Grad sein (atan(11/41.0526).

Ich habe das jetzt bei mir auch mal mit dem Simulator laufen lassen, ohne irgendwelche Maschinendaten zu verändern, und da verhält sich das alles wie erwartet, d.h. der Winkel der A-Achse nimmt bei der Interpolation längs einer Seite von einer Ecke bis zur Seitenmitte von 20.754 Grad auf 15 Grad ab und steigt dann wieder auf 20.754 bis zum Satzende, genau wie ich das erwarte.
Eigenartig!
   
Beitrag 28.11.2018, 19:38 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE (CNCFr @ 28.11.2018, 16:13 Uhr) *
Das ist allerdings der Winkel an den Ecken. In den Seitenmitten muss der Winkel der A-Achse 15 Grad sein (atan(11/41.0526).

Ja, das ist richtig. Es war wohl gestern Abend schon ein wenig spät für mich.

Ich hatte dies hier
QUOTE
Wenn ich es richtig sehe müsste in den Seitenmitten die A-Achse immer exakt die gleiche Position haben.
nicht richtig gelesen.

Ja in der Mitte der Seiten sollte die A-Achse immer die gleiche Position haben.

QUOTE
Ich habe das jetzt bei mir auch mal mit dem Simulator laufen lassen, ohne irgendwelche Maschinendaten zu verändern, und da verhält sich das alles wie erwartet, d.h. der Winkel der A-Achse nimmt bei der Interpolation längs einer Seite von einer Ecke bis zur Seitenmitte von 20.754 Grad auf 15 Grad ab und steigt dann wieder auf 20.754 bis zum Satzende, genau wie ich das erwarte.
Eigenartig!

Ja und wie ich das erwarten würde. Eigenartig und irgendwie schade.

Benutzt Du dafür die Simulation an einer Steuerung oder Sinutrain?
Wenn letzteres, welche Version nutzt Du denn? Ich habe hier die 4.4ed3.


Ich habe eben gerade noch mal die Bearbeitung (Menü "Maschine") simulieren lassen.
Dort verändert sich der Winkel wie erwartet: 20.754...15.0...20.754 Grad. Allerdings die C-Achse! Ich bin verwirrt.
   
Beitrag 28.11.2018, 21:50 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
Ich habe SinuTrain und zwar nur die heftig kastrierte lizenzfreie Variante mit der Versionsbezeichnung "SinuTrain Workbench Version: 01.02.00".
Die habe ich mir im September 2017 heruntergeladen. Ich spiele damit eher selten und ungern und kenne mich mit dem Teil deshalb auch nicht besonders gut aus.

Wenn die C-Achse die Positionen anfährt, die du eigentlich in der A-Achse erwartest, müssen wohl irgendwo die Achsen vertauscht worden sein, was ja weiter noch nichts bedeuten muss, denn (Achs-) Namen sind letztlich doch nur Schall und Rauch. Aber die Vermutung liegt nahe, dass die Vertauschung der Achsbezeichner nicht der einzige Fehler in der Trafokonfiguration ist.

Was steht den in den relevanten Daten (TRAFO_TYPE, TRAFO_AXES_IN, TRAFO5_AXIS1_1, TRAFO5_AXIS2_1)?
Wie ist die Achsreihenfolge der beiden Rundachsen? Ist C die vierte und A die fünfte Achse oder ist es umgekehrt?
   
Beitrag 29.11.2018, 20:23 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE
Aber die Vermutung liegt nahe, dass die Vertauschung der Achsbezeichner nicht der einzige Fehler in der Trafokonfiguration ist.

Das ist auch meine Vermutung und Hoffnung. Allerdings schwindet die mehr und mehr.
Ich habe gestern Abend damit angefangen, die ganze Liste der MDs von Anfang bis Ende (da bin ich noch nicht angelangt) auf Daten zu durchforsten, welche mein Thema beeinflußen könnten. Ich habe die Doku mit den ausführlichen Beschreibungen aller Parameter.
Damit habe ich dann bei den MDs welche in Frage kommen könnten ein wenig mit den Werten herumgespielt. Bis jetzt Leider ohne Erfolg.

QUOTE
Was steht denn in den relevanten Daten (TRAFO_TYPE, TRAFO_AXES_IN, TRAFO5_AXIS1_1, TRAFO5_AXIS2_1)?

24100 -> $MC_TRAFO_TYPE_1 = 512 (->TRANSMIT-Transformation? Noch nie gehört)

24110[0] -> $MC_TRAFO_AXES_IN_1 = 3
24110[1] -> $MC_TRAFO_AXES_IN_1 = 4
24110[2] -> $MC_TRAFO_AXES_IN_1 = 1
24110[3] -> $MC_TRAFO_AXES_IN_1 = 2
24110[4] -> $MC_TRAFO_AXES_IN_1 = 5
24110[5] und folgende = 0

24570[0] -> $MC_TRAFO5_AXIS1_1 = 0
24570[1] -> $MC_TRAFO5_AXIS1_1 = 0
24570[2] -> $MC_TRAFO5_AXIS1_1 = 0

24572[0] -> $MC_TRAFO5_AXIS2_1 = 0
24572[1] -> $MC_TRAFO5_AXIS2_1 = 0
24572[2] -> $MC_TRAFO5_AXIS2_1 = 0

AXIS1_1 hatte ich gestern schon mal auf [1,0,0] und AXIS2_1 auf [0,0,1] gesetzt. Resultat: keine Änderung!

An TRAFO_TYPE_1 hatte ich auch herumgespielt. Auf 49 gesetzt = 48 (5-Achs-Transformation mit drehbarem Werkstück) + 1 (Achsfolge AC).
Das gab einen Folgefehler den ich noch nicht aufgelöst habe: 4338 -> Ungültiger Transformationstyp " in Toolcarrier 0 für Orientierungstrafo 2


QUOTE
Wie ist die Achsreihenfolge der beiden Rundachsen? Ist C die vierte und A die fünfte Achse oder ist es umgekehrt?

Die Reihenfolge ist AC.
   
Beitrag 29.11.2018, 21:06 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
24100 -> $MC_TRAFO_TYPE_1 = 512: Das ist nicht TRANSMIT sondern TRACYL (TRANSMIT ist letztlich eine Transformation, die kartesische Koordinaten in Polarkoordinaten der Maschine, der Name leitet sich ab aus TRAnsformation MIlling- Turning,
TRACYL ist die sog. Zylindermanteltransformation, d.h. die kart. Ebene wird auf einen Zylindermantel abgebildet.).

Deine 5-Achs-Transformation ist also nicht die erste Trafo.
Du musst nach einem MD $MC_TRAFO_TYPE_n suchen, wobei n von 1 bis 20 laufen kann. Die erste Trafo in dieser Reihe, bei der der eingetragen Type kleiner ist als 256 ist die erste TRAORI-Trafo, die im Porgramm mit TRAORI aufgerufen wird. Ich würde den Typ 56 (oder 72, s.unten, weitere Varianten sind möglich) erwarten.
Die Maschindaten, die es für alle Trafodaten gibt haben die Form
$MC_TRAFO_TYPE_n usw.
Wenn deine Traori-Trafo also z.B. mit dem $MC_TRAFO_TYPE_3 definiert wird, werden die Achszuordnungen $MC_TRAFO_TYPE_3 usw. definiert.
Daneben gibt es Maschinendaten die es nur für die 5-Achs-Transformation gibt.
Da beginnt die Zählung wieder mit 1, also z.B.
$MC_TRAFO5_AXIS1_1

Hier passt etwas nicht. Egal welche Nummer n in $MC_TRAFO_TYPE_n steht müssten die Achsrichtungsvektoren in $MC_TRAFO5_AXIS1_1. stehen. Da du aber lauter Nullvektoren hast und es nicht zu einem Alarm kommt, müssen die Achsrichtungen aus einer anderen Quelle kommen.
Eine Erklärung wäre, dass der Trafotyp 72 ist. Dann kommen die Parameter aus einem sog. ToolCarrier. Eine andere (ganz moderne) Variante wäre, dass die Trafo mit kinematischen Ketten parametriert ist. Das Gegenteil, eine ganz antiquierte Möglichkeit wäre ein Trafotyp 48 <= Typ < 56.
Du solltest das mal überprüfen, dann sehen wir weiter.
   
Beitrag 01.12.2018, 00:46 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE (CNCFr @ 29.11.2018, 22:06 Uhr) *
24100 -> $MC_TRAFO_TYPE_1 = 512: Das ist nicht TRANSMIT sondern TRACYL (TRANSMIT ist letztlich eine Transformation, die kartesische Koordinaten in Polarkoordinaten der Maschine, der Name leitet sich ab aus TRAnsformation MIlling- Turning,
TRACYL ist die sog. Zylindermanteltransformation, d.h. die kart. Ebene wird auf einen Zylindermantel abgebildet.).

Oh ja, da hst Du Recht. Ich habe mich in der Doku verlesen. Ich dachte erst steht der Typ und in der folgenden Zeile die Kodierung.
ab 256
TRANSMIT-Transformation
ab 512
TRACYL-Transformation
Doof von mir!

QUOTE
Deine 5-Achs-Transformation ist also nicht die erste Trafo.
Du musst nach einem MD $MC_TRAFO_TYPE_n suchen, wobei n von 1 bis 20 laufen kann. Die erste Trafo in dieser Reihe, bei der der eingetragen Type kleiner ist als 256 ist die erste TRAORI-Trafo, die im Porgramm mit TRAORI aufgerufen wird. Ich würde den Typ 56 (oder 72, s.unten, weitere Varianten sind möglich) erwarten.

Das wäre dann in der Tat $MC_TRAFO_TYPE_3 mit 72.

QUOTE
Wenn deine Traori-Trafo also z.B. mit dem $MC_TRAFO_TYPE_3 definiert wird, werden die Achszuordnungen $MC_TRAFO_TYPE_3 usw. definiert.

Sorry, aber diesen Satz verstehe ich nicht. Meinst Du $MC_TRAFO_AXES_IN_3[n]?
$MC_TRAFO_AXES_IN_3[0-4] = 1,2,3,4,5
   
Beitrag 01.12.2018, 08:50 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
QUOTE (pbv0411 @ 01.12.2018, 01:46 Uhr) *
$MC_TRAFO_AXES_IN_3[0-4] = 1,2,3,4,5

Ja, die meinte ich.
Aber zumindest die Info über die Rundachsen kommt aus dem ToolCarrier.
Relevant ist mit ziemlicher Sicherheit der ToolCarrier mit dem Index 1 (der Index steht in MD24582 $MC_TRAFO5_TCARR_NO_1).
In $TC_CARR21[1] und $TC_CARR22[1] sollten die Rundachsbezeichner stehen, die bei dir anscheinend vertauscht sind bzw. nicht zu deiner Achskonfiguration passen. Du kannst die beiden vertauschen.
Die zugehörigen Richtungsvektoren für die beiden Achsen stehen in den Parametern $TC_CARR7[1] - $TC_CARR9[1] für die erste Achse und in $TC_CARR10[1] - $TC_CARR12[1] für die zweite Achse. Das muss mit den Daten in $TC_CARR21/22 zusammenpassen.
In $TC_CARR23[1] muss ein M stehen (= Mixed Kinematik, d.h. eine Rundachse im Kopf und eine im Tisch).
Ich habe im Simulator übrigens Seite mit den ToolCarriern nicht gefunden, was nicht heißt, dass sie nicht da sind, sondern nur, dass ich nicht weiß, wie man da hin kommt.
   
Beitrag 02.12.2018, 01:03 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE (CNCFr @ 01.12.2018, 09:50 Uhr) *
Relevant ist mit ziemlicher Sicherheit der ToolCarrier mit dem Index 1 (der Index steht in MD24582 $MC_TRAFO5_TCARR_NO_1).

Ja, das ist bei mir so.

QUOTE
Ich habe im Simulator übrigens Seite mit den ToolCarriern nicht gefunden, was nicht heißt, dass sie nicht da sind, sondern nur, dass ich nicht weiß, wie man da hin kommt.

Ich habe sie in SinuTrain direkt auch nirgends gefunden.
Dafür gibt es aber einige *.ini Dateien, welche unter anderem die ganzen MDs enthalten. In zwei Dateien habe ich auch die $TC-Parameter gefunden und so angepasst wie Du es gesagt hast. Dieser Weg funktioniert allerdings auch nicht, da die Dateien von SinuTrain beim Start der Simulation immer wieder mit den ursprünglichen Werten überschrieben werden.

Ich glaube wir geben die Sache auf. Oder hast Du noch eine Idee?
   
Beitrag 02.12.2018, 11:04 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
Du könntest es mal ohne den ToolCarrier probieren. Da sollte mit folgenden Änderungen gehen:
MD24582 $MC_TRAFO5_TCARR_NO_1 = 0 ; Keine Parametrierung über ToolCarrier
MD24300 $MC_TRAFO_TYPE_3 = 49 ; Trafodefinition mit voreingestellten Rundachsrichtungen

MD24310[0] $MC_TRAFO_AXES_IN_3 = 1 ; Definition der Trafoeingangsachsen
MD24310[1] $MC_TRAFO_AXES_IN_3 = 2
MD24310[2] $MC_TRAFO_AXES_IN_3 = 3
MD24310[3] $MC_TRAFO_AXES_IN_3 = 4
MD24310[4] $MC_TRAFO_AXES_IN_3 = 5

Die 5 Daten für das Array MD24310 sind wahrscheinlich schon voreingestellt. Wenn die Rundachsen dann vertauscht sind, kannst du die beiden Werte in MD24310[3 / 4] vertauschen, als 5, 4 statt 4, 5.
   
Beitrag 03.12.2018, 19:24 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
Also:
Die gute Nachricht ist, dass es Veränderungen gibt.
Die schlechte Nachricht ist, dass diese Veränderungen in beiden Fällen nicht unbedingt dem entspricht, was wir anstreben (siehe Bilder).
Halt mal die Maus über die Vorschau, dann siehst Du welches Bild von welchem Versuch stammt.

Nebenbei:
Du hattest erwähnt, dass Du mein Beispiel mit Deiner lizenzfreien Version von SinuTrain hast laufen lassen.
Ich meine jedoch gelesen zu haben, dass die freien Versionen nur reinen 3-Achsbetrieb erlauben!?

Hast Du eine Ahnung was eine Einzelplatz-Lizenz für SinuTrain kostet?
Ich hatte mal auf die schnelle danach gesucht, bin aber nicht fündig geworden.
Wird wohl nicht gerade günstig sein...

Der Beitrag wurde von pbv0411 bearbeitet: 03.12.2018, 19:26 Uhr
Angehängte Datei(en)
Angehängte Datei  4_5.JPG ( 36.81KB ) Anzahl der Downloads: 36
Angehängte Datei  5_4.JPG ( 33.64KB ) Anzahl der Downloads: 39
 
   
Beitrag 04.12.2018, 21:44 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922
Bei Siemens habe ich eine Seite gefunden, auf der man sich anscheinend die Preise anzeigen lassen kann. Dazu muss man sich aber anmelden, was ich nicht wollte.
Die Lizenzen kann man auch bei Christiani kaufen. Ich nehme mal an, dass die Preise zumindest ähnlich zu denen unmittelbar bei Siemens sind. Du findest sie hier (Button Lizenzen anclicken):
http://www.christiani.de/product_info.php/products_id/26498

Zum 3- bzw. 5-Achsbetrieb: Bei mir hat der 5-Achs-Betrieb wie gesagt sofort funktioniert und ich habe jetzt auch keine offensichtliche Fehlfunktion gesehen.
Zu den beiden Bildern: Das erste Bild (Achsreihenfolge 4-5) sieht ja recht vernünftig aus. Was mich stutzig macht: An der linken vorderen Ecke sieht die Kante konvex aus. Dass lässt sich ja mit einem Schnitt so gar nicht herstellen. Möglicherweise hat ja die Simulation ein Problem.
Eine gute Idee, was man jetzt noch probieren könnte, habe ich jetzt leider auch nicht mehr.
Hast du denn die Möglichkeit, das Ganze auch mal an einer realen Maschine zu testen?
   
Beitrag 05.12.2018, 19:47 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
QUOTE
Zum 3- bzw. 5-Achsbetrieb: Bei mir hat der 5-Achs-Betrieb wie gesagt sofort funktioniert und ich habe jetzt auch keine offensichtliche Fehlfunktion gesehen.

Das ist sehr interessant. Aber vielleicht galt die Einschränkung bei älteren Versionen auch nicht.

QUOTE
Zu den beiden Bildern: Das erste Bild (Achsreihenfolge 4-5) sieht ja recht vernünftig aus. Was mich stutzig macht: An der linken vorderen Ecke sieht die Kante konvex aus. Dass lässt sich ja mit einem Schnitt so gar nicht herstellen. Möglicherweise hat ja die Simulation ein Problem.

Ja, es sieht scheinbar so aus.

QUOTE
Eine gute Idee, was man jetzt noch probieren könnte, habe ich jetzt leider auch nicht mehr.

Das macht nichts, Du hattest ja doch etliche Ideen. Dafür auf jeden Fall mal vielen Dank!

QUOTE
Hast du denn die Möglichkeit, das Ganze auch mal an einer realen Maschine zu testen?

Ja das wäre schön. Dann hätte ich das schon gemacht. Die Maschine an der ich arbeite kann leider nur "Schwenken".
Da fehlt wohl zumindest mal das 5-Achsen Paket. Leider. Das wird aber auch bei uns nicht wirklich gebraucht.
Ich interessiere mich halt nur so dafür.
   
Beitrag 07.12.2018, 10:07 Uhr
drakefighter
drakefighter
Level 3 = Community-Techniker
***
Gruppe: Mitglied
Mitglied seit: 29.05.2007
Beiträge: 281
@pbv0411

Spannendes Thema
Ich kämpfe da auch gerade mit der Einarbeitung.

du schreibst:
"Mit Ausnahme der Radien ist dies also quasi das Gegenstück zu der in den Dokumentationen oft als Beispiel herangezogenen Tasche mit schrägen Wänden. "

Nicht ganz:
In dem Beispiel werden die Schrägen mit einfach angestelltem Werkzeug gefräst. Die Umorientierung findet in den (Radien) Kegeln statt.
Schau dir mal das Drahtmodell der Tasche in der Dokumentation genau an.

Du möchtest das Werkzeug stetig auf der Geradenfahrt umorientieren.
Ich habe für deinen Programmieransatz leider auch keine Lösung, lese aber gespannt mit und bin natürlich weiterhin gedanklich dabei.

Gruß Rainer
   
Beitrag 08.12.2018, 00:50 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
Hallo Rainer,

schön das sich noch jemand eingeklinkt!

Dein Einwand ist absolut richtig und mir war/ist dieser Sachverhalt auch klar.
Ich habe den Vergleich mit der Tasche auch eher herangezogen um erstmal die Geometrie meines Beispiels zu verdeutlichen.

Es gibt allerdings noch ein zweites Beispiel wo ORIAXES und ORIVECT gegenübergestellt werden (siehe Bild im Anhang).
Dort findet die Umorientierung auch kontinuierlich zwischen den Ecken statt.

In einem Versuch (siehe weiter oben) hatte ich mein Beispiel ja auch entsprechend abgeändert. Also ohne Radien an den Ecken.
Das merkwürdige Verhalten aber blieb bestehen, im Gegensatz zu der Darstellung auf dem angefügten Bild.

Wenn es nur so ginge wie in dem Beispiel welches Du ansprichst (parallele Richtungsvektoren am Anfang und Ende einer Seite),
dann wäre das alles ja wenig spektakulär. Findest Du nicht?

Ich denke wirklich, dass hier ein Problem mit meiner benutzen SinuTrain Version vorliegt.

Gruß Axel
Angehängte Datei(en)
Angehängte Datei  AndereTasche.jpg ( 180.63KB ) Anzahl der Downloads: 40
 
   
Beitrag 08.12.2018, 10:01 Uhr
drakefighter
drakefighter
Level 3 = Community-Techniker
***
Gruppe: Mitglied
Mitglied seit: 29.05.2007
Beiträge: 281
Hi Alex

Gibt es zu dem neu abgebildeten Beispiel auch den Programmcode?

Würd ich gerne mal nachprogrammieren.

Gruß Rainer

PS: du hast eine PN


QUOTE (pbv0411 @ 08.12.2018, 01:50 Uhr) *
Hallo Rainer,

schön das sich noch jemand eingeklinkt!

Dein Einwand ist absolut richtig und mir war/ist dieser Sachverhalt auch klar.
Ich habe den Vergleich mit der Tasche auch eher herangezogen um erstmal die Geometrie meines Beispiels zu verdeutlichen.

Es gibt allerdings noch ein zweites Beispiel wo ORIAXES und ORIVECT gegenübergestellt werden (siehe Bild im Anhang).
Dort findet die Umorientierung auch kontinuierlich zwischen den Ecken statt.

In einem Versuch (siehe weiter oben) hatte ich mein Beispiel ja auch entsprechend abgeändert. Also ohne Radien an den Ecken.
Das merkwürdige Verhalten aber blieb bestehen, im Gegensatz zu der Darstellung auf dem angefügten Bild.

Wenn es nur so ginge wie in dem Beispiel welches Du ansprichst (parallele Richtungsvektoren am Anfang und Ende einer Seite),
dann wäre das alles ja wenig spektakulär. Findest Du nicht?

Ich denke wirklich, dass hier ein Problem mit meiner benutzen SinuTrain Version vorliegt.

Gruß Axel
   
Beitrag 08.12.2018, 16:24 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
Ich habe eine Personalnummer?

Scherz beiseite...inzwischen glaube ich zu wissen was damit gemeint ist.

QUOTE
Gibt es zu dem neu abgebildeten Beispiel auch den Programmcode?

Leider nein.
Das ist aus so einer typischen "powerpointmässigen" Präsentation die nur einen kurzen Überblick über das Thema "Dynamische 5-Achsbearbeitung" gibt. Hier der Link (ich hoffe das ist hier zulässig): Dynamische-5-Achsbearbeitung
   
Beitrag 14.12.2018, 15:49 Uhr
drakefighter
drakefighter
Level 3 = Community-Techniker
***
Gruppe: Mitglied
Mitglied seit: 29.05.2007
Beiträge: 281
Ich hab das ganze im Sinutrain und an der Maschine nachprogrammiert.

Auch bei mir sieht es so aus als ob oriaxes am Werk ist. Anfangs- und Endorientierung passen.

Ich habe die lange Gerade mal in viele Inkremente zerlegt, die Zwischenorientierung berechnet,
dieselbige angefahren und das ganze in eine Schleife gepackt.

Im Ergebnis siehts jetzt richtig gut aus. Die Fläserbahn liegt auf einer Ebene :-)

Rainer
   
Beitrag 14.12.2018, 22:16 Uhr
pbv0411
pbv0411
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 25.11.2018
Beiträge: 23
Hallo Rainer.

"Tricksen" gilt nicht! smile.gif Na ja, ist aber auch manchmal ein Weg um ans Ziel zu kommen.

Ich hatte sowas auch schon mal probiert. Ebenfalls an der langen Seite, allerdings mit nur drei "Stützstellen" zwischen den Radien.
Somit ist die lange Seite in vier "Felder" unterteilt. Aber schon dabei sieht die Sache recht gut aus.
Wenn man allerdings genauer hinsieht, so erkennt man, dass auch hier die einzelnen Felder auch nicht wirklich eben,
sondern weiterhin alle etwas nach nach innen gewölbt sind. Wenn man nun sehr viele Stützstellen bzw. Felder erzeugt,
so wird man irgenwann wohl nichts mehr erkennen können, besonders in der Grafik nicht.
Dennoch werden die einzelnen Teilstücke dadurch nicht eben werden.

Daneben ist dieser Weg natürlich auch nicht das, was ich mir durch ORIVECT erhofft hatte.

Gruß Axel
   
1 Besucher lesen dieses Thema (Gäste: 1)
0 Mitglieder: