Autor Beitrag
Lord-Maricek
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 17



BeitragVerfasst: Do 19.08.10 16:29 
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.
ausblenden Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
G0 Z  15.000 
G0 X  12.879 Y  27.201
G0 Z   3.000 
G1 Z  -1.500
G1 X  12.879 Y  27.462
G1 X  13.160 Y  27.293
G1 X  13.139 Y  27.171
G1 X  13.144 Y  26.768

Für mehr Infos, hier Klicken.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
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3747
Erhaltene Danke: 123

Windows Vista, Ubuntu
Delphi 7 PE "Codename: Aurora", Eclipse Ganymede
BeitragVerfasst: 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

_________________
This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.
Critter
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 328
Erhaltene Danke: 3

Windows 7
Delphi 7 Pro.
BeitragVerfasst: 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 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

_________________
Diejenigen, die grundlegende Freiheiten aufgeben, um ein wenig mehr vorrübergehende Sicherheit zu erkaufen, verdienen weder Freiheit noch Sicherheit.
(Benjamin Franklin;"The Papers of Benjamin Franklin", Vol. 6, Apr. 1, 1755, through Sep. 30, 1756)
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Do 19.08.10 18:00 
Da kann ich meinen zwei Vorrednern nur zustimmen - wenn du user profile iconelundrils Vorschlag mit File.ReadLine/StreamReader kobinierst, ist dein Speicher komplett unabhängig von der Dateigröße :) .

user profile iconLord-Maricek hat folgendes geschrieben Zum zitierten Posting springen:
Auch habe ich noch das Problem, dass ein Array maximal 10.000 Felder haben darf.
Wie meinen? Eigentlich ist die Grenze 2GB :gruebel: .

_________________
>λ=
BenBE
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 8721
Erhaltene Danke: 191

Win95, Win98SE, Win2K, WinXP
D1S, D3S, D4S, D5E, D6E, D7E, D9PE, D10E, D12P, DXEP, L0.9\FPC2.0
BeitragVerfasst: 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.

_________________
Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.
Kha
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 3803
Erhaltene Danke: 176

Arch Linux
Python, C, C++ (vim)
BeitragVerfasst: Sa 21.08.10 09:55 
user profile iconBenBE hat folgendes geschrieben Zum zitierten Posting springen:
Kha, nicht ganz
Doch, unter der CLR schon ;) .

_________________
>λ=