QUOTE (HolgiT @ 22.11.2019, 01:12 Uhr)
...
@Thomas_W: Also ich finde es garnicht so schlimm, wenn es nicht für jeden Kram einen Zyklus gibt. Wenn man noch ein bißchen selber das Hirn anstrengen kann, rostet es auch nicht ein.
...
Der Vorschlag von Schwindel ist doch nicht schlecht. Und es reicht doch, wenn es nur für die Anwendung von eisenhans75 genügt. Warum muß das dann gleich Universal für alles sein.
Wenn man sich damit ein wenig beschäftigt, kann man das Programm für sich selbst ja noch modifizieren,
Servus!
Ja ich sehe das ähnlich. Ich finde ebenso, dass man seine Hirnaktivität nicht vernachlässigen soll. Allerdings kommen solche Sachen eben einerseits nicht so häufig vor, dass einem spontan immer Alles dazu sofort einfällt und das ist ja nicht das Einzige, woran man so verzweifeln kann. Man muss auch dran denken, dass es viele Kollegen gibt, die "aus dem Alter raus" sind Experimente zu machen und Andere schlicht nicht durchsteigen bei sowas. Die Maschine muss am Laufen gehalten werden und wenn ich dann daste'h und erstmal in Unterlagen rumsuchen oder mir "mal eben" Irgendwas aus dem Finger ziehen muss, steht die Kiste und produziert keinen Monatslohn. Die Spindel muss sich dreh'n für's Geld und man kommt oft nicht wirklich dazu Laufzeiten zum Programmieren zu nutzen (jedenfalls bei mir) da muss man schon fix dabei sein, abgesehen davon, dass sowas auch ganz böse nach hinten los geh'n kann. Daher auch mein Vorschlag mit nem Universalprogramm oder eben offiziellen Zyklus.
Wie gesagt so ein Radius oder ne Fase ist da noch was recht einfaches, solange das gleichmäßig und geradlinig ist oder meinetwegen noch ne einfache Kontur. Gerade da ist ein Zyklus eigentlich Gold wert, weil man sich dann eben nicht mehr wegen sonem Kram aufhalten und "riesige Programme" schreiben muss, anstatt einen Zyklus zu definieren und aufzurufen mit 2 Einzelsätzen oder mit PGM CALL ein Zyklusähnliches Universalprogramm. Dann bleibt das Hirn auch freier für komplexeres Zeug, das Programm bleibt übersichtlicher und andere Kollegen verstehen die Sachlage besser/schneller.
Der Vorschlag von Schwindl ist auch prizipiell super, hat keiner was Anderes behauptet. Mich persönlich stört nur Einiges in diesem Portal, weils da zbsp. keine wirkliche Struktur in der Parameterbelegung gibt. Es ist zwar immer schön erklärt aber eben bei jedem PGM völlig anders. Wie gesagt in dem einen ist Q1 Dies, in nem Anderen Jenes usw. da musste immer hoch und runterschaun was jetzt was war und was mit was gerechnet wird und immer wieder steh ich da und raff nicht mehr was jetzt Q14 gemacht hat, weils eben einfach random als Q14 gesetzt ist und nicht weil Q14 eben immer bsp. ein Winkel im Bezug Bearbeitungsebe oder eine Richtung ist. Ich mag dieses System halt nicht, deswegen die "Aufregerei" in dem Post.
eisenhans75 wollte die Nut in Längsrichtung (X) abarbeiten und nicht mit Halbkreisbewegungen in YZ. Daher ist Dein genanntes Beispiel zwar grundsätzlich für's Verständnis hilfreich, aber eben nicht für das Vorhaben des Kollegen. Somal das so ohne andere wichtige Angaben auch bedingt/garnicht funktioniert und das
Koordinatensystem falsch ist, wenn ich das richtig aus der Zkizze und dem Eingangstext interpretiert hab.
QUOTE (HolgiT @ 22.11.2019, 01:12 Uhr)
Die können aber noch kein DR/DL im TOOL CALL Satz. Kann man aber einfach mit einer NPV in Z lösen.
Eben nicht, da der Bezug für die Kontur der Mittelpunkt des Radius vom Werkzeug sein muss, sonst verfälscht sich das Ergebnis. Entweder das Werkzeug auf Kugelmitte vermessen und so eintragen oder auf Spitze vermessen und DL-Kugelradius. Wenn Du ganz normal eine Kontur seitlich mit einem
Schaftfräser abwalzt und die Korrektur selber rechnest, musste auch den Werkzeugradius drauf- bzw wegrechnen. Ist das selbe Prinzip nur in Spindelachse, nicht 90° dazu. Bei nem Torusfräser wird's noch lustiger oder wenn man Kantenschutzfasen wegrechnen muss.
Bin mal gespannt ob's funktionert. Am Montag rechne ich mal mit ner Erfolgs/Fehlermeldung vom eisenhans75.
Grüße