Ablauf für Fräsmaschine programmieren

[100nF]

ja super, ich glaube die Kommunikation in eine Richtung (PC -> µC) funktioniert schonmal!!
Dann werde ich jetzt noch die andere Richtung vornehmen, und dann hab ich schonmal ein Fundament

Das mit dem GCode-FiFo hab ich mir so in dieser Art vorgestellt, ist im RN-Wissen ja sehr gut beschrieben!

Zitat:

Ich werde vermutlich bei Kreisen den Fifo auch umformatieren, damit ich mehr als sieben Schritte puffern kann. (Mein Fifo kann mit max. 255 Bytes umgehen, drei int32_t für drei Achsen macht 36 Byte für einen Punkt).

Also ich glaube ich kann so ein grosses Array erstellen, wie es das RAM vom µC zulässt (laut Dokumentation).

Ich habe aber grad noch gesehen, dass man mehrdimensionale Arrays verwenden kann, wäre das nicht sehr nützlich in dieser Hinsicht? Die Erste Dimension kann z.B. den Befehl angeben (z.B. G01 aber in vereinfachter Form -> 1 Byte gross), und 3 weitere dimensionen geben X, Y, und Z-Position an. Allerdings müsste ich dafür ein Array of Integer nehmen um genügend grosse Zahlen speichern zu können (Maximum ist 65535 - bei einer Genauigkeit [1 Schritt] von 0,005mm gäbe das einen Verfahrensweg von 327mm).

Bei M-Befehlen oder so Sachen müsste man halt für jeden befehl eine Zahl zuordnen, damit man mit einem Integer-Array arbeiten kann, aber der PC vereinfacht den G-Code ja sowieso, dann kann er ja auch gleich alles in Zahlen angeben.

Oder bin ich da vollkommen auf dem Holzweg?

mfg
Urban

EDIT: Array of Single wäre vermutlich besser - ein Single ist 32Bit, ein Integer nur 16.

[markusj]

Zitat von urbanbruhin:

ja super, ich glaube die Kommunikation in eine Richtung (PC -> µC) funktioniert schonmal!!
Dann werde ich jetzt noch die andere Richtung vornehmen, und dann hab ich schonmal ein Fundament

Gratuliere!

Zitat von urbanbruhin:

Ich habe aber grad noch gesehen, dass man mehrdimensionale Arrays verwenden kann, wäre das nicht sehr nützlich in dieser Hinsicht? Die Erste Dimension kann z.B. den Befehl angeben (z.B. G01 aber in vereinfachter Form -> 1 Byte gross), und 3 weitere dimensionen geben X, Y, und Z-Position an. Allerdings müsste ich dafür ein Array of Integer nehmen um genügend grosse Zahlen speichern zu können (Maximum ist 65535 - bei einer Genauigkeit [1 Schritt] von 0,005mm gäbe das einen Verfahrensweg von 327mm).

Bei M-Befehlen oder so Sachen müsste man halt für jeden befehl eine Zahl zuordnen, damit man mit einem Integer-Array arbeiten kann, aber der PC vereinfacht den G-Code ja sowieso, dann kann er ja auch gleich alles in Zahlen angeben.

Oder bin ich da vollkommen auf dem Holzweg?

Jein
Wie die Vereinfachung von mir angedacht war, hast du schon Begriffen. Ich bin mir aber noch nicht ganz darüber im klaren, wie ich die G-Codes zwischenspeichere.
Das Problem ist, dass du hier schon von multidimensionalen Arrays träumst, du hast es aber mit einem µC zu tun, da hast du nicht viel RAM!
Mein ATMega168 hat 1KB SRAM, dein ATMega128 bietet dir das vierfache.

Deshalb gibt es bei nur einen einzigen Satz FiFo-Funktionen, der mit Bytes (uint8_t) arbeitet und die Möglichkeit bietet, "items" aus mehreren Bytes zu speichern. Für die RS232-Kommunikation ist das etwas überdimensioniert, ich kann den gleichen Code aber auch nutzen, um G-Code oder Motion-Control Datensätze (Structs, in Delphi Record) ablegen.

So kann ich zum Bleistift für die Motion-Control bei kleineren Schritten (Kreis!) dann Byte-große Bewegungsparameter verwenden, wenn ich wieder Linien mit einem größeren Bewegungsfeld und größeren Werten, dann benutze ich das selbe Array mit anderer Fifo-Konfiguration für weniger aber größere Datensätze.

Auf jeden Fall läuft es auf ein Array of Record raus, ich bin nur noch am überlegen, wie ich das ganze mit unterschiedlich großen Records vereinbaren kann. Einfach nur ein Array of int oder ähnlichem halte ich für nicht den richtigen Weg.

Wie gesagt, im Moment bin ich gerade dabei, die ganzen Fälle und Möglichkeiten durchzuspielen und mir ein Bild davon zu machen, wie ich den "arbeitenden" Teil der Firmware stricke.

mfG
Markus

PS: Noch ein wichtiger Punkt: Meide Fließkommaarithmetik (single) wie der Teufel das Weihwasser. Wenn du anfängst, zu dividieren oder sonstige Berechnungen mit Fließkommazahlen anzustellen, kannst du jegliche Träume von hohen Geschwindigkeiten komplett knicken.
Diese Operationen dauern im Vergleich zu den normalen Integer-Typen vielfach länger, vor allem die Kreisberechnung könntest du damit knicken, da schaffst du keine 80.000 Schritte in der Sekunde (für Kreise mit einem Radius kleiner 10.000 Schritte), die ich im Moment bei 20Mhz erreiche.

[100nF]

aaaaalso ich fang jetzt schonmal langsam mit dem mechanischen Aufbau an.
Das problem ist jetzt, ich muss wissen welche Steigung die Gewindestangen haben müssen.
Dafür brauche ich ja folgende Angaben:
- Genauigkeit (mm pro Schritt)
- Schritte pro Umdrehung

(theoretische) Genauigkeit: Hier würde ich mal auf 0,01mm tippen?! Ich weiss echt nicht was da angebracht ist. Ich will die Fräse halt fürs Platinen fräsen/bohren und bisschen zum Gravieren von verschiedensten Sachen benutzen. Um auch eine möglichst grosse Vorschubgeschwindigkeit zu erreichen, sollte die Genauigkeit ja möglichst "gross" (ungenau) gewählt werden, doch ich möchte immernoch mühelos genaue Platinen fräsen können.

Schritte pro Umdrehung: Da bin ich mir auch nicht so ganz sicher... die Motoren haben einen Schrittwinkel von 0,9°, was 400 Schritte pro Umdrehung macht. Doch dann gibt es ja noch Halbschritt? Mikroschritt? hab ich dann plötzlich 800 Schritte pro Umdrehung? oder sind die 400 Schritte im Mikroschrittbetrieb? Mir welcher Schrittzahl muss ich nun rechnen?

Bei 400 Schritten pro Umdrehung und 0,01mm Genauigkeit bräuchte ich also eine Steigung von 4mm. Ich brauche diese information nun möglichst schnell, da ich mir solche Wellen vermutlich bei ebay kaufe und das dauert jeweils eine Ewigkeit bis ich die dann habe...

mfg

[markusj]

Öhm, keine Ahnung: Du wirst abhängig von deiner Lagerung sowieso viel niedrigere Genauigkeiten erreichen.
Ich plane im Moment mit 1mm je Umdrehung, das ganze hängt halt auch von deinen Schrittmotoren ab.
Irgendwo musst du Anfangen, mein Anfang waren die Schrittmotoren die ich günstig "geschossen" habe und bis etwas 1500U/min nicht wirklich an Kraft verlieren.
Die angegebene Gradzahl gilt für den Vollschrittbetrieb, im Halbschrittbetrieb verdoppelt sich die Anzahl der Schritte, im Viertelschrittbetrieb vervierfacht sie sich etc.
Je nach dem, wie du deinen Aufbau auslegst, welche Fräser und welche Spindel du verwendest, wirst du vermutlich sowieso keine hohen Geschwindigkeiten erreichen!

Rechen auf jeden Fall damit, dass du aufgrund des Materials oder der Fräse keinen hohen Vorschub fahren wirst. "Bastelfräsen" liegen in der Regel nicht über 300mm/min, würde ich jetzt einfach mal so Tippen.
Besser wirst du bei solchen mechanischen Fragen aber sicher im Roboternetz, die passenden Threads dazu gibt es schon.

Ich selbst bin im Moment mit anderen Problemen beschäftigt. Einen Teil der alten Firmware-Architektur habe ich über den Haufen geworfen.
Die Schrittmotorsteuerung ist eine gute Portion "dümmer" und nicht mehr in der Lage, Linien zu fahren (konnte sie sowieso nie richtig, das war ein Denkfehler meiner Wenigkeit).
Stattdessen übernimmt sie "nur" noch die Beschleunigungs- und Bremsrampen, die Positionsüberwachung, Kalibrierfunktionen, die Korrektur von Umkehrspiel und evtl. auch noch anderen Fehlern. Insgesamt also die Dinge, die tatsächlich Hardwarenah sind.
Die Zwischenschicht besteht nun aus dem G-Code-Interpreter und dem Rasterungssystem.
Insbesondere letzteres bereitet mir im Moment wieder Kopfzerbrechen, da 3D-Kreise (also helixförmige Gebilde) eine Abstimmung mit der Kreisposition erfordern, und ich bisher noch nicht berechnet habe, wie viele Schritte der Kreis hat.
Dafür brauche ich jetzt eine schnelle und performante Lösung (<> durchsimulieren).
Und den Linienalgorithmus muss ich auch 3D-tauglich machen *hmpf*

mfG
Markus

[100nF]

Okay, also Schrittmotoren hab ich schon, und bei 400 Schritten/Umdrehung werde ich wohl eine Steigung von 3 bis 5 mm brauchen...

Ich wollte übrigens mal ausprobieren, den G-Code für Ausfräsungen der Platine erzeugen zu lassen, doch ich kriegs nicht hin?! Und auch Schriftzüge usw. wollte ich mal ausprobieren. Muss ich da jeweils nur den richtigen Layer wählen? Was wären denn die entsprechenden Layer? Beim pcb_gcode-Setup habe ich die entsprechenden Haken gesetzt, doch die Fräsdateien bleiben einfach leer.

mfg
Urban

[markusj]

Kann ich spontan nicht nachvollziehen, meine Glaskugel ist kaputt
Ich hatte einfach den Setup einmal abgenickt (G-Code-Stil Generic, der Rest eigentlich unverändert) und konnte dann das Board mit "run pcb-gcode" oder über das Menü/ULP ausführen die Files dann erstellen (vier .nc-Files).
Auf der Website von pcb-gcode gibt es aber nachdem was ich gesehen habe eine recht gute Doku, wenn nicht, ein Forum gibt es dort auch!

mfG
Markus (Immer noch damit beschäftigt, die Anzahl der nötigen Schritte für einen Kreis zu ermitteln ... Der Bresenham für Linien ist übrigens wieder vom Tisch)

[100nF]

macht eigentlich der G-Code-Stil viel aus?
Ich weiss nicht was ich da nehmen soll, hab da mal den genommen der bei irgendeiner Internetseite auch verwendet wurde...

ich habe übrigens nicht ganz verstanden was du da umkrempelst?!

Zitat:

...Bresenham für Linien...

mfg
Urban

[markusj]

Du musst anfangs afaik einen "Dialekt" wählen, teilweise wird da auf Eigenheiten der jeweiligen Software eingegangen.
Ich habe "generic" gewählt und ansonsten nichts in den Settings geändert.
Es gibt aber auch einen Button "Reset to factory defaults", dann könntest du es einfach noch einmal von vorne einstellen.

Zu meinen Änderungen (Bresenham für Linien ist übrigens wieder vom Tisch):
Bisher sollte die Motoransteuerung selbst in der Lage sein, Linien zu fahren. Die Bewegung wäre direkt in der Interruptroutine ermittelt worden, so wie ich es dir anfangs erklärt hatte.
Nun lagere ich das ganze aus und berechne das ebenfalls in der Hauptschleife.
Die ISR bekommt nur noch einen Byte-Fifo, der direkt die Ansteuerungswerte der Portpins beinhaltet.

mfG
Markus

[100nF]

ach so, naja klingt auch nicht schlecht...
nur ist das wieder ein zusätzliches FiFo, welches wieder überwacht werden muss usw.

Ich werde es mal auf die "alte" Variante versuchen - oder gabs da irgendwelche grossen Probleme?

mfg
Urban

[markusj]

Den Fifo gab es vorher auch schon.
Nur hat der vorher die Informationen Anzahl zurückzulegender Schritte, die Anzahl der zu wartenden Zeitscheiben, sowie evtl. auch noch den aktuellen Zählerwert.
Tatsächlich ist die Variante vermutlich wesentlich einfacher und effektiver, ich muss weder den FiFo umformatieren, noch Zählerwerte vergleichen. Tatsächlich finden nur die nötigen Vergleiche statt, die Berechnungen zur Überwachung der Zielposition ebenfalls.
Die ISR fällt also wesentlich einfacher aus, außerdem ist es mir so möglich, die Beschleunigungs- und Bremsrampen unabhängig von den G-Codes direkt in der Motoransteuerung zu platzieren.

mfG
Markus