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!

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

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

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 Ich glaub ich werde es dann auch mal auf Punktraster versuchen...

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

mfg
Urban

EDIT:
ach jetzt ist es mir schon wieder in den Sinn gekommen
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 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 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 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