Re: Ablauf für Fräsmaschine programmieren
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 |
Re: Ablauf für Fräsmaschine programmieren
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 :D hier der link: klick |
Re: Ablauf für Fräsmaschine programmieren
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 |
Re: Ablauf für Fräsmaschine programmieren
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 |
Re: Ablauf für Fräsmaschine programmieren
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 |
Re: Ablauf für Fräsmaschine programmieren
also mit "Havarie" kann ich auch nicht viel anfangen :gruebel:
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 :D 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 :D @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? |
Re: Ablauf für Fräsmaschine programmieren
Hätte ich doch fast deinen Edit übersehen! :wall:
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. |
Re: Ablauf für Fräsmaschine programmieren
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 :D 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^^) :D Doch im G-Code sind die Kreise doch irgendwie schon in einzelne Geraden umgewandelt oder?! Zitat:
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 |
Re: Ablauf für Fräsmaschine programmieren
Hi,
Zitat:
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:
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:
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:
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 |
Re: Ablauf für Fräsmaschine programmieren
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:
Die Prozedur GoToPos ist nur sehr schwer verständlich wenn ich den Code poste :D Deshalb eine kurze Erklärung:
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 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 :D Da hab ich wohl einiges zu tun um es so ähnlich hinzukriegen wie du :D 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? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz