Mein System: ------------ PC mit Windows 8.1 GBRL 3.6.1 1.) Eine Ramps 1.4 mit Atmel 2560 mit 3 Schrittmotoren auf einem Holzbrett montiert. 2.) Einen Arduino-Uno. Ich verwende beliebige *.nc files und beliebige *.gcode files.
Meine Erfahrung mit CNC beträgt ungefähr 1-2 Stunden.
Auf beiden Systemen Ramps und Arduino-Uno erscheint folgender Fehler:
"wait for ok failed" "process interrupted"
Danach steht das System. Dieser Fehler tritt bei ca. 30 Prozent der *.nc und *.gcode files auf.
Weiterhin treten noch folgende Fehler auf: ... Befehl unbekannt ... Alarm
Eigentlich ist eine CNC Steuerung ein Echtzeitsystem der PC aber nicht. Der PC kann Antwortzeiten Verzögerungen bis zu 100 ms haben. Mein 3D Drucker Geetech bleibt auch manchmal stehen wenn er mit dem PC verbunden ist aber nie wenn die Daten *.stl von der SD-Card im 3D Drucker gelesen werden.
ich glaube Du musst noch weit mehr als 2 Stunden in Dein Hobby investieren. Deine Ausführungen und Fragen deuten darauf hin, dass hier noch viel aufzuarbeiten ist.
1.) Für den 2560ger Prozessor gibt es keine GRBL-Firmware (bzw. nur auf einer speziellen Version)! 2.) Kein (mir bekannter) 3D-Drucker verarbeitet direkt *.STL-Dateien. Die werden am PC vorher mit einem Slicer in G-Code umgewandelt. 3.) Der G-Code Generator, der als Output einer CAD-Software den G-Code generiert, muss einen speziellen GRBL-Treiber besitzen. Denn nur dann wird ein code erzeugt, der zu 100% vom GRBL-Interpreter auf dem Board verstanden wird! 4.) Die "Verzögerung" auf dem PC ist unerheblich. Der Mikroprozessor auf dem die GRBL-Firmware läuft ist "Echtzeitfähig"! Der PC muss nur über die USB-Schnittstelle schnell genug den G-Code zum Board übertragen. Das ist bei 112600 Baud gewährleistet. Das ist die Voreinstellung bei GRBL ab der Version 0.9!
Du siehst, es ist noch einiges zu entdecken übrig! LG Ronald
1.) Auf die Ramps 1.4 mit dem Atmel 2560 mit den 3 Schrittmotoren habe ich ein *.hex File geladen das mit der GRBL Software auf dem PC zusammenarbeitet. Die Schrittmotoren arbeiten, allerdings drehen sie zur Zeit mit kleinen Fähnchen ins Leere.
2.) Da habe ich was falsches geschrieben über meinen 3d Drucker, es ist keine *.stl Datei sondern eine GCode Datei auf der SD-Card.
3.) Das habe ich mir auch schon gedacht, dass nicht ein X-beliebiges *.nc file oder *.gcode file genommen werden kann.
4.) und was ist wenn die Daten zu schnell kommen ?
Ich habe einige gcode Files die laufen aber fehlerfrei durch. Auf beiden Systemen dem Ramps und dem Arduino-Uno.
Wenn ich jetzt selbst ein bisschen G-Code lerne und kleine Fahrprogramme schreibe, die müssten dann aber ohne Fehlermeldung laufen. Ich rede jetzt nicht von fehlerfrei im Sinne einer Werkstückproduktion, nur ohne GRBL-Fehleranzeige.
Wenn ich das hinkriege, erst dann beginne ich mit der mechanischen Hardware. Weil beim Schrauben sieht man was man macht.
für den Atmega 2560 gibt es nur einen Fork, der dann mit dem GRBL-Controller auf dem PC zusammen arbeitet. Hast Du den drauf? Wenn nicht, wenn Du z.B. Merlin auf dem Board hast, dann kann der andere G-Code Befehle als die original GRBL-Firmware für den Arduino-UNO!
Versuch mal eins der beiden angehängten Dateien. Die sind zu 100% GRBL-geeignet und befinden sich komplett im positiven Bereich (1.Quadranten). Bitte das .txt hinten wieder abtrennen!
Anmelden
