Ablauf für Fräsmaschine programmieren

[markusj]

Du musst das G-Code Plugin einfach in den Ordner "ulp" im Eagle-Programmverzeichnis kopieren (in der Regel C:\Programme\Eagele-*\ulp)
Für den Anfang empfielt sich das Plugin gcode-1, fortgeschrittenere können sich bei pcb-gcode austoben.

Normalerweise fräst man nur Weg was sein muss, man hat ja die Möglichkeit größere Abstände zu definieren.

mfG
Markus

[100nF]

komisch, hab das jetzt mehrmals ausprobiert aber ich kann beim "CAM Processor" in der Liste keinen entsprechenden Eintrag finden?!
Im Control Panel von Eagle ist die Datei aber aufgeführt unter "User Language Programs"...

Also wenn ich "pcb-gcode" benutzen würde, dann könnte ich einfach fräserdurchmesser usw. angeben, und die datei die er dann erzeugt enthält alle befehle, die ich dann sozusagen direkt an den microcontroller schicken kann? Das wäre ja echt genial!

EDIT:
OK hab da was im Internet gefunden, sieht echt gut aus, bin das grad mal am durchlesen
hier der link: klick

[markusj]

Das ganze ist auch ein ULP und muss dementsprechend mit "ULP öffnen" aufgerufen werden. Alternativ kannst du in der Eagle-Kommandozeile run pcb-gcode ausführen.
Wenn du auf die Website von PCB-Gcode gehst (http://pcbgcode.org/index.php), findest du dort neben der aktuellsten Version auch noch ein kleines Optimierungsprogramm, das noch einmal Zeit sparen kann.

Du bekommst danach eine G-Code Datei, die du dann weiter verarbeiten kannst. Es gibt verschiedene G-Codes, z.Bsp. für Eilgang G00, Gerade G01 etc.
Je nach dem wie dein System aufgebaut ist, muss dann entweder dein Programm oder der µC diese G-Codes in Schrittanweisungen umsetzen.

Bei mir wird das ganz wie folgend Ablaufen:
1. PC-Programm tauscht die Konfiguration mit dem µC aus.
2. PC-Programm lädt G-Code, überprüft die Syntax und die Maximalwerte (Geschwindigkeit, Verfahrbereich etc.)
3. Evtl. anpassen der Konfiguration des µCs.
4. Versenden der G-Codes via RS232 über ein eigenes Protokoll. Die G-Codes werden dabei vereinfacht, der µC braucht ja für ein G00 keine drei Bytes!
5. Überwachen der Ausführung, nachfüllen des µC-Puffers wenn dieser Bedarf anmeldet.

Die komplette Rasterung und Motoransteuerung wird der µC übernehmen, neben der Ansteuerung via G-Code besteht dabei auch die Möglichkeit, vom PC oder über ein Kontrollinterface die Fräse manuell zu Steuern.

Was du nicht im PC implementierst, musst du natürlich dann im µC umsetzen!

mfG
Markus

[jokerfacehro]

wenn du SPS programmierung hast, weißt du das bestimmt, will nur nochmal draufhinweisen:

für jeden steuerschritt einen merker zu setzen und eine havarie-funktion einzubauen

[markusj]

WTFH?
Ich kann mit deinen Begriffen gerade wenig anfangen.
Havarie? Dafür gibt es für jede Achse zwei Endschalter die einen sofortigen Stop der Automatik erwirken. Gleichzeitig zählt der µC jeden einzelnen Schritt mit und weiß so zu jedem Zeitpunkt, wo er sich befindet.
Da ich keine SPS programmiere, sondern in meinem Falle einen ATMega168 habe ich keine "Merker".
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?

mfG
Markus

[100nF]

also mit "Havarie" kann ich auch nicht viel anfangen

und SPS programmieren hab ich in einem Kurs gelernt (Teil meiner Lehre als Automatiker) doch die Fräsmaschine wird mit einem Mikrocontroller realisiert (vorerst mal mit einem C-Control Pro mit Application Board).

@Markus
Also welchen Teil der µC und welchen Teil der PC übernimmt hab ich ja anfangs mal geschrieben (glaub sogar im ersten Beitrag).
Vorerst werde ich das auch mal so sein lassen, kann aber auch sein dass ich das später noch ändere, so dass es dann so ähnlich abläuft wie bei dir.

über den G-Code hab ich jetzt schon einiger gelesen, die einzelnen anweisungen hab ich hier gefunden. bin schonmal fleissig am programmieren

EDIT:
So, ging eigentlich ganz gut, bin gerade dabei das Programm für die Platine im ersten Beitrag abzuarbeiten. Der Schrittmotor für die X-Achse areitet jetzt schon fast eine Stunde, doch das Programm befindet sich noch nichtmal in der Hälfte^^

Für die Übersetztung von mm zu Schritten hab ich einfach mal den Faktor 50 angenommen, hab ja noch keine Mechanik...Ich denke aber 50 ist schon die unterste Grenze. Ausserdem hab ich keine Ahnung ob die Geschwindigkeit in Ordnung ist, doch ich fahre grad mit der zweitschnellsten Geschwindigkeit die möglich ist. (jeweils 1ms twischen den Einzelschritten)

Ich würde also meinen dass ich da noch stark optimieren muss

@markusj
könntest du vielleicht noch bisschen Informationen geben von deiner Lösung?
z.B. wie dein Protokoll aussieht wäre noch interessant.
Ausserdem habe ich noch keine grosse Erfahrung mit dem Programmieren von Microcontrollern. Wird der gesamte (verkürzte) G-Code in ein EEPROM geladen oder wie? Ich mein, so 100KB sind doch schon eine ziemliche Menge für einen Mikrocontroller...

EDIT2:
und mit welcher Programmiersprache programmierst du deinen Mikrocontrolle? Würdest du deinen Code vom Mikrocontroller auch hier im Forum posten, oder zumindest den Teil der für die Übertragung zuständig ist?

[markusj]

Hätte ich doch fast deinen Edit übersehen!

Ok, ein Paar Infos:

Die Hardware besteht aus einem ATMega168, der drei Schrittmotorplatinen L287/298 ansteuert.

Bisheriger Projektstatus: Elektrische Hardware steht größtenteils, die Fräse befindet sich noch in der Planungsphase. Die Firmware wird gerade entwickelt, das PC-Gegenstück dazu wird langsam mitwachsen.

Ich programmiere das ganze in "C", das ist für AVRs so ziemlich das günstigste und effektivste neben ASM (*grusel*).

Der µC hat mehrere Fifos für unterschiedliche Zwecke, einer davon speichert die empfangenen G-Codes zwischen. Die Ablage findet komplett im SRAM statt, EEPROM wäre viel zu langsam, außerdem macht der "nur" 100.000 (evtl. noch *10?) Schreibzyklen mit.
Je nach Füllstand fordert der µC dann neues "Futter" an oder bremst die Gegenstelle.

Mein Protokoll sieht momentan so aus: Startbyte-Message_Size-Command_Byte-Payload-Command_Byte-Checksumme-Stopbyte.
Bis auf die Payload (welche Message-Size-6 Bytes groß ist), sind alle anderen Elemente je ein Byte groß.
Die Checksumme ist einfach das Zweierkomplement der Summe aller Bytes.

Das ganze ist im Moment noch in Entwicklung, z.Z. optimiere ich gerade meinen abgewandelten Bresenham-Kreisalgorithmus.
Den Source werde ich vermutlich veröffentlichen, tendenziell aber eher im Roboternetz-Forum, in dem es einige CNC-Relevante-Threads gibt.
Zu gegebener Zeit werde ich dort auch einen neuen Thread zu meiner Firmware eröffnen.
Es spricht aber nichts dagegen, das ganze zusammen mit dem "Server"-Programm auch hier auszubreiten.

mfG
Markus

PS: Zum Thema Code-Posten: Gerade bei µCs ist Sourcecode nur begrenzt portabel. Abhängig davon, wie du die Hardware verdahtet hast, welchen µC du gewählt hast etc. bestehen manche Möglichkeiten, andere nicht.
Da der µC die G-Codes selbst umsetzen muss, verwende ich gezwungenermaßen gewisse Ressourcen wie Timer, um möglichst schnell die notwendigen Berechnungen durchführen zu können.
Wenn du diese Ressourcen andersweilig verwendest, gibt es zwaangsläufig Konflikte.
Mein Source ist zwar modularisiert, die Module werden aber stark miteinander vernetzt sein.

[100nF]

Okay, also meine Hardware ist wie gesagt das C-Control Pro, welches einen ATMega128 enthält. Die Schrittmotoren werden auch über die Kombination L297/L298 angesteuert.

Den Mega128 programmiere ich in Basic, doch "C" (bzw. "Compact-C") wäre auch möglich. Doch als ich mich entscheiden "musste" gefiel mir Basic schon einiges besser^^

Ich glaube, dass ich das mit der Übertragung alleine überhaupt nicht hinkriege. Das, was ich bis jetzt gemacht habe war so zimelich das billigste - funktionieren tuts aber

Dann zum Protokoll, ich glaub das hab ich noch nicht ganz verstanden:
Startbyte --> Darum muss ich mich nicht kümmern oder (Nur beim Initialisieren des Ports angeben)?
Message_Size --> Das gibt einfach die Länge (Anzahl Bits, Bytes?) der Message an?
Command_Byte --> Ist das der Befehl? also im G-Code wäre das z.B. M0 oder G01?
Payload --> Hier sind z.B. die X/Y/Z Koordinaten drin?
Command_Byte --> hmm nochmal das... ich lag glaub doch falsch^^
Checksumme --> Einfach zur Sicherheit nehme ich mal an...
Stopbyte --> Ähnlich wie das Startbyte...

Die übertragenen Bytes werden dann also einfach in eine Variable geschrieben wenn ich das richtig verstanden habe. Ist das irgendwie ein "Array of Irgendwas"?

Benutzt du Threads für die Übertragung? Bei meinem Programm warte ich einfach auf ein "Signal" von der seriellen Schnittstelle, wenn da keines kommt bleibt das Programm an dieser Stelle hängen...also so lange bis ein Signal kommt.

Ach ja, für was brauchst du den Bresenham-Kreisalgorithmus? Ich kenn den zwar nicht, aber wird wohl für Kreise benötigt (laut Wikipedia^^) Doch im G-Code sind die Kreise doch irgendwie schon in einzelne Geraden umgewandelt oder?!

Zitat:

PS: Zum Thema Code-Posten: Gerade bei µCs ist Sourcecode nur begrenzt portabel. Abhängig davon, wie du die Hardware verdahtet hast, welchen µC du gewählt hast etc. bestehen manche Möglichkeiten, andere nicht.

Ja das ist mir schon klar, doch ich bin absoluter Anfänger (wie du bestimmt gemerkt hast xD) auf diesem Gebiet, und da ist meine grösste Schwierigkeit im Moment noch der "Gesamtaufbau" des Programms. Dieser ist ja unabhängig von der Programmiersprache und von den einzelnen Befehlen ja grundsätzlich immer ziemlich ähnlich.

Falls du mal im Roboternetz schreibst, kannst mir vielleicht bescheid geben, damit ich das Thema dann auch mitverfolgen kann?

Danke schonmal für die Hilfe!!

mfg
Urban

[markusj]

Hi,

Zitat von urbanbruhin:

Dann zum Protokoll, ich glaub das hab ich noch nicht ganz verstanden:
Startbyte --> Darum muss ich mich nicht kümmern oder (Nur beim Initialisieren des Ports angeben)?
Message_Size --> Das gibt einfach die Länge (Anzahl Bits, Bytes?) der Message an?
Command_Byte --> Ist das der Befehl? also im G-Code wäre das z.B. M0 oder G01?
Payload --> Hier sind z.B. die X/Y/Z Koordinaten drin?
Command_Byte --> hmm nochmal das... ich lag glaub doch falsch^^
Checksumme --> Einfach zur Sicherheit nehme ich mal an...
Stopbyte --> Ähnlich wie das Startbyte...

Naja, nicht wirklich: Die Übertragung erfolgt über die serielle Schnittstelle, alles was ich angegeben habe, ist für dich von Relevanz.

Startbyte --> 0x0F, dient zum Erkennen eines Telegramms vom PC.
Message_Size --> Anzahl der Bytes des KOMPLETTEN Telegramms.
Command_Byte --> Kommando des PCs an den µC. KEIN G-Code, da es neben G-Codes noch andere Anweisungen (Kalibrierparameter etc.) an den PC gibt. Wenn ein G-Code übetragen wird, enthält das Command_Byte z.Bsp. die Anweisung cmd_code_gcode_transfer.
Payload --> Die Payload enthält die Informationen, die zur Ausführung des Commands benötigt werden. Bei cmd_code_gcode_transfer z.Bsp. würde die Payload den vereinfachten G-Code beinhalten. Anhand des Commands kann dann ein Unterprogramm aufgerufen werden, das sich dann um die Auswertung der Payload kümmert.
Command_Byte --> Zur Sicherheit wird das Command_Byte doppelt übertragen. Stimmt es nicht überein, wird das Telegramm verworfen.
Checksumme --> Zweierkomplement der Summe ALLER Bytes bis hierher. Stimmt sie nicht überein, wird das Telegramm verworfen.
Stopbyte --> 0xF0, dient zum Erkennen eines Telegrammendes.

Die komplette Dekodierung erfolgt in einer State-Machine, die den Eingangs-Fifo nach dem Startbyte durchsucht und dann Schritt für Schritt die einzelnen Überprüfungen durchführt.
Befindet sich das Stopbyte nicht an der von der Messaage_Size angegeben Position schaltet die State-Machine ebenso auf Durchzug wie bei allen anderen Telegramm-Fehlern.
Erst wenn ein Stopbyte auftaucht, "hört" die State-Machine wieder zu.

Zitat von urbanbruhin:

Benutzt du Threads für die Übertragung? Bei meinem Programm warte ich einfach auf ein "Signal" von der seriellen Schnittstelle, wenn da keines kommt bleibt das Programm an dieser Stelle hängen...also so lange bis ein Signal kommt.

Normalerweise kann ein AVR keine Threads. Eine Multithreading-Implementation würde kostbare Rechenzeit und andere Ressourcen fressen.
Stattdessen verwende ich ein ausgeklügeltes (?) *hust* Programmdesign damit alle Module ihren Job erldigen können:

Main-Schleife:
- State-Machine zur Auswertung der Telegramme
- G-Code-Interpreter & Preprozessor
- G-Code-Main-Prozessor (sofern nötig)

RS232-Receive-Interrupt:
- Schaufelt empfangene Bytes in den Receive-Fifo (der dann in der Main-Schleife ausgewertet wird)

Timer-Interrupt:
- Steuert die angeschlossenen Motoren je nach aktuellem Steuerbefehl an. (Pinwackeln )

+X andere Kleinigkeiten am Rande (ADC für die manuelle Kontrolle, blinkende LEDs, Endschalter etc.)

Solange kein Interrupt in die Ausführung der Main-Schleife springt, wartet diese auf Benutzereingaben und berechnet Anweisungen für den Motor-Timer-Interrupt vor.

Zitat von urbanbruhin:

Ach ja, für was brauchst du den Bresenham-Kreisalgorithmus? Ich kenn den zwar nicht, aber wird wohl für Kreise benötigt (laut Wikipedia^^) Doch im G-Code sind die Kreise doch irgendwie schon in einzelne Geraden umgewandelt oder?!

Nope, schau dir mal G02 und G03 an, das sind die Befehle für eine Kreisbewegung im/gegen den Uhrzeigersinn.
Der Main-Prozessor wird hauptsächlich diese Berechnungen übernehmen, für eine klassische Gerade wird das ganze hoffentlich direkt in der Motor-ISR erledigt werden können.

Zitat von urbanbruhin:

Ja das ist mir schon klar, doch ich bin absoluter Anfänger (wie du bestimmt gemerkt hast xD) auf diesem Gebiet, und da ist meine grösste Schwierigkeit im Moment noch der "Gesamtaufbau" des Programms. Dieser ist ja unabhängig von der Programmiersprache und von den einzelnen Befehlen ja grundsätzlich immer ziemlich ähnlich.

Falls du mal im Roboternetz schreibst, kannst mir vielleicht bescheid geben, damit ich das Thema dann auch mitverfolgen kann?

Kein Problem, es gibt im RN ein/zwei _richtig_ große Threads zum Thema CNC, ich bin dort unter dem selben Nick unterwegs und hab auch schon ein paar Beiträge hinterlassen.

Ich habe allerdings _keine_ Ahnung von der C-Control, nach dem was ich mir gerade ergoogelt habe, wirst du vermutlich von "meiner" Lösung Abstand nehmen müssen.
Bei der C-Control hast du eine Zwischenschicht/eine Art Betriebssystem zwischen dir und der Hardware, die Folge daraus ist vermutlich automatisch, dass du Echtzeitanwendungen eher schwierig umsetzen kannst, vor allem wenn du dich schon hart am Limit dessen bewegst, was der µC an Leistung hat.
Hast du schon einmal versucht, einen Schrittmotor "von null auf hundert" und zurück zu regeln? Kommst du bis in den Bereich, in dem Schrittverluste auftreten?

Im Moment verwende ich für meine Umsetzung Zeitscheiben von 0,1ms. Da mein µC mit 20Mhz taktet und die Ansteuerfrequenz 10kHz beträgt, habe ich je Schritt 2000 Instruktionen zur Berechnung der nächsten Bewegung zur Verfügung.
Je nach dem, wie performant meine Umsetzung ist, kann ich später sogar einen noch kleineren Grundtakt für die Motoransteuerung wählen.
Jedes Mhz weniger reduziert die Reserve, die du für deine Berechnungen hast, immerhin berechnet der µC nebenher wo die Reise hingeht, die Interrupts sind höher priorisiert und wollen nur noch den Schrittmotortreiber ansteuern, das nächste Kommando hat also da zu sein!
Die C-Control Pro scheint mit 14,irgendwas Mhz zu Takten, die Tatsache dass der Code auch noch durch einen Interpreter läuft, verschlechtert deine Chancen nur noch mehr.

mfG
Markus

[100nF]

hmm..also ich hab das bisher völlig anders gemacht würde ich sagen. Auf diese Weise wäre ein "zu langsamer" Mikrocontroller eigentlich gar nicht schlimm, ein Fräsvorgang würde einfach länger dauern aber funktionieren würde es.

Ich poste mal den relevanten Teil meines Basic-Programms, falls du willst kannst du es ja mal anschauen.

Code:

Sub OneStep(Achse As Byte, Richtung As Byte) 'Führt einfach nur einen Schritt bei einer Achse in die gewählte Richtung aus
    Select Case Achse
      Case 1 'X-Achse, F.0
        Port_WriteBit(43, Richtung) 'Richtung angeben
        Port_WriteBit(40, 1)
       ' AbsDelay(ISpeed*SpeedFactor)         ' Verzögerung  in ms
        Port_WriteBit(40, 0)
        If Richtung=0 Then
          PosX=PosX-1
        Else
          PosX=PosX+1
        End If

      Case 2 'Y-Achse  F.1
        Port_WriteBit(44, Richtung) 'Richtung angeben
        Port_WriteBit(51, 0)
       ' AbsDelay(ISpeed*SpeedFactor)         ' Verzögerung  in ms
        Port_WriteBit(51, 1)
        If Richtung=0 Then
          PosY=PosY-1
        Else
          PosY=PosY+1
        End If

      Case 3 'Z-Achse  F.2
        Port_WriteBit(45, Richtung) 'Richtung angeben
        Port_WriteBit(52, 0)
      '  AbsDelay(ISpeed*SpeedFactor)         ' Verzögerung  in ms
        Port_WriteBit(52, 1)
        If Richtung=0 Then
          PosZ=PosZ-1
        Else
          PosZ=PosZ+1
        End If

      End Case
End Sub


In der Main-Prozedur:
Do While True
    GoPosX="     "
    For i=0 To 4
      GoPosX(i)=Serial_Read(0)
    Next

    GoPosY="     "
    For i=0 To 4
      GoPosY(i)=Serial_Read(0)
    Next

    GoPosZ="     "
    For i=0 To 4
      GoPosZ(i)=Serial_Read(0)
    Next

    Speed="     "
    For i=0 To 4
      Speed(i)=Serial_Read(0)
    Next

    Text="Fahre auf Position...        "
    Serial_WriteText(0, Text)
    Serial_Write(0, LF)
    Serial_Write(0, CR)

    InZahlenWandeln()

    GoToPos() ' hier wird OneStep(...) mehrmals aufgerufen

    Text="Erwarte Befehl               "
    Serial_WriteText(0, Text)
    Serial_Write(0, LF)
    Serial_Write(0, CR)
  End While

Die Prozedur GoToPos ist nur sehr schwer verständlich wenn ich den Code poste Deshalb eine kurze Erklärung:
Istposition und Sollposition von X, Y und Z werden verglichen. OneStep wird dann mit jeder Achse so häufig aufgerufen, bis die Fräse sich in der Sollposition befinden.
Bsp: Xist, Yist, Zist = 0; Xsoll = 100, Ysoll = 50 und Zsoll=25;
--> OneStep(X) wird 100 mal aufgerufen, Jedes zweite mal wird auch OneStep(Y) und jedes vierte mal auch OneStep(Z) aufgerufen.

Zu deiner Frage noch: Anfangs konnte ich das Teil so schnell laufen lassen bis es Schrittverluste gab. Dann hab ich das Programm ein bisschen abgeändert, nun gibts (höchstwahrscheinlich sehr knapp) keine Schrittverluste mehr. Also mit der maximalen Geschwindigkeit bin ich eigentlich ganz zufrieden, ich glaub nicht dass der Schrittmotor noch schneller laufen könnte.

Mit Interrupt hab ich mich noch nicht auseinandergesetzt, dohc ich habe befürchtet dass dies für eine saubere Lösung notwendig ist


Da hab ich wohl einiges zu tun um es so ähnlich hinzukriegen wie du
Naja wenigstens wird mir so nicht langweilig^^

mfg
Urban

EDIT:
was ich schon lange fragen wollte, wie greifst du im Delphi-Programm auf die RS232 zu? Benutzt du eine Komponente?