DeutschEnglish

woodWOP Forum – Archive

This is the woodWOP Forum Archive.

You can search for archive posts by the Forum Search.

Please post new posts at forum.homag.com.

If you want to respond to an old post, just copy the text into the new forum and respond there. 

Your HOMAG Forum Team

3D-Werkzeugmodelle variabel


Author Message
Written on: 18. 04. 2011 [15:50]
tassilo
Topic creator
registered since: 18.10.2006
Posts: 94
Hallo zusammen,
um im Woodmotion exakt simulieren zu können, müssen die Werkzeugmodelle exakt den Werkzeugdaten entsprechen. Bei normalen Schaftfräseren ist das kein Problem, funktiuoniert hier automatisch.
Unklar ist jedoch, wie das bei Kugelfräser funktionieren kann. Es muss eine variable Konturzugsbeschreibung geben, die die Werkzeugdaten aus der Datenbank so ausliest, dass der Fräser beim Simulieren naturgetreu erscheint.
Die mitgelieferten Konturzugsdateien Profil_Kugel1.ktr, Profil_Kugel2.ktr und Profil_Kugel3.ktr liefern nicht das gewünschte Ergebnis (die WZ-Länge wird zwar verarbeitet, aber der Kugeldurchmesser stimmt nicht).
Hat jemand schon eine variable Konturzugsdatei für Kugelfräser oder andere Profilfräser erstellt?
Gruß
Tassilo
Written on: 20. 04. 2011 [07:31]
holzking
registered since: 14.09.2006
Posts: 230
Hallo Tassilo,

es gibt keine Möglichkeit, variable Konturzugdateien für woodMotion anzulegen, sodass die Daten aus der Werkzeugdatenbank übernommen werden. Nur die vertikalen Fräser, die Bohrer und die Sägen werden automatisch aus den Daten der Werkzeugdatenbank generiert.
Was man machen kann ist eine variable Kontur in woodWOP anzulegen, dann die Variablenwerte eingeben, dann den ktr-Export machen. Diese ktr ist dann halt nicht mehr variabel aber auf diese Weise kann man schnell Varianten eines Werkzeugs anlegen.

Grüße holzking
Written on: 20. 04. 2011 [08:12]
tassilo
Topic creator
registered since: 18.10.2006
Posts: 94
Hallo Holzking,
danke für den Tipp. Ich denke, ich werde mir die Arbeit machen müssen und Einzel- ktrs über eine variable mpr erzeugen.
Technisch sollte es aber für Homag kein großes Problem sein, hier eine rationelle Lösung zu schaffen. Die WZ-Daten wurden ja schon mal eingegeben und sollten dann für die WZ-Modelle automatisch auslesbar sein. Dann könnte man sich diese manuelle Sisyphus-Arbeit sparen. Wichtig auch vor dem Hintergrund, dass sich die Werkzeugdaten durch Nachschärfen verändern.
Werde mal das Problem bei Homag auf der Ligna ansprechen..
Gruß Tassilo
Written on: 24. 04. 2011 [12:58]
3d-holzdesignpunktde
registered since: 12.12.2006
Posts: 180
Hallo Tassilo,


Wie ich in einem anderen Thread von Dir entnehmen konnte arbeitest Du mit MasterCAM. Es verwundert mich in diesem Augenblick, dass Du dann mit WoodMotion simulierst, da Dir dein CAM diese Möglichkeit auch bietet und dabei weniger Datenpflege notwendig ist als im WoodMotion, - und vor allem bei größeren Programmen auch nicht so schnell in die Knie geht..... In MasterCAM muss hierzu die Simulation allerdings separat angelegt werden (mit deinen 3D-Maschinendaten, Achsverfahrwegen). Auch wenn dieser Weg jetzt nicht den CNC-Kern simuliert, so ist es meine Erfahrung, dass auf das Simulieren mit hoher Wahrscheinlichkeit Verlass ist..... -zumal tats. alle Arten von Fräsern, Haltern, Ausspannlänge, Schneidenlänge... so berücksichtigt werden, wie Du sie bereits in MasterCAM angelegt hast.- spart also schon mal doppelte Datenpflege. "Geschlossen" habe ich den Kreislauf des Datenflusses über den "Werkzeugorganizer", -ein Tool, das die an der Maschine angelegten Werkzeugdaten stets abholt und die Daten für MasterCAM entsprechend auch aufbereitet.....- Somit stimmt deine dortige Simulation immer, weil tats. mit den aktuellen Werkzeugdaten auch simuliert wird. Eine Simulation ist nur dann sinnvoll, wenn die WZ-Daten auch tats. real sind.
Kürzlich hatte ich beispielsweise auch ein Werkstück zu positionieren, dass von verschiedenen Seiten eine Berabeitung erhielt und zudem recht groß war. Ich konnte somit vor dem Einschalten der Maschine genau austesten, mit welchem Versatz ich arbeiten muss, damit die Maschine während des Programmlaufs aufgrund nicht ausreichenden Verfahrwegs zum Stehen kommt....- das habe ich dann auch real abgeglichen und es passte auf 2/10mm genau, bis ich auch an der Maschine eine Meldung bekommen habe, dass nun der Verfahrweg nicht mehr reicht.....-Und auch diese 2/10mm lassen sich erklären: es war die hinterlegte Simulationstolanz......-der wohl beste Beweis, dass Simulation schlichtweg immer und ausschließlich mit komplett realen Werkzeugdaten stattfinden muss.....(und auch kann....) icon_cool.gif

visit us @
www.3D-Holzdesign.de
Facebook
Youtube
Written on: 04. 05. 2011 [14:45]
tassilo
Topic creator
registered since: 18.10.2006
Posts: 94
Hallo 3d-holzdesignpunktde,
Du hast recht, es ist sicher ein Vorteil, nur eine Datenbank zu pflegen und sich dann eben auf die Simulation im MasterCam zu verlassen. Allerdings ist hier immer zu bedenken, dass auch nur die Daten von MasterCam zum Simulieren herangezogen werden und zwar vor dem Posten, also nicht das WoodWop-Programm und auch nicht das eigentliche CNC-Maschinen-Programm. Dieses aber wird in WoodMotion simuliert auf der Basis der realen Maschinen-Steuerung. Somit ist die Simularion sehr nahe an der Realität, auch wenn sie evt. einiges an Zeit in Anspruch nimmt.
Da wir einen Kardan-5Achs-Kopf haben, zeigt sich manchmal erst im WoodMotion, ob das von MasterCam erzeugte Programm auch tatsächlich an der Maschine ablauffähig ist. MasterCam erkennt nicht, ob ich mit meinem Kardankopf den C-Achsen Spielraum ausgeschöpft habe und dann gegen den C-Achsen-Endschalter fahre. MasterCam kennt nicht den Algorythmus für das Zusammenspiel von A- und C-Achse, sodass es erst kurz vor der Endlage einen Retract einbaut.
Ein weitereres Argument für WoodMotuion ist die Vorherberechnung der Bearbeitungszeit, die eingermaßen auch stimmt.
Written on: 08. 05. 2011 [21:19]
3d-holzdesignpunktde
registered since: 12.12.2006
Posts: 180
Hallo Tassilo,

auch ich poste die Daten bei der MC-MaschinenSimu in den G-Code. Somit wird gewährleistet, dass auch ein C-Achsen-Ausdrehen sowie spezifische Maschineneigenheiten entsprechend berücksichtigt werden. Von der Problematik kardan. Kopf und der sich daraus unterschiedlich resultierenden machbaren C-Winkeln habe ich bereits gehört....Um jetzt auch diese Abhängigkeit in MC simulieren zu können muss eben seitens Homag die Berechnungsgrundlage hierfür bereitgestellt werden. EInen ausgereizte Maschinenanbindung kann immer nur so gut sein, wie die Gegebenheiten der Maschine abgefangen werden können. Wenn jetzt also das Verdrehen der C-Achse aufgrund des kard. Kopfes schwankt, dann muss diese dahinterstehende Berechnugsgrundlage ohne wenn und aber an die Fremdsoftwarehäuser weitergegeben werden!!! Denn auch wenn Du jetzt deine geposteten Daten jetzt durch WoodMotion jagst.....-dann hast Du letztenlich nur die Erkennnis vor dem Fräsen darüber, dass es wohl nicht ausreichen wird. Ändern kann die Software dein mpr auch nicht mehr. Was liegt da also näher, bereits beim Posten diese Berechungsgrundlage einzubauen, so dass Du im Grunde gar nicht mehr groß darüber nachdenken musst, ob das Verdrehen der C-Achse noch ausreicht????? Ich finde solche Gegebenheiten dürfen nur dann real an der Maschine verbaut werden, wenn man eine Berechnungsgrundlage für Fremdsoftwareanbieter bereitstellen kann. Ansonsten ist von vornherein eine rationelle Programmierung der Maschinen behindert.....-kann das im Sinne des Herstellers sein? :doubt:

visit us @
www.3D-Holzdesign.de
Facebook
Youtube
Written on: 09. 05. 2011 [07:58]
holzking
registered since: 14.09.2006
Posts: 230
Hallo 3d-holzdesignpunktde,

was hat der Maschinenhersteller damit zu tun, wenn irgend ein separates CAD/CAM System den Drehbereich der C-Achse nicht überwachen kann?
Meiner Aufassung nach bietet HOMAG eine tolle Simulationssoftware, die vorallem ihre Stärke darin hat (und sich somit auch von den anderen Simulationen unterscheidet), dass sie direkt basierend auf den original Maschinendaten mit dem generierten Code simuliert.

Grüße holzking
Written on: 09. 05. 2011 [11:31]
tassilo
Topic creator
registered since: 18.10.2006
Posts: 94
Hallo 3d-holzdesignpunktde,
es gibt nichts, was man nicht besser machen kann. Aus der Sicht des Anwenders ist es natürlich ein Vorteil, gleich beim Posten die komplette Maschinenvertäglichkeit zu prüfen. Dabei ist es zunächst schon mal ein Fortschritt, mit WoodMotion ein Problem vor dem Produktionsablauf zu erkennen und nicht erst, wenn die Maschine stehen bleibt..
Dennoch, eine Simultion mit WoodMotion liefert mtr zudem auch noch eine Kollisionskontrolle (Fräser-Sauger), die ich im MC nicht habe. Alles in allem sehe ich mich hier auf der sichereren Seite, auch wenn es etwas länger dauert.
Gruß Tassilo
Written on: 09. 05. 2011 [16:27]
3d-holzdesignpunktde
registered since: 12.12.2006
Posts: 180
@holzking:

was hat der Maschinenhersteller damit zu tun, wenn irgend ein separates CAD/CAM System den Drehbereich der C-Achse nicht überwachen kann


So kann man das natürlich auch sehen..... icon_mad.gif . wenn ich aber damit Geld verdienen soll dann ändert sich hier jedoch die Sichtweise. Und das ist doch letztendlich der Sinn einer Investition.......(die bei CNC immerhin nicht wenig ist........)-den Rest habe ich bereits hier erläutert...-wenn das bei mir außerdem die Aussage bzw. das Verhalten des Maschinenherstellers gewesen wäre dann hätte ich wohl schnell gewechselt. Ohne ausgereiztem Zusammenspiel von Software & Maschine geht es schlichtweg nicht. Wie kommt man auf diese verwegene Meinung?
Damit wir hier uns nicht falsch verstehen: Ich finde auch, dass WoodMotion weit über den Standard liegt und sicher seine Dienste leistet....-aber wenn ich schon in Besitz eines CAD/CAM bin, dann sollte es auch Ziel sein, dies entsprechend mit all seinen Ressourcen zu nutzen- und vor allem Fehler bereits von vornherein umgehen.
Deine Aussage würde ja im Umkehrschluss bedeuten, dass sich letztendlich Software und Maschine sich unterschiedlich entwickeln dürfen. Genau das sollte doch weitgehend vermieden werden um letztendlich eine rationelle Programmierung zu gewährleisten. Tassilo muss also versuchsweise mit unterschiedl. Parametern etliche mal aus MC posten, bis er (aufgrund des kard. Kopfes = kein MasterCAM-Problem) in WoodMotion feststellt, dass bezüglich A/C-Winkel das Programm an der Maschine tats. durchläuft.... -"Lösen" tut ihm WoodMotion das Problem ja auch nicht! Unproduktiv lässt grüßen.....& sorry dass ich eben ausschweife aber in meinen Augen ist das ein absolutes NoGo.
Tassilo: auch die Sauger habe ich mittlerweile in der Simulation eingepflegt. Sofern man in MC das spezielle Saugertool hat werden in das mpr wie auch der maschinenspezifischen Simulation die Sauger mit eingepflegt....-derzeit allerdings erst in einer Größe.....-wir arbeiten daran,,,,-denn auch bei diesem Weg gibts Nichts, was nicht noch zu verbessern wäre........
Letztenlich haben wir doch alle dasselbe Interesse: die Maschine möglichst rationell zur Bewegung zu bringen ohne eine Doktorarbeit hinlegen zu müssen......... icon_smile.gif

[This article was edited 1 times, at last 15.05.2011 at 10:23.]

visit us @
www.3D-Holzdesign.de
Facebook
Youtube
Written on: 11. 09. 2011 [15:37]
3d-holzdesignpunktde
registered since: 12.12.2006
Posts: 180
Auch wenn es sich nicht mehr direkt um das Urspungsthema handelt...
Hat ansonsten niemand mehr mit den schwankenden Ausdrehparametern beim kard. Kopf zu kämpfen?!? Kaum zu glauben, wenn man bedenkt, was letztlich doch an 5Achs-Maschinen anzutreffen ist.....icon_cool.gif
Und warum bekommt man hierfür keine Berechungsgrundlage, damit das in die Postläufe bereits miteingebaut werden kann?? Weil es vielleicht gar keine gibt und letztlich nur eine Meldung ausgespuckt wird, dass es nicht geht?!? Naja, - das kann ja wohl kaum eine Endlösung sein.....icon_frown.gif

visit us @
www.3D-Holzdesign.de
Facebook
Youtube



RSS-FEED:

Portal information:

At the moment there are 0 users online, thereof 0 registered users and 0 guests.
Today 0 registered users and 0 guests were already online.

Now online


weeke-training.com has 6257 registered user, 1536 topics and 7910 answers. On average 1.58 posts are written per day.