GCode Programmierung für 3D in C++, Ein Projekt
28.01.2009, 13:40 Uhr
Hier ist eine Gesamtansicht. Der Korkenzieher läuft zwei Vollkreise. Es verjüngen sich sowohl die Korkenzieher-Helix wie auch die Satellitenhelix, die Materialstärke nimmt von unten nach oben z-konstant ab. Das Ding steht ungefähr auf dem Kopf, man sieht von schräg oben drauf, Startpunkt ist der gelbe Punkt =da ist z=0. Wie man die Anzeige vom Kopf auf die Füße stellt, hab ich noch nicht rausgefunden.
Damit ich das in 500 Datensätzen in GCode ausdrücken kann (mehr macht die Demo-Version Mach3 nicht), wurde die Auflösung stark reduziert und statt in Kreisen im Achteck gefahren. Achteck sieht aber auch ganz nett aus!
Damit ich das in 500 Datensätzen in GCode ausdrücken kann (mehr macht die Demo-Version Mach3 nicht), wurde die Auflösung stark reduziert und statt in Kreisen im Achteck gefahren. Achteck sieht aber auch ganz nett aus!
Angehängte Datei(en)
doppelhelix_gesamt.JPG ( 132.2KB )
Anzahl der Downloads: 59
doppelhelix_gesamt.JPG ( 132.2KB )
Anzahl der Downloads: 59--------------------
A programmer is just a tool which converts caffeine into code
28.01.2009, 13:46 Uhr
Hier ist noch eine andere Perspektive, da sieht man das 3 D besser. Auch so ungefähr schräg von oben draufgesehen.
Kleine Berichtigung:
Im Bild vorher sieht man genau von oben drauf, in diesem Bild schräg seitlich von oben. Mit dem 3D, da muß ich mich auch erstmal dran gewöhnen.
Um nun 20 Schneckengänge zu fahren oder 500 oder das Material dicker zu machen, die Steigung zu ändern oder sonstwas, braucht man nur die Zahlenangaben der Programmvorgabe zu ändern, z.B. Steigung, Radius usw.
Die Berechnung ändert sich dadurch nicht, die o.s. Funktion berechnet alles, was ihr in die Finger kommt, solange das geometrisch möglich ist.
Wenn man das Stück in diesen Dimensionen fräsen wollte, dann wär das denkbar, wenn man einen geschmiedeten, gegossenen oder gezogenen Rohling hätte, der schon ungefähr die Form hätte, also als Schlichtbearbeitung, um das Stück exakt maßgenau zu machen. Aus dem Vollen wär das dann weniger sinnvoll.
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 13:58 Uhr
Kleine Berichtigung:
Im Bild vorher sieht man genau von oben drauf, in diesem Bild schräg seitlich von oben. Mit dem 3D, da muß ich mich auch erstmal dran gewöhnen.
Um nun 20 Schneckengänge zu fahren oder 500 oder das Material dicker zu machen, die Steigung zu ändern oder sonstwas, braucht man nur die Zahlenangaben der Programmvorgabe zu ändern, z.B. Steigung, Radius usw.
Die Berechnung ändert sich dadurch nicht, die o.s. Funktion berechnet alles, was ihr in die Finger kommt, solange das geometrisch möglich ist.
Wenn man das Stück in diesen Dimensionen fräsen wollte, dann wär das denkbar, wenn man einen geschmiedeten, gegossenen oder gezogenen Rohling hätte, der schon ungefähr die Form hätte, also als Schlichtbearbeitung, um das Stück exakt maßgenau zu machen. Aus dem Vollen wär das dann weniger sinnvoll.
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 13:58 Uhr
Angehängte Datei(en)
doppelhelixnr3.JPG ( 136.71KB )
Anzahl der Downloads: 55
doppelhelixnr3.JPG ( 136.71KB )
Anzahl der Downloads: 55--------------------
A programmer is just a tool which converts caffeine into code
28.01.2009, 14:21 Uhr
Hier ist mal eine etwas kompaktere Struktur, eine Helix mit mehreren Gängen, der Materialquerschnitt ist exakt 6-kantig.
Ich hab mir das im Monitor von der Seite angesehen, läßt sich fräsen, keine Toten Winkel keine Abschottungen.
Sowas mit einer CAM zu entwerfen, dürfte womöglich auch nicht so einfach sein.
Dadurch, daß man sich beim Programmieren die Parameter schön offen läßt, könnten wir die Struktur auch mit 16 Ecken fräsen oder 21.
Ich habe mal probiert: um 500.000 Datensätze zu erzeugen, benötigt der C-Compiler zwar nur millisekunden, aber für das Speichern der Daten auf der Festplatte braucht er immerhin so ca. 10 sec. Damit sollte man zurechtkommen.
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 14:23 Uhr
Ich hab mir das im Monitor von der Seite angesehen, läßt sich fräsen, keine Toten Winkel keine Abschottungen.
Sowas mit einer CAM zu entwerfen, dürfte womöglich auch nicht so einfach sein.
Dadurch, daß man sich beim Programmieren die Parameter schön offen läßt, könnten wir die Struktur auch mit 16 Ecken fräsen oder 21.
Ich habe mal probiert: um 500.000 Datensätze zu erzeugen, benötigt der C-Compiler zwar nur millisekunden, aber für das Speichern der Daten auf der Festplatte braucht er immerhin so ca. 10 sec. Damit sollte man zurechtkommen.
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 14:23 Uhr
Angehängte Datei(en)
hexagonhelix.JPG ( 131.78KB )
Anzahl der Downloads: 46
hexagonhelix.JPG ( 131.78KB )
Anzahl der Downloads: 46--------------------
A programmer is just a tool which converts caffeine into code
28.01.2009, 18:05 Uhr
Wir wollen heute abend mal sehen, ob aus den bisherigen Programmfragmenten irgendein praktischer Nutzen entstehen könnte.
Die Antwort ist: auf jeden Fall.
Wir haben das mächtige Werkzeug
1.) Helix, mit dem wir eigentlich jede beliebige Kontur abfahren können ohne An- und Wegfahrbogen, in einem durchrutschen. Von den entwickelten Figuren sind weiter oben die Abbildung von der kreisförmigen einfachen Helix geeignet zum
2.) Fasen
bzw. Flächen schrägen einer runden Kontur. Mit derselben Funktion können wir nun auch eckige Konturen fasen, z. B. ein Oktagon (siehe untenstehende Abb., allerdings wer genau hinschaut: gemeinerweise habe ich hier ein Neun-eck genommen). Die Auflösung hab ich extra grob gelassen, damit man erkennen kann, daß es eine Helix ist. Am gelben Punkt ist start, oben enden wir schräg rechts vom Startpunkt.
Diese Grafiken sind nicht mit einem Grafikprogramm als Flächenmodelle entworfen, sondern das sind bereits fertige G-Befehle, und die Grafik entsteht auf der Fräsbahnanzeige meiner Steuerung. Das sind keine (!) Flächenmodelle, sondern fertiger Code.
Ich will heute abend mal versuchen, eine Kante zu runden, einmal an einer kreisförmigen Kontur, und dann an einer eckigen Kontur. Mal sehen ob man das so einfach hinkriegt oder ob sich die Logik da wieder so zerbröselt wie gestern abend.
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 18:07 Uhr
Die Antwort ist: auf jeden Fall.
Wir haben das mächtige Werkzeug
1.) Helix, mit dem wir eigentlich jede beliebige Kontur abfahren können ohne An- und Wegfahrbogen, in einem durchrutschen. Von den entwickelten Figuren sind weiter oben die Abbildung von der kreisförmigen einfachen Helix geeignet zum
2.) Fasen
bzw. Flächen schrägen einer runden Kontur. Mit derselben Funktion können wir nun auch eckige Konturen fasen, z. B. ein Oktagon (siehe untenstehende Abb., allerdings wer genau hinschaut: gemeinerweise habe ich hier ein Neun-eck genommen). Die Auflösung hab ich extra grob gelassen, damit man erkennen kann, daß es eine Helix ist. Am gelben Punkt ist start, oben enden wir schräg rechts vom Startpunkt.
Diese Grafiken sind nicht mit einem Grafikprogramm als Flächenmodelle entworfen, sondern das sind bereits fertige G-Befehle, und die Grafik entsteht auf der Fräsbahnanzeige meiner Steuerung. Das sind keine (!) Flächenmodelle, sondern fertiger Code.
Ich will heute abend mal versuchen, eine Kante zu runden, einmal an einer kreisförmigen Kontur, und dann an einer eckigen Kontur. Mal sehen ob man das so einfach hinkriegt oder ob sich die Logik da wieder so zerbröselt wie gestern abend.
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 18:07 Uhr
Angehängte Datei(en)
oktagon.jpg ( 91.29KB )
Anzahl der Downloads: 31
oktagon.jpg ( 91.29KB )
Anzahl der Downloads: 31--------------------
A programmer is just a tool which converts caffeine into code
28.01.2009, 18:53 Uhr
Hey Hey Hey!
Heute abend ist voll der Nostalgie-Abend.
Seitdem ich weiß, daß die Mach3 bis zu 10 Mio. Datensätze frißt (danke Cam-Tool für den Tip), denke ich natürlich bzgl. des G-Code-Materials ein bißchen großzügiger.
Und was passiert?
Kaum will ich mal richtig zulangen, stoße ich an die Grenze vom Windows-Speicher!
Hey Hey!
Das erinnert doch voll an die glorreichen Zeiten von Billies 640 KB (Kein Mensch braucht mehr als 640 KB)
Also, die alten Programmierertugenden von vor 20 Jahren, sich jedes einzelne Byte dreimal in der Hand herumzudrehen, bevor man es vom Speicher anfordert, und zu überlegen, wo man noch kleiner und sparsamer schaffen könnte, so ein altmodischer Kram ... die gelten immer noch! Ein Byte ist ein Byte, und kein Speicher ist unerschöpflich! Man kann die Gesetze der Physik nicht einfach ignorieren.
GROSSE oder EXTREM schwankende DATENMENGEN muß man dynamisch organisieren!
Hey Hey,
jetzt wissen wir, warum die Datenbank-Programmierer alles auf die Festplatte auslagern. Da müssen die nicht denken! Die wollen den Speicher nicht organisieren, das ist ja Aufwand! Und das Programm könnte, wenn man da was falsch macht, instabil werden. Also mal eben von einer Datenbank-Hochsprache ein paar Mega-Befehle reingekotzt, und es läuft. In dem Augenblick hat der Speicher einen Sack Steine auf dem Buckel, daß der kaum noch kriechen kann. So läuft das!
Ja das läuft schon! Nur:
Im Speicher rechnet man 50 Mio Datensätze im Bereich einige Millisekunden, mit der festplatte ist es Abend, bis die das durchgenudelt hat, oder das Wochenende ist vorbei.
Also, ich bin zwar programmiertechnisch nicht mehr auf dem Laufenden, stelle aber eindeutig fest:
Was damals richtig war, gilt heute noch genauso!
Daraus kann man schon ableiten, wenn dieses Projekt irgendwann mal wirklich Material erzeugen soll, 10 Mio. Datensätze, daß man dann mal einen Anruf bei unserem alten Kumpel Peter the Pointer tätigen muß:
Hallo Peter, hättest du mal lust mal ein bißchen zu pointern?
Die dynamische Verwaltung des Speichers ist die Bundesliga der Programmierung. Das ist ehrlich gesagt nichts für Anfänger.
Aber ich halt erstmal den Ball flach und mach es mit indizierten Arrays.
Hey hey!
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 19:00 Uhr
Heute abend ist voll der Nostalgie-Abend.
Seitdem ich weiß, daß die Mach3 bis zu 10 Mio. Datensätze frißt (danke Cam-Tool für den Tip), denke ich natürlich bzgl. des G-Code-Materials ein bißchen großzügiger.
Und was passiert?
Kaum will ich mal richtig zulangen, stoße ich an die Grenze vom Windows-Speicher!
Hey Hey!
Das erinnert doch voll an die glorreichen Zeiten von Billies 640 KB (Kein Mensch braucht mehr als 640 KB)
Also, die alten Programmierertugenden von vor 20 Jahren, sich jedes einzelne Byte dreimal in der Hand herumzudrehen, bevor man es vom Speicher anfordert, und zu überlegen, wo man noch kleiner und sparsamer schaffen könnte, so ein altmodischer Kram ... die gelten immer noch! Ein Byte ist ein Byte, und kein Speicher ist unerschöpflich! Man kann die Gesetze der Physik nicht einfach ignorieren.
GROSSE oder EXTREM schwankende DATENMENGEN muß man dynamisch organisieren!
Hey Hey,
jetzt wissen wir, warum die Datenbank-Programmierer alles auf die Festplatte auslagern. Da müssen die nicht denken! Die wollen den Speicher nicht organisieren, das ist ja Aufwand! Und das Programm könnte, wenn man da was falsch macht, instabil werden. Also mal eben von einer Datenbank-Hochsprache ein paar Mega-Befehle reingekotzt, und es läuft. In dem Augenblick hat der Speicher einen Sack Steine auf dem Buckel, daß der kaum noch kriechen kann. So läuft das!
Ja das läuft schon! Nur:
Im Speicher rechnet man 50 Mio Datensätze im Bereich einige Millisekunden, mit der festplatte ist es Abend, bis die das durchgenudelt hat, oder das Wochenende ist vorbei.
Also, ich bin zwar programmiertechnisch nicht mehr auf dem Laufenden, stelle aber eindeutig fest:
Was damals richtig war, gilt heute noch genauso!
Daraus kann man schon ableiten, wenn dieses Projekt irgendwann mal wirklich Material erzeugen soll, 10 Mio. Datensätze, daß man dann mal einen Anruf bei unserem alten Kumpel Peter the Pointer tätigen muß:
Hallo Peter, hättest du mal lust mal ein bißchen zu pointern?
Die dynamische Verwaltung des Speichers ist die Bundesliga der Programmierung. Das ist ehrlich gesagt nichts für Anfänger.
Aber ich halt erstmal den Ball flach und mach es mit indizierten Arrays.
Hey hey!
Der Beitrag wurde von sharky bearbeitet: 28.01.2009, 19:00 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 05:54 Uhr
***************************************************
********** Die Verrundung von Kanten *******************
********** ******************
***************************************************
Der Algorithmus zur Verrundung von Kanten ist nicht ganz banal. Zudem: er ist auch nicht ganz eindeutig determiniert.
Wir könnten die erforderlichen Bahnen horizonta versetzt berechnen, ganz so, als würden wir G2/G3 Befehle geben. Wir hätten dann aber das Problem, wie wir mit dem Werkzeug in die nächste Bahn gelangen. Da bleibt nur, das Werkzeug anzuheben, und entweder mit G1 radial zum Mittelpunkt zuzustellen, oder mit einem Anfahrbogen zu arbeiten. Letzterer verbraucht unnötige Maschinenzeit, ersterer dürfte zu einer deutlich sichtbaren Naht führen.
Ich stelle eine Behauptung auf:
REGEL: Mit G2 Behlen kann man keine Helix fahren.
Wenn einer das widerlegt, wär es recht. Würde die Programmierung sehr vereinfachen.
Wenn man auf G2 verzichtet, muß man den Kreisbogen selbst definieren. Und das machen wir so, daß wir die Auflösung festlegen als Anzahl der zu bestimmenden Punkte auf der Kreisbahn. Und in G1 abfahren. Realistisch gesehen, haben wir es nicht mit Punkten auf einer Kreisbahn zu tun, sondern mit Eckpunkten innerhalb eines Vielecks. Ob der G2/G3 Befehl intern auch so verwaltet wird, weiß ich nicht, wäre aber mal interessant zu wissen.
Daß die Programmierung nicht ganz banal ist, liegt an folgendem: Wir haben es hier innerhalb der Rundung mit einem Viertelkreis zu tun, der auf einer Schnittlinie des Werkstückmittelpunktes senkrecht auf der xy-Ebene sitzt, mit einem konstanten Radius (für eine exakte 90 Grad Rundung, man kann damit natürlich auch herumspielen und die Rundung ganz nach Belieben anders gestalten), welcher einen Offset-Anteil in allen drei Ebenen erzeugt, und mit einem in xy laufenden Zeiger mit dem Mittelpunkt in Werkstückmitte, welcher die kreisförmige Verschiebung in xy besorgt. Ja, auch die Rundung erzeugt ja eine Verschiebung in xy, nicht nur in z. Daher kann man die Koordinaten in xy nur als Summe der offsets beider radien bekommen.
Hier ist eine 90 Grad Rundung für kreisförmige Werkstücke
Erklärung: das ist EINE HELIX! Und die Helix ist kein Flächenmodell, sondern wie immer, sie besteht aus fix- und fertigen G1 Befehlen. Das Werkzeug fährt also in keinem einzigen Augenblick während der Verrundung eine Kreisbahn, sondern es fährt immer Schnecke. Allerdings ist der Versatz im radius je nach Auflösung vielleicht nur 1/1000 mm. Das kann man ja vorgeben. Wir wollen an der helix unter allen Umständen festhalten aus den oben beschriebenen Gründen.
Der Nachteil ist eine gewisse Inflationierung des Gcodes. Wir brauchen bei einer Kreisauflösung von 360 Eckpunkten schlicht und einfach 360 G1-Befehle, anstelle von zwei G2 Befehlen. Wenn es aber so ist, daß die Steuerung bis zu 10 Mio. Datensätze frißt, spielt das bei überschaubaren Bausteinen überhaupt keine Rolle. Selbst wenn man diese Verrundung von der Rauhtiefe so legt, daß man 1 Mio. datensätze benötigen würde, könnte man ja, bei Platzmangel, das als separates Programm einladen und wir hätten kein Problem.
********** Die Verrundung von Kanten *******************
********** ******************
***************************************************
Der Algorithmus zur Verrundung von Kanten ist nicht ganz banal. Zudem: er ist auch nicht ganz eindeutig determiniert.
Wir könnten die erforderlichen Bahnen horizonta versetzt berechnen, ganz so, als würden wir G2/G3 Befehle geben. Wir hätten dann aber das Problem, wie wir mit dem Werkzeug in die nächste Bahn gelangen. Da bleibt nur, das Werkzeug anzuheben, und entweder mit G1 radial zum Mittelpunkt zuzustellen, oder mit einem Anfahrbogen zu arbeiten. Letzterer verbraucht unnötige Maschinenzeit, ersterer dürfte zu einer deutlich sichtbaren Naht führen.
Ich stelle eine Behauptung auf:
REGEL: Mit G2 Behlen kann man keine Helix fahren.
Wenn einer das widerlegt, wär es recht. Würde die Programmierung sehr vereinfachen.
Wenn man auf G2 verzichtet, muß man den Kreisbogen selbst definieren. Und das machen wir so, daß wir die Auflösung festlegen als Anzahl der zu bestimmenden Punkte auf der Kreisbahn. Und in G1 abfahren. Realistisch gesehen, haben wir es nicht mit Punkten auf einer Kreisbahn zu tun, sondern mit Eckpunkten innerhalb eines Vielecks. Ob der G2/G3 Befehl intern auch so verwaltet wird, weiß ich nicht, wäre aber mal interessant zu wissen.
Daß die Programmierung nicht ganz banal ist, liegt an folgendem: Wir haben es hier innerhalb der Rundung mit einem Viertelkreis zu tun, der auf einer Schnittlinie des Werkstückmittelpunktes senkrecht auf der xy-Ebene sitzt, mit einem konstanten Radius (für eine exakte 90 Grad Rundung, man kann damit natürlich auch herumspielen und die Rundung ganz nach Belieben anders gestalten), welcher einen Offset-Anteil in allen drei Ebenen erzeugt, und mit einem in xy laufenden Zeiger mit dem Mittelpunkt in Werkstückmitte, welcher die kreisförmige Verschiebung in xy besorgt. Ja, auch die Rundung erzeugt ja eine Verschiebung in xy, nicht nur in z. Daher kann man die Koordinaten in xy nur als Summe der offsets beider radien bekommen.
Hier ist eine 90 Grad Rundung für kreisförmige Werkstücke
Erklärung: das ist EINE HELIX! Und die Helix ist kein Flächenmodell, sondern wie immer, sie besteht aus fix- und fertigen G1 Befehlen. Das Werkzeug fährt also in keinem einzigen Augenblick während der Verrundung eine Kreisbahn, sondern es fährt immer Schnecke. Allerdings ist der Versatz im radius je nach Auflösung vielleicht nur 1/1000 mm. Das kann man ja vorgeben. Wir wollen an der helix unter allen Umständen festhalten aus den oben beschriebenen Gründen.
Der Nachteil ist eine gewisse Inflationierung des Gcodes. Wir brauchen bei einer Kreisauflösung von 360 Eckpunkten schlicht und einfach 360 G1-Befehle, anstelle von zwei G2 Befehlen. Wenn es aber so ist, daß die Steuerung bis zu 10 Mio. Datensätze frißt, spielt das bei überschaubaren Bausteinen überhaupt keine Rolle. Selbst wenn man diese Verrundung von der Rauhtiefe so legt, daß man 1 Mio. datensätze benötigen würde, könnte man ja, bei Platzmangel, das als separates Programm einladen und wir hätten kein Problem.
Angehängte Datei(en)
kreisrundung.jpg ( 45.78KB )
Anzahl der Downloads: 43
kreisrundung.jpg ( 45.78KB )
Anzahl der Downloads: 43--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 06:07 Uhr
So, und jetzt kommt der große Clou bei der Sache.
Mir war das schon klar, warum ich auf jeden fall auf G2/G3 verzichten wollte, nämlich, wir wollen ja nicht nur Kreiskonturen verrunden, sondern auch eckige Werkstücke. Da käme man mit g2 nicht hin.
Definiert man den Kreis aber als vieleck, leistet die Funktion beides, wie man hier sieht, bei diesem Oktagon. Die Verrundung wurde hier nicht 90 Grad gerechnet, sondern auf 75 Grad.
Wie gesagt, es ist genau dieselbe Funktion. Um jede Art von vielecken zu runden, brauchen wir keine einzige Programmzeile mehr.
Mir war das schon klar, warum ich auf jeden fall auf G2/G3 verzichten wollte, nämlich, wir wollen ja nicht nur Kreiskonturen verrunden, sondern auch eckige Werkstücke. Da käme man mit g2 nicht hin.
Definiert man den Kreis aber als vieleck, leistet die Funktion beides, wie man hier sieht, bei diesem Oktagon. Die Verrundung wurde hier nicht 90 Grad gerechnet, sondern auf 75 Grad.
Wie gesagt, es ist genau dieselbe Funktion. Um jede Art von vielecken zu runden, brauchen wir keine einzige Programmzeile mehr.
Angehängte Datei(en)
oktagon75grad.jpg ( 51.2KB )
Anzahl der Downloads: 32
oktagon75grad.jpg ( 51.2KB )
Anzahl der Downloads: 32--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 06:17 Uhr
Hier haben wir die Verrundung eines quadratischen Werkstücks mit 90 Grad Rundungswinkel.
Da ich die Auflösung sehr grob gehalten habe, kann man die Helix-Bahnen noch relativ deutlich erkennen.
Die Rundungsfunktion kann also
1.) Jede Art von kreisförmigen Werkstücken
2.) Jede Art von Vielecken
3.) Darunter Quadrate
verrunden.
Was sie nicht kann, weil sie ja in Winkelschritten vorgeht, sind Rechtecke verrunden. Um Rechtecke zu verrunden, müßte man eine neue Funktion schreiben.
Da ich die Auflösung sehr grob gehalten habe, kann man die Helix-Bahnen noch relativ deutlich erkennen.
Die Rundungsfunktion kann also
1.) Jede Art von kreisförmigen Werkstücken
2.) Jede Art von Vielecken
3.) Darunter Quadrate
verrunden.
Was sie nicht kann, weil sie ja in Winkelschritten vorgeht, sind Rechtecke verrunden. Um Rechtecke zu verrunden, müßte man eine neue Funktion schreiben.
Angehängte Datei(en)
quadrat90grad.jpg ( 46.49KB )
Anzahl der Downloads: 44
quadrat90grad.jpg ( 46.49KB )
Anzahl der Downloads: 44--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 06:55 Uhr
Quantitativ:
Objekt: Verrundung einer kreisförmigen Struktur
Rauhtiefe =0.05 mm
Kreispunkte = 360x4
Anzahl G1-Befehle = 1,4 Mio.
Größe der erzeugten Datei 58 MB (=58.000 KB)
Wie lange braucht der C-Compiler, um das zu berechnen?
Berechnungszeit = ca. 2 Sekunden.
Zeit für das Erzeugen der datei ca. 10 Sekunden.
Objekt: Verrundung einer kreisförmigen Struktur
Rauhtiefe =0.05 mm
Kreispunkte = 360x4
Anzahl G1-Befehle = 1,4 Mio.
Größe der erzeugten Datei 58 MB (=58.000 KB)
Wie lange braucht der C-Compiler, um das zu berechnen?
Berechnungszeit = ca. 2 Sekunden.
Zeit für das Erzeugen der datei ca. 10 Sekunden.
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 16:54 Uhr
Und diese Bemerkung kann ich mir jetzt nicht verkneifen:
Der C-Code, der die Berechnung für 1,4 Mio. G-Code Zeilen durchführt, innerhalb 2 Sekunden (! hallo!), das ist der Vorteil der maschinen-nahen Sprache,
also dieser C-Code, der braucht ja auch Speicher.
Die 1,4 Mio. G-Code Zeilen, die das ausdrücken, was der C-Code innerhalb 2 Sekunden berechnen kann,
benötigen sage und schreibe 58.000.000 Byte= 58.000 KB = 58 Megabyte an Speicher.
Und wieviel benötigt der korrespondierende C-Code?
Mal raten!
Antwort kommt jetzt:
6 KB.
Bingo für den, der jetzt richtig geraten hat.
Und das exe-File, das hat natürlich etwas mehr, weil ja die ganze Laufzeitbibliothek drin untergebracht ist. Das .exe File hat 470 kb.
Also der Vergleich hinkt sowieso, weil diese 6 KB Source Code natürlich auch 20 Mio. Datensätze in G erzeugen könnten. Und würde man die Funktionen erweitern, um für eine andere Funktion weitere Millionen Datensätze zu erzeugen, würde das exe nicht wesentlich zunehmen. Das .exe hat eine Minimalgröße, bedingt durch die eingebundenen Bibliotheken, und würde man das Programm auf den doppelten Umfang erweitern, kämen besagte 6 KB dazu, nicht noch mal 470 KB, dann hätte das exe File bei Verdoppelung des source-codes vielleicht 471 KB. Das wär´s dann auch. Also aus der maus 471 KB wird niemals ein Elefant von 58 MB, der für den Preis des Größenwachstums gerade mal dieselbe Information enthält wie die Maus. Das wäre in der Natur nicht möglich.
Der C-Code enthält um den Faktor 100 bis mehrere Millionen mal mehr Information als der G-Code.
Daher kann der G-Code nicht optimal sein. Allein diese unglaubliche Aufblähung der Dateigröße, obwohl die Information ja um kein bißchen zunimmt als durch Iteration, das ist unfaßbar. Maus zum Elefanten ohne jeden Gewinn an Information, ein naturwissenschaftliches Phänomen.
So, und mehr sage ich nicht dazu. Soll sich jeder seinen Kopf machen.
Btw, eine Bemerkung liegt ja nun deutlich auf der Hand:
Die programmierung in G-Code ist deutlichst suboptimal.
Einen Quantensprung in der Maschinensteuerung würde man erzielen, wenn die Maschine von der Steuerung in Echtzeit gefüttert wird. Meinetwegen in G-Code. Dann würde das Sinn machen. Eine Echtzeiterzeugung von Minimalinformationen für die Maschine. So herum läuft das rund.
Möglicherweise ist das aber schon jetzt der Fall, ich kenne wie gesagt die professionellen Steuerung nicht.
Das wäre eine mögliche Erklärung für das Phänomen, daß ein Elefant weniger Informationen enthält wie eine Maus und trotzdem überlebt.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 17:04 Uhr
Der C-Code, der die Berechnung für 1,4 Mio. G-Code Zeilen durchführt, innerhalb 2 Sekunden (! hallo!), das ist der Vorteil der maschinen-nahen Sprache,
also dieser C-Code, der braucht ja auch Speicher.
Die 1,4 Mio. G-Code Zeilen, die das ausdrücken, was der C-Code innerhalb 2 Sekunden berechnen kann,
benötigen sage und schreibe 58.000.000 Byte= 58.000 KB = 58 Megabyte an Speicher.
Und wieviel benötigt der korrespondierende C-Code?
Mal raten!
Antwort kommt jetzt:
6 KB.
Bingo für den, der jetzt richtig geraten hat.
Und das exe-File, das hat natürlich etwas mehr, weil ja die ganze Laufzeitbibliothek drin untergebracht ist. Das .exe File hat 470 kb.
Also der Vergleich hinkt sowieso, weil diese 6 KB Source Code natürlich auch 20 Mio. Datensätze in G erzeugen könnten. Und würde man die Funktionen erweitern, um für eine andere Funktion weitere Millionen Datensätze zu erzeugen, würde das exe nicht wesentlich zunehmen. Das .exe hat eine Minimalgröße, bedingt durch die eingebundenen Bibliotheken, und würde man das Programm auf den doppelten Umfang erweitern, kämen besagte 6 KB dazu, nicht noch mal 470 KB, dann hätte das exe File bei Verdoppelung des source-codes vielleicht 471 KB. Das wär´s dann auch. Also aus der maus 471 KB wird niemals ein Elefant von 58 MB, der für den Preis des Größenwachstums gerade mal dieselbe Information enthält wie die Maus. Das wäre in der Natur nicht möglich.
Der C-Code enthält um den Faktor 100 bis mehrere Millionen mal mehr Information als der G-Code.
Daher kann der G-Code nicht optimal sein. Allein diese unglaubliche Aufblähung der Dateigröße, obwohl die Information ja um kein bißchen zunimmt als durch Iteration, das ist unfaßbar. Maus zum Elefanten ohne jeden Gewinn an Information, ein naturwissenschaftliches Phänomen.
So, und mehr sage ich nicht dazu. Soll sich jeder seinen Kopf machen.
Btw, eine Bemerkung liegt ja nun deutlich auf der Hand:
Die programmierung in G-Code ist deutlichst suboptimal.
Einen Quantensprung in der Maschinensteuerung würde man erzielen, wenn die Maschine von der Steuerung in Echtzeit gefüttert wird. Meinetwegen in G-Code. Dann würde das Sinn machen. Eine Echtzeiterzeugung von Minimalinformationen für die Maschine. So herum läuft das rund.
Möglicherweise ist das aber schon jetzt der Fall, ich kenne wie gesagt die professionellen Steuerung nicht.
Das wäre eine mögliche Erklärung für das Phänomen, daß ein Elefant weniger Informationen enthält wie eine Maus und trotzdem überlebt.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 17:04 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 19:00 Uhr
Einen vernünftige Sprachstandard zu einer Maschinensteuerung kann ich mir eigentlich nur so vorstellen:
1.) Aufbau in Modulen, die sich gegenseitig aufrufen können, in Echtzeit, mit einer sehr strengen Hierarchie, wer was aufrufen darf,
2.) Iterations-Schleifen Bevorzugung der Abbruchbedingung am Kopfende, Abbruchbedingung am Fußende braucht man nicht wirklich
3.) Verzweigungen IF THEN mit einer sicheren Befehlsstruktur, die IF-THEN Verzweigung bei verschiedenen Programmiersprachen ist eindeutig nicht eindeutig in bezug auf das ELSE. Bei C ist das schon wesentlich besser gelöst als in Pascal, Pascal hat ein ELSE-Problem.
4.) Unbedingte Sprunganweisungen (z.B. Zeilensprünge) als Relikt der Dinosaurier-Ära Hollerith-maschinen müßten unbedingt verboten sein. Programmierern die sowas machen müßte man die Lizenz entziehen.
5.) Als Standardelement Helix einführen. Helix-Befehl ist auf Maschinenzeit gesehen der optimale Befehl, warum ist er im G-Code nicht drin?
Allein mit dieser Umstellung würde man 90-95 Prozent der G-Code Anweisungen auf den Müll werfen können, ohne daß irgendwas an Information verloren geht. Da ist ja auch keine Information drin. Also man würde nicht nur 95 Prozent des Codes auf den Müll werfen können, sondern in der anderen Richtung ca. 500.000 Prozent Informationsdichte hinzugewinnen.
STATT G-CODE WÄRE JETZT MAL H-CODE ANGESAGT. Es muß jemand doch den Mut finden, so einen Code durch was besseres zu ersetzen. Oder müssen wir als Satelliten, weil es am MIT entwickelt wurde, und die AMis den Krieg gewonnen haben, den Sch*** jetzt noch 100 Jahre fressen und die Maschinen so programmieren, wie sich am besten nicht ticken?
Es muß ein H-Code her. Ich bin ja nicht lange drin, sehe erst einige Monate drauf, aber mir dreht sich bei der Betrachtung des G-Codes von jeder Seite der Magen um.Der Code ist einfach nur Schwachsinn.
Neutral ausgedrückt:
Der Code ist informationstechnisch gesehen eine einzige katastrophe.
1.) Aufbau in Modulen, die sich gegenseitig aufrufen können, in Echtzeit, mit einer sehr strengen Hierarchie, wer was aufrufen darf,
2.) Iterations-Schleifen Bevorzugung der Abbruchbedingung am Kopfende, Abbruchbedingung am Fußende braucht man nicht wirklich
3.) Verzweigungen IF THEN mit einer sicheren Befehlsstruktur, die IF-THEN Verzweigung bei verschiedenen Programmiersprachen ist eindeutig nicht eindeutig in bezug auf das ELSE. Bei C ist das schon wesentlich besser gelöst als in Pascal, Pascal hat ein ELSE-Problem.
4.) Unbedingte Sprunganweisungen (z.B. Zeilensprünge) als Relikt der Dinosaurier-Ära Hollerith-maschinen müßten unbedingt verboten sein. Programmierern die sowas machen müßte man die Lizenz entziehen.
5.) Als Standardelement Helix einführen. Helix-Befehl ist auf Maschinenzeit gesehen der optimale Befehl, warum ist er im G-Code nicht drin?
Allein mit dieser Umstellung würde man 90-95 Prozent der G-Code Anweisungen auf den Müll werfen können, ohne daß irgendwas an Information verloren geht. Da ist ja auch keine Information drin. Also man würde nicht nur 95 Prozent des Codes auf den Müll werfen können, sondern in der anderen Richtung ca. 500.000 Prozent Informationsdichte hinzugewinnen.
STATT G-CODE WÄRE JETZT MAL H-CODE ANGESAGT. Es muß jemand doch den Mut finden, so einen Code durch was besseres zu ersetzen. Oder müssen wir als Satelliten, weil es am MIT entwickelt wurde, und die AMis den Krieg gewonnen haben, den Sch*** jetzt noch 100 Jahre fressen und die Maschinen so programmieren, wie sich am besten nicht ticken?
Es muß ein H-Code her. Ich bin ja nicht lange drin, sehe erst einige Monate drauf, aber mir dreht sich bei der Betrachtung des G-Codes von jeder Seite der Magen um.Der Code ist einfach nur Schwachsinn.
Neutral ausgedrückt:
Der Code ist informationstechnisch gesehen eine einzige katastrophe.
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 21:09 Uhr
Also was den G-Code betrifft:
The first cut is the deepest.
Untertitel in deutsch: der erste Eindruck von irgendeinem Sch*** ist immer der richtige.
Bibelversion: Staub zu Staub, Asche zu Asche
Ägyptische Version:
100.000 Sklavenprogrammierer in G können nicht mal in einem Jahr das schaffen, was ein Sklaventreiber in C sich in einer Minute ausdenkt.
Bemerkung von Amun ra, dem Oberpriester:
Nichts anderes haben sie verdient, sie sind elende G-Sklavengestalten. Sie sind geboren, um Sch*** zu fressen. So werden sie geborenund so werden sie auch verrecken.
The first cut is the deepest.
Untertitel in deutsch: der erste Eindruck von irgendeinem Sch*** ist immer der richtige.
Bibelversion: Staub zu Staub, Asche zu Asche
Ägyptische Version:
100.000 Sklavenprogrammierer in G können nicht mal in einem Jahr das schaffen, was ein Sklaventreiber in C sich in einer Minute ausdenkt.
Bemerkung von Amun ra, dem Oberpriester:
Nichts anderes haben sie verdient, sie sind elende G-Sklavengestalten. Sie sind geboren, um Sch*** zu fressen. So werden sie geborenund so werden sie auch verrecken.
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 21:51 Uhr
Eine VERNÜNFTIGE Maschinensteuerung könnte z.B. den Befehl haben:
1500 = Verrunden.
1500,0 Kreisförmiges verrunden
1500,0,60.345,75.0 Verrunde kreisförmig im Radius 60.345 auf 75 Grad
1500,1,80,120.1,90.5 Verrunde Rechteck 120.1*90.5 auf Radius 80 Grad
Ungefähr so stelle ich mir eine vernünftige Maschinensteuerung vor.
Modal könnte man dann eingeben:
R = rauhtiefe 0.05.
Und noch vieles anderes mehr.
So ungefähr werde ich meine eigene kleine Programmiersprache gestalten:
1500,0 =kreisförmig
1500,18 = 18 Ecken
So in der Art. Das wäre doch Kinderkram, eine neue Maschinensprache zu entwickeln.
Nun da ich die nun für mich selbst exakt oder so ähnlich entwickeln werde, wie oben aufgeführt, als Hobby-Amateur aus der La Main heraus, stört es mich nicht weiter.
Meine kleine Baumarktmaschine wird dann ungefähr so ticken, wie oben angedeutet, allerdings muß ich den vernünftigen Code dann noch mit c-Compiler in einen völlig behämmerten Code namens G umsetzen.
Ist ja für einen c-Compiler kein Problem.
Ich werde für meine kleine Baumarktmaschine in C eine völlig perfekte Maschinensprache entwicklen.
Die werde ich in meinen Compiler eingeben, und die Schnittstelle mit dem G-Code ist dann das Problem von dem Compiler.
Ich werde mit meinem Compiler in einer ganz neuen Maschinensprache reden, die ich noch entwickeln muß.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 22:03 Uhr
1500 = Verrunden.
1500,0 Kreisförmiges verrunden
1500,0,60.345,75.0 Verrunde kreisförmig im Radius 60.345 auf 75 Grad
1500,1,80,120.1,90.5 Verrunde Rechteck 120.1*90.5 auf Radius 80 Grad
Ungefähr so stelle ich mir eine vernünftige Maschinensteuerung vor.
Modal könnte man dann eingeben:
R = rauhtiefe 0.05.
Und noch vieles anderes mehr.
So ungefähr werde ich meine eigene kleine Programmiersprache gestalten:
1500,0 =kreisförmig
1500,18 = 18 Ecken
So in der Art. Das wäre doch Kinderkram, eine neue Maschinensprache zu entwickeln.
Nun da ich die nun für mich selbst exakt oder so ähnlich entwickeln werde, wie oben aufgeführt, als Hobby-Amateur aus der La Main heraus, stört es mich nicht weiter.
Meine kleine Baumarktmaschine wird dann ungefähr so ticken, wie oben angedeutet, allerdings muß ich den vernünftigen Code dann noch mit c-Compiler in einen völlig behämmerten Code namens G umsetzen.
Ist ja für einen c-Compiler kein Problem.
Ich werde für meine kleine Baumarktmaschine in C eine völlig perfekte Maschinensprache entwicklen.
Die werde ich in meinen Compiler eingeben, und die Schnittstelle mit dem G-Code ist dann das Problem von dem Compiler.
Ich werde mit meinem Compiler in einer ganz neuen Maschinensprache reden, die ich noch entwickeln muß.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 22:03 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 22:14 Uhr
Die Entwicklung dieser neuen Maschinensprache, vom C-Compiler in G umgesetzt, ist eine zwangsläufige Folgerung aus den o.g. Beobachtungen. Mit dem kann man nicht leben, wie es ist, also muß man es ändern.
Wie man sieht: so eine Rundungsroutine oder eine Helix zu entwickeln, ist keine so große Sache.
Man muß das von der ganzen Systematik ändern.
Neue Maschinensprache muß her.
Anwender redet mit Compiler in der neuen Sprache, Compiler bringt den dummen Tölpel G-Code dazu, das zu machen. Solange man den Tölpel nur in G1 Befehle erteilt, und in G90, dürfte das nicht das mindeste Problem sein. Er macht es ja jetzt schon.
Ich werde mich aus dem G-Standard ab sofort ausklinken, und eine eigene Sprache entwickeln. Die Übersetzung muß dann der Compiler erledigen. Da habe ich nicht die geringste Sorge, daß der das auch erledigt.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 22:20 Uhr
Wie man sieht: so eine Rundungsroutine oder eine Helix zu entwickeln, ist keine so große Sache.
Man muß das von der ganzen Systematik ändern.
Neue Maschinensprache muß her.
Anwender redet mit Compiler in der neuen Sprache, Compiler bringt den dummen Tölpel G-Code dazu, das zu machen. Solange man den Tölpel nur in G1 Befehle erteilt, und in G90, dürfte das nicht das mindeste Problem sein. Er macht es ja jetzt schon.
Ich werde mich aus dem G-Standard ab sofort ausklinken, und eine eigene Sprache entwickeln. Die Übersetzung muß dann der Compiler erledigen. Da habe ich nicht die geringste Sorge, daß der das auch erledigt.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 22:20 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
29.01.2009, 22:38 Uhr
Der Witz bei einer vernünftigen Maschinensprache wäre natürlich, daß die in Echtzeit dransitzt.
Das kann ich aber mit meinen Hobby-Mitteln nicht schaffen.
Das wäre aber wirklich der Witz. Eine verschachtelte Schleife wie:
for (int i ....<1000
for (int j ...< 1000
erzeugt in 2 Programmzeilen exakt 1 Mio. Befehle.
Also anstatt 1 Mio Zeilen in G-Code erzeugt sie 1 Mio. Befehle in 2 Zeilen in Echtzeit!
Dieser Königsweg ist mir verbaut.
Wir müssen es umformulieren und den dummen Tölpel G mit riesenhaften gepeicherten dateien in Trab halten, die eigentlich, würde man es sinnvoll organisieren, gar nicht nötig wären, weil wir es leider nicht in Echtzeit können. Die wirkklichen Vorteile einer solchen Idee gehen dadurch zum großen Teil verloren. Möglicherweise hat aber MACH3 noch Möglichkeiten. Muß man abchecken.
Den Anfang muß man machen mit der Sprache. Das wird keine leichte Aufgabe aber sehr reizvoll sein.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 22:43 Uhr
Das kann ich aber mit meinen Hobby-Mitteln nicht schaffen.
Das wäre aber wirklich der Witz. Eine verschachtelte Schleife wie:
for (int i ....<1000
for (int j ...< 1000
erzeugt in 2 Programmzeilen exakt 1 Mio. Befehle.
Also anstatt 1 Mio Zeilen in G-Code erzeugt sie 1 Mio. Befehle in 2 Zeilen in Echtzeit!
Dieser Königsweg ist mir verbaut.
Wir müssen es umformulieren und den dummen Tölpel G mit riesenhaften gepeicherten dateien in Trab halten, die eigentlich, würde man es sinnvoll organisieren, gar nicht nötig wären, weil wir es leider nicht in Echtzeit können. Die wirkklichen Vorteile einer solchen Idee gehen dadurch zum großen Teil verloren. Möglicherweise hat aber MACH3 noch Möglichkeiten. Muß man abchecken.
Den Anfang muß man machen mit der Sprache. Das wird keine leichte Aufgabe aber sehr reizvoll sein.
Der Beitrag wurde von sharky bearbeitet: 29.01.2009, 22:43 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
30.01.2009, 21:09 Uhr
Dieser Thread hier ist aus meiner Sicht soweit abgeschlossen.
Es gibt nichts wesentlich Neues mehr dazu zu sagen.
Die Anfangsüberlegungen haben sich bestätigt, man kann mit dem C-Compiler sehr gut Maschinenbefehle für die Steuerung von Werkzeugmaschinen erzeugen. Das würde man sicherlich auch in einer anderes Sprache schaffen, wie Pascal oder Basic oder JAVA oder was immer.
Im Prinzip verhält sich der g-code zu einer Programmiersprache ein bißchen ähnlich wie Assembler, aber nur im ganz groben Vergleich. Während Assembler speziell für die Steuerung von Prozessoren entwickelt wurde, steht beim G-Code immer noch dick drauf: Hollerith-Maschine. Mit so einem Code steuert man keine Prozessoren, sondern mechanische Lochkarten-Automaten. Das ist das historische Umfeld, man muß die Dinge sehen, wie sie sind.
Der Ursprung aller Programmiersprachen ist, angefangen bei Basic, daß der Assembler-Code =Prozessorsprache zwar hervorragend und exzellent dazu taugt, den Prozessor zu steuern, aber nicht dazu taugt, eine problembezogene Programmierung zu erzeugen, die außerhalb der Prozessorsteuerung angesiedelt ist. Das wäre mit Assembler schon vom reinen Zeitaufwand nicht zu schaffen. Dieses Argument gilt auch unbedingt für den G-Code. Wir können mit der Programmierung zu Fuß aus G-Code keine komplexen Strukturen erzeugen, weil G-Code eine Schnittstelle ist und keine Programmiersprache.
Wenn wir zum Schluß einen Blick auf die Programmiersprache C werfen, bleibt festzustellen, es ist eine kleine Sprache mit kleinen Funktionen. Aus denen man dann mächtige Funktionen erzeugen kann, aber man muß sie selbst erzeugen.
C hat keine Mega-Befehle zur Verfügung wie etwa eine Datenbank Anwendung wie Index(). Wer in C indizieren will, muß das alles zu Fuß selbst erzeugen. C steht aus diesem Grunde sehr nahe an der Maschine, weil der Compiler, der den C-Code in Assembler übersetzt, sehr wenig übersetzen muß.
Das ist auch der Grund, warum C eine extrem schnelle Sprache ist. Für die Berechnung von Millionen Koordinaten innerhalb weniger Sekunden ist C durchaus sehr geeignet und empfehlenswert.
Es steht oben zwar C++ drauf, was hier aber realisiert wurde, war Ansi-C. Wirklich c++ ist hier nicht gelaufen. Ich glaube auch nicht, daß man für solche maschinennahen Anwendungen mit dem Schwerpunkt milionenefache Rechenoperationen c++ oder c# wirklich braucht. Mit dem Ansi C bin ich bis jetzt hervorragend zurechtgekommen, und werde auch dabei bleiben.
Der Beitrag wurde von sharky bearbeitet: 30.01.2009, 21:18 Uhr
Es gibt nichts wesentlich Neues mehr dazu zu sagen.
Die Anfangsüberlegungen haben sich bestätigt, man kann mit dem C-Compiler sehr gut Maschinenbefehle für die Steuerung von Werkzeugmaschinen erzeugen. Das würde man sicherlich auch in einer anderes Sprache schaffen, wie Pascal oder Basic oder JAVA oder was immer.
Im Prinzip verhält sich der g-code zu einer Programmiersprache ein bißchen ähnlich wie Assembler, aber nur im ganz groben Vergleich. Während Assembler speziell für die Steuerung von Prozessoren entwickelt wurde, steht beim G-Code immer noch dick drauf: Hollerith-Maschine. Mit so einem Code steuert man keine Prozessoren, sondern mechanische Lochkarten-Automaten. Das ist das historische Umfeld, man muß die Dinge sehen, wie sie sind.
Der Ursprung aller Programmiersprachen ist, angefangen bei Basic, daß der Assembler-Code =Prozessorsprache zwar hervorragend und exzellent dazu taugt, den Prozessor zu steuern, aber nicht dazu taugt, eine problembezogene Programmierung zu erzeugen, die außerhalb der Prozessorsteuerung angesiedelt ist. Das wäre mit Assembler schon vom reinen Zeitaufwand nicht zu schaffen. Dieses Argument gilt auch unbedingt für den G-Code. Wir können mit der Programmierung zu Fuß aus G-Code keine komplexen Strukturen erzeugen, weil G-Code eine Schnittstelle ist und keine Programmiersprache.
Wenn wir zum Schluß einen Blick auf die Programmiersprache C werfen, bleibt festzustellen, es ist eine kleine Sprache mit kleinen Funktionen. Aus denen man dann mächtige Funktionen erzeugen kann, aber man muß sie selbst erzeugen.
C hat keine Mega-Befehle zur Verfügung wie etwa eine Datenbank Anwendung wie Index(). Wer in C indizieren will, muß das alles zu Fuß selbst erzeugen. C steht aus diesem Grunde sehr nahe an der Maschine, weil der Compiler, der den C-Code in Assembler übersetzt, sehr wenig übersetzen muß.
Das ist auch der Grund, warum C eine extrem schnelle Sprache ist. Für die Berechnung von Millionen Koordinaten innerhalb weniger Sekunden ist C durchaus sehr geeignet und empfehlenswert.
Es steht oben zwar C++ drauf, was hier aber realisiert wurde, war Ansi-C. Wirklich c++ ist hier nicht gelaufen. Ich glaube auch nicht, daß man für solche maschinennahen Anwendungen mit dem Schwerpunkt milionenefache Rechenoperationen c++ oder c# wirklich braucht. Mit dem Ansi C bin ich bis jetzt hervorragend zurechtgekommen, und werde auch dabei bleiben.
Der Beitrag wurde von sharky bearbeitet: 30.01.2009, 21:18 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
31.01.2009, 14:22 Uhr
Hallo Sharky!
Ich weiß eigentlich gar nicht worüber Du Dich aufregst. Immerhin hast Du gerade ein paar Monate Erfahrung auf diesem Gebiet und das mit einer Low-Cost-Hobby-Lösung.
Man kann nicht in einem Kleinwagen sitzend über den Komfort der 4-rädrigen Fortbewegung meckern, ohne dabei je einen Luxus-Schlitten gefahren zu haben. Doch gäbe es den Kleinwagen nicht, würde die Mehrheit nie diese Erfahrungen erst sammeln können. So auch Du nicht im übertragenen Sinne mit Deiner CNC.
Der G-Code ist - so wie Du ihn kennst - ein einziges Grundgerüst. Jedes System benötigt solch ein Gerüst. Ob dies nun G- oder H-Code oder sonstwas heißt, ist völlig irrelevant.
Wichtig ist nur, wie stark ein System mit zusätzlichen Funktionen aufbereitet wird. Und dann lautet die Frage etwas anders:
"Ist der G-Code Sch***, oder das verwendete System?"
Ein Kleinwagen unterscheidet sich doch gewaltig von einem Luxusschlitten, obwohl der auch nur 4 Räder hat...
Gruß,
Corrado
Ich weiß eigentlich gar nicht worüber Du Dich aufregst. Immerhin hast Du gerade ein paar Monate Erfahrung auf diesem Gebiet und das mit einer Low-Cost-Hobby-Lösung.
Man kann nicht in einem Kleinwagen sitzend über den Komfort der 4-rädrigen Fortbewegung meckern, ohne dabei je einen Luxus-Schlitten gefahren zu haben. Doch gäbe es den Kleinwagen nicht, würde die Mehrheit nie diese Erfahrungen erst sammeln können. So auch Du nicht im übertragenen Sinne mit Deiner CNC.
Der G-Code ist - so wie Du ihn kennst - ein einziges Grundgerüst. Jedes System benötigt solch ein Gerüst. Ob dies nun G- oder H-Code oder sonstwas heißt, ist völlig irrelevant.
Wichtig ist nur, wie stark ein System mit zusätzlichen Funktionen aufbereitet wird. Und dann lautet die Frage etwas anders:
"Ist der G-Code Sch***, oder das verwendete System?"
Ein Kleinwagen unterscheidet sich doch gewaltig von einem Luxusschlitten, obwohl der auch nur 4 Räder hat...
Gruß,
Corrado
31.01.2009, 18:47 UhrQUOTE (corrado @ Samstag, 31.Januar 2009, 14:22 Uhr)
Hallo Sharky!
Ich weiß eigentlich gar nicht worüber Du Dich aufregst. Immerhin hast Du gerade ein paar Monate Erfahrung auf diesem Gebiet und das mit einer Low-Cost-Hobby-Lösung.
Man kann nicht in einem Kleinwagen sitzend über den Komfort der 4-rädrigen Fortbewegung meckern, ohne dabei je einen Luxus-Schlitten gefahren zu haben. Doch gäbe es den Kleinwagen nicht, würde die Mehrheit nie diese Erfahrungen erst sammeln können. So auch Du nicht im übertragenen Sinne mit Deiner CNC.
Der G-Code ist - so wie Du ihn kennst - ein einziges Grundgerüst. Jedes System benötigt solch ein Gerüst. Ob dies nun G- oder H-Code oder sonstwas heißt, ist völlig irrelevant.
Wichtig ist nur, wie stark ein System mit zusätzlichen Funktionen aufbereitet wird. Und dann lautet die Frage etwas anders:
"Ist der G-Code Sch***, oder das verwendete System?"
Ein Kleinwagen unterscheidet sich doch gewaltig von einem Luxusschlitten, obwohl der auch nur 4 Räder hat...
Gruß,
Corrado
Ich weiß eigentlich gar nicht worüber Du Dich aufregst. Immerhin hast Du gerade ein paar Monate Erfahrung auf diesem Gebiet und das mit einer Low-Cost-Hobby-Lösung.
Man kann nicht in einem Kleinwagen sitzend über den Komfort der 4-rädrigen Fortbewegung meckern, ohne dabei je einen Luxus-Schlitten gefahren zu haben. Doch gäbe es den Kleinwagen nicht, würde die Mehrheit nie diese Erfahrungen erst sammeln können. So auch Du nicht im übertragenen Sinne mit Deiner CNC.
Der G-Code ist - so wie Du ihn kennst - ein einziges Grundgerüst. Jedes System benötigt solch ein Gerüst. Ob dies nun G- oder H-Code oder sonstwas heißt, ist völlig irrelevant.
Wichtig ist nur, wie stark ein System mit zusätzlichen Funktionen aufbereitet wird. Und dann lautet die Frage etwas anders:
"Ist der G-Code Sch***, oder das verwendete System?"
Ein Kleinwagen unterscheidet sich doch gewaltig von einem Luxusschlitten, obwohl der auch nur 4 Räder hat...
Gruß,
Corrado
Der Unterschied zwischen einem Luxusschlitten und einem Kleinwagen ist marginal. Beide bringen den Fahrer in nahezu derselben Zeit morgens zur Arbeit.
Der mit dem Kleinwagen hat am Monatsende mehr Geld übrig, bei gleichem Verdienst, ein Luxusschlitten hat, energetisch gesehen, eine saumäßige Energiebilanz. Dreifacher Einsatz von Ressourcen bei nahezu gleichwertigem Nutzen. Luxuswagen dienen auch nicht dem Luxus, da solltest du nochmal nachdenken, Luxuswagen haben den einzigen Sinn, den Profit zu steigern! Das Kapital produziert nicht bedarfsbezogen, sondern profitbezogen!
Wenn du mit deinem prof. Bearbeitungszentrum überhaupt nur ein Werkstück in einer vernünftigen Zeit fertig kriegst, dann hast du das
Programmierern zu verdanken, die dir den Code berechnet haben,
und nicht dem Gcode!
Oder willst du mir erzählen, die drücken dir einen Zeichnung in die Hand, und du machst sie dir dann per handeingabe im G-Code anweisungen an der Maschine zurecht? Wenn ja, rechnet das deine Steuerung, nicht du!
Und von diesen Programmierern, die dir die Programme liefern, womit du Gcode erzeugen kannst, damit du mit deiner Luxusmaschine tolle Werkstücke machen kannst, programmiert kein einziger in Gcode. Da kannst du einen Besen fressen, daß das so ist!
Es wäre mal interessant zu wissen, wie die Maschinensteuerungen Fanuc Heidenhain &Co. intern organisiert sind.
Gruß Sharky
--------------------
A programmer is just a tool which converts caffeine into code
31.01.2009, 19:06 Uhr
By the way:
Ich finde diese Mach3 Steuerung hochinteressant.
Wir haben hier eine PC-Schnittstelle, einen Interpreter, der als Sprache G-Code benutzt.
Das macht Mach3, weil G-Code internationaler Standard ist.
Da die Mach3 aber direkte Maschinebefehle nicht in G gibt, sondern durch
LOW = 0 Volt
und
HIGH = Steuerspannung
wäre das überhaupt gar nicht nötig, daß die intern die Programme in G-Code verrechnet. Die könnte die Programmbefehle genausogut in C verrechnen oder in Assembler oder Fortran.
Wie corrado schon sagte: gäbe es keine low level Baumarktmaschinen, würden viele Leute mit diesem Bereich gar nicht in Berührung kommen.
Es gibt aber einen riesigen Kreis von Anwendern, die Hobbymäßig CNC machen, die meisten FLachbett, und mit der Mach3 Steuerung bestens bedient sind: Mach3=200-300 Euro!
Die Steuerung der Maschine, das Grundgerüst, lieber Corrado, sind aber nur
Low=0 Volt und High= Steuerspannung.
Das ist das Grundgerüst! Das Grundgerüst ist binärer Code, und der kennt nur zwei Zustände: 0 oder 1. Entspricht dann 0V oder Steuerspannung.
Ich glaube, wenn der PC sich weiter durchsetzt, daß wir dann noch alternative Lösungen erleben werden, jenseits vom G-Code.
Sehen wir mal drauf:
Der Gcode sagt: g2 x i y z
Obwohl der G2/G3 einer der mächtigsten Befehle vom G-Code ist, abgesehen mal von der Steuerung in Polarkoordinaten, kann man genau diesen, also einen der mächtigsten G-Befehle, in C in exakt einer zeile erzeugen:
for i= Auflösung ... )x=sin(winkel)*radius;y=cos(winkel)*radius;
Die beiden Anweisungen sind völlig identisch. Nur daß man bei der letzten auf den G-Code völlig verzichten kann.
Der Gcode kann die G2/G3 Befehle auch nur schaffen, wenn er sin( und cos( verwaltet, und zwar intern. Die Auflösung für den G2 findet man in den Voreinstellungen, mit welcher Schrittweite die Maschine arbeitet.
Große Schrittweite=eckige Kreise, also die G2 macht nichts anderes als trignometrische Funktionen, also zerlegt die G2 den Kreis in Kreispunkte!
Hey Hey!
Das können wir auch ohne G2!
Wenn man in C einen Fünfzeiler programmiert, kann man damit 1 Mio GBefehle erzeugen! Das hab ich ja nun in diesem Thread zweifelsfrei bewiesen. Also ist die Informationsdichte vom C-Code um den Faktor mehrere Millionen mal höher als die des G-Codes.
Ich will aber hier nicht meckern, auch wenn das manchmal so scheint, sondern versuche, das Problem mit der Maschinensteuerung mit konstruktivem Denken zu verstehen.
Gruß Sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 19:17 Uhr
Ich finde diese Mach3 Steuerung hochinteressant.
Wir haben hier eine PC-Schnittstelle, einen Interpreter, der als Sprache G-Code benutzt.
Das macht Mach3, weil G-Code internationaler Standard ist.
Da die Mach3 aber direkte Maschinebefehle nicht in G gibt, sondern durch
LOW = 0 Volt
und
HIGH = Steuerspannung
wäre das überhaupt gar nicht nötig, daß die intern die Programme in G-Code verrechnet. Die könnte die Programmbefehle genausogut in C verrechnen oder in Assembler oder Fortran.
Wie corrado schon sagte: gäbe es keine low level Baumarktmaschinen, würden viele Leute mit diesem Bereich gar nicht in Berührung kommen.
Es gibt aber einen riesigen Kreis von Anwendern, die Hobbymäßig CNC machen, die meisten FLachbett, und mit der Mach3 Steuerung bestens bedient sind: Mach3=200-300 Euro!
Die Steuerung der Maschine, das Grundgerüst, lieber Corrado, sind aber nur
Low=0 Volt und High= Steuerspannung.
Das ist das Grundgerüst! Das Grundgerüst ist binärer Code, und der kennt nur zwei Zustände: 0 oder 1. Entspricht dann 0V oder Steuerspannung.
Ich glaube, wenn der PC sich weiter durchsetzt, daß wir dann noch alternative Lösungen erleben werden, jenseits vom G-Code.
Sehen wir mal drauf:
Der Gcode sagt: g2 x i y z
Obwohl der G2/G3 einer der mächtigsten Befehle vom G-Code ist, abgesehen mal von der Steuerung in Polarkoordinaten, kann man genau diesen, also einen der mächtigsten G-Befehle, in C in exakt einer zeile erzeugen:
for i= Auflösung ... )x=sin(winkel)*radius;y=cos(winkel)*radius;
Die beiden Anweisungen sind völlig identisch. Nur daß man bei der letzten auf den G-Code völlig verzichten kann.
Der Gcode kann die G2/G3 Befehle auch nur schaffen, wenn er sin( und cos( verwaltet, und zwar intern. Die Auflösung für den G2 findet man in den Voreinstellungen, mit welcher Schrittweite die Maschine arbeitet.
Große Schrittweite=eckige Kreise, also die G2 macht nichts anderes als trignometrische Funktionen, also zerlegt die G2 den Kreis in Kreispunkte!
Hey Hey!
Das können wir auch ohne G2!
Wenn man in C einen Fünfzeiler programmiert, kann man damit 1 Mio GBefehle erzeugen! Das hab ich ja nun in diesem Thread zweifelsfrei bewiesen. Also ist die Informationsdichte vom C-Code um den Faktor mehrere Millionen mal höher als die des G-Codes.
Ich will aber hier nicht meckern, auch wenn das manchmal so scheint, sondern versuche, das Problem mit der Maschinensteuerung mit konstruktivem Denken zu verstehen.
Gruß Sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 19:17 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
31.01.2009, 19:36 Uhr
Nochmal:
Wir wollen 5000 Kreisbahnen fahren.
Wir müssen, um 5000 Kreisbahnen zu fahren, egal in welcher ebene oder z-Versatz oder radius oder sonstwas, für 5000 Kreisbahnen 10.000 g2/g3 Befehle erzeugen, jeweils zwei Halbkreise.
macht 10.000 Programmzeilen!
Würden wir die Steuerung in ECHTZEIT erledigen, und zwar in C, ohne daß die Maschine jemals in ihrem Maschinenleben etwas von einem G-Code gehört hätte, würde die äquivalente Anweisung für diese 5000 Kreisbahnen z. B. so aussehen:
float aufloesung=360/IRGENDWAS // Maschinenparameter für eingestellte Auflösung
float radius=50;
float winkel=0.0;
float z_schlepp=irgendwas
for (int i=0;i<5000;i++)
radius=radius+ größer oder kleiner, je nachdem wie man will
z_schlepp = größer oder kleiner je nachdem wie man will
for (int j=0;j<5000;j++)
{
for (int i=0, i<aufloesung;i++)
{
winkel=twinkel + aufloesung; // Winkelschritt
if (winkel>=360) winkel = winkel-360;
x[j].[i]=sin(winkel)*radius;y[j].[i]=cos(winkel)*radius;z[j].[i]= z_schlepp;
}
}
Mit diesen paar Zeilen, die zwischen den geschweiften Klammern stehen, hat man der maschine die nötigen Informationen für exakt 5000 Kreisbahnen gegeben.
Das ist so grotesk, im Vergleich mit 10000 G-BEfehlen, also 4Zeilen gegen 10.000 Zeilen, da muß jeder, der in seinem Leben schon mal programmiert hat, direkt drüber stolpern, daß da was mit der Informationsdichte beim G-Code nicht stimmen kann.
Gruß sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 19:47 Uhr
Wir wollen 5000 Kreisbahnen fahren.
Wir müssen, um 5000 Kreisbahnen zu fahren, egal in welcher ebene oder z-Versatz oder radius oder sonstwas, für 5000 Kreisbahnen 10.000 g2/g3 Befehle erzeugen, jeweils zwei Halbkreise.
macht 10.000 Programmzeilen!
Würden wir die Steuerung in ECHTZEIT erledigen, und zwar in C, ohne daß die Maschine jemals in ihrem Maschinenleben etwas von einem G-Code gehört hätte, würde die äquivalente Anweisung für diese 5000 Kreisbahnen z. B. so aussehen:
float aufloesung=360/IRGENDWAS // Maschinenparameter für eingestellte Auflösung
float radius=50;
float winkel=0.0;
float z_schlepp=irgendwas
for (int i=0;i<5000;i++)
radius=radius+ größer oder kleiner, je nachdem wie man will
z_schlepp = größer oder kleiner je nachdem wie man will
for (int j=0;j<5000;j++)
{
for (int i=0, i<aufloesung;i++)
{
winkel=twinkel + aufloesung; // Winkelschritt
if (winkel>=360) winkel = winkel-360;
x[j].[i]=sin(winkel)*radius;y[j].[i]=cos(winkel)*radius;z[j].[i]= z_schlepp;
}
}
Mit diesen paar Zeilen, die zwischen den geschweiften Klammern stehen, hat man der maschine die nötigen Informationen für exakt 5000 Kreisbahnen gegeben.
Das ist so grotesk, im Vergleich mit 10000 G-BEfehlen, also 4Zeilen gegen 10.000 Zeilen, da muß jeder, der in seinem Leben schon mal programmiert hat, direkt drüber stolpern, daß da was mit der Informationsdichte beim G-Code nicht stimmen kann.
Gruß sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 19:47 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
31.01.2009, 20:05 Uhr
Ich habe diesen ganzen thread nur mehr oder wengier oberflächlich verfolgt.
Habe ich dabei etwas übersehen?
Dein Beispiel mit dem Kreis der in einer NC-Stuerung 10000 G-Code Zeilen braucht und in C 5 Zeilen heißt doch, Äpfel mit Birnen vergleichen.
Jede NC-Steuerung, die nicht gerade aus der Steinzeit stammt, kann doch Schleifen (auch wenn sie z.B. mit GOTOS realisert wrden müssen), so daß die Programmlängen NC-Sprache - C-Code für den Beispiel vergleichbar sind. Das das über die klassische Definition der DIN 66025 hinausgeht ist auch klar.
Es gibt seti Jahrzehnten Zyklen (= Unterprogrammtechnik), die es dem Anwender erlauben, komlexe Aufgaben wie z.B. das Fräsen einer Tasche mit einer Programmzeile zu erschlagen.
Und wenn jemand das Bedürfnis hat, ein allgemein verwenbares Programm zur Herstellung eines Kegels zu schreiben, so kann er das ebenfalls mit Bordmitteln tun, ohne dabei 10 Millonen NC-Sätze schreiben zu müssen.
Irgendwie habe ich den Eindruck, daß deine Referenz der Stand der NC-Technik der siebziger Jahre (oder früher) ist.
Habe ich dabei etwas übersehen?
Dein Beispiel mit dem Kreis der in einer NC-Stuerung 10000 G-Code Zeilen braucht und in C 5 Zeilen heißt doch, Äpfel mit Birnen vergleichen.
Jede NC-Steuerung, die nicht gerade aus der Steinzeit stammt, kann doch Schleifen (auch wenn sie z.B. mit GOTOS realisert wrden müssen), so daß die Programmlängen NC-Sprache - C-Code für den Beispiel vergleichbar sind. Das das über die klassische Definition der DIN 66025 hinausgeht ist auch klar.
Es gibt seti Jahrzehnten Zyklen (= Unterprogrammtechnik), die es dem Anwender erlauben, komlexe Aufgaben wie z.B. das Fräsen einer Tasche mit einer Programmzeile zu erschlagen.
Und wenn jemand das Bedürfnis hat, ein allgemein verwenbares Programm zur Herstellung eines Kegels zu schreiben, so kann er das ebenfalls mit Bordmitteln tun, ohne dabei 10 Millonen NC-Sätze schreiben zu müssen.
Irgendwie habe ich den Eindruck, daß deine Referenz der Stand der NC-Technik der siebziger Jahre (oder früher) ist.
31.01.2009, 20:09 Uhr
Es ist ein Tippfehler drin, erstmal richtig stellen:
float aufloesung=360/IRGENDWAS // Maschinenparameter für eingestellte Auflösung
float radius=50;
float winkel=0.0;
float z_schlepp=irgendwas
for (int j=0;j<5000;j++)
radius=radius+ größer oder kleiner, je nachdem wie man will
z_schlepp = größer oder kleiner je nachdem wie man will
for (int i=0; i<aufloesung;i++)
{
winkel=twinkel + aufloesung; // Winkelschritt
if (winkel>=360) winkel = winkel-360;
x[j].[i]=sin(winkel)*radius;y[j].[i]=cos(winkel)*radius;z[j].[i]= z_schlepp;
}
}
Also ich war ja am grübeln, wie G2 intern die Auflösung verwalten.
Jetzt ist es mir klar:
G2 schiebt die Auflösung rüber zur Maschine, auf die Schrittweiten in X und Y.
Das ist der einzige Grund, warum der Befehl so schlank ist.
Wenn wir statt G2 G1 programmieren, müssen wird die Kreisauflösung selbst definieren, wie schon lange weiter oben gesagt.
Da der G-Code sowieso so inflationär ist wie die Landeswährung von Timbuktu, kommt es darauf auch nicht mehr an.
Mit einer Auflösung von 360*10 legen wir 3600 Kreispunkte fest (das sollte schon einen ordentlichen Kreis geben) und wenn nicht, legen wir 360*100=36.000 Kreispunkte fest.
Macht dann pro Kreis 36.000 G1-Befehle.
Man sieht, das wird irgendwann kritisch mit der Inflation.
Wir wollen aber nicht den Staatshaushalt von Timbuktu sanieren, sondern überlegen, wie weit man damit kommt:
Der perfekte Superkreis, 36.000 G-Befehle pro Kreis (G1 !!!!!!), macht dann nach 1000 Kreisen 36.000.000 G-Befehle, da wird die Mach mit 10.000.000 schon lange aussteigen.
Würde man 1000 Kreise interaktiv mit einer Steuerung abarbeiten, würde gar keine Datei entstehen. Erforderlicher Speicherplatz: 0 Byte.
Schon von daher ist die interaktive STeuerung anstelle einer datei der Königsweg.
Und warum der G-code solche Dateigrößen braucht, ist rein historisch: Lochkartenmaschine.
Eine lochkartensteuerung kennt den Algorithmus einer Echtzeitsteuerung nicht, kann den gar nicht berücksichtigen.
Ich denke mal, die Hersteller von maschinensteuerungen kennen den aber sehr wohl, diesen Algorithmus, und arbeiten so, daß sie in Echtzeit steuern.
Sonst könnte man ja Stücke im Nanometerbereich auch gar nicht hinkriegen.
Lieber corrado:
Wenn die heutigen prof. Steuerung gut funktionieren, dann nicht
wegen dem G-code,
sondern trotz dem G-Code!
Gruß Sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 20:19 Uhr
float aufloesung=360/IRGENDWAS // Maschinenparameter für eingestellte Auflösung
float radius=50;
float winkel=0.0;
float z_schlepp=irgendwas
for (int j=0;j<5000;j++)
radius=radius+ größer oder kleiner, je nachdem wie man will
z_schlepp = größer oder kleiner je nachdem wie man will
for (int i=0; i<aufloesung;i++)
{
winkel=twinkel + aufloesung; // Winkelschritt
if (winkel>=360) winkel = winkel-360;
x[j].[i]=sin(winkel)*radius;y[j].[i]=cos(winkel)*radius;z[j].[i]= z_schlepp;
}
}
Also ich war ja am grübeln, wie G2 intern die Auflösung verwalten.
Jetzt ist es mir klar:
G2 schiebt die Auflösung rüber zur Maschine, auf die Schrittweiten in X und Y.
Das ist der einzige Grund, warum der Befehl so schlank ist.
Wenn wir statt G2 G1 programmieren, müssen wird die Kreisauflösung selbst definieren, wie schon lange weiter oben gesagt.
Da der G-Code sowieso so inflationär ist wie die Landeswährung von Timbuktu, kommt es darauf auch nicht mehr an.
Mit einer Auflösung von 360*10 legen wir 3600 Kreispunkte fest (das sollte schon einen ordentlichen Kreis geben) und wenn nicht, legen wir 360*100=36.000 Kreispunkte fest.
Macht dann pro Kreis 36.000 G1-Befehle.
Man sieht, das wird irgendwann kritisch mit der Inflation.
Wir wollen aber nicht den Staatshaushalt von Timbuktu sanieren, sondern überlegen, wie weit man damit kommt:
Der perfekte Superkreis, 36.000 G-Befehle pro Kreis (G1 !!!!!!), macht dann nach 1000 Kreisen 36.000.000 G-Befehle, da wird die Mach mit 10.000.000 schon lange aussteigen.
Würde man 1000 Kreise interaktiv mit einer Steuerung abarbeiten, würde gar keine Datei entstehen. Erforderlicher Speicherplatz: 0 Byte.
Schon von daher ist die interaktive STeuerung anstelle einer datei der Königsweg.
Und warum der G-code solche Dateigrößen braucht, ist rein historisch: Lochkartenmaschine.
Eine lochkartensteuerung kennt den Algorithmus einer Echtzeitsteuerung nicht, kann den gar nicht berücksichtigen.
Ich denke mal, die Hersteller von maschinensteuerungen kennen den aber sehr wohl, diesen Algorithmus, und arbeiten so, daß sie in Echtzeit steuern.
Sonst könnte man ja Stücke im Nanometerbereich auch gar nicht hinkriegen.
Lieber corrado:
Wenn die heutigen prof. Steuerung gut funktionieren, dann nicht
wegen dem G-code,
sondern trotz dem G-Code!
Gruß Sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 20:19 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
31.01.2009, 20:31 UhrQUOTE (CNCler @ Samstag, 31.Januar 2009, 20:05 Uhr)
Jede NC-Steuerung, die nicht gerade aus der Steinzeit stammt, kann doch Schleifen (auch wenn sie z.B. mit GOTOS realisert wrden müssen), so daß die Programmlängen NC-Sprache - C-Code für den Beispiel vergleichbar sind. Das das über die klassische Definition der DIN 66025 hinausgeht ist auch klar.
Es gibt seti Jahrzehnten Zyklen (= Unterprogrammtechnik), die es dem Anwender erlauben, komlexe Aufgaben wie z.B. das Fräsen einer Tasche mit einer Programmzeile zu erschlagen.
Und wenn jemand das Bedürfnis hat, ein allgemein verwenbares Programm zur Herstellung eines Kegels zu schreiben, so kann er das ebenfalls mit Bordmitteln tun, ohne dabei 10 Millonen NC-Sätze schreiben zu müssen.
Irgendwie habe ich den Eindruck, daß deine Referenz der Stand der NC-Technik der siebziger Jahre (oder früher) ist.
Es gibt seti Jahrzehnten Zyklen (= Unterprogrammtechnik), die es dem Anwender erlauben, komlexe Aufgaben wie z.B. das Fräsen einer Tasche mit einer Programmzeile zu erschlagen.
Und wenn jemand das Bedürfnis hat, ein allgemein verwenbares Programm zur Herstellung eines Kegels zu schreiben, so kann er das ebenfalls mit Bordmitteln tun, ohne dabei 10 Millonen NC-Sätze schreiben zu müssen.
Irgendwie habe ich den Eindruck, daß deine Referenz der Stand der NC-Technik der siebziger Jahre (oder früher) ist.
Wie macht sie denn die Schleifen?
Aber doch nicht in G-code.
Erklär doch mal, wie deine Steuerung Schleifen macht und in welcher Sprache das programmiert ist, das würde mich interessieren. Wenn du da steinzeitliche Zeilensprungbefehle drin hast mit goto vermute ich , deine Steuerung ist in Basic programmiert. Zu 99 Prozent ist das so.
2. Du kannst in G nicht mit einer Zeile eine komplette Tasche fräsen. Der Grund ist:
Die Anweisung G98 Ln
kann zwar die Funktion iterieren, und sie kann auch einen Versatz in der Ebene machen, sie kann aber nicht den Radius verändern oder ausräumen!
Wenn du davon redest, irgendwas in einer Zeile zu erschlagen, dann ist deine Steuerung so progammiert, daß sie exakt das tut, was ich jetzt schon tausendmal beschrieben habe, nämlich interaktiv neue G-Befehle zu erzeugen, und das ist auch genau der richtige Weg, weil man dafür keine Dateien braucht. Speicherplatz 0 Byte.
Ein Verdachtskanditat für deine Steuerung wäre Visual Basic. Wenn die schon 20 Jahre alt ist, vielleicht sogar Fortran. Mach dich mal schlau.
Mfg Sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 20:41 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
31.01.2009, 20:42 Uhr
Alle modernen Steuerungen können (hoffe ich doch!) Schleifen, z.B. bei der Siemens in der Art:
for Zaehler = 1 to 1000
g91 x0.1
endfor
Ob du das jetzt als "G-Code" bezeichen willst oder nicht ist eher Geschmackssache. Mir ist jedenfalls nicht bekannt, daß G-Code als Bezeichnung einer Programmiersprache irgendwo definiert wäre.
Ein Blick in die online Dokumentation
http://www.automation.siemens.com/doconweb...008_D&scope=all
und die Suche nach dem Begriff "Kontrollstrukturen" wird dir einen ersten Überblick geben.
for Zaehler = 1 to 1000
g91 x0.1
endfor
Ob du das jetzt als "G-Code" bezeichen willst oder nicht ist eher Geschmackssache. Mir ist jedenfalls nicht bekannt, daß G-Code als Bezeichnung einer Programmiersprache irgendwo definiert wäre.
Ein Blick in die online Dokumentation
http://www.automation.siemens.com/doconweb...008_D&scope=all
und die Suche nach dem Begriff "Kontrollstrukturen" wird dir einen ersten Überblick geben.
31.01.2009, 20:59 UhrQUOTE (CNCler @ Samstag, 31.Januar 2009, 20:42 Uhr)
Alle modernen Steuerungen können (hoffe ich doch!) Schleifen, z.B. bei der Siemens in der Art:
for Zaehler = 1 to 1000
g91 x0.1
endfor
Ob du das jetzt als "G-Code" bezeichen willst oder nicht ist eher Geschmackssache. Mir ist jedenfalls nicht bekannt, daß G-Code als Bezeichnung einer Programmiersprache irgendwo definiert wäre.
Ein Blick in die online Dokumentation
http://www.automation.siemens.com/doconweb...008_D&scope=all
und die Suche nach dem Begriff "Kontrollstrukturen" wird dir einen ersten Überblick geben.
for Zaehler = 1 to 1000
g91 x0.1
endfor
Ob du das jetzt als "G-Code" bezeichen willst oder nicht ist eher Geschmackssache. Mir ist jedenfalls nicht bekannt, daß G-Code als Bezeichnung einer Programmiersprache irgendwo definiert wäre.
Ein Blick in die online Dokumentation
http://www.automation.siemens.com/doconweb...008_D&scope=all
und die Suche nach dem Begriff "Kontrollstrukturen" wird dir einen ersten Überblick geben.
Hallo CnCler,
ich hab jetzt mal einen ersten Blick auf die Sinumeric geworfen.
Das ist ja ein Hammerteil!
Das gibt´s ja gar nicht, was die da alles realisiert haben!
Zwischen Sinumeric und Mach3 liegen keine welten, sondern ein ganzes Universum!
Wenn du sowas auf der Steuerung verfügbar hast, kann da ja (fast) gar nichts mehr schief gehen.
Ist aber so erstaunlich auch nicht, geht ja um Produktion, Profit. Da muß das passen.
Mit einer sinumeric auf der Platte spielt der G-code nun echt keine Rolle mehr. Jetzt verstehe ich, was du sagen wolltest.
Frag doch deinen local siemens außendienstler mal, in welcher Sprache das programmiert wurde. Der weiß das bestimmt nicht, könnte sich aber erkundigen.
Die Verdachtskandidaten wären Basic, Fortran oder Algol. An C oder Pascal glaube ich weniger wegen der grauenhaften Sprungbefehle.
MfG Sharky
Der Beitrag wurde von sharky bearbeitet: 31.01.2009, 21:09 Uhr
--------------------
A programmer is just a tool which converts caffeine into code
2 Besucher lesen dieses Thema (Gäste: 2) 0 Mitglieder: |
