mikrocontroller.net

Forum: Projekte & Code Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega


Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
22 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Gerhard W. (gerhard_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
3 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Max May (max6666)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Tany (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SUUUUUUUUUUUUUUUUUPER!

Autor: Hardy F. (hardyf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schliesse mich einfach mal Max und Waldemar an...

Gute Arbeit, bin sehr gespannt auf kommende Versionen.

Danke !

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
Ebay-Artikel Nr. 221394570257
Ebay-Artikel Nr. 181353602653
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Anbei SerialComCNC Version 0.4a (Maintenance Release)

Autor: Einhart Pape (einhart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian W. (ch65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian W. (ch65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Christian W. (ch65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Christian W. (ch65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hardy F. (hardyf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Hardy F. (hardyf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
(Ebay-Artikel Nr. 371135385497) 
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

Ebay-Artikel Nr. 311106253844

Ebay-Artikel Nr. 181537932223

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
Autor: Christian W. (ch65)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Michael W. (slackman)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter Tarpan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Walter Tarpan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Andreas H (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas H (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: sand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Andreas H (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah,

ja so geht's auch bei mir.

danke
Andreas

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Hans Lang (holzwurm56)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Peter Xuang (peter_x)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Einhart Pape (einhart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thorsten Ostermann (Firma: mechapro GmbH) (ostermann) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: CNC-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 !

Autor: Daniel Devaux (deva_d)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael W. (slackman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Piter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Francesco Na (franceso-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 .

Autor: GrblGru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=...

Da gibt es auch ein Filmchen und meinen 1. Versuch einer 
Bedienungsanleitung.




Gruß + weiter viel Erfolg

  GrblGru

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Einhart Pape (einhart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du bist wirklich von der schnellen Truppe Ulrich Albert! Ich bin 
wirklich beindruckt.

Herzlichen Dank dafür.

Gruß
Einhart

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fräser (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hardy F. (hardyf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 !

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Walter Tarpan (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nach dem Jogging sollte nochmal zur Sicherheit ein G90 gesendet werden.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Daniel S. (Firma: privat) (daniel_sun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ein erfreuter Benutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: ein erfreuter Benutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Albert M. schrieb:
> oder einstellbar

Das wäre natürlich optimal.

Vielen Dank !

Super - nach Minuten schon eine positive Antwort.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: ein erfreuter Benutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andree (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...wirklich tolles Programm, welches ich an meinem Selbstbaulasergravier 
betreibe. Um Längen komfortabler als die diversen GCodesender!

Klasse, danke dafür !!!

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Reiner W. (reiner_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Reiner W. (reiner_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Waldemar.

Auf so eine Antwort habe ich gehofft;-)
Da mach ich mich mal an die Arbeit.

Autor: Kristian P. (Gast)
Datum:
Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?
Ebay-Artikel Nr. 321380535406

: Bearbeitet durch User
Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Albert,
 voll genial dein projekt.

Grüsse Matthias

Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MTA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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
Autor: Edgar R. (edgar_cnc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Edgar R. (edgar_cnc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: V. K. (fragender)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Crazy H. (crazy_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: fragender (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: MTA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MTA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ingo W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MTA (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MTA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ingo Wendler schrieb:
> Könnte vielleicht an einer manuell geänderten Systemschriftröße liegen.

Ingo war schneller :-)

Autor: Ronny S. (phoenix-0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ronny S. (phoenix-0815)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Crazy H. (crazy_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Crazy H. (crazy_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Waldemar P. (waldi_p)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry: 
Ebay-Artikel Nr. 311106192368

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Harry (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo Albert,

da mach ich mir keine Gedanken. Das läuft so ja seit ca. 1 1/2 Jahren 
unter Mach3.

Gruss
Harry

Autor: Conny G. (conny_g)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Yetim Yetim (yetim-a)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
INKSCAPE erzeugte plt. oder hpgl. Datei -> SerialComCNC -> HPGL 
Converter= (FEHLERMELDUNG)" ist kein Gleitkommawert.

Was mache ich hier falsch?

Gruß
Yetim

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Johannes (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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

Autor: Thorsten Ostermann (Firma: mechapro GmbH) (ostermann) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Gabriel M. (gabse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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:
Ebay-Artikel Nr. 321380535406

Gruss Ulrich Albert

Homepage:
http://www.serialcominstruments.com/

: Bearbeitet durch User
Autor: Mechaniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DANKE für dieses Programm und die ständigen sehr nützlichen 
Erweiterungen.
 Ich zähle es zu dem besten Frontend für Grbl.

Autor: Gabriel M. (gabse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Hardy F. (hardyf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Wilfried Richter (knozi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charly B. (charly)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
poste mal ne Bohrdatei, am besten als .zip

vlG
Charly

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Richter (knozi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
ich habe auch einen anderen USB-Port versucht - dort wurde der gleiche 
Treiber über den Windowsdienst installiert - mit gleichem Ergebnis...

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wilfried Richter (knozi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Schulze (Firma: e.m.s.) (frankschulze)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Schulze (Firma: e.m.s.) (frankschulze)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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...

Autor: Sven (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>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

Autor: Frank Schulze (Firma: e.m.s.) (frankschulze)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank Schulze (Firma: e.m.s.) (frankschulze)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/scre...

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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Sven (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: arsi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: CNC Projekt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Unterstützung bei meinem Projekt. Im Anhang ein paar 
Bilder.

LG,Frank

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: bastelFritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hardy F. (hardyf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

(Ebay-Artikel Nr. 181279299016)

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

Autor: bastelFritz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Youtube-Video "SerialComCNC neuer EasyJob Modus"

Gruss
Ulrich Albert

: Bearbeitet durch User
Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark Haber (mark_haber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein tolles Projekt!

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Frank Schulze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Herbert König (herbi39)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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
Autor: Herbert König (herbi39)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Albert,

damit gehts!

Vielen Dank und ein schönes Wochenende

Grüße
Herbert

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Herbert König (herbi39)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MartinM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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