GCode Programmierung für 3D in C++, Ein Projekt

Kann ich grade nicht. Die Mühle ist beschäftigt.



Möglich. Natürlich kannst auf einem Kreisbogen mit Radius R von einem Startpunkt zu einem Endpunkt fahren, solange beide Punkte nicht weiter als 2xR voneinander entfernt liegen. Aber die Bewegung bleibt trotzdem ein Kreisbogen, evtl. um ein Zentrum das außerhalb der Kegelachse liegt. Gibst du hingegen - am Startpunkt stehend - ein Zentrum und den Endpunkt an, dann müssen Start- und Endpunkt den gleichen Abstand zu diesem Zentrum haben. Andernfalls kommt dieser Kreisendpunktfehler anstatt einer Spiralinterpolation.
So isses zumindest bei den Steuerungen, die ich kenne.

Oisklaa?

Gruß,

Clemens

Dieser Befehl:

g91
g2 x-90 i-40 z1
g90

der das Problem klarer sichtbar macht als der völlig identische G90 Befehl (Wie oben angeführt) wird von meiner Steuerung exakt richtig interpretiert, wie es der G-Code vorschreibt.

Der Radius von 40 wird während des ganzen Verfahrweges niemals erreicht, er bemüht sich nur, dahinzukommen, und daher haben wir es hier nicht mit einem KReisbogen zu tun

sondern mit einem sich auf den Zielwert i-40 verengenden Kreisbogen.

Darauf muß ich, weil das sachlich so richtig ist und nicht anders, leider bestehen.

Möglicherweise unterlaufen auch Profis gelegentlich Denkfehler.



Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 19:42 Uhr

Hab's nun gerade mal auf meinem Heidenhain-Programmierplatz ausprobiert.
ISO-Code an der Steuerung zu programmieren war für mich ungewohnt und auch etwas ein Blindflug, weil ich keine geeignete (Vorsatz-)Tastatur dafür habe. Alle Kreise habe ich mit der (Klartext-)Taste "CC" erzeugt. Was sich darunter im ISO-Modus verbirgt, weiß der Geier.



Die Steuerung frißt das tatsächlich, fährt aber Kreisbögen vom Start- zum Zielpunkt und ignoriert den mit I und J fest vorgegeben Mittelpunkt. Anfangs stand in allen Sätzen R50, da konnte man das klar erkennen.
Probier mal an deiner Steuerung in deinem G91-Satz statt I40, was ja offenbar der Radius sein soll, I500 einzugeben. Nach deiner Auffassung sollte das ja wurscht sein, da ein 500er Radius genau so wenig da rein paßt wie ein 40er.

Gruß,

Clemens

Hallo Camtool,

ganz ehrlich gesagt, der Code von deiner Heidenhain, das sind böhmische Dörfer. Versteh ich echt nur Bahnhof.

Ich kann mich da auch nicht einarbeiten, wenn ich sowas nicht auf dem Bildschirm habe.

Wie man allerdings mit stinknormalen GBefehlen die Helix hinkriegt, um einen Kegel zu fräsen, dazu hätte ich eine vorläufige Idee (die könnte aber auch falsch sein).

Wir machen das mal stufenweise in G91. Abgeleitet von der HÖhenzustellung Rampe:

Wollen wir eine Rampe von z 1, müssen wir die Höhenzustellung gleichmäßig verteilen auf den unteren Halbkreis von z0.5, und im oberen Halbkreis wieder 0.5 fahren, macht am Ende 1mm. So:

g2 x-100 i-50 z0.5 (Unten herum)
g2 x100 i50 z0.5 (inremental z+0.5 = insgesamt z=1)
Wir sind dann um den Turmbau zu Babel mit einer Rampe herumgefahren.

Für die nächste Bahn wird es dann ernst, z bleibt konstant, aber wir wollen x aufteilen. Wir wollen den x-Versatz so aufteilen, daß wir erstens genau auf dem Mittelpunkt bleiben, also keinen Versatz vom Kegel haben, und zweitens, daß wir den x-Versatz gleichmäßig auf den KReisbogen aufteilen.

X soll jetzt nur zum Beispiel 20 kleiner werden, i demnach -10.

DANN BLEIBT ANALOG ZU Z-ZUSTELLUNG ALS LEITGEDANKE, daß wir x ebenfalls nochmal halbieren, also auf den einen Kreisbogen x-10 abziehen, und bei i 5 abziehen, und auf dem Rückweg wieder x-10 abziehen und i-5, macht dann:

g2 x-90 i-45 z0.5

Und zurückfahren mit

g2 x80 i40 z0.5

SO ÄHNLICH schwebt es mir im Hinterkopf. Ob das so tickt oder da ein Denkfeherl drin liegt, muß ich morgen mal auf der Steuerung nachsehen.

Wie gesagt der Grundgedanke ist, wie in Z die Rampe gleichmäßig auf den ganzen Kreisbogen verteilen, diesmal in x.

Dann hätten wir, völlig unabhängig ob man es in G90 oder g91 formuliert, eine völlig homogene Oberfläche.

HOMOGENE Oberfläche, das ist das strategische Ziel.




Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 21:32 Uhr

oder anders ausgedrückt:


Find' ich gut, deine Idee!

Machen wir es kurz:

Ich hab die perfekte Helix entdeckt.

Ganz ohne C!

Sondern im G-Code. Ich muß den Glöckner von Notre Dame um Verzeihung bitten. Sieht ein bißchen schrecklich aus, ist aber ein liebes Mensch. Glöckner, das hätte ich dir nicht zugetraut, ich hab dich unterschätzt!

Bevor wir C programmieren müssen wir ja erstmal logisch denken.

Also es geht so:

G91 (mein liebster Code, kann man natürlich in Offset umwandeln G90)

g2 x-100 i-50 z0.5 (Unterer Kreisbogen)
g2 x98 i49 z0.5 (zurück nicht als Kreisbogen sondern mit Verengung gleichzeitig z nicht vergessen)
g2 x-96 i-48 z0.5 (wieder nach 9 Uhr wieder weiter verengen, wir laufen zu jeder Zeit in allen Achsen Helix )
g2 x94 i-47 z0.5

Wir schrauben uns um den Kegel in 3 D herum! :doch:

Bei einer HELIX GIBT ES KEINE KREISBÖGEN!

Wir sind ständig in der Schräge, in x und in z!

Wir arbeiten nicht mit Kreisbögen, sondern NUR NOCH MIT SICH VERENGENDEN KREISBÖGEN!

WÜrden wir mit Kreisbögen fahren, könnten wir keine Helix fahren!

Wir fahren ständig Helix=Schnecke.

KREISBOGEN =2D, wir sind aber in 3 D!!!!!!!!!!!!!!


:doch:

Wir müssen umdenken von 2 D auf 3 D, das muß rein in die Birne!

KOMMT EINE VÖLLIG HOMOGENE OBERFLÄCHE BEI HERAUS.

Jedenfalls die Kopie meiner Steuerung die ich ja hier auf dem PC liegen habe, sagt mir:

Sharky, also in xy hast du dabei keinen Versatz. Das ist o.k. So wird das laufen kannst du demnächst programmieren.

Wollen wir mal hoffen, daß es auch so ist.




Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 22:13 Uhr

Frage wär, ob man bei der perfekten Helix noch an der Relation von x und i herumschrauben muß.

Das wäre möglich, nach dem Beispiel weiter oben.

Aber erstmal sind wir so am Ball.

Feinheiten dann im Anschluß.

Beim Programmieren:

Erstmal probieren, und dann programmieren!

Also bei dieser Sache glaube ich, daß ich auf der richtigen Spur bin.

Und das in G-Code!

Unfaßbar!

Was hab ich für schlimme Dinge über den Glöckner gesagt! Glöcker ist ein liebes Mensch, werde ich niemals mehr drüber lästern! Denn nicht nur daß der ein liebes Mensch ist, der hat auch was drauf!

Wie gesagt unfaßbar!

Mit einfachen G-Befehlen eine perfekte Helix!

Ist jetzt nur ein Gedanke aber wenn es so geht, dann hat der G-code bei mir einen dicken stein im Brett.




:doch:

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 22:24 Uhr

Ich bin jetzt so völlig hin und weg, dieser Beitrag muß sein:

Wenn wir Helix fahren, können wir ja nicht erwarten, daß wir gleiche Kreisbögen fahren.

Helix in xy Ebene gesehen, ist eine ständig sich verengende Schraube, jeder Befehl von gleichen kreisbögen wäre da völlig verkehrt!!!!

:doch:

Gleichzeitig schrauben wir uns in z Hoch. Man muß mal sehen, daß diese Schraube in z und in x genau koordiniert wird, nach den physikalischen Daten wird das aber der Fall sein, wir haben ja die Höhenzustellung schon berechnet.

Das MUSS PASSEN!


Und der Glöckner macht uns die rampe! Wenn wir sagen: mach die Rampe in zwei Teilstrecken 180 Grad in z, macht er das, warum soll er dann nicht die rampe in zwei Teilstrecken 180 Grad in x machen? Macht er natürlich auch.

MEIN LIEBER GLÖCKNER,

könnte man sagen,

anstatt mein lieber Scholli,

hier geht das ja mittlerweile wirlich gut ab!

Hallo

@ sharky
Wie cam-tool schon geschrieben hatte, würde ich auch den Kegel von Oben bearbeiten. Den Grund hat er ja auch schon genannt: der Schnittdruck kann die Spitze wegdrücken.

Zu deiner Frage wegen der evtl. sichtbaren Struktur auf der Oberfläche. Diese Facettierung kommt auch bei den "Profis" immer wieder mal vor. Dann muss man unter anderem die Verhältnisse zwischen Vorschub und Drehzahl ändern. Nur durch das ändern der Bahnabstände wird das Muster zwar verändert, aber es wird immer sichtbar bleiben. Aber da brauchen auch die Profis teilweise den einen oder anderen Versuch, bis die Oberfläche den Sichtansprüchen genügt. Ansonsten bleibt da nur eine Nacharbeit.

Zu den angesprochenen Problemen mit den Kreismittelpunkten.
Wenn der angegebene Endpunkt mit den Daten des Mittelpunktes vom letzten Punkt nicht passt, wird jede Steuerung die Fehlermeldung bringen, dass die Kreisendpunkte nicht passen. Sollte die bei deiner Steuerung anders sein, so ist dieses Verhalten als Fehlerhaft zu betrachten.
Beim Versuch von cam-tool auf der Heidenhain ist wahrscheinlichst einfach die Steuerung vom angegebenen Radius ausgegangen und hat einen der anderen dann überflüssigen Werte einfach überlesen. Denn mit Endpunkt, Mittelpunkt und Radiusangabe war die Bahn überbestimmt. Damit kann die Steuerung meiner Meinung nach quasi die dann falsche Angabe überlesen.
Allerdings hat cam-tool es schon gesagt. Bei einer G2/G3- oder Radius-Anweisung kommt immer ein Kreisbogen heraus, denn nur dafür stehen diese Befehle. Die gleichzeitige Bewegung in der dritten Achse (hier Z) ändert daran meiner Meinung gar nichts, da man immer noch einen genauen Kreisbogen fährt, welcher dann nur nicht mehr genau in einer Ebene (zwei Achsen) liegt.


Ich werd dir das mal ein bisschen vereinfachen:
%spiral G71 *
Programmzeichen (%), Programmname (spiral) und die Angabe, ob das Programm in MM (G71) oder in Inch (G70) ist.
N10 G30 G17 X-60 Y-60 Z-20*
G17-Ebene und der erste Punkt (mit G30) des Rohteiles für die Simulation; vorne links unten
N20 G31 X+60 Y+60 Z+0*
zweiter Punkt des Rohteiles; hinten rechts oben. Hier kann auch noch ein G90 oder ein G91 stehen zur Vorauswahl ob überwiegend Absolut oder Inkremental programmiert werden soll.
N30 G99 T1 L+0 R+3*
Definition des Werkzeuges mit Werkzeugnummer, Länge und Radius
N30 T1 G17 S1000 F500 DL+0 DR+3*
Werkzeugaufruf, Ebenenanwahl, Drehzahl, Vorschub, extra Längen- und Radiuskorrektur. Damit kann man diese Werte des Werkzeuges auf eine einfache Art anpassen/ändern, um z.B. ein bestimmtes Aufmass manuell zu ändern.
N40 G90*
Angabe, das Absolut programmiert wird
N40 G01 X+0 Y+50 G40 F500 M3*
Verfahren sollte klar sein, keine Radiuskorrektur (G40) , Vorschub und Drehrichtung des Werkzeuges
N50 G01 Z-10*
N60 G03 X-45 Y+0 R+50 I+0 J+0 F500*
N70 G03 X+0 Y-40 R+45 I+0 J+0*
N80 G03 X+35 Y+0 R+40 I+0 J+0*
N90 G03 X+0 Y+30 R+35 I+0 J+0*
Diese Verfahrsätze sollten klar sein
N99999999 %spiral G71 *
Programmende, Rest wie Programmanfang

Bei jeder Steuerung gibt es andere Befehle als G-Code. Teilweise ändern die sich sogar noch mit evtl. gekauften Optionen
Nur ein kleiner Teil bleibt dabei gleich. Und auch da kann es Unterschiede geben. Z.B. bei G2/G3: fast alle Steuerungen wollen den Mittelpunkt Inkremental vom letzten Endpunkt aus, einige aber Absolut vom Werkstücknullpunkt. Kommt aber teilweise auch auf die Voreinstellungen in den Maschinenparametern an. Und dann hat man fast immer die Möglichkeit, einzelnen Achsbefehle entweder als Absolut oder als Inkremental anzugeben, unabhängig vom Rest des Satzes.

Gruß Gerd

Gekufi:

du kommst zu spät!

Das Problem der perfekten Helix wurde gerade eben gelöst, ganz ohne Heidenhain. Trotzdem danke, daß du dir die Mühe gegeben hast, das Chinesisch zu übersetzen!

Die perfekte Helix ist ganz ohne Heidenhain in Arbeit, heute abend nicht mehr, aber man wird sehen.

Und du glaubst nicht, wer mir dabei geholfen hat:

Der Glöckner.

Über den denke ich seit heute Abend ganz anders!


DENN: Das Problem läßt sich mit ganz stinknormalem G-Code lösen. Unfaßbar, wenn es denn wahr ist.

Was noch zu klären wäre, ob man an i oder j noch herumschrauben müßte. Muß ich mal in Ruhe drüber nachdenken.


Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 22:59 Uhr

Hallo


In deinen Beispielen fährst Du die Helix als eine Aneinanderreihung von Kreisbögen. Das kannst Du drehen und wenden wie Du willst. Deine einzelnen Verfahrbefehle sind und bleiben Kreisbögen. Nur in der Summe ergibt sich eine spiralförmig gefahrene Helix.


Ein einzelner Kreisbogen kann sich nicht verengen, dies geschieht immer nur bei vielen Kreisbögen im Gesamten, indem man den Mittelpunkt oder Radius entsprechend anpasst/versetzt. Es spielt dabei auch die dritte Achse keine Rolle. Der Kreisbogen liegt dann nur nicht mehr in einer Ebene (XY, XZ, YZ), sondern im Raum. Aber es bleibt ein Kreisbogen. Siehe Oben.


Dies werd ich jetzt mal so stehen lassen. Also Du siehst, man kann den G-Code doch brauchen und andere Lösungen sind auch nicht der Weisheit letzter Schluss

Gruß Gerd

[quote=gekufi,Samstag, 24.Januar 2009, 22:58 Uhr] Hallo
[/QUOTE]
In deinen Beispielen fährst Du die Helix als eine Aneinanderreihung von Kreisbögen. Das kannst Du drehen und wenden wie Du willst. Deine einzelnen Verfahrbefehle sind und bleiben Kreisbögen. Nur in der Summe ergibt sich eine spiralförmig gefahrene Helix.

[/QUOTE]

Gruß Gerd [/QUOTE]
Wenn das so wäre, müßte ich an i noch herumschrauben.

ICH WILL KEINE KREISBÖGEN FAHREN!

Muss morgen mal drüber nachdenken. Eine Möglickeit wäre, daß man i kleiner setzt als 1/2 x. Ist aber noch unausgegoren.

Bitte jetzt nicht auf irgendwas festnageln, ich bin n och am Nachdenken.

Aber ich bin mir sicher, daß das Problem IM PRINZIP gelöst ist.

Und, das kannst du so stehen lassen: nicht in C, sondern in G.

Natürlich könnte man es auch in C lösen (der war jetzt gemein, aber mußte sein)





Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 23:05 Uhr

Quelle Malheur!
Und welch wundersame Wandlung!

Stattdessen verdirbst du dir's grad mit einem möglichen Verbündeten, nämlich der Dr. Johannes Heidenhain GmbH. Die hat nämlich auch mal G-Code rumgenörgelt und über eine Alternative dazu nachgedacht.

Und nein, am Ende kam was anderes raus als C.

Hallo


Dann kannst Du G2/G3 vergessen, denn diese Befehle sind für einzelne Kreisbögen. Deshalb geben bei einer spiralförmigen Helix meines Wissens nach alle CAM-Systeme die Verfahrbewegungen als viele und kurze G1-Befehle aus.


Äh, der Wert von I errechnet sich genau betrachtet immer aus dem Endpunkt des letzten Verfahrbefehles, dem gewünschten nächsten Endpunkt und dem gewünschten Radius, welcher verfahren werden soll. Der Wert von I (und auch J und K) kann von 0 bis max. Radius (auch im negativen) alle Werte annehmen, je nachdem wo der Mittelpunkt der Kreisbahn liegt. Der Abstand des Mittelpunktes vom letzten Punkt liegt genau beim Wert des Radius.
Er kann deshalb z.B. keinesfalls größer als der Radius sein, denn der Wert von I und J (K) ergibt sich aus dem Radius.

@ cam-tool

Sehr viel anders als der G-Code ist der Heidenhain Klartext jetzt auch nicht unbedingt aufgebaut. Die Befehle sind größtenteils anders, eben Klartext anstatt einem G mit Zahl. Aber der Grundaufbau bleibt meiner Meinung nach immer noch der gleiche.

Gruß Gerd

Der Beitrag wurde von gekufi bearbeitet: 24.01.2009, 23:20 Uhr

Kein Malheur, ich mache ja auch komplimente, wo sie hingehören.

Lieber Clemens,

mal ganz grundsätzlich:

ich bin ein kleiner Hobby-mensch mit einer baumarkt-maschine, wo ein bißchen CNC drangebaut ist. Gesamtpreis der Maschine incl. Steuerung und software = 6.500 Euro. Dafür kriegst du wahrscheinlich noch nicht mal eine neue Spindel eingebaut.

Bevor ich das Ding gekauft habe, wußte ich gar nicht mal, daß es so etwas gibt wie Heidenhain oder Fanuc. Heidenhain kannte ich nur vom HÖrensagen im Zusammenhang mit den Glasmaßstäben an den konventionellen Maschinen, was aber ja mit CNC wenig zu tun hat, und auch nur aus dem Ebay.

Mit CNC und Gcode hab ich im November 2008 den ersten Kontakt aufgebaut, in Verbindung mit dem Kauf der kleinen Fräsmaschine, bis dahin hatte ich in meinem Leben noch niemals was von einem G-Code gehört. Meine Kenntnisse der CNC-Szene sind bis heute rudimentär bis gar nicht vorhanden.

Also traue mir keine sachen zu, die für dich als Profi vielleicht selbstverständlich sind, insbesondere nicht als Motiv für irgendetwas!



Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 23:33 Uhr

Aber eines möchte ich noch hinzufügen:

So klein meine Maschine auch ist, es ist keine Portalfräsmaschine, sondern eine Säulenfräsmachine. Da können die Leute ja noch so lachen, ich betrachte diese kleine Maschine nicht als Witz, sondern als eine Maschine, mit der man Metall bearbeiten kann auf bis in die GEgend von 1/100 mm, je nachdem.

Und damit gehöre ich zu einer winzigen Minderheit, die sich das traut.

Das stört mich aber nicht weiter.

Ich denke, ich weiß schon so für meine Zwecke ziemlich genau, wozu das gut ist.

Und wenn hier in diesem Forum sofort das Etikett "Baumarkt" draufgepappt wurde, also da stehe ich völlig drüber.




Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 24.01.2009, 23:43 Uhr

Hallo


Alles nur eine Frage der Vorgehensweise und ob die Mechanik der Maschine das hergibt. Bei dir denke ich mal, dass ersteres auf jeden Fall gegeben ist (machst dir eine Menge Gedanken) und das Zweite nimmst Du auch nicht zu leichtfertig. Das hast Du ja in anderen Themen gezeigt, bei denen es um deine Hardware (die Maschine) und den Problemen damit ging.
Und die nötige Geduld scheinst Du meiner Meinung nach auch zu haben. Vor Problemen hast Du bis jetzt auf jeden Fall keinen großen Halt eingelegt, sondern Du bist zurück zur Kreuzung gegangen und nimmst eben einen anderen Weg.

Als angenehmer Nebeneffekt kommt mal wieder ein großes Thema in den Foren vor, welches auch noch lesenswert ist und so einige Dinge hinterfragt. Und für alle anderen ist es mindestens noch Unterhaltsam und teilweise auch recht lehrreich. Nicht nur auf die CNC-Technik bezogen (C-Code).

Gruß Gerd

Ja gekufi, du bist schon ein schlauer Mensch.

Ich möchte dir und Camtool mal ein Kompliment machen: ihr drückt euch zwar nicht immer so aus, daß man das direkt verstehen kann, aber das wirkt schon. Ich denke mal, eure Kommentare haben mich davon abgehalten, in eine Richtung zu laufen, wo das keinen Sinn macht.

Jedenfalls, das ganze Thema macht mir Spaß.

Und ich will auch sagen, wie ich es weiter sehe:

Wir wollen keine Kegel fräsen, wir brauchen keine kegel, bei der Gelegenhzeit haben wir aber den Code für die Bearbeitung von Schrägen.

Wir wollen keine Halbkugeln fräsen, aber wir haben bei der Gelegenheit den Code, um 90 Grad um die Kante zu gehen, und damit auch den Code, nur 70 Grad um die Kante zu gehen oder 45 Grad.

Es liegt da Potential drin. Schon bei dem bißchen, was bis jetzt realisiert wurde.


Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 00:34 Uhr

Lieber sharky,

mal ganz grundsätzlich:
Ich selbst besitze keinerlei CNC-Maschine, sondern mache nur CAD/CAM.
Ich hätte gerne eine für eigene Fräsversuche und um überhaupt etwas näher am Thema zu sein. Und noch lieber hätte ich eine professionelle Anwendung dafür, denn nur zum Spielen ist mir selbst die Baumarkt-Klasse entschieden zu teuer.

Im Übrigen habe ich großen Respekt davor, was du tust und wie du rangehst. Chapeau Monsieur! Andernfalls würde ich mich auch kaum so rege an diesem Thread beteiligen. Und in C bekäme ich selbst wohl mit Mühe gerade mal ein Programm hin, das "Hello World!" sagt.

Was mich jedoch stört, das ist dein ständiges Polemisieren gegen vorhandene oder frühere technische Methoden, Vorgehensweisen und Praktiken. Richtig ist, daß es keinen Fortschritt geben kann, wenn man nicht Kritik am Bestehenden übt. Fortschritt fußt also irgendwo auch auf Respektlosigkeit.
Richtig ist aber auch, daß jedes Ding seine Zeit hat, in der es unter den gegebenen Umständen die zweckmäßigste und naheliegendste Antwort auf ein bestehendes Problem darstellt oder dargestellt hat. Ich habe mal erlebt, wie sich zwei Maschinenbaustudenten halbtot gelacht haben, als sie zum ersten Mal einen Viertaktmotor aus den 20er Jahren mit offenliegenden Haarnadelventilfedern gesehen haben. Pimpfe! Rotärsche! Keine Ahnung von nix! Weder von den Schwingungs- und Kühlproblemen in der damaligen Zeit, noch von den Bedingungen, unter denen damals ein solch hochreiner Stahl geschmolzen wurde, wie man ihn für Ventilfedern benötigt. Die heutige Technik wäre mit damaligen Mitteln nicht funktionstüchtig herstellbar gewesen.
Natürlich sah Fortran alt aus, nachdem C erschienen war und natürlich ist C++ mittlerweile von Java überholt. Natürlich gehen mit der Zeit auch handwerkliche Fertigkeiten verschütt und natürlich gehen heutige Programmierer in Zeiten des massenhaft verfügbaren Speichers nicht mehr so sorgsam damit um, wie früher mit dem C64. Für doof halte ich die dennoch nicht. Wußtest du übrigens, daß wir es heute nicht mehr schaffen, mit den Mitteln von damals ein Kanonenrohr zu gießen, wie sie zu Zeiten Christoph Kolumbus' massenhaft hergestellt wurden. Wir bekommen's nicht mehr hin, trotz 500 Jahren Zugewinn an Wissen um Gießtechnik und Metallurgie.
Als Techniker tut man deshalb m.E. gut daran, allem Bestehenden und Gewesenen zunächst mal mit Achtung und Respekt zu begegnen. Erst mal besser machen, dann kann man kritisieren.

Ich persönlich achte übrigens auf genau diesen Punkt, um die Dampfplauderer von den Koryphäen zu unterscheiden. Wer wirklich was auf der Pfanne hat, der prahlt damit nicht rum.

Der G-Code steht oder stand übrigens wirklich auf der Abschußliste und sollte durch STEP ersetzt werden. Das Vorhaben liegt aber derzeit wieder auf Eis.

So, und nun, nachdem das geklärt ist, weiter im Text!


Gruß,

Clemens

Hallo Clemens,

kann ich so unterschreiben.

Ich bin zwar grundsätzlich jemand, der sich bemüht, den Ball flach zu halten, aber manchmal geht mein temperament mit mir durch. Außerdem neige ich zu Sarkasmen und englischem Humor, kommt bei manchen leuten auch nicht gut. Nicht mißverstehen!


Gruß Sharky



Also weiter im Text:

Ich hab mich da gestern abend in etwas verrrannt, und die Lösung heute nicht gefunden. Woran das liegt, keine Ahnung. Womöglich ist es der G2 Befehl, der verhindert, daß man eine echte Helix hinbekommt. Der hat zwar so im Anfahrbogen auf sich verringernde Radien einen Helix-Anteil, den kann man aber schlecht so auf die Kontur verteilen, daß tatsächlich ein geometrisch exakter Kegel entsteht.

Man könnte natürlich nun in C hingehen, und für sagen wir 6 Mio. Punkte im Kreisumfang eine Koordinate errechnen, die genau 1/6mio. von der gewünschten Zustellungsdifferenz weniger Radius hat als der Vorgänger. Nur das würde dann leider 6 Mio. G-Code Befehle ergeben für eine Helixbahn.

Nicht geometrisch wäre es, würde man versuchen, die Helix aus sagen wir mal 4 oder 12 Kreisauschnitten mit G2 so hinzukriegen, daß sich die Radien verringern. Es wären dann die segmente am fertigen Stück entweder zu sehen oder meßbar ungenau.

Es ist wahrscheinlich so, daß man solche Konturen besser mit einer Steuerung fertigt, welche die Koordinaten nicht als G-Befehle vorrätig hat, sondern sie zur Laufzeit, also live berechnet. Ich vermute, eine Haidenhein Steuerung macht das genau so, wenn sie Spirale fährt. Die wird wahrscheinlich von der Rechnenleistung völlig gleichwertig sein mit einem guten PC, womöglich sogar noch viel besser (obwohl mein Compiler die 6 Mio. Punte in 1 ms errechnet, also so viel besser geht dann gar nicht mehr).

Ich habe mir jetzt den Kopf zergrübelt und bin zu folgendem Algorithmus gelangt, den ich den Fachleuten zur gflln. Kenntnisnahme mal vorlegen möchte.

Man möge sich nicht dran stoßen, daß dieser Algorithmus mit der Hand sehr schwierig zu programmieren wäre. Das ist ja gerade der Vorteil einer Programmiersprache, daß man solche "Unhandlichkeiten" einmal eingibt und die Maschine dann davon beliebig viele Kopien erzeugen kann mit den gewünschten maßen.

Das hier ist reiner G-Code, von Hand eingetippt, und meine Steuerung meint, der wäre geometrisch exakt.

Hier der G-Code, danach der Kommentar:


(FRÄSBAHN #1 beginnend bei 3 Uhr)
(GRundfläche ist 50 Radius, Mittelpunkt bei 0.0)
g2 x0 y-45 i-45 z1(Viertelkreis Rampe in x und z von 3 nach 6)
g2 x0 y45 j45 (Halbkreis 6 nach 12)
g2 x45 y0 j-45 (Viertelkreis 12 nach 3)
G1 z0 (Absenken bei 3 Uhr)
g2 x0 y-45 i-45 (Viertelkreis rampe räumen 3 nach 6 )
g1 z1 (anheben)

(Fräsbahn #2 beginnend bei 6 Uhr)
g2 x-40 y0 j40 z2 (Rampe in x und z von 6 nach 9)
g2 x40 i40 (Halbkreis von 9 nach 3)
g2 x0 y-40 i-40 (Viertelkreis von 3 nach 6)
g1 z1 (absenken bei 6 Uhr)
g2 x-40 y0 j40 (Viertelkreis Rampe räumen von 6 nach 9)
g1 z2 (anheben)

(Fräsbahn #3 beginnend bei 9 Uhr)
g2 x0 y35 i35 z3 (Rampe von 9 nach 12)
g2 y-35 j-35 (Halbkreis von 12 nach 6)
g2 x-35 y0 j35 (Viertelkreis von 6 nach 9)
g1 z2(absenken)
g2 x0 y35 i35 (Viertelkreis Rampe räumen von 9 nach 12)
g1 z3 (anheben)

(Fräsbahn #4 beginnend bei 12 Uhr)
g2 x30 y0 j-30 z4 (Rampe von 12 nach 3)
g2 x-30 y0 i-30 (Halbkreis von 3 nach 9)
g2 x0 y30 i30 (viertelkreis von 9 nach 12)
g1 z3 (absenken)
g2 x30 y0 j-30 (Viertelkreis Rampe räumen von 12 nach 3)
g1 z4 (anheben)


Das ist in G90, etwas unanschaulich, in g91 wäre es besser, aber das zeigt mir mein Monitor nicht an.

Der Algorithmus sieht folgende Bearbeitung vor:

1.) Wir fahren von der jeweiligen Position 90 Grad rampe in z auf die nächsthöhere Bahn, wo wir dann unsere Höhe erreicht haben und unseren verkleinerten Radius. (Wir fräsen von unten nach oben, daß man Kegel besser von oben nach unten fräst, soll hier bei dem Algorithmus keine Rollse spielen, geht ja auch umgekehrt).

2.) Wir fahren dann, nachdem wir in Höhe und Radius in der nächsthöheren Ebene angekommen sind, einen Halbkreis.

3.) Von dort fahren wir einen Viertelkreis, wir sind also dort, wo wir angefangen haben. Bleibt jetzt nur noch das Problem, daß in dem folgenden Viertelkreis unsere Rampe in z steht, die auch einen Radius-Anteil hat. Würde man die nicht wegräumen, würde man das später am Stück als Fehlstelle sehen.

4.) Wir senken ab auf die H öhe von der vorherigen Bahn

5.) Wir fahren den Viertelkreis nochmal nach, um rampe zu räumen

6. Und heben das Werkzeug wieder an.

Der Alogrithmus benötigt also für eine Kreisbahn mit Rampe räumen nicht 360 Grad, sondern 90 Grad mehr = 450 Grad.

Das heißt, die nächste Kreisbahn startet dann um 90 Grad versetzt, mit genau derselben Reihenfolge. Das ist wahrscheiinlich gar nicht mal so verkehrt, für die Oberfläche, weil sich die Bearbeitungsspuren nicht in ein und dem sselben Sektor ansammeln.

Programmieren ließe sich sowas ganz leicht, mit der Hand eintippen und noch in g90 sind Schweißausbrüche angesagt,

aber bevor ich sowas programmiere,

würde mich mal die Meinung der Profis interessieren.





Gruß @all Sharky

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 17:36 Uhr

Ach ja, warum 4 Fräsbahnen?

Wir fangen bei 3 Uhr an, dann bei 6 9 und 12, und nach Ende der 4. bahn stehen wir wieder bei 3 Uhr.

Wäre das Ende der Bearbeitung mittendrin, kein Problem, wäre die Maschine eben fertig und würde den Rest der 4er Gruppe nicht mehr fahren.

Ob man das als Vierergruppe programmiert, eher unwahrscheinlich. Man wird wohl den Winkelversatz als Schleppzeiger weiterreichen, physikalisch, nur die Bezeichner i und j müßten dann bei der Erzeugung der G-Befehle ausgetauscht werden.

Also wie gesagt: zur Programmierung eignen sich solche etwas "unhandlichen" Algorithmen hervorragend.

Die 90 Grad "mehr" als 360 sind für meine Begriffe aus dem Bauch heraus immer noch sehr viel weniger, als würde man das mit An-und Abfahrbogen pro Bahn programmieren, was natürlich auch als Alternative übrig bliebe.

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 17:49 Uhr

Hallo sharky,

ich denke, wir sollten jetzt doch mal drüber grübeln, wo wir eigentlich hinwollen.
- Die von dir skizzierte Methode verlängert den gesamten Fräsweg und damit die Bearbeitungszeit um 25%. Gemessen daran, daß sie bei dem vorgesehenen Vorschub von 100mm/min schon vorher inakzeptabel hoch war, scheint mir das kein Pappenstil.
- Du hast vorher irgendwann gesagt, wir bräuchten keinen Kegel und keine Kugel, sondern nur "Pattern" = vorbereitete Programmfragmente für real vorkommende Bauteilgeometrien. Unter der Prämisse spricht wieder alles für Z-konstante Bahnen, weil ein Kegel- oder Kugelsegment sich dann an andere Bauteilflächen anschließen wird, die man dann mit zusammenhängenden Bahnen gleich mitbearbeiten könnte.
- Ein Anfahrbogen muß nicht unbedingt 90° umfassen, sondern braucht mit dem Startpunkt nur um das vorhandene Aufmaß + Sicherheitszuschlag von der Fertiggeometrie entfernt zu liegen.
- An kreisförmige Bahnen kann man auch tangentiale Geraden als Anfahrweg benutzen.

Unter praktischen Gesichtspunkten spricht deshalb m.E. alles dafür, das Problem mit zweidimensionalen Fräswegen zu erschlagen. Falls wir aus "intellektueller Neugierde" trotzdem die Helixoption realisieren wollen, dann aber richtig, unter Verzicht auf alle 2D-Bahnen, mit Ausnahme einer einzigen Bahn um den Grundkreis.
Professionelle Steuerungen bieten dafür die Möglichkeit der Parameterprogrammierung, bei der eine Programmschleife immer wieder durchlaufen und der nächste Wegpunkt berechnet wird. Ob der dann per Kreis- oder per Geradeninterpolation angefahren wird, ist nebensächlich, wenn man die Wegpunkte nur eng genug legt. Mit etwas Geschick führt das zu einem kurzen, handlichen NC-Programm, mit dem - je nach gewählter Schrittweite - trotzdem eine Zillion Wegpunkte angefahren werden können. Die Zeit, die beim gewählten Vorschub von Wegpunkt zu Wegpunkte verstreicht, muß dabei ausreichen, den darauf folgenden Wegpunkt zu berechnen. Die typische Satzverarbeitungszeit liegt dabei im Bereich von unter 1ms bis max. 5ms und wird m.W. auch von PC-Steuerungen erreicht. Beim gegebenen F100 kann man damit also den Weg sehr, sehr fein auflösen.
Falls deine Steuerung keine solche Möglichkeit bietet, dann muß man eben extern mit irgendwelchen anderen Mitteln solch ein G-Code-Monster erzeugen. Professionelle Steuerungen lassen sich, wenn sie solch einen Brocken nicht im Speicher halten können, dann per "drip feed" füttern. Dabei werden permanent bereits abgearbeitete Sätze aus dem Speicher gelöscht, um Platz für neue zu schaffen, die dann blockweise nachgeladen werden. Das ist ein weiterer Grund für die lineare Struktur des "Glöckners".
Falls deine Steuerung weder drip feed noch überlange Programme kann, dann - und nur dann - würde ich mit Kreisinterpolation rangehen. Denn Vollkreis in 18, 36 oder 72 Segmente zerlegen und dann die Radius- und Z-Änderung gleichmäßig auf diese Segmente verteilen.

Gruß,

Clemens

Huch, jetzt hab ich ja den Schock fürs Leben gekriegt, ganz überlesen.

Was lesen wir da bei Clemens?

//und natürlich ist C++ mittlerweile von Java überholt. //


Möglicherweise hast du mich damit auf eine Idee gebracht. In C kenne ich mich jetzt kaum länger als ca. 1 Woche ein bißchen aus, könnte daher auch genausogut auf JAVA umsteigen.

Werde mir das mal ansehen.

Was mich dabei unbedingt interessieren würde, wäre das GUI.

Graphical user interface.

Weil ich es in C nämlich vermisse, was ich in Turbo-Pascal verfügbar hatte, daß man grafische Darstellungen von Kurven am bildschirm machen kann.

Das wäre gerade im vorliegenden Projekt natürlich eine große HIlfe, wenn das GUI was taugen würde.

Ich hab mal was rauskopiert aus dem Internet, eine GEgenüberstellung JAVA vs. C, steht hinten dran.

Vielleicht kann ja einer hier etwas zu diesem GUI sagen.

Ich würde gern meine errechneten Kurven in xy am Bildschirm sehen können, und die nicht über GBefehle in die Steuerung kopieren müssen. Das würde mir nämlich bei der PRogrammentwicklung sehr helfen.


Gruß Sharky






Java: Java vs. C
Is Java easier or harder than C?
Java is harder because ...

* Java is more powerful and can do much more than C. For example, C doesn't have a graphical user interface (GUI), and C doesn't have any way to do object-oriented programming (OOP). It's possible to write in Java in a C style, avoiding the new powerful features of Java. But that is foolish.
* Java either checks for errors, or makes you check for errors. C lets you do many things that would cause errors (for example, convert strings to integers, or do I/O), but doesn't make you write code to handle the errors. Java makes you write try...catch statements around things that might cause problems.

Java is easier because ...

* Java checks for errors. For example, Java checks subscripts to make sure they are in the correct range.
* Java does things for you. There are a huge number of things that Java has already written for you. For example, expandable arrays, many data structures, etc. In C it would take a very long time to write and debug these things by yourself.
* Java doesn't have the most dangerous things. The things in C which cause the most program errors are pointers, pointer arithmetic, and memory management. Java has replaced these with much, much safer things: references, subscription, and garbage collection.

The reason that everyone is very enthusiastic about Java is because it is easier (faster, cheaper, ...) to produce good programs.
From C++ to Java
If you know C or C++, you already know a lot of Java.

The Java language is based mostly on C and C++. You'll see that a lot of the basic language elements, for example, the primitive types, operators, and statements of Java are taken directly from C.
Primitive Java types are similar to C

Java includes types which are similar to those in C/C++ (char, short, int, long, float, and double). Unlike C/C++, Java defines exactly how these types are implemented. For example, the length of an int in C might be 16 bits on a PC, 32 bits on a workstation, and 60 bits on an old supercomputer. Java defines exactly how ints are represented (32 bits, two's complement, big-endian). All Java types are completely defined, in contrast to C where NO types are well specified.
Portability and types

Because of the lack of complete type definitions, moving a C/C++ program from one machine to another can be a giant headache, or even impossible. For example, to preserve the range of an integer variable you might have to change shorts to ints, but then you also have to change the corresponding format specifiers, union declarations, bit field declarations, shift operators, etc. This is only one example of the tremendous number of portability problems in C/C++. There are entire books written about these problems. Because the Java types are well defined, there are none of these problems.
Additional primitive types

Java has two additional primitive types: boolean and byte. The boolean type is a nice addition that is like Pascal boolean; it can have only the values true and false. The byte type is used for 8-bit integers because char is a Unicode character, which requires 16 bits.
Summary of the Java primitive types

Java integer types are two's complement: byte (signed 8 bits), char (unsigned 16 bits), short (signed 16 bits), int (signed 32 bits), and long (signed 64 bits).

The real surprise here is that char is 16 bits! This is because the Unicode character set is used so that characters in all major human languages can be represented. C doesn't specify the character set for char (no, it isn't ASCII, it can be EBCDIC or any other code) -- another sad C portability story.

The two types float (32 bits) and double (64 bits) use the IEEE 754 floating-point representation.
Java and C Arrays

Java arrays are very similar to C arrays although they must always be dynamically allocated. However, Java arrays are not just pointers into memory, but separate objects. One of the good benefits of this is that array subscript bounds are checked, which makes finding bugs much easier.
Java Strings are not Arrays of char

In Java there is two special object types, String and StringBuffer, that are used to store strings of characters. C uses arrays of char, but this causes many problems. Of course, you can use an array of characters in Java if you need to, but it is usually easier to use String or StringBuffer
Java Operators are similar to C

Most of the Java operators are the same as those in C/C++, however Java specifies the exact order of evaluation in an expression, which C does not.

Rather than list all of the 40+ operators that are the same, it's easier to list the differences.

There is an additional right shift operator, >>>, to add zero bits on the left regardless of the sign of the left operand. The C comma operator is limited to the first and third parts of the for loop, which is just about the only place it is normally used in C programs anyway.

There are no pointer operators (&, *, ->) because Java uses something called references instead of pointers. References are really pointers to objects, but are simpler, and safer, than pointers.
Java statements are similar to C

You'll see all the usual statement keywords with the same meanings: if, else, switch, case, break, default, for, do, while, continue, and return.

A few statements have been added to handle exceptions and threads. Java exceptions are basically errors, and there are statements to help detect and handle these errors. Java also allows more than one part of a program to run simultaneously using threads. You won't have to use threads for most programming, but in the cases where you do, there are statements to control the different threads.
Object Oriented Programming - OOP

Classes form the basis for Object Oriented Programming (OOP). Java classes are like C++ class, which are something like a C structs that includes both data fields and functions. Objects are created when memory is allocated for one of these class "structs". The basic idea is simple.
Java support for large programming projects

For small programming projects it's sufficient to use functions, sometimes in separate source files. Large programming projects need more control over the structure and visibility of the program elements. Java provides this control in the form of classes, packages, and interfaces, along with a number of ways to control who can see what.
Class libraries

Sometimes someone says that Java is a small language, smaller than C++, and perhaps smaller than C. This may be true if you ignore one of the most important things: the class libraries. There are a huge number of methods (the special OOP word for function) in the thousands of classes that are grouped in packages. Packages and OOP are the reasons that it's possible to have such large libraries.
Copyleft 2003 Fred Swartz MIT License, Last update: 2003-10-26

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 19:15 Uhr

Nein, sorry!

Ich habe damals aber auch etwas im Internet recherchiert, um den Satz abzusichern, der dich so erschreckt hat. Dabei habe ich auch was über C# gefunden, eine Sprache, die ich bislang noch überhaupt nicht auf'm Schirm hatte.
C# und C++ sind completely different animals!
C#, das Cis oder englisch C sharp, ist ein Microsoft-Konkurrenzprodukt zu Java - und damit von vornherein zutiefst verabscheuungswürdig, egal ob's was taucht odda nich.



Gruß,

Clemens

(der hier selbstverständlich nur seine subjektive Sicht der Dinge darstellt, die in keiner Weise die Meinung der Betreiber dieses Forums widerspiegelt, auch wenn diese hier anschließend nicht im Text rumschnippeln werden.)

Ich hab darüber im Netz auch noch nichts vernünftiges gefunden. C# ist wirklich von MS und daher sofort abhaken, siehe ganz im Anfang, als ich den MS C++ Compiler draufgeladen hatte. Und der war noch nicht mal C#, sondern C++ von MS.

C++ steht zwar im Titel auf diesem Thread, aber wir haben es hier bisher ausschließlich mit Ansi-C von Ritchie zu tun. Ich beabsichtige auch gar nicht, als typischer ZU FUSS Programmierer (ist natürlich Hobby, bin kein Profi) das objektorientierte überhaupt auszunutzen. Sowas, da stellen sich mir die Fußnägel hoch. OOP ist was für Profis, die in kurzer Zeit viele Programme zusammenkleistern müssen, und was dabei herauskommt, hab ich weiter oben beschrieben, zum Stand der miserablen Programmierung heutzutage: FAktor 5000 vom Speed ist da noch schöngeredet. Ist natürlich nicht repräsentativ, meine Meinung, und ich kenne auch nur ein paar Branchenlösungen, aber da ist es genauso

Es würde mich sehr wundern, wenn die Shelby AC Cobra, denn das ist C, C ist ganz dicht an der Maschine, von solchen OOP im Speed übertroffen werden könnte. Das kriegt man nur hin, wenn man ganz dämliche Vergleichsoperationen heranzieht, also wenn man eine AC Cobra gegen einen Leopard-Panzer in der Wildnis fahren läßt, wird der lahmarschige Leopard natürlich gewinnen.

Ich seh es ja aus meiner (zwar lange zurückliegenden, aber damals war SPEED alles) Erfahrung, schon aus dem Bauch heraus, daß der devc++ Compiler eine ultraheiße Kiste ist. Der macht Millionen Rechenoperationen pro ms, was soll denn da noch schneller sein?

Jetzt würde mich mal interessieren, was der absolute Praktiker Gekufi zu meinem zugegebenermaßen etwas umständlichen 450 Grad Algorithmus anzumerken hätte. So wie ich das mitbekommen habe, steht der ja jeden Tag an der Maschine und sieht mit eigenen Augen, was er da zusammenbaut.


Gruß Sharky

Der Beitrag wurde von sharky bearbeitet: 25.01.2009, 22:38 Uhr