Announcement: there is an English version of this forum on 
Wie schon in einem anderen Thread angedeutet, habe ich jetzt mit dem Projekt begonnen. Darum geht es: Stepper Motor / CNC Windows-Frontend für GRBL mit ATMega328/Arduino/Uno/Nano für die billigen A4988 CNC Motor Controller Boards und ähnlichen. Der Vorteil von GRBL ist das fertige und ausgetestete Hex-File, welches man einfach auf einen Arduino Uno/Nano flashen kann. Die Kommunikation läuft dann über die eingebaute USB/Seriell-Schnittstelle. Damit entfällt der parallele Printer-Port, der sonst meist für CNC genutzt wird, aber in neuern PC's nicht mehr vorhanden ist. Die Interpretation des G-Codes findet auf dem ATMega statt. Der PC sendet nur den G-Code und passende Steuerbefehle. Es gibt zwar einige wenige Frontends für Linux/Java/Windows, aber alles hat mir für meine Zwecke nicht wirklich zugesagt. Also erstelle ich jetzt eine Bedienoberfläche für Windows neu. Als Features habe ich mir gedacht: - Manual-Mode, umfangreicher Handbetrieb - File-Mode, das G-Code-File wird autom. ausgeführt - G-Code Editor und G-Code Befehlszeile - Autom. Fehlererkennung im G-Code - Betrieb von 1 bis zu 3 Stepper Motoren - Betrieb eines Spindelmotors mit Geschwindigkeitssteuerung - event. Kühlmittelfreigabe für den Spindelmotor - Umfangreiche Betriebs/Status-Anzeigen - Graphische Darstellung des GCodes mit Echtzeitverlauf Die ersten Versuche mit einem Arduino Nano, A4988 Board und kleinerem Stepper-Motor in einer simplen Versuchanordnung verlaufen bereits erfolgreich (siehe Bild). Oben seht ihr einen Screen Shot der vorläufigen Programm-Version. Übrigens verwende ich die Version 0.9g des GRBL Hex-File. Hier noch einige Links zu GRBL: https://github.com/grbl/grbl/wiki https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/ Gruss Ulrich Albert
Angehängte Dateien:
-
SerialComCNC_v0.1_Test.jpg
170 KB -
IMG_5720_fuer_Forum.jpg
380 KB
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.1_Test_2.jpg
150 KB
So, der manuelle Modus ist inzwischen voll funktionsfähig. Wenn es einer an seinen Schrittmotoren ausprobieren möchte, kann ich eine vorläufige Programmversion mit manuellem Modus hier einstellen. Der nächste Schritt, der File-Modus, ist etwas anspruchsvoller und dauert bei der Programmierung was länger :)
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.1_Test_3.jpg
110 KB
Anbei SerialComCNC Version 0.1 In dieser frühen Version ist der manuelle Modus voll funktionsfähig und eignet sich gut zum Testen von Schrittmotoren oder auch bereits zur halbautomatischen CNC Bearbeitung mit Fräsen, Drehmaschinen oder für sonstige Bewegungsvorgänge. Der File-Modus ist noch nicht funktionsfähig. Das Zip-File enthält: - SerialComCNC Programm - GRBL v0.9g Hex-File (G-Code Interpreter) zum Flashen auf Arduino Uno/Nano - XLoder Programm, damit lässt sich das GRBL Hex-File direkt auf den Arduino flashen. Alle Maschinen-Parameter lassen sich einfach über direkte GRBL-Befehle im Frontend anpassen. Ansicht der Maschinen-Parameter durch Eingabe von $$ und Hilfe über Eingabe von $ Die eingestellten Maschinen-Parameter werden persistent im ATMega gespeichert. Über Rückmeldungen und Vorschläge würde ich mich freuen. Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Im Frontend der "Nullpunkt setzen". Welcher Nullpunkt ist denn gemeint? Der X, Y oder Z-Nullpunkt? Wäre es nicht Sinnvoll den Button entsprechend X,Y,Z zu unterteilen? Weil ich ermittel ja die Nullpunkte einzeln nacheinander.
Danke für den Hinweis. X,Y,Z Nullpunkt einzeln setzen kommt als zusätzliche Option in der nächsten Version. Der File Modus, incl. G-Code Editor funktioniert auch bereits soweit.
Angehängte Dateien:
-
SerialComCNC_v0.2.jpg
170 KB
Anbei SerialComCNC Version 0.2 Change Log V0.2 --------------- XYZ Achsen können jetzt auch einzeln genullt werden. G-Code File-Import mit vollständigem Processing, d.h. Übertragung auf den Arduino. Das G-Code File kann editiert werden. Fehler im G-Code werden während der Abarbeitung angezeigt (siehe Bild oben). Was noch nicht geht: Koordinaten Anzeige während der Abarbeitung des G-Code Files. Menue-Einträge fehlen, usw. Ausserdem kommt eine G-Code Überprüfung ohne Stepper-Motor Bewegung, so dass man Fehler frühzeitig erkennt und im Editor beheben kann. Das geänderte File kann dann wieder gespeichert werden. In der vorliegenden Form kann das Programm aber bereits produktiv genutzt werden.
:
Bearbeitet durch User
Sieht wieder mal sehr vielversprechend aus. Eindeutig Daumen hoch! Ganz spontan kam mir gerade die Idee, daß es wohl relativ einfach wäre, ein Handrad einzubinden. Ein Drehencoder, paar Taster und ein Controller, der per serieller Schnittstelle an den PC sendet.
Hallo, ich verwende die Software JCNC in Verbindung mit GRBL oder TinyG. Die macht doch schon alles was du brauchtst... http://www.jtronics.de/software/jcnc-cnc-steuerung.html Mach doch lieber Vorschläge was noch mit in die Software soll. Ich selbst habe schon einige Wünsche geäußert, welche dann schnell bearbeitet wurden.
tobi schrieb: > ich verwende die Software JCNC in Verbindung mit GRBL oder TinyG. > Die macht doch schon alles was du brauchtst... Die Entwicklung der jtronics Software steht seit längerem anscheinend still und es fehlt: - Ein direktes Eingabefeld für G-Code - Eine direkte Feed-Einstellung - Möglichkeit die XYZ-Achsen einzeln zu Nullen - Response über Fehler im G-Code File - Eine vernüftige Hilfe, incl. G-Code Befehle usw.... Alles das was bei jtronics fehlt kann meine Software oder wird sie demnächst können.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.3.jpg
180 KB
Anbei SerialComCNC Version 0.3 Change Log V0.3 --------------- Änderung der Start-File und Not-Stop Bedienung. G-Code File nun voll editierbar. Speichern und Laden des G-Code Files. Halt und Continue ohne Schritt- und Positionsverlust. Anzeige der Job-Dauer. Mit Test-Button und Start wird das File zur Überprüfung auf dem MC ausgeführt ohne die Motoren bewegen (ohne Signale an das Driver Board). Home Offset für die Y-Achse zugefügt. Die X Y Z Displays funktionieren zur Zeit nur mit der manuellen/interativen G-Code Eingabe/Verarbeitung. Ansonsten kann die Software produktiv genutzt werden. Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, Das sieht schon ganz gut aus um längen angenehmer als die Java Geschichten die zur GRBL-Steuerung im Netz kursieren. Ich selbst nutze GRBL auch schon gut über einem Jahr es ist erstaunlich was der "chamnit" da so zaubert aus dem 328. Also weiter so einem Fan hast Du schon gewonnen. schöne Grüße Waldemar
Hallo, hab mich eben extra hier angemeldet um dir zu sagen, dass ich von deiner Idee und der Umsetzung begeistert bin. Weiter so, bin schon ganz ungeduldig und warte auf die nächste Version. Als Anregung würde ich noch vorschlagen, dass man die Achsen so wie unter LinuxCNC auch noch mit den Peiltasten und den "Bild auf" und "Bild runter" manuell verfahren kann. Ist den auch ein "Vorschaubereich" des Teils und ein virtuelles abfahren angedacht. Den zweiten Fan hast du auch schon. Max P.S. auch deine Tools für mc zur seriellen Schnittstelle find ich klasse.
:
Bearbeitet durch User
Schliesse mich einfach mal Max und Waldemar an... Gute Arbeit, bin sehr gespannt auf kommende Versionen. Danke !
Die Software ist ja gerade mal 6 Tage mit wenigen Stunden in der Entwicklung. Da freut es mich besonders, dass sie euch schon gefällt. Die neue Version kommt schnellstens. Was an Erweiterungen so alles kommt muss ich selber mal sehen, für Vorschläge bin ich dankbar. Eigentlich sollte das ja nur ein Projekt für meine eigenen Bedürfnisse sein. Anscheinend findet es mehr Interesse und das motiviert für zusätzliche Features :)
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.4.jpg
200 KB
Anbei SerialComCNC Version 0.4 Change Log V0.4 --------------- X X Z - Displays jetzt in allen Modi funktionsfähig. Im manuellen Modus Verfahren über Keyboard/Keypad möglich. Deaktivierung der Schnittstelle bewirkt einen Not-Halt. Hilfe-System/Bedienungsanleitung teilweise erstellt. Diverse Bugs behoben. Das dürfte für den Praxiseinsatz erst mal reichen. Alles Zusätzliche ist Nice-To-Have. Soll aber nicht heissen, dass die Entwicklung stehen bleibt, mal schauen wie aufwändig eine Realtime-Grafik dazu ist :) Ich baue jetzt zuerst mal meine Käsefräse Proxxon MF70 auf CNC um. Habe mir dazu diese Teile bestellt: http://www.ebay.de/itm/CNC-Kit-PROXXON-MF70-umbau-auf-CNC-fur-NEMA17-und-NEMA23-Motoren-/221394570257?pt=Modellbauwerkzeuge&var=&hash=item338c250c11 http://www.ebay.de/itm/181353602653?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 Referenzschalter verbau ich keine, weil für meine Zwecke unnötig. Der Umbau war der eigentliche Anlass für die Software-Entwicklung. Mal schauen was dem Mechanik/Elektronik Geraffel wird. Und noch einen Stepper-Motor samt Driverboard übrig, irgend wo für wird der auch noch gut sein. Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Anbei SerialComCNC Version 0.4a (Maintenance Release)
Hallo Ulrich oder Albert, Was du da in kurzer Zeit auf die Beine stellst ist einfach klasse! Eine grafische Darstellung wäre das Sahnehäubchen. Dein Programm kommt bei mir sicher zum Einsatz. Die Schrittmotoren sind schon an meiner Fräse (und behindern den manuelen Betrieb ;-). Danke für deinen Einsatz. Einhart
Angehängte Dateien:
Hier mal eine Vorschau auf die nächste Version. Neue Features: Graphische Darstellung der vom Arduino zurückgelieferten Positionswerte beim Fräsen. Die Anzeige ist in mm skaliert und kann verschoben und gezommt/umskaliert werden, auch während des laufenden Betriebes. Es werden die Verfahrwege in x und y Koordinaten als Draufsicht angezeigt. Eine 3D Darstellung ist mir z.Z. zu aufwändig. Für diejenigen die eine Farbunterscheidung zwischen Verfahren und Fräsen möchten: GRBL richtet auf dem ATMega einen Befehlspuffer ein. Ich schicke an den Puffer solange Befehle, bis der nächtste Befehl nicht mehr vollständig passt. Damit wird die Look-Ahead Funktion von GRBL voll genutzt. Der ATMega arbeitet die Befehle im Befehlspuffer ab und sendet auf Anfrage leider nur den Status und die Positionswerte zurück. So ist bei der Auswertung für die Grafikanzeige nicht mehr einfach nachvollziehbar welche Positionsdaten Verfahr- oder Fräswerte sind, da man nicht bestimmen kann welcher von vielen möglichen Behlen im Puffer gerade abgearbeitet wird. Bei GRBL-Frontends die eine farbige Unterscheidung zeigen werden demnach die Befehle einzeln abgearbeitet (in den Puffer geschickt und gewartet bis fertig) und damit kann die Look-Ahead Optimierung von GRBL dann nicht genutzt werden. Lange Rede kurzer Sinn: Mir ist die Look-Ahead Optimierung lieber und ich pfeife auf eine farbige Unterscheidung. Was es noch Neues gibt: Ein Process View, bei dem im File-Mode alle an den Arduino geschickten Befehle und vom Arduino kommenden Positionswerte aufgelistet werden. Zwischen Grafik und Process View kann während des Betriebes umgeschaltet werden.
:
Bearbeitet durch User
Hallo Albert, Das sieht schon Profi massig aus. bin begeistert was Du in so kurzen Zeit auf die Beine gestellt hast. Die Graphikmode in 2D reicht vollkommen. Ich selbst benutze GRBL bei meiner Platinenfräse dazu Konvertiere ich die Exellon Bohrdaten ( DRL ) und HP-Plotdaten ( PLT ) zur G-Code um die Fräse mit Daten zu füttern. Als Vorschlag zu späterem Zeitpunkt, so eine zusätzliche Implementierung der Funktionen, wird bestimmt vielen Usern nützlich sein. Da die meisten hier mit Elektronikbasteleien am werkeln sind. schöne Grüße Waldemar
Hallo Ulrich, Respekt! Ich finde es klasse was mach einer hier für Sachen produziert. Auch ich nutze das GRBL (noch v0.8) auf einer älteren, von mir umgebauten Säulenfräse. Ich habe das GRBL für einen STM32 Mikrocontroller umgeschrieben und um einige Fähigkeiten für die manuelle Bedienung erweitert. Da ich meist nur Teile aus Platten herausfräsen bzw. kompliziert angeordnete Lochmuster bohren will, wird bei mir nur X und Y vom Prozessor gesteuert, Z bediene ich manuell. Ich werde mir dein Tool auf jeden Fall mal näher anschauen und sehen was damit bei mir geht. Beste Grüße Christian
Hallo Ulrich, für eine Echtzeit-Positionsanzeige würde ich dir anbieten, das GRBL so zu modifizieren dass es dich ständig oder auf Abruf mit aktuellen Postitionsdaten versorgt. Meine Version macht das bereits, um das Display des "Handrades" mit diesen Informationen zu füttern. Christian
Christian W. schrieb: > für eine Echtzeit-Positionsanzeige würde ich dir anbieten, das GRBL so > zu modifizieren dass es dich ständig oder auf Abruf mit aktuellen > Postitionsdaten versorgt. Hallo Christian, das macht meine Software natürlich bereits, auch ohne GRBL Modifikation. Wie sollten die Anzeigen und die Graphic auch sonst funktionieren? Was GRBL in der neuen Version 0.9g leider noch nicht macht, ist eine zusätzlich zu der Koordinaten-Ausgabe eine Information über den aktuell bearbeiteten Befehl zu liefern, z.b. ob es ein G0 oder G1 Aufruf war. Das könnte ich gut gebrauchen, siehe mein Beitrag oben. Ansonsten sieht es so aus, dass ich vom PC timergesteuert ca. 7 mal pro Sekunde den Befehl "?" schicke, worauf GRBL mit Status und aktuellen Koordinaten antwortet. Schnellere Update als ca. 10/s würden GRBL zu stark ausbremsen und event. Fehlfunktionen verursachen. Aber eigentlich reichen die 7 mal pro Sekunde gut aus. Schneller würde auch nicht mehr Information bringen. Ändern möchte ich GRBL auf keinen Fall. Ich will mich bei meinem Programm immer auf die aktuelle/offizielle GRBL Version stützen.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.5_Bild1.jpg
200 KB
Anbei SerialComCNC Version 0.5 Change Log V0.5 --------------- Graphische Darstellung der Verfahr/Fräswege, incl. mitlaufendem Fadenkreuz auf der aktuellen Postion. Die Darstellung kann beliebig verschoben oder umskaliert werden, auch während des Fräsvorgangs. Process View mit laufender Anzeige der Schnittstellen Kommunikation während des File-Mode Betriebes. Diverse Bugs beseitigt. Have Fun! Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/ Link zu meinem Project SerialComInstruments: Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"
:
Bearbeitet durch User
Ich habe vorhin wohl geantwortet, bevor ich dein Problem richtig verstanden habe. Klar zeigt der "?" Befehl die aktuellen Koordinaten. Du brauchst den GCode Befehl der aktuell aus dem Puffer abgearbeitet wird. Den könnte man zusammen mit den Koordinaten des "?" Befehls an den PC zurückschicken. Das zu ändern wäre keine große Tat... Ich würde erstmal damit anfangen ein absolut identisches GRBL 0.9g Hexfile zu compilieren, und dann die Änderungen einbauen... Das Angebot steht ;-) Mal interessehalber: Mit welchem Tool (Visual Studio Express etc...) entwickelst du dein Windows Programm?
Christian, ich programmiere mit Delphi 7 Professional. Danke für dein Angebot GRBL passend zu modifizieren. Das ergibt für mich allerdings folgendes Problem: GRBL ist in C geschrieben und meine C Kenntnisse sind eher mangelhaft. Ich müsste daher immer auf Dich oder jemand anderes zurückgreifen, wenn es eine neue GRBL Version gibt, damit meine Software auch dann noch funktionsfähig bleibt. Daher möchte ich mich, zumindest vorerst, auf die offiziellen GRBL Version stützen, auch wenn das ein odere andere noch fehlt. Aber vielleicht komme ich doch noch mal auf Dein Angebot zurück :)
Ich verstehe das Problem. Melde dich gern wenn du Interesse hast, solche Projekte kann man einfach nur unterstützen :) Als ich damit anfing hatte mir vorgenommen, meine Änderungen an des GRBL Team zurückzuschicken damit sie offizioll einfließen können. Aber die Änderungen sind bis auf die STM32-Adaptierung sehr speziell (manuelle Betriebsmodi für selbstgebautes Handrad mit CAN Bus etc.) und für aussenstehende nicht gut genug dokumentiert. Ausserdem sollen noch weitere Funktionen rein. Ich befürchte das braucht so kein anderer... aber vielleicht versuche ich es doch mal.
Einsame Spitze, dein Projekt. Es waere gut, wenn man die benoetigten Konfigurations-Einstellungen gleich ueber die grafische Oberflaeche deines Programms in den GRBL bringen koennte. Beim Aufbau der Fraese wird doch viel experimentiert, da waere dies sicher optimal. Vielleicht waere dies auch fuer andere interessant. Vielen Dank fuer deine Arbeit.
Hardy F. schrieb: > Es waere gut, wenn man die benoetigten Konfigurations-Einstellungen > gleich ueber die grafische Oberflaeche deines Programms in den GRBL > bringen koennte. > Beim Aufbau der Fraese wird doch viel experimentiert, da waere dies > sicher optimal. Hallo Hardy, diese Funktionaltät ist doch bereits vorhanden: Wenn Du z.B. die Step (z.B für die X-Achse) pro mm skalieren möchtest, gibst Du in das Befehls-Eingabefeld unten rechts einfach ein: $100=x (wobei 100 = XAchse und x = Step). GRBL antwortet dann, wenn alles passt, mit einem OK. Dieser Eintrag wird dann permanent auf dem EEPROM des Arduino/ATMega gespeichert. Die aktuellen Einstellungen der z.Z. möglichen 32 Parameter ruft Du mit $$ zur Ansicht im Monitor auf und kannst sie, wie gerade beschrieben, neu setzen. Einfach mal probieren, dann siehst Du wie einfach das geht. Einer zusäzlichen Eingabemaske im Programm bedarf es dafür nicht. Mit der beschriebenen Konfigurations-Methode bleibt man auch flexibel wenn bei GRBL in Zukunft neue Parametrierungs-Befehle dazu kommen. Ansonsten müsste in meinem Programm jedesmal die Eingabemaske angepasst werden. Siehe dazu auch: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9
:
Bearbeitet durch User
Albert M. schrieb: > diese Funktionaltät ist doch bereits vorhanden Das kommt davon, wenn man nur theoretisiert und momentan keine Moeglichkeiten hat, alles in der Praxis zu probieren.... Entschuldigung. Bin voruebergehend die letzten Wochen leider weit weg vom Hobbyplatz und freue mich schon darauf, wieder daheim zu sein und dann endlich alles selbst umzusetzen, was dein Projekt hergibt.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.5_Bild2a.jpg
110 KB -
SerialComCNC_v0.5_Bild2b.jpg
220 KB -
SerialComCNC_v0.5_Bild2c.jpg
110 KB
Hier ein kleines Beispiel, entstanden für das Fräsen von einem Zahnradsatz aus Polystyrolglas. Und was mit dem netten Zahnrad-Konstruktions Programm (nicht von mir) noch Schönes machbar ist zeigt das 3. Bild.
:
Bearbeitet durch User
Hi Albert, vor ca. einem Jahr habe ich mir mit Unterstützung die c't Portalfräse nachgebaut. Da die Steuerung softwareseitig mit einem uralt-Labview von c't gelöst wurde, war das natürlich auf meinem aktuellen Labview (Studentenversion aus einem Buch) nicht lauffähig. Umso mehr freut es mich, dass Du Dich dem Thema widmest! Ich habe nämlich einen GRBL Stepper auf Basis eines Arduino Nano zuwischengeschaltet, sodass der jetzt die Fräse steuert. Es hat mich schon ein wenig geärgert, dass die c't Leute solch aufwändige Projekte nicht vernünftig zum Abschluss bringen. Als Softwareentwickler bin ich natürlich auch schon auf die Idee gekommen, selber ein Frontend zu bauen, über den Anfangsstatus bin ich aber bislang nicht hinausgekommen (Familie und Pendelei fordern ihren Tribut). Da ich überwiegend C# unter Visual Studio code und die Anwendung gerne in C# übersetzen würde, interessiere ich mich natürlich brennend für die Sourcen. Besteht die Möglichkeit, dass Du sie veröffentlichst oder sie auf Anfrage zusendest? Ich würde gerne eine Gamepad Unterstützung hinzufügen. Import von SVG, DXF,... und Umsetzung in GRBL wären auch noch schön. Am Wochenende werde ich Deine Anwendung testen, ich freue mich schon drauf! Gruß Michael
Michael W. schrieb: > Da ich überwiegend C# unter Visual Studio code und die Anwendung gerne > in C# übersetzen würde, interessiere ich mich natürlich brennend für die > Sourcen. Besteht die Möglichkeit, dass Du sie veröffentlichst oder sie > auf Anfrage zusendest? Hallo Michael, Ich programmiere alle meine Projekte mit Delphi/Pascal. Die Sourcen veröffentliche ich bei meinen Projekten nicht. Michael W. schrieb: > Ich würde gerne eine Gamepad Unterstützung > hinzufügen. Die Gamepad Unterstützung hatte ich bereits für kommende Versionen vorgesehen. Ich werde allerdings zuerst mal testen, ob das überhaupt sinnvoll ist. Michael W. schrieb: > Import von SVG, DXF,... und Umsetzung in GRBL wären auch > noch schön. Die Umsetzung von Vector-Graphic in G-Code ist nicht trivial und ziemlich aufwändig. Da benutze ich z.Z. lieber käufliche CAM-Software, wie z.B. Filou usw. Aber vielleicht gebe ich mich da doch mal dran.
:
Bearbeitet durch User
Hi Albert, danke für die Antwort und: schade wegen der Sourcen. Ich hatte gelesen, dass Du in Delphi codest, das Umsetzen in C# wäre aber sicher möglich - egal. Das Gamepad halte ich schon für eine gute Sache, um die Fräse erstmal auf Position zu bringen. Macht das Anwählen und Nullen wirklich bequemer. Die nächste G-Code Version soll ja Joggen unterstützen (wenn das noch in den 328 passt). Auch von mir hier nochmal Glückwunsch und Dank für Deine Software. Konnte meine Fräse damit erfolgreich in Bewegung setzen. Cool! (Muss bei meiner Fräse die Endschalter noch installieren). Gruß Michel
Hallo Albert, Ich hatte mir nochmal Dein Bild aus dem ersten Beitrag angesehen: möchtest Du mit einfachen Gewindestangen eine Fräse bauen? Meine ersten Versuche habe ich ähnlich begonnen und hatte das Problem, dass die Muttern auf dem Gewinde recht viel Spiel haben: wenn die Drehrichtung umgekehrt wird, dreht der Motor einige Steps bevor die Mutter in der Gegenrichtung mitgenommen wird. Es gibt also ein Problem beim wiederfinden z.B. des Startpunktes einer Figur. Wie löst Du das Problem? Wahrscheinlich wirst Du nicht um Gewindespindeln mit passender Mutter herumkommen. Ich teste noch mit preiswerten Rändelmuttern (http://www.ebay.de/itm/Kunststoff-Polyamid-Randelmuttern-M6-Polyamid-schwarz-10St-/371135385497?pt=DE_Haus_Garten_Heimwerker_Eisenwaren&hash=item5669648f99) für eine einfache kleine Platinenbohrmaschine... Geplant ist, zwei solcher Muttern in einem Block leicht zu kontern. Für ein anderes Projekt habe ich die unwesentlich teureren 8825 Treiber für die Schrittmotoren benutzt, die 4988 Treiber sind mir zweimal durchgebrannt. Damit soll man sogar noch Nema 23 Stepper treiben können. Das habe ich aber noch nicht getestet, meine laufen mit Toshiba TB5660 Treibern, weshalb ich auch ein Interface bauen musste: USB -> Printeranschluss mit Arduino Nano als GRBL Bindeglied. Gruß Michel
Michael W. schrieb: > Ich hatte mir nochmal Dein Bild aus dem ersten Beitrag angesehen: > möchtest Du mit einfachen Gewindestangen eine Fräse bauen? Nein, bewahre! Das war nur ein quick+dirty Testaufbau für meine Software. Die Software ist eigentlich für meine Proxxon MF70 Käsefräse. Nach einem Reinfall mit einem Chinesen mit angeblichem "German Warehouse", der dann doch nicht den bestellten Kit (Motoren, Driver und Netzteil) liefern konnte, habe ich mir jetzt das hier bestellt: http://www.ebay.de/itm/SainSmart-CNC-Router-1-Axis-3A-TB6560-Schrittmotor-Stepper-Motor-Driver-Board-/311106253844?pt=Motoren_Getriebe&hash=item486f60b414 http://www.ebay.de/itm/Free-shipping-5PCS-Nema17-1-3A-4-leads-17HS5413-stepper-motor-3D-printer-/181537932223?pt=Motoren_Getriebe&hash=item2a448103bf und einen mechanischen Umbau-Set für die MF70 (ca. 50 Euro). 8825 Treiber Boards habe ich hier auch noch rum liegen, ich habe mich dann aber für die obigen Boards entschieden. Die Stepper-Motoren (5 Tage Lieferzeit) und der Umbau-Set sind inzwischen da, auf die Driver-Boards warte ich noch. Dazu kommt noch ein Schaltnetzteil 24V 6A. Endschalter brauche ich für meine Zwecke nicht. Ich nulle auf das Werkstück und damit hat es sich.
:
Bearbeitet durch User
Hallo Michael, dieses Umkehrspiel kann man selbst mit teuren Kugelgewindespindeln nicht ganz eliminieren. Die gesamte Antriebskette Schrittmotor-Getriebe-Kupplung-Kugelumlaufmutter hat immer ein Restspiel. Gäbe es gar kein Spiel würde das ganze klemmen. Bei meiner Fräse (mit 16/5mmm Kugelumlaufspindeln aus China) beträgt das gesamte Umkehrspiel immer noch ca 3/100 mm. Ich gleiche das per Software aus. Grbl 0.8 kann das von haus aus nicht, aber eine Umkehrspiel-Kompensation lässt sich mit erträglichem Aufwand nachträglich einbauen. CNC Programme wie Mach 3 usw. haben diese Funktion konfigurierbar eingebaut. Gruß Christian
Angehängte Dateien:
-
SerialComCNC_v0.5_Bild3.jpg
440 KB
Mal ein Einblick in den Bastelfortschritt bei der Hardware. Die Stepper Motoren sind an der MF70 Fräse montiert und die x-Achse ist bereits funktionsfähig. Leider sind die fehlenden Driver Boards noch nicht angekommen.
:
Bearbeitet durch User
Angehängte Dateien:
-
Fraese_3.jpg
550 KB -
Fraese_Controller_Power.jpg
670 KB -
Fraese_GRBLler.jpg
930 KB
Cool, nicht schlecht, so'n Umrüstset! Sieht ja schon nach richtiger Arbeit aus. Und auch das Oszi kommt mir bekannt vor :-) Ich hab meins vor einem Jahr gegen das DS 1074Z von Rigol getauscht und hochgepatcht ;-) Ich wollte mir eine Fräse mit größerem Arbeitstisch bauen, naja, man will ja immer alle möglichen Großtaten damit erledigen (einerseits Platinen fräsen, andererseits Sperrholz und Alu 'schneiden'). Die Fräse ist also nach einem Bauvorschlag aus einer c't Hacks. Allerdings sind hier die Teile aus Eisen statt Alu, die komplette Fräse wiegt sicher an die 50 kg, allein die Nutenplatte und die Grundplatte haben 20mm Stärke. Bei dem China-Controller gab's damals Mach3 dazu (Testversion?), die Fräse lief aber eher schlecht als recht mit einem Windows PC als Controller. Seit dem GRBL Interface läuft sie richtig gut. Aus Kostengründen versuche ich natürlich mit Freewaretools auszukommen. Gruß Michel
Albert M. schrieb: > Mal ein Einblick in den Bastelfortschritt bei der Hardware. Ein wenig OT: Ich sehe, Du nutzt ein Rigol DS1022 zum Testen Deiner Hardware. Steuerst Du das Gerät irgendwie vom PC aus fern? Kannst Du das irgendwie aus Matlab oder Python fernsteuern? Viele Grüße W.T. P.S.: Die MF70 mit CNC ist auch niedlich. Aber das DS1022 interessiert mich momentan mehr, weil ich vor einer ähnlichen Problemstellung stehe.
Michael W. schrieb: > nicht schlecht, so'n Umrüstset! Sieht ja schon nach richtiger Arbeit > aus. Den Umrüstsatz hatte ich in weniger als einer Stunde montiert. Gegenüber meiner MF70 ist Deine Fräse ja schon ein richtiger Brocken. Walter Tarpan schrieb: > Ich sehe, Du nutzt ein Rigol DS1022 zum Testen Deiner > Hardware. Steuerst Du das Gerät irgendwie vom PC aus fern? Kannst Du das > irgendwie aus Matlab oder Python fernsteuern? Du meinst doch sicher den Funktionsgenerator DG1022? Das Oszi ist ein Rigol DS1052E, aber egal: Nachdem ich versucht hatte mit dem Rigol Oszi was in Verbindung mit dem PC zu machen und das nur sehr umständlich und mit fremden Treibern von NI mehr schlecht als recht machbar war, ist mir die Lust auf eine gleiche Erfahrung mit dem DG1022 Fkt-Generator vergangen. Daher kann ich Dir dazu leider auch nicht mehr sagen. Rigol muss was das Steuern und Auslesen der Geräte mittels PC angeht langsam etwas mehr Enthusiasmus zeigen. Prospektversprechen und Realität klaffen da noch weit auseinander.
:
Bearbeitet durch User
Albert M. schrieb: > Du meinst doch sicher den Funktionsgenerator DG1022? Das Oszi ist ein > Rigol DS1052E, aber egal: > Nachdem ich versucht hatte mit dem Rigol Oszi was in Verbindung mit dem > PC zu machen und das nur sehr umständlich und mit fremden Treibern von > NI mehr schlecht als recht machbar war, ist mir die Lust auf eine > gleiche Erfahrung mit dem DG1022 Fkt-Generator vergangen. Daher kann ich > Dir dazu leider auch nicht mehr sagen. Rigol muss was das Steuern und > Auslesen der Geräte mittels PC angeht langsam etwas mehr Enthusiasmus > zeigen. Prospektversprechen und Realität klaffen da noch weit > auseinander. Hallo Albert, danke für die Antwort. Ich habe es gestern einfach mal probiert (habe das Gerät erst seit ein paar Tagen) und siehe da: Sobald man die SCPI-Kommandos senden kann, geht alles ganz wunderbar. Jetzt am OT Ende. Viele Grüße W.T.
Hi Albert, dieses Wochenende habe ich etwas mehr Zeit gehabt, mich etwas mit meiner Fräse und Deinem Tool zu beschäftigen. Die ersten Tests hatte ich mit der 0.4.0 Version gemacht, dabei lief alles ganz gut. Als ich heute die 0.5.0 benutzt habe, reagierte die Anwendung nicht auf Eingaben: Codes konnte ich eingeben, im Monitorfenster gab's aber kein Feedback. Zurück zur 0.4.0 - alles lief problemlos. Irgendwas in der Kommunikation zwischen den Versionen hat sich geändert... Dann habe ich noch den 'UniversalGCodeSender' ausprobiert, ähnlich Funktionalität aber eigentlich gefällt mir Deiner besser. Einige schöne Features hat er trotzdem: - Man kann die $$ Settings in einer Tabellenform editieren und dann auf den Controller zurückschreiben - sehr schön. - Unter anderem kann man die Feedback Polling Rate einstellen, auch sehr schön. So kann man eperimentieren, wie oft man pollen kann, ohne die Codeausführung zu stören. Gruß Michel
Michael W. schrieb: > Die ersten Tests hatte ich mit der 0.4.0 Version gemacht, dabei lief > alles ganz gut. Als ich heute die 0.5.0 benutzt habe, reagierte die > Anwendung nicht auf Eingaben: Codes konnte ich eingeben, im > Monitorfenster gab's aber kein Feedback. Zurück zur 0.4.0 - alles lief > problemlos. Irgendwas in der Kommunikation zwischen den Versionen hat > sich geändert... Wenn Du auf der rechten Seite nichts eingeben/bedienen kannst, ist die serielle Kommunikation nicht etabliert. Im Programmcode wurde in den Kommunikations-Routinen zwischen den Versionen nichts geändert. Ich habe es bei mir noch mal mit verschiedenen Boards und PC's (Arduino Uno, Arduino Nano, aktueller PC mit Win7, vintage PC mit Windows XP) gestestet und alles läuft einwandfrei. Manchmal connecten die Arduino Boards nicht direkt beim ersten Einstecken des USB-Kabels. Das ist aber kein Problem meines Programms, sondern hat etwas mit den verwendeten USB/Seriell Treibern der Boards zu tun. > Dann habe ich noch den 'UniversalGCodeSender' ausprobiert, ähnlich > Funktionalität aber eigentlich gefällt mir Deiner besser. 'UniversalGCodeSender' ist eine Java basierte Anwendung. SerialComCNC ist eine nativ Windows Application ohne Abhängigkeiten. > Einige schöne Features hat er trotzdem: > - Man kann die $$ Settings in einer Tabellenform editieren und dann auf > den Controller zurückschreiben - sehr schön. Dazu habe ich bereits oben was geschrieben. Die Änderung von Parametern über die Eingabebox in meinem Programm ist auch nicht wesentlich aufwändiger. Vorläufig werde ich da nichts ändern. > - Unter anderem kann man die Feedback Polling Rate einstellen, auch sehr > schön. So kann man eperimentieren, wie oft man pollen kann, ohne die > Codeausführung zu stören. Das Polling erfolgt bei mir im Abstand von 150 ms, also ca. 6,7 mal pro Sekunde. Nach meinen Tests treten Störungen erst bei kürzeren Zeiten als 90 ms auf. Schnelleres Pollen bringt eh keinen praktischen Vorteil. Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo Albert, Bin neu hier und dank Grbl & Arduino Nano auf dein Projekt gestoßen. Natürlich habe ich mir dein Frontend gleich geladen, und es sieht toll aus nur leider gibt's es keine Verbindung zu meinen Arduino´s. Es kommt immer die Meldung: Serial Port Connection Error. Das die Verbindung funktionieren könnte zeigt mir die Verwendung des Grbl Controller (http://zapmaker.org/projects/grbl-controller-3-0/). Damit bekomme ich eine Verbindung hin. Was würdest du an Informationen benötigen um zu erkennen woran es liegen könnte? Getestet habe ich übrigens die Versionen 0.4a & 0.5. beides unter Win7/64. Abgesehen davon hab ich eine Frage zum Unterschied Uno zu Nano und Grbl. Die Pinbelegung zeigt ja beim Uno das z.B. für die X Achse Step und Dir auf den Pins 2 und 5 liegen. https://github.com/grbl/grbl/wiki/Connecting-Grbl Wenn ich nun den Nano verwenden will, sind Step und Dir aber auf den Pins 2 und 3. Beim gleichen Hex File und auch bei deinem Testaufbau im ersten Bild so zu sehen (wenn ich es richtig interpretiere). Hast du eine Idee wie man am Nano zur gleichen Pinbelegung kommt wie am Uno? besten Dank Andreas
Andreas H schrieb: > Es kommt immer die Meldung: Serial Port Connection Error. Bei mir funktioniert die Verbindung unter Windows 7 32bit. Ich werde in den nächsten Tagen aber mal mit verschiedenen Arduino Boards untersuchen, wo event. die Verbindungsprobleme bei Dir liegen könnten. Michael (siehe oben) hatte ja auch ähnlich Probleme. > Hast du eine Idee wie man am Nano zur gleichen Pinbelegung kommt wie am > Uno? Da musst Du mal den Entwickler der GRBL Software kontaktieren, bezw. in den GRBL Foren nachsehen. Oder wenn Du in C++ fit bist den Source Code der GRBL Software ändern. Gruss Ulrich Albert
:
Bearbeitet durch User
Andreas H schrieb: > Abgesehen davon hab ich eine Frage zum Unterschied Uno zu Nano und Grbl. > Die Pinbelegung zeigt ja beim Uno das z.B. für die X Achse Step und Dir > auf den Pins 2 und 5 liegen. > https://github.com/grbl/grbl/wiki/Connecting-Grbl > Wenn ich nun den Nano verwenden will, sind Step und Dir aber auf den > Pins 2 und 3. Beim gleichen Hex File und auch bei deinem Testaufbau im > ersten Bild so zu sehen (wenn ich es richtig interpretiere). > > Hast du eine Idee wie man am Nano zur gleichen Pinbelegung kommt wie am > Uno? Die Pinbelegung bei GRBL ist in allen Varianten gleich. Die Stepper werden immer !!! an dem Port D angeschlossen von PD.2 - PD.7 oder Audrinoseitig an Digital D2 bis D7. Wo die Pins an der Platine ausgeführt sind musst Du selbst finden. Waldemar
Vielen Dank für eure Mühe, ich habe das ganze Wochenende damit verbracht diverse Foren wegen der Pinbelegung zu durchstöbern, leider hat es nicht die erhoffte Erleuchtung gebracht.. Es ist auch nicht sehr tragisch, mir ist halt aufgefallen das auch hier im ersten Testaufbau Step und Dir pro Achse nebeneinander liegen was ja nicht der aktuellen Grbl Pinbelegung entspricht. Das für mich faszinierende ist halt das die Belegung wie sie in der cpu_map.h definiert ist, beim Uno das erwartete Ergebnis bringt, nicht aber beim Nano. Obwohl beide den ATMEGA328P verwenden. Vielleicht liegt es auch daran das der Nano ein Clone ist der sich da eigen verhält. Da muss ich noch etwas testen. Wie gesagt, nicht sehr tragisch. Ich verwende halt den Uno und fertig. Auf alle Fälle nochmal danke Andreas
Betr. Fehlermeldung "Connection Error" Ich bin jetzt mal der Ursache auf den Grund gegangen und habe folgendes festgestellt: Die Port-Auswahlbox zeigt alle angeschlossenen Devices (Portnummern) an. Daraus selectiert man dann den gewünschten Port und die Connection funktioniert. Wenn nur ein einziges serielles Device angeschlossen ist, zeigt die Port-Auswahlbox auch nur dieses an. Betätigt man nun den Connect-Button ohne den angezeigten Port expliziert zu selectieren, erscheint die Fehlermeldung "Connection Error". Es ist also notwendig den angezeigten Port expliziert mit der Mouse zu selectieren, auch wenn nur ein Port angezeigt wird. Mir ist das bisher nicht aufgefallen, da ich immer zwei zusätzliche virtuelle Ports (von com0com Nullmodem) aktiviert habe und ich so den Arduino Port immer mit der Mouse selectieren musste. Ich schaue mal für die nächste Version wie man das Verhalten der Port-Selectionsbox passend ändern kann. Bis dahin eben den angezeigten Port einfach vor dem Connect per Mouse selektieren. Im übrigen habe ich beim Test mit mehreren Arduino Uno's und Nano's bemerkt, dass einige nicht immer beim Anschluss im Windows Gerätemanager erscheinen, sondern erst nach mehrfachen Einstecken des USB-Kabels. Das ist allerdings dann ein Problem der Arduino Hardware. Insbesondere tritt dieses Verhalten bei den billigen China Clones auf, die original Arduino Uno's connecten immer auf Anhieb. Gruss Ulrich Albert
:
Bearbeitet durch User
Ah, ja so geht's auch bei mir. danke Andreas
Anbei SerialComCNC Version 0.5a Change Log V0.5a ---------------- Angezeigter Port wird jetzt auch ohne Mouse-Selektion übernommen. Bei der manuellen Steuerung wird bei Click auf "Home" (X0 Y0 Z0) jetzt zuerst die Z-Achse auf die Home Position gefahren (Z0 + eingestelltem Offset) und dann erst die X- und Y-Achse. Das vermeidet einen eventuellen Crash des Fräsers mit der Oberfläche des Werkstückes. Gruss Ulrich Albert Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/ Link zu meinem Project SerialComInstruments: Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"
:
Bearbeitet durch User
Hallo , ich habe eben diesen Beitrag gesehen und finde das Projekt super . Es wird immer von Stepperansteuerung gesprochen gehen auch Servoendstufen mit Schritt und Richtungssignal ? Das hex-File hat 77kb , wie gehen die in den ATMega 328 mit 32kB ? MfG Hans
Hallo Hans, ein hex-Datei ist keine Binär-Datei und somit unterscheiden sich die Dateilängen. Was eine (Intel) hex-Datei sagt dir das De-Wiki.
Hans Lang schrieb: > gehen auch Servoendstufen > mit Schritt und Richtungssignal ? Da viele Anbieter von Servoendstufen in den Beschreibungen angeben "kompatibel mit CNC-Steuerungen" denke ich mal das geht. Aber Versuch macht klug :)
Neues Feature Was haltet ihr von einer neuen Funktion um schnell präzise Löcher zu bohren? Und zwar ohne vorher Zeichnungs- und CAM-Software benutzen zu müssen. Also nur Eingabe der Koordinaten und Bohrtiefe, event. auch eine editierbare Liste, vielleicht auch lesbar aus z.B. einem Exel Sheet.
:
Bearbeitet durch User
Albert M. schrieb: > Was haltet ihr von einer neuen Funktion um schnell präzise Löcher zu > bohren? Fände ich gut. Habe dabei auch das Programm "Front Designer" von Abacom im Hinterkopf. http://www.abacom-online.de/html/frontdesigner.html
:
Bearbeitet durch User
Hallo Albert, schön wäre die Verarbeitung von Excellon Dateien. Damit ließen sich Platinen komfortabel bohren. Man brauchte eine Funktion zum Ausrichten der Platine z.B. über zwei Eckbohrungen. Dann zum Festlegen der Z-Verfahrebene und der Bohrtiefe. Nach Abarbeitung der Koordinaten für ein Tool sollte die X-Achse angehoben und auf den Werkzeugwechsel gewartet werden. Vielen Dank dass du deine Super-Programme der Community zur Verfügung stellst! Gruß Einhart
In der neuen c't Hacks wird auch ein GBRL-Frontend vorstellt. Ich hatte allerdings noch keine Zeit den Artikel zu lesen. Hat sich schon jemand die Software angesehen? Mit freundlichen Grüßen Thorsten Ostermann
Hi Thorsten, das Frontend aus der c't Hacks ist in erster Linie für deren GRBL Router mit Jogger gedacht, eine komplette Eigenentwicklung von c't mit anderem Prozessor... Natürlich kann man das Frontend anpassen, ich versuche gerade die Sourcen in Lazarus zu überführen um es evtl. für mich zu nutzen, da ich den 'normalen' 0.9 GRBL Code nutze. Da es in Delphi 2005 geschrieben wurde, könnte Albert eine Anpassung für den seriellen Port einbauen, es läuft nur mit der FTDI-DLL. Mich reizt die Funktionalität mit Kamera und Referenzpunktsuche... Mit einem einfachen GCode Sender hat die c't Anwendung nichts mehr gemeinsam. Michael
Einhart Pape schrieb: > schön wäre die Verarbeitung von Excellon Dateien. Damit ließen sich > Platinen komfortabel bohren. Das Excellon Format für die Bohrdaten werde ich mir mal ansehen. Michael W. schrieb: > Mich reizt die Funktionalität mit Kamera und Referenzpunktsuche Kamera-Einbindung für Referenzpunkt-Einstellung kann ich meinem Programm auch verpassen, auch wenn es vielleicht nur eine Spielerei ist. Ich habe den Artikel in der CT kurz überflogen und werde mir den mal in den nächsten Tagen genau ansehen. Was ich aber bereits jetzt dazu sagen kann: Das ganze Werk ersetzt keinesfall die herkömmliche Methode mit ordentlicher Zeichnung und G-Code Erzeugung mittels Cam-Software. Nirgendwo kann ich die notwendigen diversen Einstell- und Konfigurationsmöglichkeiten einer Cam-Software erkennen, wie sie z.B. in Filou oder sogar im kostengünstigen Estlcam vorhanden sind. Also, ich möchte mit der CT-Lösung kein präzises Werkstück erstellen und ich denke mal, dass ist auch garnicht deren Intension. Michael W. schrieb: > Da es in Delphi 2005 geschrieben > wurde, könnte Albert eine Anpassung für den seriellen Port einbauen, es > läuft nur mit der FTDI-DLL. Nö, ich werkele grundsätzlich nicht in anderen Leutz Softwerken rum. Einen wirklichen Vorteil kann ich in der CT-Lösung mit der FTDI-DLL auch nicht erkennen. Damit macht man sich nur von FTDI abhängig und gewinnt wenig. Gruss Ulrich Albert
:
Bearbeitet durch User
Angehängte Dateien:
> Michael W. schrieb: > Mich reizt die Funktionalität mit Kamera und Referenzpunktsuche Ich habe inzwischen mal kurz die Video-Anbindung für die Referenzpunkt-Einstellung implementiert. Das müsste mit allen gängigen Web-Cams funktionieren. In das Videobild wird ein Fadenkreuz und ein grössenverstellbarer Kreis im Mittelpunkt eingeblendet, die Strichstärke von Fadenkreuz und Kreis ist ebenso wie die Farbe einstellbar. Die Web-Cam wird neben dem Fräskopf mit Blick genau senkrecht nach unten befestigt. Kalibriert wird einmalig indem man das Fadenkreuz auf den Werkstück-Nullpunkt fährt, XY in der Software auf Null setzt und anschliessend, am besten mit einer Nadel im Bohrfutter manuell auf den Nullpunkt verfährt. Die angezeigten XY Werte werden jetzt als Offset gespeichert. Beim nächsten Start des Programms werden diese Offset-Werte wieder bei der optischen Nullpunkteinstellung verwendet. Leider kann ich euch dazu kein besonders schönes Bild zeigen, da meine Web-Cam keine manuelle Schärfeeinstellung hat und im Nahbereich nichts taugt. Deshalb im Bild oben ein weisses Blatt als Hintergrund :) Die neue Version wird vielleicht in der nächsten Woche bereits fertig sein.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.6.jpg
380 KB
Anbei SerialComCNC Version 0.6 Change Log V0.6 --------------- Video/WebCam zur optischen Nullpunkt-Einstellung implementiert. Die Anleitung ist unter Hilfe zu finden. Ich bitte um Rückmeldung, da ich hier zur Zeit keine Testmöglichkeit mit meiner Fräse habe. Und sorry, meine Webcam liefert wegen der fehlenden Einstellmöglichkeit im Nahbereich nur unscharfe Bilder.
:
Bearbeitet durch User
Einwandfreie Sache ! Vielen Dank für deine Arbeit. Ich könnte sowas nicht.... Und passend zum Wochenende. Da werden sicher viele Leute Zeit zum Testen haben. Gut gemacht !
Hello Gibtes eine version für den Raspberry ? Besten Dank für ein antwort PS meine Mutersprache ist französich ich komme aus der Schweiz.
Hi, coole Sache. Man kann den Kameraoffset vielleicht auch einfacher einstellen: mit einem feinen Fräser ein Loch in eine Opferplatte fräsen und dann den Fräskopf soweit bewegen, bis des Fadenkreuz im Videobild im Zentrum des Bohrlochs liegt. Mir ist die Positionierung des Fräskopfes mit eingespanntem Werkzeug immer zu schwierig, jedenfalls auf Zehntel, geschweige denn Hundertstel genau, daher nutze ich lieber die obige Methode. Besten Dank nochmal für Deine Mühe. Michael
Daniel Devaux schrieb: > Gibt es eine version für den Raspberry ? Google mal nach GRBL+Raspberry, muss dann allerdings GRBL 0.9g sein. Mein Programm gibt es nur in der vorliegenden Windows Version. Michael W. schrieb: > Man kann den Kameraoffset vielleicht auch einfacher einstellen Guter Tip, Michael!
Albert, nach längerer 'Abstinenz' bin ich grade mal wieder auf meiner 'grbl'-Tour um mich wieder auf Stand zu bringen und ich muss sagen, daß ich ziemlich beeindruckt bin! Besonders die Tatsache, daß SerialComCNC ohne Installation auszukommen scheint, macht die Software schön flexibel. Die Geschichte mit der WebCam mag vielleicht anfänglich wie Spielerei anmuten, hat aber in jedem Fall besonders bei nicht so präzisen Maschinen und/oder Bearbeitungen mit nicht so engen Toleranzen ihre Berechtigung und spart durch die Unabhängigkeit vom eingespannten Werkzeg Zeit beim Einrichten. Alles in allem eine sehr gelungene und erstklassige Alternative zu anderen grbl-Frontends, vielen Dank! Ich bin bestimmt nicht der einzige, der schon jetzt auf die nächste Version und die nächsten Features gespannt ist... Respekt auch für die anderen Projekte auf Deiner Homepage. Die SerialConInstruments sehen auch sehr interessant aus. Wenn der Tag doch nur mehr Stunden hätte...! Besten Gruß Piter
Albert M. schrieb: > Einhart Pape schrieb: >> schön wäre die Verarbeitung von Excellon Dateien. Damit ließen sich >> Platinen komfortabel bohren. > > Das Excellon Format für die Bohrdaten werde ich mir mal ansehen. > Hallo, schau dir mal Beitrag "Re: CNC-Fräse im Selbstbau" an, excellon sowie excellon2 .
Hallo Ulrich Albert, als stolzer Besitzer einer Eigenbau-Fräse und dem Arduino mit GRBL bin ich zur Zeit auf der Suche nach einer Bezugsquelle für den TinyG. Dabei bin ich zufällig auf 'Deine' Seite geraten. Dabei habe ich erstaunt festgestellt, daß wir beide zur gleichen Zeit am selben Thema 'schrauben'. Respekt, was du in so kurzer Zeit auf die Beine gestellt hast. Ich glaube das beurteilen zu können weil mir viele deiner geschilderten Probleme, wie z.B. das Rücksender der Achspositionen mit '?' sehr bekannt sind. Bin mit meiner Lösung übrigens immer noch unzufrieden. Auch beneide ich dich um deine Fans, die dich mit guten praktischen Ideen nahezu überschütten. Eine Software ist am Ende immer so gut wie ihre Tester. Ich werde in Zukunft diese Seite immer mal wieder aufsuchen, um mich ein wenig von euch inspirieren zu lassen. Falls du auch mal Lust haben solltest andere Ideen, Anregungen oder verbesserbare- oder schlechte Beispiele zum Thema Grbl-Drumrum-Programme zu sehen, schau doch mal auf meine Baustelle: http://www.shapeoko.com/forum/viewtopic.php?f=6&t=4710&start=10 Da gibt es auch ein Filmchen und meinen 1. Versuch einer Bedienungsanleitung. Gruß + weiter viel Erfolg GrblGru
@ GrblGru Leider bekomme ich Deine Software nicht wirklich zum Laufen. Es treten unregelmässige Exceptions auf. Trotz Installationsprogramm ist eine Installation nur im Windows Programm Ordner möglich. Ansonsten sieht die 3-D Darstellung geil aus. Ich wünsche Dir auch noch viel Spass und Erfolg bei der weiteren Entwicklung. Gruss Ulrich Albert
Angehängte Dateien:
-
SerialComCNC_v0.7_Bild1.jpg
270 KB
Anbei SerialComCNC Version 0.7 Change Log V0.7 --------------- Excellon Bohrdaten Import (drl Text-Files). Das importierte Excellon-File wird mit einstellbaren Parametern in G-Code transformiert. Das Excellon-File muss dabei die Koordinaten in Millimetern mit Dezimalpunkt als Komma anbieten. Diese Einstellung dürfte eigentlich in allen Platinen Layout Programmen möglich sein. Das importierte Excellon-File als auch der erzeugte G-Code ist editierbar. Ich werde mal schauen, ob für die nächsten Version eine Möglichkeit für einen/mehrere manuelle Werkzeugwechsel besteht, obwohl das durch GRBL nicht direkt unterstützt wird. Eine Weg-Optimierung (Travelling Salesman), falls notwendig, kommt in einer der nächsten Versionen. Gruss Ulrich Albert Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Du bist wirklich von der schnellen Truppe Ulrich Albert! Ich bin wirklich beindruckt. Herzlichen Dank dafür. Gruß Einhart
Anbei SerialComCNC Version 0.7a Change Log V0.7a ---------------- Funktionen für manuellen Werkzeugwechsel implementiert. Optional werden im G-Code (gilt natürlich auch für konvertierte Excellon Files) die Befehle Txx für den Werkzeugwechsel erkannt. Die Maschine fährt auf eine wählbare Z-Höhe und dann auf die X und Y Null-Position (kann später event. noch wählbar gemacht werden). Nach dem manuellen Werkzeugwechsel wird auf die letzte Bearbeitungsposition zurückgefahren und der G-Code weiter abgearbeitet. Im Programm muss für diese Funktion "Use Tool Change Txx" markiert werden und bei Verwendung von Excellon Files im Konvertierungsfenster ebenfalls "Use Tool Change" markiert sein. Die Wechselhöhe wird unter Settings eingestellt und bleibt persistent (im ini-File). Zusätzlich wurden einige Bugs behoben. Gruss Ulrich Albert
:
Bearbeitet durch User
Waldemar P. schrieb: > Ich selbst benutze GRBL bei meiner Platinenfräse dazu > Konvertiere ich die Exellon Bohrdaten ( DRL ) und HP-Plotdaten ( PLT ) > zur G-Code um die Fräse mit Daten zu füttern. Als Vorschlag zu späterem > Zeitpunkt, so eine zusätzliche Implementierung der Funktionen, wird > bestimmt vielen Usern nützlich sein. Da die meisten hier mit > Elektronikbasteleien am werkeln sind. Das habe ich vor 2 Monaten geschrieben, und sehe da die erste Routine ist implementiert.Ich bin begeistert und beeindruckt von diesem Program. Noch eine Routine für HPGL um den angeschlossenen Geräten bei Fräsen von Platinen und Frontplatten auf die Sprünge zu helfen Dann ist der „ Meisterwerk “ perfekt. Schöne Grüsse Waldemar
Danke für das faszinierende Frontend ! Wenn da alle Vorschläge machen , hab ich auch einen. Dieser würde dann ein defacto Alleinstellungsmerkmal sein für dein Programm. Schau dir mal Visolate an bei Github. Das generiert aus Gerberdateien fürs PCB-Fräsen sogenannte Voronoi-Toolpaths Auch ein Linuxprog pcb2gcode macht das gleiche, nur alles unkomfortabel. Nicht jeder ist firm mit Linux und Java.... Danke für deine Mühen.
Event. Fehler in der "Tool Change Funktion" in Version 0.7a Bei mir treten jetzt sporadisch Fehler bei Verwendung der Tool Change Funktion auf: "bad number format". Die Ursache konnte ich noch nicht entdecken, da im G-Code vordergründig zuerst mal alles normal aussieht. Vielleich läuft bei der Übertragung was schief. Ich kann mich leider erst nächste Woche darum kümmern. Bitte bis dahin diese Funktion nicht benutzen, da nach der Fehlermeldung weitere Koordinaten event. nicht richtig übernommen werden. Fräser schrieb: > Schau dir mal Visolate an bei Github. Das generiert aus Gerberdateien > fürs PCB-Fräsen sogenannte Voronoi-Toolpaths So weit ich weiss bieten diese Funktion (Isolations-Fräsen) doch inzwischen alle Platinen-Layout Programme direkt an und geben die Daten im HPGL-Format aus. Das kann sogar Sprint Layout. Es wäre also nur das HPGL-Format in G-Code zu wandeln.
Fräser schrieb: > Das generiert aus Gerberdateien > fürs PCB-Fräsen sogenannte Voronoi-Toolpaths Er meint damit nicht die üblichen Isolationsbahnen, sondern speziell optimierte. Schau dir das mal an : http://runcnc.files.wordpress.com/2010/11/dsc_3056.jpg So eine Möglichkeit würde mich auch sehr interessieren. Danke für dein Programm !
Albert M. schrieb: > Fehler in der "Tool Change Funktion" in Version 0.7a Ich habe den Fehler gefunden. Die "Tool Change Funktion" wird komplett überarbeitet, die korrigierte Version kommt in den nächsten Tagen. Fräser schrieb: > Schau dir mal Visolate an bei Github. Das generiert aus Gerberdateien > fürs PCB-Fräsen sogenannte Voronoi-Toolpaths Das ist mir zu aufwändig, da sollten die normalen Isolations-Fräsdaten reichen.
ist es machbar, richtigen Gcode zu erzeugen. Nicht nur Txx, sondern auch m6 und im Gcode, wenn Txx vorkommt, dies einfach speichern, und bei m6 wenn dies vom programm selbst geparst wird, sollte konfigurierbar sein, dann die entsprechende Aktion ausloesen. Txx is nur ein Toolwechsel, der richtige toolwechsel ist m6, was eigentlich ein m6P=xx ist. Nur weil historisch bedingt, wurde das auf T und m6 beschraenkt. Grund war oder ist, dass bei gewissen maschinen ein Revolverkopf das Werkzeig zur Wechselposition bringt. Dies braucht eine gewisse Zeit. So kann man T3 m6 T8 (vorbereitung fuer kommenden Werkzeugwechsel) G1... ... m6 (ladet T8 ohne auf den Revolverkopf zu warten) T4 (vorbereitung ...) Auch eine (MSG, CHANGE TOOL TO xx) kann sinnvoll sein. Gruss Chris
chris schrieb: > ist es machbar, richtigen Gcode zu erzeugen. > Nicht nur Txx, sondern auch m6 .... Leider bietet GRBL keine Funktionen für autom. oder manuellen Toolwechsel an ( https://github.com/grbl/grbl/wiki ). Deshalb auch meine Klimmzüge im Programm um zumindest einen manuellen Toolwechsel nachzubilden. Einen autom. Toolwechsel werde ich nicht programmieren, da wohl kaum jemand hobbymässig solche CNC-Maschinen zuhause stehen hat. chris schrieb: > Auch eine (MSG, CHANGE TOOL TO xx) kann sinnvoll sein. Das lässt sich implementieren.
:
Bearbeitet durch User
Albert M. schrieb: > da wohl kaum > jemand hobbymässig solche CNC-Maschinen zuhause stehen hat. Das nicht.... aber an solchen Maschinen wird EMC oder Mach3 verbreiteter sein.
> Leider bietet GRBL keine Funktionen für autom. oder manuellen > Toolwechsel an ( https://github.com/grbl/grbl/wiki ). Deshalb auch meine > Klimmzüge im Programm um zumindest einen manuellen Toolwechsel > nachzubilden. > Einen autom. Toolwechsel werde ich nicht programmieren, da wohl kaum > jemand hobbymässig solche CNC-Maschinen zuhause stehen hat. > Schon klar, auch wenn ich diese Klimmzuege problematisch ansehe. Was ich vorschlagen wollte, Txx -> speichert Werkzeug M6 -> Unterbricht programm, und macht folgendes, auf jeden Falle werden die Zeilen danach nicht im gbrl gebuffert: optional sendet M5 (spindle stop) optional sendet G4P=... (dwell pause time) wartet auf ok. sendet ? zu GBRL und speichert Position A sendet G53G0Z0 wartet auf ok sendet ? zu GBRL und speichert Position B wenn A == B, dann sende G90 sendet G53G0Z0 wenn wechselpos xx sowie yy nicht -1 ist, dann sendet G53G0XxxYyy wechselposition. warte bis Benutzer ok drueckt. jogging sollte machbar sein. sendet G53G0Z0 sendet G53G0XaxYay pos aus Variable a sendet G53G0Zaz pos aus variable a wenn A == B dann sende G91 das wars. Spindle stop/start sollte noch irgendwie beachtet werden, kann aber auch nur ueber buttons gemacht werden. Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. Dann waere auch ein normales Gcode Program mit Werkzeugwechsel machbar und auch nur das eventuelle copieren vom Gcode und ausfuehren mit emc oder mach3 z.B. > chris schrieb: >> Auch eine (MSG, CHANGE TOOL TO xx) kann sinnvoll sein. > > Das lässt sich implementieren.
> Schon klar, auch wenn ich diese Klimmzuege problematisch ansehe.
Was ich damit meinte ist, einfach an eine Wechselposition xy zu fahren,
unabhaengig sowie ev. ohne relativ/absolute Koordinaten zu
beruecksichtigen.
nach dem Jogging sollte nochmal zur Sicherheit ein G90 gesendet werden.
chris schrieb: > M6 -> Unterbricht programm M6 wird von GRBL nicht unterstützt, es lässt sich aber M0 verwenden. chris schrieb: > Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. Eben nicht, siehe im Thread weiter oben. Das Problem bei GRBL ist, dass immer mehrere G-Code Befehle in einen Puffer gelesen werden. Welchen Befehl der Processor aber gerade tatsächlich abarbeitet ist nicht mit irgendwelchen Statusmeldungen verknüft, es werden lediglich auf Anforderung die jeweilig aktuellen Koordinaten ausgegeben. Es gibt Workarrounds, aber die sind alle mehr oder weniger fehlerträchtig. Ich habe aber so weit eine Lösung gefunden, die Deiner oben skizzierten Befehlfolge ähnelt.
:
Bearbeitet durch User
Albert M. schrieb: > chris schrieb: >> M6 -> Unterbricht programm Ich meinte damit in deinem Code, und dass dann nichts weitergesendet wird, bis eben alles abgearbeitet wurde. Dies liese sich mittels '?' sogar abfragen. // Returns the number of active blocks are in the planner buffer. if (bit_istrue(settings.status_report_mask,BITFLAG_RT_STATUS_PLANNER_BUFFER )) { printPgmString(PSTR(",Buf:")); print_uint8_base10(plan_get_block_buffer_count()); } > > M6 wird von GRBL nicht unterstützt, es lässt sich aber M0 verwenden. > Nicht wirklich. Es waere aber kein Problem M6 einzufuegen, dazu braucht es nur 4+ kleine Aenderungen. T wird ja bereits unterstuetzt und normalerweise auch zum Auswahl des externen Motor MUX verwendet fuer den pulse ausgang. Funktioniert aber nur, wenn dann das Jogging ueber $J geht, ansonsten no go, oder eben wenn M6 uebertragungsende heisst und in m0 umgewandelt wird, wobei mir die letztere Loesung mehr gefaellt. > chris schrieb: >> Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. > Doch , mit $G bekommt man raus, inch/mm sowie G90/91 und eben auch M3/M4/M5. Wenn interesse besteht, fuege ich dir m6 rein, aber M0 unter SW control ist besser, da man dann nicht $J verwenden muss.
chris schrieb: >> chris schrieb: >>> Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. >> > Doch , mit $G bekommt man raus, inch/mm sowie G90/91 und eben auch > M3/M4/M5. Ich kenne die GRBL Kommandos :) $G hilft aber bei der Problemstellung nicht weiter. chris schrieb: >> M6 wird von GRBL nicht unterstützt, es lässt sich aber M0 verwenden. >> > Nicht wirklich. Doch, ich habe inzwischen Tests mit M0 vorgenommen und das funktioniert problemlos. Es mag ja sein, dass M0 auf grossen Profi-CNC's aus irgendwelchen Gründen nicht optimal ist, für Hobbygeräte und nur dafür ist meine Software gedacht, spielt das aber keine Rolle. Meine neue Implementation wird so aussehen: Kommt im G- oder Excellon-Code ein Txx (Werkzeugwechsel) vor, so wird optional in den Code automatisch ein M0 eingefügt. Beim Maschinenlauf wird dann an dieser Stelle angehalten, XYZ auf eine Wechsel/Null-Position gefahren und eine Meldung über die geforderte Werkzeugnummer xx ausgegeben. Nach Werkzeugwechsel wird auf die ursprüngliche Position zurückgefahren und der Code weiter abgearbeitet. Das funktioniert soweit, bedarf aber noch weiterer Tests. chris schrieb: > Wenn interesse besteht, fuege ich dir m6 rein Danke, aber Änderungen im GRBL Source Code wurden oben bereits diskutiert und ich habe mich dagegen entschieden. Bei einer Modifikation müsste ich bei neuen GRBL-Versionen die vorgenommenen Änderungen jedesmal neu einfügen/supporten. Und meine Software wäre dann jeweils nur mit modifizierten GRBL-Versionen lauffähig. Zudem habe ich keine Lust auf 2 Baustellen zu werkeln. Das Projekt fängt eh schon an auszuarten. Eigentlich wollte ich nur ein Mini-Tool für eigene Bedürfnisse für meine Käsefräse entwickeln um hier und da mal ein wenig rumzufräsen.
:
Bearbeitet durch User
Ok. So wie ich es Kenne wird beim manuellem Werkzeugwechsel nur z auf g53 null gefahren. Dann kann man manuell die POS andern und auch z.b g92 für Werkzeug offset usw. Bei m0 kann man nicht mehr manuell verfahren, da geht nur warten oder weiter. Deshalb geht m0 anstelle von m6 nicht so gut . Es ist aber eine einfache Lösung. Mit einer Wechselposition geht es, nur wenn man Zwingen oder so hat, um das Werkzeug festzuhalten, dann ist so eine Wechselpos. Kritisch. Bei Platinen ist sowas nicht so kritisch. Es wäre aber schön wenn auch anderen code als Platine gestreamt werden kann und dabei der Werkzeugwechsel funktioniert. Muss aber nicht sein.
Albert M. schrieb: > chris schrieb: >>> chris schrieb: >>>> Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. >> Doch , mit $G bekommt man raus, inch/mm sowie G90/91 und eben auch >> M3/M4/M5. > > Ich kenne die GRBL Kommandos :) > $G hilft aber bei der Problemstellung nicht weiter. Ich meinte hier den Status von m3/4/5 Der Motor sollte ja auch abgeschaltet werden und dann wieder eingeschaltet.
Hallo, bin Einsteiger in Hobby CNC und bin kürzlich auf diesen Thread gestoßen. Zunächst mal große Anerkennung für die Leistung! Habe natürlich das Programm sofort auf meinen Arduino mit grbl losgelassen. Leider habe ich derzeit noch keine Schrittmotortreiber.... Mir ist aber was aufgefallen, das ich hier berichten möchte: - Wenn man den COM Port verbindet meldet das Programm, daß die Verbindung steht tatsächlich beginnt der Datenverkehr aber erst nachdem man OK geklickt hat. - Aus Versehen habe ich den COM Port des Arduino Programmers angegeben. Der hat offensichtlich geantwortet und dann sind hunderte Meldungsfenster am PC aufgegangen. Nun - ich mußte das Programm abschießen.... Bitte das nicht als Kritik verstehen! Wollte das nur melden ... vielleicht ist ja der Bugfix gerade mal eine Codezeile Aufwand. Grüße Johannes
Johannes schrieb: > Aus Versehen habe ich den COM Port des Arduino Programmers angegeben. > Der hat offensichtlich geantwortet und dann sind hunderte > Meldungsfenster am PC aufgegangen Danke für die Info, der Fehler ist mir bekannt und wird in der nächsten Version behoben. Ausserdem, Behandlung von Werkzeugwechseln (Fehler in der letzten Version): Eine passende Behandlung von Werkzeugwechseln nach den jeweiligen Txx G-Code Befehlen ist mit GRBL anscheinend doch nicht so trivial wie gedacht und bedarf noch einiger Tage. Einen Guten Rutsch ins neue Jahr Ulrich Albert
Angehängte Dateien:
-
SerialComCNC_0.7b.jpg
320 KB
Anbei SerialComCNC Version 0.7b Change Log V0.7b ---------------- Bei mehreren angezeigten Com-Ports wird jetzt geprüft ob bei der gewählten Verbindung GRBL antwortet. Falls nicht, wird die Verbindung geschlossen und eine Meldung angezeigt. Es wird nun eine Unterbrechung der Com-Verbindung während des laufenden Betriebes erkannt und eine Warn-Meldung ausgegeben. Es ist ein Neustart des Programms notwendig. Änderungen / Fehler-Behebung im "Use Tool Change" Mode: Wenn Werkzeugwechsel "Use Tool Change" aktiviert ist, wird der jeweils nächste bevorstehende Werkzeugwechsel im Monitor-Fenster incl. der Werzeugnummer Txx angezeigt. Wenn im Programmfluss Txx erreicht wird, wird das GRBL-Programm mittels intern eingefügtem M0 angehalten, die aktuelle Position gespeichert und die Z-Achse um 20 mm hochgefahren. Es muss abgewartet werden bis im Process Display "Idle" angezeigt wird. Über die Bedienbuttons im Manual Process Fenster können die Achsen jetzt beliebig verfahren werden, um eine optimale Position zum Werkzeugwechsel zu erreichen. Nach dem Werkzeugwechsel wird zum Fortfahren der Button "Cont" im Process Display betätigt. Die X- und Y-Achsen und danach die Z-Achse werden nun auf die gespeicherte Position zurück gefahren und das G-Code Programm fortgesetzt. Programm-Ende G-Code Commando M30: Das G-Code Commando M30 wird erkannt, jedoch in SerialComCNC nicht mehr in GRBL zur Ausführung gebracht. Der Grund ist folgender: M30 bewirkt in GRBL nicht nur die Beendigung der Bearbeitung, sondern leider auch ein Reset. Damit werden die aktuellen Achsen-Positionen mit irgendwelchen Werten überschrieben und es müsste eine erneute Werkstück Nullpunktbestimmung durchgeführt werden (dies betrifft die Welt-Koordinaten mit denen SerialComCNC arbeitet). Die interne Unterdrückung von M30 hat ansonsten keinerlei Nachteile. Beim Erreichen von M30 können die Achsen über den neuen Nullpunkt-Button im Process Display auf den XYZ-Nullpunkt zurückgefahren werden.
:
Bearbeitet durch User
Hallo kann mir jemand helfen? Soweit funktioniert alles (bis zum Fehler). Erst mal ein grosses Lob an deine Arbeit find ich klasse. Bestrome ich das System läuft es sauber an und beginnt auch zu fräsen aber irgendwann (nach 1 oder 2 min) kommt die Fehlermeldung writefile communication failure Error:31 Die Fräsung stoppt und und nach dem Wegklicken der Fehlermeldung geht nichts mehr (Tankmanager beenden des Tasks notwendig). Der Comport (in Systemeinstellungen) ist noch da aber ich kann keine Verbindung mehr aufbauen zum Arduino mit dem Tool. Es muss der Uno einmal abgesteckt werden und dann gehts wieder. Hat jemand ne Idee? Im Tool steht Baudrate auf 115200 und ebenso in der Systemeinstellung. Auf dem Uno (Clone) ist die Firmware aus dem Ordner drauf. Gruß Daniel
:
Bearbeitet durch User
Daniel S. schrieb: > Bestrome ich das System läuft es sauber an und beginnt auch zu fräsen > aber irgendwann (nach 1 oder 2 min) kommt die Fehlermeldung > writefile communication failure Error:31 Ich habe bei mir Langzeittests gemacht, der beschriebene Fehler tritt dabei nicht auf. Ich denke, dass die Ursache ein EMV Problem Deiner Beschaltung ist. Fräse und Arduino sollten je eine eigene Stromversorgung haben. Die Stepper-Driver möglichst galvanisch getrennt (über Optokoppler) mit dem Arduino verbinden. Möglichst kurze Verbindungen verwenden, usw. So sieht das zumindest bei mir aus und da läuft es problemlos.
Hallo und danke für das Projekt. Albert M. schrieb: > die aktuelle Position > gespeichert und die Z-Achse um 20 mm hochgefahren Kann man diesen Weg von 20mm einstellbar machen ? Die Z-Achse meiner Platinen-Bohrmaschine erlaubt leider nur max. 15mm Vielen Dank
ein erfreuter Benutzer schrieb: >> die aktuelle Position gespeichert und die Z-Achse um 20 mm hochgefahren > > Kann man diesen Weg von 20mm einstellbar machen ? > Die Z-Achse meiner Platinen-Bohrmaschine erlaubt leider nur max. 15mm Kein Problem, wird in der nächsten Version implementiert. Entweder dann auf 10 mm geändert oder einstellbar.
:
Bearbeitet durch User
Albert M. schrieb: > oder einstellbar Das wäre natürlich optimal. Vielen Dank ! Super - nach Minuten schon eine positive Antwort.
Anbei SerialComCNC Version 0.7c Change Log V0.7c ---------------- Werkzeugwechsel Warte-Position (Tool Change Pos) jetzt frei einstellbar. Die eingestellte Position wird im ini-File gespeichert. Die Video Anzeige (WebCam) ist nun unabhängig von der gewählten Video- Auflösung (Standard 640x480)und wird auf den verfügbaren Anzeigebereich mittig skaliert. Homepage http://www.serialcominstruments.com/
:
Bearbeitet durch User
Vielen Dank Ulrich. Jetzt funktioniert der Bohrerwechsel auch bei mir. Macht richtig Spaß. So ein Programm hatte ich mir immer für meine kleine CNC gewünscht.
...wirklich tolles Programm, welches ich an meinem Selbstbaulasergravier betreibe. Um Längen komfortabler als die diversen GCodesender! Klasse, danke dafür !!!
Angehängte Dateien:
-
IMG_5923a.jpg
530 KB -
IMG_5925a.jpg
470 KB
Für die optische Nullpunkteinstellung mittels WebCam habe ich mir einen passenden Adapter für die Proxxon MF70 gefräst. Durch eine 1mm Vertiefung für den Körper der WebCam verruscht diese auch bei heftigen Bewegungen nicht. Durch den leicht konischen Lagerring (oder wie immer man das nennt) der MF70 sitzt die Cam bombenfest durch einfaches Aufschieben.
Hallo, ich bin neu in Sachen CNC, also ich bitte um Nachsicht. Problem: Ich habe eine China Fräse CNC 3040T. Der Controller ist ein Z-DQ mit paralleler Schnittstelle für Mach3 oä. Da ich Mach3 nicht habe und über SerialComCNC nur Gutes gehört habe, würde ich die Fräse gern damit betreiben. Allerdings würde ich den Controller ungern rausschmeißen. Kann ich SerialComCNC über einen geeigneten Konverter an meinem parallelen MACH3 Kontrolle betreiben? Ein paar Arduino hab ich auch rumliegen. Kann mich jemand in die richtige Richtung schubsen? Vielen Dank P.S. Also, dass ich GRBL auf den Arduino bringen muss, hab ich soweit verstanden. Was ich diesbezüglich so gesehen habe, steuert der Arduino die Motorkontroller dann direkt an. Ich will aber vom Arduino auf die parallele vom Mach3 Controller
:
Bearbeitet durch User
Hallo Reiner, Du hast ein an deiner CNC höchst wahrscheinlich kein Controller sondern nur Motorsteuerung mit Endstufen die durch Parallelport angesteuert werden können. Zum Betrieb der CnC brauchst Du eben ein Controller, entweder ein PC mit Mach3, WinCNC oder PC-NC oder ein Controller wie eben GRBL auf einem Arduino. Du Kannst auf dem Arduino den GRBL aufspielen und die Signalports des Arduino mit dem Parallelanschluss der Motorsteuerung verbinden.
Vielen Dank Waldemar. Auf so eine Antwort habe ich gehofft;-) Da mach ich mich mal an die Arbeit.
Angehängte Dateien:
-
20150115_125422.jpg
220 KB
Hello, sorry for disturbing this German speaking forum, but there is no english speaking forum about this nice project SerialCOM CNC! Many Thanks Ulrich!!! I would like share my project, a expansion board for Arduino UNO + GRBL v0.9g. This board have more features, I will start production of PCB. I am collecting contacts and interested peoples, simply more peoples = cheaper PCB, and also more people have more good ideas. As example, this board also solve problem with cheaper chinese Arduinos, they halt on USB serial communication with 115200bps. There is serial convertor for that replace. Second thing,I am developing second I/O board with arduino, it will help to connect additional sensors and input/outputs to your cnc. (cooling, water, air, laser, vacuum, lighting, measure something, etc.). GRBL project is not supporting that, but I have idea how simply expand... use same one USB cable, use same one SerialCom CNC software with small extension KPr
Als nächstes habe ich folgende Funktion in Angrfiff genommen:
Werkzeuglängen-Sensor / Probing für die Z-Achse.
Ich teste gerade die in GRBL 0.9g verfügbaren Funktionen
G38.2 : Probing
G43.1 und G49 : Dynamic Tool Length Offsets
Mangels Werkzeuglängen-Sensor benutze ich für das Testen einen einfachen
metallische Kontakt (kupferkaschierte Platine) und fahre den Fräser mit
F1 einfach vorsichtig drauf. Funktioniert erstmal problemlos :)
Taugt dieser Werkzeuglängen-Sensor was?
http://www.ebay.de/itm/Werkzeuglangenmesser-Werkzeuglangensensor-Werkzeugtaster-CNC-Frase-/321380535406?pt=Industriemaschinen&hash=item4ad3c5cc6e
:
Bearbeitet durch User
Hallo Albert, voll genial dein projekt. Grüsse Matthias
Hallo Albert, Wie sieht´s den aus mit dem HPGL Implementierung ? Bist Du da schon weiter gekommen ? Das würde das Programm endgültig Richtung Olymp katapultieren. Eine All in One ElektronikBastlerOberfläche für GRBL. Schöne Grüße Waldemar
Waldemar P. schrieb: > Wie sieht´s den aus mit dem HPGL Implementierung ? Ich denke mal, dass ich einen HPGL > G-Code Converter für die nächste Version hinbekomme. Bitte schau Dir mal an, ob ich für die Konvertierung nichts vergessen habe: PA goto Absolute Position (bezogen auf den vorher festgelegten Nullpunkt wie alles in SerialComCNC; nicht auf Maschinen-Koordinaten) PR goto Relative Position PD Spindel down PU Spindel up SP Select pen (Werkzeugwechsel), fraglich ob nötig/zuerst mal nicht Eingabebox: Feedrate für Einstechen Eingabebox: Feedrate für Fräsen Eingabebox: Sicherheitshöhe (Pen up) Eingabebox: Einstechtiefe (Pen down) Eingabebox: Skalierungsfaktor HPGL (Standard ist hier glaube ich 1016) Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo Albert, Das hört sich gut an. zur deinen Eingaben: Albert M. schrieb: > Eingabebox: Feedrate für Einstechen > Eingabebox: Feedrate für Fräsen > Eingabebox: Sicherheitshöhe (Pen up) > Eingabebox: Einstechtiefe (Pen down) > Eingabebox: Skalierungsfaktor HPGL (Standard ist hier glaube ich 1016) Noch eine Geschwindigkeit wäre von Vorteil „Freie Fahrt“ das heißt nach einem PD alle PA´s mit Fräsgeschwindigkeit Nach einem PU mit „Freie Fahrt“. Die Einheiten für HPGL sind entweder 1/40 mm oder 1/1000 Zoll im Klartext entweder 0,025 mm oder 0,0254 mm. Die Datei könnte so aussehen: PU; G1Z(oben)F(x) x –Geschwindigkeit Freie Fahrt SP3; ignorieren PA135,176; /40 X3,375Y4,4F(x) PD; Z(unten)F(einstechen) PA148,167; /40 X3,7Y4,175F(fräsen) PA163,164; /40 X4,075Y4,1 PA178,167; /40 X4,45Y4,175 PU; Z(oben)F(heben) PA226,189; /40 X5,65Y4,725F(x) PD; Z(unten)F(einstechen) PA235,176; /40 X5,873Y4,4F(fräsen) PA248,167; /40 X6,2Y4,175 PA263,164; /40 ...... Gruß Waldemar
Moin Albert! Zunächst ganz vielen Dank für die tolle Software! Mir ist ein kleiner Bug aufgefallen, den ich leider nicht exakt reproduzieren kann, allerdings ist er bei mir schon mehrfach aufgetreten. Ich benutze die aktuelle Version von SerialComCNC (0.7c) unter Win7 64 Bit. Wenn ich im Bereich "Manual Process" viel mit den Knöpfen für die Einheiten des Verfahrweges (10/1/0.1/0.01) rumgespielt habe, werden irgendwann alle weiteren Betätigungen dieser Knöpfe ignoriert und es sind nur noch Veränderungen von 1 mm möglich. Auch die Tastatureingabe eines Wertes funktioniert dann nicht mehr. So weit ich bisher sehe, hilft dann nur noch ein Neustart. Ist nicht gar so schlimm das Problem, aber ich dachte ich geb mal Feedback, vielleicht lässt sich der Fehler ja schnell finden und beheben. Viele Grüße Malte
Angehängte Dateien:
-
SerialComCNC_v0.7d.jpg
390 KB
Anbei SerialComCNC Version 0.7d Change Log V0.7d ---------------- HPGL-File (.plt) Import Konverter nach G-Code Unterstützt werden folgende Befehle: PU, PD, PA, PR. Alle sonstige Befehle werden ignoriert. Einstellbare Parameter: Feedrate für Einstechen Feedrate für Fräsen Sicherheitshöhe (Pen up) Einstechtiefe (Pen down) Skalierungsfaktor HPGL (0,025) metrisch @ MTA Danke für die Info.
:
Bearbeitet durch User
Hallo Albert, Tolle Leistung Danke !!! Albert M. schrieb: > Einstellbare Parameter: > Feedrate für Einstechen > Feedrate für Fräsen > Sicherheitshöhe (Pen up) > Einstechtiefe (Pen down) > Skalierungsfaktor HPGL (0,025) metrisch Ich habe mir die generierten Daten angeschaut soweit alles gut. In dem Header Sind noch Unstimmigkeiten vorhanden. M3 Spindel EIN G00 Z4.00 Z-Achse Sicherheitshöhe ( Fehlt FeedRate ) G90 X3.375 Y4.400 Fehlt FeedRate Eilgang F200 G01 Z-7.00 Z.Achse Einstechen kein Negativzeichen ( FeedRate Drill fehlt ) F400 unnötig G90 X3.700 Y4.175 Fräsbewegung ( Fehlt FeedRate Milling ) G90 X4.075 Y4.100 ok G00 Z4.00 ok G90 X5.650 Y4.725 Fehlt FeedRate Eilgang F200 G01 Z-7.00 Z.Achse Einstechen kein Negativzeichen ( FeedRate Drill fehlt ) ... ... Meine Fräse hat den 0-Punkt an oberen Anschlag Bewegung nach unten läuft in positive Richtung.( keine Negativkoordinaten ) G01 Z4.00 F400 Sicherheitshöche 4mm G01 Z7.00 F100 Einstechen bis 7mm mit DrillFeed ....... Fräsen G01 Z4.00 F400 Hochfahren Sicherheitshöche ....... Neuen Punkt anfahren G01 Z7.00 F100 Einstechen bis 7mm mit DrillFeed ....... Fräsen Bei Negativbewegten Z-Achse das gleiche mit - Vorzeichen bei Z Jetzt erzeugter Code F200 G01 Z--7.00 Grüße Waldemar
Waldemar P. schrieb: > G00 Z4.00 Z-Achse Sicherheitshöhe ( Fehlt FeedRate ) > G90 X3.375 Y4.400 Fehlt FeedRate Eilgang Erste Zeile: Die Feedrate wird doch bereits durch G00 (in der GRBL-Konfiguration eingestellte max-Rate) bestimmt. G00 = Eilgang = max-Rate Zweite Zeile: Auch hier fehlt der Eilgang nicht, da G00 bezw. G01 jeweils solange im Befehlssatz gültig sind bis sie geändert werden. D.h. das G00 der ersten Zeile ist auch noch in der zweiten Zeile gültig, da hier nichts anderes vereinbart wird. Siehe allgemeine G-Code Konventionen. Waldemar P. schrieb: > Meine Fräse hat den 0-Punkt an oberen Anschlag Bewegung nach unten > läuft in positive Richtung.( keine Negativkoordinaten ) Da musst Du dich schon an die Konventionen von SerialCommCNC halten (siehe auch unter Hilfe). Deiner Fräse kann es egal sein wo der Nullpunkt liegt. Die Konventionen sind: - keine Maschinen-Koordinaten, sondern ausschlieslich Welt-Koord. - der Koordinaten-Ursprung beginnt immer am gesetzten Nullpunkt (Set XYZ Zero). Der sollte sinnigerweise beim Platinen-oder Schriftzug-Fräsen auf der Oberseite des Werkstückes liegen. - vom Nullpunkt ist + immer: X nach rechts, Y nach hinten, Z nach oben - das kann man problemlos mittels $$ anschauen und mit $3=Parameter über die Eingabebox für jede Achse persistent ändern, wenn die CNC-Maschine was anderes macht. Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo Albert, M3 Spindel EIN G00 Z4.00 Z-Achse fährt über die Platine G90 X3.375 Y4.400 Fährt zur Startpunkt F200 G01 Z-7.00 Z-Achse fährt auf Endschalter Maschine geht in Störung Bei Z0.000 ist Ende Endschalter ( Homeposition ) Umgestellt auf Negative Koordinaten: M3 Spindel EIN G00 Z-4.00 Z-Achse fährt über die Platine G90 X3.375 Y4.400 Fährt zur Startpunkt F200 G01 Z--7.00 Maschine geht in Störung ( Syntaxfehler ) Waldemar
@ Waldemar Du hast SerialComCNC und die Nullpunkt-Konventionen bis jetzt noch nicht verstanden. Bitte lies Dir meinen obigen Post nochmal durch, versuche den zu verstehen, insbesondere die Achsen-Konventionen und setze das dann auf Deine CNC-Maschine um. Die Achsen sind richtig eingestellt, wenn sie sich bei Betätigung der Pfeil-Tasten in genau diese Richtung bewegen. Ebenfalls empfehle ich Dir das Studium von GRBL und die unterstützten G-Code Befehle: https://github.com/grbl/grbl/wiki Jetzt mal ganz einfach: 1. Die Endschalter sind unerheblich und müssen nicht benutzt werden. 2. Lege das Werkstück/Platine nach X und Y gerade ausgerichtet auf den Frästisch. 3. Fahre den Fräser XY auf den unteren linken Rand der Platine, die Z-Achse fährst Du runter bis das der Fräser das Werkstück/Platine berührt. 4. Betätige die Nullung (Button "Set XYZ Zero"). Ab da ist jetzt für die Z-Achse und die XY-Achsen Null. Z nach oben postiv und nach unten in das Werkstück/Platine hinein negativ. Der XY Nullpunkt sollte mit dem Nullpunkt der Zeichnung/Platinen-Layout übereinstimmen. 5. Starte das in G-Code konvertierte File mit dem "Start File" Button. Und nochmal: Das Ganze hat mit den Maschinen-Koordinaten und Nullung mittels Endschalter absolut NICHTS zu tun. Einfacher geht es doch wirklich nicht. Alles wird gut :) P.S. Im Konvertierungsfenster wird dann der Wert für die Bohrtiefe (Drill Depth) natürlich bei der Eingabe NICHT mit einem negativen Vorzeichen versehen.
:
Bearbeitet durch User
Angehängte Dateien:
-
Steuerung1.jpg
240 KB
Hallöchen, ich bin gestern zufällig über dieses Forum gestolpert. Nachdem ich dann mit den "gefühlten" 1000 Beträgen durch war, kam mir als erstes ein "Hut ab" in den Sinn. Super was Du seit September auf die Beine gestellt hast. Auch das Du "Geduld" bei der Beantwortung von Fragen aufbringst (siehe Antwort an Waldemar) hat mich bewogen mich mal mit deiner Software etwas näher zu beschäftigen. Zu mir selber: Ich bin auf dem Gebiet CNC noch blutiger Anfänger. Also gerade mal einen Schritt vom DAU entfernt. Ich weiss auch, dass ich hier noch ein massives Defizit in den Grundkenntnissen habe. Das meine Englischkenntnisse auch nicht gerade die Krönung sind, erleichtert die ganze Angelegenheit wirklich. Und manchmal scheitert die ganze Sache auch nur an "dem Brett vorm Kopp". Ich hab mir dann heute mal den Arduino geschnappt und es auch geschafft das Grbl 0.9g dort draufzubügeln. Ardunio, Schrittmotortreiber und alten Schrittmotor "wild" verkabelt (nur X-Achse). 12Volt angeschlossen, Arduino ans Laptop, Laptop hochgefahren, Programm gestartet, ComPort eingestellt, Connect geklickt, mm 10 eingetragen, Feed mit 150 eingetragen. X-Achse Pfeil nach rechts geklickt. --> Nix Fehlermeldung: error: Undefined feed rate Feed auf 50 reduziert. Neuer Versuch. --> Nix gleiche Fehlermeldung Das war das "Brett vorm Kopp". Man sollte auch auf das "Feed" klicken wenn man einen neuen Wert eingetragen hat. Ich war davon ausgegangen das nach Änderung bei Verlassen des Feldes der Wert automatisch gesetzt wird. Nach Klicken von Feed, nächster Versuch. Begeisterung: Er dreht sich. Das war der erste Schritt :-) Bis zu diesem Schritt hab ich nur eine kleine Sache, die die Funktionalität des Programms in keiner Weise einschränkt aber für mich etwas merkwürdig ist. Bei jedem Start des Programms ist als "DefaultPort" COM3 eingetragen. Wenn ich auf "Connect" klicke dann kommt das InfoFenster "Falscher Comport". Laut Gerätemanger habe ich nur den ComPort4 für den Arduino. Also wechsle ich auf den ComPort4 und klicke Connect. Es kommt das Infofenster "Der ComPort ist jetzt aktiv". Bei erneutem Start des Programms ist wieder der ComPort3 als Default eingetragen. Schön wäre es, wenn der zuletzt gewählte ComPort der Default wäre. Aber ich dann ein wenig weiter getestet. - Programm neu gestartet - ComPort4 ausgewählt - Connect geklickt. Infofenster: "Der Comport ist jetzt aktiv" Jetzt - Disconnect geklickt - ComPort3 ausgewählt - Connect geklickt. Infofenster: "Der Comport ist jetzt aktiv" Natürlich funzt der ComPort nicht. Nächster Schritt bei mir: In der nächsten Woche Material besorgen um die Schrittmotoren an die Proxon zu basteln. Fazit bisher: Ein großartiges Projekt. Ich hoffe nur, dass es für dich nicht "allzusehr ausartet" und Du trotzdem aus dem "Mini-Tool für die eigenen Bedürfnisse" weiterhin ein Tool für uns alle machst und das Projekt lange am Leben hälst.
Edgar R. schrieb: > Bei jedem Start des Programms ist als "DefaultPort" COM3 eingetragen. Beim Start erkennt SerialComCNC alle Ports die bei Windows in Benutzung sind oder waren und nicht mehr freigegeben wurden. Es ist also möglich, dass Du da z.B. als ersten Port COM3 eingetragen hast, andere haben hier jede Menge eingetragen (benutzte, unbenutzte, nicht freigegebene). Wenn Du bei mehreren Einträgen sofort wissen willst welcher der Richtige ist, einfach in der Windows Computerverwaltung/Gerätemanager unter Anschlüsse (COM & LPT) nachsehen welchen Port dein Arduino belegt. Und nur diesen Port kannst Du dann mit SerialComCNC benutzen, bei allen anderen erscheint eine Fehlermeldung.
:
Bearbeitet durch User
Angehängte Dateien:
-
Geraetemanger.png
78 KB -
ComPort3.png
110 KB
Hallo Ulrich, danke für die prompte Reaktion. Ich weiss ja, dass ich nur ComPort4 nutzen kann. Behindert ja auch nicht die Funktion. Wäre einfach nur schön wenn er sich diesen beim Beenden des Programms merken würde. Ich fand es nur merkwürdig, dass er ComPort3 einträgt, obwohl es den im Gerätemanager gar nicht gibt. (siehe Bild). Im zweiten Bild kann man sehen, dass man auch eine positive Bestätigung bei ComPort3 bekommen kann, nur funzt der natürlich nicht.
Edgar R. schrieb: > Ich fand es nur merkwürdig, dass er ComPort3 einträgt, obwohl es den im > Gerätemanager gar nicht gibt. (siehe Bild). Für Windows-Probleme ist mein Programm nicht zuständig. Sollten Ports als belegt erscheinen, aber nicht benutzt sein, einfach überschreiben und Windows Fehlermeldung ignorieren. Ansonsten mal selbst die Initiative ergreifen und Google fragen "belegte com ports freigeben", da wird einem geholfen. Edgar R. schrieb: > Im zweiten Bild kann man sehen, dass man auch eine positive Bestätigung > bei ComPort3 bekommen kann, nur funzt der natürlich nicht. Wenn man die Com-Ports mehrere Male kurz hintereinander aktiviert und deaktiviert und ändert und nicht den kompletten Prozess abwartet, mag das mal sein. Das Com-Port Thema ist hiermit für mich beendet, es wurde alles dazu gesagt.
:
Bearbeitet durch User
Hallo Albert, erstmal Danke für die Bereitstellung der Software von Dir. Ist echt ein sehr tolles Projekt was Du da in der kurzen Zeit auf die Beine gestellt hast. Habe dazu eine Frage wird es auch einen Import Konverter für .dxf geben. lg
Hallo Albert, auch von mir ein "klasse Projekt/Programm". Ich bin zwar nicht unerfahren im fräsen (seit 1 1/2 Jahren CamBam + Mach3) aber eine Frage hätte ich doch: vielleicht übersehen oder blind .... wo stellt man die Schritte/Fahrweg ein ? Gruss Harry
V. K. schrieb: > eine Frage wird es auch einen Import Konverter für .dxf geben Vorerst nicht. Crazy H. schrieb: > vielleicht übersehen oder blind > .... wo stellt man die Schritte/Fahrweg ein ? Betätige den Button $$, es werden dann im Monitor alle persistenten Einstellungen nummeriert aufgelistet. Die Schritte/mm für die X, Y und Z-Achse findest Du bei $100 bis $102. Betätigst Du den Button $, dann wird eine Liste möglicher Befehle ausgegeben. Darin findest Du die passende Syntax für die Änderung der Einstellungen: $x=value (save Grbl setting) Wenn Du also z.B. die Schritte/mm auf 800 für die X-Achse ändern willst, gibst Du unten im Eingabefeld (Abschluss mit Return-Taste) ein: $100=800 Anschliessend kannst Du ja noch mal mit $$ überprüfen ob die Änderung ordnungsgemäss übernommen wurde. Der geänderte Wert bleibt im Mikrocontroller des Arduino persistent erhalten. Für einige Einstellungen die mit $$ aufgelistet werden, empfiehlt sich zum besseren Verständnis unbedingt das Studium von "Configuring Grbl v0.9": https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Gruss Ulrich Albert
:
Bearbeitet durch User
Anbei SerialComCNC Version 0.7e Change Log V0.7e ---------------- Laser Cut für HPGL-Files (.plt) implementiert. Zum Ein/Ausschalten des Lasers wird der Ausgang für den Spindel-Motor benutzt. Die Pen Up/Down Befehle in HPGL werden bei der Konvertierung in G-Code mit "M5" bezw. "M3" also Motor Aus/An ersetzt und damit der Laser direkt (über den Laser-Treiber) angesteuert. Neue Import-Möglichkeit für G-Code direkt über das Clipboard (Windows Zwischenablage). Damit kann man z.B. bei der Filou/WinPC Version die nur das Übertragen des erzeugten G-Codes nach WinPC erlaubt, aber den G-Code nicht als File speichert, den G-Code in Filou markieren/kopieren und direkt über "File/Load Clipboard" in SerialComCNC einfügen.
:
Bearbeitet durch User
Hallo Albert, bin seit eingier Zeit dankbarer Nutzer Deines Frontends. Bin noch nicht produktiv, weil ich meine Fräse noch einfahre bzw. heftig lernen muss. @CrazyH: Bei Windows kann man im Grätemanger die Nummer der ComPorts auch verändern. Habe Com1 auf Com11 geschickt und den Arduino auf Com1. So ist der Start dann ganz einfach. Bitte bei den Schritten pro mm (Werte: $100 bis $102) immer rechnen, ob die maximale Frequenz von 30KHz nicht überschritten wird. Bin kürzlich böse reingefallen. Auch wenn man beim Fräsen selbst eine niedrige Geschwindigkeit fährt, so bewegt sich die Fräse bei Leerfahrten (Kommando G0) immer mit der maximalen Geschwindigkeit (Werte bei $110 bis $112). Diese Werte werden bei grbl auch beim Fräsen nicht überschritten (Kommando G1), selbst wenn man höhere F-Werte per Programm schickt. Beispiel: $10x: 1600 Schritte/mm $11x: 1000 mm/Minute 1600 X 1000 60 1000 = 26,66 KHz -> OK $10x: 1600 Schritte/mm $11x: 2000 mm/Minute 1600 X 2000 60 1000 = 53,33 KHz -> Problem. Der Ardunio steigt nicht nur aus sondern überschreibt auch seinen Speicher oder EEPROM. Mußte mehrfach neu flashen, bis man mich im Netz auf das richtige Pferd gehoben hatte. Und das möchte ich hiermit weiter geben.Es ist also wieder mal wahr geworden, daß die meisten Probleme zwischen dem Sessel und dem Bildschirm hocken. Es gibt aber auch Ausnahmen. Habe als "blindes Huhn" z.B. beim aktuellen grbl einen SW Fehler gefunden. Bei wiederholten exakt diagonalen x/y Fahrten wurde bei Richtungswechsel zwischendurch nicht gebremst oder beschleunigt. Das tritt im realen Leben eher selten bis gar nicht auf. Aber als "bloody redneck" macht man halt auch sowas. Nun das ist von den Profis im Netz quasi über Nacht behoben worden und fließt in den nächsten Release h ein. Die Version ist als Zwischenversion auf github zu finden. grbl_v0_9h_edge_328p_16mhz_115200_build20150205.hex Grüße Johannes
Korrektur: Bei den Formeln oben hat HTML die Schrägstriche geschluckt. Soll z.B. heißen: 1660 mal 1000 geteilt durch 60 geteilt durch 1000
...und noch eine Korrektur für dein Beispiel. Bei GRBL Version 9g muss es jeweils heissen: $100 anstatt $10 $110 anstatt $11 Ansonsten Danke für Deinen Beitrag.
:
Bearbeitet durch User
Albert M. schrieb: > ...und noch eine Korrektur für dein Beispiel. > Bei GRBL Version 9g muss es jeweils heissen: ... stimmte schon so, hatte das x bei Dir übersehen :)
Angehängte Dateien:
-
Unbenannt.JPG
26 KB
Hallo Albert, kann es sein das hier etwas nicht richtig ist habe es auf 2 Rechnern unter XP getestet. Ist mir bei 0.7d und 0.7e aufgefallen. lg fragender
fragender schrieb: > kann es sein das hier etwas nicht richtig ist Wer selbst programmiert kennt das Thema. Trotz Einstellung der Programmierumgebung auf Autoscale/Proportional ist es schwierig eine universelle Skalierung für alle möglichen Monitor-/ Grafikkarten-Einstellungen (Auflösung, DPI, Textgrösse usw) zu finden. Bei dem gezeigten Bild passt nicht nur die Textplatzierung nicht, auch die Eingabeboxen rechts oben sind ineinander gerutscht. Ich versuche das für die nächste Version zu korrigieren. Welche Grafikkarteneinstellungen benutzt Du?
:
Bearbeitet durch User
Hallo Albert! Das gehört ganz unten auf die To-Do-Liste (wenn überhaupt), aber weil Du gerade von Grafik sprichst eine Nebensächlichkeit von mir: wäre es ggf möglich, das Farbschema einstellbar zu machen? Oder aber vielleicht 2 bis 3 Schemata fertig vorzuhalten? Ich persönlich finde das schlichte durchgängige PC-grau (wie die Menüleiste) am unaufdringlichsten :-). Gruß Malte
Hallo Albert, danke für die Info von Dir, habe als Grafikeinstellung 1024x768 aber auch ein höher oder tiefer setzen ändert an der Darstellung nichts. Ab 1280x800 wird die breite allerdings auch nicht mehr verändert.Also kein Vollbild Modus mehr. Ist auf beiden Systemen das selbe Win XP Pro einmal mit ATI Grafik Karte neuste Treiber sind drauf und einmal Laptop 17 Zoll mit NVidea Grafik Karte auch neuste Treiber. Also nichts exsotisches von der Hardware her. Hatte ja auch nur Angefrag ob da was nicht i.O. ist, bei einem Rechner hätte der Fehler ja durch aus bei mir liegen können. Habe das aber auch auf einen Netbook Samsung NC30 unter Win7 heute noch mal getestet da ist der selbe Fehler bei allen Möglichen Auflösungen. Jedenfalls noch mal Danke für die schnelle Antwort von Dir. lg fragender MTA schrieb: > Das gehört ganz unten auf die To-Do-Liste (wenn überhaupt) Hallo Malte, kann deinen Kommentar ( dein Problem ) leider nicht Nachvollziehen.
Hallo, fragender schrieb: > Hallo Malte, > > kann deinen Kommentar ( dein Problem ) leider nicht Nachvollziehen. Du verstehst inhaltlich nicht was ich meine oder Du meinst es wäre für Dich nicht interessant das Farbschema ändern zu können? Ich bin nicht davon ausgegangen, dass es für jedermann von Interesse wäre, die Farbe ändern zu können, deswegen auch meine sehr defensive Anmerkung, dass es ganz unten auf die To-Do-Lister gehört. Ist's so klarer für Dich geworden?
fragender schrieb: > habe als Grafikeinstellung 1024x768 aber > auch ein höher oder tiefer setzen ändert an der Darstellung nichts. Ich habe jetzt mal die Darstellung auf 3 verschiedenen PC's (XP und Win7) mit unterschiedlichen Grafikkarten in sämtlichen Grafik- und Text-DPI-Modi getestet (Grafik 1024x768 bis zu 2048x1152). Die Darstellung ist dabei immer einwandfrei. Leider kann ich das in deinem Bild gezeigte Verhalten nicht reproduzieren, was für eine Korrektur unabdingbar wäre.
Könnte vielleicht an einer manuell geänderten Systemschriftröße liegen. Unter XP waren die Einstellungen ja noch über die Systemsteuerung zugänglich. Hat Mircosoft inzwischen ziemlich verbaut. Nur noch über "[HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics]" mfG vom ingo
Angehängte Dateien:
-
fnt.png
6,6 KB
Hallo nochmal, Albert M. schrieb: > Leider kann ich das in deinem > Bild gezeigte Verhalten nicht reproduzieren, was für eine Korrektur > unabdingbar wäre. ich habe das Problem auch nicht, aber ich glaube es liegt daran, dass der Font in dem Bild von "fragender" breiter ist. Ich habe mal einen Screenshot unter Lupe gemacht und als Bild angehängt. Oben sieht man den Text von "fragender" und darunter die Darstellung bei mir auf dem Rechner. Möglicherweise liegt es an Einstellungen zu Windows GUI (habe selber nie an den Fonts rumgedreht). Ich habe übrigens noch einen kleinen Typo gefunden. Im "Manual Process" Bereich steht unten links neben der Checkbox "Keybord" statt "Keyboard". Völlig nebensächlich :-). Gruß Malte
Ingo Wendler schrieb: > Könnte vielleicht an einer manuell geänderten Systemschriftröße liegen. Ingo war schneller :-)
Angehängte Dateien:
-
Fehler.png
67 KB
Guten Morgen, hier mal zur Ansicht auf einen Asus Mini Laptop unter Win 7 Pro in 1024x600 sieht auch etwas komisch aus oder ? Kann es mit Externen Monitor auch hoch Skalieren die Darstellung bleibt immer etwas verschoben. Gruß Ronny
Angehängte Dateien:
-
Fehler-2.png
71 KB -
Fehler-3.png
60 KB
Hallo, Fehler Bild 2 zeigt 1024x768 in Fehler Bild 3 ist die Auflösung nur 800x600 Maximiert da sieht das dann so aus z.B. Hoffe die Bilder helfen bei der Fehler suche. Gruß Ronny
Die Design-Breite/Höhe beträgt 1200x760. Damit ist die minimale Auflösung für die Darstellung vorgegeben. Das wird auch nicht geändert. Die Verwendete skalierbare Schriftart ist Arial, welche normalerweise auf allen Windows PC's verfügbar ist. Fehler die ab dieser Mindest-Auflösung in der Darstellung auftreten versuche ich zu ändern, so weit bei mir nachvollziehbar oder versuchsweise nach den von euch gezeigten Screen Shots.
:
Bearbeitet durch User
Anbei SerialComCNC Version 0.7f Change Log V0.7f ---------------- Bugs in Laser Cut für HPGL-Files (.plt) behoben. Code Zeilen-Counter in allen Ansichten zugefügt. "Please Wait ..." Info bei allen länger dauernden Import oder Konvertierungsvorgängen zugefügt. Diverse kleinere Bugs behoben. Gruß Ulrich Albert Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Noch eine Frage von einem nicht-Arduino-Benutzer: Hat so ein Arduino irgend etwas besonderes an sich, das die grbl-Software nur auf ihm lauffähig macht oder kann ich die einfach auf einem selbst gebauten Board mit passendem uC flashen und fertig ? Gruss Harry
Crazy H. schrieb: > Hat so ein Arduino > irgend etwas besonderes an sich, das die grbl-Software nur auf ihm > lauffähig macht oder kann ich die einfach auf einem selbst gebauten > Board mit passendem uC flashen Übertrage auf Deinen ATMega328 den Arduino Bootloader mittels ISP-Programmer. Um den Bootloader aufzuspielen am einfachsten die Arduino Oberfläche installieren, da Deinen Programmer einstellen und den Bootloader direkt mit ISP übertragen: http://arduino.cc/en/Main/Software Betreibe deinen ATmega mit der selben Taktfrequenz wie der Original Arduino Uno, füge einen FTDI Seriell/USB Wandler (oder ähnliche, gibt es auch als fertige Break Out Boards) hinzu. Bei der Installation der Arduino Oberfläche kannst Du auch gleich Treiber für die FTDI Seriell/USB Wandler mit installieren lassen. Beachte die Pin-Zuordnung für den Anschluss an das Stepper Driver Board: http://arduino.cc/en/Hacking/PinMapping168 und entsprechend: https://github.com/grbl/grbl/wiki/Connecting-Grbl Dann noch GRBL mit dem SerialComCNC beigefügten Flash-Tool auf deinen ATMega flashen. Hab ich was vergessen? Ach ja die Arduino-Oberfläche deinstallieren :)
:
Bearbeitet durch User
Hallo Albert, die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht einfach mit meinem Progger so flashen ? Für was brauch ich den BootLoader ? Gruss Harry
Crazy H. schrieb: > die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht > einfach mit meinem Progger so flashen ? Für was brauch ich den > BootLoader ? Sicher kannst Du das hex File direkt flashen, ob dann aber GRBL funktioniert weiss ich nicht. Habs nie probiert. Ich kann auch nicht sagen welche Funktionalität der Arduino Bootloader sonst noch hat die unabdingbar wäre oder ob der Bootloader vom Hex-File überschrieben wird. Daher meine oben beschriebene sichere Methode. Aber Versuch macht klug :) Vielleicht kann jemand mehr dazu sagen?
:
Bearbeitet durch User
Albert M. schrieb: > Crazy H. schrieb: >> die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht >> einfach mit meinem Progger so flashen ? Für was brauch ich den >> BootLoader ? > > Sicher kannst Du das hex File direkt flashen, ob dann aber GRBL > funktioniert weiss ich nicht. Habs nie probiert. Sicher kannst Du das HEX File direkt flaschen und die funktionier auch. Das weis ich. Waldemar
Danke Albert & Waldemar :o) Ich hoffe ihr könnt mir meine Frage nachsehen, aber Google spuckt bei "Arduino Uno Mega328" so viel Zeugs aus - ich blick nicht durch. R1, R2, R3, ... ????? Bahnhof ? Einfache Frage: Mega328P ? 16 MHz ? Pinbelegung hab ich ja :o) Ich hab mir TB6600-Enstufen bestellt und möchte 4 von denen auf eine Platte schrauben und eine Platine layouten, die so lang/groß ist, daß die Anschlüsse der Controller-Platine direkt deckungsgleich mit den Endstufenanschlüssen sind. D.h. die Platine soll (mehr-oder-weniger) kurze Anschlussdrähte haben, an die ich direkt die Steckkontakte der Endstufe schrauben kann. Sowas: http://www.ebay.de/311106192368
Harry schrieb: > Einfache Frage: Mega328P ? 16 MHz ? Ja Harry schrieb: > TB6600-Enstufen bestellt und möchte 4 von denen GRBL unterstützt aber nur 3 Achsen (XYZ) keine 4
:
Bearbeitet durch User
Albert M. schrieb: > Harry schrieb: >> TB6600-Enstufen bestellt und möchte 4 von denen > > GRBL unterstützt aber nur 3 Achsen (XYZ) keine 4 Ich hab in der X-Achse 2 Motoren. Die schalte ich dann parallel .... die Endstufeneingänge natürlich ;o)
Harry schrieb: > Ich hab in der X-Achse 2 Motoren. Die schalte ich dann parallel .... die > Endstufeneingänge natürlich ;o) Ich glaube nicht, dass das eine gute Idee ist. Angefangen bei eventuell verschiedenen Steigungsfehlern der beiden Anstriebswellen usw. Du musst aber selber wissen was Du da machst. Trotzdem würde ich mich an Deiner Stelle diesbezüglich noch mal in den entsprechenden CNC Foren schlau machen.
Hallo Albert, da mach ich mir keine Gedanken. Das läuft so ja seit ca. 1 1/2 Jahren unter Mach3. Gruss Harry
Crazy H. schrieb: > Hallo Albert, > > die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht > einfach mit meinem Progger so flashen ? Für was brauch ich den > BootLoader ? > > Gruss > Harry Der Bootloader ist nur ein Bootloader, die Firmware braucht den nicht.
Angehängte Dateien:
-
Screenshot__2_.png
110 KB
INKSCAPE erzeugte plt. oder hpgl. Datei -> SerialComCNC -> HPGL Converter= (FEHLERMELDUNG)" ist kein Gleitkommawert. Was mache ich hier falsch? Gruß Yetim
Ali Yetim schrieb: > Was mache ich hier falsch? Falsch: PU4583 7338 Richtig: PU PA4583,7338 das lässt sich doch bestimmt in der Konfiguration von INKSCAPE so einstellen? Falls nicht kann ich Dir da auch nicht weiter helfen. Jeder Grafik/Draw Programm Hersteller kocht sein eigenes Formate-Süppchen und ich habe wenig Motivation hier 20 verschiedene HPGL Formate zu unterstützen. Im Web findet man so einige Format-Konverter, vielleicht die mal auf Brauchbarkeit prüfen. SerialComCNC unterstützt folgende HPGL Befehle Befehle: PU, PD, PA, PR. Alle sonstige Befehle werden ignoriert. PU = Pen Up PD = Pen Down PA = Koordinaten absolut PR = Koordinaten relativ Format (wobei x und y ganzzahlig sind): PU PAx,y PD PRx,y
:
Bearbeitet durch User
Hallo Leute, bitte seid vorsichtig mit chinesischen Treiberstufen. Nachdem ich selber mal auf die Nase gefallen bin, habe ich so ziemlich alles gescannt (Waren und Foren), was aus diesem Kontinent so im lower end bereich kommt. Habe keine einzigen Schaltung gefunden, die der Spezifikation entspricht. Da wird abgekupfert was das Zeug hält und wenn einer mal gute Erfahrung hatte, muss das nicht heißen, daß ein Teil das genau so aussieht und beschriftet ist auch wirklich funktioniert. Wenn die Dinger nur mit 30% ihrer Leistung laufen ist das noch ein Gut-Fall. Als ich dann selber Hand angelegen Wollte, habe ich diese Quelle gefunden. http://users.skynet.be/ldt/CNC%20electronics/THB6064AH.html Die Schaltung und das Layout der LP stimmt und der Aufbau war super gut. Löten, Einschalten, Funktion... (NEIN, habe keine Anteile an Lucas' Firma...) Insgesamt habe ich also 2 mal so ziemlich das Gleiche bezahlt - einmal China (Lehrgeld)und einmal Belgien (Funktion). Noch ein Tipp. Viele PC Firmen leeren momentan ihre Lager an alten CPU Kühlkörpern mit Lüfter (eBay). Habe 3 Stück für 12 Euronen bekommen und halte somit die Treiberstufen auf Raumtemperatur - selbst unter Vollast. Hier soll es ja eigentlich um Alberts super Programm gehen - aber habe mich getaut diese Tipps hier zuschreiben, damit Enttäuschung bei Einigen von Euch vermieden wird. Grüße Johannes
Hallo Johannes, > bitte seid vorsichtig mit chinesischen Treiberstufen. Nachdem ich selber > mal auf die Nase gefallen bin, habe ich so ziemlich alles gescannt > (Waren und Foren), was aus diesem Kontinent so im lower end bereich > kommt. Habe keine einzigen Schaltung gefunden, die der Spezifikation > entspricht. Ich hätte nichts dagegen, wenn du recht hättest. Immerhin setzen die Chinesen seit Jahren den europäischen Markt unter Druck. Es gibt aber durchaus brauchbare China-Endstufen, sonst wären die Chinesen nicht so lange so erfolgreich. Bei den 3-/4-Achsboards mit Toshiba-ICs für Hobby CNC-Maschinen mag das Qualitätsniveau allerdings deutlich schlechter sein als bei den industrietauglichen Endstufen. Bei den Hobbyisten ist allerdings auch der Hang am größten, so billig wie möglich einzukaufen, koste es was es wolle. ;) Im übrigen hat das hier mit dem eigentlichen Thema nichts zu tun, so dass sich der Verdacht aufdrängt, dass du hier doch nur Schleichwerbung machen willst. Mit freundlichen Grüßen Thorsten Ostermann
@Thorsten, sicher hast Du Recht das es damit nichts zu tun hat. Aber den Hinweis auf den THB6064 finde ich trotzdem in Ordnung. Der ist deutlich leistungsfähiger als die Vorgänger z.B. TB6560. Leider ist der THB immer noch nicht überall zu bekommen. Wir haben den selber aus China holen müssen. Gerade das langsame Timing des TB ist immer wieder ein Grund für scheinbar unerklärliche Probleme mit Mach3.
Hallo Ich benutze SerialComCNC schon seit längerer Zeit. Seit kurzem habe ich eine USB Webcam an meine CNC angebaut. Mein Problem ist, dass das Programm nach ca. einer Minute zu hängen anfängt nachdem man auf Video schaltet. Man muss SerialComCNC neu starten, damit es wieder weiter läuft. Ich habe sicherlich nicht den schnellsten PC angeschlossen, aber ich glaube nicht, dass es daran liegt, da die RAM und CPU Auslastung nicht sehr hoch ist.
Gabriel M. schrieb: > ich eine USB Webcam an meine CNC angebaut. Mein Problem ist, dass > das Programm nach ca. einer Minute zu hängen anfängt nachdem man auf > Video schaltet. Man muss SerialComCNC neu starten, damit es wieder > weiter läuft. Ich habe sicherlich nicht den schnellsten PC Das ist nichts was ich in SerialComCNC ändern könnte. Das Problem liegt entweder an den Treibern Deiner WebCam oder an einem zu langsamen PC. Bei meinem Intel i7 860 PC mit Logitech WebCam gibt diesbezüglich keinerlei Probleme.
Angehängte Dateien:
-
SerialComCNC_v0.8.jpg
300 KB
Anbei SerialComCNC Version 0.8 Change Log V0.8 --------------- Werkzeuglängen-Sensor / Probe Unterstützung zugefügt. Anschluss des Sensors/Probe siehe hier: https://github.com/grbl/grbl/wiki/Connecting-Grbl Den Werkzeuglängen-Sensor zuerst unter Settings/Probe einmalig einrichten. Dabei wird der Sensor auf der Oberfläches eines Werkstücks platziert. Die Kontakthöhe des Sensors wird beim Beendes des Programms gespeichert und steht beim nächsten Aufruf wieder zur Verfügung. Nach der Einrichtung wird nach einem Werkzeugwechsel mittels Button P das Probing durchgeführt und anschliessend mit Button UP (Use Probe) die Z-Achse automatisch genau bis auf den Werkzeug-Nullpunkt heruntergefahren. Der Vorschub/Feed der Z-Achse während des Probing ist in 3 Stufen von 2 bis 10 mm/min einstellbar. Das Probing funktioniert zuerst mal nur so wie hier beschrieben, also halb-manuell. Der korrekte Ablauf innerhalb eines laufenden G-Code Programms wurde noch nicht implementiert/überprüft. Als Werkzeuglängen-Sensor wurde zum Test der hier benutzt: http://www.ebay.de/itm/Werkzeuglangenmesser-Werkzeuglangensensor-Werkzeugtaster-CNC-Frase-/321380535406?pt=Industriemaschinen&hash=item4ad3c5cc6e Gruss Ulrich Albert Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
DANKE für dieses Programm und die ständigen sehr nützlichen Erweiterungen. Ich zähle es zu dem besten Frontend für Grbl.
Albert M. schrieb: > Gabriel M. schrieb: >> ich eine USB Webcam an meine CNC angebaut. Mein Problem ist, dass >> das Programm nach ca. einer Minute zu hängen anfängt nachdem man auf >> Video schaltet. Man muss SerialComCNC neu starten, damit es wieder >> weiter läuft. Ich habe sicherlich nicht den schnellsten PC > > Das ist nichts was ich in SerialComCNC ändern könnte. Das Problem liegt > entweder an den Treibern Deiner WebCam oder an einem zu langsamen PC. > Bei meinem Intel i7 860 PC mit Logitech WebCam gibt diesbezüglich > keinerlei Probleme. Danke das mit dem updaten werde ich probieren, ansonsten muss wohl ein neuerer pc her...
Angehängte Dateien:
Hier die Vorschau auf die nächste Version 8a. Neu: Makros Es können 4 verschiedene Makros mit beliebigem G-Code definiert, editiert, gespeichert und über den neuen Button M aufgerufen werden. Gruss Ulrich Albert
:
Bearbeitet durch User
Das wird die Software des Jahres 2015 wenn du so weitermachst. Danke für deine unermüdlichen und sehr praktischen Verbesserungen . Weiter so.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_v0.8a.jpg
300 KB
Anbei SerialComCNC Version 0.8a
Change Log V0.8a
----------------
Makros implementiert.
Unter Settings/Macros können bis zu 4 Makros mit G-Code definiert
werden.
Format: 1. Zeile = Kommentar/Info, wird nicht ausgewertert
weitere Zeilen = G-Code
Leerzeilen sind nicht erlaubt
Befehle für Tool Change (Txx) werden ignoriert
Die Makros werden über den Button M im Manual Process ausgewählt
und mit dem 'Run Macro' Button gestartet.
Gruss Ulrich Albert
Homepage:
http://www.serialcominstruments.com/
:
Bearbeitet durch User
Ich kann mich nur hardyf anschliessen. Einfach super, danke! Meine Tests laufen mit einer 3D-dxf super. Mit der Erstellung eines Codes für die Platienenbohrung habe ich allerdings Probleme. Ich arbeite mit Eagle 7.2. Die Bohrdaten stelle ich mit Cam-job und dem Excellon-Treiber her. Da fehlen mMn die z-Werte, oder seh ich da was falsch? Das ist für mich völliges Neuland, bisher habe ich händisch gebohrt. Kann mir jemand Schritt für Schritt erklären, wie ich den Code für die Steuerung erstellen kann? Gruss Wilfried
poste mal ne Bohrdatei, am besten als .zip vlG Charly
Wilfried Richter schrieb: > Die Bohrdaten stelle ich mit Cam-job und dem > Excellon-Treiber her. > Da fehlen mMn die z-Werte, oder seh ich da was falsch? Lässt sich doch alles im Excellon Drill Data Converter Fenster einstellen: z-Werte = Drill Depth Sicherheitshöhe = Secure Height Vorschub = Milling Feed
Hallo, das war ja prompt. Herzlichen Dank für eure Hilfe ! Mit dem Excellon Drill Data Converter wusste ich nichts anzufangen. Ich hab' ihn aber gefunden, sogar ohne Google. Hat ja prima funktioniert. Nochmals danke. Gruss Wilfried
Hallo Albert, vielen Dank für dein tolles Tool, nur leider läuft es bei mir nicht zufriedenstellend. Problem: GRBL-Startup Meldung kommt nach Verbindung mit Controller (in schwarz). Manuelle Steuerung (Verfahren) funktioniert (gesendete Befehle in grün, aber kein schwarzes 'ok' als Antwort) aber keine Abfragen ($, $$) und kein 'Job'. Bei einer Jobausführung wird immer die erste Zeile auf Senden 'ok' gesetzt, danach passiert nichts mehr - vermutlich weil Endlos auf eine GRBL-Antwort gewartet wird. Meine Hardware: Win7 HomePremium 64Bit. Ich habe dieses Problem mit einem Uno R3 Clone sowie zwei Adruino Nano Clones (mehr habe ich nicht zum probieren). Alle Boards verwenden einen CH340 seriell USB Converter. Bisherige Lösungsversuche: Programiert wurde mit der Arduino IDE (der XLoader funktioniert bei den Nanos nicht - beim Uno Clone schon). Verbinung mit der Adruino-IDE COM-Verbindung sowie mit HTerm funktioniert (z.B. Abfrage $). Neuinstallation des CH340 Treiber (von anderer Quelle runtergeladen): gleiche Treiberversion, gleiches Verhalten. Auch das runtersetzen der Übertragungsrate (und neu Compilierung inder Adruino-IDE) auf 19200 brachte keine Besserung - es werden Befehle angenommen aber keine Bestätigung im SerialComCNC angezeigt. Ich vermute dass dein SerialComCNC etwas 'zickig' beim Empfangen ist? Oder das 7Hz Pollen den Empfang vom CH340 beeinträchtigt? Was kann ich noch versuchen um meine Boards mit SerialComCNC zum Laufen zu bekommen? Gruß Sven
Nachtrag: ich habe auch einen anderen USB-Port versucht - dort wurde der gleiche Treiber über den Windowsdienst installiert - mit gleichem Ergebnis...
Sven schrieb: > Auch das runtersetzen der Übertragungsrate (und neu Compilierung inder > Adruino-IDE) auf 19200 brachte keine Besserung GRBL 0.9 benötigt zwingend 115200 baud. Ich weiss auch nicht was Du da "neu kompilierst"? Es muss nichts kompiliert werden. Es muss nur das beigefügte Hex-File auf den Arduino geflasht werden. Sven schrieb: > Win7 HomePremium 64Bit. Ich habe dieses Problem mit einem Uno R3 Clone > sowie zwei Adruino Nano Clones (mehr habe ich nicht zum probieren). Alle > Boards verwenden einen CH340 seriell USB Converter. Ich habe hier nur Boards mit FTDI USB/Seriell Converter und Windows 7 Pro 32bit. Vielleicht zicken Deine Treiber bei Win 64bit. Da Du bisher der Einzige bist, der sich mit diesem Problem meldet, vermute ich den Fehler zuerst mal eher auf Deiner Seite. Sven schrieb: > Was kann ich noch versuchen um meine Boards mit SerialComCNC zum Laufen > zu bekommen? Versuche mal Deinen Arduino mit geflashtem GRBL nur mit einem Terminal-Programm zu betreiben, indem Du entsprechende G-Codes schickst. Z.B. G-Code für eine lange Line mit langsamen Vorschub und dann mehrmals pro Sekunde "?" schicken, um zu testen ob der Arduino die aktuellen Positionen zurück sendet.
:
Bearbeitet durch User
Hallo Albert, >Ich weiss auch nicht was Du da "neu kompilierst"? Ich habe mir die GRBL Dateien runtergeladen, die config.h angepasst (#define BAUD_RATE 19200) und mit der Arduino IDE neu compiliert und hochgeladen. In deinem SerialComCNC habe ich die Baudrate entsprechend angepasst und konnte mein Board steuern - mit unverändertem Verhalten, dass keine Antwort vom GRBL im SerialComCNC angezeigt wird. >Versuche mal Deinen Arduino mit geflashtem GRBL nur mit einem >Terminal-Programm zu betreiben, indem Du entsprechende G-Codes schickst. >Z.B. G-Code für eine lange Line mit langsamen Vorschub und dann mehrmals >pro Sekunde "?" schicken, um zu testen ob der Arduino die aktuellen >Positionen zurück sendet. Das habe ich gerade erfolgreich mit HTerm ausgeführt: ich bekomme mit jeder Abfrage eine "<run..." String und zum Schluß "<Idle..." zurück. Also GRBL scheint fehlerfrei zu laufen... Gruß Sven
Moin, es scheint wohl an meinem Notebook zu liegen: An einem anderen PC (Win7 Enterprise 32Bit) wurde der geleiche Treiber automatisch installiert und mein Nano antwortet hier auf gesendete Befehle im SerialComCNC - also wird die Jobausführung vermutlich auch funktionieren. Was ist an meinem Notebook falsch, dass es dort nicht läuft? Wegen der 64Bit Version? Sehr merkwürdig. Gruß Sven
Hallo zusammen, ich hatte ein ähnliches Problem. Mit der Arduino-Software 1.5.7 funktionierte der automatisch installierte USB-Treiber nicht. Daraufhin habe ich den Treiber aus der Version 1.5.2 installiert und damit gings. Gruss Wilfried
Angehängte Dateien:
-
Buffer.png
160 KB
Ich habe nun Stunden damit verbracht das Problem zu lösen... Jetzt funktioniert es gerade und ich hoffe es lag an der Einstellung des Empfangbuffers (siehe Bild). Auch wenn es nicht in deinem Sinne ist den original GRBL-Code zu ändern, möchte ich hier ein 'GRBL-Hack' teilen, mit welchem ein RC-Servo über den Spindle-PWM Ausgang gesteuert werden kann (Pen Up/Down oder Ansteuerung eines RC-Fahrtreglers zur Steuerung der Motordrehzahl) - für Arduino Uno und Nano. Anpassung der Spindelsteuerung in (vermutlich) C:\Program Files (x86)\Arduino\libraries\GRBL\spindle_control.c - einfach ersetzen. Achtung in config.h muss #define VARIABLE_SPINDLE eingefügt werden (Zeile 157 in der aktuellen v0.9 Version) Änderung der PWM-Frequenz auf 61Hz (Teiler = 1024), damit Ladewerte für Servo-short = 15 (1ms), Servo-long = 32 (2ms). Über die Spindelgeschwindigkeit kann der Servoweg eingestellt werden. Richtungsumkehr des Servos per #define möglich (in spindle_control.c) Um die Dauer des Stift Anhebens / Absenkens zu berücksichtigen wäre es klasse wenn Du bei der Konvertierung von HPGL, im SerialComCNC, die Angabe von Pausenzeiten vor/nach M03/M05 abfragen könntest. Beim CNC-USB (www.planet-cnc.com) werden diese Delays über das Einfügen von z.B. G04 P2.0 (2ms Pause) nach den Befehlen M03 und M05 realisiert. Gruß Sven
Hallo Albert, leider war das Funktionieren gestern nur ein einmaliger Glücksfall. Ich habe mir nun den 'Serial Port Monitor' von Eltima installiert und interpretiere die Ergebnisse so, dass SerialComCNC den Empfangsstatus einfach nicht mehr abfragt nach dem Senden der ersten paar '?'. Anbei die Dumpfiles im HTML-Format vom HTerm (senden '?' alle 150ms) und vom SerialComCNC. HTerm_dump.html: bei Eintrag #597 kommt die GRBL-Statusmeldung und das Senden von '?' beginnt. Nach jedem '?' wird der Empfangsbuffer abgefragt (IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK)). SerialCom_CNC_dump.html: bei Eintrag #115 kommt die GRBL-Statusmeldung und das Senden von '?' beginnt. Einmalig wird der Empfangbuffer ausgelesen, danach (Eintrag #130) nicht mehr... Hängt sich da die Empfangroutine auf? Sehr mysteriös... Gruß Sven
Hallo zusammen, Ich bräuchte auch dringend mal unterstützung mit der Firmware und Software für meine CNC Fräsmaschine mit Mega2560 und Ramps 1.4 Die Maschine (XYZ) ist fertig und läuft mit der 3D Druckersoftware auch Problemlos wenn ich Sie über Pronterface bediene. Nur ist Pronterface ja zum 3D Drucken und nicht zum Fräsen. Auch mit der Einrichtung der Arduino Druckersoftware Marlin bin ich bis jetzt gut klar gekommen. Nun möchte ich die Maschine jedoch nicht als Drucker betreiben und kenne mich absolut nicht aus mit der Firmware für das Mega im Bereich CNC Fräsen und noch weniger mit der Software dazu. Ich habe verschiedene Versionen von Grbl to Arduino geladen und auf das Board gespielt. Der GRBL Controller konnte sich auch mit dem Arduino verbinden, aber das war´s dann auch schon. Die hier angebotenen Versionen habe ich auch getestet...kommt leider immer Serial Port Error wenn ich mich mit Serial Com CNC verbinden möchte. Die Firmware habe ich mit dem hier angebotenen Xloader aufgespielt.(grbl_v0_9g_edge_328p_16mhz_115200_build20140813) Hat jemand eine Fräsmaschine mit einem Mega2540 und Ramps1.4 am laufen? Ich wäre Soooo Dankbar wenn mir jemand helfen könnte. Hänge da schon seit Tagen fest. LG, Frank
Hallo Frank, die angebotenen Hex-Files sind vermutlich für Uno und Nano (beide mit ATMEGA328P) compiliert. Du müsstest dir die Arduino IDE installieren, die aktuellen GRBL files ins entsprechende Verzeichniss kopieren. Dann in config.h deinen Mega2540 angeben, dieser scheint in der cpu_map.h aufgeführt zu sein. Also einfach in der config.h die Zeile (bei mir 46) #define CPU_MAP_ATMEGA328P_TRADITIONAL // Arduino Uno CPU gegen #define CPU_MAP_ATMEGA2560 // (Arduino Mega 2560) Working austauschen. Wg.der Verbindungprobleme solltest Du nach der richtigen Übertragungsrate gucken, default sind jetzt (version 0.9) 115200 (config.h Zeile 42 #define BAUD_RATE 115200). Viel Erfolg Sven
Thx, Sven Hallo @all... Kurz zum aktuellen Stand. Ich habe die Firmware Version GRBL_RAMPS1_4 noch einmal auf mein Board geladen. Keine Ahnung warum, aber ich bekomme nun eine Verbindung zu meiner Maschine. Was ich mir noch nicht erklären kann ist warum ich den Y Motor steckplatz mit Z tauschen musste. Die Achsen kann ich nun mit "Grbl Controller" und "SerialComCNC" fahren. Die Schritte pro mm habe ich auch anpassen können. Nun hänge ich aber an der Feinabstimmung da ich mich mit diesen Programmen nicht auskenne. Keine meiner Endschalter werden erkannt...ich Nutze auf dem mega2560 (Ramps1.4) die gleichen Steckplätze wie beim 3D Printer. Inzwischen habe ich mitbekommen das ich Sie ev in andere Ports aufstecken muss.Konnte ich noch nicht testen, aber woher soll die Fräse wissen in welche Richtung Sie die anfahren soll? Also beim 3D Drucker hatte ich die Möglichkeit einzustellen ob ich Soft oder Hardware endschalter habe. (ich habe nur einen Schließer an jeder achse zum Referieren.) Auch konnte ich einstellen in welche Richtung die Maschine zum referieren fahren muss. Hier mal meine Config.h die ich zum Druck benutze. fndef CONFIGURATION_H #define CONFIGURATION_H // This configuration file contains the basic settings. // Advanced settings can be found in Configuration_adv.h // BASIC SETTINGS: select your board type, temperature sensor type, axis scaling, and endstop configuration //====================================================================== ===== //============================= DELTA Printer =============================== //====================================================================== ===== // For a Delta printer replace the configuration files with the files in the // example_configurations/delta directory. // //====================================================================== ===== //============================= SCARA Printer =============================== //====================================================================== ===== // For a Delta printer replace the configuration files with the files in the // example_configurations/SCARA directory. // // User-specified version info of this build to display in [Pronterface, etc] terminal window during // startup. Implementation of an idea by Prof Braino to inform user that any changes made to this // build by the user have been successfully uploaded into firmware. #define STRING_VERSION_CONFIG_H _DATE_ " " _TIME_ // build date and time #define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes. // SERIAL_PORT selects which serial port should be used for communication with the host. // This allows the connection of wireless adapters (for instance) to non-default port pins. // Serial port 0 is still used by the Arduino bootloader regardless of this setting. #define SERIAL_PORT 0 // This determines the communication speed of the printer // This determines the communication speed of the printer #define BAUDRATE 115200 // This enables the serial port associated to the Bluetooth interface //#define BTENABLED // Enable BT interface on AT90USB devices //// The following define selects which electronics board you have. Please choose the one that matches your setup // 10 = Gen7 custom (Alfons3 Version) "https://github.com/Alfons3/Generation_7_Electronics"; // 11 = Gen7 v1.1, v1.2 = 11 // 12 = Gen7 v1.3 // 13 = Gen7 v1.4 // 2 = Cheaptronic v1.0 // 20 = Sethi 3D_1 // 3 = MEGA/RAMPS up to 1.2 = 3 // 33 = RAMPS 1.3 / 1.4 (Power outputs: Extruder, Fan, Bed) // 34 = RAMPS 1.3 / 1.4 (Power outputs: Extruder0, Extruder1, Bed) // 35 = RAMPS 1.3 / 1.4 (Power outputs: Extruder, Fan, Fan) // 4 = Duemilanove w/ ATMega328P pin assignment // 5 = Gen6 // 51 = Gen6 deluxe // 6 = Sanguinololu < 1.2 // 62 = Sanguinololu 1.2 and above // 63 = Melzi // 64 = STB V1.1 // 65 = Azteeg X1 // 66 = Melzi with ATmega1284 (MaKr3d version) // 67 = Azteeg X3 // 68 = Azteeg X3 Pro // 7 = Ultimaker // 71 = Ultimaker (Older electronics. Pre 1.5.4. This is rare) // 72 = Ultimainboard 2.x (Uses TEMP_SENSOR 20) // 77 = 3Drag Controller // 8 = Teensylu // 80 = Rumba // 81 = Printrboard (AT90USB1286) // 82 = Brainwave (AT90USB646) // 83 = SAV Mk-I (AT90USB1286) // 84 = Teensy++2.0 (AT90USB1286) // CLI compile: DEFINES=AT90USBxx_TEENSYPP_ASSIGNMENTS HARDWARE_MOTHERBOARD=84 make // 9 = Gen3+ // 70 = Megatronics // 701= Megatronics v2.0 // 702= Minitronics v1.0 // 90 = Alpha OMCA board // 91 = Final OMCA board // 301= Rambo // 21 = Elefu Ra Board (v3) // 88 = 5DPrint D8 Driver Board // 999 = Leapfrog #ifndef MOTHERBOARD #define MOTHERBOARD 33 #endif // Define this to set a custom name for your generic Mendel, // #define CUSTOM_MENDEL_NAME "This Mendel" // Define this to set a unique identifier for this printer, (Used by some programs to differentiate between machines) // You can use an online service to generate a random UUID. (eg [www.uuidgenerator.net]) // #define MACHINE_UUID "00000000-0000-0000-0000-000000000000" // This defines the number of extruders #define EXTRUDERS 1 //// The following define selects which power supply you have. Please choose the one that matches your setup // 1 = ATX // 2 = X-Box 360 203Watts (the blue wire connected to PS_ON and the red wire to VCC) #define POWER_SUPPLY 1 // Define this to have the electronics keep the power supply off on startup. If you don't know what this is leave it. // #define PS_DEFAULT_OFF //====================================================================== ===== //=============================Thermal Settings ============================ //====================================================================== ===== // //--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table // //// Temperature sensor settings: // -2 is thermocouple with MAX6675 (only for sensor 0) // -1 is thermocouple with AD595 // 0 is not used // 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup) // 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup) // 3 is Mendel-parts thermistor (4.7k pullup) // 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !! // 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup) // 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup) // 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup) // 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup) // 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) // 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup) // 10 is 100k RS thermistor 198-961 (4.7k pullup) // 11 is 100k beta 3950 1% thermistor (4.7k pullup) // 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed) // 20 is the PT100 circuit found in the Ultimainboard V2.x // 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950 // // 1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k // (but gives greater accuracy and more stable PID) // 51 is 100k thermistor - EPCOS (1k pullup) // 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup) // 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup) // // 1047 is Pt1000 with 4k7 pullup // 1010 is Pt1000 with 1k pullup (non standard) // 147 is Pt100 with 4k7 pullup // 110 is Pt100 with 1k pullup (non standard) #define TEMP_SENSOR_0 1 #define TEMP_SENSOR_1 0 #define TEMP_SENSOR_2 0 #define TEMP_SENSOR_BED 0 // This makes temp sensor 1 a redundant sensor for sensor 0. If the temperatures difference between these sensors is to high the print will be aborted. //#define TEMP_SENSOR_1_AS_REDUNDANT #define MAX_REDUNDANT_TEMP_SENSOR_DIFF 10 // Actual temperature must be close to target for this long before M109 returns success #define TEMP_RESIDENCY_TIME 10 // (seconds) #define TEMP_HYSTERESIS 3 // (degC) range of +/- temperatures considered "close" to the target one #define TEMP_WINDOW 1 // (degC) Window around target to start the residency timer x degC early. // The minimal temperature defines the temperature below which the heater will not be enabled It is used // to check that the wiring to the thermistor is not broken. // Otherwise this would lead to the heater being powered on all the time. #define HEATER_0_MINTEMP 5 #define HEATER_1_MINTEMP 5 #define HEATER_2_MINTEMP 5 #define BED_MINTEMP 5 // When temperature exceeds max temp, your heater will be switched off. // This feature exists to protect your hotend from overheating accidentally, but NOT from thermistor short/failure! // You should use MINTEMP for thermistor short/failure protection. #define HEATER_0_MAXTEMP 260 #define HEATER_1_MAXTEMP 260 #define HEATER_2_MAXTEMP 260 #define BED_MAXTEMP 150 // If your bed has low resistance e.g. .6 ohm and throws the fuse you can duty cycle it to reduce the // average current. The value should be an integer and the heat bed will be turned on for 1 interval of // HEATER_BED_DUTY_CYCLE_DIVIDER intervals. //#define HEATER_BED_DUTY_CYCLE_DIVIDER 4 // If you want the M105 heater power reported in watts, define the BED_WATTS, and (shared for all extruders) EXTRUDER_WATTS //#define EXTRUDER_WATTS (12.0*12.0/6.7) // P=I^2/R //#define BED_WATTS (12.0*12.0/1.1) // P=I^2/R // PID settings: // Comment the following line to disable PID and enable bang-bang. #define PIDTEMP #define BANG_MAX 355 // limits current to nozzle while in bang-bang mode; 255=full current #define PID_MAX 355 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current #ifdef PIDTEMP //#define PID_DEBUG // Sends debug data to the serial port. //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX #define PID_FUNCTIONAL_RANGE 10 // If the temperature difference between the target temperature and the actual temperature // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max. #define PID_INTEGRAL_DRIVE_MAX 355 //limit for the integral term #define K1 0.95 //smoothing factor within the PID #define PID_dT ((OVERSAMPLENR * 8.0)/(F_CPU / 64.0 / 256.0)) //sampling period of the temperature routine // If you are using a pre-configured hotend then you can use one of the value sets by uncommenting it // Ultimaker #define DEFAULT_Kp 22.2 #define DEFAULT_Ki 1.08 #define DEFAULT_Kd 114 // MakerGear // #define DEFAULT_Kp 7.0 // #define DEFAULT_Ki 0.1 // #define DEFAULT_Kd 12 // Mendel Parts V9 on 12V // #define DEFAULT_Kp 63.0 // #define DEFAULT_Ki 2.25 // #define DEFAULT_Kd 440 #endif // PIDTEMP // Bed Temperature Control // Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis // // Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder. // If your PID_dT above is the default, and correct for your hardware/configuration, that means 7.689Hz, // which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating. // This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater. // If your configuration is significantly different than this and you don't understand the issues involved, you probably // shouldn't use bed PID until someone else verifies your hardware works. // If this is enabled, find your own PID constants below. //#define PIDTEMPBED // //#define BED_LIMIT_SWITCHING // This sets the max power delivered to the bed, and replaces the HEATER_BED_DUTY_CYCLE_DIVIDER option. // all forms of bed control obey this (PID, bang-bang, bang-bang with hysteresis) // setting this to anything other than 255 enables a form of PWM to the bed just like HEATER_BED_DUTY_CYCLE_DIVIDER did, // so you shouldn't use it unless you are OK with PWM on your bed. (see the comment on enabling PIDTEMPBED) #define MAX_BED_POWER 255 // limits duty cycle to bed; 255=full current #ifdef PIDTEMPBED //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from FOPDT model - kp=.39 Tp=405 Tdead=66, Tc set to 79.2, aggressive factor of .15 (vs .1, 1, 10) #define DEFAULT_bedKp 10.00 #define DEFAULT_bedKi .023 #define DEFAULT_bedKd 305.4 //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from pidautotune // #define DEFAULT_bedKp 97.1 // #define DEFAULT_bedKi 1.41 // #define DEFAULT_bedKd 1675.16 // FIND YOUR OWN: "M303 E-1 C8 S90" to run autotune on the bed at 90 degreesC for 8 cycles. #endif // PIDTEMPBED //this prevents dangerous Extruder moves, i.e. if the temperature is under the limit //can be software-disabled for whatever purposes by #define PREVENT_DANGEROUS_EXTRUDE //if PREVENT_DANGEROUS_EXTRUDE is on, you can still disable (uncomment) very long bits of extrusion separately. #define PREVENT_LENGTHY_EXTRUDE #define EXTRUDE_MINTEMP 170 #define EXTRUDE_MAXLENGTH (X_MAX_LENGTH+Y_MAX_LENGTH) //prevent extrusion of very large distances. /*================== Thermal Runaway Protection ============================== This is a feature to protect your printer from burn up in flames if it has a thermistor coming off place (this happened to a friend of mine recently and motivated me writing this feature). The issue: If a thermistor come off, it will read a lower temperature than actual. The system will turn the heater on forever, burning up the filament and anything else around. After the temperature reaches the target for the first time, this feature will start measuring for how long the current temperature stays below the target minus _HYSTERESIS (set_temperature - THERMAL_RUNAWAY_PROTECTION_HYSTERESIS). If it stays longer than _PERIOD, it means the thermistor temperature cannot catch up with the target, so something may be wrong. Then, to be on the safe side, the system will he halt. Bear in mind the count down will just start AFTER the first time the thermistor temperature is over the target, so you will have no problem if your extruder heater takes 2 minutes to hit the target on heating. */ // If you want to enable this feature for all your extruder heaters, // uncomment the 2 defines below: // Parameters for all extruder heaters //#define THERMAL_RUNAWAY_PROTECTION_PERIOD 40 //in seconds //#define THERMAL_RUNAWAY_PROTECTION_HYSTERESIS 4 // in degree Celsius // If you want to enable this feature for your bed heater, // uncomment the 2 defines below: // Parameters for the bed heater //#define THERMAL_RUNAWAY_PROTECTION_BED_PERIOD 20 //in seconds //#define THERMAL_RUNAWAY_PROTECTION_BED_HYSTERESIS 2 // in degree Celsius //====================================================================== ===== //====================================================================== ===== //=============================Mechanical Settings=========================== //====================================================================== ===== // Uncomment the following line to enable CoreXY kinematics // #define COREXY // coarse Endstop Settings #define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors #ifndef ENDSTOPPULLUPS // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined // #define ENDSTOPPULLUP_XMAX // #define ENDSTOPPULLUP_YMAX // #define ENDSTOPPULLUP_ZMAX // #define ENDSTOPPULLUP_XMIN // #define ENDSTOPPULLUP_YMIN // #define ENDSTOPPULLUP_ZMIN #endif #ifdef ENDSTOPPULLUPS #define ENDSTOPPULLUP_XMAX #define ENDSTOPPULLUP_YMAX #define ENDSTOPPULLUP_ZMAX #define ENDSTOPPULLUP_XMIN #define ENDSTOPPULLUP_YMIN #define ENDSTOPPULLUP_ZMIN #endif // The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins. const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. //#define DISABLE_MAX_ENDSTOPS //#define DISABLE_MIN_ENDSTOPS // Disable max endstops for compatibility with endstop checking routine #if defined(COREXY) && !defined(DISABLE_MAX_ENDSTOPS) #define DISABLE_MAX_ENDSTOPS #endif // For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1 #define X_ENABLE_ON 0 #define Y_ENABLE_ON 0 #define Z_ENABLE_ON 0 #define E_ENABLE_ON 0 // For all extruders // Disables axis when it's not being used. #define DISABLE_X false #define DISABLE_Y false #define DISABLE_Z false #define DISABLE_E false // For all extruders #define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled #define INVERT_X_DIR false // for Mendel set to false, for Orca set to true #define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false #define INVERT_Z_DIR false // for Mendel set to false, for Orca set to true #define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false #define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false #define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false // ENDSTOP SETTINGS: // Sets direction of endstops when homing; 1=MAX, -1=MIN #define X_HOME_DIR -1 #define Y_HOME_DIR -1 #define Z_HOME_DIR 1 #define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS. #define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below. // Travel limits after homing #define X_MAX_POS 300 #define X_MIN_POS 0 #define Y_MAX_POS 175 #define Y_MIN_POS 0 #define Z_MAX_POS 138.9 #define Z_MIN_POS 0 #define X_MAX_LENGTH (X_MAX_POS - X_MIN_POS) #define Y_MAX_LENGTH (Y_MAX_POS - Y_MIN_POS) #define Z_MAX_LENGTH (Z_MAX_POS - Z_MIN_POS) //============================= Bed Auto Leveling =========================== //#define ENABLE_AUTO_BED_LEVELING // Delete the comment to enable (remove // at the start of the line) #define Z_PROBE_REPEATABILITY_TEST // If not commented out, Z-Probe Repeatability test will be included if Auto Bed Leveling is Enabled. #ifdef ENABLE_AUTO_BED_LEVELING // There are 2 different ways to pick the X and Y locations to probe: // - "grid" mode // Probe every point in a rectangular grid // You must specify the rectangle, and the density of sample points // This mode is preferred because there are more measurements. // It used to be called ACCURATE_BED_LEVELING but "grid" is more descriptive // - "3-point" mode // Probe 3 arbitrary points on the bed (that aren't colinear) // You must specify the X & Y coordinates of all 3 points #define AUTO_BED_LEVELING_GRID // with AUTO_BED_LEVELING_GRID, the bed is sampled in a // AUTO_BED_LEVELING_GRID_POINTSxAUTO_BED_LEVELING_GRID_POINTS grid // and least squares solution is calculated // Note: this feature occupies 10'206 byte #ifdef AUTO_BED_LEVELING_GRID // set the rectangle in which to probe #define LEFT_PROBE_BED_POSITION 15 #define RIGHT_PROBE_BED_POSITION 170 #define BACK_PROBE_BED_POSITION 180 #define FRONT_PROBE_BED_POSITION 20 // set the number of grid points per dimension // I wouldn't see a reason to go above 3 (=9 probing points on the bed) #define AUTO_BED_LEVELING_GRID_POINTS 2 #else // not AUTO_BED_LEVELING_GRID // with no grid, just probe 3 arbitrary points. A simple cross-product // is used to esimate the plane of the print bed #define ABL_PROBE_PT_1_X 15 #define ABL_PROBE_PT_1_Y 180 #define ABL_PROBE_PT_2_X 15 #define ABL_PROBE_PT_2_Y 20 #define ABL_PROBE_PT_3_X 170 #define ABL_PROBE_PT_3_Y 20 #endif // AUTO_BED_LEVELING_GRID // these are the offsets to the probe relative to the extruder tip (Hotend - Probe) #define X_PROBE_OFFSET_FROM_EXTRUDER -25 #define Y_PROBE_OFFSET_FROM_EXTRUDER -29 #define Z_PROBE_OFFSET_FROM_EXTRUDER -12.35 #define Z_RAISE_BEFORE_HOMING 0 // (in mm) Raise Z before homing (G28) for Probe Clearance. // Be sure you have this distance over your Z_MAX_POS in case #define XY_TRAVEL_SPEED 500 // X and Y axis travel speed between probes, in mm/min #define Z_RAISE_BEFORE_PROBING 15 //How much the extruder will be raised before traveling to the first probing point. #define Z_RAISE_BETWEEN_PROBINGS 5 //How much the extruder will be raised when traveling from between next probing points //#define Z_PROBE_SLED // turn on if you have a z-probe mounted on a sled like those designed by Charles Bell //#define SLED_DOCKING_OFFSET 5 // the extra distance the X axis must travel to pickup the sled. 0 should be fine but you can push it further if you'd like. //If defined, the Probe servo will be turned on only during movement and then turned off to avoid jerk //The value is the delay to turn the servo off after powered on - depends on the servo speed; 300ms is good value, but you can try lower it. // You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile. // #define PROBE_SERVO_DEACTIVATION_DELAY 300 //If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing, //it is highly recommended you let this Z_SAFE_HOMING enabled!!! #define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area. // When defined, it will: // - Allow Z homing only after X and Y homing AND stepper drivers still enabled // - If stepper drivers timeout, it will need X and Y homing again before Z homing // - Position the probe in a defined XY point before Z Homing when homing all axis (G28) // - Block Z homing only when the probe is outside bed area. #ifdef Z_SAFE_HOMING #define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28) #define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28) #endif #endif // ENABLE_AUTO_BED_LEVELING // The position of the homing switches //#define MANUAL_HOME_POSITIONS // If defined, MANUAL_*_HOME_POS below will be used //#define BED_CENTER_AT_0_0 // If defined, the center of the bed is at (X=0, Y=0) //Manual homing switch locations: // For deltabots this means top and center of the Cartesian print volume. #define MANUAL_X_HOME_POS 0 #define MANUAL_Y_HOME_POS 0 #define MANUAL_Z_HOME_POS 0 //#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing. //// MOVEMENT SETTINGS #define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E #define HOMING_FEEDRATE {10*60, 10*60, 4*60, 0} // set the homing speeds (mm/min) // default settings #define DEFAULT_AXIS_STEPS_PER_UNIT {1066.333333333336, 1066.333333333336, 2133.333333333333, 97.079122078} // default steps per unit for Ultimaker #define DEFAULT_MAX_FEEDRATE {30, 30, 30, 10} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {25,25,25,1000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot. #define DEFAULT_ACCELERATION 10 // X, Y, Z and E max acceleration in mm/s^2 for printing moves #define DEFAULT_RETRACT_ACCELERATION 20 // X, Y, Z and E max acceleration in mm/s^2 for retracts // Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing). // The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder). // For the other hotends it is their distance from the extruder 0 hotend. // #define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis // #define EXTRUDER_OFFSET_Y {0.0, 5.00} // (in mm) for each extruder, offset of the hotend on the Y axis // The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously) #define DEFAULT_XYJERK 8.0 // (mm/sec) #define DEFAULT_ZJERK 0.4 // (mm/sec) #define DEFAULT_EJERK 5.0 // (mm/sec) //====================================================================== ===== //=============================Additional Features=========================== //====================================================================== ===== // Custom M code points #define CUSTOM_M_CODES #ifdef CUSTOM_M_CODES #define CUSTOM_M_CODE_SET_Z_PROBE_OFFSET 851 #define Z_PROBE_OFFSET_RANGE_MIN -15 #define Z_PROBE_OFFSET_RANGE_MAX -5 #endif // EEPROM // The microcontroller can store settings in the EEPROM, e.g. max velocity... // M500 - stores parameters in EEPROM // M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily). // M502 - reverts to the default "factory settings". You still need to store them in EEPROM afterwards if you want to. //define this to enable EEPROM support //#define EEPROM_SETTINGS //to disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out: // please keep turned on if you can. //#define EEPROM_CHITCHAT // Preheat Constants #define PLA_PREHEAT_HOTEND_TEMP 180 #define PLA_PREHEAT_HPB_TEMP 70 #define PLA_PREHEAT_FAN_SPEED 255 // Insert Value between 0 and 255 #define ABS_PREHEAT_HOTEND_TEMP 240 #define ABS_PREHEAT_HPB_TEMP 100 #define ABS_PREHEAT_FAN_SPEED 255 // Insert Value between 0 and 255 //LCD and SD support //#define ULTRA_LCD //general LCD support, also 16x2 //#define DOGLCD // Support for SPI LCD 128x64 (Controller ST7565R graphic Display Family) //#define SDSUPPORT // Enable SD Card Support in Hardware Console //#define SDSLOW // Use slower SD transfer mode (not normally needed - uncomment if you're getting volume init error) //#define SD_CHECK_AND_RETRY // Use CRC checks and retries on the SD communication //#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder //#define ENCODER_STEPS_PER_MENU_ITEM 5 // Set according to ENCODER_PULSES_PER_STEP or your liking //#define ULTIMAKERCONTROLLER //as available from the Ultimaker online store. //#define ULTIPANEL //the UltiPanel as on Thingiverse //#define LCD_FEEDBACK_FREQUENCY_HZ 1000 // this is the tone frequency the buzzer plays when on UI feedback. ie Screen Click //#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 // the duration the buzzer plays the UI feedback sound. ie Screen Click // The MaKr3d Makr-Panel with graphic controller and SD support // [reprap.org] //#define MAKRPANEL // The RepRapDiscount Smart Controller (white PCcool smiley // [reprap.org] //#define REPRAP_DISCOUNT_SMART_CONTROLLER // The GADGETS3D G3D LCD/SD Controller (blue PCcool smiley // [reprap.org] //#define G3D_PANEL // The RepRapDiscount FULL GRAPHIC Smart Controller (quadratic white PCcool smiley // [reprap.org] // // ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: [code.google.com] //#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER // The RepRapWorld REPRAPWORLD_KEYPAD v1.1 // [reprapworld.com] //#define REPRAPWORLD_KEYPAD //#define REPRAPWORLD_KEYPAD_MOVE_STEP 10.0 // how much should be moved when a key is pressed, eg 10.0 means 10mm per click // The Elefu RA Board Control Panel // [www.elefu.com] // REMEMBER TO INSTALL LiquidCrystal_I2C.h in your ARUDINO library folder: [github.com] //#define RA_CONTROL_PANEL //automatic expansion #if defined (MAKRPANEL) #define DOGLCD #define SDSUPPORT #define ULTIPANEL #define NEWPANEL #define DEFAULT_LCD_CONTRAST 17 #endif #if defined (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) #define DOGLCD #define U8GLIB_ST7920 #define REPRAP_DISCOUNT_SMART_CONTROLLER #endif #if defined(ULTIMAKERCONTROLLER) || defined(REPRAP_DISCOUNT_SMART_CONTROLLER) || defined(G3D_PANEL) #define ULTIPANEL #define NEWPANEL #endif #if defined(REPRAPWORLD_KEYPAD) #define NEWPANEL #define ULTIPANEL #endif #if defined(RA_CONTROL_PANEL) #define ULTIPANEL #define NEWPANEL #define LCD_I2C_TYPE_PCA8574 #define LCD_I2C_ADDRESS 0x27 // I2C Address of the port expander #endif //I2C PANELS //#define LCD_I2C_SAINSMART_YWROBOT #ifdef LCD_I2C_SAINSMART_YWROBOT // This uses the LiquidCrystal_I2C library ( [bitbucket.org] ) // Make sure it is placed in the Arduino libraries directory. #define LCD_I2C_TYPE_PCF8575 #define LCD_I2C_ADDRESS 0x27 // I2C Address of the port expander #define NEWPANEL #define ULTIPANEL #endif // PANELOLU2 LCD with status LEDs, separate encoder and click inputs //#define LCD_I2C_PANELOLU2 #ifdef LCD_I2C_PANELOLU2 // This uses the LiquidTWI2 library v1.2.3 or later ( [github.com] ) // Make sure the LiquidTWI2 directory is placed in the Arduino or Sketchbook libraries subdirectory. // (v1.2.3 no longer requires you to define PANELOLU in the LiquidTWI2.h library header file) // Note: The PANELOLU2 encoder click input can either be directly connected to a pin // (if BTN_ENC defined to != -1) or read through I2C (when BTN_ENC == -1). #define LCD_I2C_TYPE_MCP23017 #define LCD_I2C_ADDRESS 0x20 // I2C Address of the port expander #define LCD_USE_I2C_BUZZER //comment out to disable buzzer on LCD #define NEWPANEL #define ULTIPANEL #ifndef ENCODER_PULSES_PER_STEP #define ENCODER_PULSES_PER_STEP 4 #endif #ifndef ENCODER_STEPS_PER_MENU_ITEM #define ENCODER_STEPS_PER_MENU_ITEM 1 #endif #ifdef LCD_USE_I2C_BUZZER #define LCD_FEEDBACK_FREQUENCY_HZ 1000 #define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 #endif #endif // Panucatt VIKI LCD with status LEDs, integrated click & L/R/U/P buttons, separate encoder inputs //#define LCD_I2C_VIKI #ifdef LCD_I2C_VIKI // This uses the LiquidTWI2 library v1.2.3 or later ( [github.com] ) // Make sure the LiquidTWI2 directory is placed in the Arduino or Sketchbook libraries subdirectory. // Note: The pause/stop/resume LCD button pin should be connected to the Arduino // BTN_ENC pin (or set BTN_ENC to -1 if not used) #define LCD_I2C_TYPE_MCP23017 #define LCD_I2C_ADDRESS 0x20 // I2C Address of the port expander #define LCD_USE_I2C_BUZZER //comment out to disable buzzer on LCD (requires LiquidTWI2 v1.2.3 or later) #define NEWPANEL #define ULTIPANEL #endif // Shift register panels // --------------------- // 2 wire Non-latching LCD SR from: // [bitbucket.org] //#define SR_LCD #ifdef SR_LCD #define SR_LCD_2W_NL // Non latching 2 wire shift register //#define NEWPANEL #endif #ifdef ULTIPANEL // #define NEWPANEL //enable this if you have a click-encoder panel #define SDSUPPORT #define ULTRA_LCD #ifdef DOGLCD // Change number of lines to match the DOG graphic display #define LCD_WIDTH 20 #define LCD_HEIGHT 5 #else #define LCD_WIDTH 20 #define LCD_HEIGHT 4 #endif #else //no panel but just LCD #ifdef ULTRA_LCD #ifdef DOGLCD // Change number of lines to match the 128x64 graphics display #define LCD_WIDTH 20 #define LCD_HEIGHT 5 #else #define LCD_WIDTH 16 #define LCD_HEIGHT 2 #endif #endif #endif // default LCD contrast for dogm-like LCD displays #ifdef DOGLCD # ifndef DEFAULT_LCD_CONTRAST # define DEFAULT_LCD_CONTRAST 32 # endif #endif // Increase the FAN pwm frequency. Removes the PWM noise but increases heating in the FET/Arduino //#define FAST_PWM_FAN // Temperature status LEDs that display the hotend and bet temperature. // If all hotends and bed temperature and temperature setpoint are < 54C then the BLUE led is on. // Otherwise the RED led is on. There is 1C hysteresis. //#define TEMP_STAT_LEDS // Use software PWM to drive the fan, as for the heaters. This uses a very low frequency // which is not ass annoying as with the hardware PWM. On the other hand, if this frequency // is too low, you should also increment SOFT_PWM_SCALE. //#define FAN_SOFT_PWM // Incrementing this by 1 will double the software PWM frequency, // affecting heaters, and the fan if FAN_SOFT_PWM is enabled. // However, control resolution will be halved for each increment; // at zero value, there are 128 effective control positions. #define SOFT_PWM_SCALE 0 // M240 Triggers a camera by emulating a Canon RC-1 Remote // Data from: [www.doc-diy.net] // #define PHOTOGRAPH_PIN 23 // SF send wrong arc g-codes when using Arc Point as fillet procedure //#define SF_ARC_FIX // Support for the BariCUDA Paste Extruder. //#define BARICUDA //define BlinkM/CyzRgb Support //#define BLINKM /*********************************************************************\ * R/C SERVO support * Sponsored by TrinityLabs, Reworked by codexmas **********************************************************************/ // Number of servos // // If you select a configuration below, this will receive a default value and does not need to be set manually // set it manually if you have more servos than extruders and wish to manually control some // leaving it undefined or defining as 0 will disable the servo subsystem // If unsure, leave commented / disabled // //#define NUM_SERVOS 3 // Servo index starts with 0 for M280 command // Servo Endstops // // This allows for servo actuated endstops, primary usage is for the Z Axis to eliminate calibration or bed height changes. // Use M206 command to correct for switch height offset to actual nozzle height. Store that setting with M500. // //#define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1 //#define SERVO_ENDSTOP_ANGLES {0,0, 0,0, 70,0} // X,Y,Z Axis Extend and Retract angles #include "Configuration_adv.h" #include "thermistortables.h" #endif //__CONFIGURATION_H Wo muß ich den diese Werte jetzt für die Fräse anpassen? Ich bräuchte sozusagen nen Übersetzer von diesen Einstellungen zu Grbl...also Wo, wird Was Eingetragen. Vielen Dank schonmal...
>Hier mal meine Config.h die ich zum Druck benutze. Warum hast Du ihn nicht angehängt ? Bitte lies dir die GRBL-Wiki durch dort steht wie es geht: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Achtung verschiedene Befehle für verschiedene GRBL Versionen... Gruß Sven
Hallo zusammen, Ich habe mich mal ein wenig mit den Einstellungen für GRBL beschäftigt. Mein Englisch ist zwar sehr begrenzt aber zusammen mit dem Übersetzer ging es so... Als erstes habe ich mich mit der Referenzfahrt beschäftigt. Leider Erfolglos. Die Maschine fährt kurz los und bleibt ohne jeglichen kontakt nach 10-30 mm stehen. Die Endschalter(REF) habe ich nun auf AUX3 gelegt. Leider ohne Erfolg/Funktion. Einzelne Fahrbefehle und Schritte pro mm passen aber soweit. bin echt ratlos wie ich die Endschalter zum laufen bekomme.... LG,
Frank Schulze schrieb: > Als erstes habe ich mich mit der Referenzfahrt beschäftigt. Leider > Erfolglos. Die Maschine fährt kurz los und bleibt ohne jeglichen kontakt > nach 10-30 mm stehen. Also ich benutze keine Endschalter und damit keine Referenzfahrt. SerialComCNC verwendet den damit gewonnenen Maschinen-Nullpunkt auch nicht. Wie auch immer, beschäftige Dich mal mit den Einstellungen unter $5, $21 bis $27. Siehe auch hier: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Frank Schulze schrieb: > Die Endschalter(REF) habe ich nun auf AUX3 gelegt. Leider ohne > Erfolg/Funktion. Was soll denn AUX3 sein? Die Endschalter gehören an die mit "Limit XYZ Axis" bezeichneten Pins des Arduino. Siehe hier: https://github.com/grbl/grbl/wiki/Connecting-Grbl
:
Bearbeitet durch User
Hallo Albert, ersteinmal vielen Dank für ein so großartiges Programm und das Du dies mit der allgemeinheit teilst. Das mit Aux 3 kahm mir auch seltsamm vor. Mir wurde ein Bild geschickt auf dem die Anschlußskizze mit ref schalter auf Aux zu sehen war. Ärgerte mich ein wenig da ich mein Display nicht mehr verwenden könnte. http://a.fsdn.com/con/app/proj/grblforramps14/screenshots/grblRamps.png Ich hatte mir auch schon überlegt ohne ref und end zu arbeiten. Gestern habe ich noch zum testen ein Programm gestartet und es lief zu meiner Zufriedenheit. $23=1 (homing dir invert mask:00000001) Bei dieser einstellung Blicke ich nicht so ganz durch. Meine Maschine muß X nach Links ins "-" fahren, Y nach Vorn ins minus und Z nach oben ins "+?" um nach hause zu fahren.Y könnte ich aber nach hinten ändern. Nun kann ich die Maschine erstmal fertig machen und dann die Feinheiten einstellen. LG, Frank
Frank Schulze schrieb: > $23=1 (homing dir invert mask:00000001) Bei dieser einstellung Blicke > ich nicht so ganz durch. Meine Maschine muß X nach Links ins "-" fahren, > Y nach Vorn ins minus und Z nach oben ins "+?" um nach hause zu fahren Um die Fahrtrichtung hier zu ändern benutze für die Maske die selbe Tabelle wie unter: $2 Step port invert mask:binary" auf der Configuring-Grbl-v0.9 Seite. Steht doch unter $23 alles beschrieben.
Hallo Albert, wie viele Zeilen HPGL Code kannst Du konvertieren? Mit meinem Muster (knapp 10000 Zeilen) stüzt das Program leider ab. Ich habe mir einen EggBot gebaut und wollte dein SerialComCNC zur Steuerung benutzen. Anbei eine HPGL Datei die sich nicht einlesen lässt wegen der Größe. Gruß Sven
Sven schrieb: > wie viele Zeilen HPGL Code kannst Du konvertieren? Bis zu 50.000 Zeilen müssten eigentlich gehen. Wieviel maximal werde ich mal testen. > Mit meinem Muster(knapp 10000 Zeilen) stüzt das Program leider ab. > Anbei eine HPGL Datei die sich nicht einlesen lässt wegen der Größe. Die Datei lässt sich im HPGL-Converter einlesen in in G-Code wandeln. Die Übernahme des G-Codes dauert aber anschliessend viel zu lange (ca. 6 Minuten) und das Converter Fenster schliesst sich nicht. Beides wird nächste Woche mit einer neuen Version behoben. Gruss Ulrich Albert
Albert M. > Beides wird nächste Woche mit einer neuen Version behoben. Prima - Danke, toll wäre noch wenn Du auch *.hpgl als Dateiendung zulässt - dann bräuchte man die Dateien nicht immer umbenennen (kann man im Inkscape leider nicht einstellen, bzw ich hab's im Code nicht gefunden)... Falls es jemanden interessiert, anbei der modifizierte Inkscape (0.91) HPGL-Konverter um die Ausgabe im geforderten Format zu machen (siehe Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" ). Einfach die Dateien im Verzeichnis (bei mir) C:\Program Files\Inkscape\share\extensions ersetzen. Gruß Sven
Sven schrieb: > Danke, toll wäre noch wenn Du auch *.hpgl als Dateiendung > zulässt Kein Problem. Sven schrieb: > Falls es jemanden interessiert, anbei der modifizierte Inkscape (0.91) > HPGL-Konverter um die Ausgabe im geforderten Format zu machen Sehr schön, das wird bestimmt die Inkscape Benutzer interessieren. Gruss Ulrich Albert
Anbei SerialComCNC Version 0.8b Change Log V0.8b ---------------- Die Verbesserungen beziehen sich besonders auf grosse Dateien: Übernahme von grossen Excellon oder HPGL Files vom Converter "Use Processed Data" erheblich beschleunigt (< 1 Sekunde bei 10.000 Zeilen). "Clear All" und "Clear Resp" Funktion erheblich beschleunigt. File Filter für HPGL Dateien erweitert (plt + hpgl). Sven schrieb: > wie viele Zeilen HPGL Code kannst Du konvertieren? Mehr als 100.000 Zeilen sind kein Problem. Gruss Ulrich Albert Homepage: http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, >Anbei SerialComCNC Version 0.8b leider bekomme ich beim HPGL-konvertieren eine Fehlermeldung "Temp File Read error" (Datei aus Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"). Danch kommt nur noch 'Please wait...'. Ist aber halb so schlimm: Ich habe hier: https://bugs.launchpad.net/inkscape/+bug/1409568 (Beitrag 14) einen aktuellen Inkscape (0.91) HPGL exporter gefunden, welcher auch die Stiftfarben exportiert, den ich zum GRBL Plotter GCode Exporter umgebastelt habe. D.h. Pen up/down wird zu M3/M5 exportiert mit anschließender Wartezeit G04 um dem Servo Zeit zu geben den Stift abzusenken. Die verschiedenen Stiftfarben werden zu Tx konvertiert, so dass man manuell im SerialComCNC den Stift wechseln kann. Im Inkscape müssen gleichfarbige Objekte in der gleichen Ebene liegen welche als 'Pen x' (x = Stiftnummer) umbenannt werden muss. D.h. für jede neue Farbe muss eine neue Ebene angelegt werden - eine schöne Idee des Autors, jeder Stift kommt nur einmal in Export vor. Einfach die drei Dateien ins Verzeichnis (bei mir) C:\Program Files\Inkscape\share\extensions kopieren. Dann gibt es eine neue Speicheroption 'GRBL Plotter file (*.nc)'. Gruß Sven
Sven schrieb: > leider bekomme ich beim HPGL-konvertieren eine Fehlermeldung "Temp File > Read error" Welche Windows Version benutzt Du? SerialComCNC schreibt nach dem Konvertieren der HPGL oder Excellon Dateien das Resultat als File (SerialComCNC.scc) temporär in C:/users/ Die beschriebene Fehlermeldung tritt auf wenn das Schreiben oder Lesen in C:/users fehl schlägt. Bei meinem Windows 7 funktioniert das, ich kann jetzt im Moment aber nicht testen ob z.B. Windows XP anstatt das Verzeichnis "Users" das Verzeichnis "Anwender" erwartet. Ich melde mich dazu später nochmal. .... Habs jetzt unter Windows XP getestet, da funktioniert es bei mir auch. Schau mal nach, ob das Verzeichnis "C:/users" bei Dir irgendwelche Schreib-Restriktionen hat. Alternativ speichere ich das File in das jeweilige Windows temp Verzeichnis, da ich vermeiden möchte, weitere Dateistrukturen anzulegen.
:
Bearbeitet durch User
Anbei SerialComCNC Version 0.8b1 Change Log V0.8b1 ----------------- Betr. temporäre Zwischenspeicherung der konvertierten Exellon und HPGL Dateien: Das Programm sucht unter Windows nach dem voreingestelltem TempPath für Anwender Daten und speichert das temporäre File jetzt dort hin. Dies ist unabhängig von der verwendeten Windos Version und deren Einstellungen. Der verwendete TemPath wird unter "Help/Info" angezeigt. Diverse kleinere Bugs behoben. Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo, Ich musste die limit pins umzuleiten auf AUX-3, Grbl verwendet "pin change interrupt" um den limit Status zu bestimmen, und original ramps limit pins unterstützen es nicht.. Z axe ist ausgetauscht mit Y, weil die Z hat Verbindungsstelle für zweier Motoren, und shapeoko hat eine doppelte Y Arsi
arsi schrieb: > Ich musste die limit pins umzuleiten auf AUX-3, Grbl verwendet "pin > change interrupt" um den limit Status zu bestimmen, und original ramps > limit pins unterstützen es nicht.. > Z axe ist ausgetauscht mit Y, weil die Z hat Verbindungsstelle für > zweier Motoren, und shapeoko hat eine doppelte Y Und was hat das alles mit SerialComCNC zu tun? Für GRBL bin ich und dieser Thread nicht zuständig, bitte diskutiere das in irgendwelchen GRBL Foren.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMAG0344_-_Kopie_-_Kopie.JPG
240 KB -
IMAG0345_-_Kopie_-_Kopie.JPG
270 KB -
IMAG0329_-_Kopie.JPG
300 KB
Vielen Dank für die Unterstützung bei meinem Projekt. Im Anhang ein paar Bilder. LG,Frank
Danke für die Bilder Frank, würde mich auch interessieren was die Anderen so mit dem Programm anstellen. Ist die folgende Erweiterung von SerialComCNC für euch interessant? Wenn man nur einfache Fräsarbeiten hat, wie mal eben einige Löcher Bohren oder einen Auschnitt fräsen, ist es lästig eine Zeichnung zu machen, diese in die CAM-Software zu importieren um den G-Code zu erhalten. Die Erweiterung würde eine Auswahl an Arbeitsvorgängen anbieten, wie z.B.: Drill, Line of Drills, Line, Rectangle, Circle und erwartet dann die Eingabe der Parameter/Koordinaten (XY, Frästiefe, Fräsgeschwindigkeit usw). Die gewünschten Vorgänge würden in eine Liste eingetragen, in G-Code gewandelt und in das Hauptfenster zum Fräsen kopiert.
Hallo Albert, ich fände die Schnell-Fräs-Optionen durchaus interessant. Ich würde mir spontan noch die Option für Rechecke mit abgerundeten Ecken wünschen (evtl. mit Eingabe des Eckenradius). Leider habe ich noch mit ein paar Ungenauigkeit meiner Käsefräse zu kämpfen...
Bohren von Lochraster mit Eingabe x und y Maße der Lage der Bohrungen und Größe des Rasterfeldes wäre sicher auch sehr interessant. Danke für deine Arbeit
Hallo Albert, solche funktionen sind immer gut. Ich habe noch ein weiteres Problem mit der Software. Als ich mein Bedienpult gefräst habe, ist die Maschine öfters beim ausfräsen einer Kontur in die falsche Richtung gefahren. Zum Glück immer in den Ausschuss. Erst bin ich von einem Fehler der Steuerung ausgegangen und habe alles überarbeitet. Nach einem weiteren Durchlauf passierte es aber wieder. Immer bei einem Richtungs-wechsel. Als ich nicht mehr weiter wusste habe ich das Fräsprogramm mal mit dem GRBL Controller gestartet und damit läuft alles Problemlos durch. Nun habe ich immer 2 Programme offen und verbinde für die Manuelle fahrt mit Deinem, weil der GRBL Controller bescheiden ist für das manuelle fahren und für den Automatik Ablauf starte ich den GRBL. Hast Du ev eine Idee woran das liegen kann?? Ein weiteres Problem ist der Automatik-abbruch. Warum nullt sich die Steuerung und man muß danach alles neu anfahren? Gibt es eine Möglichkeit die Automatik zu verlassen ohne den Nullpunkt neu anzufahren? Vieleicht mach ich ja auch was falsch. Beim Drucken zum Beispiel konnte man das Programm auch jederzeit anhalten und die Maschine verfahren. Drückte man nun wieder Start fuhr sie zum Programmpunkt zurück. So etwas finde ich sehr gut um Teile die man ausfräst kurz zu sichern und dann weiter ausfräsen zu lassen. LG, Frank
Frank Schulze schrieb: > ist die Maschine öfters beim > ausfräsen einer Kontur in die falsche Richtung gefahren. Zum Glück immer > in den Ausschuss. Wenn Du dabei gestoppt hast, weisst Du doch nicht wohin die Maschine weiter gefahren wäre. Vielleicht war das so schon richtig und Dein CAM Programm wollte das so? Hast Du Dein CAM schon mal simuliert? Wie auch immer, versuche das ganze mal mit einer Luftnummer (Z hochgefahren) und schau Dir dabei die Ausgabe im Graphic-Monitor an. Wenn im Graphic-Monitor der Fehler auch auftritt, sende mir bitte einen Screenshot, Dein NC-Programm mit der Beschreibung wo der Fehler Auftritt und der Zeichnung. Wenn im Graphic-Monitor alles stimmt, hast Du wahrscheinlich ein EMV-Problem, d.h. durch Störimpulse von ausserhalb wird die serielle Verbindung beeinträchtigt und G-Code Befehle werden nicht korrekt übertragen oder der Controller wird direkt beeinträchtigt. Frank Schulze schrieb: > Problem ist der Automatik-abbruch. Was genau meinst Du mit Automatik-Abbruch?
:
Bearbeitet durch User
Moin, also... nehmen wir mal an ich habe mehrere Programmteile/Programme mit denen ich ein Teil bearbeiten möchte. Ich fahre den Nullpunkt für das Programm an und Starte Programm 1. Danach Programm 2 und merke nun ich habe mich mit dem Vorschub vertan oder wie im Fall meines Bedienpultes, die Maschine fährt Plötzlich in die falsche Richtung. Ich halte das Programm nun mit Programm-halt an und würde jetzt gern wieder auf meinen Nullpunkt fahren. Die manuelle verfahr-option steht mir aber in diesem Moment nicht zur Verfügung. Wenn ich jetzt auf Programm-Stop gehe, wird die Maschine auf der momentanen Position auf Null gesetzt, sodass ich mein Teil wieder neu anfahren muss. Wenn ich meinen Nullpunkt nun mit dem ersten Programmdurchlauf weg fräse, habe ich ein Problem. Zu dem Fehler: Ich habe die Seitenteile meines Bedienpultes mit einem 6mm Schrupfräser bearbeitet. Die 3eckigen Aussparungen habe ich in Z-2mm schritten ausgefräst da mein Motor sonst zu sehr Belastet wird. ( habe schon nen neuen) Nachdem ich teilweise schon 10-14 mm tief im Teil war fuhr die Maschine Plötzlich statt z.B. X-40 y-40 schräg nach x-40 Y0/-10 "gerade". Dieses Problem tauchte mehrmals auf und beschränkte sich nicht immer auf die gleiche Richtung. Auch tauchte es nicht immer an der gleichen stelle auf sondern sporadisch auch an anderen Positionen. Bis zu diesen Punkt hatte ich den Automatikablauf/Programmablauf nicht angehalten. Komischer Weise läuft aber genau das selbe Programm mit dem GRBL Controller Problemlos durch. Kann es ev. daran liegen das ein Satz nicht rechtzeitig übertragen wurde oder übersprungen wurde? was mir beim GRBL Controller aufgefallen ist, er braucht immer einen kleinen Momenent bis er den Befehl ausführt. Ich hoffe der Text verwirrt nicht all zu sehr, LG, Frank P.S: Ich werde aber bei gelegenheit den Fehler nochmal Simulieren.
@Frank In kurzen Worten: Du meinst also eine Programm-Restart Funktion die den gesetzten XYZ Nullpunkt intakt lässt und gleichzeitig das manuelle Bedienfeld wieder frei gibt. Kann ich in der nächsten Version einbauen. Nochmal zu den bei Dir sporadisch auftretenden Fehlern: Wenn es mit GRBL Controller läuft, bedeutet das nicht unbedingt dass in SerialComCNC ein Fehler vorliegt. Es ist ebenso eine prekäre Schnittstelle möglich auf die SerialComCNC empfindlicher reagiert. Dies hatte ich mal bei einem Arduino Clone, mit einem Programm war es ok, mit einem anderen sporadische Aussetzer. Hast Du den Luftnummer-Test versucht? Wie auch immer, mehr kann ich ohne Deinen G-Code zu testen nicht sagen. Bei mir treten auch bei langen Jobs keine Fehler auf, bei anderen anscheinend auch nicht, sonst hätte darüber hier schon was gestanden.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC_Vorschau.jpg
150 KB
Hier mal eine Vorschau auf die neue Erweiterung "EasyJob" als CAM für Arme. EasyJob wird im Menue von SerialComCNC aufgerufen. Folgende Arbeitsvorgängen werden angeboten: Drill Hole, Line of Holes, Line, Rectangle, Circle. Diese Jobs werden in eine Liste eingetragen. Die Jobs sind innerhalb der Liste auch noch nachträglich verschiebbar. Für Rectangle und Circle kann eine Fräserradius-Korrektur für Innen oder Aussen oder Mitte fräsen eingestellt werden. Es können einzelne Jobs oder alle zusammen konvertiert werden. Bei der Konvertierung wird der G-Code erzeugt und in das SerialComCNC G-Code File Fenster zur Benutzung eingetragen. Das gezeigte Bild diente nur zum Test. Das Layout wird noch überarbeitet.
:
Bearbeitet durch User
Hallo Albert, Vielen Dank für die Schnelle Rückmeldung und Danke schonmal für die zusätzliche Funktion die mir doch einiges an Arbeit spart. Ich habe den Test noch nicht gemacht. Ich denke da komme ich am Sonntag erst dazu. Heute habe ich erstmal meinen Bürstenlosen Motor eingebaut. Gibt es eigentlich die Möglichkeit den Motor-Regler/Servoanschluß für den Motor mit dem Ramps 1.4 zu betreiben? Es gibt ja die Möglichkeit Servos auf der Platine zu stecken...die Frage ist nur wie aufwendig das ist dies für den Regler zu konfigurieren. (http://www.ebay.de/itm/CHIRI-PRO-BL-ESC-50A-65A-SBEC-5A-5V-5-5V-6V-Governor-2-6Lipo-/181279299016?pt=LH_DefaultDomain_77&hash=item2a351695c8) Im Moment schalte ich den Motor über den Ramps1.4 ein. der Regler muß dazu auf null stehen und dann muß ich die Drehzahl von hand einstellen. LG,Frank
Guten Tag, du bist ja echt fix. Respekt. Die neue Funktionsvorlage sieht schon gut aus. Die Aufgaben der einzelnen Felder lassen sich gut erschließen. Ich hatte auch schon das Problem, dass ich einen Job abbrechen musste und nach der automatischen Nullung den Startpunkt neu anfahren musste. Wenn es für dich kein Problem wäre, ließe sich doch evtl. in den Einstellungen eine Option einrichten, um das Nullen nach Jobsreset zu unterbinden? Ich habe es bis jetzt so gemacht, dass ich mir vor dem Reset nach dem Halten die Position abgeschrieben habe und dann negativ wieder eingeben habe, um dann wieder zum Ausgangspunkt zu kommen... Ich hatte leider auch schon das Problem, dass mir der Fräser schräg vom Job abgehauen ist. Er lief dann leider in Werkstück. Es war zum Glück nur eine kleine Holzgravur. Das gerade bearbeitete Element war eine Ellipse... Ich hatte den GCODE auch in OpenSCAM erfolgreich getest. Bin aber nicht sicher ob es am SerialComCNC liegt, weil ich keine alternative geteset habe. Außerdem ist das schon ein paar Tage her, also wurde ein ältere Version verwendet (ich glaube 0.7). Wollte nur mitteilen, dass mir sowas auch schon passiert ist. Nur so nebenbei, bei einem anderen Test hat mir das Inkscape-Gcode-Tool Zeilen mit mehr als 49 Zeichen ausgegeben. Da wollte der Fräser auch schräg abhauen (er ist schräg über die Dimensonen des Gcodes hinaus gefahren und kurz vor dem Ende des Fahrwegs habe ich die Stromversorgung unterbrochen :-)), obwohl der GCODE in OpenSCAM keine Probleme machte. Habe dann Kommastellen reduzierte und irgenwann gings... Könnte natürlich auch an der GRBL Firmware liegen. Da es vielleicht im 2. Fall zum Bufferoverflow kam. Ich glaube eine Zeile darf max 49 Zeichen lang sein. Super Arbeit, mach weiter so.
Hier seht ihr eine Video-Vorschau vom neuen EasyJob Modus von SerialComCNC. Der EasyJob-Modus ist für einfache Fräs-Arbeiten und ersetzt CAD und CAM. Es können geometrische Figuren (Hole, Line of Holes, Line, Rectangle, Circle) erzeugt und parametrisiert werden, die dann autom. in G-Code überführt werden. https://www.youtube.com/watch?v=PAm-B0i21cY Gruss Ulrich Albert
:
Bearbeitet durch User
...einfach Klasse... Freu mich schon darauf, damit zu Arbeiten. Denkst Du auch noch daran die Positionen bei einem Programm-abbruch nicht zu reseten? LG,Frank
Anbei SerialComCNC Version 0.8c Change Log V0.8c ---------------- Bei Not-Aus/Reset bleibt der XYZ-Nullpunkt erhalten und kann mit dem * Button (rechts neben dem Oberen Cont-Button) angefahren werden. Dabei wird zuerst zur Sicherheit die Z-Achse um 10 mm angehoben und erst bei erreichen von XY Null auf Z0 abgesenkt. Es darf dabei nach dem Not-Reset beliebig manuell verfahren werden. Fehler bei der Graphic-Darstellung und sonstige kleinere Bugs behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert Albert M. schrieb: > Bei Not-Aus/Reset bleibt der XYZ-Nullpunkt erhalten und kann > mit dem * Button (rechts neben dem Oberen Cont-Button) Ich habe das Program kurz testen können. Während eines Durchlaufs musste ich das Fräsprogram anhalten und habe "Program-halt" gedrückt. Die Maschine blieb stehen. Dann habe ich das Programm mit "Stop-file" abgebrochen und die Position hat sich wieder genullt. Ich habe auch versucht nach "Programm-Halt" die Maschine mittels dem kleinen Button rechts neben Continue zurück zu fahren. Auch im rechten "Manuell-Feld" hatte ich keine Funktion. Was könnte ich verkehrt gemacht haben? LG, Frank
Frank Schulze schrieb: > Ich habe auch > versucht nach "Programm-Halt" die Maschine mittels dem kleinen Button > rechts neben Continue zurück zu fahren. Der kleine * Button wird erst nach einem Not-Stop aktiviert (schwarzer Rahmen um den Button = aktiv). Die Vorgehensweise: NC-Programm laden, XYZ-Nullpunkt setzen, Programm starten, Halt/Cont nach belieben (dabei aber keine Nullfahrt möglich), Programm-Abbruch mit Stop, jetzt ist der kleine * Button aktiviert und die Maschine fährt bei Button-Click auf den ursprünglichen Nullpunkt zurück, auch nachdem sie event. manuell irgend wohin verfahren wurde. Wenn der ursprüngliche XYZ Nullpunkt erreicht ist, rechts den Set XYZ-Zero Button betätigen (entfällt bei der nächsten Version). Der komplette manuelle Bedienbereich ist immer während eines Programmlaufs gesperrt. Es ist mir jedoch noch ein Fehler aufgefallen, Z wird bei der Nullfahrt mit dem * Button nicht immer korrekt um 10 mm angehoben, also Vorsicht und bis zur Korrektur Z manuell etwas hochfahren. Das werde ich gleich mit einer neuen Version korrigieren.
:
Bearbeitet durch User
Anbei SerialComCNC Version 0.8c2 Change Log V0.8c2 ----------------- Z-Fehler bei Nullfahrt nach Not-Stop mittels * Button korrigiert (siehe Beitrag oben). Die Vorgehensweise um nach Not-Halt zum Origal-Nullpunkt zu fahren: - Abwarten bis Nothalt-Prozedur beendet ist. - Auf den nun aktivierten kleinen * Button (oben) klicken. - Die Spindel fährt jetzt um 10mm hoch und dann auf XYZ-Original Null. - Dann den "Set XYZ Zero" Button drücken Info: Original-Null wird beim Betätigen des Set XYZ-Zero aus den Maschinen-Koordinaten erzeugt und gespeichert. Bei Betätigung von * (oben) werden diese Maschinen-Koordinaten wieder angefahren. Der Hintergrund ist, dass GRBL bei Reset die Weltkoordinaten nullt und somit der vorherige Nullpunkt verloren ist. SerialComCNC arbeitet ansonsten immer mit Welt-Koordinaten.
:
Bearbeitet durch User
Hallo Albert, ich hatte vorhin nochmal mit der 0.8c getestet und hab es nicht hinbekommen. Wahrscheinlich stell ich mich nur zu doof an. ;) Programm Starten - OK Programm Halt - Maschine bleibt stehen - Stern nicht möglich Stop File - Meldefenster wegklicken/bestätigen und dann ist die Position weg :( Werde Morgen Früh mal die 08.c2 testen... ev hab ich was übersehen. Aber mal davon abgesehen... Super Arbeit... Wenn ich nich so ne kleine Lernschwäche hätte, würde ich mich auch mal mit Programieren beschäftigen. Im Moment arbeite ich mich gerade in Autocad ein. Das fällt mir schwer genug. Mit Sketchup komme ich super zurecht, nur leider stimmen die Maße beim Export als Dfx nicht mehr obwohl alles auf mm steht. Komischer Weise war beim Drucken immer alles ok. Naja, bin eben eher ein Praktiker und lerne durch Probieren. LG,Frank
@Frank Wenn Du die Vorgehesweise wie zu Version 0.8c2 einhälst funktioniert das. Optimal ist dies allerdings nicht, so dass bei der nächsten Version der beim Resetten von GRBL verlorene Weltkoordinaten-Nullpunkt mittels der ursprünglichen (von Set XYZ Zero) und den aktuellen Maschinenkoordinaten berechnet wird. Mit dem G92 G-Code Befehls werden die Weltkoordinaten danach sofort neu gesetzt und erscheinen so auch in der XYZ Anzeige. Auf XYZ Null zurückfahren geht dann mit dem kleinen * Button (Sicherheitshöhe Z = 10mm) oder mit dem * Null-Button rechts (Sicherheitshöhe einstellbar über die "Home Offs. Z0" Eingabe).
Anbei SerialComCNC Version 0.8d Change Log V0.8d ---------------- Internet-Check für neue Versionen (unter Menue Hilfe). Die Versions-Nr. wird dabei aus der Info in der SerialComCNC Web Seite extrahiert. Beim Not-Stop werden die aktuellen Koordinaten neu betrechnet und in die Anzeige eingetragen, sowie den Weltkoordinaten bekannt gemacht. Auf XYZ Null zurückfahren geht jetzt mit dem kleinen * Button (Sicherheitshöhe Z = 10mm) oder mit dem * Null-Button rechts (Sicherheitshöhe einstellbar über die "Home Offs. Z0" Eingabe Ungewollter Neustart eines G-Code File bei Betätigen des Stop Buttons während die Bearbeitung läuft jetzt unterbunden. Diverse Voreinstellung für die Achsen-Skalierung der Graphic. Die Schnittstelle/ComPort ist jetzt unempfindlich gegen Programm-Beenden ohne die Verbindung vorher geschlossen zu haben. Neueste Version GRBL 0.9i (Hex-File) zugefügt.
:
Bearbeitet durch User
Folgende noch auftretende Probleme werden mit der nächsten Version korrigiert: Fehler nach Not-Stop während einer Makro-Ausführung. Fehler nach Not-Stop im Manual Process.
Change Log V0.8e ---------------- Fehler nach Not-Stop während einer Makro-Ausführung korrigiert. Fehler nach Not-Stop im Manual Process korrigiert. Sprache der Programm-Oberfläche wahlweise: Englisch / Deutsch. Auch während der Laufzeit änderbar. Einige Übersetzungen fehlen allerdings noch. Es müssen alle Dateien ins Installations-Verzeichnis kopiert werden. Die nächsten Versionen kommen mit einem eigenem Installations-Programm. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Ist ja wie Weihnachten :) Vielen,vielen Dank. Übrigends konnte ich die Maschine mit der Version 0.8d das erste mal auf den Nullpunkt zurück fahren. (allerdings auf die sogenannten Weltkoordinaten) Das Teil musste ich trotzdem neu anfahren. Da ich viele Teile aus einer Platte ausfräse, muss ich immer schauen wie ich Platztechnisch positioniere. Wenn ich dann abbrechen muss weil es einen Fehler gab (gestern zum Beispiel schaltete sich mein Motor nicht richtig ein - Reglerfehler) muss ich diesen Punkt neu finden. Ich habe ja, wie schon erwähnt, keine Ahnung wie Aufwendig das ist, so etwas zu Programieren. Deswegen hab ich jedes mal ein schlechtes Gewissen wenn ich Optionen Anfrage. ;) Ich stelle mir den Ablauf wie folgt vor: Teil anfahren - Startposition nullen Programm/File-Start - Maschine Startet Programm Bei einem Fehler - Programm HALT taste betätigen Nun wäre es zwingend erforderlich die exakte Startposition wieder zu erreichen.In der Anzeige stehen ja noch die Koordinaten, wie weit ich davon entfernt bin. Also weiter zum Ablauf: ( ich befinde mich noch im Programm-HALT ) - Das rechte manuelle Bedienfeld wird frei gegeben und ich kann die Maschine Manuell verfahren und/oder den Programm/Teil-Nullpunkt anfahren. - da das Programm noch auf HALT steht kann man nun entweder mit Continue das Programm fortsetzen und die Maschine fährt auf die letzte Programmposition zurück(nicht zwingend erforderlich), oder auf der Programm-Null_Position das Programm abbrechen. An dieser Stelle kann sich die Steuerung auch Reseten, da die Null nach dem Reset/ProgrammSTOP gleichzeitig die ProgrammStart/Teil Null ist. Ich hoffe, ich verlange nicht zuviel, LG,Frank
Frank Schulze schrieb: > Teil anfahren - Startposition nullen > Programm/File-Start - Maschine Startet Programm > Bei einem Fehler - Programm HALT taste betätigen > > Nun wäre es zwingend erforderlich die exakte Startposition wieder zu > erreichen.In der Anzeige stehen ja noch die Koordinaten, wie weit ich > davon entfernt bin. In der Beschreibung der 0.8d oben steht nichts von "Halt" drücken: Albert M. schrieb: > Beim Not-Stop werden die aktuellen Koordinaten neu betrechnet > und in die Anzeige eingetragen, sowie den Weltkoordinaten bekannt > gemacht. Auf XYZ Null zurückfahren geht jetzt mit dem kleinen * Button > (Sicherheitshöhe Z = 10mm) oder mit dem * Null-Button rechts > (Sicherheitshöhe einstellbar über die "Home Offs. Z0" Eingabe Mach einfach mal genau das was da beschrieben steht (also nicht Halt sondern Stop drücken), dann fährt deine Maschine auch nach einem Stop und drücken der * Taste auf die vorher gesetzte Nullposition zurück. Vor dem drücken des * Button (oben oder rechts) kannst Du auch noch manuell beliebig verfahren, da ja nach Stop die Bedienfläche rechts wieder freigegeben ist. Vor dem Drücken der * Taste im manuellen Bedienfeld unbedingt mit "Home Offs Z0" die Sicherheitshöhe einstellen. Bei einem Fehler (Motorausfall) wie von Dir beschrieben wird dann nach Neustart dein G-Code erneut vom vorne abgearbeitet (vom vorher gesetzten Nullpunkt). Bis zur vorherigen Fehlerstelle macht der Fräser dann zwar eine Luftnummer, aber das sollte vorerst ok sein:) Eine Funktionalität für "Halt" während des Programmlaufs, danach beliebiges Verfahren und nach "Cont" Wiederaufsetzen auf den Halt-Punkt wird es demnächst geben. Aber ich denke, Du kannst Dich mit der obigen Methode vorerst gut behelfen.
:
Bearbeitet durch User
Albert M. schrieb: > Eine Funktionalität für "Halt" während des Programmlaufs, danach > beliebiges Verfahren und nach "Cont" Wiederaufsetzen auf den Halt-Punkt > wird es demnächst geben. Nach einiger Recherche und Versuchen gibt es anscheinend keine Möglichkei diese Funktionalität mit GRBL zu erreichen. Mit "! Feed hold" kann man die laufende Abarbeitung des G-Codes ohne Schrittverluste anhalten und mit "~ Cycle start" anschliessend genau da weiterarbeiten lassen. Zwischen diesen beiden Kommandos, also nach "!" nimmt GRBL nur noch Realtime-Kommandos an, aber keinerlei G-Code Kommandos. Damit ist die oben genannte Funktionalität gestorben. Falls man jedoch vorher bereits weiss wo man anhalten möchte, kann man alternativ im G-Code ein Dummy Txx Kommando (Tool Chang/Werkzeugwechsel) einfügen. Siehe dazu die entsprechnde Beschreibung in der Hilfe.
:
Bearbeitet durch User
Angehängte Dateien:
-
Fehler_SerialComCNC.jpg
43 KB
Hallo Albert, nachdem ich SerialComCNC_0.8e auf meinem Windows 7 PC installiert habe bekomme ich die im Bild zu sehende Fehlermeldung. Auch ein Neustart des Rechners hat nichts gebracht. Die Version 0.8d lief noch einwandfrei. Viele Grüße Herbert
@Herbert König Probier bitte mal die beiliegende Version aus (mit und ohne Admin Rechte). Wann tritt der Fehler auf? Ich arbeite auch unter Win7 und kann leider den Fehler nicht reproduzieren. Gruss Ulrich Albert
:
Bearbeitet durch User
Hallo Albert, damit gehts! Vielen Dank und ein schönes Wochenende Grüße Herbert
Anbei SerialComCNC Version 0.9 Change Log V0.9 --------------- Der Button für die Funktion "Test Code" ist jetzt im Process Display angeordnet und die Funktion wurde automatisiert. Bei Betätigung wird der geladene G-Code sofort auf dem Arduino ausgeführt, allerdings ohne Signale an die Stepper-Driver auszugeben. Fehler im Code können damit festgestellt werden ohne die Fräse zu bewegen. Fehler bei Excellon-File Import. Eventuelle Kommas wurden bei Konvertierung nach G-Code nicht in Dezimalpunkte gewandelt. Aufruf des Windows-Rechners oder eines frei wählbaren Calculators. Programm-Layout mit wählbarem Farbschema: grau grau-blau grün-beige Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert, ist es mit viel Aufwand verbunden, bei Fenstermaximierung auf Bildschirmgröße, das Seitenverhältnis der Grafikvorschau zu erhalten. Im Moment kann man ja das Fenster noch nicht bildschirmfüllend maximieren? Ich hoffe, daß ich einigermaßen verständlich erklärt habe was ich meine. Viele Grüße Herbert
Herbert König schrieb: > ist es mit viel Aufwand verbunden, bei Fenstermaximierung auf > Bildschirmgröße, das Seitenverhältnis der Grafikvorschau zu erhalten. > Im Moment kann man ja das Fenster noch nicht bildschirmfüllend > maximieren? Das ist keine Vorschau, sonder die Realtime-Darstelung der Fräser-Bewegung. Durch eine Vergrösserung des Grafikfensters erhält man auch nicht besonders mehr Information. Event. kommt ja zu der jetzigen XY-Verschiebung der Grafik per Mouse noch eine Zoom-Möglichkeit.
Hallo Albert, gestern habe ich mal die Probfunktion getestet und bin nun etwas verwundert. Bis jetzt bin ich davon ausgegangen, dass ich die Prob mit bekannter Höhe auf den Tisch bzw auf das Werkstück stelle und antaste. Danach sollte der Z-Wert / Nullpunkt korrekt eingestellt sein. Beispiel: das Werkstück ist 5mm hoch, die Prob ist 20mm hoch und steht auf dem Werkstück. Der Fräser fährt nach Antasten der Prob 10mm hoch, dann sollte doch der Z-Wert doch auf 30mm stehen. Warum soll ich also das Werkstück noch mal antasten? Was hat es mit den F2, F5 und F10 aufsich? Gruß MartinM
MartinM schrieb: > Bis jetzt bin ich davon ausgegangen, dass ich die Prob mit bekannter > Höhe auf den Tisch bzw auf das Werkstück stelle und antaste. Danach > sollte der Z-Wert / Nullpunkt korrekt eingestellt sein. Es wird bei der erstmaligen Einrichtung der Probe davon ausgegangen, dass die Höhe der Probe nicht genau bekannt ist, was gerade für den Schaltpunkt selbstgebauter Probes zutrifft. Wenn Du die genaue Höhe der Probe (Schaltpunkt) bereits kennst, kannst Du diesen Wert natürlich direkt in Einstellungen/Probe/Probe_Höhe eintragen und mit "Set" F2 bis F10 die Anfahrgeschwindigkeit (Feed) auf die Probe einstellen, die dann rechts unter "P-Feed mm/min) angezeigt wird. Die einmal eingetragene Probe Höhe bleibt auch nach Beenden des Programms erhalten und wird im "Manuellen Prozess" Feld angezeigt. Danach brauchst Du also jedesmal (also auch nach Programm-Neustart) nur die Probe auf das (neue) Werkstück setzen und "P" (Probe) drücken, das Werkzeug tastet jetzt die Probe an und fährt hoch. Danach verfährst Du auf deinen XY-Nullpunkt und drückst "UP" (Use Probe) und das Werkzeug fährt auf Z0 herunter und Du kannst den Button "Setze XYZ Null" betätigen. Falls Du dann nochmal verfahren möchtest ist das kein Problem, der XYZ Nullpunkt bleibt ja erhalten. Siehe dazu auch unter "Probe" in der Hilfe.
:
Bearbeitet durch User
Angehängte Dateien:
Anbei SerialComCNC Version 0.9a Change Log V0.9a ---------------- Es wurden 3 Buttons ( >X0 , >Y0 , >Z0 ) zugefügt. Damit können die Achsen auch getrennt auf Null-Position gefahren werden. Buttons 0,1 und 0,01 wurden in der Version 0.9 versehentlich vertauscht. Kleinere Fehler bei der Farbzuordnung beim wählbaren Farbschema behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Hallo Albert. danke für sie schnelle Anwort, jetzt ist es auch mir klar, was gemeint ist. Weiter so, super Programm! Gruß MartinM
Hallo Albert, auch auf die Gefahr, dass ich nerve, möcht ich Dich fragen, ob eine automatische Antastung in X und Y-Richtung auch möglich ist. Also sowas in der Art "G38.2 X-10 F10". Dann könnte man damit ja einen 3D-Kantentaster verwirklichen. Technisch ist das leicht umzusetzen, gibt es bei Ebay als Kantentater mit LED. LED raus Kabel mit Stecker dran fertig. Gruß MartinM
MartinM schrieb: > gibt es bei Ebay als Kantentaster mit LED Hast Du Dir auch mal die Schaftdurchmesser (10 bis 20 mm) angesehen? Die kann man auf einer Hobby-Fräsmaschine nur schwer oder garnicht einspannen.
Hallo zusammen, Das mit dem Kantentaster finde ich eine gute Idee. Auf welche pins des Atmega/Ramps1,4 setzt man den auf? Ich habe aber noch ein weiteres Problem. Ich kann leider mit den Weltkoordinaten überhaupt nichts anfangen. Nach einem Programm Abbruch kann ich nun die Null Position anfahren, die Maschine fährt aber auf die "Welt 0", also auf den Punkt, auf dem sie stand als ich sie eingeschaltet habe. Meine Werkstück Null ist somit wieder weg und ich muss mir diesen Punkt aufs neue suchen.( Falls er nicht beim ersten Durchgang weg gefräst wurde) Bitte,bitte, bitte...gib mir eine Möglichkeit problemlos zu meinem Werkstücknullpunkt, an dem ich das Programm gestartet habe zurück zu kehren. LG,Frank
Hallo Albert, die Kantentaster von Ebay waren nur als Beispiel für die technische Umsetzung gemeint. Da ich selbst nur eine ER11-Spannzange habe kommen die für mich auch nicht in frage. Ich würde mir selbst eine Drehen ( Kunststoffschaft in die Spannzange und eine Kugel als elek.Kontakt unten dran), das Werkstück würde ich dann an Masse angeschliessen. Radius der Kugel eintragen und somit X- und Y-Achse Nullen. Aber noch mal zurück zum Z-Probing. Wenn der Fräser die Z-Probe berührt hat, fährt er danach 10mm nach oben und im Display steht dann 10.000mm. Ich würde aber erwarte, wenn meine Probe mit 20.000mm angegeben ist, dass dann im Display 30.000mm steht. Damit bräuchte ich den UP-Button nicht mehr und würde die Arbeitsschritte UP anklicken, warten bis Z-Achse runtergefahren ist und dann Z-Achse Nullen einsparen. Gruß MartinM
Hallo Albert, nachdem ich meine Fräsmaschine fertig gebaut habe, habe ich dein Programm getestet, es funktioniert im großen Umfang auf Anhieb. Der Haken ist: das Programm hat keine Werkzeugskorrektur (Txx und M06) und ist somit für CNC-Fräser nicht optimal. Da kannst du nicht dafür, weil es im grbl nicht implementiert ist. Schade. Gruß Tany
Frank Schulze schrieb: > Nach einem Programm Abbruch > kann ich nun die Null Position anfahren, die Maschine fährt aber auf die > "Welt 0", also auf den Punkt, auf dem sie stand als ich sie > eingeschaltet habe. Bei mir fährt nach einem Stop, die autom. Reset-Prozedur abwarten und dann Click auf * die Maschine immer auf den mit "Set XYZ Zero" eingestellten ursprünglichen Nullpunkt zurück. Ich habe jetzt 1 Stunde unter immer neuen Konditionen probiert und es wird immer korrekt auf den eingestellten Nullpunkt zurückgefahren. Ich werde das aber noch weiter untersuchen. Hat noch jemand dieses Problem? MartinM schrieb: > Aber noch mal zurück zum Z-Probing. Das werde ich nochmal überdenken. Tany schrieb: > Der Haken ist: das Programm hat keine Werkzeugskorrektur (Txx und M06) > und ist somit für CNC-Fräser nicht optimal. Da kannst du nicht dafür, > weil es im grbl nicht implementiert ist. Schade. Ja Schade. Leider kann ich mich auch nur auf das stützen was GRBL an Funktionen anbietet.
:
Bearbeitet durch User
An die Admins Welcher Idiot hat die Thread Überschrift geändert von ATMega auf Z80? Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit Z80 Wenn sich hier jeder so einhacken kann und Thread-Überschriften nach Belieben manipulieren kann, wird es wohl Zeit dass ich Microcontroller.net verlasse. Laufend werden auch wie von Geisterhand meine gerade eingegebenen Texte hier verändert. Wenn ich A T M G A eingebe wird diese sofort wie von selbst in ZetAchtzig verändert. Ich hab jetzt hier die Schnautze voll! Grsuus Ulrich Albert
:
Bearbeitet durch User
@Ulrich ist / war meines wissens ein April Scherz des Forumbetreibers global einige Prozessorbezeichnungen zu vertauschen vlG Charly geht auch mit der Autokorrektur in Office prima, der in die aendern und umgekehrt, die Sekraetaerin wird verzweifeln ;)
:
Bearbeitet durch User
Hallo Albert, ich habe es heute tatsächlich geschaft nach einem Fräserbruch meinen Nullpunkt wieder an zu fahren. Ich glaubte das teil schon verloren und probierte denoch die Nullfahrt. Und siehe da... er fuhr zum Startpunkt. Ich werde es nochmal testen, denn seither habe ich die Achsen separat Achse für Achse beim anfahren genullt da diese nicht immer auf dem gleichen Punkt lagen. Ev gibt es einen Unterschied zwischen XYZ Null und achsen einzeln nullen. LG, ein sehr zufriedener Frank
Angehängte Dateien:
-
IMAG0379.JPG
280 KB -
IMAG0378.JPG
170 KB -
IMAG0377.JPG
170 KB -
IMAG0382.JPG
170 KB
ertappt... Hallo Albert, Wir hatten es letztens davon, das die Maschine sporadisch falsch fährt. Mir ist das immer wieder mal passiert, aber es waren kleine Teile und somit nicht der Rede Wert. Von einem Gcode-Fehler ist zu 200% nicht auszugehen da ich z.B. mit einem Programm schon mehrere Teile ausgefräst habe und es auch nicht immer an der gleichen Stelle auftritt. Gestern war es besonders Ärgerlich da es nicht nur ein großes Teil war, sondern die Maschine nach über einer Stunde Fräszeit durch das fertige Teil gefahren ist. Zum Glück mit der ersten Zustellung beim Teil Ausschneiden. Ich habe nicht abgebrochen und einfach weiterlaufen lassen. Wie man auf den Bildern sehen kann, ist die Maschine von rechts Mitte Teil nach Oben Mitte Teil gefahren und hat die rechte obere Ecke einfach ausgelassen. Also keine Falsche Koordinate angefahren sondern einfach Programmpunkte/Koordinaten ausgelassen/übersprungen. Großes zittern bei der nächsten Zustellung und tatsächlich fährt die Maschine bei den nächsten 2 durchläufen richtig. Großes Fragezeichen??? Störungen bei der Übertragung schließe ich eigentlich aus, da dass USB Kabel direkt beim Board aus der Maschine raus kommt und ohne Umwege in den Rechner geht. Vieleicht ist die Übertragung zu schnell, sodas Sätze übersprungen werden? Ich kenne mich da leider überhaupt nicht aus. LG Frank
Albert M. schrieb: > An die Admins Es gibt nur einen. Es war der 01.04. als Albert M. schrieb: > Welcher Idiot hat die Thread Überschrift geändert von ATMega auf Z80? Wer hat Java erfunden? Ein kleiner Tipp: du solltest nicht allzu spassbefreit und gereizt durchs Leben gehen...
Lothar Miller schrieb: > Es war der 01.04. als Albert M. schrieb: >> Welcher Idiot hat die Thread Überschrift geändert von ATMega auf Z80? > Wer hat Java erfunden? > Ein kleiner Tipp: du solltest nicht allzu spassbefreit und gereizt > durchs Leben gehen... Lothar, ich bin bestimmt der letzte der nicht für einen Spass zu haben ist. Aber in dem Moment hatte ich, wie andere bestimmt auch, einen dicken Hals :)
Frank Schulze schrieb: > Ich habe nicht abgebrochen und einfach weiterlaufen lassen. Wie man auf > den Bildern sehen kann, ist die Maschine von rechts Mitte Teil nach Oben > Mitte Teil gefahren und hat die rechte obere Ecke einfach ausgelassen. > Also keine Falsche Koordinate angefahren sondern einfach > Programmpunkte/Koordinaten ausgelassen/übersprungen. Da hättest Du besser abgebrochen und Dir im G-Code Fenster angesehen ob eine Fehlermeldung angezeigt wurde. Ebenso hättest Du im Monitor/Prozess Fenster die letzten Befehle/Werte ansehen können. Frank Schulze schrieb: > Großes zittern bei der nächsten Zustellung und tatsächlich fährt die > Maschine bei den nächsten 2 durchläufen richtig. Das der Fehler bei Dir sporadisch Auftritt ist eher ein Zeichen von EMV-Störungen. Frank Schulze schrieb: > Vieleicht ist die Übertragung zu schnell, sodas Sätze übersprungen > werden? Das halte ich für sehr unwahrscheinlich. Im Programm wird vor Absenden eines neuen G-Code Befehl geprüft ob der letzte Befehl bereits abgearbeitet wurde und der neue schon in den Eingangs-Puffer passt. Übersprungen werden oder zu schnell sein kann da nichts. Und wenn würde da eher ein systematischer Fehler auftreten, also beim gleichen G-Code File immer an der selben Stelle. Als sonstige mögliche Fehlerursachen kommen in Frage: EMV-Störungen in Deiner Elektronik oder von aussen (Spikes im Netz), Probleme mit dem USB/Seriell Wandler auf dem Arduino Board, Stromversorgung der Elektronik. Wissenswert dazu ist auch, obwohl das eher für systematische Fehlerbilder zutrifft, dass GRBL bei einem nicht akzeptierten Zeichen/Befehl den kompletten Befehlsatz verwirft, also alle in der Zeile stehenden korrekten Code-Segmente. Da ist Vorsicht geboten, da manche CAM-Software G-Code mit Befehlen produziert die in GRBL nicht zulässig sind. GRBL unterstützt ja nur ein Subset der möglichen G-Code Befehle. Wenn man da nicht sicher ist, sollte das G-Code File zuerst mal im Test-Mode durchlaufen und das Ergebnis im G-Code Fenster geprüft werden.
:
Bearbeitet durch User
Angehängte Dateien:
-
SerialComCNC__preview.jpg
430 KB -
SerialComCNC__preview2.jpg
180 KB
Hier eine neue Vorschau auf den EasyJob Modus. Der EasyJob-Modus ist für einfache Fräs-Arbeiten gedacht und ersetzt dabei CAD und CAM. Es können folgende geometrische Figuren/Jobs erzeugt und parametrisiert werden, die dann autom. in G-Code konvertiert und in das Hauptprogramm übertragen werden. Drill Hole : Einfache Bohrung mit Fräser-Durchmesser Drill Line of Holes : Eine Reihe von Löchern mit Fräser-Durchm. Line : Eine Linie, Fräser mittig, links, rechts Rectangle : Rechteck, Fräser mittig, aussen, innen Rounded Rectangle : Rechteck runde Ecken, sonst wie Rechteck Circle : Kreis, Fräser mittig, aussen, innen Line of Circles : Reihe von Kreisen, sonst wie Kreis Rectangular Pocket : Rechteck-Tasche, Fräser innen Rect. Rounded Pocket : Rechteck-Tasche mit runden Ecken Circular Pocket : Kreistasche, Fräser innen Die Jobs werden in eine Liste eingetragen und können einzeln oder zusammen in G-Code überführt werden. Optional kann eine Graphik der Jobs als Vorschau zur Überprüfung der Einstellungen angezeigt werden (siehe Bild oben, kleine Kreuze = Drill Line of Holes). Die Job-Liste ist auch noch nachträglich frei editierbar und lässt sich zur weiteren Verwendung speichern. Voll Funktionsfähig sind zur Zeit bereits Drill Hole, Drill Line of Holes, Line, Rectangle und Circle. Es ist noch viel zu tun :) Schon mal frohe Ostern! Gruss Ulrich Albert http://www.serialcominstruments.com/
:
Bearbeitet durch User
Moin, Frank Schulze schrieb: > Wir hatten es letztens davon, das die Maschine sporadisch falsch fährt. > Mir ist das immer wieder mal passiert, aber es waren kleine Teile und > somit nicht der Rede Wert. Von einem Gcode-Fehler ist zu 200% nicht > auszugehen da ich z.B. mit einem Programm schon mehrere Teile ausgefräst > habe und es auch nicht immer an der gleichen Stelle auftritt. > Gestern war es besonders Ärgerlich da es nicht nur ein großes Teil war, > sondern die Maschine nach über einer Stunde Fräszeit durch das fertige > Teil gefahren ist. Zum Glück mit der ersten Zustellung beim Teil > Ausschneiden. das Problem kann ich mit GRBLFeeder/GCodeSender oder wie das jetzt heißt als Frontend bei meinem GRBL-MF70-Umbau ebenfalls bestätigen. Bei der 0.8er trat es bei mir sporadisch auf, mit der aktuellen hatte ich es zweimal in zwei Jobs, hatte das dann zurückgeflasht und mich geärgert. Ich kann auch bestätigen, dass das mit 99%iger Wahrscheinlichkeit nicht mit der seriellen Verbinung zusammen hängt. Der GRBL scheint wohl seinen RAM zu korrumpieren oder sowas. Bei mir sieht das dann so aus, dass die Fräse einen Versatz fährt und anschließend weiterläuft, als wär nix gewesen. Für die Theorie spricht auch, dass die Maschine danach bei mir falsche Arbeitskoordinaten hatte. Der Fehler tritt scheinbar auch häufiger auf, wenn ein G92 (Bezugspunkt) gesetzt ist. OT: Ich hab vor einiger Zeit mal ein I/O-Board für die Verwendung mit GRBL angefangen. Das implementiert auf einem Mega32U2 einen virtuellen COM-Port und stellt acht Open-Collector-Outs, acht optisch getrennte Inputs und zwei Relaisausgänge zur Verfügung. Wenn ich mal wieder dazu komme an der Firmware weiterzuarbeiten, wird man die Eingänge auch auf Key-Events mappen können(zB F13..F20). Ich werde das mal hier im Wiki dokumentieren. Wäre vielleicht was, ums in das Frontend zu integrieren, falls das Board hier auf Interesse stößt. Ich habs damals entworfen, weil ich keine Lust auf Aluspäne in der Laptoptastatur habe.
:
Bearbeitet durch User
von
Albert M.
(Firma: Bastler aus Mönchengladbach)
(albertm)
