Ablauf für Fräsmaschine programmieren

[markusj]

Meine Platinen sind nach der Fädel-Methode entstanden ;) Alles Lochraster, gequetscht auf eine Größe von 7*5cm. Jede Platine hat einen zehnpoligen Buchsenstecker, der nahezu alle Funkionen des L287 herausführt, plus einen Satz Jumper, mit denen man das meiste vorkonfigurieren kann (und so Pins spart).
Ich habe dann noch eine großzügig bemessene Adapterplatine, die die einzelnen Module übereinander anordnet und nur die Leitungen für Takt, Richtung und Stromversorgung des Logikteils herausführt.
Bei Interesse kann ich später mal "Pigs" machen.

Zu der Sache mit Threads: Wie schon erwähnt, ein AVR kann eigentlich kein Multithreading. Die Implementationen die es so gibt, tricksen ein wenig.
Sie nehmen sich einen Timer als Interruptquelle und jedes Mal, wenn der Interrupt auftritt, wird die aktuelle Funktion unterprochen. Normalerweise kehrt der AVR nach einem Interrupt wieder zur ursprünglichen Funktion zurück. Wenn man die Rücksprungadresse jetzt aber auf den letzten Zustand des zweiten Threads umbiegt, läuft plötzlich dieser!
Tatsächlich wird aber immer nur zwischen den verschiedenen Funktionen hin und her gewechselt ... und oh Überraschung: Das kann ich auch, sogar ohne Interrupt. Dafür müssen command_decode und der gcode_preprocessor nur so aufgebaut sein, dass sie freiwillig nach einem Schritt die Kontrolle wieder zurückgeben.
=> Sie müssen ihren aktuellen Zustand im Speicher hinterlegen und beim nächsten Aufruf wiederherstellen.

Da du nicht weißt, wie die "Threads" getaktet sind, kannst du diese eher schlecht für das RS232 Senden/Empfangen verwenden. Vor allem produzierst du dabei eine unnötige Prozessorlast, die du gut an anderen Stellen brauchen könntest.
Ein Interrupt dagegen "kommt" nur, wenn er gebraucht wird. Er erledigt seine Arbeit schnell und schmerzlos und verschwindet danach in der Versenkung.

mfG
Markus

[100nF]

lol, okay so kann man platinen auch herstellen xD
Fotos wären super! :D

Hier mal ein Ausschnitt aus der Bedienungsanleitung:

Zitat:

Multithreading
Unter Multithreading versteht man die quasi parallele Abarbeitung mehrerer Abläufe in einem
Programm. Einer von diesen Abläufen wird Thread (engl. Faden) genannt. Beim Multithreading
wird in schnellen Abständen zwischen den verschiedenen Threads gewechselt, so daß beim
Anwender der Eindruck von Gleichzeitigkeit entsteht.
Die C-Control Pro Firmware unterstützt außer dem Hauptprogramm (Thread "0") bis zu 13
zusätzliche Threads. Beim Multithreading wird nach einer bestimmten Anzahl von verarbeiteten
Byte Instruktionen der aktuelle Thread auf den Status "inaktiv" gesetzt und der nächste
ausführbare Thread wird gesucht. Danach startet die Abarbeitung des neuen Threads. Der neue
Thread kann wieder derselbe wie vorher sein, je nachdem wie viele Threads aktiviert wurden oder
für eine Ausführung bereit sind. Das Hauptprogramm gilt als erster Thread. Daher ist Thread "0"
immer aktiv, auch wenn explizit keine Threads gestartet worden sind.
Die Priorität eines Threads kann beeinflußt werden, in dem man ändert, wie viele Bytecodes ein
Thread bis zum nächsten Threadwechsel ausführen darf (siehe Threadoptionen). Je kleiner die
Anzahl der Zyklen bis zum Wechsel, desto geringer die Priorität des Threads. Die Ausführungszeit
eines Bytecodes ist im Mittel 7-9 μsec. Bei einzelnen Bytecode Befehlen dauert es jedoch länger,
z.B. Floatingpoint Operationen.
Auch interne Interpreterfunktionen gelten als ein Zyklus. Da z.B. Serial_Read wartet, bis ein
Zeichen von der seriellen Schnittstelle ankommt, kann in Ausnahmefällen ein Zyklus sehr lange
dauern.
Ein Thread bekommt für seine lokalen Variablen soviel Platz wie ihm in den Threadoptionen des
Projekts zugewiesen wird. Eine Ausnahme ist Thread "0" (das Hauptprogramm). Dieser Thread
erhält den restlichen Speicherplatz, den die anderen Threads übrig lassen. Man sollte daher
vorher planen, wie viel Speicherplatz jeder zusätzliche Thread wirklich benötigt.
Damit zusätzliche Threads gestartet werden können muß "Multithreading" in den
Projektoptionen eingeschaltet werden, und die Parameter für die weiteren Threads in den
Threadoptionen auf korrekte Wert gesetzt werden.
Beim arbeiten mit Threads immer Thread_Delay und nicht AbsDelay benutzen. Wird trotzdem
z.B. ein AbsDelay(1000) benutzt, so tritt folgender Effekt auf: Da der Thread erst nach 5000 Zyklen
(Default Wert) zum nächsten Thread wechselt, würde der Thread 5000 * 1000ms (5000 Sek.)
laufen, bis der nächste Thread anfangen könnte zu arbeiten.

Wenn ein Thread ein Weilchen nicht gebraucht wird, kann ich den auch deaktivieren, damit keine Rechenzeit verloren geht. Aber das war nur mal eine Idee, mit Threads zu arbeiten - ob die Idee schlecht oder gut ist weiss ich noch nicht genau^^

Ausserdem bin ich mir nicht sicher, ob das mit der Kommunikation bei mir gleich funktioniert wie bei dir. Ich habe nämlich gelesen, dass intern schon eine FiFo verwendet wird, und dazu muss ich eine globale Variable zur Verfügung stellen. Ausserdem muss ich die Grösse des Empfangs- und des Sendepuffers angeben. Somit wird irgendwie das, was du machen willst, teilweise schon intern ausgeführt?!

mfg
Urban

[markusj]

Das Problem ist, dass dieses Multithreading dem Echtzeitanspruch, den die Umsetzung der G-Codes in der Fräse stellt, möglicherweise nicht gerecht wird. Das wirst du aber ausprobieren müssen.
Zu der Sache mit den FiFos: Möglicherweise kapselt C-Control das ganze schon in einen Fifo, du könntest dann direkt mit command_decode an den C-Control-Fifo "connecten".
Die Fifo-Größe musst du natürlich selbst setzen, bei mir liegt die bei 50 Byte Receive und 25 Byte Transmit. Sind aber erst einmal nur experimentelle Werte, die noch nie getestet wurden.

mfG
Markus

PS: Pigs folgen noch.

[100nF]

ja ich glaub das ist shcon so wie ich mir das vorgestellt habe...
Ich denke dann müsste ich aber den Sendepuffer auf 1 Byte einstellen, damit auch jede Fehlermeldung sofort verschickt wird?! (Die Fehlermeldungen werden wohl nie mehr als 1 Byte beanspruchen denke ich mal, ansonsten muss ich halt den Sendepuffer doch weiter hochschrauben und dann halt auch bei kleinen Mitteilungen den ganzen Puffer füllen damit es auch verschickt wird)

Ich hab jetzt schonmal einen Teil des Kommunikations-Zeugs programmiert.
Bei der Erstellung der FiFo für den G-Code habe ich aber noch eine Frage. Also Linien sind klar, die werden einfach 1:1 in die FiFo geschrieben. Die Kreise werden jedoch berechnet, und es werden sehr viele kurze Linien in die FiFo geschrieben. Diese Berechnung, die wird schon in einem Durchgang vollständig berechnet oder? Oder wird da irgendwie bei jedem Zyklus wieder ein einziger Schritt in den G-Code-FiFo geschrieben? Und wenn der G-Code-FiFo während der Kreisberechnung voll ist, wird solange gewartet bis wieder ein Befehl ausgeführt wurde und somit ein Platz im Array frei geworden ist?

mfg
Urban

[markusj]

Das Protokoll vom µC zum PC ist das selbe wie vom PC zum µC, ein Byte TX-Fifo (würde ich eher Puffer nennen ;)) reicht also definitiv nicht, die kleinste Nachricht besteht ja aus sechs Bytes.

Zur Kreisberechnung: Der Bresenham-Algorithmus rechnet immer einen Schritt aus. Wenn der G-Code Präprozessor in seinen Statusvariablen stehen hat, dass er noch Punkte in einem Kreis berechnen muss, wird dieser nachsehen ob der FiFo noch voll ist und bei Bedarf einige Punkte berechnen und in den Fifo füllen.
Wenn er dann mit dem Kreis durch ist, nimmt er sich den nächsten G-Code vor.
Ansonsten tut der Präprozessor einfach nichts und command_decode wird wieder von "main" aufgerufen.

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).

mfG
Markus

PS: Mein Scanner ist im Moment leider ... demontiert, daher kann ich dir meine Platinenplanung im Moment nicht hochladen.
PPS: Sorry für die Quali, ist halt nur von meiner Notebook-Knipse

[100nF]

okay, ja das mit dem Protokoll ist mir auch noch eingefallen, dass das das selbe sein soll in beide Richtungen :mrgreen:

Das mit den Berechnungen hab ich so vermutet. Gibt zwar wieder bisschen was zu überlegen, aber ist bestimmt nicht unmöglich :D

Beim G-Code-FiFo: Wenn da eine Anweisung ausgeführt wurde, werden dann alle Bytes von der letzten Anweisung gelöscht und der Rest ganz nach vorne verschoben?

Und danke noch für die Fotos, sieht echt geil aus :D Ich glaub ich werde es dann auch mal auf Punktraster versuchen...

hmmm...irgendeine Frage hatte ich noch...hab Sie aber vergessen :gruebel:
naja ist ja auch egal.

mfg
Urban

EDIT:
ach jetzt ist es mir schon wieder in den Sinn gekommen :D
wie wird die Prüfsumme genau berechnet? Genügt für diese Information ein Byte?

[markusj]

Zum G-Code-Fifo: Es ist viel einfacher, du verschiebst nur den Pointer.
Zur Prüfsumme: Du addierst alle Bytes vom Startbyte bis zum Checksummenbyte, negierst das ganze und addierst eins.
Beim Empfangen musst du nur alle Bytes wieder aufaddieren, das Ergebnis sollte dann Null sein.
Ach ja, du addierst in ein Byte, sprich mit Überlauf. Dementsprechend kommt auch nur ein Byte heraus.

mfG
Markus

PS: Danke für das Lob. Ich hab an dem Layoutentwurf lange gearbeitet, um alle Funktionen des L297 bereitzustellen. Tatsächlich nutze ich davon nur die Takte- und den Richtungseingänge.

[100nF]

Zitat:

Zum G-Code-Fifo: Es ist viel einfacher, du verschiebst nur den Pointer.

Also beim ersten Befüllen wird ganz normal "von unten nach oben" aufgefüllt. Und sobald das Array voll ist, wird wieder das erste Byte überschrieben und sozusagen von vorne begonnen? mit Pointer meinst du einfach eine Varieble die sich merkt, welcher Befehl gerade ausgeführt wird?

Zitat:

Zur Prüfsumme: Du addierst alle Bytes vom Startbyte bis zum Checksummenbyte, negierst das ganze und addierst eins.

Hmm in Delphi hab ich das noch nicht richtig hingekriegt...

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  b1, b2, b3, b4, b5, bn, bx: byte;
  i: integer;
begin
  b1 := ord(strtoint(edit2.text));
  b2 := ord(strtoint(label13.caption));
  b3 := ord(strtoint(edit4.text));
  b4 := ord(strtoint(edit6.text));
  b5 := ord(strtoint(edit3.text));

  for i := 1 to length(edit5.Text) do
    if I = 1 then
      bn := ord(edit5.text[i])
    else
      bn := bn + ord(edit5.text[i]);

  bx := ((b1+b2+b3+b4+b5+bn)*(-1));

  label14.caption := inttostr(bx);
end;

Schlussendlich krieg ich gar keine negative Zahl?! Aber das liegt vermutlich daran dass ein Byte kein Vorzeichen enthält oder? Und per RS232 kann man doch eh nur 0 bis 255 verschicken oder nicht?

Wie hast du dir denn das genau vorgestellt?

mfg
Urban

EDIT: aah oder meinst du mit "negieren", die erhaltene Zahl von 255 (oder256?) abziehen?

EDIT2: Bei einem Werkzeugwechsel wird ja eine Benutzereingabe verlangt, dass das Programm weiterläuft. Machst du diese Hardwaremässig (Taster) oder am PC mit einem Button? Ich tendiere da vorläufig eher zu einem Button, später werde ich das aber vermutlich Hardwaremässig noch realisieren. Ich habe nämlich vor, einen alten PC ohne Bildschirm usw. zu verwenden, wo ich dann einfach einen USB-Stick mit dem Programm reinstecken kann und der PC das automatisch ausliest und die Fräse startet. Aber vorläufig mach ich das mal mit meinem eigenen PC...

[jokerfacehro]

Zitat:

Tatsächlich muss der AVR aber die ganze Zeit darüber bescheid wissen, wo er gerade steht und wohin er fährt.

Das war es doch, was du mit Merker meintest, oder?

jop und ob die fräse aufsetzt oder darüber schwebt und am besten en log mitführen

ne havarie funktion wäre angebracht (also not-aus), wenn falsches oder undefiniertes verhalten der maschine bemerkt wird und natürlich für die sicherheit.

[markusj]

Zitat:

Zitat von urbanbruhin

Zitat:

Zum G-Code-Fifo: Es ist viel einfacher, du verschiebst nur den Pointer.

Also beim ersten Befüllen wird ganz normal "von unten nach oben" aufgefüllt. Und sobald das Array voll ist, wird wieder das erste Byte überschrieben und sozusagen von vorne begonnen? mit Pointer meinst du einfach eine Varieble die sich merkt, welcher Befehl gerade ausgeführt wird?

Der FiFo besteht aus einem Array und ein paar Zusatzinformationen. Du hast zwei Zeigervariablen, die auf das nächste zu lesende/schreibende Byte zeigen. Schreibst du jetzt eine G-Code-Struktur, wird der Schreibzeiger am Ende auf den nächsten freien Platz zeigen, ist er am Ende des Arrays, wird er wieder auf den Anfang gesetzt. Liest du aus dem Fifo, wird der Schreibzeiger weitergeschoben.
RN-Wissen: Fifo mit avr-gcc
Bei Interesse kann ich auch einmal meine Fifo-Implementierung anhängen.

Zitat:

Zitat von urbanbruhin

Hmm in Delphi hab ich das noch nicht richtig hingekriegt...

Delphi-Quellcode:

procedure TForm2.Button1Click(Sender: TObject);
var
  b1, b2, b3, b4, b5, bn, bx: byte;
  i: integer;
begin
  b1 := ord(strtoint(edit2.text));
  b2 := ord(strtoint(label13.caption));
  b3 := ord(strtoint(edit4.text));
  b4 := ord(strtoint(edit6.text));
  b5 := ord(strtoint(edit3.text));

  for i := 1 to length(edit5.Text) do
    if I = 1 then
      bn := ord(edit5.text[i])
    else
      bn := bn + ord(edit5.text[i]);

  bx := ((b1+b2+b3+b4+b5+bn)*(-1));

  label14.caption := inttostr(bx);
end;

Schlussendlich krieg ich gar keine negative Zahl?! Aber das liegt vermutlich daran dass ein Byte kein Vorzeichen enthält oder? Und per RS232 kann man doch eh nur 0 bis 255 verschicken oder nicht?

Die Checksummenberechnung sieht ohne das ganze "Gemüse" außenrum so aus:

Delphi-Quellcode:

type TPayload = array of byte;
const STARTBYTE = $0F;
const STOPBYTE = $F0;
const MIN_MESSAGE_SIZE = 6;

function Build_Checksum(command : byte, payload : TPayload) : byte;
  var i : byte;
  begin
  result := STARTBYTE+2*command+MIN_MESSAGE_SIZE+sizeof(payload); //erster Header, bestehend aus startbyte, command und message size (berechnet aus MIN_MESSAGE_SIZE und der Payload-Größe), sowie einem Teil des zweiten Headers, nämlich dem wiederholten command)
  for i := 0 to high(payload) do //payload aufaddieren
    result := result+payload[i];
  result := (not result) + 1; //zweierkomplement bilden
  end;

Zitat:

Zitat von urbanbruhin

EDIT2: Bei einem Werkzeugwechsel wird ja eine Benutzereingabe verlangt, dass das Programm weiterläuft. Machst du diese Hardwaremässig (Taster) oder am PC mit einem Button? Ich tendiere da vorläufig eher zu einem Button, später werde ich das aber vermutlich Hardwaremässig noch realisieren. Ich habe nämlich vor, einen alten PC ohne Bildschirm usw. zu verwenden, wo ich dann einfach einen USB-Stick mit dem Programm reinstecken kann und der PC das automatisch ausliest und die Fräse startet. Aber vorläufig mach ich das mal mit meinem eigenen PC...

So weit bin ich noch nicht. Im Moment mache ich mir Gedanken zur Umsetzung der Schnittstelle Command_Decode=>G-Code-Präprozessor->Motion_Control, unter Berücksichtigung des gewünschten Funktionsumfanges (Anfahrrampen etc.)
Geplant ist, dass sowohl über die Software, als auch über einen Schalter bestätigt werden kann.
Geplant ist ferner, dass der PC anzeigt, wo die Fräse gerade ist (oder glaubt zu sein), was sie bereits abgefahren hat und was noch bevorsteht.

@jokerfacehro:
Log erfolgt, wie oben geschrieben, durch Rückmeldung an den PC, welche Schritte gerade erledigt werden.
Havarie gibt es in verschiedenen Formen: Not-Aus, Endschalter (beides vorgesehen, letzteres auch für Referenzfahrt) und Watchdog-Reset (wird vermutlich auch eingebaut). Letzterer springt ein, wenn die Firmware nicht regelmäßig einen Timer zurücksetzt, und soll so diverse "Abstürze" der Firmware (Stackpointer gekillt o.ä.) durch Reset neutralisieren und schlimmeres vermeiden.

mfG
Markus

[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 :D

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:

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 :D

Gratuliere!

Zitat:

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 :angel:
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...

:wiejetzt:

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. :gruebel:

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

[100nF]

hmm okay, klingt wirklich nicht schlecht...
aber für den gesamten ablauf bräuchtest du doch auch ein FiFo wo dann z.B. auch die M-Befehle drin stehen?! oder wie verarbeitest du dann die M-Befehle?

mfg
Urban

[markusj]

Alles was G-Code ist, wird durch die entsprechende Auswertungsroutine von command_decode vorverarbeitet.
Danach landet es im G-Code-FiFo.
Der G-Code-Interpreter nimmt sich immer ein Element von diesem FiFo und arbeitet es ab (wird in Einzelschritte zerlegt in den Motion-Fifo geschrieben). Wenn das ein M-Kommando ist, wird eben die entsprechende Operation durchgeführt.
Da nicht mehr ganze Kommandos im Motion-Fifo landen, werden die einzelnen Schritte quasi atomar abgearbeitet, man muss bei Bedarf nur noch auf die letzten paar Schritte warten.
Die Vorteile sind aber vor allem softwarearchitektonischer Art, die High- und die Low-Level-Funktionen sind jetzt sauber getrennt.

mfG
Markus

[100nF]

hallo, ich bins wiedermal :D

also ich hab jetzt schon einige Zeit am Programm gearbeitet, hat auch mal so halbwegs funktioniert, nach einer grösseren Änderung (die nicht mehr rückgängig machbar war^^) läuft es wieder weniger gut...:)

Eine Frage habe ich aber noch:
Bei der Variante dass man beim Laden eines neuen Verfahr-Jobs die Anzahl Schritte und die Anzahl wartende Schritte für jede Achse in Variablen schreibt und im Timer dann ausliest/verändert, wolltest du das so machen dass die Anzahl der Durchläufe der Timer-Routine dem kgV der Anzahl Schritte aller drei Achsen entspricht? (Komplizierter Satz...) Wenn das so wäre, würde die Verfahrensgeschwindigkeit ja immer stark variieren, da bei der Positionierung X100 Y50 Z25 nur 100 Timer-Durchläufe nötig sind, bei X100 Y51 Z25 wären aber 5100 Durchläufe nötig, obwohl nur ein einziger Schritt mehr ausgeführt wird?!
Und mit Singles sollte man ja nicht arbeiten schreibst du :D

Wie hast du dir das denn vorgestellt? bzw. wie machst du es nun oder wie hast du es gemacht?

Gruss
urbanbruhin

[markusj]

Ich habe inzwischen ein anderes Modell, welches vermutlich effektiver arbeitet, das hatte ich afair aber schon erklärt.
Der alte Ansatz hätte natürlich mit etwas mathematischem Geschick dann die Geschwindigkeits-Kombination ausrechnen müssen, die am besten zu den vorgegebenen Linien passt.
Leider steht das Projekt im Moment, weil ich neben meinem Studium kaum Zeit finde. Ich hoffe, das normalisiert sich in den nächsten Wochen noch.

mfg
Markus