Lord-Maricek - Do 19.08.10 16:29
Titel: Abarbeitung von G-Code

---

Hi,

ich baue gerade mit einem Freund eine CNC Fräse. Dazu schreibe ich jetzt eine Software. Ich muss dazu einen G-Code einlesen, dass ist ein spezieller Code, indem die Eckkoordinaten, des zu fräsenden Modells drin stehen. Der sieht ungefähr so aus.

Für mehr Infos, hier Klicken.http://en.wikipedia.org/wiki/G-code

In dem G-Code stehen noch mehr Infos drin, aber ich brauche nur die, mit G0 und G1 davor. G0 ist, wenn die Fräse im Leerlauf, in eine Ausgangsposition fährt, und G1 ist das eigentliche Fräsen.
Das Problem ist, dass der G-Code meistens <10000 Zeilen für kleinere Modelle und teilweise sogar <1.000.000 Zeilen für größere Modelle hat.
Ein weiteres Problem ist, dass das immer nur die Start und Endkoordinaten für Strecken sind, und ich für die CNC aber ca. alle 0.01mm einen Punkt benötige. Die errechne ich mit Vektor Berechnungen, aber die Anzahl der Punkte ist das Problem. Für einen cm benötige ich dann schon 100 Punkte. Ich habe mir das bisher so überlegt, dass ich die richTextBox Zeile für Zeile auslese und für jede Zeile ein Objekt anlege und das in einem Array speichere. Das Objekt ist für die Klasse, die ich für die Errechnung der Punkte erstellen werde. In der Klasse werden dann immer Start und Zielkoordinaten gespeichert, und dann werden mit einer Vektorrechnung die zwischen Punkte errechnet. Auch habe ich noch das Problem, dass ein Array maximal 10.000 Felder haben darf. Aber wenn ich +10.000 Zeilen habe, wird das ziemlich Problematisch.
Was haltet ihr von meiner Idee, oder habt ihr Verbesserungsvorschläge?
Wie kann ich das mit dem Objekt Array am einfachsten lösen?

MfG
Philipp

elundril - Do 19.08.10 16:33

---

Naja, ich würd die zwischenpunkte zwischen 2 Eckpunkten gar nicht speichern sondern onthefly berechnen und das wars. Damit sparst du dann etwas speicherplatz weil du immer nur konstant 1 temporäres Element brauchst. Gute Idee, oder eher zum vergessen?

lg elundril

Critter - Do 19.08.10 17:38

---

Hi,

wenn ich das richtig sehe wird die Datei ja immer Sequenziell abgearbeitet, somit würde ich sie auch einfach Zeile für Zeile einlesen (Stichworte Textfile und ReadLn), die jeweils Aktuelle Zeile abarbeiten und dann wieder vergessen. So kann es dir Egal sein, wie viele Zeilen eine Datei hat, du kennst ohnehin immer nur eine. Auf Stringlisten oder gar eine RichTextBox würde ich verzichten, zumindest, solange der user die Daten nicht Live eintippen soll. Wenn es dir dann noch gelingt wie vorgeschlagen die Zwischenpunkte on the Fly zu Berechnen ist der Speicherverbrauch absolut zu vernachlässigen. Selbst wenn es nicht klappt, musst du immer nur die Punkte für eine Strecke im Speicher halten, was auch zu verschmerzen sein sollte.

//Edit: Ups, Sorry. War im Delphi nicht in C#. Aber hier findest du ein Beispiel [http://www.computerleben.net/artikel/Datei_zeilenweise_auslesen-283.html] wie du in C# eine Textdatei Zeile für Zeile lesen kannst. Anstelle von Console.WriteLine(line); setzt du da dann einfach etwas wie MeinInterpreter.InterpretiereZeile(line); ein.

critter

Kha - Do 19.08.10 18:00

---

Da kann ich meinen zwei Vorrednern nur zustimmen - wenn du elundrils Vorschlag mit File.ReadLine/StreamReader kobinierst, ist dein Speicher komplett unabhängig von der Dateigröße :) .

Lord-Maricek hat folgendes geschrieben :

Auch habe ich noch das Problem, dass ein Array maximal 10.000 Felder haben darf.

Wie meinen? Eigentlich ist die Grenze 2GB :gruebel: .

BenBE - Do 19.08.10 23:20

---

Kha, nicht ganz: Die Grenze ist der in einem Block zusammenhängend alloziierbare Speicher ... Unter 64 Bit dürfte man da so ungefähr einmal die Erde und ne Hyperraum-Umgehungsstraße mit phräsen können ...

Ansonsten schon wie gesagt: Speicher nur die nötigen Daten zwischen, die Du wirklich im Speicher halten musst. Deine Idle-Position, den vorigen Vektor, den nächsten Zielvektor, die aktuelle Position und nen Vektor zur Fehlerkorrektur. Ansonsten das Vorgehen wie von den anderen bereits genannt.

Visuelle Controls zum Speichern von Daten sind nicht nur aus Performance-Sicht ein No-Go.

Kha - Sa 21.08.10 09:55

---

BenBE hat folgendes geschrieben :

Kha, nicht ganz

Doch, unter der CLR schon ;) .