Announcement: there is an English version of this forum on 
Wie schon in einem anderen Thread angedeutet, habe ich jetzt mit dem Projekt begonnen. Darum geht es: Stepper Motor / CNC Windows-Frontend für GRBL mit ATMega328/Arduino/Uno/Nano für die billigen A4988 CNC Motor Controller Boards und ähnlichen. Der Vorteil von GRBL ist das fertige und ausgetestete Hex-File, welches man einfach auf einen Arduino Uno/Nano flashen kann. Die Kommunikation läuft dann über die eingebaute USB/Seriell-Schnittstelle. Damit entfällt der parallele Printer-Port, der sonst meist für CNC genutzt wird, aber in neuern PC's nicht mehr vorhanden ist. Die Interpretation des G-Codes findet auf dem ATMega statt. Der PC sendet nur den G-Code und passende Steuerbefehle. Es gibt zwar einige wenige Frontends für Linux/Java/Windows, aber alles hat mir für meine Zwecke nicht wirklich zugesagt. Also erstelle ich jetzt eine Bedienoberfläche für Windows neu. Als Features habe ich mir gedacht: - Manual-Mode, umfangreicher Handbetrieb - File-Mode, das G-Code-File wird autom. ausgeführt - G-Code Editor und G-Code Befehlszeile - Autom. Fehlererkennung im G-Code - Betrieb von 1 bis zu 3 Stepper Motoren - Betrieb eines Spindelmotors mit Geschwindigkeitssteuerung - event. Kühlmittelfreigabe für den Spindelmotor - Umfangreiche Betriebs/Status-Anzeigen - Graphische Darstellung des GCodes mit Echtzeitverlauf Die ersten Versuche mit einem Arduino Nano, A4988 Board und kleinerem Stepper-Motor in einer simplen Versuchanordnung verlaufen bereits erfolgreich (siehe Bild). Oben seht ihr einen Screen Shot der vorläufigen Programm-Version. Übrigens verwende ich die Version 0.9g des GRBL Hex-File. Hier noch einige Links zu GRBL: https://github.com/grbl/grbl/wiki https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/ Gruss Ulrich Albert
Angehängte Dateien:
-
SerialComCNC_v0.1_Test.jpg
170 KB -
IMG_5720_fuer_Forum.jpg
380 KB
Angehängte Dateien:
-
SerialComCNC_v0.1_Test_2.jpg
150 KB
So, der manuelle Modus ist inzwischen voll funktionsfähig. Wenn es einer an seinen Schrittmotoren ausprobieren möchte, kann ich eine vorläufige Programmversion mit manuellem Modus hier einstellen. Der nächste Schritt, der File-Modus, ist etwas anspruchsvoller und dauert bei der Programmierung was länger :)
Angehängte Dateien:
-
SerialComCNC_v0.1_Test_3.jpg
110 KB
Anbei SerialComCNC Version 0.1 In dieser frühen Version ist der manuelle Modus voll funktionsfähig und eignet sich gut zum Testen von Schrittmotoren oder auch bereits zur halbautomatischen CNC Bearbeitung mit Fräsen, Drehmaschinen oder für sonstige Bewegungsvorgänge. Der File-Modus ist noch nicht funktionsfähig. Das Zip-File enthält: - SerialComCNC Programm - GRBL v0.9g Hex-File (G-Code Interpreter) zum Flashen auf Arduino Uno/Nano - XLoder Programm, damit lässt sich das GRBL Hex-File direkt auf den Arduino flashen. Alle Maschinen-Parameter lassen sich einfach über direkte GRBL-Befehle im Frontend anpassen. Ansicht der Maschinen-Parameter durch Eingabe von $$ und Hilfe über Eingabe von $ Die eingestellten Maschinen-Parameter werden persistent im ATMega gespeichert. Über Rückmeldungen und Vorschläge würde ich mich freuen. Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
Im Frontend der "Nullpunkt setzen". Welcher Nullpunkt ist denn gemeint? Der X, Y oder Z-Nullpunkt? Wäre es nicht Sinnvoll den Button entsprechend X,Y,Z zu unterteilen? Weil ich ermittel ja die Nullpunkte einzeln nacheinander.
Danke für den Hinweis. X,Y,Z Nullpunkt einzeln setzen kommt als zusätzliche Option in der nächsten Version. Der File Modus, incl. G-Code Editor funktioniert auch bereits soweit.
Angehängte Dateien:
-
SerialComCNC_v0.2.jpg
170 KB
Anbei SerialComCNC Version 0.2 Change Log V0.2 --------------- XYZ Achsen können jetzt auch einzeln genullt werden. G-Code File-Import mit vollständigem Processing, d.h. Übertragung auf den Arduino. Das G-Code File kann editiert werden. Fehler im G-Code werden während der Abarbeitung angezeigt (siehe Bild oben). Was noch nicht geht: Koordinaten Anzeige während der Abarbeitung des G-Code Files. Menue-Einträge fehlen, usw. Ausserdem kommt eine G-Code Überprüfung ohne Stepper-Motor Bewegung, so dass man Fehler frühzeitig erkennt und im Editor beheben kann. Das geänderte File kann dann wieder gespeichert werden. In der vorliegenden Form kann das Programm aber bereits produktiv genutzt werden.
Sieht wieder mal sehr vielversprechend aus. Eindeutig Daumen hoch! Ganz spontan kam mir gerade die Idee, daß es wohl relativ einfach wäre, ein Handrad einzubinden. Ein Drehencoder, paar Taster und ein Controller, der per serieller Schnittstelle an den PC sendet.
Hallo, ich verwende die Software JCNC in Verbindung mit GRBL oder TinyG. Die macht doch schon alles was du brauchtst... http://www.jtronics.de/software/jcnc-cnc-steuerung.html Mach doch lieber Vorschläge was noch mit in die Software soll. Ich selbst habe schon einige Wünsche geäußert, welche dann schnell bearbeitet wurden.
tobi schrieb: > ich verwende die Software JCNC in Verbindung mit GRBL oder TinyG. > Die macht doch schon alles was du brauchtst... Die Entwicklung der jtronics Software steht seit längerem anscheinend still und es fehlt: - Ein direktes Eingabefeld für G-Code - Eine direkte Feed-Einstellung - Möglichkeit die XYZ-Achsen einzeln zu Nullen - Response über Fehler im G-Code File - Eine vernüftige Hilfe, incl. G-Code Befehle usw.... Alles das was bei jtronics fehlt kann meine Software oder wird sie demnächst können.
Angehängte Dateien:
-
SerialComCNC_v0.3.jpg
180 KB
Anbei SerialComCNC Version 0.3 Change Log V0.3 --------------- Änderung der Start-File und Not-Stop Bedienung. G-Code File nun voll editierbar. Speichern und Laden des G-Code Files. Halt und Continue ohne Schritt- und Positionsverlust. Anzeige der Job-Dauer. Mit Test-Button und Start wird das File zur Überprüfung auf dem MC ausgeführt ohne die Motoren bewegen (ohne Signale an das Driver Board). Home Offset für die Y-Achse zugefügt. Die X Y Z Displays funktionieren zur Zeit nur mit der manuellen/interativen G-Code Eingabe/Verarbeitung. Ansonsten kann die Software produktiv genutzt werden. Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
Hallo Albert, Das sieht schon ganz gut aus um längen angenehmer als die Java Geschichten die zur GRBL-Steuerung im Netz kursieren. Ich selbst nutze GRBL auch schon gut über einem Jahr es ist erstaunlich was der "chamnit" da so zaubert aus dem 328. Also weiter so einem Fan hast Du schon gewonnen. schöne Grüße Waldemar
Hallo, hab mich eben extra hier angemeldet um dir zu sagen, dass ich von deiner Idee und der Umsetzung begeistert bin. Weiter so, bin schon ganz ungeduldig und warte auf die nächste Version. Als Anregung würde ich noch vorschlagen, dass man die Achsen so wie unter LinuxCNC auch noch mit den Peiltasten und den "Bild auf" und "Bild runter" manuell verfahren kann. Ist den auch ein "Vorschaubereich" des Teils und ein virtuelles abfahren angedacht. Den zweiten Fan hast du auch schon. Max P.S. auch deine Tools für mc zur seriellen Schnittstelle find ich klasse.
Schliesse mich einfach mal Max und Waldemar an... Gute Arbeit, bin sehr gespannt auf kommende Versionen. Danke !
Die Software ist ja gerade mal 6 Tage mit wenigen Stunden in der Entwicklung. Da freut es mich besonders, dass sie euch schon gefällt. Die neue Version kommt schnellstens. Was an Erweiterungen so alles kommt muss ich selber mal sehen, für Vorschläge bin ich dankbar. Eigentlich sollte das ja nur ein Projekt für meine eigenen Bedürfnisse sein. Anscheinend findet es mehr Interesse und das motiviert für zusätzliche Features :)
Angehängte Dateien:
-
SerialComCNC_v0.4.jpg
200 KB
Anbei SerialComCNC Version 0.4 Change Log V0.4 --------------- X X Z - Displays jetzt in allen Modi funktionsfähig. Im manuellen Modus Verfahren über Keyboard/Keypad möglich. Deaktivierung der Schnittstelle bewirkt einen Not-Halt. Hilfe-System/Bedienungsanleitung teilweise erstellt. Diverse Bugs behoben. Das dürfte für den Praxiseinsatz erst mal reichen. Alles Zusätzliche ist Nice-To-Have. Soll aber nicht heissen, dass die Entwicklung stehen bleibt, mal schauen wie aufwändig eine Realtime-Grafik dazu ist :) Ich baue jetzt zuerst mal meine Käsefräse Proxxon MF70 auf CNC um. Habe mir dazu diese Teile bestellt: http://www.ebay.de/itm/CNC-Kit-PROXXON-MF70-umbau-auf-CNC-fur-NEMA17-und-NEMA23-Motoren-/221394570257?pt=Modellbauwerkzeuge&var=&hash=item338c250c11 http://www.ebay.de/itm/181353602653?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 Referenzschalter verbau ich keine, weil für meine Zwecke unnötig. Der Umbau war der eigentliche Anlass für die Software-Entwicklung. Mal schauen was dem Mechanik/Elektronik Geraffel wird. Und noch einen Stepper-Motor samt Driverboard übrig, irgend wo für wird der auch noch gut sein. Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
Anbei SerialComCNC Version 0.4a (Maintenance Release)
Hallo Ulrich oder Albert, Was du da in kurzer Zeit auf die Beine stellst ist einfach klasse! Eine grafische Darstellung wäre das Sahnehäubchen. Dein Programm kommt bei mir sicher zum Einsatz. Die Schrittmotoren sind schon an meiner Fräse (und behindern den manuelen Betrieb ;-). Danke für deinen Einsatz. Einhart
Angehängte Dateien:
Hier mal eine Vorschau auf die nächste Version. Neue Features: Graphische Darstellung der vom Arduino zurückgelieferten Positionswerte beim Fräsen. Die Anzeige ist in mm skaliert und kann verschoben und gezommt/umskaliert werden, auch während des laufenden Betriebes. Es werden die Verfahrwege in x und y Koordinaten als Draufsicht angezeigt. Eine 3D Darstellung ist mir z.Z. zu aufwändig. Für diejenigen die eine Farbunterscheidung zwischen Verfahren und Fräsen möchten: GRBL richtet auf dem ATMega einen Befehlspuffer ein. Ich schicke an den Puffer solange Befehle, bis der nächtste Befehl nicht mehr vollständig passt. Damit wird die Look-Ahead Funktion von GRBL voll genutzt. Der ATMega arbeitet die Befehle im Befehlspuffer ab und sendet auf Anfrage leider nur den Status und die Positionswerte zurück. So ist bei der Auswertung für die Grafikanzeige nicht mehr einfach nachvollziehbar welche Positionsdaten Verfahr- oder Fräswerte sind, da man nicht bestimmen kann welcher von vielen möglichen Behlen im Puffer gerade abgearbeitet wird. Bei GRBL-Frontends die eine farbige Unterscheidung zeigen werden demnach die Befehle einzeln abgearbeitet (in den Puffer geschickt und gewartet bis fertig) und damit kann die Look-Ahead Optimierung von GRBL dann nicht genutzt werden. Lange Rede kurzer Sinn: Mir ist die Look-Ahead Optimierung lieber und ich pfeife auf eine farbige Unterscheidung. Was es noch Neues gibt: Ein Process View, bei dem im File-Mode alle an den Arduino geschickten Befehle und vom Arduino kommenden Positionswerte aufgelistet werden. Zwischen Grafik und Process View kann während des Betriebes umgeschaltet werden.
Hallo Albert, Das sieht schon Profi massig aus. bin begeistert was Du in so kurzen Zeit auf die Beine gestellt hast. Die Graphikmode in 2D reicht vollkommen. Ich selbst benutze GRBL bei meiner Platinenfräse dazu Konvertiere ich die Exellon Bohrdaten ( DRL ) und HP-Plotdaten ( PLT ) zur G-Code um die Fräse mit Daten zu füttern. Als Vorschlag zu späterem Zeitpunkt, so eine zusätzliche Implementierung der Funktionen, wird bestimmt vielen Usern nützlich sein. Da die meisten hier mit Elektronikbasteleien am werkeln sind. schöne Grüße Waldemar
Hallo Ulrich, Respekt! Ich finde es klasse was mach einer hier für Sachen produziert. Auch ich nutze das GRBL (noch v0.8) auf einer älteren, von mir umgebauten Säulenfräse. Ich habe das GRBL für einen STM32 Mikrocontroller umgeschrieben und um einige Fähigkeiten für die manuelle Bedienung erweitert. Da ich meist nur Teile aus Platten herausfräsen bzw. kompliziert angeordnete Lochmuster bohren will, wird bei mir nur X und Y vom Prozessor gesteuert, Z bediene ich manuell. Ich werde mir dein Tool auf jeden Fall mal näher anschauen und sehen was damit bei mir geht. Beste Grüße Christian
Hallo Ulrich, für eine Echtzeit-Positionsanzeige würde ich dir anbieten, das GRBL so zu modifizieren dass es dich ständig oder auf Abruf mit aktuellen Postitionsdaten versorgt. Meine Version macht das bereits, um das Display des "Handrades" mit diesen Informationen zu füttern. Christian
Christian W. schrieb: > für eine Echtzeit-Positionsanzeige würde ich dir anbieten, das GRBL so > zu modifizieren dass es dich ständig oder auf Abruf mit aktuellen > Postitionsdaten versorgt. Hallo Christian, das macht meine Software natürlich bereits, auch ohne GRBL Modifikation. Wie sollten die Anzeigen und die Graphic auch sonst funktionieren? Was GRBL in der neuen Version 0.9g leider noch nicht macht, ist eine zusätzlich zu der Koordinaten-Ausgabe eine Information über den aktuell bearbeiteten Befehl zu liefern, z.b. ob es ein G0 oder G1 Aufruf war. Das könnte ich gut gebrauchen, siehe mein Beitrag oben. Ansonsten sieht es so aus, dass ich vom PC timergesteuert ca. 7 mal pro Sekunde den Befehl "?" schicke, worauf GRBL mit Status und aktuellen Koordinaten antwortet. Schnellere Update als ca. 10/s würden GRBL zu stark ausbremsen und event. Fehlfunktionen verursachen. Aber eigentlich reichen die 7 mal pro Sekunde gut aus. Schneller würde auch nicht mehr Information bringen. Ändern möchte ich GRBL auf keinen Fall. Ich will mich bei meinem Programm immer auf die aktuelle/offizielle GRBL Version stützen.
Angehängte Dateien:
-
SerialComCNC_v0.5_Bild1.jpg
200 KB
Anbei SerialComCNC Version 0.5 Change Log V0.5 --------------- Graphische Darstellung der Verfahr/Fräswege, incl. mitlaufendem Fadenkreuz auf der aktuellen Postion. Die Darstellung kann beliebig verschoben oder umskaliert werden, auch während des Fräsvorgangs. Process View mit laufender Anzeige der Schnittstellen Kommunikation während des File-Mode Betriebes. Diverse Bugs beseitigt. Have Fun! Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/ Link zu meinem Project SerialComInstruments: Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"
Ich habe vorhin wohl geantwortet, bevor ich dein Problem richtig verstanden habe. Klar zeigt der "?" Befehl die aktuellen Koordinaten. Du brauchst den GCode Befehl der aktuell aus dem Puffer abgearbeitet wird. Den könnte man zusammen mit den Koordinaten des "?" Befehls an den PC zurückschicken. Das zu ändern wäre keine große Tat... Ich würde erstmal damit anfangen ein absolut identisches GRBL 0.9g Hexfile zu compilieren, und dann die Änderungen einbauen... Das Angebot steht ;-) Mal interessehalber: Mit welchem Tool (Visual Studio Express etc...) entwickelst du dein Windows Programm?
Christian, ich programmiere mit Delphi 7 Professional. Danke für dein Angebot GRBL passend zu modifizieren. Das ergibt für mich allerdings folgendes Problem: GRBL ist in C geschrieben und meine C Kenntnisse sind eher mangelhaft. Ich müsste daher immer auf Dich oder jemand anderes zurückgreifen, wenn es eine neue GRBL Version gibt, damit meine Software auch dann noch funktionsfähig bleibt. Daher möchte ich mich, zumindest vorerst, auf die offiziellen GRBL Version stützen, auch wenn das ein odere andere noch fehlt. Aber vielleicht komme ich doch noch mal auf Dein Angebot zurück :)
Ich verstehe das Problem. Melde dich gern wenn du Interesse hast, solche Projekte kann man einfach nur unterstützen :) Als ich damit anfing hatte mir vorgenommen, meine Änderungen an des GRBL Team zurückzuschicken damit sie offizioll einfließen können. Aber die Änderungen sind bis auf die STM32-Adaptierung sehr speziell (manuelle Betriebsmodi für selbstgebautes Handrad mit CAN Bus etc.) und für aussenstehende nicht gut genug dokumentiert. Ausserdem sollen noch weitere Funktionen rein. Ich befürchte das braucht so kein anderer... aber vielleicht versuche ich es doch mal.
Einsame Spitze, dein Projekt. Es waere gut, wenn man die benoetigten Konfigurations-Einstellungen gleich ueber die grafische Oberflaeche deines Programms in den GRBL bringen koennte. Beim Aufbau der Fraese wird doch viel experimentiert, da waere dies sicher optimal. Vielleicht waere dies auch fuer andere interessant. Vielen Dank fuer deine Arbeit.
Hardy F. schrieb: > Es waere gut, wenn man die benoetigten Konfigurations-Einstellungen > gleich ueber die grafische Oberflaeche deines Programms in den GRBL > bringen koennte. > Beim Aufbau der Fraese wird doch viel experimentiert, da waere dies > sicher optimal. Hallo Hardy, diese Funktionaltät ist doch bereits vorhanden: Wenn Du z.B. die Step (z.B für die X-Achse) pro mm skalieren möchtest, gibst Du in das Befehls-Eingabefeld unten rechts einfach ein: $100=x (wobei 100 = XAchse und x = Step). GRBL antwortet dann, wenn alles passt, mit einem OK. Dieser Eintrag wird dann permanent auf dem EEPROM des Arduino/ATMega gespeichert. Die aktuellen Einstellungen der z.Z. möglichen 32 Parameter ruft Du mit $$ zur Ansicht im Monitor auf und kannst sie, wie gerade beschrieben, neu setzen. Einfach mal probieren, dann siehst Du wie einfach das geht. Einer zusäzlichen Eingabemaske im Programm bedarf es dafür nicht. Mit der beschriebenen Konfigurations-Methode bleibt man auch flexibel wenn bei GRBL in Zukunft neue Parametrierungs-Befehle dazu kommen. Ansonsten müsste in meinem Programm jedesmal die Eingabemaske angepasst werden. Siehe dazu auch: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9
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.
Angehängte Dateien:
-
SerialComCNC_v0.5_Bild2a.jpg
110 KB -
SerialComCNC_v0.5_Bild2b.jpg
220 KB -
SerialComCNC_v0.5_Bild2c.jpg
110 KB
Hier ein kleines Beispiel, entstanden für das Fräsen von einem Zahnradsatz aus Polystyrolglas. Und was mit dem netten Zahnrad-Konstruktions Programm (nicht von mir) noch Schönes machbar ist zeigt das 3. Bild.
Hi Albert, vor ca. einem Jahr habe ich mir mit Unterstützung die c't Portalfräse nachgebaut. Da die Steuerung softwareseitig mit einem uralt-Labview von c't gelöst wurde, war das natürlich auf meinem aktuellen Labview (Studentenversion aus einem Buch) nicht lauffähig. Umso mehr freut es mich, dass Du Dich dem Thema widmest! Ich habe nämlich einen GRBL Stepper auf Basis eines Arduino Nano zuwischengeschaltet, sodass der jetzt die Fräse steuert. Es hat mich schon ein wenig geärgert, dass die c't Leute solch aufwändige Projekte nicht vernünftig zum Abschluss bringen. Als Softwareentwickler bin ich natürlich auch schon auf die Idee gekommen, selber ein Frontend zu bauen, über den Anfangsstatus bin ich aber bislang nicht hinausgekommen (Familie und Pendelei fordern ihren Tribut). Da ich überwiegend C# unter Visual Studio code und die Anwendung gerne in C# übersetzen würde, interessiere ich mich natürlich brennend für die Sourcen. Besteht die Möglichkeit, dass Du sie veröffentlichst oder sie auf Anfrage zusendest? Ich würde gerne eine Gamepad Unterstützung hinzufügen. Import von SVG, DXF,... und Umsetzung in GRBL wären auch noch schön. Am Wochenende werde ich Deine Anwendung testen, ich freue mich schon drauf! Gruß Michael
Michael W. schrieb: > Da ich überwiegend C# unter Visual Studio code und die Anwendung gerne > in C# übersetzen würde, interessiere ich mich natürlich brennend für die > Sourcen. Besteht die Möglichkeit, dass Du sie veröffentlichst oder sie > auf Anfrage zusendest? Hallo Michael, Ich programmiere alle meine Projekte mit Delphi/Pascal. Die Sourcen veröffentliche ich bei meinen Projekten nicht. Michael W. schrieb: > Ich würde gerne eine Gamepad Unterstützung > hinzufügen. Die Gamepad Unterstützung hatte ich bereits für kommende Versionen vorgesehen. Ich werde allerdings zuerst mal testen, ob das überhaupt sinnvoll ist. Michael W. schrieb: > Import von SVG, DXF,... und Umsetzung in GRBL wären auch > noch schön. Die Umsetzung von Vector-Graphic in G-Code ist nicht trivial und ziemlich aufwändig. Da benutze ich z.Z. lieber käufliche CAM-Software, wie z.B. Filou usw. Aber vielleicht gebe ich mich da doch mal dran.
Hi Albert, danke für die Antwort und: schade wegen der Sourcen. Ich hatte gelesen, dass Du in Delphi codest, das Umsetzen in C# wäre aber sicher möglich - egal. Das Gamepad halte ich schon für eine gute Sache, um die Fräse erstmal auf Position zu bringen. Macht das Anwählen und Nullen wirklich bequemer. Die nächste G-Code Version soll ja Joggen unterstützen (wenn das noch in den 328 passt). Auch von mir hier nochmal Glückwunsch und Dank für Deine Software. Konnte meine Fräse damit erfolgreich in Bewegung setzen. Cool! (Muss bei meiner Fräse die Endschalter noch installieren). Gruß Michel
Hallo Albert, Ich hatte mir nochmal Dein Bild aus dem ersten Beitrag angesehen: möchtest Du mit einfachen Gewindestangen eine Fräse bauen? Meine ersten Versuche habe ich ähnlich begonnen und hatte das Problem, dass die Muttern auf dem Gewinde recht viel Spiel haben: wenn die Drehrichtung umgekehrt wird, dreht der Motor einige Steps bevor die Mutter in der Gegenrichtung mitgenommen wird. Es gibt also ein Problem beim wiederfinden z.B. des Startpunktes einer Figur. Wie löst Du das Problem? Wahrscheinlich wirst Du nicht um Gewindespindeln mit passender Mutter herumkommen. Ich teste noch mit preiswerten Rändelmuttern (http://www.ebay.de/itm/Kunststoff-Polyamid-Randelmuttern-M6-Polyamid-schwarz-10St-/371135385497?pt=DE_Haus_Garten_Heimwerker_Eisenwaren&hash=item5669648f99) für eine einfache kleine Platinenbohrmaschine... Geplant ist, zwei solcher Muttern in einem Block leicht zu kontern. Für ein anderes Projekt habe ich die unwesentlich teureren 8825 Treiber für die Schrittmotoren benutzt, die 4988 Treiber sind mir zweimal durchgebrannt. Damit soll man sogar noch Nema 23 Stepper treiben können. Das habe ich aber noch nicht getestet, meine laufen mit Toshiba TB5660 Treibern, weshalb ich auch ein Interface bauen musste: USB -> Printeranschluss mit Arduino Nano als GRBL Bindeglied. Gruß Michel
Michael W. schrieb: > Ich hatte mir nochmal Dein Bild aus dem ersten Beitrag angesehen: > möchtest Du mit einfachen Gewindestangen eine Fräse bauen? Nein, bewahre! Das war nur ein quick+dirty Testaufbau für meine Software. Die Software ist eigentlich für meine Proxxon MF70 Käsefräse. Nach einem Reinfall mit einem Chinesen mit angeblichem "German Warehouse", der dann doch nicht den bestellten Kit (Motoren, Driver und Netzteil) liefern konnte, habe ich mir jetzt das hier bestellt: http://www.ebay.de/itm/SainSmart-CNC-Router-1-Axis-3A-TB6560-Schrittmotor-Stepper-Motor-Driver-Board-/311106253844?pt=Motoren_Getriebe&hash=item486f60b414 http://www.ebay.de/itm/Free-shipping-5PCS-Nema17-1-3A-4-leads-17HS5413-stepper-motor-3D-printer-/181537932223?pt=Motoren_Getriebe&hash=item2a448103bf und einen mechanischen Umbau-Set für die MF70 (ca. 50 Euro). 8825 Treiber Boards habe ich hier auch noch rum liegen, ich habe mich dann aber für die obigen Boards entschieden. Die Stepper-Motoren (5 Tage Lieferzeit) und der Umbau-Set sind inzwischen da, auf die Driver-Boards warte ich noch. Dazu kommt noch ein Schaltnetzteil 24V 6A. Endschalter brauche ich für meine Zwecke nicht. Ich nulle auf das Werkstück und damit hat es sich.
Hallo Michael, dieses Umkehrspiel kann man selbst mit teuren Kugelgewindespindeln nicht ganz eliminieren. Die gesamte Antriebskette Schrittmotor-Getriebe-Kupplung-Kugelumlaufmutter hat immer ein Restspiel. Gäbe es gar kein Spiel würde das ganze klemmen. Bei meiner Fräse (mit 16/5mmm Kugelumlaufspindeln aus China) beträgt das gesamte Umkehrspiel immer noch ca 3/100 mm. Ich gleiche das per Software aus. Grbl 0.8 kann das von haus aus nicht, aber eine Umkehrspiel-Kompensation lässt sich mit erträglichem Aufwand nachträglich einbauen. CNC Programme wie Mach 3 usw. haben diese Funktion konfigurierbar eingebaut. Gruß Christian
Angehängte Dateien:
-
SerialComCNC_v0.5_Bild3.jpg
440 KB
Mal ein Einblick in den Bastelfortschritt bei der Hardware. Die Stepper Motoren sind an der MF70 Fräse montiert und die x-Achse ist bereits funktionsfähig. Leider sind die fehlenden Driver Boards noch nicht angekommen.
Angehängte Dateien:
-
Fraese_3.jpg
550 KB -
Fraese_Controller_Power.jpg
670 KB -
Fraese_GRBLler.jpg
930 KB
Cool, nicht schlecht, so'n Umrüstset! Sieht ja schon nach richtiger Arbeit aus. Und auch das Oszi kommt mir bekannt vor :-) Ich hab meins vor einem Jahr gegen das DS 1074Z von Rigol getauscht und hochgepatcht ;-) Ich wollte mir eine Fräse mit größerem Arbeitstisch bauen, naja, man will ja immer alle möglichen Großtaten damit erledigen (einerseits Platinen fräsen, andererseits Sperrholz und Alu 'schneiden'). Die Fräse ist also nach einem Bauvorschlag aus einer c't Hacks. Allerdings sind hier die Teile aus Eisen statt Alu, die komplette Fräse wiegt sicher an die 50 kg, allein die Nutenplatte und die Grundplatte haben 20mm Stärke. Bei dem China-Controller gab's damals Mach3 dazu (Testversion?), die Fräse lief aber eher schlecht als recht mit einem Windows PC als Controller. Seit dem GRBL Interface läuft sie richtig gut. Aus Kostengründen versuche ich natürlich mit Freewaretools auszukommen. Gruß Michel
Albert M. schrieb: > Mal ein Einblick in den Bastelfortschritt bei der Hardware. Ein wenig OT: Ich sehe, Du nutzt ein Rigol DS1022 zum Testen Deiner Hardware. Steuerst Du das Gerät irgendwie vom PC aus fern? Kannst Du das irgendwie aus Matlab oder Python fernsteuern? Viele Grüße W.T. P.S.: Die MF70 mit CNC ist auch niedlich. Aber das DS1022 interessiert mich momentan mehr, weil ich vor einer ähnlichen Problemstellung stehe.
Michael W. schrieb: > nicht schlecht, so'n Umrüstset! Sieht ja schon nach richtiger Arbeit > aus. Den Umrüstsatz hatte ich in weniger als einer Stunde montiert. Gegenüber meiner MF70 ist Deine Fräse ja schon ein richtiger Brocken. Walter Tarpan schrieb: > Ich sehe, Du nutzt ein Rigol DS1022 zum Testen Deiner > Hardware. Steuerst Du das Gerät irgendwie vom PC aus fern? Kannst Du das > irgendwie aus Matlab oder Python fernsteuern? Du meinst doch sicher den Funktionsgenerator DG1022? Das Oszi ist ein Rigol DS1052E, aber egal: Nachdem ich versucht hatte mit dem Rigol Oszi was in Verbindung mit dem PC zu machen und das nur sehr umständlich und mit fremden Treibern von NI mehr schlecht als recht machbar war, ist mir die Lust auf eine gleiche Erfahrung mit dem DG1022 Fkt-Generator vergangen. Daher kann ich Dir dazu leider auch nicht mehr sagen. Rigol muss was das Steuern und Auslesen der Geräte mittels PC angeht langsam etwas mehr Enthusiasmus zeigen. Prospektversprechen und Realität klaffen da noch weit auseinander.
Albert M. schrieb: > Du meinst doch sicher den Funktionsgenerator DG1022? Das Oszi ist ein > Rigol DS1052E, aber egal: > Nachdem ich versucht hatte mit dem Rigol Oszi was in Verbindung mit dem > PC zu machen und das nur sehr umständlich und mit fremden Treibern von > NI mehr schlecht als recht machbar war, ist mir die Lust auf eine > gleiche Erfahrung mit dem DG1022 Fkt-Generator vergangen. Daher kann ich > Dir dazu leider auch nicht mehr sagen. Rigol muss was das Steuern und > Auslesen der Geräte mittels PC angeht langsam etwas mehr Enthusiasmus > zeigen. Prospektversprechen und Realität klaffen da noch weit > auseinander. Hallo Albert, danke für die Antwort. Ich habe es gestern einfach mal probiert (habe das Gerät erst seit ein paar Tagen) und siehe da: Sobald man die SCPI-Kommandos senden kann, geht alles ganz wunderbar. Jetzt am OT Ende. Viele Grüße W.T.
Hi Albert, dieses Wochenende habe ich etwas mehr Zeit gehabt, mich etwas mit meiner Fräse und Deinem Tool zu beschäftigen. Die ersten Tests hatte ich mit der 0.4.0 Version gemacht, dabei lief alles ganz gut. Als ich heute die 0.5.0 benutzt habe, reagierte die Anwendung nicht auf Eingaben: Codes konnte ich eingeben, im Monitorfenster gab's aber kein Feedback. Zurück zur 0.4.0 - alles lief problemlos. Irgendwas in der Kommunikation zwischen den Versionen hat sich geändert... Dann habe ich noch den 'UniversalGCodeSender' ausprobiert, ähnlich Funktionalität aber eigentlich gefällt mir Deiner besser. Einige schöne Features hat er trotzdem: - Man kann die $$ Settings in einer Tabellenform editieren und dann auf den Controller zurückschreiben - sehr schön. - Unter anderem kann man die Feedback Polling Rate einstellen, auch sehr schön. So kann man eperimentieren, wie oft man pollen kann, ohne die Codeausführung zu stören. Gruß Michel
Michael W. schrieb: > Die ersten Tests hatte ich mit der 0.4.0 Version gemacht, dabei lief > alles ganz gut. Als ich heute die 0.5.0 benutzt habe, reagierte die > Anwendung nicht auf Eingaben: Codes konnte ich eingeben, im > Monitorfenster gab's aber kein Feedback. Zurück zur 0.4.0 - alles lief > problemlos. Irgendwas in der Kommunikation zwischen den Versionen hat > sich geändert... Wenn Du auf der rechten Seite nichts eingeben/bedienen kannst, ist die serielle Kommunikation nicht etabliert. Im Programmcode wurde in den Kommunikations-Routinen zwischen den Versionen nichts geändert. Ich habe es bei mir noch mal mit verschiedenen Boards und PC's (Arduino Uno, Arduino Nano, aktueller PC mit Win7, vintage PC mit Windows XP) gestestet und alles läuft einwandfrei. Manchmal connecten die Arduino Boards nicht direkt beim ersten Einstecken des USB-Kabels. Das ist aber kein Problem meines Programms, sondern hat etwas mit den verwendeten USB/Seriell Treibern der Boards zu tun. > Dann habe ich noch den 'UniversalGCodeSender' ausprobiert, ähnlich > Funktionalität aber eigentlich gefällt mir Deiner besser. 'UniversalGCodeSender' ist eine Java basierte Anwendung. SerialComCNC ist eine nativ Windows Application ohne Abhängigkeiten. > Einige schöne Features hat er trotzdem: > - Man kann die $$ Settings in einer Tabellenform editieren und dann auf > den Controller zurückschreiben - sehr schön. Dazu habe ich bereits oben was geschrieben. Die Änderung von Parametern über die Eingabebox in meinem Programm ist auch nicht wesentlich aufwändiger. Vorläufig werde ich da nichts ändern. > - Unter anderem kann man die Feedback Polling Rate einstellen, auch sehr > schön. So kann man eperimentieren, wie oft man pollen kann, ohne die > Codeausführung zu stören. Das Polling erfolgt bei mir im Abstand von 150 ms, also ca. 6,7 mal pro Sekunde. Nach meinen Tests treten Störungen erst bei kürzeren Zeiten als 90 ms auf. Schnelleres Pollen bringt eh keinen praktischen Vorteil. Gruss Ulrich Albert
Hallo Albert, Bin neu hier und dank Grbl & Arduino Nano auf dein Projekt gestoßen. Natürlich habe ich mir dein Frontend gleich geladen, und es sieht toll aus nur leider gibt's es keine Verbindung zu meinen Arduino´s. Es kommt immer die Meldung: Serial Port Connection Error. Das die Verbindung funktionieren könnte zeigt mir die Verwendung des Grbl Controller (http://zapmaker.org/projects/grbl-controller-3-0/). Damit bekomme ich eine Verbindung hin. Was würdest du an Informationen benötigen um zu erkennen woran es liegen könnte? Getestet habe ich übrigens die Versionen 0.4a & 0.5. beides unter Win7/64. Abgesehen davon hab ich eine Frage zum Unterschied Uno zu Nano und Grbl. Die Pinbelegung zeigt ja beim Uno das z.B. für die X Achse Step und Dir auf den Pins 2 und 5 liegen. https://github.com/grbl/grbl/wiki/Connecting-Grbl Wenn ich nun den Nano verwenden will, sind Step und Dir aber auf den Pins 2 und 3. Beim gleichen Hex File und auch bei deinem Testaufbau im ersten Bild so zu sehen (wenn ich es richtig interpretiere). Hast du eine Idee wie man am Nano zur gleichen Pinbelegung kommt wie am Uno? besten Dank Andreas
Andreas H schrieb: > Es kommt immer die Meldung: Serial Port Connection Error. Bei mir funktioniert die Verbindung unter Windows 7 32bit. Ich werde in den nächsten Tagen aber mal mit verschiedenen Arduino Boards untersuchen, wo event. die Verbindungsprobleme bei Dir liegen könnten. Michael (siehe oben) hatte ja auch ähnlich Probleme. > Hast du eine Idee wie man am Nano zur gleichen Pinbelegung kommt wie am > Uno? Da musst Du mal den Entwickler der GRBL Software kontaktieren, bezw. in den GRBL Foren nachsehen. Oder wenn Du in C++ fit bist den Source Code der GRBL Software ändern. Gruss Ulrich Albert
Andreas H schrieb: > Abgesehen davon hab ich eine Frage zum Unterschied Uno zu Nano und Grbl. > Die Pinbelegung zeigt ja beim Uno das z.B. für die X Achse Step und Dir > auf den Pins 2 und 5 liegen. > https://github.com/grbl/grbl/wiki/Connecting-Grbl > Wenn ich nun den Nano verwenden will, sind Step und Dir aber auf den > Pins 2 und 3. Beim gleichen Hex File und auch bei deinem Testaufbau im > ersten Bild so zu sehen (wenn ich es richtig interpretiere). > > Hast du eine Idee wie man am Nano zur gleichen Pinbelegung kommt wie am > Uno? Die Pinbelegung bei GRBL ist in allen Varianten gleich. Die Stepper werden immer !!! an dem Port D angeschlossen von PD.2 - PD.7 oder Audrinoseitig an Digital D2 bis D7. Wo die Pins an der Platine ausgeführt sind musst Du selbst finden. Waldemar
Vielen Dank für eure Mühe, ich habe das ganze Wochenende damit verbracht diverse Foren wegen der Pinbelegung zu durchstöbern, leider hat es nicht die erhoffte Erleuchtung gebracht.. Es ist auch nicht sehr tragisch, mir ist halt aufgefallen das auch hier im ersten Testaufbau Step und Dir pro Achse nebeneinander liegen was ja nicht der aktuellen Grbl Pinbelegung entspricht. Das für mich faszinierende ist halt das die Belegung wie sie in der cpu_map.h definiert ist, beim Uno das erwartete Ergebnis bringt, nicht aber beim Nano. Obwohl beide den ATMEGA328P verwenden. Vielleicht liegt es auch daran das der Nano ein Clone ist der sich da eigen verhält. Da muss ich noch etwas testen. Wie gesagt, nicht sehr tragisch. Ich verwende halt den Uno und fertig. Auf alle Fälle nochmal danke Andreas
Betr. Fehlermeldung "Connection Error" Ich bin jetzt mal der Ursache auf den Grund gegangen und habe folgendes festgestellt: Die Port-Auswahlbox zeigt alle angeschlossenen Devices (Portnummern) an. Daraus selectiert man dann den gewünschten Port und die Connection funktioniert. Wenn nur ein einziges serielles Device angeschlossen ist, zeigt die Port-Auswahlbox auch nur dieses an. Betätigt man nun den Connect-Button ohne den angezeigten Port expliziert zu selectieren, erscheint die Fehlermeldung "Connection Error". Es ist also notwendig den angezeigten Port expliziert mit der Mouse zu selectieren, auch wenn nur ein Port angezeigt wird. Mir ist das bisher nicht aufgefallen, da ich immer zwei zusätzliche virtuelle Ports (von com0com Nullmodem) aktiviert habe und ich so den Arduino Port immer mit der Mouse selectieren musste. Ich schaue mal für die nächste Version wie man das Verhalten der Port-Selectionsbox passend ändern kann. Bis dahin eben den angezeigten Port einfach vor dem Connect per Mouse selektieren. Im übrigen habe ich beim Test mit mehreren Arduino Uno's und Nano's bemerkt, dass einige nicht immer beim Anschluss im Windows Gerätemanager erscheinen, sondern erst nach mehrfachen Einstecken des USB-Kabels. Das ist allerdings dann ein Problem der Arduino Hardware. Insbesondere tritt dieses Verhalten bei den billigen China Clones auf, die original Arduino Uno's connecten immer auf Anhieb. Gruss Ulrich Albert
Ah, ja so geht's auch bei mir. danke Andreas
Anbei SerialComCNC Version 0.5a Change Log V0.5a ---------------- Angezeigter Port wird jetzt auch ohne Mouse-Selektion übernommen. Bei der manuellen Steuerung wird bei Click auf "Home" (X0 Y0 Z0) jetzt zuerst die Z-Achse auf die Home Position gefahren (Z0 + eingestelltem Offset) und dann erst die X- und Y-Achse. Das vermeidet einen eventuellen Crash des Fräsers mit der Oberfläche des Werkstückes. Gruss Ulrich Albert Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/ Link zu meinem Project SerialComInstruments: Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"
Hallo , ich habe eben diesen Beitrag gesehen und finde das Projekt super . Es wird immer von Stepperansteuerung gesprochen gehen auch Servoendstufen mit Schritt und Richtungssignal ? Das hex-File hat 77kb , wie gehen die in den ATMega 328 mit 32kB ? MfG Hans
Hallo Hans, ein hex-Datei ist keine Binär-Datei und somit unterscheiden sich die Dateilängen. Was eine (Intel) hex-Datei sagt dir das De-Wiki.
Hans Lang schrieb: > gehen auch Servoendstufen > mit Schritt und Richtungssignal ? Da viele Anbieter von Servoendstufen in den Beschreibungen angeben "kompatibel mit CNC-Steuerungen" denke ich mal das geht. Aber Versuch macht klug :)
Neues Feature Was haltet ihr von einer neuen Funktion um schnell präzise Löcher zu bohren? Und zwar ohne vorher Zeichnungs- und CAM-Software benutzen zu müssen. Also nur Eingabe der Koordinaten und Bohrtiefe, event. auch eine editierbare Liste, vielleicht auch lesbar aus z.B. einem Exel Sheet.
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
Hallo Albert, schön wäre die Verarbeitung von Excellon Dateien. Damit ließen sich Platinen komfortabel bohren. Man brauchte eine Funktion zum Ausrichten der Platine z.B. über zwei Eckbohrungen. Dann zum Festlegen der Z-Verfahrebene und der Bohrtiefe. Nach Abarbeitung der Koordinaten für ein Tool sollte die X-Achse angehoben und auf den Werkzeugwechsel gewartet werden. Vielen Dank dass du deine Super-Programme der Community zur Verfügung stellst! Gruß Einhart
In der neuen c't Hacks wird auch ein GBRL-Frontend vorstellt. Ich hatte allerdings noch keine Zeit den Artikel zu lesen. Hat sich schon jemand die Software angesehen? Mit freundlichen Grüßen Thorsten Ostermann
Hi Thorsten, das Frontend aus der c't Hacks ist in erster Linie für deren GRBL Router mit Jogger gedacht, eine komplette Eigenentwicklung von c't mit anderem Prozessor... Natürlich kann man das Frontend anpassen, ich versuche gerade die Sourcen in Lazarus zu überführen um es evtl. für mich zu nutzen, da ich den 'normalen' 0.9 GRBL Code nutze. Da es in Delphi 2005 geschrieben wurde, könnte Albert eine Anpassung für den seriellen Port einbauen, es läuft nur mit der FTDI-DLL. Mich reizt die Funktionalität mit Kamera und Referenzpunktsuche... Mit einem einfachen GCode Sender hat die c't Anwendung nichts mehr gemeinsam. Michael
Einhart Pape schrieb: > schön wäre die Verarbeitung von Excellon Dateien. Damit ließen sich > Platinen komfortabel bohren. Das Excellon Format für die Bohrdaten werde ich mir mal ansehen. Michael W. schrieb: > Mich reizt die Funktionalität mit Kamera und Referenzpunktsuche Kamera-Einbindung für Referenzpunkt-Einstellung kann ich meinem Programm auch verpassen, auch wenn es vielleicht nur eine Spielerei ist. Ich habe den Artikel in der CT kurz überflogen und werde mir den mal in den nächsten Tagen genau ansehen. Was ich aber bereits jetzt dazu sagen kann: Das ganze Werk ersetzt keinesfall die herkömmliche Methode mit ordentlicher Zeichnung und G-Code Erzeugung mittels Cam-Software. Nirgendwo kann ich die notwendigen diversen Einstell- und Konfigurationsmöglichkeiten einer Cam-Software erkennen, wie sie z.B. in Filou oder sogar im kostengünstigen Estlcam vorhanden sind. Also, ich möchte mit der CT-Lösung kein präzises Werkstück erstellen und ich denke mal, dass ist auch garnicht deren Intension. Michael W. schrieb: > Da es in Delphi 2005 geschrieben > wurde, könnte Albert eine Anpassung für den seriellen Port einbauen, es > läuft nur mit der FTDI-DLL. Nö, ich werkele grundsätzlich nicht in anderen Leutz Softwerken rum. Einen wirklichen Vorteil kann ich in der CT-Lösung mit der FTDI-DLL auch nicht erkennen. Damit macht man sich nur von FTDI abhängig und gewinnt wenig. Gruss Ulrich Albert
Angehängte Dateien:
> Michael W. schrieb: > Mich reizt die Funktionalität mit Kamera und Referenzpunktsuche Ich habe inzwischen mal kurz die Video-Anbindung für die Referenzpunkt-Einstellung implementiert. Das müsste mit allen gängigen Web-Cams funktionieren. In das Videobild wird ein Fadenkreuz und ein grössenverstellbarer Kreis im Mittelpunkt eingeblendet, die Strichstärke von Fadenkreuz und Kreis ist ebenso wie die Farbe einstellbar. Die Web-Cam wird neben dem Fräskopf mit Blick genau senkrecht nach unten befestigt. Kalibriert wird einmalig indem man das Fadenkreuz auf den Werkstück-Nullpunkt fährt, XY in der Software auf Null setzt und anschliessend, am besten mit einer Nadel im Bohrfutter manuell auf den Nullpunkt verfährt. Die angezeigten XY Werte werden jetzt als Offset gespeichert. Beim nächsten Start des Programms werden diese Offset-Werte wieder bei der optischen Nullpunkteinstellung verwendet. Leider kann ich euch dazu kein besonders schönes Bild zeigen, da meine Web-Cam keine manuelle Schärfeeinstellung hat und im Nahbereich nichts taugt. Deshalb im Bild oben ein weisses Blatt als Hintergrund :) Die neue Version wird vielleicht in der nächsten Woche bereits fertig sein.
Angehängte Dateien:
-
SerialComCNC_v0.6.jpg
380 KB
Anbei SerialComCNC Version 0.6 Change Log V0.6 --------------- Video/WebCam zur optischen Nullpunkt-Einstellung implementiert. Die Anleitung ist unter Hilfe zu finden. Ich bitte um Rückmeldung, da ich hier zur Zeit keine Testmöglichkeit mit meiner Fräse habe. Und sorry, meine Webcam liefert wegen der fehlenden Einstellmöglichkeit im Nahbereich nur unscharfe Bilder.
Einwandfreie Sache ! Vielen Dank für deine Arbeit. Ich könnte sowas nicht.... Und passend zum Wochenende. Da werden sicher viele Leute Zeit zum Testen haben. Gut gemacht !
Hello Gibtes eine version für den Raspberry ? Besten Dank für ein antwort PS meine Mutersprache ist französich ich komme aus der Schweiz.
Hi, coole Sache. Man kann den Kameraoffset vielleicht auch einfacher einstellen: mit einem feinen Fräser ein Loch in eine Opferplatte fräsen und dann den Fräskopf soweit bewegen, bis des Fadenkreuz im Videobild im Zentrum des Bohrlochs liegt. Mir ist die Positionierung des Fräskopfes mit eingespanntem Werkzeug immer zu schwierig, jedenfalls auf Zehntel, geschweige denn Hundertstel genau, daher nutze ich lieber die obige Methode. Besten Dank nochmal für Deine Mühe. Michael
Daniel Devaux schrieb: > Gibt es eine version für den Raspberry ? Google mal nach GRBL+Raspberry, muss dann allerdings GRBL 0.9g sein. Mein Programm gibt es nur in der vorliegenden Windows Version. Michael W. schrieb: > Man kann den Kameraoffset vielleicht auch einfacher einstellen Guter Tip, Michael!
Albert, nach längerer 'Abstinenz' bin ich grade mal wieder auf meiner 'grbl'-Tour um mich wieder auf Stand zu bringen und ich muss sagen, daß ich ziemlich beeindruckt bin! Besonders die Tatsache, daß SerialComCNC ohne Installation auszukommen scheint, macht die Software schön flexibel. Die Geschichte mit der WebCam mag vielleicht anfänglich wie Spielerei anmuten, hat aber in jedem Fall besonders bei nicht so präzisen Maschinen und/oder Bearbeitungen mit nicht so engen Toleranzen ihre Berechtigung und spart durch die Unabhängigkeit vom eingespannten Werkzeg Zeit beim Einrichten. Alles in allem eine sehr gelungene und erstklassige Alternative zu anderen grbl-Frontends, vielen Dank! Ich bin bestimmt nicht der einzige, der schon jetzt auf die nächste Version und die nächsten Features gespannt ist... Respekt auch für die anderen Projekte auf Deiner Homepage. Die SerialConInstruments sehen auch sehr interessant aus. Wenn der Tag doch nur mehr Stunden hätte...! Besten Gruß Piter
Albert M. schrieb: > Einhart Pape schrieb: >> schön wäre die Verarbeitung von Excellon Dateien. Damit ließen sich >> Platinen komfortabel bohren. > > Das Excellon Format für die Bohrdaten werde ich mir mal ansehen. > Hallo, schau dir mal Beitrag "Re: CNC-Fräse im Selbstbau" an, excellon sowie excellon2 .
Hallo Ulrich Albert, als stolzer Besitzer einer Eigenbau-Fräse und dem Arduino mit GRBL bin ich zur Zeit auf der Suche nach einer Bezugsquelle für den TinyG. Dabei bin ich zufällig auf 'Deine' Seite geraten. Dabei habe ich erstaunt festgestellt, daß wir beide zur gleichen Zeit am selben Thema 'schrauben'. Respekt, was du in so kurzer Zeit auf die Beine gestellt hast. Ich glaube das beurteilen zu können weil mir viele deiner geschilderten Probleme, wie z.B. das Rücksender der Achspositionen mit '?' sehr bekannt sind. Bin mit meiner Lösung übrigens immer noch unzufrieden. Auch beneide ich dich um deine Fans, die dich mit guten praktischen Ideen nahezu überschütten. Eine Software ist am Ende immer so gut wie ihre Tester. Ich werde in Zukunft diese Seite immer mal wieder aufsuchen, um mich ein wenig von euch inspirieren zu lassen. Falls du auch mal Lust haben solltest andere Ideen, Anregungen oder verbesserbare- oder schlechte Beispiele zum Thema Grbl-Drumrum-Programme zu sehen, schau doch mal auf meine Baustelle: http://www.shapeoko.com/forum/viewtopic.php?f=6&t=4710&start=10 Da gibt es auch ein Filmchen und meinen 1. Versuch einer Bedienungsanleitung. Gruß + weiter viel Erfolg GrblGru
@ GrblGru Leider bekomme ich Deine Software nicht wirklich zum Laufen. Es treten unregelmässige Exceptions auf. Trotz Installationsprogramm ist eine Installation nur im Windows Programm Ordner möglich. Ansonsten sieht die 3-D Darstellung geil aus. Ich wünsche Dir auch noch viel Spass und Erfolg bei der weiteren Entwicklung. Gruss Ulrich Albert
Angehängte Dateien:
-
SerialComCNC_v0.7_Bild1.jpg
270 KB
Anbei SerialComCNC Version 0.7 Change Log V0.7 --------------- Excellon Bohrdaten Import (drl Text-Files). Das importierte Excellon-File wird mit einstellbaren Parametern in G-Code transformiert. Das Excellon-File muss dabei die Koordinaten in Millimetern mit Dezimalpunkt als Komma anbieten. Diese Einstellung dürfte eigentlich in allen Platinen Layout Programmen möglich sein. Das importierte Excellon-File als auch der erzeugte G-Code ist editierbar. Ich werde mal schauen, ob für die nächsten Version eine Möglichkeit für einen/mehrere manuelle Werkzeugwechsel besteht, obwohl das durch GRBL nicht direkt unterstützt wird. Eine Weg-Optimierung (Travelling Salesman), falls notwendig, kommt in einer der nächsten Versionen. Gruss Ulrich Albert Link zu meiner Projekt-Homepage: http://www.serialcominstruments.com/
Du bist wirklich von der schnellen Truppe Ulrich Albert! Ich bin wirklich beindruckt. Herzlichen Dank dafür. Gruß Einhart
Anbei SerialComCNC Version 0.7a Change Log V0.7a ---------------- Funktionen für manuellen Werkzeugwechsel implementiert. Optional werden im G-Code (gilt natürlich auch für konvertierte Excellon Files) die Befehle Txx für den Werkzeugwechsel erkannt. Die Maschine fährt auf eine wählbare Z-Höhe und dann auf die X und Y Null-Position (kann später event. noch wählbar gemacht werden). Nach dem manuellen Werkzeugwechsel wird auf die letzte Bearbeitungsposition zurückgefahren und der G-Code weiter abgearbeitet. Im Programm muss für diese Funktion "Use Tool Change Txx" markiert werden und bei Verwendung von Excellon Files im Konvertierungsfenster ebenfalls "Use Tool Change" markiert sein. Die Wechselhöhe wird unter Settings eingestellt und bleibt persistent (im ini-File). Zusätzlich wurden einige Bugs behoben. Gruss Ulrich Albert
Waldemar P. schrieb: > Ich selbst benutze GRBL bei meiner Platinenfräse dazu > Konvertiere ich die Exellon Bohrdaten ( DRL ) und HP-Plotdaten ( PLT ) > zur G-Code um die Fräse mit Daten zu füttern. Als Vorschlag zu späterem > Zeitpunkt, so eine zusätzliche Implementierung der Funktionen, wird > bestimmt vielen Usern nützlich sein. Da die meisten hier mit > Elektronikbasteleien am werkeln sind. Das habe ich vor 2 Monaten geschrieben, und sehe da die erste Routine ist implementiert.Ich bin begeistert und beeindruckt von diesem Program. Noch eine Routine für HPGL um den angeschlossenen Geräten bei Fräsen von Platinen und Frontplatten auf die Sprünge zu helfen Dann ist der „ Meisterwerk “ perfekt. Schöne Grüsse Waldemar
Danke für das faszinierende Frontend ! Wenn da alle Vorschläge machen , hab ich auch einen. Dieser würde dann ein defacto Alleinstellungsmerkmal sein für dein Programm. Schau dir mal Visolate an bei Github. Das generiert aus Gerberdateien fürs PCB-Fräsen sogenannte Voronoi-Toolpaths Auch ein Linuxprog pcb2gcode macht das gleiche, nur alles unkomfortabel. Nicht jeder ist firm mit Linux und Java.... Danke für deine Mühen.
Event. Fehler in der "Tool Change Funktion" in Version 0.7a Bei mir treten jetzt sporadisch Fehler bei Verwendung der Tool Change Funktion auf: "bad number format". Die Ursache konnte ich noch nicht entdecken, da im G-Code vordergründig zuerst mal alles normal aussieht. Vielleich läuft bei der Übertragung was schief. Ich kann mich leider erst nächste Woche darum kümmern. Bitte bis dahin diese Funktion nicht benutzen, da nach der Fehlermeldung weitere Koordinaten event. nicht richtig übernommen werden. Fräser schrieb: > Schau dir mal Visolate an bei Github. Das generiert aus Gerberdateien > fürs PCB-Fräsen sogenannte Voronoi-Toolpaths So weit ich weiss bieten diese Funktion (Isolations-Fräsen) doch inzwischen alle Platinen-Layout Programme direkt an und geben die Daten im HPGL-Format aus. Das kann sogar Sprint Layout. Es wäre also nur das HPGL-Format in G-Code zu wandeln.
Fräser schrieb: > Das generiert aus Gerberdateien > fürs PCB-Fräsen sogenannte Voronoi-Toolpaths Er meint damit nicht die üblichen Isolationsbahnen, sondern speziell optimierte. Schau dir das mal an : http://runcnc.files.wordpress.com/2010/11/dsc_3056.jpg So eine Möglichkeit würde mich auch sehr interessieren. Danke für dein Programm !
Albert M. schrieb: > Fehler in der "Tool Change Funktion" in Version 0.7a Ich habe den Fehler gefunden. Die "Tool Change Funktion" wird komplett überarbeitet, die korrigierte Version kommt in den nächsten Tagen. Fräser schrieb: > Schau dir mal Visolate an bei Github. Das generiert aus Gerberdateien > fürs PCB-Fräsen sogenannte Voronoi-Toolpaths Das ist mir zu aufwändig, da sollten die normalen Isolations-Fräsdaten reichen.
ist es machbar, richtigen Gcode zu erzeugen. Nicht nur Txx, sondern auch m6 und im Gcode, wenn Txx vorkommt, dies einfach speichern, und bei m6 wenn dies vom programm selbst geparst wird, sollte konfigurierbar sein, dann die entsprechende Aktion ausloesen. Txx is nur ein Toolwechsel, der richtige toolwechsel ist m6, was eigentlich ein m6P=xx ist. Nur weil historisch bedingt, wurde das auf T und m6 beschraenkt. Grund war oder ist, dass bei gewissen maschinen ein Revolverkopf das Werkzeig zur Wechselposition bringt. Dies braucht eine gewisse Zeit. So kann man T3 m6 T8 (vorbereitung fuer kommenden Werkzeugwechsel) G1... ... m6 (ladet T8 ohne auf den Revolverkopf zu warten) T4 (vorbereitung ...) Auch eine (MSG, CHANGE TOOL TO xx) kann sinnvoll sein. Gruss Chris
chris schrieb: > ist es machbar, richtigen Gcode zu erzeugen. > Nicht nur Txx, sondern auch m6 .... Leider bietet GRBL keine Funktionen für autom. oder manuellen Toolwechsel an ( https://github.com/grbl/grbl/wiki ). Deshalb auch meine Klimmzüge im Programm um zumindest einen manuellen Toolwechsel nachzubilden. Einen autom. Toolwechsel werde ich nicht programmieren, da wohl kaum jemand hobbymässig solche CNC-Maschinen zuhause stehen hat. chris schrieb: > Auch eine (MSG, CHANGE TOOL TO xx) kann sinnvoll sein. Das lässt sich implementieren.
Albert M. schrieb: > da wohl kaum > jemand hobbymässig solche CNC-Maschinen zuhause stehen hat. Das nicht.... aber an solchen Maschinen wird EMC oder Mach3 verbreiteter sein.
> Leider bietet GRBL keine Funktionen für autom. oder manuellen > Toolwechsel an ( https://github.com/grbl/grbl/wiki ). Deshalb auch meine > Klimmzüge im Programm um zumindest einen manuellen Toolwechsel > nachzubilden. > Einen autom. Toolwechsel werde ich nicht programmieren, da wohl kaum > jemand hobbymässig solche CNC-Maschinen zuhause stehen hat. > Schon klar, auch wenn ich diese Klimmzuege problematisch ansehe. Was ich vorschlagen wollte, Txx -> speichert Werkzeug M6 -> Unterbricht programm, und macht folgendes, auf jeden Falle werden die Zeilen danach nicht im gbrl gebuffert: optional sendet M5 (spindle stop) optional sendet G4P=... (dwell pause time) wartet auf ok. sendet ? zu GBRL und speichert Position A sendet G53G0Z0 wartet auf ok sendet ? zu GBRL und speichert Position B wenn A == B, dann sende G90 sendet G53G0Z0 wenn wechselpos xx sowie yy nicht -1 ist, dann sendet G53G0XxxYyy wechselposition. warte bis Benutzer ok drueckt. jogging sollte machbar sein. sendet G53G0Z0 sendet G53G0XaxYay pos aus Variable a sendet G53G0Zaz pos aus variable a wenn A == B dann sende G91 das wars. Spindle stop/start sollte noch irgendwie beachtet werden, kann aber auch nur ueber buttons gemacht werden. Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. Dann waere auch ein normales Gcode Program mit Werkzeugwechsel machbar und auch nur das eventuelle copieren vom Gcode und ausfuehren mit emc oder mach3 z.B. > chris schrieb: >> Auch eine (MSG, CHANGE TOOL TO xx) kann sinnvoll sein. > > Das lässt sich implementieren.
> Schon klar, auch wenn ich diese Klimmzuege problematisch ansehe.
Was ich damit meinte ist, einfach an eine Wechselposition xy zu fahren,
unabhaengig sowie ev. ohne relativ/absolute Koordinaten zu
beruecksichtigen.
nach dem Jogging sollte nochmal zur Sicherheit ein G90 gesendet werden.
chris schrieb: > M6 -> Unterbricht programm M6 wird von GRBL nicht unterstützt, es lässt sich aber M0 verwenden. chris schrieb: > Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. Eben nicht, siehe im Thread weiter oben. Das Problem bei GRBL ist, dass immer mehrere G-Code Befehle in einen Puffer gelesen werden. Welchen Befehl der Processor aber gerade tatsächlich abarbeitet ist nicht mit irgendwelchen Statusmeldungen verknüft, es werden lediglich auf Anforderung die jeweilig aktuellen Koordinaten ausgegeben. Es gibt Workarrounds, aber die sind alle mehr oder weniger fehlerträchtig. Ich habe aber so weit eine Lösung gefunden, die Deiner oben skizzierten Befehlfolge ähnelt.
Albert M. schrieb: > chris schrieb: >> M6 -> Unterbricht programm Ich meinte damit in deinem Code, und dass dann nichts weitergesendet wird, bis eben alles abgearbeitet wurde. Dies liese sich mittels '?' sogar abfragen. // Returns the number of active blocks are in the planner buffer. if (bit_istrue(settings.status_report_mask,BITFLAG_RT_STATUS_PLANNER_BUFFER )) { printPgmString(PSTR(",Buf:")); print_uint8_base10(plan_get_block_buffer_count()); } > > M6 wird von GRBL nicht unterstützt, es lässt sich aber M0 verwenden. > Nicht wirklich. Es waere aber kein Problem M6 einzufuegen, dazu braucht es nur 4+ kleine Aenderungen. T wird ja bereits unterstuetzt und normalerweise auch zum Auswahl des externen Motor MUX verwendet fuer den pulse ausgang. Funktioniert aber nur, wenn dann das Jogging ueber $J geht, ansonsten no go, oder eben wenn M6 uebertragungsende heisst und in m0 umgewandelt wird, wobei mir die letztere Loesung mehr gefaellt. > chris schrieb: >> Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. > Doch , mit $G bekommt man raus, inch/mm sowie G90/91 und eben auch M3/M4/M5. Wenn interesse besteht, fuege ich dir m6 rein, aber M0 unter SW control ist besser, da man dann nicht $J verwenden muss.
chris schrieb: >> chris schrieb: >>> Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. >> > Doch , mit $G bekommt man raus, inch/mm sowie G90/91 und eben auch > M3/M4/M5. Ich kenne die GRBL Kommandos :) $G hilft aber bei der Problemstellung nicht weiter. chris schrieb: >> M6 wird von GRBL nicht unterstützt, es lässt sich aber M0 verwenden. >> > Nicht wirklich. Doch, ich habe inzwischen Tests mit M0 vorgenommen und das funktioniert problemlos. Es mag ja sein, dass M0 auf grossen Profi-CNC's aus irgendwelchen Gründen nicht optimal ist, für Hobbygeräte und nur dafür ist meine Software gedacht, spielt das aber keine Rolle. Meine neue Implementation wird so aussehen: Kommt im G- oder Excellon-Code ein Txx (Werkzeugwechsel) vor, so wird optional in den Code automatisch ein M0 eingefügt. Beim Maschinenlauf wird dann an dieser Stelle angehalten, XYZ auf eine Wechsel/Null-Position gefahren und eine Meldung über die geforderte Werkzeugnummer xx ausgegeben. Nach Werkzeugwechsel wird auf die ursprüngliche Position zurückgefahren und der Code weiter abgearbeitet. Das funktioniert soweit, bedarf aber noch weiterer Tests. chris schrieb: > Wenn interesse besteht, fuege ich dir m6 rein Danke, aber Änderungen im GRBL Source Code wurden oben bereits diskutiert und ich habe mich dagegen entschieden. Bei einer Modifikation müsste ich bei neuen GRBL-Versionen die vorgenommenen Änderungen jedesmal neu einfügen/supporten. Und meine Software wäre dann jeweils nur mit modifizierten GRBL-Versionen lauffähig. Zudem habe ich keine Lust auf 2 Baustellen zu werkeln. Das Projekt fängt eh schon an auszuarten. Eigentlich wollte ich nur ein Mini-Tool für eigene Bedürfnisse für meine Käsefräse entwickeln um hier und da mal ein wenig rumzufräsen.
Ok. So wie ich es Kenne wird beim manuellem Werkzeugwechsel nur z auf g53 null gefahren. Dann kann man manuell die POS andern und auch z.b g92 für Werkzeug offset usw. Bei m0 kann man nicht mehr manuell verfahren, da geht nur warten oder weiter. Deshalb geht m0 anstelle von m6 nicht so gut . Es ist aber eine einfache Lösung. Mit einer Wechselposition geht es, nur wenn man Zwingen oder so hat, um das Werkzeug festzuhalten, dann ist so eine Wechselpos. Kritisch. Bei Platinen ist sowas nicht so kritisch. Es wäre aber schön wenn auch anderen code als Platine gestreamt werden kann und dabei der Werkzeugwechsel funktioniert. Muss aber nicht sein.
Albert M. schrieb: > chris schrieb: >>> chris schrieb: >>>> Irgendwie sollte das doch ueber so eine Statusmessage abfragbar sein. >> Doch , mit $G bekommt man raus, inch/mm sowie G90/91 und eben auch >> M3/M4/M5. > > Ich kenne die GRBL Kommandos :) > $G hilft aber bei der Problemstellung nicht weiter. Ich meinte hier den Status von m3/4/5 Der Motor sollte ja auch abgeschaltet werden und dann wieder eingeschaltet.
Hallo, bin Einsteiger in Hobby CNC und bin kürzlich auf diesen Thread gestoßen. Zunächst mal große Anerkennung für die Leistung! Habe natürlich das Programm sofort auf meinen Arduino mit grbl losgelassen. Leider habe ich derzeit noch keine Schrittmotortreiber.... Mir ist aber was aufgefallen, das ich hier berichten möchte: - Wenn man den COM Port verbindet meldet das Programm, daß die Verbindung steht tatsächlich beginnt der Datenverkehr aber erst nachdem man OK geklickt hat. - Aus Versehen habe ich den COM Port des Arduino Programmers angegeben. Der hat offensichtlich geantwortet und dann sind hunderte Meldungsfenster am PC aufgegangen. Nun - ich mußte das Programm abschießen.... Bitte das nicht als Kritik verstehen! Wollte das nur melden ... vielleicht ist ja der Bugfix gerade mal eine Codezeile Aufwand. Grüße Johannes
Johannes schrieb: > Aus Versehen habe ich den COM Port des Arduino Programmers angegeben. > Der hat offensichtlich geantwortet und dann sind hunderte > Meldungsfenster am PC aufgegangen Danke für die Info, der Fehler ist mir bekannt und wird in der nächsten Version behoben. Ausserdem, Behandlung von Werkzeugwechseln (Fehler in der letzten Version): Eine passende Behandlung von Werkzeugwechseln nach den jeweiligen Txx G-Code Befehlen ist mit GRBL anscheinend doch nicht so trivial wie gedacht und bedarf noch einiger Tage. Einen Guten Rutsch ins neue Jahr Ulrich Albert
Angehängte Dateien:
-
SerialComCNC_0.7b.jpg
320 KB
Anbei SerialComCNC Version 0.7b Change Log V0.7b ---------------- Bei mehreren angezeigten Com-Ports wird jetzt geprüft ob bei der gewählten Verbindung GRBL antwortet. Falls nicht, wird die Verbindung geschlossen und eine Meldung angezeigt. Es wird nun eine Unterbrechung der Com-Verbindung während des laufenden Betriebes erkannt und eine Warn-Meldung ausgegeben. Es ist ein Neustart des Programms notwendig. Änderungen / Fehler-Behebung im "Use Tool Change" Mode: Wenn Werkzeugwechsel "Use Tool Change" aktiviert ist, wird der jeweils nächste bevorstehende Werkzeugwechsel im Monitor-Fenster incl. der Werzeugnummer Txx angezeigt. Wenn im Programmfluss Txx erreicht wird, wird das GRBL-Programm mittels intern eingefügtem M0 angehalten, die aktuelle Position gespeichert und die Z-Achse um 20 mm hochgefahren. Es muss abgewartet werden bis im Process Display "Idle" angezeigt wird. Über die Bedienbuttons im Manual Process Fenster können die Achsen jetzt beliebig verfahren werden, um eine optimale Position zum Werkzeugwechsel zu erreichen. Nach dem Werkzeugwechsel wird zum Fortfahren der Button "Cont" im Process Display betätigt. Die X- und Y-Achsen und danach die Z-Achse werden nun auf die gespeicherte Position zurück gefahren und das G-Code Programm fortgesetzt. Programm-Ende G-Code Commando M30: Das G-Code Commando M30 wird erkannt, jedoch in SerialComCNC nicht mehr in GRBL zur Ausführung gebracht. Der Grund ist folgender: M30 bewirkt in GRBL nicht nur die Beendigung der Bearbeitung, sondern leider auch ein Reset. Damit werden die aktuellen Achsen-Positionen mit irgendwelchen Werten überschrieben und es müsste eine erneute Werkstück Nullpunktbestimmung durchgeführt werden (dies betrifft die Welt-Koordinaten mit denen SerialComCNC arbeitet). Die interne Unterdrückung von M30 hat ansonsten keinerlei Nachteile. Beim Erreichen von M30 können die Achsen über den neuen Nullpunkt-Button im Process Display auf den XYZ-Nullpunkt zurückgefahren werden.
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
Daniel S. schrieb: > Bestrome ich das System läuft es sauber an und beginnt auch zu fräsen > aber irgendwann (nach 1 oder 2 min) kommt die Fehlermeldung > writefile communication failure Error:31 Ich habe bei mir Langzeittests gemacht, der beschriebene Fehler tritt dabei nicht auf. Ich denke, dass die Ursache ein EMV Problem Deiner Beschaltung ist. Fräse und Arduino sollten je eine eigene Stromversorgung haben. Die Stepper-Driver möglichst galvanisch getrennt (über Optokoppler) mit dem Arduino verbinden. Möglichst kurze Verbindungen verwenden, usw. So sieht das zumindest bei mir aus und da läuft es problemlos.
Hallo und danke für das Projekt. Albert M. schrieb: > die aktuelle Position > gespeichert und die Z-Achse um 20 mm hochgefahren Kann man diesen Weg von 20mm einstellbar machen ? Die Z-Achse meiner Platinen-Bohrmaschine erlaubt leider nur max. 15mm Vielen Dank
ein erfreuter Benutzer schrieb: >> die aktuelle Position gespeichert und die Z-Achse um 20 mm hochgefahren > > Kann man diesen Weg von 20mm einstellbar machen ? > Die Z-Achse meiner Platinen-Bohrmaschine erlaubt leider nur max. 15mm Kein Problem, wird in der nächsten Version implementiert. Entweder dann auf 10 mm geändert oder einstellbar.
Albert M. schrieb: > oder einstellbar Das wäre natürlich optimal. Vielen Dank ! Super - nach Minuten schon eine positive Antwort.
Anbei SerialComCNC Version 0.7c Change Log V0.7c ---------------- Werkzeugwechsel Warte-Position (Tool Change Pos) jetzt frei einstellbar. Die eingestellte Position wird im ini-File gespeichert. Die Video Anzeige (WebCam) ist nun unabhängig von der gewählten Video- Auflösung (Standard 640x480)und wird auf den verfügbaren Anzeigebereich mittig skaliert. Homepage http://www.serialcominstruments.com/
Vielen Dank Ulrich. Jetzt funktioniert der Bohrerwechsel auch bei mir. Macht richtig Spaß. So ein Programm hatte ich mir immer für meine kleine CNC gewünscht.
...wirklich tolles Programm, welches ich an meinem Selbstbaulasergravier betreibe. Um Längen komfortabler als die diversen GCodesender! Klasse, danke dafür !!!
Angehängte Dateien:
-
IMG_5923a.jpg
530 KB -
IMG_5925a.jpg
470 KB
Für die optische Nullpunkteinstellung mittels WebCam habe ich mir einen passenden Adapter für die Proxxon MF70 gefräst. Durch eine 1mm Vertiefung für den Körper der WebCam verruscht diese auch bei heftigen Bewegungen nicht. Durch den leicht konischen Lagerring (oder wie immer man das nennt) der MF70 sitzt die Cam bombenfest durch einfaches Aufschieben.
Hallo, ich bin neu in Sachen CNC, also ich bitte um Nachsicht. Problem: Ich habe eine China Fräse CNC 3040T. Der Controller ist ein Z-DQ mit paralleler Schnittstelle für Mach3 oä. Da ich Mach3 nicht habe und über SerialComCNC nur Gutes gehört habe, würde ich die Fräse gern damit betreiben. Allerdings würde ich den Controller ungern rausschmeißen. Kann ich SerialComCNC über einen geeigneten Konverter an meinem parallelen MACH3 Kontrolle betreiben? Ein paar Arduino hab ich auch rumliegen. Kann mich jemand in die richtige Richtung schubsen? Vielen Dank P.S. Also, dass ich GRBL auf den Arduino bringen muss, hab ich soweit verstanden. Was ich diesbezüglich so gesehen habe, steuert der Arduino die Motorkontroller dann direkt an. Ich will aber vom Arduino auf die parallele vom Mach3 Controller
Hallo Reiner, Du hast ein an deiner CNC höchst wahrscheinlich kein Controller sondern nur Motorsteuerung mit Endstufen die durch Parallelport angesteuert werden können. Zum Betrieb der CnC brauchst Du eben ein Controller, entweder ein PC mit Mach3, WinCNC oder PC-NC oder ein Controller wie eben GRBL auf einem Arduino. Du Kannst auf dem Arduino den GRBL aufspielen und die Signalports des Arduino mit dem Parallelanschluss der Motorsteuerung verbinden.
Vielen Dank Waldemar. Auf so eine Antwort habe ich gehofft;-) Da mach ich mich mal an die Arbeit.
Angehängte Dateien:
-
20150115_125422.jpg
220 KB
Hello, sorry for disturbing this German speaking forum, but there is no english speaking forum about this nice project SerialCOM CNC! Many Thanks Ulrich!!! I would like share my project, a expansion board for Arduino UNO + GRBL v0.9g. This board have more features, I will start production of PCB. I am collecting contacts and interested peoples, simply more peoples = cheaper PCB, and also more people have more good ideas. As example, this board also solve problem with cheaper chinese Arduinos, they halt on USB serial communication with 115200bps. There is serial convertor for that replace. Second thing,I am developing second I/O board with arduino, it will help to connect additional sensors and input/outputs to your cnc. (cooling, water, air, laser, vacuum, lighting, measure something, etc.). GRBL project is not supporting that, but I have idea how simply expand... use same one USB cable, use same one SerialCom CNC software with small extension KPr
Als nächstes habe ich folgende Funktion in Angrfiff genommen:
Werkzeuglängen-Sensor / Probing für die Z-Achse.
Ich teste gerade die in GRBL 0.9g verfügbaren Funktionen
G38.2 : Probing
G43.1 und G49 : Dynamic Tool Length Offsets
Mangels Werkzeuglängen-Sensor benutze ich für das Testen einen einfachen
metallische Kontakt (kupferkaschierte Platine) und fahre den Fräser mit
F1 einfach vorsichtig drauf. Funktioniert erstmal problemlos :)
Taugt dieser Werkzeuglängen-Sensor was?
http://www.ebay.de/itm/Werkzeuglangenmesser-Werkzeuglangensensor-Werkzeugtaster-CNC-Frase-/321380535406?pt=Industriemaschinen&hash=item4ad3c5cc6e
Hallo Albert, voll genial dein projekt. Grüsse Matthias
Hallo Albert, Wie sieht´s den aus mit dem HPGL Implementierung ? Bist Du da schon weiter gekommen ? Das würde das Programm endgültig Richtung Olymp katapultieren. Eine All in One ElektronikBastlerOberfläche für GRBL. Schöne Grüße Waldemar
Waldemar P. schrieb: > Wie sieht´s den aus mit dem HPGL Implementierung ? Ich denke mal, dass ich einen HPGL > G-Code Converter für die nächste Version hinbekomme. Bitte schau Dir mal an, ob ich für die Konvertierung nichts vergessen habe: PA goto Absolute Position (bezogen auf den vorher festgelegten Nullpunkt wie alles in SerialComCNC; nicht auf Maschinen-Koordinaten) PR goto Relative Position PD Spindel down PU Spindel up SP Select pen (Werkzeugwechsel), fraglich ob nötig/zuerst mal nicht Eingabebox: Feedrate für Einstechen Eingabebox: Feedrate für Fräsen Eingabebox: Sicherheitshöhe (Pen up) Eingabebox: Einstechtiefe (Pen down) Eingabebox: Skalierungsfaktor HPGL (Standard ist hier glaube ich 1016) Gruss Ulrich Albert
Hallo Albert, Das hört sich gut an. zur deinen Eingaben: Albert M. schrieb: > Eingabebox: Feedrate für Einstechen > Eingabebox: Feedrate für Fräsen > Eingabebox: Sicherheitshöhe (Pen up) > Eingabebox: Einstechtiefe (Pen down) > Eingabebox: Skalierungsfaktor HPGL (Standard ist hier glaube ich 1016) Noch eine Geschwindigkeit wäre von Vorteil „Freie Fahrt“ das heißt nach einem PD alle PA´s mit Fräsgeschwindigkeit Nach einem PU mit „Freie Fahrt“. Die Einheiten für HPGL sind entweder 1/40 mm oder 1/1000 Zoll im Klartext entweder 0,025 mm oder 0,0254 mm. Die Datei könnte so aussehen: PU; G1Z(oben)F(x) x –Geschwindigkeit Freie Fahrt SP3; ignorieren PA135,176; /40 X3,375Y4,4F(x) PD; Z(unten)F(einstechen) PA148,167; /40 X3,7Y4,175F(fräsen) PA163,164; /40 X4,075Y4,1 PA178,167; /40 X4,45Y4,175 PU; Z(oben)F(heben) PA226,189; /40 X5,65Y4,725F(x) PD; Z(unten)F(einstechen) PA235,176; /40 X5,873Y4,4F(fräsen) PA248,167; /40 X6,2Y4,175 PA263,164; /40 ...... Gruß Waldemar
Moin Albert! Zunächst ganz vielen Dank für die tolle Software! Mir ist ein kleiner Bug aufgefallen, den ich leider nicht exakt reproduzieren kann, allerdings ist er bei mir schon mehrfach aufgetreten. Ich benutze die aktuelle Version von SerialComCNC (0.7c) unter Win7 64 Bit. Wenn ich im Bereich "Manual Process" viel mit den Knöpfen für die Einheiten des Verfahrweges (10/1/0.1/0.01) rumgespielt habe, werden irgendwann alle weiteren Betätigungen dieser Knöpfe ignoriert und es sind nur noch Veränderungen von 1 mm möglich. Auch die Tastatureingabe eines Wertes funktioniert dann nicht mehr. So weit ich bisher sehe, hilft dann nur noch ein Neustart. Ist nicht gar so schlimm das Problem, aber ich dachte ich geb mal Feedback, vielleicht lässt sich der Fehler ja schnell finden und beheben. Viele Grüße Malte
Angehängte Dateien:
-
SerialComCNC_v0.7d.jpg
390 KB
Anbei SerialComCNC Version 0.7d Change Log V0.7d ---------------- HPGL-File (.plt) Import Konverter nach G-Code Unterstützt werden folgende Befehle: PU, PD, PA, PR. Alle sonstige Befehle werden ignoriert. Einstellbare Parameter: Feedrate für Einstechen Feedrate für Fräsen Sicherheitshöhe (Pen up) Einstechtiefe (Pen down) Skalierungsfaktor HPGL (0,025) metrisch @ MTA Danke für die Info.
Hallo Albert, Tolle Leistung Danke !!! Albert M. schrieb: > Einstellbare Parameter: > Feedrate für Einstechen > Feedrate für Fräsen > Sicherheitshöhe (Pen up) > Einstechtiefe (Pen down) > Skalierungsfaktor HPGL (0,025) metrisch Ich habe mir die generierten Daten angeschaut soweit alles gut. In dem Header Sind noch Unstimmigkeiten vorhanden. M3 Spindel EIN G00 Z4.00 Z-Achse Sicherheitshöhe ( Fehlt FeedRate ) G90 X3.375 Y4.400 Fehlt FeedRate Eilgang F200 G01 Z-7.00 Z.Achse Einstechen kein Negativzeichen ( FeedRate Drill fehlt ) F400 unnötig G90 X3.700 Y4.175 Fräsbewegung ( Fehlt FeedRate Milling ) G90 X4.075 Y4.100 ok G00 Z4.00 ok G90 X5.650 Y4.725 Fehlt FeedRate Eilgang F200 G01 Z-7.00 Z.Achse Einstechen kein Negativzeichen ( FeedRate Drill fehlt ) ... ... Meine Fräse hat den 0-Punkt an oberen Anschlag Bewegung nach unten läuft in positive Richtung.( keine Negativkoordinaten ) G01 Z4.00 F400 Sicherheitshöche 4mm G01 Z7.00 F100 Einstechen bis 7mm mit DrillFeed ....... Fräsen G01 Z4.00 F400 Hochfahren Sicherheitshöche ....... Neuen Punkt anfahren G01 Z7.00 F100 Einstechen bis 7mm mit DrillFeed ....... Fräsen Bei Negativbewegten Z-Achse das gleiche mit - Vorzeichen bei Z Jetzt erzeugter Code F200 G01 Z--7.00 Grüße Waldemar
Waldemar P. schrieb: > G00 Z4.00 Z-Achse Sicherheitshöhe ( Fehlt FeedRate ) > G90 X3.375 Y4.400 Fehlt FeedRate Eilgang Erste Zeile: Die Feedrate wird doch bereits durch G00 (in der GRBL-Konfiguration eingestellte max-Rate) bestimmt. G00 = Eilgang = max-Rate Zweite Zeile: Auch hier fehlt der Eilgang nicht, da G00 bezw. G01 jeweils solange im Befehlssatz gültig sind bis sie geändert werden. D.h. das G00 der ersten Zeile ist auch noch in der zweiten Zeile gültig, da hier nichts anderes vereinbart wird. Siehe allgemeine G-Code Konventionen. Waldemar P. schrieb: > Meine Fräse hat den 0-Punkt an oberen Anschlag Bewegung nach unten > läuft in positive Richtung.( keine Negativkoordinaten ) Da musst Du dich schon an die Konventionen von SerialCommCNC halten (siehe auch unter Hilfe). Deiner Fräse kann es egal sein wo der Nullpunkt liegt. Die Konventionen sind: - keine Maschinen-Koordinaten, sondern ausschlieslich Welt-Koord. - der Koordinaten-Ursprung beginnt immer am gesetzten Nullpunkt (Set XYZ Zero). Der sollte sinnigerweise beim Platinen-oder Schriftzug-Fräsen auf der Oberseite des Werkstückes liegen. - vom Nullpunkt ist + immer: X nach rechts, Y nach hinten, Z nach oben - das kann man problemlos mittels $$ anschauen und mit $3=Parameter über die Eingabebox für jede Achse persistent ändern, wenn die CNC-Maschine was anderes macht. Gruss Ulrich Albert
Hallo Albert, M3 Spindel EIN G00 Z4.00 Z-Achse fährt über die Platine G90 X3.375 Y4.400 Fährt zur Startpunkt F200 G01 Z-7.00 Z-Achse fährt auf Endschalter Maschine geht in Störung Bei Z0.000 ist Ende Endschalter ( Homeposition ) Umgestellt auf Negative Koordinaten: M3 Spindel EIN G00 Z-4.00 Z-Achse fährt über die Platine G90 X3.375 Y4.400 Fährt zur Startpunkt F200 G01 Z--7.00 Maschine geht in Störung ( Syntaxfehler ) Waldemar
@ Waldemar Du hast SerialComCNC und die Nullpunkt-Konventionen bis jetzt noch nicht verstanden. Bitte lies Dir meinen obigen Post nochmal durch, versuche den zu verstehen, insbesondere die Achsen-Konventionen und setze das dann auf Deine CNC-Maschine um. Die Achsen sind richtig eingestellt, wenn sie sich bei Betätigung der Pfeil-Tasten in genau diese Richtung bewegen. Ebenfalls empfehle ich Dir das Studium von GRBL und die unterstützten G-Code Befehle: https://github.com/grbl/grbl/wiki Jetzt mal ganz einfach: 1. Die Endschalter sind unerheblich und müssen nicht benutzt werden. 2. Lege das Werkstück/Platine nach X und Y gerade ausgerichtet auf den Frästisch. 3. Fahre den Fräser XY auf den unteren linken Rand der Platine, die Z-Achse fährst Du runter bis das der Fräser das Werkstück/Platine berührt. 4. Betätige die Nullung (Button "Set XYZ Zero"). Ab da ist jetzt für die Z-Achse und die XY-Achsen Null. Z nach oben postiv und nach unten in das Werkstück/Platine hinein negativ. Der XY Nullpunkt sollte mit dem Nullpunkt der Zeichnung/Platinen-Layout übereinstimmen. 5. Starte das in G-Code konvertierte File mit dem "Start File" Button. Und nochmal: Das Ganze hat mit den Maschinen-Koordinaten und Nullung mittels Endschalter absolut NICHTS zu tun. Einfacher geht es doch wirklich nicht. Alles wird gut :) P.S. Im Konvertierungsfenster wird dann der Wert für die Bohrtiefe (Drill Depth) natürlich bei der Eingabe NICHT mit einem negativen Vorzeichen versehen.
Angehängte Dateien:
-
Steuerung1.jpg
240 KB
Hallöchen, ich bin gestern zufällig über dieses Forum gestolpert. Nachdem ich dann mit den "gefühlten" 1000 Beträgen durch war, kam mir als erstes ein "Hut ab" in den Sinn. Super was Du seit September auf die Beine gestellt hast. Auch das Du "Geduld" bei der Beantwortung von Fragen aufbringst (siehe Antwort an Waldemar) hat mich bewogen mich mal mit deiner Software etwas näher zu beschäftigen. Zu mir selber: Ich bin auf dem Gebiet CNC noch blutiger Anfänger. Also gerade mal einen Schritt vom DAU entfernt. Ich weiss auch, dass ich hier noch ein massives Defizit in den Grundkenntnissen habe. Das meine Englischkenntnisse auch nicht gerade die Krönung sind, erleichtert die ganze Angelegenheit wirklich. Und manchmal scheitert die ganze Sache auch nur an "dem Brett vorm Kopp". Ich hab mir dann heute mal den Arduino geschnappt und es auch geschafft das Grbl 0.9g dort draufzubügeln. Ardunio, Schrittmotortreiber und alten Schrittmotor "wild" verkabelt (nur X-Achse). 12Volt angeschlossen, Arduino ans Laptop, Laptop hochgefahren, Programm gestartet, ComPort eingestellt, Connect geklickt, mm 10 eingetragen, Feed mit 150 eingetragen. X-Achse Pfeil nach rechts geklickt. --> Nix Fehlermeldung: error: Undefined feed rate Feed auf 50 reduziert. Neuer Versuch. --> Nix gleiche Fehlermeldung Das war das "Brett vorm Kopp". Man sollte auch auf das "Feed" klicken wenn man einen neuen Wert eingetragen hat. Ich war davon ausgegangen das nach Änderung bei Verlassen des Feldes der Wert automatisch gesetzt wird. Nach Klicken von Feed, nächster Versuch. Begeisterung: Er dreht sich. Das war der erste Schritt :-) Bis zu diesem Schritt hab ich nur eine kleine Sache, die die Funktionalität des Programms in keiner Weise einschränkt aber für mich etwas merkwürdig ist. Bei jedem Start des Programms ist als "DefaultPort" COM3 eingetragen. Wenn ich auf "Connect" klicke dann kommt das InfoFenster "Falscher Comport". Laut Gerätemanger habe ich nur den ComPort4 für den Arduino. Also wechsle ich auf den ComPort4 und klicke Connect. Es kommt das Infofenster "Der ComPort ist jetzt aktiv". Bei erneutem Start des Programms ist wieder der ComPort3 als Default eingetragen. Schön wäre es, wenn der zuletzt gewählte ComPort der Default wäre. Aber ich dann ein wenig weiter getestet. - Programm neu gestartet - ComPort4 ausgewählt - Connect geklickt. Infofenster: "Der Comport ist jetzt aktiv" Jetzt - Disconnect geklickt - ComPort3 ausgewählt - Connect geklickt. Infofenster: "Der Comport ist jetzt aktiv" Natürlich funzt der ComPort nicht. Nächster Schritt bei mir: In der nächsten Woche Material besorgen um die Schrittmotoren an die Proxon zu basteln. Fazit bisher: Ein großartiges Projekt. Ich hoffe nur, dass es für dich nicht "allzusehr ausartet" und Du trotzdem aus dem "Mini-Tool für die eigenen Bedürfnisse" weiterhin ein Tool für uns alle machst und das Projekt lange am Leben hälst.
Edgar R. schrieb: > Bei jedem Start des Programms ist als "DefaultPort" COM3 eingetragen. Beim Start erkennt SerialComCNC alle Ports die bei Windows in Benutzung sind oder waren und nicht mehr freigegeben wurden. Es ist also möglich, dass Du da z.B. als ersten Port COM3 eingetragen hast, andere haben hier jede Menge eingetragen (benutzte, unbenutzte, nicht freigegebene). Wenn Du bei mehreren Einträgen sofort wissen willst welcher der Richtige ist, einfach in der Windows Computerverwaltung/Gerätemanager unter Anschlüsse (COM & LPT) nachsehen welchen Port dein Arduino belegt. Und nur diesen Port kannst Du dann mit SerialComCNC benutzen, bei allen anderen erscheint eine Fehlermeldung.
Angehängte Dateien:
-
Geraetemanger.png
78 KB -
ComPort3.png
110 KB
Hallo Ulrich, danke für die prompte Reaktion. Ich weiss ja, dass ich nur ComPort4 nutzen kann. Behindert ja auch nicht die Funktion. Wäre einfach nur schön wenn er sich diesen beim Beenden des Programms merken würde. Ich fand es nur merkwürdig, dass er ComPort3 einträgt, obwohl es den im Gerätemanager gar nicht gibt. (siehe Bild). Im zweiten Bild kann man sehen, dass man auch eine positive Bestätigung bei ComPort3 bekommen kann, nur funzt der natürlich nicht.
Edgar R. schrieb: > Ich fand es nur merkwürdig, dass er ComPort3 einträgt, obwohl es den im > Gerätemanager gar nicht gibt. (siehe Bild). Für Windows-Probleme ist mein Programm nicht zuständig. Sollten Ports als belegt erscheinen, aber nicht benutzt sein, einfach überschreiben und Windows Fehlermeldung ignorieren. Ansonsten mal selbst die Initiative ergreifen und Google fragen "belegte com ports freigeben", da wird einem geholfen. Edgar R. schrieb: > Im zweiten Bild kann man sehen, dass man auch eine positive Bestätigung > bei ComPort3 bekommen kann, nur funzt der natürlich nicht. Wenn man die Com-Ports mehrere Male kurz hintereinander aktiviert und deaktiviert und ändert und nicht den kompletten Prozess abwartet, mag das mal sein. Das Com-Port Thema ist hiermit für mich beendet, es wurde alles dazu gesagt.
Hallo Albert, erstmal Danke für die Bereitstellung der Software von Dir. Ist echt ein sehr tolles Projekt was Du da in der kurzen Zeit auf die Beine gestellt hast. Habe dazu eine Frage wird es auch einen Import Konverter für .dxf geben. lg
Hallo Albert, auch von mir ein "klasse Projekt/Programm". Ich bin zwar nicht unerfahren im fräsen (seit 1 1/2 Jahren CamBam + Mach3) aber eine Frage hätte ich doch: vielleicht übersehen oder blind .... wo stellt man die Schritte/Fahrweg ein ? Gruss Harry
V. K. schrieb: > eine Frage wird es auch einen Import Konverter für .dxf geben Vorerst nicht. Crazy H. schrieb: > vielleicht übersehen oder blind > .... wo stellt man die Schritte/Fahrweg ein ? Betätige den Button $$, es werden dann im Monitor alle persistenten Einstellungen nummeriert aufgelistet. Die Schritte/mm für die X, Y und Z-Achse findest Du bei $100 bis $102. Betätigst Du den Button $, dann wird eine Liste möglicher Befehle ausgegeben. Darin findest Du die passende Syntax für die Änderung der Einstellungen: $x=value (save Grbl setting) Wenn Du also z.B. die Schritte/mm auf 800 für die X-Achse ändern willst, gibst Du unten im Eingabefeld (Abschluss mit Return-Taste) ein: $100=800 Anschliessend kannst Du ja noch mal mit $$ überprüfen ob die Änderung ordnungsgemäss übernommen wurde. Der geänderte Wert bleibt im Mikrocontroller des Arduino persistent erhalten. Für einige Einstellungen die mit $$ aufgelistet werden, empfiehlt sich zum besseren Verständnis unbedingt das Studium von "Configuring Grbl v0.9": https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Gruss Ulrich Albert
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.
Hallo Albert, bin seit eingier Zeit dankbarer Nutzer Deines Frontends. Bin noch nicht produktiv, weil ich meine Fräse noch einfahre bzw. heftig lernen muss. @CrazyH: Bei Windows kann man im Grätemanger die Nummer der ComPorts auch verändern. Habe Com1 auf Com11 geschickt und den Arduino auf Com1. So ist der Start dann ganz einfach. Bitte bei den Schritten pro mm (Werte: $100 bis $102) immer rechnen, ob die maximale Frequenz von 30KHz nicht überschritten wird. Bin kürzlich böse reingefallen. Auch wenn man beim Fräsen selbst eine niedrige Geschwindigkeit fährt, so bewegt sich die Fräse bei Leerfahrten (Kommando G0) immer mit der maximalen Geschwindigkeit (Werte bei $110 bis $112). Diese Werte werden bei grbl auch beim Fräsen nicht überschritten (Kommando G1), selbst wenn man höhere F-Werte per Programm schickt. Beispiel: $10x: 1600 Schritte/mm $11x: 1000 mm/Minute 1600 X 1000 60 1000 = 26,66 KHz -> OK $10x: 1600 Schritte/mm $11x: 2000 mm/Minute 1600 X 2000 60 1000 = 53,33 KHz -> Problem. Der Ardunio steigt nicht nur aus sondern überschreibt auch seinen Speicher oder EEPROM. Mußte mehrfach neu flashen, bis man mich im Netz auf das richtige Pferd gehoben hatte. Und das möchte ich hiermit weiter geben.Es ist also wieder mal wahr geworden, daß die meisten Probleme zwischen dem Sessel und dem Bildschirm hocken. Es gibt aber auch Ausnahmen. Habe als "blindes Huhn" z.B. beim aktuellen grbl einen SW Fehler gefunden. Bei wiederholten exakt diagonalen x/y Fahrten wurde bei Richtungswechsel zwischendurch nicht gebremst oder beschleunigt. Das tritt im realen Leben eher selten bis gar nicht auf. Aber als "bloody redneck" macht man halt auch sowas. Nun das ist von den Profis im Netz quasi über Nacht behoben worden und fließt in den nächsten Release h ein. Die Version ist als Zwischenversion auf github zu finden. grbl_v0_9h_edge_328p_16mhz_115200_build20150205.hex Grüße Johannes
Korrektur: Bei den Formeln oben hat HTML die Schrägstriche geschluckt. Soll z.B. heißen: 1660 mal 1000 geteilt durch 60 geteilt durch 1000
...und noch eine Korrektur für dein Beispiel. Bei GRBL Version 9g muss es jeweils heissen: $100 anstatt $10 $110 anstatt $11 Ansonsten Danke für Deinen Beitrag.
Albert M. schrieb: > ...und noch eine Korrektur für dein Beispiel. > Bei GRBL Version 9g muss es jeweils heissen: ... stimmte schon so, hatte das x bei Dir übersehen :)
Angehängte Dateien:
-
Unbenannt.JPG
26 KB
Hallo Albert, kann es sein das hier etwas nicht richtig ist habe es auf 2 Rechnern unter XP getestet. Ist mir bei 0.7d und 0.7e aufgefallen. lg fragender
fragender schrieb: > kann es sein das hier etwas nicht richtig ist Wer selbst programmiert kennt das Thema. Trotz Einstellung der Programmierumgebung auf Autoscale/Proportional ist es schwierig eine universelle Skalierung für alle möglichen Monitor-/ Grafikkarten-Einstellungen (Auflösung, DPI, Textgrösse usw) zu finden. Bei dem gezeigten Bild passt nicht nur die Textplatzierung nicht, auch die Eingabeboxen rechts oben sind ineinander gerutscht. Ich versuche das für die nächste Version zu korrigieren. Welche Grafikkarteneinstellungen benutzt Du?
Hallo Albert! Das gehört ganz unten auf die To-Do-Liste (wenn überhaupt), aber weil Du gerade von Grafik sprichst eine Nebensächlichkeit von mir: wäre es ggf möglich, das Farbschema einstellbar zu machen? Oder aber vielleicht 2 bis 3 Schemata fertig vorzuhalten? Ich persönlich finde das schlichte durchgängige PC-grau (wie die Menüleiste) am unaufdringlichsten :-). Gruß Malte
Hallo Albert, danke für die Info von Dir, habe als Grafikeinstellung 1024x768 aber auch ein höher oder tiefer setzen ändert an der Darstellung nichts. Ab 1280x800 wird die breite allerdings auch nicht mehr verändert.Also kein Vollbild Modus mehr. Ist auf beiden Systemen das selbe Win XP Pro einmal mit ATI Grafik Karte neuste Treiber sind drauf und einmal Laptop 17 Zoll mit NVidea Grafik Karte auch neuste Treiber. Also nichts exsotisches von der Hardware her. Hatte ja auch nur Angefrag ob da was nicht i.O. ist, bei einem Rechner hätte der Fehler ja durch aus bei mir liegen können. Habe das aber auch auf einen Netbook Samsung NC30 unter Win7 heute noch mal getestet da ist der selbe Fehler bei allen Möglichen Auflösungen. Jedenfalls noch mal Danke für die schnelle Antwort von Dir. lg fragender MTA schrieb: > Das gehört ganz unten auf die To-Do-Liste (wenn überhaupt) Hallo Malte, kann deinen Kommentar ( dein Problem ) leider nicht Nachvollziehen.
Hallo, fragender schrieb: > Hallo Malte, > > kann deinen Kommentar ( dein Problem ) leider nicht Nachvollziehen. Du verstehst inhaltlich nicht was ich meine oder Du meinst es wäre für Dich nicht interessant das Farbschema ändern zu können? Ich bin nicht davon ausgegangen, dass es für jedermann von Interesse wäre, die Farbe ändern zu können, deswegen auch meine sehr defensive Anmerkung, dass es ganz unten auf die To-Do-Lister gehört. Ist's so klarer für Dich geworden?
fragender schrieb: > habe als Grafikeinstellung 1024x768 aber > auch ein höher oder tiefer setzen ändert an der Darstellung nichts. Ich habe jetzt mal die Darstellung auf 3 verschiedenen PC's (XP und Win7) mit unterschiedlichen Grafikkarten in sämtlichen Grafik- und Text-DPI-Modi getestet (Grafik 1024x768 bis zu 2048x1152). Die Darstellung ist dabei immer einwandfrei. Leider kann ich das in deinem Bild gezeigte Verhalten nicht reproduzieren, was für eine Korrektur unabdingbar wäre.
Könnte vielleicht an einer manuell geänderten Systemschriftröße liegen. Unter XP waren die Einstellungen ja noch über die Systemsteuerung zugänglich. Hat Mircosoft inzwischen ziemlich verbaut. Nur noch über "[HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics]" mfG vom ingo
Angehängte Dateien:
-
fnt.png
6,6 KB
Hallo nochmal, Albert M. schrieb: > Leider kann ich das in deinem > Bild gezeigte Verhalten nicht reproduzieren, was für eine Korrektur > unabdingbar wäre. ich habe das Problem auch nicht, aber ich glaube es liegt daran, dass der Font in dem Bild von "fragender" breiter ist. Ich habe mal einen Screenshot unter Lupe gemacht und als Bild angehängt. Oben sieht man den Text von "fragender" und darunter die Darstellung bei mir auf dem Rechner. Möglicherweise liegt es an Einstellungen zu Windows GUI (habe selber nie an den Fonts rumgedreht). Ich habe übrigens noch einen kleinen Typo gefunden. Im "Manual Process" Bereich steht unten links neben der Checkbox "Keybord" statt "Keyboard". Völlig nebensächlich :-). Gruß Malte
Ingo Wendler schrieb: > Könnte vielleicht an einer manuell geänderten Systemschriftröße liegen. Ingo war schneller :-)
Angehängte Dateien:
-
Fehler.png
67 KB
Guten Morgen, hier mal zur Ansicht auf einen Asus Mini Laptop unter Win 7 Pro in 1024x600 sieht auch etwas komisch aus oder ? Kann es mit Externen Monitor auch hoch Skalieren die Darstellung bleibt immer etwas verschoben. Gruß Ronny
Angehängte Dateien:
-
Fehler-2.png
71 KB -
Fehler-3.png
60 KB
Hallo, Fehler Bild 2 zeigt 1024x768 in Fehler Bild 3 ist die Auflösung nur 800x600 Maximiert da sieht das dann so aus z.B. Hoffe die Bilder helfen bei der Fehler suche. Gruß Ronny
Die Design-Breite/Höhe beträgt 1200x760. Damit ist die minimale Auflösung für die Darstellung vorgegeben. Das wird auch nicht geändert. Die Verwendete skalierbare Schriftart ist Arial, welche normalerweise auf allen Windows PC's verfügbar ist. Fehler die ab dieser Mindest-Auflösung in der Darstellung auftreten versuche ich zu ändern, so weit bei mir nachvollziehbar oder versuchsweise nach den von euch gezeigten Screen Shots.
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/
Noch eine Frage von einem nicht-Arduino-Benutzer: Hat so ein Arduino irgend etwas besonderes an sich, das die grbl-Software nur auf ihm lauffähig macht oder kann ich die einfach auf einem selbst gebauten Board mit passendem uC flashen und fertig ? Gruss Harry
Crazy H. schrieb: > Hat so ein Arduino > irgend etwas besonderes an sich, das die grbl-Software nur auf ihm > lauffähig macht oder kann ich die einfach auf einem selbst gebauten > Board mit passendem uC flashen Übertrage auf Deinen ATMega328 den Arduino Bootloader mittels ISP-Programmer. Um den Bootloader aufzuspielen am einfachsten die Arduino Oberfläche installieren, da Deinen Programmer einstellen und den Bootloader direkt mit ISP übertragen: http://arduino.cc/en/Main/Software Betreibe deinen ATmega mit der selben Taktfrequenz wie der Original Arduino Uno, füge einen FTDI Seriell/USB Wandler (oder ähnliche, gibt es auch als fertige Break Out Boards) hinzu. Bei der Installation der Arduino Oberfläche kannst Du auch gleich Treiber für die FTDI Seriell/USB Wandler mit installieren lassen. Beachte die Pin-Zuordnung für den Anschluss an das Stepper Driver Board: http://arduino.cc/en/Hacking/PinMapping168 und entsprechend: https://github.com/grbl/grbl/wiki/Connecting-Grbl Dann noch GRBL mit dem SerialComCNC beigefügten Flash-Tool auf deinen ATMega flashen. Hab ich was vergessen? Ach ja die Arduino-Oberfläche deinstallieren :)
Hallo Albert, die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht einfach mit meinem Progger so flashen ? Für was brauch ich den BootLoader ? Gruss Harry
Crazy H. schrieb: > die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht > einfach mit meinem Progger so flashen ? Für was brauch ich den > BootLoader ? Sicher kannst Du das hex File direkt flashen, ob dann aber GRBL funktioniert weiss ich nicht. Habs nie probiert. Ich kann auch nicht sagen welche Funktionalität der Arduino Bootloader sonst noch hat die unabdingbar wäre oder ob der Bootloader vom Hex-File überschrieben wird. Daher meine oben beschriebene sichere Methode. Aber Versuch macht klug :) Vielleicht kann jemand mehr dazu sagen?
Albert M. schrieb: > Crazy H. schrieb: >> die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht >> einfach mit meinem Progger so flashen ? Für was brauch ich den >> BootLoader ? > > Sicher kannst Du das hex File direkt flashen, ob dann aber GRBL > funktioniert weiss ich nicht. Habs nie probiert. Sicher kannst Du das HEX File direkt flaschen und die funktionier auch. Das weis ich. Waldemar
Danke Albert & Waldemar :o) Ich hoffe ihr könnt mir meine Frage nachsehen, aber Google spuckt bei "Arduino Uno Mega328" so viel Zeugs aus - ich blick nicht durch. R1, R2, R3, ... ????? Bahnhof ? Einfache Frage: Mega328P ? 16 MHz ? Pinbelegung hab ich ja :o) Ich hab mir TB6600-Enstufen bestellt und möchte 4 von denen auf eine Platte schrauben und eine Platine layouten, die so lang/groß ist, daß die Anschlüsse der Controller-Platine direkt deckungsgleich mit den Endstufenanschlüssen sind. D.h. die Platine soll (mehr-oder-weniger) kurze Anschlussdrähte haben, an die ich direkt die Steckkontakte der Endstufe schrauben kann. Sowas: http://www.ebay.de/311106192368
Harry schrieb: > Einfache Frage: Mega328P ? 16 MHz ? Ja Harry schrieb: > TB6600-Enstufen bestellt und möchte 4 von denen GRBL unterstützt aber nur 3 Achsen (XYZ) keine 4
Albert M. schrieb: > Harry schrieb: >> TB6600-Enstufen bestellt und möchte 4 von denen > > GRBL unterstützt aber nur 3 Achsen (XYZ) keine 4 Ich hab in der X-Achse 2 Motoren. Die schalte ich dann parallel .... die Endstufeneingänge natürlich ;o)
Harry schrieb: > Ich hab in der X-Achse 2 Motoren. Die schalte ich dann parallel .... die > Endstufeneingänge natürlich ;o) Ich glaube nicht, dass das eine gute Idee ist. Angefangen bei eventuell verschiedenen Steigungsfehlern der beiden Anstriebswellen usw. Du musst aber selber wissen was Du da machst. Trotzdem würde ich mich an Deiner Stelle diesbezüglich noch mal in den entsprechenden CNC Foren schlau machen.
Hallo Albert, da mach ich mir keine Gedanken. Das läuft so ja seit ca. 1 1/2 Jahren unter Mach3. Gruss Harry
Crazy H. schrieb: > Hallo Albert, > > die grbl-Software liegt doch als .hex-File vor. Kann ich die nicht > einfach mit meinem Progger so flashen ? Für was brauch ich den > BootLoader ? > > Gruss > Harry Der Bootloader ist nur ein Bootloader, die Firmware braucht den nicht.
Angehängte Dateien:
-
Screenshot__2_.png
110 KB
INKSCAPE erzeugte plt. oder hpgl. Datei -> SerialComCNC -> HPGL Converter= (FEHLERMELDUNG)" ist kein Gleitkommawert. Was mache ich hier falsch? Gruß Yetim
Ali Yetim schrieb: > Was mache ich hier falsch? Falsch: PU4583 7338 Richtig: PU PA4583,7338 das lässt sich doch bestimmt in der Konfiguration von INKSCAPE so einstellen? Falls nicht kann ich Dir da auch nicht weiter helfen. Jeder Grafik/Draw Programm Hersteller kocht sein eigenes Formate-Süppchen und ich habe wenig Motivation hier 20 verschiedene HPGL Formate zu unterstützen. Im Web findet man so einige Format-Konverter, vielleicht die mal auf Brauchbarkeit prüfen. SerialComCNC unterstützt folgende HPGL Befehle Befehle: PU, PD, PA, PR. Alle sonstige Befehle werden ignoriert. PU = Pen Up PD = Pen Down PA = Koordinaten absolut PR = Koordinaten relativ Format (wobei x und y ganzzahlig sind): PU PAx,y PD PRx,y
Hallo Leute, bitte seid vorsichtig mit chinesischen Treiberstufen. Nachdem ich selber mal auf die Nase gefallen bin, habe ich so ziemlich alles gescannt (Waren und Foren), was aus diesem Kontinent so im lower end bereich kommt. Habe keine einzigen Schaltung gefunden, die der Spezifikation entspricht. Da wird abgekupfert was das Zeug hält und wenn einer mal gute Erfahrung hatte, muss das nicht heißen, daß ein Teil das genau so aussieht und beschriftet ist auch wirklich funktioniert. Wenn die Dinger nur mit 30% ihrer Leistung laufen ist das noch ein Gut-Fall. Als ich dann selber Hand angelegen Wollte, habe ich diese Quelle gefunden. http://users.skynet.be/ldt/CNC%20electronics/THB6064AH.html Die Schaltung und das Layout der LP stimmt und der Aufbau war super gut. Löten, Einschalten, Funktion... (NEIN, habe keine Anteile an Lucas' Firma...) Insgesamt habe ich also 2 mal so ziemlich das Gleiche bezahlt - einmal China (Lehrgeld)und einmal Belgien (Funktion). Noch ein Tipp. Viele PC Firmen leeren momentan ihre Lager an alten CPU Kühlkörpern mit Lüfter (eBay). Habe 3 Stück für 12 Euronen bekommen und halte somit die Treiberstufen auf Raumtemperatur - selbst unter Vollast. Hier soll es ja eigentlich um Alberts super Programm gehen - aber habe mich getaut diese Tipps hier zuschreiben, damit Enttäuschung bei Einigen von Euch vermieden wird. Grüße Johannes
Hallo Johannes, > bitte seid vorsichtig mit chinesischen Treiberstufen. Nachdem ich selber > mal auf die Nase gefallen bin, habe ich so ziemlich alles gescannt > (Waren und Foren), was aus diesem Kontinent so im lower end bereich > kommt. Habe keine einzigen Schaltung gefunden, die der Spezifikation > entspricht. Ich hätte nichts dagegen, wenn du recht hättest. Immerhin setzen die Chinesen seit Jahren den europäischen Markt unter Druck. Es gibt aber durchaus brauchbare China-Endstufen, sonst wären die Chinesen nicht so lange so erfolgreich. Bei den 3-/4-Achsboards mit Toshiba-ICs für Hobby CNC-Maschinen mag das Qualitätsniveau allerdings deutlich schlechter sein als bei den industrietauglichen Endstufen. Bei den Hobbyisten ist allerdings auch der Hang am größten, so billig wie möglich einzukaufen, koste es was es wolle. ;) Im übrigen hat das hier mit dem eigentlichen Thema nichts zu tun, so dass sich der Verdacht aufdrängt, dass du hier doch nur Schleichwerbung machen willst. Mit freundlichen Grüßen Thorsten Ostermann
@Thorsten, sicher hast Du Recht das es damit nichts zu tun hat. Aber den Hinweis auf den THB6064 finde ich trotzdem in Ordnung. Der ist deutlich leistungsfähiger als die Vorgänger z.B. TB6560. Leider ist der THB immer noch nicht überall zu bekommen. Wir haben den selber aus China holen müssen. Gerade das langsame Timing des TB ist immer wieder ein Grund für scheinbar unerklärliche Probleme mit Mach3.
Hallo Ich benutze SerialComCNC schon seit längerer Zeit. Seit kurzem habe ich eine USB Webcam an meine CNC angebaut. Mein Problem ist, dass das Programm nach ca. einer Minute zu hängen anfängt nachdem man auf Video schaltet. Man muss SerialComCNC neu starten, damit es wieder weiter läuft. Ich habe sicherlich nicht den schnellsten PC angeschlossen, aber ich glaube nicht, dass es daran liegt, da die RAM und CPU Auslastung nicht sehr hoch ist.
Gabriel M. schrieb: > ich eine USB Webcam an meine CNC angebaut. Mein Problem ist, dass > das Programm nach ca. einer Minute zu hängen anfängt nachdem man auf > Video schaltet. Man muss SerialComCNC neu starten, damit es wieder > weiter läuft. Ich habe sicherlich nicht den schnellsten PC Das ist nichts was ich in SerialComCNC ändern könnte. Das Problem liegt entweder an den Treibern Deiner WebCam oder an einem zu langsamen PC. Bei meinem Intel i7 860 PC mit Logitech WebCam gibt diesbezüglich keinerlei Probleme.
Angehängte Dateien:
-
SerialComCNC_v0.8.jpg
300 KB
Anbei SerialComCNC Version 0.8 Change Log V0.8 --------------- Werkzeuglängen-Sensor / Probe Unterstützung zugefügt. Anschluss des Sensors/Probe siehe hier: https://github.com/grbl/grbl/wiki/Connecting-Grbl Den Werkzeuglängen-Sensor zuerst unter Settings/Probe einmalig einrichten. Dabei wird der Sensor auf der Oberfläches eines Werkstücks platziert. Die Kontakthöhe des Sensors wird beim Beendes des Programms gespeichert und steht beim nächsten Aufruf wieder zur Verfügung. Nach der Einrichtung wird nach einem Werkzeugwechsel mittels Button P das Probing durchgeführt und anschliessend mit Button UP (Use Probe) die Z-Achse automatisch genau bis auf den Werkzeug-Nullpunkt heruntergefahren. Der Vorschub/Feed der Z-Achse während des Probing ist in 3 Stufen von 2 bis 10 mm/min einstellbar. Das Probing funktioniert zuerst mal nur so wie hier beschrieben, also halb-manuell. Der korrekte Ablauf innerhalb eines laufenden G-Code Programms wurde noch nicht implementiert/überprüft. Als Werkzeuglängen-Sensor wurde zum Test der hier benutzt: http://www.ebay.de/itm/Werkzeuglangenmesser-Werkzeuglangensensor-Werkzeugtaster-CNC-Frase-/321380535406?pt=Industriemaschinen&hash=item4ad3c5cc6e Gruss Ulrich Albert Homepage: http://www.serialcominstruments.com/
DANKE für dieses Programm und die ständigen sehr nützlichen Erweiterungen. Ich zähle es zu dem besten Frontend für Grbl.
Albert M. schrieb: > Gabriel M. schrieb: >> ich eine USB Webcam an meine CNC angebaut. Mein Problem ist, dass >> das Programm nach ca. einer Minute zu hängen anfängt nachdem man auf >> Video schaltet. Man muss SerialComCNC neu starten, damit es wieder >> weiter läuft. Ich habe sicherlich nicht den schnellsten PC > > Das ist nichts was ich in SerialComCNC ändern könnte. Das Problem liegt > entweder an den Treibern Deiner WebCam oder an einem zu langsamen PC. > Bei meinem Intel i7 860 PC mit Logitech WebCam gibt diesbezüglich > keinerlei Probleme. Danke das mit dem updaten werde ich probieren, ansonsten muss wohl ein neuerer pc her...
Angehängte Dateien:
Hier die Vorschau auf die nächste Version 8a. Neu: Makros Es können 4 verschiedene Makros mit beliebigem G-Code definiert, editiert, gespeichert und über den neuen Button M aufgerufen werden. Gruss Ulrich Albert
Das wird die Software des Jahres 2015 wenn du so weitermachst. Danke für deine unermüdlichen und sehr praktischen Verbesserungen . Weiter so.
Angehängte Dateien:
-
SerialComCNC_v0.8a.jpg
300 KB
Anbei SerialComCNC Version 0.8a
Change Log V0.8a
----------------
Makros implementiert.
Unter Settings/Macros können bis zu 4 Makros mit G-Code definiert
werden.
Format: 1. Zeile = Kommentar/Info, wird nicht ausgewertert
weitere Zeilen = G-Code
Leerzeilen sind nicht erlaubt
Befehle für Tool Change (Txx) werden ignoriert
Die Makros werden über den Button M im Manual Process ausgewählt
und mit dem 'Run Macro' Button gestartet.
Gruss Ulrich Albert
Homepage:
http://www.serialcominstruments.com/
Ich kann mich nur hardyf anschliessen. Einfach super, danke! Meine Tests laufen mit einer 3D-dxf super. Mit der Erstellung eines Codes für die Platienenbohrung habe ich allerdings Probleme. Ich arbeite mit Eagle 7.2. Die Bohrdaten stelle ich mit Cam-job und dem Excellon-Treiber her. Da fehlen mMn die z-Werte, oder seh ich da was falsch? Das ist für mich völliges Neuland, bisher habe ich händisch gebohrt. Kann mir jemand Schritt für Schritt erklären, wie ich den Code für die Steuerung erstellen kann? Gruss Wilfried
poste mal ne Bohrdatei, am besten als .zip vlG Charly
Wilfried Richter schrieb: > Die Bohrdaten stelle ich mit Cam-job und dem > Excellon-Treiber her. > Da fehlen mMn die z-Werte, oder seh ich da was falsch? Lässt sich doch alles im Excellon Drill Data Converter Fenster einstellen: z-Werte = Drill Depth Sicherheitshöhe = Secure Height Vorschub = Milling Feed
Hallo, das war ja prompt. Herzlichen Dank für eure Hilfe ! Mit dem Excellon Drill Data Converter wusste ich nichts anzufangen. Ich hab' ihn aber gefunden, sogar ohne Google. Hat ja prima funktioniert. Nochmals danke. Gruss Wilfried
Hallo Albert, vielen Dank für dein tolles Tool, nur leider läuft es bei mir nicht zufriedenstellend. Problem: GRBL-Startup Meldung kommt nach Verbindung mit Controller (in schwarz). Manuelle Steuerung (Verfahren) funktioniert (gesendete Befehle in grün, aber kein schwarzes 'ok' als Antwort) aber keine Abfragen ($, $$) und kein 'Job'. Bei einer Jobausführung wird immer die erste Zeile auf Senden 'ok' gesetzt, danach passiert nichts mehr - vermutlich weil Endlos auf eine GRBL-Antwort gewartet wird. Meine Hardware: Win7 HomePremium 64Bit. Ich habe dieses Problem mit einem Uno R3 Clone sowie zwei Adruino Nano Clones (mehr habe ich nicht zum probieren). Alle Boards verwenden einen CH340 seriell USB Converter. Bisherige Lösungsversuche: Programiert wurde mit der Arduino IDE (der XLoader funktioniert bei den Nanos nicht - beim Uno Clone schon). Verbinung mit der Adruino-IDE COM-Verbindung sowie mit HTerm funktioniert (z.B. Abfrage $). Neuinstallation des CH340 Treiber (von anderer Quelle runtergeladen): gleiche Treiberversion, gleiches Verhalten. Auch das runtersetzen der Übertragungsrate (und neu Compilierung inder Adruino-IDE) auf 19200 brachte keine Besserung - es werden Befehle angenommen aber keine Bestätigung im SerialComCNC angezeigt. Ich vermute dass dein SerialComCNC etwas 'zickig' beim Empfangen ist? Oder das 7Hz Pollen den Empfang vom CH340 beeinträchtigt? Was kann ich noch versuchen um meine Boards mit SerialComCNC zum Laufen zu bekommen? Gruß Sven
Nachtrag: ich habe auch einen anderen USB-Port versucht - dort wurde der gleiche Treiber über den Windowsdienst installiert - mit gleichem Ergebnis...
Sven schrieb: > Auch das runtersetzen der Übertragungsrate (und neu Compilierung inder > Adruino-IDE) auf 19200 brachte keine Besserung GRBL 0.9 benötigt zwingend 115200 baud. Ich weiss auch nicht was Du da "neu kompilierst"? Es muss nichts kompiliert werden. Es muss nur das beigefügte Hex-File auf den Arduino geflasht werden. Sven schrieb: > Win7 HomePremium 64Bit. Ich habe dieses Problem mit einem Uno R3 Clone > sowie zwei Adruino Nano Clones (mehr habe ich nicht zum probieren). Alle > Boards verwenden einen CH340 seriell USB Converter. Ich habe hier nur Boards mit FTDI USB/Seriell Converter und Windows 7 Pro 32bit. Vielleicht zicken Deine Treiber bei Win 64bit. Da Du bisher der Einzige bist, der sich mit diesem Problem meldet, vermute ich den Fehler zuerst mal eher auf Deiner Seite. Sven schrieb: > Was kann ich noch versuchen um meine Boards mit SerialComCNC zum Laufen > zu bekommen? Versuche mal Deinen Arduino mit geflashtem GRBL nur mit einem Terminal-Programm zu betreiben, indem Du entsprechende G-Codes schickst. Z.B. G-Code für eine lange Line mit langsamen Vorschub und dann mehrmals pro Sekunde "?" schicken, um zu testen ob der Arduino die aktuellen Positionen zurück sendet.
Hallo Albert, >Ich weiss auch nicht was Du da "neu kompilierst"? Ich habe mir die GRBL Dateien runtergeladen, die config.h angepasst (#define BAUD_RATE 19200) und mit der Arduino IDE neu compiliert und hochgeladen. In deinem SerialComCNC habe ich die Baudrate entsprechend angepasst und konnte mein Board steuern - mit unverändertem Verhalten, dass keine Antwort vom GRBL im SerialComCNC angezeigt wird. >Versuche mal Deinen Arduino mit geflashtem GRBL nur mit einem >Terminal-Programm zu betreiben, indem Du entsprechende G-Codes schickst. >Z.B. G-Code für eine lange Line mit langsamen Vorschub und dann mehrmals >pro Sekunde "?" schicken, um zu testen ob der Arduino die aktuellen >Positionen zurück sendet. Das habe ich gerade erfolgreich mit HTerm ausgeführt: ich bekomme mit jeder Abfrage eine "<run..." String und zum Schluß "<Idle..." zurück. Also GRBL scheint fehlerfrei zu laufen... Gruß Sven
Moin, es scheint wohl an meinem Notebook zu liegen: An einem anderen PC (Win7 Enterprise 32Bit) wurde der geleiche Treiber automatisch installiert und mein Nano antwortet hier auf gesendete Befehle im SerialComCNC - also wird die Jobausführung vermutlich auch funktionieren. Was ist an meinem Notebook falsch, dass es dort nicht läuft? Wegen der 64Bit Version? Sehr merkwürdig. Gruß Sven
Hallo zusammen, ich hatte ein ähnliches Problem. Mit der Arduino-Software 1.5.7 funktionierte der automatisch installierte USB-Treiber nicht. Daraufhin habe ich den Treiber aus der Version 1.5.2 installiert und damit gings. Gruss Wilfried
Angehängte Dateien:
-
Buffer.png
160 KB
Ich habe nun Stunden damit verbracht das Problem zu lösen... Jetzt funktioniert es gerade und ich hoffe es lag an der Einstellung des Empfangbuffers (siehe Bild). Auch wenn es nicht in deinem Sinne ist den original GRBL-Code zu ändern, möchte ich hier ein 'GRBL-Hack' teilen, mit welchem ein RC-Servo über den Spindle-PWM Ausgang gesteuert werden kann (Pen Up/Down oder Ansteuerung eines RC-Fahrtreglers zur Steuerung der Motordrehzahl) - für Arduino Uno und Nano. Anpassung der Spindelsteuerung in (vermutlich) C:\Program Files (x86)\Arduino\libraries\GRBL\spindle_control.c - einfach ersetzen. Achtung in config.h muss #define VARIABLE_SPINDLE eingefügt werden (Zeile 157 in der aktuellen v0.9 Version) Änderung der PWM-Frequenz auf 61Hz (Teiler = 1024), damit Ladewerte für Servo-short = 15 (1ms), Servo-long = 32 (2ms). Über die Spindelgeschwindigkeit kann der Servoweg eingestellt werden. Richtungsumkehr des Servos per #define möglich (in spindle_control.c) Um die Dauer des Stift Anhebens / Absenkens zu berücksichtigen wäre es klasse wenn Du bei der Konvertierung von HPGL, im SerialComCNC, die Angabe von Pausenzeiten vor/nach M03/M05 abfragen könntest. Beim CNC-USB (www.planet-cnc.com) werden diese Delays über das Einfügen von z.B. G04 P2.0 (2ms Pause) nach den Befehlen M03 und M05 realisiert. Gruß Sven
Hallo Albert, leider war das Funktionieren gestern nur ein einmaliger Glücksfall. Ich habe mir nun den 'Serial Port Monitor' von Eltima installiert und interpretiere die Ergebnisse so, dass SerialComCNC den Empfangsstatus einfach nicht mehr abfragt nach dem Senden der ersten paar '?'. Anbei die Dumpfiles im HTML-Format vom HTerm (senden '?' alle 150ms) und vom SerialComCNC. HTerm_dump.html: bei Eintrag #597 kommt die GRBL-Statusmeldung und das Senden von '?' beginnt. Nach jedem '?' wird der Empfangsbuffer abgefragt (IRP_MJ_DEVICE_CONTROL (IOCTL_SERIAL_WAIT_ON_MASK)). SerialCom_CNC_dump.html: bei Eintrag #115 kommt die GRBL-Statusmeldung und das Senden von '?' beginnt. Einmalig wird der Empfangbuffer ausgelesen, danach (Eintrag #130) nicht mehr... Hängt sich da die Empfangroutine auf? Sehr mysteriös... Gruß Sven
Hallo zusammen, Ich bräuchte auch dringend mal unterstützung mit der Firmware und Software für meine CNC Fräsmaschine mit Mega2560 und Ramps 1.4 Die Maschine (XYZ) ist fertig und läuft mit der 3D Druckersoftware auch Problemlos wenn ich Sie über Pronterface bediene. Nur ist Pronterface ja zum 3D Drucken und nicht zum Fräsen. Auch mit der Einrichtung der Arduino Druckersoftware Marlin bin ich bis jetzt gut klar gekommen. Nun möchte ich die Maschine jedoch nicht als Drucker betreiben und kenne mich absolut nicht aus mit der Firmware für das Mega im Bereich CNC Fräsen und noch weniger mit der Software dazu. Ich habe verschiedene Versionen von Grbl to Arduino geladen und auf das Board gespielt. Der GRBL Controller konnte sich auch mit dem Arduino verbinden, aber das war´s dann auch schon. Die hier angebotenen Versionen habe ich auch getestet...kommt leider immer Serial Port Error wenn ich mich mit Serial Com CNC verbinden möchte. Die Firmware habe ich mit dem hier angebotenen Xloader aufgespielt.(grbl_v0_9g_edge_328p_16mhz_115200_build20140813) Hat jemand eine Fräsmaschine mit einem Mega2540 und Ramps1.4 am laufen? Ich wäre Soooo Dankbar wenn mir jemand helfen könnte. Hänge da schon seit Tagen fest. LG, Frank
Hallo Frank, die angebotenen Hex-Files sind vermutlich für Uno und Nano (beide mit ATMEGA328P) compiliert. Du müsstest dir die Arduino IDE installieren, die aktuellen GRBL files ins entsprechende Verzeichniss kopieren. Dann in config.h deinen Mega2540 angeben, dieser scheint in der cpu_map.h aufgeführt zu sein. Also einfach in der config.h die Zeile (bei mir 46) #define CPU_MAP_ATMEGA328P_TRADITIONAL // Arduino Uno CPU gegen #define CPU_MAP_ATMEGA2560 // (Arduino Mega 2560) Working austauschen. Wg.der Verbindungprobleme solltest Du nach der richtigen Übertragungsrate gucken, default sind jetzt (version 0.9) 115200 (config.h Zeile 42 #define BAUD_RATE 115200). Viel Erfolg Sven
Thx, Sven Hallo @all... Kurz zum aktuellen Stand. Ich habe die Firmware Version GRBL_RAMPS1_4 noch einmal auf mein Board geladen. Keine Ahnung warum, aber ich bekomme nun eine Verbindung zu meiner Maschine. Was ich mir noch nicht erklären kann ist warum ich den Y Motor steckplatz mit Z tauschen musste. Die Achsen kann ich nun mit "Grbl Controller" und "SerialComCNC" fahren. Die Schritte pro mm habe ich auch anpassen können. Nun hänge ich aber an der Feinabstimmung da ich mich mit diesen Programmen nicht auskenne. Keine meiner Endschalter werden erkannt...ich Nutze auf dem mega2560 (Ramps1.4) die gleichen Steckplätze wie beim 3D Printer. Inzwischen habe ich mitbekommen das ich Sie ev in andere Ports aufstecken muss.Konnte ich noch nicht testen, aber woher soll die Fräse wissen in welche Richtung Sie die anfahren soll? Also beim 3D Drucker hatte ich die Möglichkeit einzustellen ob ich Soft oder Hardware endschalter habe. (ich habe nur einen Schließer an jeder achse zum Referieren.) Auch konnte ich einstellen in welche Richtung die Maschine zum referieren fahren muss. Hier mal meine Config.h die ich zum Druck benutze. fndef CONFIGURATION_H #define CONFIGURATION_H // This configuration file contains the basic settings. // Advanced settings can be found in Configuration_adv.h // BASIC SETTINGS: select your board type, temperature sensor type, axis scaling, and endstop configuration //====================================================================== ===== //============================= DELTA Printer =============================== //====================================================================== ===== // For a Delta printer replace the configuration files with the files in the // example_configurations/delta directory. // //====================================================================== ===== //============================= SCARA Printer =============================== //====================================================================== ===== // For a Delta printer replace the configuration files with the files in the // example_configurations/SCARA directory. // // User-specified version info of this build to display in [Pronterface, etc] terminal window during // startup. Implementation of an idea by Prof Braino to inform user that any changes made to this // build by the user have been successfully uploaded into firmware. #define STRING_VERSION_CONFIG_H _DATE_ " " _TIME_ // build date and time #define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes. // SERIAL_PORT selects which serial port should be used for communication with the host. // This allows the connection of wireless adapters (for instance) to non-default port pins. // Serial port 0 is still used by the Arduino bootloader regardless of this setting. #define SERIAL_PORT 0 // This determines the communication speed of the printer // This determines the communication speed of the printer #define BAUDRATE 115200 // This enables the serial port associated to the Bluetooth interface //#define BTENABLED // Enable BT interface on AT90USB devices //// The following define selects which electronics board you have. Please choose the one that matches your setup // 10 = Gen7 custom (Alfons3 Version) "https://github.com/Alfons3/Generation_7_Electronics"; // 11 = Gen7 v1.1, v1.2 = 11 // 12 = Gen7 v1.3 // 13 = Gen7 v1.4 // 2 = Cheaptronic v1.0 // 20 = Sethi 3D_1 // 3 = MEGA/RAMPS up to 1.2 = 3 // 33 = RAMPS 1.3 / 1.4 (Power outputs: Extruder, Fan, Bed) // 34 = RAMPS 1.3 / 1.4 (Power outputs: Extruder0, Extruder1, Bed) // 35 = RAMPS 1.3 / 1.4 (Power outputs: Extruder, Fan, Fan) // 4 = Duemilanove w/ ATMega328P pin assignment // 5 = Gen6 // 51 = Gen6 deluxe // 6 = Sanguinololu < 1.2 // 62 = Sanguinololu 1.2 and above // 63 = Melzi // 64 = STB V1.1 // 65 = Azteeg X1 // 66 = Melzi with ATmega1284 (MaKr3d version) // 67 = Azteeg X3 // 68 = Azteeg X3 Pro // 7 = Ultimaker // 71 = Ultimaker (Older electronics. Pre 1.5.4. This is rare) // 72 = Ultimainboard 2.x (Uses TEMP_SENSOR 20) // 77 = 3Drag Controller // 8 = Teensylu // 80 = Rumba // 81 = Printrboard (AT90USB1286) // 82 = Brainwave (AT90USB646) // 83 = SAV Mk-I (AT90USB1286) // 84 = Teensy++2.0 (AT90USB1286) // CLI compile: DEFINES=AT90USBxx_TEENSYPP_ASSIGNMENTS HARDWARE_MOTHERBOARD=84 make // 9 = Gen3+ // 70 = Megatronics // 701= Megatronics v2.0 // 702= Minitronics v1.0 // 90 = Alpha OMCA board // 91 = Final OMCA board // 301= Rambo // 21 = Elefu Ra Board (v3) // 88 = 5DPrint D8 Driver Board // 999 = Leapfrog #ifndef MOTHERBOARD #define MOTHERBOARD 33 #endif // Define this to set a custom name for your generic Mendel, // #define CUSTOM_MENDEL_NAME "This Mendel" // Define this to set a unique identifier for this printer, (Used by some programs to differentiate between machines) // You can use an online service to generate a random UUID. (eg [www.uuidgenerator.net]) // #define MACHINE_UUID "00000000-0000-0000-0000-000000000000" // This defines the number of extruders #define EXTRUDERS 1 //// The following define selects which power supply you have. Please choose the one that matches your setup // 1 = ATX // 2 = X-Box 360 203Watts (the blue wire connected to PS_ON and the red wire to VCC) #define POWER_SUPPLY 1 // Define this to have the electronics keep the power supply off on startup. If you don't know what this is leave it. // #define PS_DEFAULT_OFF //====================================================================== ===== //=============================Thermal Settings ============================ //====================================================================== ===== // //--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table // //// Temperature sensor settings: // -2 is thermocouple with MAX6675 (only for sensor 0) // -1 is thermocouple with AD595 // 0 is not used // 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup) // 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup) // 3 is Mendel-parts thermistor (4.7k pullup) // 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !! // 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup) // 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup) // 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup) // 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup) // 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) // 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup) // 10 is 100k RS thermistor 198-961 (4.7k pullup) // 11 is 100k beta 3950 1% thermistor (4.7k pullup) // 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed) // 20 is the PT100 circuit found in the Ultimainboard V2.x // 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950 // // 1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k // (but gives greater accuracy and more stable PID) // 51 is 100k thermistor - EPCOS (1k pullup) // 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup) // 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup) // // 1047 is Pt1000 with 4k7 pullup // 1010 is Pt1000 with 1k pullup (non standard) // 147 is Pt100 with 4k7 pullup // 110 is Pt100 with 1k pullup (non standard) #define TEMP_SENSOR_0 1 #define TEMP_SENSOR_1 0 #define TEMP_SENSOR_2 0 #define TEMP_SENSOR_BED 0 // This makes temp sensor 1 a redundant sensor for sensor 0. If the temperatures difference between these sensors is to high the print will be aborted. //#define TEMP_SENSOR_1_AS_REDUNDANT #define MAX_REDUNDANT_TEMP_SENSOR_DIFF 10 // Actual temperature must be close to target for this long before M109 returns success #define TEMP_RESIDENCY_TIME 10 // (seconds) #define TEMP_HYSTERESIS 3 // (degC) range of +/- temperatures considered "close" to the target one #define TEMP_WINDOW 1 // (degC) Window around target to start the residency timer x degC early. // The minimal temperature defines the temperature below which the heater will not be enabled It is used // to check that the wiring to the thermistor is not broken. // Otherwise this would lead to the heater being powered on all the time. #define HEATER_0_MINTEMP 5 #define HEATER_1_MINTEMP 5 #define HEATER_2_MINTEMP 5 #define BED_MINTEMP 5 // When temperature exceeds max temp, your heater will be switched off. // This feature exists to protect your hotend from overheating accidentally, but NOT from thermistor short/failure! // You should use MINTEMP for thermistor short/failure protection. #define HEATER_0_MAXTEMP 260 #define HEATER_1_MAXTEMP 260 #define HEATER_2_MAXTEMP 260 #define BED_MAXTEMP 150 // If your bed has low resistance e.g. .6 ohm and throws the fuse you can duty cycle it to reduce the // average current. The value should be an integer and the heat bed will be turned on for 1 interval of // HEATER_BED_DUTY_CYCLE_DIVIDER intervals. //#define HEATER_BED_DUTY_CYCLE_DIVIDER 4 // If you want the M105 heater power reported in watts, define the BED_WATTS, and (shared for all extruders) EXTRUDER_WATTS //#define EXTRUDER_WATTS (12.0*12.0/6.7) // P=I^2/R //#define BED_WATTS (12.0*12.0/1.1) // P=I^2/R // PID settings: // Comment the following line to disable PID and enable bang-bang. #define PIDTEMP #define BANG_MAX 355 // limits current to nozzle while in bang-bang mode; 255=full current #define PID_MAX 355 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current #ifdef PIDTEMP //#define PID_DEBUG // Sends debug data to the serial port. //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX #define PID_FUNCTIONAL_RANGE 10 // If the temperature difference between the target temperature and the actual temperature // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max. #define PID_INTEGRAL_DRIVE_MAX 355 //limit for the integral term #define K1 0.95 //smoothing factor within the PID #define PID_dT ((OVERSAMPLENR * 8.0)/(F_CPU / 64.0 / 256.0)) //sampling period of the temperature routine // If you are using a pre-configured hotend then you can use one of the value sets by uncommenting it // Ultimaker #define DEFAULT_Kp 22.2 #define DEFAULT_Ki 1.08 #define DEFAULT_Kd 114 // MakerGear // #define DEFAULT_Kp 7.0 // #define DEFAULT_Ki 0.1 // #define DEFAULT_Kd 12 // Mendel Parts V9 on 12V // #define DEFAULT_Kp 63.0 // #define DEFAULT_Ki 2.25 // #define DEFAULT_Kd 440 #endif // PIDTEMP // Bed Temperature Control // Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis // // Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder. // If your PID_dT above is the default, and correct for your hardware/configuration, that means 7.689Hz, // which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating. // This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater. // If your configuration is significantly different than this and you don't understand the issues involved, you probably // shouldn't use bed PID until someone else verifies your hardware works. // If this is enabled, find your own PID constants below. //#define PIDTEMPBED // //#define BED_LIMIT_SWITCHING // This sets the max power delivered to the bed, and replaces the HEATER_BED_DUTY_CYCLE_DIVIDER option. // all forms of bed control obey this (PID, bang-bang, bang-bang with hysteresis) // setting this to anything other than 255 enables a form of PWM to the bed just like HEATER_BED_DUTY_CYCLE_DIVIDER did, // so you shouldn't use it unless you are OK with PWM on your bed. (see the comment on enabling PIDTEMPBED) #define MAX_BED_POWER 255 // limits duty cycle to bed; 255=full current #ifdef PIDTEMPBED //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from FOPDT model - kp=.39 Tp=405 Tdead=66, Tc set to 79.2, aggressive factor of .15 (vs .1, 1, 10) #define DEFAULT_bedKp 10.00 #define DEFAULT_bedKi .023 #define DEFAULT_bedKd 305.4 //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from pidautotune // #define DEFAULT_bedKp 97.1 // #define DEFAULT_bedKi 1.41 // #define DEFAULT_bedKd 1675.16 // FIND YOUR OWN: "M303 E-1 C8 S90" to run autotune on the bed at 90 degreesC for 8 cycles. #endif // PIDTEMPBED //this prevents dangerous Extruder moves, i.e. if the temperature is under the limit //can be software-disabled for whatever purposes by #define PREVENT_DANGEROUS_EXTRUDE //if PREVENT_DANGEROUS_EXTRUDE is on, you can still disable (uncomment) very long bits of extrusion separately. #define PREVENT_LENGTHY_EXTRUDE #define EXTRUDE_MINTEMP 170 #define EXTRUDE_MAXLENGTH (X_MAX_LENGTH+Y_MAX_LENGTH) //prevent extrusion of very large distances. /*================== Thermal Runaway Protection ============================== This is a feature to protect your printer from burn up in flames if it has a thermistor coming off place (this happened to a friend of mine recently and motivated me writing this feature). The issue: If a thermistor come off, it will read a lower temperature than actual. The system will turn the heater on forever, burning up the filament and anything else around. After the temperature reaches the target for the first time, this feature will start measuring for how long the current temperature stays below the target minus _HYSTERESIS (set_temperature - THERMAL_RUNAWAY_PROTECTION_HYSTERESIS). If it stays longer than _PERIOD, it means the thermistor temperature cannot catch up with the target, so something may be wrong. Then, to be on the safe side, the system will he halt. Bear in mind the count down will just start AFTER the first time the thermistor temperature is over the target, so you will have no problem if your extruder heater takes 2 minutes to hit the target on heating. */ // If you want to enable this feature for all your extruder heaters, // uncomment the 2 defines below: // Parameters for all extruder heaters //#define THERMAL_RUNAWAY_PROTECTION_PERIOD 40 //in seconds //#define THERMAL_RUNAWAY_PROTECTION_HYSTERESIS 4 // in degree Celsius // If you want to enable this feature for your bed heater, // uncomment the 2 defines below: // Parameters for the bed heater //#define THERMAL_RUNAWAY_PROTECTION_BED_PERIOD 20 //in seconds //#define THERMAL_RUNAWAY_PROTECTION_BED_HYSTERESIS 2 // in degree Celsius //====================================================================== ===== //====================================================================== ===== //=============================Mechanical Settings=========================== //====================================================================== ===== // Uncomment the following line to enable CoreXY kinematics // #define COREXY // coarse Endstop Settings #define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors #ifndef ENDSTOPPULLUPS // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined // #define ENDSTOPPULLUP_XMAX // #define ENDSTOPPULLUP_YMAX // #define ENDSTOPPULLUP_ZMAX // #define ENDSTOPPULLUP_XMIN // #define ENDSTOPPULLUP_YMIN // #define ENDSTOPPULLUP_ZMIN #endif #ifdef ENDSTOPPULLUPS #define ENDSTOPPULLUP_XMAX #define ENDSTOPPULLUP_YMAX #define ENDSTOPPULLUP_ZMAX #define ENDSTOPPULLUP_XMIN #define ENDSTOPPULLUP_YMIN #define ENDSTOPPULLUP_ZMIN #endif // The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins. const bool X_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Y_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Z_MIN_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool X_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Y_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. const bool Z_MAX_ENDSTOP_INVERTING = true; // set to true to invert the logic of the endstop. //#define DISABLE_MAX_ENDSTOPS //#define DISABLE_MIN_ENDSTOPS // Disable max endstops for compatibility with endstop checking routine #if defined(COREXY) && !defined(DISABLE_MAX_ENDSTOPS) #define DISABLE_MAX_ENDSTOPS #endif // For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1 #define X_ENABLE_ON 0 #define Y_ENABLE_ON 0 #define Z_ENABLE_ON 0 #define E_ENABLE_ON 0 // For all extruders // Disables axis when it's not being used. #define DISABLE_X false #define DISABLE_Y false #define DISABLE_Z false #define DISABLE_E false // For all extruders #define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled #define INVERT_X_DIR false // for Mendel set to false, for Orca set to true #define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false #define INVERT_Z_DIR false // for Mendel set to false, for Orca set to true #define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false #define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false #define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false // ENDSTOP SETTINGS: // Sets direction of endstops when homing; 1=MAX, -1=MIN #define X_HOME_DIR -1 #define Y_HOME_DIR -1 #define Z_HOME_DIR 1 #define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS. #define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below. // Travel limits after homing #define X_MAX_POS 300 #define X_MIN_POS 0 #define Y_MAX_POS 175 #define Y_MIN_POS 0 #define Z_MAX_POS 138.9 #define Z_MIN_POS 0 #define X_MAX_LENGTH (X_MAX_POS - X_MIN_POS) #define Y_MAX_LENGTH (Y_MAX_POS - Y_MIN_POS) #define Z_MAX_LENGTH (Z_MAX_POS - Z_MIN_POS) //============================= Bed Auto Leveling =========================== //#define ENABLE_AUTO_BED_LEVELING // Delete the comment to enable (remove // at the start of the line) #define Z_PROBE_REPEATABILITY_TEST // If not commented out, Z-Probe Repeatability test will be included if Auto Bed Leveling is Enabled. #ifdef ENABLE_AUTO_BED_LEVELING // There are 2 different ways to pick the X and Y locations to probe: // - "grid" mode // Probe every point in a rectangular grid // You must specify the rectangle, and the density of sample points // This mode is preferred because there are more measurements. // It used to be called ACCURATE_BED_LEVELING but "grid" is more descriptive // - "3-point" mode // Probe 3 arbitrary points on the bed (that aren't colinear) // You must specify the X & Y coordinates of all 3 points #define AUTO_BED_LEVELING_GRID // with AUTO_BED_LEVELING_GRID, the bed is sampled in a // AUTO_BED_LEVELING_GRID_POINTSxAUTO_BED_LEVELING_GRID_POINTS grid // and least squares solution is calculated // Note: this feature occupies 10'206 byte #ifdef AUTO_BED_LEVELING_GRID // set the rectangle in which to probe #define LEFT_PROBE_BED_POSITION 15 #define RIGHT_PROBE_BED_POSITION 170 #define BACK_PROBE_BED_POSITION 180 #define FRONT_PROBE_BED_POSITION 20 // set the number of grid points per dimension // I wouldn't see a reason to go above 3 (=9 probing points on the bed) #define AUTO_BED_LEVELING_GRID_POINTS 2 #else // not AUTO_BED_LEVELING_GRID // with no grid, just probe 3 arbitrary points. A simple cross-product // is used to esimate the plane of the print bed #define ABL_PROBE_PT_1_X 15 #define ABL_PROBE_PT_1_Y 180 #define ABL_PROBE_PT_2_X 15 #define ABL_PROBE_PT_2_Y 20 #define ABL_PROBE_PT_3_X 170 #define ABL_PROBE_PT_3_Y 20 #endif // AUTO_BED_LEVELING_GRID // these are the offsets to the probe relative to the extruder tip (Hotend - Probe) #define X_PROBE_OFFSET_FROM_EXTRUDER -25 #define Y_PROBE_OFFSET_FROM_EXTRUDER -29 #define Z_PROBE_OFFSET_FROM_EXTRUDER -12.35 #define Z_RAISE_BEFORE_HOMING 0 // (in mm) Raise Z before homing (G28) for Probe Clearance. // Be sure you have this distance over your Z_MAX_POS in case #define XY_TRAVEL_SPEED 500 // X and Y axis travel speed between probes, in mm/min #define Z_RAISE_BEFORE_PROBING 15 //How much the extruder will be raised before traveling to the first probing point. #define Z_RAISE_BETWEEN_PROBINGS 5 //How much the extruder will be raised when traveling from between next probing points //#define Z_PROBE_SLED // turn on if you have a z-probe mounted on a sled like those designed by Charles Bell //#define SLED_DOCKING_OFFSET 5 // the extra distance the X axis must travel to pickup the sled. 0 should be fine but you can push it further if you'd like. //If defined, the Probe servo will be turned on only during movement and then turned off to avoid jerk //The value is the delay to turn the servo off after powered on - depends on the servo speed; 300ms is good value, but you can try lower it. // You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile. // #define PROBE_SERVO_DEACTIVATION_DELAY 300 //If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing, //it is highly recommended you let this Z_SAFE_HOMING enabled!!! #define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area. // When defined, it will: // - Allow Z homing only after X and Y homing AND stepper drivers still enabled // - If stepper drivers timeout, it will need X and Y homing again before Z homing // - Position the probe in a defined XY point before Z Homing when homing all axis (G28) // - Block Z homing only when the probe is outside bed area. #ifdef Z_SAFE_HOMING #define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28) #define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28) #endif #endif // ENABLE_AUTO_BED_LEVELING // The position of the homing switches //#define MANUAL_HOME_POSITIONS // If defined, MANUAL_*_HOME_POS below will be used //#define BED_CENTER_AT_0_0 // If defined, the center of the bed is at (X=0, Y=0) //Manual homing switch locations: // For deltabots this means top and center of the Cartesian print volume. #define MANUAL_X_HOME_POS 0 #define MANUAL_Y_HOME_POS 0 #define MANUAL_Z_HOME_POS 0 //#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing. //// MOVEMENT SETTINGS #define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E #define HOMING_FEEDRATE {10*60, 10*60, 4*60, 0} // set the homing speeds (mm/min) // default settings #define DEFAULT_AXIS_STEPS_PER_UNIT {1066.333333333336, 1066.333333333336, 2133.333333333333, 97.079122078} // default steps per unit for Ultimaker #define DEFAULT_MAX_FEEDRATE {30, 30, 30, 10} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {25,25,25,1000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot. #define DEFAULT_ACCELERATION 10 // X, Y, Z and E max acceleration in mm/s^2 for printing moves #define DEFAULT_RETRACT_ACCELERATION 20 // X, Y, Z and E max acceleration in mm/s^2 for retracts // Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing). // The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder). // For the other hotends it is their distance from the extruder 0 hotend. // #define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis // #define EXTRUDER_OFFSET_Y {0.0, 5.00} // (in mm) for each extruder, offset of the hotend on the Y axis // The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously) #define DEFAULT_XYJERK 8.0 // (mm/sec) #define DEFAULT_ZJERK 0.4 // (mm/sec) #define DEFAULT_EJERK 5.0 // (mm/sec) //====================================================================== ===== //=============================Additional Features=========================== //====================================================================== ===== // Custom M code points #define CUSTOM_M_CODES #ifdef CUSTOM_M_CODES #define CUSTOM_M_CODE_SET_Z_PROBE_OFFSET 851 #define Z_PROBE_OFFSET_RANGE_MIN -15 #define Z_PROBE_OFFSET_RANGE_MAX -5 #endif // EEPROM // The microcontroller can store settings in the EEPROM, e.g. max velocity... // M500 - stores parameters in EEPROM // M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily). // M502 - reverts to the default "factory settings". You still need to store them in EEPROM afterwards if you want to. //define this to enable EEPROM support //#define EEPROM_SETTINGS //to disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out: // please keep turned on if you can. //#define EEPROM_CHITCHAT // Preheat Constants #define PLA_PREHEAT_HOTEND_TEMP 180 #define PLA_PREHEAT_HPB_TEMP 70 #define PLA_PREHEAT_FAN_SPEED 255 // Insert Value between 0 and 255 #define ABS_PREHEAT_HOTEND_TEMP 240 #define ABS_PREHEAT_HPB_TEMP 100 #define ABS_PREHEAT_FAN_SPEED 255 // Insert Value between 0 and 255 //LCD and SD support //#define ULTRA_LCD //general LCD support, also 16x2 //#define DOGLCD // Support for SPI LCD 128x64 (Controller ST7565R graphic Display Family) //#define SDSUPPORT // Enable SD Card Support in Hardware Console //#define SDSLOW // Use slower SD transfer mode (not normally needed - uncomment if you're getting volume init error) //#define SD_CHECK_AND_RETRY // Use CRC checks and retries on the SD communication //#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder //#define ENCODER_STEPS_PER_MENU_ITEM 5 // Set according to ENCODER_PULSES_PER_STEP or your liking //#define ULTIMAKERCONTROLLER //as available from the Ultimaker online store. //#define ULTIPANEL //the UltiPanel as on Thingiverse //#define LCD_FEEDBACK_FREQUENCY_HZ 1000 // this is the tone frequency the buzzer plays when on UI feedback. ie Screen Click //#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 // the duration the buzzer plays the UI feedback sound. ie Screen Click // The MaKr3d Makr-Panel with graphic controller and SD support // [reprap.org] //#define MAKRPANEL // The RepRapDiscount Smart Controller (white PCcool smiley // [reprap.org] //#define REPRAP_DISCOUNT_SMART_CONTROLLER // The GADGETS3D G3D LCD/SD Controller (blue PCcool smiley // [reprap.org] //#define G3D_PANEL // The RepRapDiscount FULL GRAPHIC Smart Controller (quadratic white PCcool smiley // [reprap.org] // // ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: [code.google.com] //#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER // The RepRapWorld REPRAPWORLD_KEYPAD v1.1 // [reprapworld.com] //#define REPRAPWORLD_KEYPAD //#define REPRAPWORLD_KEYPAD_MOVE_STEP 10.0 // how much should be moved when a key is pressed, eg 10.0 means 10mm per click // The Elefu RA Board Control Panel // [www.elefu.com] // REMEMBER TO INSTALL LiquidCrystal_I2C.h in your ARUDINO library folder: [github.com] //#define RA_CONTROL_PANEL //automatic expansion #if defined (MAKRPANEL) #define DOGLCD #define SDSUPPORT #define ULTIPANEL #define NEWPANEL #define DEFAULT_LCD_CONTRAST 17 #endif #if defined (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER) #define DOGLCD #define U8GLIB_ST7920 #define REPRAP_DISCOUNT_SMART_CONTROLLER #endif #if defined(ULTIMAKERCONTROLLER) || defined(REPRAP_DISCOUNT_SMART_CONTROLLER) || defined(G3D_PANEL) #define ULTIPANEL #define NEWPANEL #endif #if defined(REPRAPWORLD_KEYPAD) #define NEWPANEL #define ULTIPANEL #endif #if defined(RA_CONTROL_PANEL) #define ULTIPANEL #define NEWPANEL #define LCD_I2C_TYPE_PCA8574 #define LCD_I2C_ADDRESS 0x27 // I2C Address of the port expander #endif //I2C PANELS //#define LCD_I2C_SAINSMART_YWROBOT #ifdef LCD_I2C_SAINSMART_YWROBOT // This uses the LiquidCrystal_I2C library ( [bitbucket.org] ) // Make sure it is placed in the Arduino libraries directory. #define LCD_I2C_TYPE_PCF8575 #define LCD_I2C_ADDRESS 0x27 // I2C Address of the port expander #define NEWPANEL #define ULTIPANEL #endif // PANELOLU2 LCD with status LEDs, separate encoder and click inputs //#define LCD_I2C_PANELOLU2 #ifdef LCD_I2C_PANELOLU2 // This uses the LiquidTWI2 library v1.2.3 or later ( [github.com] ) // Make sure the LiquidTWI2 directory is placed in the Arduino or Sketchbook libraries subdirectory. // (v1.2.3 no longer requires you to define PANELOLU in the LiquidTWI2.h library header file) // Note: The PANELOLU2 encoder click input can either be directly connected to a pin // (if BTN_ENC defined to != -1) or read through I2C (when BTN_ENC == -1). #define LCD_I2C_TYPE_MCP23017 #define LCD_I2C_ADDRESS 0x20 // I2C Address of the port expander #define LCD_USE_I2C_BUZZER //comment out to disable buzzer on LCD #define NEWPANEL #define ULTIPANEL #ifndef ENCODER_PULSES_PER_STEP #define ENCODER_PULSES_PER_STEP 4 #endif #ifndef ENCODER_STEPS_PER_MENU_ITEM #define ENCODER_STEPS_PER_MENU_ITEM 1 #endif #ifdef LCD_USE_I2C_BUZZER #define LCD_FEEDBACK_FREQUENCY_HZ 1000 #define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 #endif #endif // Panucatt VIKI LCD with status LEDs, integrated click & L/R/U/P buttons, separate encoder inputs //#define LCD_I2C_VIKI #ifdef LCD_I2C_VIKI // This uses the LiquidTWI2 library v1.2.3 or later ( [github.com] ) // Make sure the LiquidTWI2 directory is placed in the Arduino or Sketchbook libraries subdirectory. // Note: The pause/stop/resume LCD button pin should be connected to the Arduino // BTN_ENC pin (or set BTN_ENC to -1 if not used) #define LCD_I2C_TYPE_MCP23017 #define LCD_I2C_ADDRESS 0x20 // I2C Address of the port expander #define LCD_USE_I2C_BUZZER //comment out to disable buzzer on LCD (requires LiquidTWI2 v1.2.3 or later) #define NEWPANEL #define ULTIPANEL #endif // Shift register panels // --------------------- // 2 wire Non-latching LCD SR from: // [bitbucket.org] //#define SR_LCD #ifdef SR_LCD #define SR_LCD_2W_NL // Non latching 2 wire shift register //#define NEWPANEL #endif #ifdef ULTIPANEL // #define NEWPANEL //enable this if you have a click-encoder panel #define SDSUPPORT #define ULTRA_LCD #ifdef DOGLCD // Change number of lines to match the DOG graphic display #define LCD_WIDTH 20 #define LCD_HEIGHT 5 #else #define LCD_WIDTH 20 #define LCD_HEIGHT 4 #endif #else //no panel but just LCD #ifdef ULTRA_LCD #ifdef DOGLCD // Change number of lines to match the 128x64 graphics display #define LCD_WIDTH 20 #define LCD_HEIGHT 5 #else #define LCD_WIDTH 16 #define LCD_HEIGHT 2 #endif #endif #endif // default LCD contrast for dogm-like LCD displays #ifdef DOGLCD # ifndef DEFAULT_LCD_CONTRAST # define DEFAULT_LCD_CONTRAST 32 # endif #endif // Increase the FAN pwm frequency. Removes the PWM noise but increases heating in the FET/Arduino //#define FAST_PWM_FAN // Temperature status LEDs that display the hotend and bet temperature. // If all hotends and bed temperature and temperature setpoint are < 54C then the BLUE led is on. // Otherwise the RED led is on. There is 1C hysteresis. //#define TEMP_STAT_LEDS // Use software PWM to drive the fan, as for the heaters. This uses a very low frequency // which is not ass annoying as with the hardware PWM. On the other hand, if this frequency // is too low, you should also increment SOFT_PWM_SCALE. //#define FAN_SOFT_PWM // Incrementing this by 1 will double the software PWM frequency, // affecting heaters, and the fan if FAN_SOFT_PWM is enabled. // However, control resolution will be halved for each increment; // at zero value, there are 128 effective control positions. #define SOFT_PWM_SCALE 0 // M240 Triggers a camera by emulating a Canon RC-1 Remote // Data from: [www.doc-diy.net] // #define PHOTOGRAPH_PIN 23 // SF send wrong arc g-codes when using Arc Point as fillet procedure //#define SF_ARC_FIX // Support for the BariCUDA Paste Extruder. //#define BARICUDA //define BlinkM/CyzRgb Support //#define BLINKM /*********************************************************************\ * R/C SERVO support * Sponsored by TrinityLabs, Reworked by codexmas **********************************************************************/ // Number of servos // // If you select a configuration below, this will receive a default value and does not need to be set manually // set it manually if you have more servos than extruders and wish to manually control some // leaving it undefined or defining as 0 will disable the servo subsystem // If unsure, leave commented / disabled // //#define NUM_SERVOS 3 // Servo index starts with 0 for M280 command // Servo Endstops // // This allows for servo actuated endstops, primary usage is for the Z Axis to eliminate calibration or bed height changes. // Use M206 command to correct for switch height offset to actual nozzle height. Store that setting with M500. // //#define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1 //#define SERVO_ENDSTOP_ANGLES {0,0, 0,0, 70,0} // X,Y,Z Axis Extend and Retract angles #include "Configuration_adv.h" #include "thermistortables.h" #endif //__CONFIGURATION_H Wo muß ich den diese Werte jetzt für die Fräse anpassen? Ich bräuchte sozusagen nen Übersetzer von diesen Einstellungen zu Grbl...also Wo, wird Was Eingetragen. Vielen Dank schonmal...
>Hier mal meine Config.h die ich zum Druck benutze. Warum hast Du ihn nicht angehängt ? Bitte lies dir die GRBL-Wiki durch dort steht wie es geht: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Achtung verschiedene Befehle für verschiedene GRBL Versionen... Gruß Sven
Hallo zusammen, Ich habe mich mal ein wenig mit den Einstellungen für GRBL beschäftigt. Mein Englisch ist zwar sehr begrenzt aber zusammen mit dem Übersetzer ging es so... Als erstes habe ich mich mit der Referenzfahrt beschäftigt. Leider Erfolglos. Die Maschine fährt kurz los und bleibt ohne jeglichen kontakt nach 10-30 mm stehen. Die Endschalter(REF) habe ich nun auf AUX3 gelegt. Leider ohne Erfolg/Funktion. Einzelne Fahrbefehle und Schritte pro mm passen aber soweit. bin echt ratlos wie ich die Endschalter zum laufen bekomme.... LG,
Frank Schulze schrieb: > Als erstes habe ich mich mit der Referenzfahrt beschäftigt. Leider > Erfolglos. Die Maschine fährt kurz los und bleibt ohne jeglichen kontakt > nach 10-30 mm stehen. Also ich benutze keine Endschalter und damit keine Referenzfahrt. SerialComCNC verwendet den damit gewonnenen Maschinen-Nullpunkt auch nicht. Wie auch immer, beschäftige Dich mal mit den Einstellungen unter $5, $21 bis $27. Siehe auch hier: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9 Frank Schulze schrieb: > Die Endschalter(REF) habe ich nun auf AUX3 gelegt. Leider ohne > Erfolg/Funktion. Was soll denn AUX3 sein? Die Endschalter gehören an die mit "Limit XYZ Axis" bezeichneten Pins des Arduino. Siehe hier: https://github.com/grbl/grbl/wiki/Connecting-Grbl
Hallo Albert, ersteinmal vielen Dank für ein so großartiges Programm und das Du dies mit der allgemeinheit teilst. Das mit Aux 3 kahm mir auch seltsamm vor. Mir wurde ein Bild geschickt auf dem die Anschlußskizze mit ref schalter auf Aux zu sehen war. Ärgerte mich ein wenig da ich mein Display nicht mehr verwenden könnte. http://a.fsdn.com/con/app/proj/grblforramps14/screenshots/grblRamps.png Ich hatte mir auch schon überlegt ohne ref und end zu arbeiten. Gestern habe ich noch zum testen ein Programm gestartet und es lief zu meiner Zufriedenheit. $23=1 (homing dir invert mask:00000001) Bei dieser einstellung Blicke ich nicht so ganz durch. Meine Maschine muß X nach Links ins "-" fahren, Y nach Vorn ins minus und Z nach oben ins "+?" um nach hause zu fahren.Y könnte ich aber nach hinten ändern. Nun kann ich die Maschine erstmal fertig machen und dann die Feinheiten einstellen. LG, Frank
Frank Schulze schrieb: > $23=1 (homing dir invert mask:00000001) Bei dieser einstellung Blicke > ich nicht so ganz durch. Meine Maschine muß X nach Links ins "-" fahren, > Y nach Vorn ins minus und Z nach oben ins "+?" um nach hause zu fahren Um die Fahrtrichtung hier zu ändern benutze für die Maske die selbe Tabelle wie unter: $2 Step port invert mask:binary" auf der Configuring-Grbl-v0.9 Seite. Steht doch unter $23 alles beschrieben.
Hallo Albert, wie viele Zeilen HPGL Code kannst Du konvertieren? Mit meinem Muster (knapp 10000 Zeilen) stüzt das Program leider ab. Ich habe mir einen EggBot gebaut und wollte dein SerialComCNC zur Steuerung benutzen. Anbei eine HPGL Datei die sich nicht einlesen lässt wegen der Größe. Gruß Sven
Sven schrieb: > wie viele Zeilen HPGL Code kannst Du konvertieren? Bis zu 50.000 Zeilen müssten eigentlich gehen. Wieviel maximal werde ich mal testen. > Mit meinem Muster(knapp 10000 Zeilen) stüzt das Program leider ab. > Anbei eine HPGL Datei die sich nicht einlesen lässt wegen der Größe. Die Datei lässt sich im HPGL-Converter einlesen in in G-Code wandeln. Die Übernahme des G-Codes dauert aber anschliessend viel zu lange (ca. 6 Minuten) und das Converter Fenster schliesst sich nicht. Beides wird nächste Woche mit einer neuen Version behoben. Gruss Ulrich Albert
Albert M. > Beides wird nächste Woche mit einer neuen Version behoben. Prima - Danke, toll wäre noch wenn Du auch *.hpgl als Dateiendung zulässt - dann bräuchte man die Dateien nicht immer umbenennen (kann man im Inkscape leider nicht einstellen, bzw ich hab's im Code nicht gefunden)... Falls es jemanden interessiert, anbei der modifizierte Inkscape (0.91) HPGL-Konverter um die Ausgabe im geforderten Format zu machen (siehe Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" ). Einfach die Dateien im Verzeichnis (bei mir) C:\Program Files\Inkscape\share\extensions ersetzen. Gruß Sven
Sven schrieb: > Danke, toll wäre noch wenn Du auch *.hpgl als Dateiendung > zulässt Kein Problem. Sven schrieb: > Falls es jemanden interessiert, anbei der modifizierte Inkscape (0.91) > HPGL-Konverter um die Ausgabe im geforderten Format zu machen Sehr schön, das wird bestimmt die Inkscape Benutzer interessieren. Gruss Ulrich Albert
Anbei SerialComCNC Version 0.8b Change Log V0.8b ---------------- Die Verbesserungen beziehen sich besonders auf grosse Dateien: Übernahme von grossen Excellon oder HPGL Files vom Converter "Use Processed Data" erheblich beschleunigt (< 1 Sekunde bei 10.000 Zeilen). "Clear All" und "Clear Resp" Funktion erheblich beschleunigt. File Filter für HPGL Dateien erweitert (plt + hpgl). Sven schrieb: > wie viele Zeilen HPGL Code kannst Du konvertieren? Mehr als 100.000 Zeilen sind kein Problem. Gruss Ulrich Albert Homepage: http://www.serialcominstruments.com/
Hallo Albert, >Anbei SerialComCNC Version 0.8b leider bekomme ich beim HPGL-konvertieren eine Fehlermeldung "Temp File Read error" (Datei aus Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"). Danch kommt nur noch 'Please wait...'. Ist aber halb so schlimm: Ich habe hier: https://bugs.launchpad.net/inkscape/+bug/1409568 (Beitrag 14) einen aktuellen Inkscape (0.91) HPGL exporter gefunden, welcher auch die Stiftfarben exportiert, den ich zum GRBL Plotter GCode Exporter umgebastelt habe. D.h. Pen up/down wird zu M3/M5 exportiert mit anschließender Wartezeit G04 um dem Servo Zeit zu geben den Stift abzusenken. Die verschiedenen Stiftfarben werden zu Tx konvertiert, so dass man manuell im SerialComCNC den Stift wechseln kann. Im Inkscape müssen gleichfarbige Objekte in der gleichen Ebene liegen welche als 'Pen x' (x = Stiftnummer) umbenannt werden muss. D.h. für jede neue Farbe muss eine neue Ebene angelegt werden - eine schöne Idee des Autors, jeder Stift kommt nur einmal in Export vor. Einfach die drei Dateien ins Verzeichnis (bei mir) C:\Program Files\Inkscape\share\extensions kopieren. Dann gibt es eine neue Speicheroption 'GRBL Plotter file (*.nc)'. Gruß Sven
Sven schrieb: > leider bekomme ich beim HPGL-konvertieren eine Fehlermeldung "Temp File > Read error" Welche Windows Version benutzt Du? SerialComCNC schreibt nach dem Konvertieren der HPGL oder Excellon Dateien das Resultat als File (SerialComCNC.scc) temporär in C:/users/ Die beschriebene Fehlermeldung tritt auf wenn das Schreiben oder Lesen in C:/users fehl schlägt. Bei meinem Windows 7 funktioniert das, ich kann jetzt im Moment aber nicht testen ob z.B. Windows XP anstatt das Verzeichnis "Users" das Verzeichnis "Anwender" erwartet. Ich melde mich dazu später nochmal. .... Habs jetzt unter Windows XP getestet, da funktioniert es bei mir auch. Schau mal nach, ob das Verzeichnis "C:/users" bei Dir irgendwelche Schreib-Restriktionen hat. Alternativ speichere ich das File in das jeweilige Windows temp Verzeichnis, da ich vermeiden möchte, weitere Dateistrukturen anzulegen.
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
Hallo, Ich musste die limit pins umzuleiten auf AUX-3, Grbl verwendet "pin change interrupt" um den limit Status zu bestimmen, und original ramps limit pins unterstützen es nicht.. Z axe ist ausgetauscht mit Y, weil die Z hat Verbindungsstelle für zweier Motoren, und shapeoko hat eine doppelte Y Arsi
arsi schrieb: > Ich musste die limit pins umzuleiten auf AUX-3, Grbl verwendet "pin > change interrupt" um den limit Status zu bestimmen, und original ramps > limit pins unterstützen es nicht.. > Z axe ist ausgetauscht mit Y, weil die Z hat Verbindungsstelle für > zweier Motoren, und shapeoko hat eine doppelte Y Und was hat das alles mit SerialComCNC zu tun? Für GRBL bin ich und dieser Thread nicht zuständig, bitte diskutiere das in irgendwelchen GRBL Foren.
Angehängte Dateien:
-
IMAG0344_-_Kopie_-_Kopie.JPG
240 KB -
IMAG0345_-_Kopie_-_Kopie.JPG
270 KB -
IMAG0329_-_Kopie.JPG
300 KB
Vielen Dank für die Unterstützung bei meinem Projekt. Im Anhang ein paar Bilder. LG,Frank
Danke für die Bilder Frank, würde mich auch interessieren was die Anderen so mit dem Programm anstellen. Ist die folgende Erweiterung von SerialComCNC für euch interessant? Wenn man nur einfache Fräsarbeiten hat, wie mal eben einige Löcher Bohren oder einen Auschnitt fräsen, ist es lästig eine Zeichnung zu machen, diese in die CAM-Software zu importieren um den G-Code zu erhalten. Die Erweiterung würde eine Auswahl an Arbeitsvorgängen anbieten, wie z.B.: Drill, Line of Drills, Line, Rectangle, Circle und erwartet dann die Eingabe der Parameter/Koordinaten (XY, Frästiefe, Fräsgeschwindigkeit usw). Die gewünschten Vorgänge würden in eine Liste eingetragen, in G-Code gewandelt und in das Hauptfenster zum Fräsen kopiert.
Hallo Albert, ich fände die Schnell-Fräs-Optionen durchaus interessant. Ich würde mir spontan noch die Option für Rechecke mit abgerundeten Ecken wünschen (evtl. mit Eingabe des Eckenradius). Leider habe ich noch mit ein paar Ungenauigkeit meiner Käsefräse zu kämpfen...
Bohren von Lochraster mit Eingabe x und y Maße der Lage der Bohrungen und Größe des Rasterfeldes wäre sicher auch sehr interessant. Danke für deine Arbeit
Hallo Albert, solche funktionen sind immer gut. Ich habe noch ein weiteres Problem mit der Software. Als ich mein Bedienpult gefräst habe, ist die Maschine öfters beim ausfräsen einer Kontur in die falsche Richtung gefahren. Zum Glück immer in den Ausschuss. Erst bin ich von einem Fehler der Steuerung ausgegangen und habe alles überarbeitet. Nach einem weiteren Durchlauf passierte es aber wieder. Immer bei einem Richtungs-wechsel. Als ich nicht mehr weiter wusste habe ich das Fräsprogramm mal mit dem GRBL Controller gestartet und damit läuft alles Problemlos durch. Nun habe ich immer 2 Programme offen und verbinde für die Manuelle fahrt mit Deinem, weil der GRBL Controller bescheiden ist für das manuelle fahren und für den Automatik Ablauf starte ich den GRBL. Hast Du ev eine Idee woran das liegen kann?? Ein weiteres Problem ist der Automatik-abbruch. Warum nullt sich die Steuerung und man muß danach alles neu anfahren? Gibt es eine Möglichkeit die Automatik zu verlassen ohne den Nullpunkt neu anzufahren? Vieleicht mach ich ja auch was falsch. Beim Drucken zum Beispiel konnte man das Programm auch jederzeit anhalten und die Maschine verfahren. Drückte man nun wieder Start fuhr sie zum Programmpunkt zurück. So etwas finde ich sehr gut um Teile die man ausfräst kurz zu sichern und dann weiter ausfräsen zu lassen. LG, Frank
Frank Schulze schrieb: > ist die Maschine öfters beim > ausfräsen einer Kontur in die falsche Richtung gefahren. Zum Glück immer > in den Ausschuss. Wenn Du dabei gestoppt hast, weisst Du doch nicht wohin die Maschine weiter gefahren wäre. Vielleicht war das so schon richtig und Dein CAM Programm wollte das so? Hast Du Dein CAM schon mal simuliert? Wie auch immer, versuche das ganze mal mit einer Luftnummer (Z hochgefahren) und schau Dir dabei die Ausgabe im Graphic-Monitor an. Wenn im Graphic-Monitor der Fehler auch auftritt, sende mir bitte einen Screenshot, Dein NC-Programm mit der Beschreibung wo der Fehler Auftritt und der Zeichnung. Wenn im Graphic-Monitor alles stimmt, hast Du wahrscheinlich ein EMV-Problem, d.h. durch Störimpulse von ausserhalb wird die serielle Verbindung beeinträchtigt und G-Code Befehle werden nicht korrekt übertragen oder der Controller wird direkt beeinträchtigt. Frank Schulze schrieb: > Problem ist der Automatik-abbruch. Was genau meinst Du mit Automatik-Abbruch?
Moin, also... nehmen wir mal an ich habe mehrere Programmteile/Programme mit denen ich ein Teil bearbeiten möchte. Ich fahre den Nullpunkt für das Programm an und Starte Programm 1. Danach Programm 2 und merke nun ich habe mich mit dem Vorschub vertan oder wie im Fall meines Bedienpultes, die Maschine fährt Plötzlich in die falsche Richtung. Ich halte das Programm nun mit Programm-halt an und würde jetzt gern wieder auf meinen Nullpunkt fahren. Die manuelle verfahr-option steht mir aber in diesem Moment nicht zur Verfügung. Wenn ich jetzt auf Programm-Stop gehe, wird die Maschine auf der momentanen Position auf Null gesetzt, sodass ich mein Teil wieder neu anfahren muss. Wenn ich meinen Nullpunkt nun mit dem ersten Programmdurchlauf weg fräse, habe ich ein Problem. Zu dem Fehler: Ich habe die Seitenteile meines Bedienpultes mit einem 6mm Schrupfräser bearbeitet. Die 3eckigen Aussparungen habe ich in Z-2mm schritten ausgefräst da mein Motor sonst zu sehr Belastet wird. ( habe schon nen neuen) Nachdem ich teilweise schon 10-14 mm tief im Teil war fuhr die Maschine Plötzlich statt z.B. X-40 y-40 schräg nach x-40 Y0/-10 "gerade". Dieses Problem tauchte mehrmals auf und beschränkte sich nicht immer auf die gleiche Richtung. Auch tauchte es nicht immer an der gleichen stelle auf sondern sporadisch auch an anderen Positionen. Bis zu diesen Punkt hatte ich den Automatikablauf/Programmablauf nicht angehalten. Komischer Weise läuft aber genau das selbe Programm mit dem GRBL Controller Problemlos durch. Kann es ev. daran liegen das ein Satz nicht rechtzeitig übertragen wurde oder übersprungen wurde? was mir beim GRBL Controller aufgefallen ist, er braucht immer einen kleinen Momenent bis er den Befehl ausführt. Ich hoffe der Text verwirrt nicht all zu sehr, LG, Frank P.S: Ich werde aber bei gelegenheit den Fehler nochmal Simulieren.
@Frank In kurzen Worten: Du meinst also eine Programm-Restart Funktion die den gesetzten XYZ Nullpunkt intakt lässt und gleichzeitig das manuelle Bedienfeld wieder frei gibt. Kann ich in der nächsten Version einbauen. Nochmal zu den bei Dir sporadisch auftretenden Fehlern: Wenn es mit GRBL Controller läuft, bedeutet das nicht unbedingt dass in SerialComCNC ein Fehler vorliegt. Es ist ebenso eine prekäre Schnittstelle möglich auf die SerialComCNC empfindlicher reagiert. Dies hatte ich mal bei einem Arduino Clone, mit einem Programm war es ok, mit einem anderen sporadische Aussetzer. Hast Du den Luftnummer-Test versucht? Wie auch immer, mehr kann ich ohne Deinen G-Code zu testen nicht sagen. Bei mir treten auch bei langen Jobs keine Fehler auf, bei anderen anscheinend auch nicht, sonst hätte darüber hier schon was gestanden.
Angehängte Dateien:
-
SerialComCNC_Vorschau.jpg
150 KB
Hier mal eine Vorschau auf die neue Erweiterung "EasyJob" als CAM für Arme. EasyJob wird im Menue von SerialComCNC aufgerufen. Folgende Arbeitsvorgängen werden angeboten: Drill Hole, Line of Holes, Line, Rectangle, Circle. Diese Jobs werden in eine Liste eingetragen. Die Jobs sind innerhalb der Liste auch noch nachträglich verschiebbar. Für Rectangle und Circle kann eine Fräserradius-Korrektur für Innen oder Aussen oder Mitte fräsen eingestellt werden. Es können einzelne Jobs oder alle zusammen konvertiert werden. Bei der Konvertierung wird der G-Code erzeugt und in das SerialComCNC G-Code File Fenster zur Benutzung eingetragen. Das gezeigte Bild diente nur zum Test. Das Layout wird noch überarbeitet.
Hallo Albert, Vielen Dank für die Schnelle Rückmeldung und Danke schonmal für die zusätzliche Funktion die mir doch einiges an Arbeit spart. Ich habe den Test noch nicht gemacht. Ich denke da komme ich am Sonntag erst dazu. Heute habe ich erstmal meinen Bürstenlosen Motor eingebaut. Gibt es eigentlich die Möglichkeit den Motor-Regler/Servoanschluß für den Motor mit dem Ramps 1.4 zu betreiben? Es gibt ja die Möglichkeit Servos auf der Platine zu stecken...die Frage ist nur wie aufwendig das ist dies für den Regler zu konfigurieren. (http://www.ebay.de/itm/CHIRI-PRO-BL-ESC-50A-65A-SBEC-5A-5V-5-5V-6V-Governor-2-6Lipo-/181279299016?pt=LH_DefaultDomain_77&hash=item2a351695c8) Im Moment schalte ich den Motor über den Ramps1.4 ein. der Regler muß dazu auf null stehen und dann muß ich die Drehzahl von hand einstellen. LG,Frank
Guten Tag, du bist ja echt fix. Respekt. Die neue Funktionsvorlage sieht schon gut aus. Die Aufgaben der einzelnen Felder lassen sich gut erschließen. Ich hatte auch schon das Problem, dass ich einen Job abbrechen musste und nach der automatischen Nullung den Startpunkt neu anfahren musste. Wenn es für dich kein Problem wäre, ließe sich doch evtl. in den Einstellungen eine Option einrichten, um das Nullen nach Jobsreset zu unterbinden? Ich habe es bis jetzt so gemacht, dass ich mir vor dem Reset nach dem Halten die Position abgeschrieben habe und dann negativ wieder eingeben habe, um dann wieder zum Ausgangspunkt zu kommen... Ich hatte leider auch schon das Problem, dass mir der Fräser schräg vom Job abgehauen ist. Er lief dann leider in Werkstück. Es war zum Glück nur eine kleine Holzgravur. Das gerade bearbeitete Element war eine Ellipse... Ich hatte den GCODE auch in OpenSCAM erfolgreich getest. Bin aber nicht sicher ob es am SerialComCNC liegt, weil ich keine alternative geteset habe. Außerdem ist das schon ein paar Tage her, also wurde ein ältere Version verwendet (ich glaube 0.7). Wollte nur mitteilen, dass mir sowas auch schon passiert ist. Nur so nebenbei, bei einem anderen Test hat mir das Inkscape-Gcode-Tool Zeilen mit mehr als 49 Zeichen ausgegeben. Da wollte der Fräser auch schräg abhauen (er ist schräg über die Dimensonen des Gcodes hinaus gefahren und kurz vor dem Ende des Fahrwegs habe ich die Stromversorgung unterbrochen :-)), obwohl der GCODE in OpenSCAM keine Probleme machte. Habe dann Kommastellen reduzierte und irgenwann gings... Könnte natürlich auch an der GRBL Firmware liegen. Da es vielleicht im 2. Fall zum Bufferoverflow kam. Ich glaube eine Zeile darf max 49 Zeichen lang sein. Super Arbeit, mach weiter so.
Hier seht ihr eine Video-Vorschau vom neuen EasyJob Modus von SerialComCNC. Der EasyJob-Modus ist für einfache Fräs-Arbeiten und ersetzt CAD und CAM. Es können geometrische Figuren (Hole, Line of Holes, Line, Rectangle, Circle) erzeugt und parametrisiert werden, die dann autom. in G-Code überführt werden. https://www.youtube.com/watch?v=PAm-B0i21cY Gruss Ulrich Albert
...einfach Klasse... Freu mich schon darauf, damit zu Arbeiten. Denkst Du auch noch daran die Positionen bei einem Programm-abbruch nicht zu reseten? LG,Frank
Anbei SerialComCNC Version 0.8c Change Log V0.8c ---------------- Bei Not-Aus/Reset bleibt der XYZ-Nullpunkt erhalten und kann mit dem * Button (rechts neben dem Oberen Cont-Button) angefahren werden. Dabei wird zuerst zur Sicherheit die Z-Achse um 10 mm angehoben und erst bei erreichen von XY Null auf Z0 abgesenkt. Es darf dabei nach dem Not-Reset beliebig manuell verfahren werden. Fehler bei der Graphic-Darstellung und sonstige kleinere Bugs behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert Albert M. schrieb: > Bei Not-Aus/Reset bleibt der XYZ-Nullpunkt erhalten und kann > mit dem * Button (rechts neben dem Oberen Cont-Button) Ich habe das Program kurz testen können. Während eines Durchlaufs musste ich das Fräsprogram anhalten und habe "Program-halt" gedrückt. Die Maschine blieb stehen. Dann habe ich das Programm mit "Stop-file" abgebrochen und die Position hat sich wieder genullt. Ich habe auch versucht nach "Programm-Halt" die Maschine mittels dem kleinen Button rechts neben Continue zurück zu fahren. Auch im rechten "Manuell-Feld" hatte ich keine Funktion. Was könnte ich verkehrt gemacht haben? LG, Frank
Frank Schulze schrieb: > Ich habe auch > versucht nach "Programm-Halt" die Maschine mittels dem kleinen Button > rechts neben Continue zurück zu fahren. Der kleine * Button wird erst nach einem Not-Stop aktiviert (schwarzer Rahmen um den Button = aktiv). Die Vorgehensweise: NC-Programm laden, XYZ-Nullpunkt setzen, Programm starten, Halt/Cont nach belieben (dabei aber keine Nullfahrt möglich), Programm-Abbruch mit Stop, jetzt ist der kleine * Button aktiviert und die Maschine fährt bei Button-Click auf den ursprünglichen Nullpunkt zurück, auch nachdem sie event. manuell irgend wohin verfahren wurde. Wenn der ursprüngliche XYZ Nullpunkt erreicht ist, rechts den Set XYZ-Zero Button betätigen (entfällt bei der nächsten Version). Der komplette manuelle Bedienbereich ist immer während eines Programmlaufs gesperrt. Es ist mir jedoch noch ein Fehler aufgefallen, Z wird bei der Nullfahrt mit dem * Button nicht immer korrekt um 10 mm angehoben, also Vorsicht und bis zur Korrektur Z manuell etwas hochfahren. Das werde ich gleich mit einer neuen Version korrigieren.
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.
Hallo Albert, ich hatte vorhin nochmal mit der 0.8c getestet und hab es nicht hinbekommen. Wahrscheinlich stell ich mich nur zu doof an. ;) Programm Starten - OK Programm Halt - Maschine bleibt stehen - Stern nicht möglich Stop File - Meldefenster wegklicken/bestätigen und dann ist die Position weg :( Werde Morgen Früh mal die 08.c2 testen... ev hab ich was übersehen. Aber mal davon abgesehen... Super Arbeit... Wenn ich nich so ne kleine Lernschwäche hätte, würde ich mich auch mal mit Programieren beschäftigen. Im Moment arbeite ich mich gerade in Autocad ein. Das fällt mir schwer genug. Mit Sketchup komme ich super zurecht, nur leider stimmen die Maße beim Export als Dfx nicht mehr obwohl alles auf mm steht. Komischer Weise war beim Drucken immer alles ok. Naja, bin eben eher ein Praktiker und lerne durch Probieren. LG,Frank
@Frank Wenn Du die Vorgehesweise wie zu Version 0.8c2 einhälst funktioniert das. Optimal ist dies allerdings nicht, so dass bei der nächsten Version der beim Resetten von GRBL verlorene Weltkoordinaten-Nullpunkt mittels der ursprünglichen (von Set XYZ Zero) und den aktuellen Maschinenkoordinaten berechnet wird. Mit dem G92 G-Code Befehls werden die Weltkoordinaten danach sofort neu gesetzt und erscheinen so auch in der XYZ Anzeige. Auf XYZ Null zurückfahren geht dann mit dem kleinen * Button (Sicherheitshöhe Z = 10mm) oder mit dem * Null-Button rechts (Sicherheitshöhe einstellbar über die "Home Offs. Z0" Eingabe).
Anbei SerialComCNC Version 0.8d Change Log V0.8d ---------------- Internet-Check für neue Versionen (unter Menue Hilfe). Die Versions-Nr. wird dabei aus der Info in der SerialComCNC Web Seite extrahiert. Beim Not-Stop werden die aktuellen Koordinaten neu betrechnet und in die Anzeige eingetragen, sowie den Weltkoordinaten bekannt gemacht. Auf XYZ Null zurückfahren geht jetzt mit dem kleinen * Button (Sicherheitshöhe Z = 10mm) oder mit dem * Null-Button rechts (Sicherheitshöhe einstellbar über die "Home Offs. Z0" Eingabe Ungewollter Neustart eines G-Code File bei Betätigen des Stop Buttons während die Bearbeitung läuft jetzt unterbunden. Diverse Voreinstellung für die Achsen-Skalierung der Graphic. Die Schnittstelle/ComPort ist jetzt unempfindlich gegen Programm-Beenden ohne die Verbindung vorher geschlossen zu haben. Neueste Version GRBL 0.9i (Hex-File) zugefügt.
Folgende noch auftretende Probleme werden mit der nächsten Version korrigiert: Fehler nach Not-Stop während einer Makro-Ausführung. Fehler nach Not-Stop im Manual Process.
Change Log V0.8e ---------------- Fehler nach Not-Stop während einer Makro-Ausführung korrigiert. Fehler nach Not-Stop im Manual Process korrigiert. Sprache der Programm-Oberfläche wahlweise: Englisch / Deutsch. Auch während der Laufzeit änderbar. Einige Übersetzungen fehlen allerdings noch. Es müssen alle Dateien ins Installations-Verzeichnis kopiert werden. Die nächsten Versionen kommen mit einem eigenem Installations-Programm. Gruss Ulrich Albert http://www.serialcominstruments.com/
Ist ja wie Weihnachten :) Vielen,vielen Dank. Übrigends konnte ich die Maschine mit der Version 0.8d das erste mal auf den Nullpunkt zurück fahren. (allerdings auf die sogenannten Weltkoordinaten) Das Teil musste ich trotzdem neu anfahren. Da ich viele Teile aus einer Platte ausfräse, muss ich immer schauen wie ich Platztechnisch positioniere. Wenn ich dann abbrechen muss weil es einen Fehler gab (gestern zum Beispiel schaltete sich mein Motor nicht richtig ein - Reglerfehler) muss ich diesen Punkt neu finden. Ich habe ja, wie schon erwähnt, keine Ahnung wie Aufwendig das ist, so etwas zu Programieren. Deswegen hab ich jedes mal ein schlechtes Gewissen wenn ich Optionen Anfrage. ;) Ich stelle mir den Ablauf wie folgt vor: Teil anfahren - Startposition nullen Programm/File-Start - Maschine Startet Programm Bei einem Fehler - Programm HALT taste betätigen Nun wäre es zwingend erforderlich die exakte Startposition wieder zu erreichen.In der Anzeige stehen ja noch die Koordinaten, wie weit ich davon entfernt bin. Also weiter zum Ablauf: ( ich befinde mich noch im Programm-HALT ) - Das rechte manuelle Bedienfeld wird frei gegeben und ich kann die Maschine Manuell verfahren und/oder den Programm/Teil-Nullpunkt anfahren. - da das Programm noch auf HALT steht kann man nun entweder mit Continue das Programm fortsetzen und die Maschine fährt auf die letzte Programmposition zurück(nicht zwingend erforderlich), oder auf der Programm-Null_Position das Programm abbrechen. An dieser Stelle kann sich die Steuerung auch Reseten, da die Null nach dem Reset/ProgrammSTOP gleichzeitig die ProgrammStart/Teil Null ist. Ich hoffe, ich verlange nicht zuviel, LG,Frank
Frank Schulze schrieb: > Teil anfahren - Startposition nullen > Programm/File-Start - Maschine Startet Programm > Bei einem Fehler - Programm HALT taste betätigen > > Nun wäre es zwingend erforderlich die exakte Startposition wieder zu > erreichen.In der Anzeige stehen ja noch die Koordinaten, wie weit ich > davon entfernt bin. In der Beschreibung der 0.8d oben steht nichts von "Halt" drücken: Albert M. schrieb: > Beim Not-Stop werden die aktuellen Koordinaten neu betrechnet > und in die Anzeige eingetragen, sowie den Weltkoordinaten bekannt > gemacht. Auf XYZ Null zurückfahren geht jetzt mit dem kleinen * Button > (Sicherheitshöhe Z = 10mm) oder mit dem * Null-Button rechts > (Sicherheitshöhe einstellbar über die "Home Offs. Z0" Eingabe Mach einfach mal genau das was da beschrieben steht (also nicht Halt sondern Stop drücken), dann fährt deine Maschine auch nach einem Stop und drücken der * Taste auf die vorher gesetzte Nullposition zurück. Vor dem drücken des * Button (oben oder rechts) kannst Du auch noch manuell beliebig verfahren, da ja nach Stop die Bedienfläche rechts wieder freigegeben ist. Vor dem Drücken der * Taste im manuellen Bedienfeld unbedingt mit "Home Offs Z0" die Sicherheitshöhe einstellen. Bei einem Fehler (Motorausfall) wie von Dir beschrieben wird dann nach Neustart dein G-Code erneut vom vorne abgearbeitet (vom vorher gesetzten Nullpunkt). Bis zur vorherigen Fehlerstelle macht der Fräser dann zwar eine Luftnummer, aber das sollte vorerst ok sein:) Eine Funktionalität für "Halt" während des Programmlaufs, danach beliebiges Verfahren und nach "Cont" Wiederaufsetzen auf den Halt-Punkt wird es demnächst geben. Aber ich denke, Du kannst Dich mit der obigen Methode vorerst gut behelfen.
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.
Angehängte Dateien:
-
Fehler_SerialComCNC.jpg
43 KB
Hallo Albert, nachdem ich SerialComCNC_0.8e auf meinem Windows 7 PC installiert habe bekomme ich die im Bild zu sehende Fehlermeldung. Auch ein Neustart des Rechners hat nichts gebracht. Die Version 0.8d lief noch einwandfrei. Viele Grüße Herbert
@Herbert König Probier bitte mal die beiliegende Version aus (mit und ohne Admin Rechte). Wann tritt der Fehler auf? Ich arbeite auch unter Win7 und kann leider den Fehler nicht reproduzieren. Gruss Ulrich Albert
Hallo Albert, damit gehts! Vielen Dank und ein schönes Wochenende Grüße Herbert
Anbei SerialComCNC Version 0.9 Change Log V0.9 --------------- Der Button für die Funktion "Test Code" ist jetzt im Process Display angeordnet und die Funktion wurde automatisiert. Bei Betätigung wird der geladene G-Code sofort auf dem Arduino ausgeführt, allerdings ohne Signale an die Stepper-Driver auszugeben. Fehler im Code können damit festgestellt werden ohne die Fräse zu bewegen. Fehler bei Excellon-File Import. Eventuelle Kommas wurden bei Konvertierung nach G-Code nicht in Dezimalpunkte gewandelt. Aufruf des Windows-Rechners oder eines frei wählbaren Calculators. Programm-Layout mit wählbarem Farbschema: grau grau-blau grün-beige Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert, ist es mit viel Aufwand verbunden, bei Fenstermaximierung auf Bildschirmgröße, das Seitenverhältnis der Grafikvorschau zu erhalten. Im Moment kann man ja das Fenster noch nicht bildschirmfüllend maximieren? Ich hoffe, daß ich einigermaßen verständlich erklärt habe was ich meine. Viele Grüße Herbert
Herbert König schrieb: > ist es mit viel Aufwand verbunden, bei Fenstermaximierung auf > Bildschirmgröße, das Seitenverhältnis der Grafikvorschau zu erhalten. > Im Moment kann man ja das Fenster noch nicht bildschirmfüllend > maximieren? Das ist keine Vorschau, sonder die Realtime-Darstelung der Fräser-Bewegung. Durch eine Vergrösserung des Grafikfensters erhält man auch nicht besonders mehr Information. Event. kommt ja zu der jetzigen XY-Verschiebung der Grafik per Mouse noch eine Zoom-Möglichkeit.
Hallo Albert, gestern habe ich mal die Probfunktion getestet und bin nun etwas verwundert. Bis jetzt bin ich davon ausgegangen, dass ich die Prob mit bekannter Höhe auf den Tisch bzw auf das Werkstück stelle und antaste. Danach sollte der Z-Wert / Nullpunkt korrekt eingestellt sein. Beispiel: das Werkstück ist 5mm hoch, die Prob ist 20mm hoch und steht auf dem Werkstück. Der Fräser fährt nach Antasten der Prob 10mm hoch, dann sollte doch der Z-Wert doch auf 30mm stehen. Warum soll ich also das Werkstück noch mal antasten? Was hat es mit den F2, F5 und F10 aufsich? Gruß MartinM
MartinM schrieb: > Bis jetzt bin ich davon ausgegangen, dass ich die Prob mit bekannter > Höhe auf den Tisch bzw auf das Werkstück stelle und antaste. Danach > sollte der Z-Wert / Nullpunkt korrekt eingestellt sein. Es wird bei der erstmaligen Einrichtung der Probe davon ausgegangen, dass die Höhe der Probe nicht genau bekannt ist, was gerade für den Schaltpunkt selbstgebauter Probes zutrifft. Wenn Du die genaue Höhe der Probe (Schaltpunkt) bereits kennst, kannst Du diesen Wert natürlich direkt in Einstellungen/Probe/Probe_Höhe eintragen und mit "Set" F2 bis F10 die Anfahrgeschwindigkeit (Feed) auf die Probe einstellen, die dann rechts unter "P-Feed mm/min) angezeigt wird. Die einmal eingetragene Probe Höhe bleibt auch nach Beenden des Programms erhalten und wird im "Manuellen Prozess" Feld angezeigt. Danach brauchst Du also jedesmal (also auch nach Programm-Neustart) nur die Probe auf das (neue) Werkstück setzen und "P" (Probe) drücken, das Werkzeug tastet jetzt die Probe an und fährt hoch. Danach verfährst Du auf deinen XY-Nullpunkt und drückst "UP" (Use Probe) und das Werkzeug fährt auf Z0 herunter und Du kannst den Button "Setze XYZ Null" betätigen. Falls Du dann nochmal verfahren möchtest ist das kein Problem, der XYZ Nullpunkt bleibt ja erhalten. Siehe dazu auch unter "Probe" in der Hilfe.
Angehängte Dateien:
Anbei SerialComCNC Version 0.9a Change Log V0.9a ---------------- Es wurden 3 Buttons ( >X0 , >Y0 , >Z0 ) zugefügt. Damit können die Achsen auch getrennt auf Null-Position gefahren werden. Buttons 0,1 und 0,01 wurden in der Version 0.9 versehentlich vertauscht. Kleinere Fehler bei der Farbzuordnung beim wählbaren Farbschema behoben. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert. danke für sie schnelle Anwort, jetzt ist es auch mir klar, was gemeint ist. Weiter so, super Programm! Gruß MartinM
Hallo Albert, auch auf die Gefahr, dass ich nerve, möcht ich Dich fragen, ob eine automatische Antastung in X und Y-Richtung auch möglich ist. Also sowas in der Art "G38.2 X-10 F10". Dann könnte man damit ja einen 3D-Kantentaster verwirklichen. Technisch ist das leicht umzusetzen, gibt es bei Ebay als Kantentater mit LED. LED raus Kabel mit Stecker dran fertig. Gruß MartinM
MartinM schrieb: > gibt es bei Ebay als Kantentaster mit LED Hast Du Dir auch mal die Schaftdurchmesser (10 bis 20 mm) angesehen? Die kann man auf einer Hobby-Fräsmaschine nur schwer oder garnicht einspannen.
Hallo zusammen, Das mit dem Kantentaster finde ich eine gute Idee. Auf welche pins des Atmega/Ramps1,4 setzt man den auf? Ich habe aber noch ein weiteres Problem. Ich kann leider mit den Weltkoordinaten überhaupt nichts anfangen. Nach einem Programm Abbruch kann ich nun die Null Position anfahren, die Maschine fährt aber auf die "Welt 0", also auf den Punkt, auf dem sie stand als ich sie eingeschaltet habe. Meine Werkstück Null ist somit wieder weg und ich muss mir diesen Punkt aufs neue suchen.( Falls er nicht beim ersten Durchgang weg gefräst wurde) Bitte,bitte, bitte...gib mir eine Möglichkeit problemlos zu meinem Werkstücknullpunkt, an dem ich das Programm gestartet habe zurück zu kehren. LG,Frank
Hallo Albert, die Kantentaster von Ebay waren nur als Beispiel für die technische Umsetzung gemeint. Da ich selbst nur eine ER11-Spannzange habe kommen die für mich auch nicht in frage. Ich würde mir selbst eine Drehen ( Kunststoffschaft in die Spannzange und eine Kugel als elek.Kontakt unten dran), das Werkstück würde ich dann an Masse angeschliessen. Radius der Kugel eintragen und somit X- und Y-Achse Nullen. Aber noch mal zurück zum Z-Probing. Wenn der Fräser die Z-Probe berührt hat, fährt er danach 10mm nach oben und im Display steht dann 10.000mm. Ich würde aber erwarte, wenn meine Probe mit 20.000mm angegeben ist, dass dann im Display 30.000mm steht. Damit bräuchte ich den UP-Button nicht mehr und würde die Arbeitsschritte UP anklicken, warten bis Z-Achse runtergefahren ist und dann Z-Achse Nullen einsparen. Gruß MartinM
Hallo Albert, nachdem ich meine Fräsmaschine fertig gebaut habe, habe ich dein Programm getestet, es funktioniert im großen Umfang auf Anhieb. Der Haken ist: das Programm hat keine Werkzeugskorrektur (Txx und M06) und ist somit für CNC-Fräser nicht optimal. Da kannst du nicht dafür, weil es im grbl nicht implementiert ist. Schade. Gruß Tany
Frank Schulze schrieb: > Nach einem Programm Abbruch > kann ich nun die Null Position anfahren, die Maschine fährt aber auf die > "Welt 0", also auf den Punkt, auf dem sie stand als ich sie > eingeschaltet habe. Bei mir fährt nach einem Stop, die autom. Reset-Prozedur abwarten und dann Click auf * die Maschine immer auf den mit "Set XYZ Zero" eingestellten ursprünglichen Nullpunkt zurück. Ich habe jetzt 1 Stunde unter immer neuen Konditionen probiert und es wird immer korrekt auf den eingestellten Nullpunkt zurückgefahren. Ich werde das aber noch weiter untersuchen. Hat noch jemand dieses Problem? MartinM schrieb: > Aber noch mal zurück zum Z-Probing. Das werde ich nochmal überdenken. Tany schrieb: > Der Haken ist: das Programm hat keine Werkzeugskorrektur (Txx und M06) > und ist somit für CNC-Fräser nicht optimal. Da kannst du nicht dafür, > weil es im grbl nicht implementiert ist. Schade. Ja Schade. Leider kann ich mich auch nur auf das stützen was GRBL an Funktionen anbietet.
An die Admins Welcher Idiot hat die Thread Überschrift geändert von ATMega auf Z80? Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit Z80 Wenn sich hier jeder so einhacken kann und Thread-Überschriften nach Belieben manipulieren kann, wird es wohl Zeit dass ich Microcontroller.net verlasse. Laufend werden auch wie von Geisterhand meine gerade eingegebenen Texte hier verändert. Wenn ich A T M G A eingebe wird diese sofort wie von selbst in ZetAchtzig verändert. Ich hab jetzt hier die Schnautze voll! Grsuus Ulrich Albert
@Ulrich ist / war meines wissens ein April Scherz des Forumbetreibers global einige Prozessorbezeichnungen zu vertauschen vlG Charly geht auch mit der Autokorrektur in Office prima, der in die aendern und umgekehrt, die Sekraetaerin wird verzweifeln ;)
Hallo Albert, ich habe es heute tatsächlich geschaft nach einem Fräserbruch meinen Nullpunkt wieder an zu fahren. Ich glaubte das teil schon verloren und probierte denoch die Nullfahrt. Und siehe da... er fuhr zum Startpunkt. Ich werde es nochmal testen, denn seither habe ich die Achsen separat Achse für Achse beim anfahren genullt da diese nicht immer auf dem gleichen Punkt lagen. Ev gibt es einen Unterschied zwischen XYZ Null und achsen einzeln nullen. LG, ein sehr zufriedener Frank
Angehängte Dateien:
-
IMAG0379.JPG
280 KB -
IMAG0378.JPG
170 KB -
IMAG0377.JPG
170 KB -
IMAG0382.JPG
170 KB
ertappt... Hallo Albert, Wir hatten es letztens davon, das die Maschine sporadisch falsch fährt. Mir ist das immer wieder mal passiert, aber es waren kleine Teile und somit nicht der Rede Wert. Von einem Gcode-Fehler ist zu 200% nicht auszugehen da ich z.B. mit einem Programm schon mehrere Teile ausgefräst habe und es auch nicht immer an der gleichen Stelle auftritt. Gestern war es besonders Ärgerlich da es nicht nur ein großes Teil war, sondern die Maschine nach über einer Stunde Fräszeit durch das fertige Teil gefahren ist. Zum Glück mit der ersten Zustellung beim Teil Ausschneiden. Ich habe nicht abgebrochen und einfach weiterlaufen lassen. Wie man auf den Bildern sehen kann, ist die Maschine von rechts Mitte Teil nach Oben Mitte Teil gefahren und hat die rechte obere Ecke einfach ausgelassen. Also keine Falsche Koordinate angefahren sondern einfach Programmpunkte/Koordinaten ausgelassen/übersprungen. Großes zittern bei der nächsten Zustellung und tatsächlich fährt die Maschine bei den nächsten 2 durchläufen richtig. Großes Fragezeichen??? Störungen bei der Übertragung schließe ich eigentlich aus, da dass USB Kabel direkt beim Board aus der Maschine raus kommt und ohne Umwege in den Rechner geht. Vieleicht ist die Übertragung zu schnell, sodas Sätze übersprungen werden? Ich kenne mich da leider überhaupt nicht aus. LG Frank
Albert M. schrieb: > An die Admins Es gibt nur einen. Es war der 01.04. als Albert M. schrieb: > Welcher Idiot hat die Thread Überschrift geändert von ATMega auf Z80? Wer hat Java erfunden? Ein kleiner Tipp: du solltest nicht allzu spassbefreit und gereizt durchs Leben gehen...
Lothar Miller schrieb: > Es war der 01.04. als Albert M. schrieb: >> Welcher Idiot hat die Thread Überschrift geändert von ATMega auf Z80? > Wer hat Java erfunden? > Ein kleiner Tipp: du solltest nicht allzu spassbefreit und gereizt > durchs Leben gehen... Lothar, ich bin bestimmt der letzte der nicht für einen Spass zu haben ist. Aber in dem Moment hatte ich, wie andere bestimmt auch, einen dicken Hals :)
Frank Schulze schrieb: > Ich habe nicht abgebrochen und einfach weiterlaufen lassen. Wie man auf > den Bildern sehen kann, ist die Maschine von rechts Mitte Teil nach Oben > Mitte Teil gefahren und hat die rechte obere Ecke einfach ausgelassen. > Also keine Falsche Koordinate angefahren sondern einfach > Programmpunkte/Koordinaten ausgelassen/übersprungen. Da hättest Du besser abgebrochen und Dir im G-Code Fenster angesehen ob eine Fehlermeldung angezeigt wurde. Ebenso hättest Du im Monitor/Prozess Fenster die letzten Befehle/Werte ansehen können. Frank Schulze schrieb: > Großes zittern bei der nächsten Zustellung und tatsächlich fährt die > Maschine bei den nächsten 2 durchläufen richtig. Das der Fehler bei Dir sporadisch Auftritt ist eher ein Zeichen von EMV-Störungen. Frank Schulze schrieb: > Vieleicht ist die Übertragung zu schnell, sodas Sätze übersprungen > werden? Das halte ich für sehr unwahrscheinlich. Im Programm wird vor Absenden eines neuen G-Code Befehl geprüft ob der letzte Befehl bereits abgearbeitet wurde und der neue schon in den Eingangs-Puffer passt. Übersprungen werden oder zu schnell sein kann da nichts. Und wenn würde da eher ein systematischer Fehler auftreten, also beim gleichen G-Code File immer an der selben Stelle. Als sonstige mögliche Fehlerursachen kommen in Frage: EMV-Störungen in Deiner Elektronik oder von aussen (Spikes im Netz), Probleme mit dem USB/Seriell Wandler auf dem Arduino Board, Stromversorgung der Elektronik. Wissenswert dazu ist auch, obwohl das eher für systematische Fehlerbilder zutrifft, dass GRBL bei einem nicht akzeptierten Zeichen/Befehl den kompletten Befehlsatz verwirft, also alle in der Zeile stehenden korrekten Code-Segmente. Da ist Vorsicht geboten, da manche CAM-Software G-Code mit Befehlen produziert die in GRBL nicht zulässig sind. GRBL unterstützt ja nur ein Subset der möglichen G-Code Befehle. Wenn man da nicht sicher ist, sollte das G-Code File zuerst mal im Test-Mode durchlaufen und das Ergebnis im G-Code Fenster geprüft werden.
Angehängte Dateien:
-
SerialComCNC__preview.jpg
430 KB -
SerialComCNC__preview2.jpg
180 KB
Hier eine neue Vorschau auf den EasyJob Modus. Der EasyJob-Modus ist für einfache Fräs-Arbeiten gedacht und ersetzt dabei CAD und CAM. Es können folgende geometrische Figuren/Jobs erzeugt und parametrisiert werden, die dann autom. in G-Code konvertiert und in das Hauptprogramm übertragen werden. Drill Hole : Einfache Bohrung mit Fräser-Durchmesser Drill Line of Holes : Eine Reihe von Löchern mit Fräser-Durchm. Line : Eine Linie, Fräser mittig, links, rechts Rectangle : Rechteck, Fräser mittig, aussen, innen Rounded Rectangle : Rechteck runde Ecken, sonst wie Rechteck Circle : Kreis, Fräser mittig, aussen, innen Line of Circles : Reihe von Kreisen, sonst wie Kreis Rectangular Pocket : Rechteck-Tasche, Fräser innen Rect. Rounded Pocket : Rechteck-Tasche mit runden Ecken Circular Pocket : Kreistasche, Fräser innen Die Jobs werden in eine Liste eingetragen und können einzeln oder zusammen in G-Code überführt werden. Optional kann eine Graphik der Jobs als Vorschau zur Überprüfung der Einstellungen angezeigt werden (siehe Bild oben, kleine Kreuze = Drill Line of Holes). Die Job-Liste ist auch noch nachträglich frei editierbar und lässt sich zur weiteren Verwendung speichern. Voll Funktionsfähig sind zur Zeit bereits Drill Hole, Drill Line of Holes, Line, Rectangle und Circle. Es ist noch viel zu tun :) Schon mal frohe Ostern! Gruss Ulrich Albert http://www.serialcominstruments.com/
Moin, Frank Schulze schrieb: > Wir hatten es letztens davon, das die Maschine sporadisch falsch fährt. > Mir ist das immer wieder mal passiert, aber es waren kleine Teile und > somit nicht der Rede Wert. Von einem Gcode-Fehler ist zu 200% nicht > auszugehen da ich z.B. mit einem Programm schon mehrere Teile ausgefräst > habe und es auch nicht immer an der gleichen Stelle auftritt. > Gestern war es besonders Ärgerlich da es nicht nur ein großes Teil war, > sondern die Maschine nach über einer Stunde Fräszeit durch das fertige > Teil gefahren ist. Zum Glück mit der ersten Zustellung beim Teil > Ausschneiden. das Problem kann ich mit GRBLFeeder/GCodeSender oder wie das jetzt heißt als Frontend bei meinem GRBL-MF70-Umbau ebenfalls bestätigen. Bei der 0.8er trat es bei mir sporadisch auf, mit der aktuellen hatte ich es zweimal in zwei Jobs, hatte das dann zurückgeflasht und mich geärgert. Ich kann auch bestätigen, dass das mit 99%iger Wahrscheinlichkeit nicht mit der seriellen Verbinung zusammen hängt. Der GRBL scheint wohl seinen RAM zu korrumpieren oder sowas. Bei mir sieht das dann so aus, dass die Fräse einen Versatz fährt und anschließend weiterläuft, als wär nix gewesen. Für die Theorie spricht auch, dass die Maschine danach bei mir falsche Arbeitskoordinaten hatte. Der Fehler tritt scheinbar auch häufiger auf, wenn ein G92 (Bezugspunkt) gesetzt ist. OT: Ich hab vor einiger Zeit mal ein I/O-Board für die Verwendung mit GRBL angefangen. Das implementiert auf einem Mega32U2 einen virtuellen COM-Port und stellt acht Open-Collector-Outs, acht optisch getrennte Inputs und zwei Relaisausgänge zur Verfügung. Wenn ich mal wieder dazu komme an der Firmware weiterzuarbeiten, wird man die Eingänge auch auf Key-Events mappen können(zB F13..F20). Ich werde das mal hier im Wiki dokumentieren. Wäre vielleicht was, ums in das Frontend zu integrieren, falls das Board hier auf Interesse stößt. Ich habs damals entworfen, weil ich keine Lust auf Aluspäne in der Laptoptastatur habe.
@Frank Schulze + Andreas Lang In den Englischen Foren findet sich dazu folgendes: @CaptainFeature : Yes it's highly likely your energy saving feature is causing the issue. It's recommended to disable all of these when running a job. Antwort dazu: After switching off the energy saving stuff of my laptop everything runs smoothly. Thanks for your support. @SixthGenie : I also noticed that the whole USB - Arduino - CNC-Shield thing is quite sensitive to fluorescent lamps being switched on and off. I definively will also try a shielded usb cable as chamnit suggested. Ausserdem werden dort einige Fälle diskutiert wo die langen Endschalterkabel als Antennen für Störimpulse ausgemacht wurden, sowie Fälle wo durch einschalten von elektrischen Geräten in der Nähe Probleme auftraten. Für meine These, dass ein EMV-Problem vorliegt spricht auch, dass bei mir die geschilderten Probleme noch nie aufgetreten sind. Und das trotz erheblich langer Testzeiten, die eure Fräs-Zeiten sicherlich um ein mehrfaches übertreffen. Im übrigen benutze ich keine Endschalterkabel, die ja ansonsten ganz ungeschützt direkt an einem Arduino-Port liegen.
Hallo Albert, nein, ich habe keine CNC-Fräse zuhause und nutze somit Dein Programm (noch) nicht. Kann sich aber schnell mal ändern :-) Ich steh beruflich täglich an einer erwachsenen CNC-Fräse mit Heidenhain-Steuerung. Dein "EasyJob" macht ja schon die ersten Schritte in diese Richtung. Evtl. findest Du ein paar Inspirationen hier im Handbuch der Heidenhain-Steuerung: http://content.heidenhain.de/doku/tnc_guide/pdf_files/TNC400/280476-xx/bhb/340_135-17.pdf Der für Dich interessante Teil steht wohl ab Seite 285 bei den Zyklen für Kreis- und Rechtecktaschen und Seite 210 für die Bohrzyklen. Vielleicht ist ja was für Dich dabei... Viele Grüße Gerhard
Gerhard W. schrieb: > Evtl. findest Du ein paar Inspirationen hier im > Handbuch der Heidenhain-Steuerung: > http://content.heidenhain.de/doku/tnc_guide/pdf_files/TNC400/280476-xx/bhb/340_135-17.pdf Danke für den Verweis auf die interessante Lektüre. Daraus hab ich weitere Ideen für den EasyJob Modus in meinem Programm: Circle Segment : Teilkreis (Fräser-Durchm.) Circular Pocket Isle : Kreis-Tasche mit Insel Circle Segment Pocket X : Teilkreis-Tasche (Teilkreis-Nut) Holes on Circular Orbit : n Bohrungen (Fräser-Durchm.) auf Kreisbahn Holes on Circular Segment: n Bohrungen (Fräser-Durchm.) auf Teilkreis Circ. Pockets on Orbit : n Kreis-Taschen auf Kreis Circl.Pockets on Orb.Segm: n Kreis-Taschen auf Teilkreis Die bisher fertigen/geplanten: Drill Hole : Einfache Bohrung mit Fräser-Durchmesser Drill Line of Holes : Reihe von n Löchern mit Fräser-Durchm. Line : Eine Linie, Fräser mittig, links, rechts Rectangle : Rechteck, Fräser mittig, aussen, innen Rounded Rectangle : Rechteck runde Ecken, sonst wie Rechteck Circle : Kreis, Fräser mittig, aussen, innen Line of Circles : Reihe von n Kreisen, sonst wie Kreis Rectangular Pocket : Rechteck-Tasche, Fräser innen Rect. Rounded Pocket : Rechteck-Tasche mit runden Ecken Circular Pocket : Kreis-Tasche Damit lassen sich einzeln oder durch Kombination der Jobs ein Grossteil der Standard-Fräsarbeiten ohne zusätzliche CAD und CAM Software schnell erledigen. Gruss Ulrich Albert
Hallo Albert, bei einer Tasche kann man oft, je nach Material, nicht mit dem Fräser senkrecht ins Material tauchen. Entweder der Fräser mag es nicht, es gibt grausige lange Späne, die sich um den Fräser wickeln, oder der Schnittdruck wird einfach zu stark für ne einfache Hobbymaschine. Ich benutze daher vor dem Taschen-Zyklus einen der folgenden Zyklen, einfach um am Einstechpunkt der Tasche das Material raus zu bekommen: - Zyklus 208 Bohrfräsen auf Seite 251 - Zyklus 210 Nut pendelnd auf Seite 300 Den Unterschied macht dabei die schräge Rampe aus, auf der der Fräser fährt. Zum Bohren verwende ich eigentlich immer den Zyklus 203 auf Seite 245. Der Vorteil dieses Bohrzyklus ist das Spanbrechen alle paar Millimeter. Viele Grüße Gerhard
Gerhard W. schrieb: > Zum Bohren verwende ich eigentlich immer den Zyklus 203 auf Seite 245. > Der Vorteil dieses Bohrzyklus ist das Spanbrechen alle paar Millimeter. Das macht SerialComCNC im EasyJob Modus bereits. Ist beim Bohren eine Zustellung angegeben, so fährt der Bohrer nach jeder Zustellung aus dem Bohrloch hinaus, damit Späne aus den Loch entfernt werden. Gerhard W. schrieb: > bei einer Tasche kann man oft, je nach Material, nicht mit dem Fräser > senkrecht ins Material tauchen. Da hatte ich auch bereits ein schräges Eintauchen auf die Zustell-Ebenen vorgesehen. Das gleiche gilt für die Kreistaschen.
Hallo Albert, gestern habe ich versucht eine QuickCam Pro 9000 von Logitech zur Anzeige in SerialComCNC zu bewegen, leider ohne Erfolg. Sie wurde vom Betriebssystem als Webcam erkannt und man konnte Sie auch benutzen, doch SerialComCNC meinte, dass keine Webcam vorhanden sei. Was mache ich falsch? Ich weiß, dass Du gerade dabei bist EasyJob zu verbessern, ich möchte aber das Thema Z-Probing und Kantentaster noch mal hervorkramen. Es wäre schön, wenn man auch die X- und Y-Achse nullen könnte. Ebenso wäre es möglich den Mittelpunkt einer Bohrung mittels Kantentaster zu finden. Wenn man den Radius/Durchmesser ein gibt, sollte man doch mit zwei Messpunkten den Mittelpunkt berechnen können. Das alles könnte man in einen Setupdialog durchführen um die eigentliche Bedienoberfläche nicht zu überfrachten. Gruß MartinM
MartinM schrieb: > gestern habe ich versucht eine QuickCam Pro 9000 von Logitech zur > Anzeige in SerialComCNC zu bewegen, leider ohne Erfolg. Sie wurde vom > Betriebssystem als Webcam erkannt und man konnte Sie auch benutzen, doch > SerialComCNC meinte, dass keine Webcam vorhanden sei. Was mache ich > falsch? Alle 7 von mir getesteten Webcams diverser Hersteller, auch Logitech, bis hin zur 9 Euro Endoskop Stiftcam haben bei mir funktioniert. Das Erkennen einer Webcam kann schon mal was dauern. Mit einem Rechtsclick auf das schwarze Kästchen links neben Start-Button im Video-Bereich ist der passende Treiber auszuwählen (siehe Hilfe). Ansonsten benutze ich für Video eine fertige freie Delphi-Komponente zu ich keinerlei weiteren Support für die Akzeptanz diverser Treiber anbiete. MartinM schrieb: > ich möchte aber das Thema Z-Probing und Kantentaster noch mal hervorkramen. Das spricht Du jetzt zum mind. 3. Mal an. Glaube mir, das ich alle Info's und Wünsche von Anwendern notiere. Beim Kantentaster finde ich bis jetzt keine akzeptable oder bezahlbare Konstruktion für Hobby-Fräsen. Also ist das für mich nicht aktuell. MartinM schrieb: > Ebenso wäre es > möglich den Mittelpunkt einer Bohrung mittels Kantentaster zu finden. > Wenn man den Radius/Durchmesser ein gibt, sollte man doch mit zwei > Messpunkten den Mittelpunkt berechnen können. Woher willst Du denn mit Bestimmtheit sagen können, dass Du gerade genau an den Stellen des grössten Durchmessers misst? Es sind mind. 3 Kantenmessungen erforderlich um einen beliebigen Kreis zu bestimmen und damit hast Du 3 Gleichungssysteme. Google mal unter "Kreis mit 3 Punkten bestimmen".
Angehängte Dateien:
-
Clipboard01.jpg
12 KB
Sorry wenn ich nerve! Zum Kantentater hab ich mir ein paar Gedanken gemacht und wie ich finde auch eine brauchbare Lösung gefunden. Ich hab mir eine ER11 Spannzange aus Pomm gedreht und einen abgebrochenen Fräser verkehrt herum eingespannt. Krokoklemme an den Fräser und ans Werkstück fertig. Erste Tests waren vielversprechend.
MartinM schrieb: > Zum Kantentater hab ich mir ein paar Gedanken gemacht und wie ich finde > auch eine brauchbare Lösung gefunden. Ich hab mir eine ER11 Spannzange > aus Pomm gedreht und einen abgebrochenen Fräser verkehrt herum > eingespannt. Krokoklemme an den Fräser und ans Werkstück fertig. Erste > Tests waren vielversprechend. Genau sowas ist für mich keine akzeptable Lösung. Leute die Kunstoff oder Holz fräsen, können damit nichts anfangen. Bei Metall-Werkstücken muss man fest daran glauben, dass bei Berührung sofort ein elektrischer Kontakt erfolgt, was bei erodierten/oxidierten Oberflächen nicht immer gegeben ist. Wenn dann der Taster bricht, wird die Schuld auf die Software geschoben.
Tach, tach und vielen Dank für SerialComCNC ... Wenn ich einen Wunsch äußern dürfte, dann wäre es die Funktion "Gewindewirbeln/Gewindefräsen" im EasyJob-Modul. Sich per Knopfdruck einen Satz Gewinde ins Werkstück schneiden lassen zu können, wäre schon sehr, sehr sportlich .. ;) Nur das Beste und Danke für alles, Tillmann
Tillmann schrieb: > Wenn ich einen Wunsch äußern dürfte, dann wäre es die Funktion > "Gewindewirbeln/Gewindefräsen" im EasyJob-Modul. > > Sich per Knopfdruck einen Satz Gewinde ins Werkstück schneiden lassen zu > können, wäre schon sehr, sehr sportlich .. ;) Wenn Du das sofort willst, schau mal auf http://www.estlcam.com/ . Ähnliches könnte ich dann auch in das Easy-Job Modul implementieren. Und ich freue mich, dass Dir meine Software gefällt.
Moin Albert, In Estlcam ist die Funktion angekündigt und wird auch sehnlichst erwartet. Allerdings ist mir der Ansatz eines Easy-Job-Moduls lieber, weil ich nicht über CAD-CAM-G-Code springen muss. Unter LinuxCNC gibt es den Ansatz für einen zentralen G-Code-Generator bereits: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-Code_Generators .. und ich mag die Idee, G-Code über Standardfunktionen parametrisiert eingeben zu können. Das minimiert nicht nur die Fehlerquellen sondern erlaubt m.E. auch eleganteres Arbeiten. ... und es können später auch interessierte Programmierer Module dazu beitragen.
Moin Moin, Bugreport: Nach Abarbeitung eines Fräsjobs wird angezeigt,dass das Programm zu Ende ist. Es ist nun aber nicht mehr möglich Werte im Setbereich zu verändern, da ausgegraut. Die Achsen lassen sich noch verfahren, doch die Positionsanzeige aktualisiert sich nicht. Macros werden nicht dauerhaft gespeichert. Grbl 0.9i SerialComCNC 0.9a
Danke für den Bug-Report. NeuerGast schrieb: > Nach Abarbeitung eines Fräsjobs wird angezeigt,dass das Programm zu Ende > ist. Es ist nun aber nicht mehr möglich Werte im Setbereich zu > verändern, da ausgegraut. Die Achsen lassen sich noch verfahren, doch > die Positionsanzeige aktualisiert sich nicht. Wird in der nächsten Version korrigiert. NeuerGast schrieb: > Macros werden nicht dauerhaft gespeichert. Bei mir funktioniert das Speichern der Makros problemlos und dauerhaft. Diese werden beim normalem Beenden des Programms autom. gespeichert. Den dafür verwendeten Speicherort findes Du unten auf dem Info-Panel als TempPath. Vielleicht wird dieser ja von CCleaner oder ähnlichem bei Dir gelöscht. Bitte Überprüfe das mal und gib mir diesbezüglich eine Info, ich werde den Speicherort dann ändern.
Moin Moin, Speicherort ist C:\Users\Name\AppData\Local\Temp\
NeuerGast schrieb: > Speicherort ist C:\Users\Name\AppData\Local\Temp\ Wird in der nächsten Version zur Sicherheit auf C:\Users\Name\AppData\Local\SerialComCNC\ geändert.
Anbei SerialComCNC Version 0.9b Change Log V0.9b ---------------- Beim Connect mit dem Arduino wurde die Schnittstellen-Prüfung auf korrekten Com-Port und Antwort des Arduino verbessert, dauert nun aber etwas länger. Behoben: Der Set-Bereich wurde nach einem Fräsjob nicht mehr aktiviert. Im Set-Panel hat "Move mm" jetzt immer 2 Nachkommastellen. Der Wert im "Move mm" Eingabefeld wird durch Doppelklick in die Eingabe auf Null zurückgesetzt. Die Fenster-Position und das Farbthema werden nun beim Beenden gespeichert und beim Neustart übernommen. Wenn die Schnittstelle nicht aktiv ist, sind alle Elemente in der Prozess Anzeige deaktiviert, die Start Button-Led ist dann grau. Der DatenPfad für die Sicherung der Einstellungen und Makros ist jetzt: C:\Users\User\AppData\Local\SerialComCNC\ wobei User der PC-Benutzer Name ist. Gruss Ulrich Albert http://www.serialcominstruments.com/
Anbei SerialComCNC Version 0.9c Change Log V0.9c ---------------- Sorry, habe gerade noch einen bösen Bug im Timingverhalten entdeckt. Hier die korrigierte Version. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert, Wäre es möglich den Werkzeug Wechsel zu automatisieren, damit meine ich einen Ablauf wie folgenden: Programm lauft ab, Txx Kommando kommt im Programm, Maschine fährt auf Makro 1 (Tool Chance Position), SerialComCNC gibt eine Fenster mit der Meldung "Bitte auf Tool3 (z.B. Borer 2.1mm) wechseln!", nach dem wechseln des Werkzeugs und dem drücken eines OK Buttons Fährt die Maschine auf Makro 2 (Probing Position), tastet die werkzeuglänge ab, verrechnet die Längendifferenz, fährt auf die letzten Arbeitskoordinaten zurück und geht in der Abarbeitung des Programmes weiter. Ich selbst habe zwar noch keinen Längentaster an meiner Maschine, aber da ich mir gerne in nicht allzu ferner Zukunft eine zulegen werde, hoffe ich dass du eine solche Funktion in einem des nächsten Release einbauen könntest. Danke im voraus, Gabriel
Gabriel M. schrieb: > Wäre es möglich den Wie wäre es, wenn du , bevor du Ansprüche stellst, dich beim Autor dieses Programms für genau eben dieses erst mal gebührend bedanken würdest ? Dafür das er es als Freeware zur Verfügung stellt und so intensiv weiterentwickelt ?
Hallo Ulrich, Ich verfolge jetzt deinen Thread quasi seit Beginn. Faszinierend und beeindruckend.... !! Ich suche schon seit mindestens 2 Jahren nach einer Alternative für den "klobigen" Linuxcnc Rechner... Hab bestimmt 3/4 der "Googlelösungen" durchexerziert...über hal2arduino und GcodeSender bis Machinekit..... Dein Ansatz, vermutlich ist die Bezeichnung "Lösung" mittlerweile angebracht , könnte echt der Durchbruch für mich sein. Ich sage vermutlich weil ich leider seit version 4 deine software nicht testen kann.... Dachte bis letzte Woche dass es an meinem Arduino Klon liegt...war ja mal im Gespräch .. Mittlerweile hab ich aber auch einen Arduino Uno...dennoch hab ich irgendwie keine Verbindung ..Checkport wird zwar mit ok quittiert..ich bekomm aber über die Dollarzeichen keine Auflistung der GRBL Befehle...Lediglich das Dollarzeichen wird auf dem Monitor ausgegeben..in "Grün" ! Mein Betriebssystem ist mainstream Win7... Dadurch dass in dem langen Thread jetzt keiner mehr mit solchen Problemen zu kämpfen scheint...vermute ich das Problem jetzt langsam vor dem Bildschirm.....Aber ich komm nicht drauf... Ueber den Arduino eigenen serial monitor kann ich GRBL konfigurieren... Vlt fällt dir oder anderen Usern noch was ein... Danke fürs teilen !!! afrikavi.
Danke Nutzer, daß du uns ein solch schönes Programm gebaut hast. Aber mal ehrlich, es hat dich doch keiner gezwungen das zu tun, oder?
Hallo Afrikavi, mein Problem mit den fehlenden Antworten vom Arduino (3 verschiedene Clone probiert)ist nicht gelöst. Problem: Beim Reset bekomme ich noch die GRBL-Version angezeigt als Antwort, danach ist Stille, aber der Arduino reagiert auf manuelle Befehle vom SerialComCNC. Der einzigste funktionierende Workarround ist, dass ich mich als Admin im Win7 anmelde und SerialComCNC ausführe. Selbst eine Win7-Neuinstallation und aktuellere Ch340 Treiber haben nicht geholfen. Hab gerade die v0.9c ausprobiert - keine Änderung. Gruß Sven
Ich habe hier zum Testen folgende Arduino Boards: Arduino Uno R2 mit ATMega 8U2 (Original Arduino) SainSmart UNO R3 ATMEGA328P mit ATMega16U2 (Clone) Nano V3.0 ATmega328P mit FTDI (Clone) Arduino Uno R3 mit ATMega 16U2 (Clone) Alle laufen problemlos unter Windows 7 und XP. Diese Boards benutzen als Serial/USB Wandler als FTDI, 16U2 oder 8U2. Ob der CH340 Wandler bei den Clone Boards Probleme macht kann ich daher nicht sagen.
(noch?)nichtNutzer schrieb: > Danke Nutzer, daß du uns ein solch schönes Programm gebaut hast. > Aber mal ehrlich, es hat dich doch keiner gezwungen das zu tun, oder? Merke dir du Schmierer, ich bin nicht der Programm-Autor, ich hasse nur Leute, die immer nur nehmen, aber nicht geben, und wenn es zumindest ein Danke ist.
@Sven und Afrikavi Ich habe in einem GRBL Forum folgendes gefunden: "With regards the error at 115200 baud - with a 16MHz crystal it is about 2.1%. With asynchronous communications the timing is restarted on every start bit, so it is only cumulative across the 10 bits (start, 8 bits, and stop), giving a max of about 19% on the stop bit (9 x 2.1%). You can theoretically get away with as much as 5% error per bit (+/-45% on the stop bit), but you can have errors on both ends of the communcation, so best to stay below 2.5%, and the lower the error the better. Cheap Arduinos with resonators instead of crystal oscillators will introduce further error, and shouldn't be used at high baud rates." Fazit daraus: Die Kommunikation ist von den GRBL Machern mit den vorgeschriebenen 115200 Baud eh am Rande des Zulässigen festgelegt. Wenn man jetzt noch einen Billig-Arduino mit Resonator anstatt Quarz hat, kann das ganz in die Hose gehen. Desweiteren: "I tested three boundrates 115200,250000,20000000 with my arduino nano and CH340 USB chip. With simple C# code that sends simple G-code 1 Test, start position X0Y0Z0 G0X100 G0X0 Avarage time off all boundrates is almost the same about 6.5Sek 2 Test, same distanse, but gcode every one milimeter - results as above for all boundrates. 3 Test, same distanse, but gcode every 0.1 milimeter Resoult: 115200 - 1/10 ok other fail due to comunication error" Zeigt dass Arduinos mit CH340 in Verbindung mit GRBL zu misstrauen ist.
Hallo Albert, danke für deine Bemühungen. Wie schon vor einigen Wochen mal geschrieben, hatte ich GRBL für 9600Baud neu kompiliert - mit gleichem Ergebnis beim SerialComCNC. Dagegen funktioniert es mit 115200 mit den seriellen Progs. der Arduino IDE und HTerm. Im HTerm kann ich auch deine 7Hz Pos.Abfrage simulieren und bekomme immer eine Antwort vom Arduino. Es handelt sich um Arduino-Nano, sowie -UNO jeweils mit Quarz... Gruß Sven
Sven schrieb: > Es handelt sich um Arduino-Nano, sowie -UNO jeweils mit Quarz... Sven schrieb: > Selbst eine > Win7-Neuinstallation und aktuellere Ch340 Treiber haben nicht geholfen. Zu den CH340 steht ja oben was. Sven schrieb: > Der einzigste funktionierende Workarround ist, dass ich mich als Admin > im Win7 anmelde und SerialComCNC ausführe. Admin Rechte sind nicht notwendig. Wenn nun aber bei fast allen Anwendern SerialComCNC funktioniert, unterscheidet Dich davon eigentlich nur noch Dein spezieller PC. Vieleicht ist da beim Wandler-Chip das Timing gerade am falschen Ende oder irgendwelche System-Tasks pfuschen rein. Hast Du es mal mit einem anderen PC oder Laptop versucht? Nachtrag: Ich habe jetzt gerade mal das Programm auf einem lahmen Uralt-PC mit WinXP getestet. Alles läuft auch auf dem alten Teil wie es soll. Übrigens benutze ich für die Entwicklung einen PC mit Intel Core i7 / 860 Processor mit Win 7 32bit.
Hallo Albert, mit meinem alten XP-Notebook funktioniert es. >Admin Rechte sind nicht notwendig. Mit meinem (fast) neuen Win7-Notebook funktioniert es nur wenn ich als Admin angemeldet bin (SW als Admin starten, bei Normaluser Anmeldung reicht nicht). Ich habe auch schon versucht dem 'Normaluser' Adminrechte zu geben, hat aber auch nicht geholfen. Nur ein echter Admin Login funktioniert. >Wenn nun aber bei fast allen Anwendern SerialComCNC funktioniert, >unterscheidet Dich davon eigentlich nur noch Dein spezieller PC. Das scheint mir auch so, es ist ein Asus N73JF (X7BJ-Series)... Ich denke ich muss damit leben. Gruß Sven
Nutzer schrieb: > Gabriel M. schrieb: >> Wäre es möglich den > > Wie wäre es, wenn du , bevor du Ansprüche stellst, dich beim Autor > dieses Programms für genau eben dieses erst mal gebührend bedanken > würdest ? > > Dafür das er es als Freeware zur Verfügung stellt und so intensiv > weiterentwickelt ? Ja Nutzer, Stimmt, ich habe mich nicht bedankt, und das würde ich hiermit gerne nachholen. Danke Albert für das tolle Programm! Ich werde dir sobald meine Visakarte wieder funktioniert eine kleine Spende für ein extragroßes Bier zukommen lassen! Gabriel
Hi Albert, das Programm schmiert nach "TestCode" folgende CNC Code: N001 G17 G21 G90 G94 G54 N0014 G00 Z10.000 N0016 M04 N0018 G00 X33.441 Y4.800 N0020 G00 Z0.500 N0022 G01 Z-2.000 F300 S1000 N0024 G03 X30.241 Y8.000 I-3.200 J0.000 F100.0 N0026 G01 X-25.000 F300 N0028 G03 Y-8.000 I0.000 J-8.000 F100.0 N0030 G01 X35.000 F300 N0032 G03 Y8.000 I0.000 J8.000 F100.0 N0034 G01 X30.241 F200 N0038 G00 X-100 Y-100 N0040 G00 Z120.000 N0044 M05 weitere Kleinigkeit: Im Setings - Graphic nimmt TEdit Minus Zeichen nicht an. Gibt's ein Grund, warumm du das Format ###,### und nicht ###.### verwendest? Meiner Meinng nach,das macht mehr Aufwand und ist eine Fehlerquelle mehr wie etwa '' ist kein Gleitkommawert... Und wenn ein Grund dafür gibt, müßte bei englisch wieder die Format ###.### anwenden. Nach der Connection des TComport könnte man den default Feed setzen als kleiner Verbesserungsvorschlag. Ansonsten ein gelungenes Programm. Gruß Tany
Tany schrieb: > das Programm schmiert nach "TestCode" folgende CNC Code: Hallo Tany, ich kann auch bei mehrmaligem Durchlauf Deines Test-Codes keinen Fehler finden. Bitte beschreibe genau was bei Dir falsch läuft. Tany schrieb: > Im Setings - Graphic nimmt TEdit Minus Zeichen nicht an. Wird im nächsten Release geändert. Tany schrieb: > Gibt's ein Grund, warumm du das Format ###,### und nicht ###.### > verwendest? Das Komma ist nun mal bei uns der Dezimaltrenner für die Eingabe. Den Fehler " '' ist kein Gleitkommawert" werde ich korrigieren. Tany schrieb: > Nach der Connection des TComport könnte man den default Feed setzen als > kleiner Verbesserungsvorschlag. Den Feed habe ich bewusst aus Sicherheitsgründen nach Connection oder Reset auf Null gesetzt. Falls sich allerdings noch mehr Beführworter für einen Default-Feed finden, werde ich das wieder ändern.
> Nach der Connection des TComport könnte man den default Feed setzen als > kleiner Verbesserungsvorschlag. Man könnte es auch in den GRBL Startup Block legen: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9#n---view-startup-blocks Gruß Sven
Hallo Sven...und all die andern, die sich "kurz" mit meiner Problematik auseinandergesetzt haben..DANKE. Leider ist das gewünschte Ergebniss ausgeblieben, kann bis Dato nicht mit dem Arduino kommunizieren. Workarounds haben nichts gebracht...Admin bin ich schon...und am ch340 liegts auch nicht..weil nicht vohanden..( UNO r3 SMD original) Wie gesagt, Verbindung steht - gcode kann eingelesen werden - Grafik wird keine angezeigt ... sobald ich auf $ oder $$ oder whatever button drücke fängt der Arduino.. -oder das Programm dermassen an zu schaffen dass der Eindruck ensteht der pc wäre am Limit...Task Manager sagt aber alles ruhig ... ( i5 32 bit WIN7 ) Falls das jemanden bekannt vorkommt..... Ansonsten...Time will tell ..werd eifrig weiterverfolgen.. gruß Afrikavi
Afrikavi schrieb: > Wie gesagt, Verbindung steht - gcode kann eingelesen werden - Grafik > wird keine angezeigt ... sobald ich auf $ oder $$ oder whatever button > drücke fängt der Arduino.. -oder das Programm dermassen an zu schaffen > dass der Eindruck ensteht der pc wäre am Limit...Task Manager sagt aber > alles ruhig Wie wäre es mal mit einer Fehlerbeschreibung die auch ich verstehe? Also detailiert Step for Step und Aktion/Reaktion, angefangen bei Click auf den Button Connect. Welche GRBL Version ist auf dem Arduino geflasht, bezw. wird beim Connect im Monitor angezeigt? Mit welcher SerialComCNC Programm-Version arbeitest Du? Mit Deiner Beschreibung oben kann icht absolut nichts anfangen. Im übrigen, wenn Du im Monitor rechts oben den Graphic-Reiter nicht anklicken kannst, steht auch die Verbindung nicht.
Danke für die Mühe.
- installiere SerialComCNC - keine Fehler
- flashe per xloader grbl_v0_9g edge - kein Fehler
- Starte SerialComCNC - kein Fehler
...port com30..baud 115200...sind vorgewählt
- ich drücke connect
...rechts im Reiter MONITOR wird 6 mal CHECKPORT ausgegeben
...dann erscheint eine info box : "der ComPort ist jetzt aktiv."...
...im Reiter MONITOR steht mittlerweile in "grün" G92 X0 Y0 Z0
Grbl 09g....
ok
ok
$x (in Grün)
ok
-ich quittiere die info box mit OK
-Reiter MONITOR is jetzt blank
-wähle Reiter Grafik an.... kein fehler..sehe fadenkreuz...lässt
sich verschieben..
-das gleiche mit den zwei anderen Reiter...keine Fehler
-noch während ich schreibe und die reiter durchklicke ändert sich die
blinkfrequenz der tx rx leds des arduino...leuchten jetzt
statisch...davor haben sie geblinkt...
versuch den $-button zu klicken...wird erst nach ca. 3sek
angenommen....oben im Reiter Monitor steht jetzt $ in grün....
versuch gcode zu laden...wird verzögert ausgeführt..aber ohne Fehler...
programm hängt mittlerweile so dass ich disconnecte und wieder
connecte..
...läuft dann wieder...tx rx blinken...bis ich den Button Test code
drücke...zb.
...dann hängts wieder...tx rx statisch..
...so in etwa...
Hi Albert, so wie Afrikavi beschreibt, ist's bei mir auch zu beobachten. Ich hab ein Verdacht, es könnte an der Kabellänge liegen. Werde heute Abend testen.
Kurzer Nachtrag, Meine oben beschriebene Vorgehensweise bezieht sich auf den UNO r3 smd und SerialComCNC 0.9c + grbl 0.9g . Betriebssystem und pc_hardware wurden schon erwähnt. Gleiches habe ich nun mit dem Arduino Duemilanove Klon von DFrobot durchgespielt. der Klon verhält sich bis auf ein Merkmal gleich : er schafft sich nicht tot nach einer Minute...will heissen, SerialComCNC bleibt stabil und lässt sich quasi bedienen. Es scheint bloss dem Klon nicht mitteilen zu kÖnnen was er eigentlich will...sprich wenn ich Dollar drücke, bekomme ich keine Ausgabe der Liste...usw..wie oben schon beschrieben... Immerhin hängt das Programm nicht nach einer Minute !! Gleiches Szenario habe ich nun auf einem notebook probiert. i5 32bit win7 SerialComCNC connected sich... verbindung steht...ich drück Dollar... und krieg ne Liste !!!! Lade gcode....drücke start....gcode läuft...fadenkreuz bewegt sich im Monitor...Bahn wird ausgegeben..!! SerialComCNC nach 30 min. immer noch stabil !! Cam gestartet...Led am notebook neben cam leuchtet kurz auf..dann Meldung :keine cam gefunden... Klon drangehängt...Alles bestens !! SerialComCNC nach 30 min. immer noch stabil !! SPRICH AUF DEM NOTEBOKK RENNT DAS DINGENS !! USB Kabel hab ich hin und wieder getauscht...aber alle max 1200mm lang.... hatte nix geändert.. Ich schau mir mal mein Rechner an... Nur zur ERINNERUNG SerialComCNC 0.4a hat auch noch auf meinem PC getan (Klon sowie Original)!! Unter Umständen hilft dieser Nachtrag noch dem einen oder andren auf die Sprünge. ...ansonsten,soweit ich bis jetzt beurteilen kann..Klasse Programm Albert!! Afrikavi.
Ach nö, es liegt nicht daran. Das Programm schmiert immer noch ab. Auch nach dem Disconnect leuchten LEDs dauerhaft... Ich mache mit mein Eigenem weiter... Wünsche dir viel Erfolg. Gruß Tany
Afrikavi schrieb: > Nur zur ERINNERUNG SerialComCNC 0.4a hat auch noch auf meinem PC getan > (Klon sowie Original)!! Meinst Du damit, dass bei Dir Version 0.5 nicht mehr gelaufen ist oder hast Du danach mehrere Versionen übersprungen? Würde mich jetzt interessieren was genau die letzte funktionierende Version war. Ich habe mal die relevanten Prozeduren von 0.4a und 0.5 mit WinMerge http://winmerge.org/ verglichen, da gibt es keine Änderungen im Code.
Hallo, 0.4 _ 0.4a funktionieren. 0.5 _ 0.5a _ 0.6 _ 0.8b1 _ 0.8e1 _ 0.9 _ 0.9c funktionieren nicht. gruss Afrikavi.
Habt ihr den Arduino mal ohne Verbindung zu den Stepper-Drivern Endschalter usw. betrieben? Also nur USB-Kabel an Arduino und dann SerialComCNC starten. Dass bei einigen wenigen PC's Kommunikations-Probleme auftreten hat nichts mit meiner Software zu tun. Dieser Effekt wird auch in diversen deutsch-und englischensprachigen Foren beschrieben, die Arduino/GRBL über andere Front-Ends ansprechen. Hier einige Zitate: "ich hatte bisher mehrfach Probleme mit GRBL wenn das USB-Kabel Mist war. Und zuletzt hat der Fräsvorgang einfach gestoppt weil der USB Port nicht ganz "rund" lief, anderen Rechner genommen und schon ging alles." "Ich hab dann ein gutes USB-Kabel mit Ferrit genommen, alle Eingänge entprellt (RC-Glied) und ein saubere, zentrale Masse aufgebaut, ohne Masseschleifen. Was davon am meisten geholfen hat, kann ich nicht sagen, aber seitdem kann ich den Staubsauger oder die Neinröhren an- und ausschalten, ohne dass GRBL stoppt bzw. abstürzt." "Teilweise sind es auch Potentialprobleme Zwioschen Rechner, Arduino und Fräse Probleme, da hier ja keine galvanische Trennung vorhanden ist. Bei mir lösten so z.B. teils die Endschalter aus wenn ich den Sauger anschaltete."
Hi Albert, lade bitte meine o.g Testcode und drücke auf Button "TestCode", nicht auf "StartDatei". Das schmiert bei mir ab. Normarweise benutze ich sowas nicht. Mit "StartDatei" läuft dein Programm ohne Fehler, auch wenn man mehrmals probiert.
Tany schrieb: > lade bitte meine o.g Testcode und drücke auf Button "TestCode", nicht > auf "StartDatei". Das schmiert bei mir ab. Beim 1. Durchlauf geht es, beim 2. mal Absturz. Ja das ist ein Bug. werde ich für die nächste Version korrigieren.
Anbei SerialComCNC Version 0.9d Change Log V0.9d ---------------- Procedure des Fahrens zum gesetzen Nullpunkt in "Manueller Prozess" geändert. Wenn kein Wert in "Home Offs" gesetzt ist, wird zuerst X und Y auf null gefahren und dann erst Z. Ist ein Wert in"Home Offs" gesetzt ist, wird zuerst Z auf diesen Wert gefahren, dann X und Y auf null gefahren und zuletzt Z auf Null. Es sind nun auch negative Werte bei den Grafik-Einstellungen möglich. Das ComTimer Intervall mit der Daten vom Arduino/GRBL abgefragt werden, ist nun über Einstellungen/Einstellung zugänglich und zwischen 100 ms und 200 ms einstellbar. Laut GRBL-Doku sind 200ms immer sicher, voreingestellt sind jedoch 150 ms, weil damit niemals Fehler bei mir auftraten. Intervalle kürzer als 100 ms verursachen immer Fehler, da GRBL dann interne Timings nicht mehr sicherstellt. Das TimerInterval hat auch Einfluss auf die Graphik: Je kürzer das Interval, desto mehr Daten stehen pro Zeiteinheit der Graphik zur Verfügung, d.h die Graphic hat dann eine höhere Auflösung. Die Einstellung bleibt beim Beenden des Programms erhalten. Fehler bei vertikaler Grössenänderung der Programmoberfläche bereinigt. Fehler bei Benutzung des Test-Modus korrigiert. Im Test-Modus werden jetzt die erkannten Fehler im G-Code File gezählt und im Monitor rot angezeigt: "nnn Errors found in G-Code" Unter Einstellungen/Graphic kann mit "Supress Lines if Z >= 0" optional festgelegt werden, ob die Fräserbewegungen bei Position der Z-Achse >= 0 in der Graphic dargestellt werden. Da dies fast immer nur auf Verfahrwege zutrifft, werden bei Aktivierung der Option die Verfahrwege ausgeblendet. Die Einstellung bleibt beim Beenden des Programms erhalten. Bei der Nullpunkt-Einstellung mittels WebCam wird nun auch der "Home Offs Z0" Wert berücksichtigt. Damit ist die genau senkrechte Ausrichtung der Kamera nicht mehr so kritsch. Im Klartext: Zuerst wird der Nullpunkt grob mit der WebCam gesucht, dann die Z-Achse fast auf Null gefahren und der Nullpunkt im Fadenkreuz genau justiert. Damit stimmt auch die Kamera-Paralaxe für Z0. Bei Betätigen des Use-Buttons wird zuerst die Z-Achse um den Offsetwert angehoben, X und Y zum Nullpunkt verfahren und Z dann wieder auf Z0 abgesenkt. Das Verfahren muss natürlich auch für die einmalige Kalibrierung angewendet werden. Im übrigen ist die Benutzung einer Webcam nur für leistungsstarke PC's empfehlenswert. Gruss Ulrich Albert http://www.serialcominstruments.com/
Suuuupergut: In JCNC hat mich die synchrone Nullpunktfahrt schon eine Reihe von Fräsköpfen gekostet ... damit ist jetzt Schluß ;) ;) Danke vielmalst
Wegen Linux, eine Alte Version funktionierte 0.7, nur wegen der Kamera DLL stuertzte sie ab. Die neue Version funktioniert total nicht. Einige Sachen funktionieren nicht, wie z.B. Excellon->Gerber Resultat zu Uebernehmen, ansonsten funktioniert sie. Hast du ev eine Erklaerung dafuer dass die neue Version durch eine Speicherverletzung (fixe addresse) abstuertzt ?
Chris S. schrieb: > Wegen Linux Sorry Chris, aber Linux/Wine wird von der Software nicht unterstützt und der Betrieb nun unter virtuellen Umgebungen, wie z.B. Linux/Wine, VMWare, VirtualBox usw., generell unterbunden. Gruss Ulrich Albert
Angehängte Dateien:
-
ERROR2.jpg
240 KB
Hallo, Was kann ich tun, normal zu arbeiten? Schauen Sie, was ich Fehler. Vielen Dank im Voraus. Luben Lambov
Liubo schrieb: > Schauen Sie, was ich Fehler. > Vielen Dank im Voraus. Der Fehler ist mir bekannt und wird demnächst korrigiert. Einfach OK drücken und weiter arbeiten. This bug is already known and will be corrected asap. Just press the OK button and go ahead. Nothing strange will happen after that.
Übrigens kann in der nächsten Version das Programmfenster beliebig vergrössert werden. Damit wird die graphische Darstellung notwendiger Weise immer isometrisch. Bei der Einstellung der Achsen können dann nur noch Xmin, Xmax und Ymin geändert werden. Ymax wird daraus autom. so berechnet, dass sich eine isometrische Darstellung (Kreis ist immer rund) ergibt.
Hallo Albert, erst mal Vielen dank für das Programm SerialComCNC. Ich selbst bin grade dabei eine CNC Maschine zu bauen. Das ganze ist grade noch im Bau. Löte grade die Controllerplatinen der Schrittmotoren für jeder der drei Achsen. Habe mir zwischenzeitlich Gedanken über die Steuerkommunikation gemacht LPT, RS232 oder USB Die Entscheidung hast du mir schon abgenommen. Da ich schon seid Jahren Atmega Chips brutzle ist Arduino mir bekannt. Arduino Uno mit Atmega328p besorgt und die Hex aufgespielt. Das ganze erst mal mit Steckbrett, Steuerung und Schrittmotoren zum laufen gebracht. (Teste das auf einen alten XP Laptop) keinerlei Probleme mit der Verbindung, habe das schon stundenlang am laufen. Motoren liegen dabei nur auf dem Tisch sind noch nicht angebracht. Für den Test lasse ich den Gode immer wieder durchlaufen ohne das Programm neu zu starten. Läuft ohne Störung. Das USB-Kabel ist noch recht kurz. Es zeigt das dein Programm stabil läuft und das auf dem Steckbrett! Die Erweiterung "EasyJob" ist eine sehr gute Idee Das Programm finde ich sehr gut, grade mit CAM Wenn ich da noch einen Joystick in Windows einbinde und dabei die Tasten der Steuerung übernehme lässt sich das ganze bestimmt auch gut manuell steuern. Wollte nur mal mein Feedback dazu geben. LG Daniel
Daniel Steinbock schrieb: > Wollte nur mal mein Feedback dazu geben. Hallo Daniel, freut mich hier auch mal Feedback zu bekommen was selten genug ist. Gruss Ulrich Albert
Hallo Frank. Den von Dir beschriebenen Fehler „das die Maschine sporadisch falsch fährt“ trat bei mir ebenfalls auf. Dabei drehte plötzlich die x Achse für ca. 5 -10 sec. Mit voller Geschwindigkeit. Ich ließ den Gode min 10x durchlaufen um dem Phänomen auf die Spur zu kommen. Auf den Bildern von dir ist gut zu erkennen das es auch ein paar Sekunden bei Dir sein müssten. Er trat nie an der gleichen Stelle auf. Fehler im Code kann ich auch ausschließen. Da es immer min. 5 - 10 sec. Hat man doch eine gewisse Zeit um in diesen Moment etwas zu tun. Also zog ich das USB-Kabel raus. ??? Motor drehte natürlich weiter. In der Graphische Darstellung von SerialComCNC keine abweichung. kein Sprung Im Process View in diesen Moment zu erkennen. Ein Bug im Programm des 328p ??? Also klein angefangen: ATmega 8 zur Steuerung des Controllers mit Joystick (Hatte noch einen alten WII stick. Stecker ab und neu verlötet. Die haben 10k Poti drin die sind dafür gut, nur 5V auf die eine und Grund auf die andere und der Schleifer direkt am Analogen Port des Atmega 8 . Halt einen einfachen Spannungsteiler. ) Programmierte den Atmega so das ich mit dem stick den Motor nicht nur bewegen sondern auch die Richtung und Geschwindigkeit regeln konnte. Beim Anschlag in eine Richtung Summte der Motor nur noch naja das Timing passte nicht auf die Schnelle. Damit spielte ich ein paar Minuten rum. Und siehe da: plötzlich drehte er wieder 10 sec. Somit war klar Programm im 328p i.o. USB-Kabel vermutlich auch i.o. PC i.o. Hallo Albert! Und somit kein Fehler beim SerialComCNC ! aus meiner Sicht zumindest. Als ich die Controller tauschte (X <> Y) blieb der Fehler auf dem gleichen Controller. Bei der Überprüfung fiel mir auf das der Control Eingang (L297) nicht definiert war (Wackelkontakt). Also weder auf Masse noch auf VCC Auf dem anderen Controller der keine Macke hatte lag der Control auf Masse. Laut Datenplatt: verstehe ich, sollte dieser definiert sein. Die Störung lies sich danach auch nicht mehr reproduzieren. Also war das vermutlich der Fehler bei mir. Sorry wenn ich so ausführlich berichte, es sollte nachvollziehbar sein. LG Daniel
Hallo Albert, zuerst mal vielen dank für deine mühe und für so ein tolles programm. ich wollte dich fragen, wenn es nicht allzu mühsam ist bei register video noch ein capture mode zum bilder machen oder live video daten beim fräsen zum aufzeichnen hinzufügen kannst ? Es geht bei mir um ein projekt, wobei ich die anfangspunkte mit webcam fotografiert haben möchte und für beobachten live aufnahmen benötige. Wäre es ein grosse aufwand ? Zwei buttons fotomachen und aufnehmen ? Danke im vorraus, und hoffe du machst lange weiter so, beobachte die entwicklung seit anfang an und benutze dein programm gerne. LG C.S
@Daniel Steinbock Danke für Deinen Bericht. c.s schrieb: > bei register > video noch ein capture mode zum bilder machen oder live video daten beim > fräsen zum aufzeichnen hinzufügen kannst ? Es geht bei mir um ein > projekt, wobei ich die anfangspunkte mit webcam fotografiert haben > möchte und für beobachten live aufnahmen benötige. Anscheinend hast Du Deine Webcam falsch montiert :) Die WebCam wird neben der Spindel montiert, mit Blickrichtung senkrecht nach unten und ist nur dazu gedacht optisch den gewünschten Nullpunkt zu bestimmen. Also stimmen bei richtiger Montage Blickrichtung der Camera und Position des Fräsers nicht überein und liegen einige Zentimeter auseinander. Dementsprechend kannst Du mit der Camera auch nicht den Fräsvorgang beobachten. Im übrigen wird nach Test mit diversen Webcam's und deren zum Teil miserablen Treibern die Webcam während des Fräsvorgang ab der nächten Software Version komplett abgeschaltet. Gerade bei älteren PC's ist der Resourcenverbrauch derart hoch, dass das korrekte Timing während des Video-Betriebs in SerialComCNC negativ beeinflusst wird (wurde bis jetzt auch schon deaktiviert, lässt sich aber demnächt während des Fräsens nicht mehr starten).
Naja so war es nicht gemeint, aber ich kann dich auch verstehen :) Ich habe mich ganz kurz befasst, da alles bei mir läuft und ich bei meinem projekt die kamera nicht als nullpunkt bestimmer nehme :) ich habe es so eingestellt das ich damit das schnittverhalten, einfluss von schnittgeschwindigkeit und schnittwerkstoffe vergleiche, ich will nicht weiter darauf eingehen. Zur zeit mache ich das über externes programm. Es war auch nur für mich gemeint aber das wäre zuviel verlangt. Wollte nur fragen. Trotzdem danke ! :)
Hello Albert, application is nice. I tested English language and there are several notices which can help you, maybe. App language *App is not remember language settings after exit and restart. *App when producing message box (i.e. error case), it always use german. (i.e. when COM port connected, disconnected, etc) Another notices from testing app, *When multiple commands are on one line "T4 M06 G43" and you run "Test Code", it notify you for error. But I think M06 and G43 are supported as example. Can we make red just wrong command and not whole line? (i.e. I am using HeeksCAM 1.1) *Somebody wrote there that is good to remember last used COM port in new start of application. i.e. I have COM26 and it is quite big listing :-) In listing I have first 8-10 COM ports without number, they are just named COM and they not works. It is some issue with listing COM ports from Windows. *App is not remember settings of graphical window. I set it to 300x200mm, after app restart it was smaller as before. (100x60 or something like that). *Sometimes after finishing G-code program with milling, the app behave strange. Some warning comes up, then GRBL is restarted, and again and again. I will try to repeat and make photos of that behaviour. Exit and restart application helped. * I am curious to understandable what some buttons doing. I.e. Process Display "Cont", "Halt", and in ManualProcess "Not-Stop" "halt" "Cont". Please can you explain what these buttons are doing with process,with GRBL, with coordinates etc.? can be help in German I can help you with Czech language files and help, If I can please you to add this language into app :-). K.
@KPr thank you for your comments. KPr schrieb: > *App is not remember language settings after exit and restart. > *App when producing message box (i.e. error case), it always use german. Will be corrected within the next versions. This is also true for the settings of graphical window. KPr schrieb: > *When multiple commands are on one line "T4 M06 G43" and you run "Test > Code", it notify you for error. But I think M06 and G43 are supported as > example. Error checking is not provided by my software but all done by GRBL. The check results are just displayed in the monitor window. But even if you type "T4 M06 G43" in the input box it gives you the error "Unsupported command". So there is something wrong with that command (G43). Read GRBL documentation on the GRBL wiki sites. So far I can remeber there are some issues discussed about tool length commands in GRBL forums. KPr schrieb: > Can we make red just wrong command and not whole line? No, see above comment. KPr schrieb: > *Sometimes after finishing G-code program with milling, the app behave > strange. Some warning comes up, then GRBL is restarted, and again and > again. I will try to repeat and make photos of that behaviour. Exit and > restart application helped. It seems that there are some EMV problems within your wiring of components. The behavior looks like an arduino reset due to voltage spikes within your wiring. If it mostly happends during end of job check influence of power off of the milling spindle or something like that. KPr schrieb: > * I am curious to understandable what some buttons doing. I.e. Process > Display "Cont", "Halt", and in ManualProcess "Not-Stop" "halt" "Cont". > Please can you explain what these buttons are doing with process,with > GRBL, with coordinates etc.? can be help in German "Halt" means an intermediate stop of the running G-Code file. "Cont" means go ahead after a "Halt". Do not move the axis manually during a "Halt" cause no halt coordinates are stored (will be changed in a later version). "Not-Stop" means stop file processing and reset the arduino. Use "Not-Stop" for emergency case if something is going wrong or just for interrupt e.g. long test programs a.s.o. During a "Not-Stop" the XYZ zero point is stored and you can drive the machine back to that point by pressing the "*" button. KPr schrieb: > I can help you with Czech language files and help, If I can please you > to add this language into app :-) I can provide a seperate windows app which will show up a side by side language conversion. So you can convert to Czech language and make the change persistend. But this software is somewhat complicated. A more easy way for you is just to change the German or enlish lng-file simply with a text editor. But dont change the file name itself.
Hallo an alle, Zuerst einmal reißen Respekt und wow. Da schon öfter der Werkzeug Wechsler angesprochen wurde haben ich mir da mal ein paar Gedanken gemacht und würde mich anbieten einen Wechsler und die Controller Software zu entwickeln. (natürlich so dass jeder seinen eigenen Wechsler damit betreiben kann) Aufgrund deiner Programmierung mit der Möglichkeit einen wechselpunkt anzufahren wäre es durchaus möglich um Grbl herum zu arbeiten und das Ganze mit einem zweiten Controller zu realisieren. Ich stelle mir das folgendermaßen vor: Du implementierst eine zweite Schnittstelle für den Wechsler, die nur Infos über das momentane und angeforderte Werkzeug sendet und empfängt. Die Einstellungen und Justierung des Wechslers erfolgt über ein von mir generiertes GUI (das nur zur Justierung genutzt und für den späteren Wechsel Ablauf nicht gebraucht wird). Ich versuche die Programmierung so allgemein zu halten wie möglich, dass sowohl Schrittmotoren, Servos oder Magnete verwenden werden können. Damit ist gewährleistet dass jeder einen für seine Ansprüche passenden Wechsler bauen kann. Zum Ablauf SerialcomCNC - Die vordefinierte Wechsler Position wird automatisch angefahren - Wenn angefahren Meldung an den Wechsler Controller welches Werkzeug eingespannt ist z.B. W4 - Meldung an den Wechsler Controller welches Werkzeug benötigt wird z.B. W6 Wechsler Controller - Die Aufnahme für das Werkzeug ``W4‘‘ wird in Position gefahren - Das Werkzeug wird ausgeworfen - Die Aufnahme für Werkzeug W4 wird abgefahren - Die Aufnahme für Werkzeug W6 wird in Position gebracht - Werkzeug wird verriegelt - Die Aufnahme W6 wird abgefahren - Meldung an SerialcomCNC ``W6´´ (eingespanntes Werkzeug) diese Meldung kann dazu benutzt werden um die fräse wieder weiter arbeiten zu lassen und um beim nächsten Wechsel die Info über das genutzte Werkzeug an den Wechsler Controller zu senden. SerialcomCNC - Werkzeuglänge bestimmen - UND WEITER GEHT’S Soweit die Idee. Sensoren für die Bestätigung dass das Werkzeug eingesetzt ist oder ähnliches kann wenn überhaupt Interesse besteht noch mit eingebracht werden. Sollet die Möglichkeit bzw. Interesse von dir oder den anderen vorliegen dann bitte einfach ein Feedback schreiben.
Ich bin ein absoluter Freak wenn es um Automatisierung geht und ein Werkzeugwechsler ist echt ne feine Sache. Allerdings kann ich mir nicht vorstellen das dies hier jemand umsetzen kann da die meisten kleinen Fräsmaschienen, meine inbegriffen, über Spannzangenaufnahmen verfügen. LG, Frank P.S: Falls Du Fit im Programieren bist, ich suche noch ne UNO Firmware für meinen 6-Achs Servo Roboter Arm. Beitrag "Re: Suche Projekthilfe bei 5 Achsen Roboterarm mit Schrittmotoren"
Angehängte Dateien:
Hi Benjamin, Warum so kompliziert? Man könnte die Werkzeuge auch einfach direkt an ihren Ablage Positionen abholen, wie es z.B. bei LPKF bei der ProtoMat Serie gemacht wird. Das einzige was man dafür benötigen würde wären frei Steuerbarer Ein- und Ausgänge für das Öffnen der Spannzange und einem Sensor, ob sich ein Werkzeug im Halter befindet. Leider verfügt die GRBL Firmware über keine freien ein- und Ausgänge. L.G. Gabriel
Morgen, Ersteinmal zu Frank. Klar sollte was machbar sein. Und jetzt zu Gabriel. Albert meinte, das er nicht vor hat einen werkzeugwechselvorgang in seine Software aufzu nehmen, schon aus dem Grund das grbl die funtionen nicht unterstützt und er sonnvollerweise die grbl Firmware nicht verändern wollte. Deshalb, wie er es so schön gesagt hat, die Klimmzüge von mir. Zum Problem mit der spannzange, da kann man auf einen eigenbau industriestanart zurückgreifen, allerdings nicht mit druckluft sondern servos oder Stepper motoren. Ich suche nachher nach einem youtube video. Da hat sich einer was gutes einfallen lassen. Habs auf die Schnelle aber nicht gefunden.
Betrifft: Werkzeugwechsler Ich habe jetzt mal Versuche mit mehreren seriellen Schnittstellen in SerialComCNC gemacht. Diese verliefen erfolgreich, es lassen sich also über zusätzliche MC's (Arduinos oder was auch immer) weitere beliebige I/O Funktionen unabhängig von GRBL ausführen. Trotzdem bleibt ein Werkzeugwechsler zuerst mal Zukunftsmusik, da die in der Entwicklung befindlichen EasyJob Funktionen sehr umfangreich und zeitraubend sind. Überdies denke ich, dass im Hobbybereich kaum jemand einen Werkzeugwechsler an seiner Fräse einsetzt.
Hallo Albert, erst einmal ein dickes Lob und Danke für die Software. ich habe ein emechanisch auf der Shapeoko 2 basierende Portalfräse gebaut. Arduino Uno R3 SMD OEM, DRV8522 Treiber, Protoneer Shield, 65x65x10cm Berabeitungsraum) Mit deinem Frontend hat die Fräse auf Anhieb funktioniert, was man von den zur Shapeoko empfohlenen Tools nicht sagen kann (GBRL-Kontroller geht, hat aber Fehler in der Abarbeitung, Universila G-Code Sender übernimmt Parameter nicht korrekt -> Wegstreckenfehler). Albert M. schrieb: > A more easy way for you is just to change the German or enlish lng-file > simply with a text editor. But dont change the file name itself. Hier habe ich genau das gemacht, also die Dateien einfach umbenannt in einer deiner frühen Versionen, bisher ohne Probleme. Ich habe nun mit der Version 0.9c gearbeitet, bisher auch alles super, jedoch habe ich folgendes Verhalten beim ende eines Jobs: in einigen Fällen, bleibt die Software mit "Das Ende des G-Code Files wurde erkannt. Befehle im Puffer werden noch verarbeitet. Bitte warten bis Anzeige "Idle" ok" stehen und kann nur durch "abschießen wieder benutzt werden (alternativ über den Reset des Arduino (der Zustand der Software zeigt aber bereits "Idle" an). Vielleicht liegt's ja auch an den umbenannten Sprachdateien... :P Ansonsten scheint seit der Version 0.9c das Icon für Windows verschwunden zu sein, wobei bei gestartetem Programm in der Taskleiste alles schick ist. Ich freue mich schon darauf, den Easy-Job Modus zu testen wenn du ihn fertig hast, Dann muss man dir eigentlich mal nen Dankeschön zukommen lassen. PS: kleine Frage, hast du vor eine Art .ini Datei zum Speichern der Programmeinstellungen zu verwenden in zukünftigen Versionen (für Grafik Fenster, Sprache, verwendeten COM-Port...)? Wie gesagt großes Lob und Danke für deine bisherige Leistung und Mühe. MfG EGS (ja ich hab ne Anmeldung, ist aber grad nicht mein PC an dem ich Schreibe...)
Hallo, erstmal klasse Programm! Nun zu meinem Problem: Webcam ist die "Hama Black Tube" Treiber ist der "Microsoft WDM Image Capture (Win32)" Das Programm meint aber keine Webcam zu finden. Einen eigenen Treiber liefer aber Hama nicht mit. Was kann ich machen um es trotzdem zum laufen zu bringen? Gruß NeuerGast
NeuerGast schrieb: > Webcam ist die "Hama Black Tube" > Treiber ist der "Microsoft WDM Image Capture (Win32)" > Das Programm meint aber keine Webcam zu finden. > > Einen eigenen Treiber liefer aber Hama nicht mit. > Was kann ich machen um es trotzdem zum laufen zu bringen? Siehe dazu weiter oben im Thread: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" und hier: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
EGS schrieb: > Albert M. schrieb: >> A more easy way for you is just to change the German or enlish lng-file >> simply with a text editor. But dont change the file name itself. > > Hier habe ich genau das gemacht, also die Dateien einfach umbenannt in > einer deiner frühen Versionen, bisher ohne Probleme. Verstehe ich jetzt nicht. Du bist doch offensichtlich deutschsprachig, warum änderst Du dann die Sprachdateien? EGS schrieb: > in einigen Fällen, bleibt die Software mit> > "Das Ende des G-Code Files wurde erkannt. > Befehle im Puffer werden noch verarbeitet. > Bitte warten bis Anzeige "Idle" > ok"> > stehen und kann nur durch "abschießen wieder benutzt werden (alternativ > über den Reset des Arduino (der Zustand der Software zeigt aber bereits > "Idle" an). Siehe dazu einen Beitrag weiter oben. Es handelt sich bei Dir anscheinend auch um EMV Probleme. Ein deutlicher Hinweis darauf ist auch Deine Aussage: "was man von den zur Shapeoko empfohlenen Tools nicht sagen kann (GBRL-Kontroller geht, hat aber Fehler in der Abarbeitung, Universila G-Code Sender übernimmt Parameter nicht korrekt -> Wegstreckenfehler)." bestätigt. Diese beiden Tools kaufen normalerweise fehlerfrei. Wenn sie bei Dir zicken hat das andere Ursachen, nämlich die von mir vermuteten EMV Probleme. Lies dazu mal weiter oben was dazu in mehreren Beiträgen geschrieben wurde. Im übrigen ist die aktuelle Software Version 0.9d, da solltest Du nicht mehr die ältere Version benutzen.
Hallo Albert, Super Programm!! Bin noch beim testen, glaube aber das ein kleiner Fehler beim vorgeben des Weges besteht, manchmal stimmen Vorwahl mit Wertänderung nicht. zB. 0,1mm vorgewählt Änderung aber um 1mm Kann es sein das sich beim z offset auch ein Fehler eingeschlichen hat? Z-Achse fährt bei Homefahrt auf offset Wert und dann wieder auf 0. Gruß Frank und weiter so!
Frank schrieb: > manchmal stimmen Vorwahl mit Wertänderung > nicht. > zB. 0,1mm vorgewählt Änderung aber um 1mm Ist bei mir noch nie vorgekommen, werde ich aber nochmal überprüfen. Du benutzt auch die neue Version 0.9d? Frank schrieb: > Kann es sein das sich beim z offset auch ein Fehler eingeschlichen hat? > Z-Achse fährt bei Homefahrt auf offset Wert und dann wieder auf 0. Das ist schon richtig so. Es verhindert dass der Fräser während der Nullfahrt über die Oberfläches des Werkstücks kratzt oder an Erhebungen anstösst. Genau dazu ist der Offset Wert gedacht. Siehe dazu den Change Log v0.9d bei den Downloads und diesen Kommentar von Tillmann: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
Albert M. schrieb: > Verstehe ich jetzt nicht. Du bist doch offensichtlich deutschsprachig, > warum änderst Du dann die Sprachdateien? Das war noch eine der früheren Versionen, da ist das Programm immer mit Englisch gestartet. Als Abhilfe habe ich dann die Sprachdateien umbenannt, damit's immer gleich deutsch ist... ? EMV-Probleme muss ich mal schaun, habe nen schon recht kurzes USB-Kabel mit Ferriten an beiden Enden, kann mir höchstens die Treiberbausteine oder das Netzteil (Meanwell 24 VDC, 10 A) als Störquelle vorstellen. Kanns aber erst am Tag der Arbeit wieder testen, jetzt is erstmal schaffen in Berlin angesagt. MfG EGS
EGS schrieb: > EMV-Probleme muss ich mal schaun, habe nen schon recht kurzes USB-Kabel > mit Ferriten an beiden Enden, kann mir höchstens die Treiberbausteine > oder das Netzteil (Meanwell 24 VDC, 10 A) als Störquelle vorstellen. Weitere gute Kanditaten sind auch die Spindel oder die Kühlung/Absaugung, jeweils Motor an/aus.
Angehängte Dateien:
-
issue1.jpg
140 KB
@Albert, thanks you for information. So many issues will be solved in new SW generation, nice. About EMV (EMC problem), USB is not industrial proof interface. I researched this problem years ago in school, problem is usually that host or device controller lost synchronisation or they came restarted. Software mostly on operation system side cannot easily recover. I.e. in case of FTDI chip or any VCP solutions, there is problem to recover Windows API working with file I/O access. Usually disconnection and reconnection is needed to refresh also driver. Partially we can solve EMC issue with power-less notebook running from battery, where USB is floating. Also on my breakout board I have galvanic insulation of USART RX/TX, helping to avoid galvanic loops and peaks going thru. I have EMC problems in situation i.e. when GRBL wants to do zero step, like G0 Z0 etc. , it make pulse and inrush to motors, but it must be some issue of GRBL firmware. I expect that zero change do zero motor control without any pulse :-). Issue with COM ports listing attached. Sometimes SerialCOM have problems to enumerat COM ports and you see... Second Issue, when GRBL stopped by SerialCOM "NotStop" and then arduino GRBL goes to restart, it produces this weird message about floating point... . K.
KPr schrieb: > Second Issue, when GRBL stopped by SerialCOM "NotStop" and then arduino > GRBL goes to restart, it produces this weird message about floating > point... . Hi KPr, This is a known bug Albert supposed to,fix with the next Version. Albert has come to know at 19th of april over Libous announcement. That USB is not the best way to communicate with an (half/quarter) semi-professional machine is clear, better way would be rs232 or rs485...i guess ? Even centronics interface or parallel port would be much better, but Albert needs to use the given firmware for grbl-small sytem controllers. No blaming on Albert, he is doing still a great work here ? Greets EGS
@EGS, Thanks you. You are right, better is RS-232 and more better is differential RS-485 or RS-422 for both channels. I have using that in industrial machines, close to heavy engines producing a lot of EMC noise. If something goes wrong, there is also opportunity to add optical (galvanical) insulation of digital signals. They work well. For hobbist the cheapest option is from two pieces, first one is converter USB FTDI RS-232 converter (because FTDI is reliable and no many new computers have COM ports) , second optional is galvanical insulator for RS-232 as single module or breadboarded piece :-). KPr
Hallo Albert, zu > manchmal stimmen Vorwahl mit Wertänderung > nicht. > zB. 0,1mm vorgewählt Änderung aber um 1mm Ist bei mir noch nie vorgekommen, werde ich aber nochmal überprüfen. Du benutzt auch die neue Version 0.9d? Tritt auf wenn Vohrwahl über Tastatur vorgegeben wird und danach über Softbuttons. (Bedienfehler von mir oder zu ändern?) Gruß Frank
Frank schrieb: > Hallo Albert, > >> manchmal stimmen Vorwahl mit Wertänderung >> nicht. >> zB. 0,1mm vorgewählt Änderung aber um 1mm > > Tritt auf wenn Vohrwahl über Tastatur vorgegeben wird und danach über > Softbuttons. (Bedienfehler von mir oder zu ändern?) Dieses Verhalten kann ich bei mir nicht reproduzieren.
Albert M. schrieb: > Frank schrieb: >> Hallo Albert, >> >>> manchmal stimmen Vorwahl mit Wertänderung >>> nicht. >>> zB. 0,1mm vorgewählt Änderung aber um 1mm >> >> Tritt auf wenn Vohrwahl über Tastatur vorgegeben wird und danach über >> Softbuttons. (Bedienfehler von mir oder zu ändern?) > > Dieses Verhalten kann ich bei mir nicht reproduzieren. Auch ich habe dieses Problem schon öfters beobachten können. Nachdem man einen Wert von Hand eingibt ist egal ob 10, 1, 0.1 oder 0.01 ausgewählt ist, es ändert sich immer um 1mm. Zudem kommt, dass (auf jeden Fall bei mir) ein von Hand eingegebenen Beistrich oder Punkt nicht akzeptiert wird.
Bei mir habe ich von Gabriel M. beschriebenes Verhalten ebenfalls feststellen können.
Gabriel M. schrieb: > Zudem kommt, dass (auf jeden Fall bei > mir) ein von Hand eingegebenen Beistrich oder Punkt nicht akzeptiert > wird. Hallo Gabriel, mit welcher Version arbeitest du? In der aktuellen Version 0.9d sollte es gehen. In früheren Versionen habe ich es auch gehabt. Gruß Frank
Ja, en klein Bug! (auch beim 9d!) Vorschlag: die Buttons entfernen. Das schafft mehr Übersicht. Ein "echter" CNC-Fräser wird die nicht vermissen. Genauso wie beim Speed und Feed. Es wäre besser mit Trackbar. Die Buttons '$' '$$', '$H', 'P' werden selten benötigt! ...
Gabriel M. schrieb: > Nachdem man > einen Wert von Hand eingibt ist egal ob 10, 1, 0.1 oder 0.01 ausgewählt > ist, es ändert sich immer um 1mm. Zudem kommt, dass (auf jeden Fall bei > mir) ein von Hand eingegebenen Beistrich oder Punkt nicht akzeptiert > wird. Das zeigt mir, dass Du noch nicht die Version 0.9d verwendest oder das Konzept falsch interpretierst. Und versuche es mal mit einem Komma als Dezimaltrenner :) Noch mal zum Konzept der Vorwahlbuttons: Es wird NICHT, wie Gabriel vielleicht meint, um den Betrag des Vorwahlbuttons verfahren. Die Vorwahlbuttons dienen ausschliesslich dazu den Wert zu wählen um den sich der Betrag in der Eingabebox bei Betätigen der Up/Down-Buttons ändert. Es wird immer ausschliesslich um den Wert verfahren, der in der Eingabebox (Move mm) zu sehen ist. Wie auch immer, in der 0.9d kann ich dazu momemtan keinen Fehler feststellen.
Der hat nicht detailliert beschrieben, wie der Fehler kam. :-) Na dann probiere mal: - du gibst einen Wert (per Tastatur) ein. z.B 12,03 - Ohne Enter zu drücken,(Der Cursor steht noch am Ende im Editfeld), drückst bitte dann den Up/Down Taster mit der Maus. - Wieviele wurde geändert? - 0,01? nicht so schlimm, drückt mit der Maus auf Vorwahlbutton "10" - drücke erneut Up/Down -->Änderung immer noch um 0,01 jedenfalls bei mir!
Tany schrieb: > Der hat nicht detailliert beschrieben, wie der Fehler kam. Ah, jetzt seh ich es. Wird im nächsten Release behoben.
Albert M. schrieb: > Das ist schon richtig so. Es verhindert dass der Fräser während der > Nullfahrt über die Oberfläches des Werkstücks kratzt oder an Erhebungen > anstösst. Genau dazu ist der Offset Wert gedacht. Siehe dazu den Change > Log v0.9d bei den Downloads und diesen Kommentar von Tillmann: > Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit > ATMega" ist schon klar, wurde aber doch schon vorher verhindert weil erst die Z-Achse heraus fuhr. Nicht wie bei JCNC alle Achsen fahren zugleich die Nullfahrt. Wenn offset vergessen wird besteht die Gefahr jetzt aber erst recht. Sorry wenn ich nerve. Wie geht es mit dem Easy Job voran? Hoffe gut. Gruß Frank
Hallo Albert,
kleinen Tippfehler in der GRBL-Hilfe gefunden.
§§ - es werden alle persistenten Systemeinstellungenangezeigt.
müsste
$$ - es werden alle persistenten Systemeinstellungen angezeigt.
sein
Damit ein spitzen Programm noch besser wird.
Gruß
Frank
Frank schrieb: > Gabriel M. schrieb: >> Zudem kommt, dass (auf jeden Fall bei >> mir) ein von Hand eingegebenen Beistrich oder Punkt nicht akzeptiert >> wird. > > Hallo Gabriel, > > mit welcher Version arbeitest du? In der aktuellen Version 0.9d > sollte es gehen. In früheren Versionen habe ich es auch gehabt. > > Gruß > Frank Danke für den Hinweis Frank. Mit dem Update auf 0.9d funktioniert jetzt die Erkennung des Kommas. Albert M. schrieb: > Tany schrieb: >> Der hat nicht detailliert beschrieben, wie der Fehler kam. > > Ah, jetzt seh ich es. > Wird im nächsten Release behoben. Danke Albert, du bist der Größte!
Falls du bem Easy Job sehr konzentrieren muß, hier mein Vorschlag:
Die Vorwahlbuttons (10, 1, 0,1, 0.01) werden mit Tag (1000, 100, 10, 1)
verpasst.
Beim OnKlick:
UpDown1.Tag :=TButton(Sender).Tag;
Und nun beim ChangingEx von UpDownButton:
procedure...
var
k:Smallint;
begin
k:=-1;
if Direction = updUp then k:=1;
Edit1.Text
:=FormatFloat('0.00',StrToFloat(Edit1.Text)+k*UpDown1.Tag/100);
if pos('-',Edit1.Text)>0 then Edit1.Text :='0,00';
end;
@ Tany Der Fehler ist behoben und die Ursache war banal. Die Komponente hat eine Eigenschaft "IncrementSmart" die dummerweise gesetzt war und das Fehlverhalten verursacht hat.
Frank schrieb: > Wenn offset vergessen wird besteht die Gefahr jetzt aber erst recht. > Sorry wenn ich nerve. Änderungen für die nächste Version: Der eingestellte "Home Offs Z0" Wert wird beim Programmende gespeichert und steht im Auslieferzustand der Software auf 10 mm. Ich denke das ist ein tragbarer Kompromiss. Die Einstellungen vom ComPort und die Baudrate werden beim Programmende ebenfalls gespeichert.
Hallo Albert, warum werden die Koordinaten nach abarbeiten eines Files und beim Reset auf 0 gesetzt? (aktuelle Version V0.9d) Nullfahrt ist so etwas schwierig. G92.1 und dann Nullfahrt(Home XYZ) War in älteren Versionen nicht der Fall.(z.b. V0.7c)
Frank schrieb: > warum werden die Koordinaten nach abarbeiten eines Files und > beim Reset auf 0 gesetzt? (aktuelle Version V0.9d) Weil GRBL die Weltkoordinaten bei Reset auf Null setzt. Dieses Problem wurde aber bereits ab Version 0.8d behoben: Beim Not-Stop werden die aktuellen Koordinaten aus den Maschinenkoordinaten neu in Weltkoordinaten umgerechnet und in die Anzeige eingetragen. Auf XYZ Null zurückfahren geht jetzt nach Not-Stop mit dem * Button.
Albert M. schrieb: > Beim Not-Stop werden die aktuellen Koordinaten aus den > Maschinenkoordinaten neu in Weltkoordinaten umgerechnet und in die > Anzeige eingetragen. Auf XYZ Null zurückfahren geht jetzt nach Not-Stop > mit dem * Button. Nicht nach Not-Stop sondern nach normalen File ende. Wenn im File nicht Home Position angefahren wird. Gruß Frank
@ Frank Die Koordinaten werden nach normalem File-Ende NICHT auf Null gesetzt, sondern stehen auf der aktuellen Position. Wenn die Koordinaten bei Dir auf Null gesetzt werden (wahrscheinlich MC-Reset), hat das andere Ursachen, z.B. EMV Probleme durch ausschalten der Spindel am File-Ende oder ähnliches.
Frank schrieb: > warum werden die Koordinaten nach abarbeiten eines Files und > beim Reset auf 0 gesetzt? (aktuelle Version V0.9d) Wenn in der letzten Zeile M05M30 oder M2 steht...
Tany schrieb: > Wenn in der letzten Zeile M05M30 oder M2 steht... G-Code Guidelines: "To end a program, program: M2 or M30. M2 leaves the next line to be executed as the M2 line. M30 "rewinds" the G-code file. These commands can have the following effects: Axis offsets are set to zero" Bei M30 / M2 macht GRBL also einen Reset/Nullsetzung. Um dieses etwas unglückliche Design für GRBL zu umgehen und die Nullsetzung zu verhindern, wird in meiner Software der M30 Befehl abgefangen und nicht auf GRBL ausgeführt. Eine Kombination wie M05M30 ist dabei nicht zulässig. Als letzter Befehl muss M30 daher alleine als letzte Zeile im Code stehen (oder weggelassen werden). Die G-Code Richtlinie ist für GRBL deshalb unglücklich, weil alle Weltkoordinaten bei M30 auf Null gesetzt werden (also auch der gesetzte Nullpunkt), die Maschinenkoordinaten aber nicht manipuliert werden können. Siehe dazu auch die Diskussionen oben im Thread. Daher wird der M30 Befehl von mir nicht zur Ausführung gebracht und nur als Programm-Ende Kennung benutzt. Dadurch bleiben die Nullpunkt-Koordinaten und die aktuelle Position erhalten und ein Reset/Nullsetzung beibt dem Anwender überlassen. Der Befehl M2 wird noch nicht abgefangen (da selten benutzt), dies wird aber für die nächste Version nachgeholt.
@ Tany Problem lag an Anweisung M2 in lezter Zeile. Danke! @ Albert Hinweis: In Version 0.7c war es kein Problem die Anweisung M2 zu verwenden. Vieleicht hilfreich?
Frank schrieb: > Hinweis: In Version 0.7c war es kein Problem die Anweisung M2 > zu verwenden. Vieleicht hilfreich? Wie gerade geschrieben (für die nächste Version): Zusätzlich zum M30 Befehl wird nun auch M2 ignoriert, d.h. diese File-Ende Befehle werden nicht ausgeführt um ein Reset zu vermeiden. M2 und M30 können damit optional am File-Ende stehen, bewirken aber weiter nichts.
Hier noch etwas mehr Hintergrund-Informationen über die M2 / M30 Problematik: https://github.com/grbl/grbl/issues/681
Albert M. schrieb: > Hier noch etwas mehr Hintergrund-Informationen über die M2 / M30 > Problematik: > > https://github.com/grbl/grbl/issues/681 Ohne das zu lesen: Nach M2 und M30 führt gbrl keine weitere G-Code mehr aus. D.h G-Mode ist nicht aktiv. Die nach M2/M30 gesendete G-Code gehen verloren. Um das wieder zu aktivieren braucht man bei Bedarf nur ~ rüber zu schicken und alles wieder i.O. M2 und M30 setzen zwar Controller zurück, die WPos bleibt aber erhalten. Du läßt aber nach dem Reset immer den Befehl G92 X0 Y0 Z0 ausführen und und setzt damit alle auf Null. Gruß Tany
Tany schrieb: > M2 und M30 setzen zwar Controller zurück, die WPos bleibt aber erhalten. Nein. Beweis (einfach mal ein Terminalprogramm am Arduino anschliessen); hier der Terminal-Dump: G92 X0 Y0 Z0 ok ? <Idle,MPos:-60.000,0.000,0.000,WPos:0.000,0.000,0.000> ok G90 ok G0 X-15.000 Y0.000 ok ? <Idle,MPos:-75.000,0.000,0.000,WPos:-15.000,0.000,0.000> ok M30 ~ ok Grbl 0.9i ['$' for help] ok ? <Idle,MPos:-75.000,0.000,0.000,WPos:-65.000,0.000,-9.412> ok Wie Du siehst steht nach ~ in den World-Koordinaten nur noch Unfug. Was meinst Du warum ich die Umstände in der Software mache, teilweise auch aus den Maschinen-Koordinaten zurückrechne, wenn es auch einfacher gehen würde? Das Thema ist für mich jetzt erledigt und ich bleibe vorerst bei meinem Ansatz bis sich event. hierzu in weiteren Versionen von GRBL was ändert.
Albert M. schrieb: > Was meinst Du warum ich die Umstände in der Software mache, teilweise > auch aus den Maschinen-Koordinaten zurückrechne, wenn es auch einfacher > gehen würde? Natürlich geht's viel einfacher, aber das Thema bleibt für dich erstmal erledigt. :-)
Albert M. schrieb: > Beweis (einfach mal ein Terminalprogramm am Arduino anschliessen); > hier der Terminal-Dump G92 X0 Y0 Z0 ok ? <Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000> ok G90 ok G0 X-15.000 Y0.000 ok ? <Idle,MPos:-15.000,0.000,0.000,WPos:-15.000,0.000,0.000> ok M30 ~ ok Grbl 0.9i ['$' for help] ok ? <Idle,MPos:-15.000,0.000,0.000,WPos:-15.000,0.000,0.000> ok
@ Tany Das stimmige Ergbnis erzielst Du nur nach einem Hard-Reset (Stecker raus/rein). Ist schon vorher einiges an Code gelaufen und diverse Resets ausgeführt, erhälst Du meistens ein völlig verkehrtes Ergebnis, wie ich oben eindeutig gezeigt habe. Glaube mir, dass ich diesbezüglich ausgiebig Versuchedurchgeführt habe und GRBL in dieser Beziehung nicht zu trauen ist. Daher ist vorerst mein Work-Around die sinnigste Lösung. Und wie schon geschrieben, werde ich mir dazu auch erstmal keine Gedanken mehr machen.
Hallo Albert, Super Programm!! habe eine kleine Frage. Ist es eine Option eine Loop einzubauen mit geändertem Z Wert gebraucht wird es bei mir wenn das Brett etwas dicker ist. z.B. neue Zeile am Ende Loop 3 Nxx Z+= -2 Loop 3 mal nach zeile Nxx mit wert Z + -2 Gruß Heinz
Hallo Albert, vielen Dank für Dein Projekt und das daraus entstandene SerialComCNC. Ich habe es jetzt auf einem Netbook laufen. Die ursprüngliche OS Version Windows 7 Starter wollte per tout keine Werte vom GRBL entgegen nehmen (Serial <-> USB Wandler CP2102). Nun habe ich mir eine Version Windows 7 Home Premium gekauft und siehe da: es funktioniert. Auf dem kleinen Bildschirm passt die Anwendung so gerade drauf. Schön wäre es wenn man einstellen könnte, daß das Programm immer im Vollbild startet (scheint zur Zeit eine festeingestellte Fenstergröße zu haben - kann in der Verknüpfung einstellen was ich will, es startet nicht im Vollbild), da ich das Tool im Autostart habe. Ansonsten bin ich mehr als zufrieden und habe das Programm schon weiter empfohlen. Ach ja, ich betreibe eine eShapeOko mit dem GRBL und einer 3fach TB6560 Treiber Stufe mit NEMA17 Motoren. Marco
Heinz schrieb: > habe eine kleine Frage. > Ist es eine Option eine Loop einzubauen mit geändertem Z Wert Loops werden in GRBL nicht Unterstützt. Was Du brauchst bietet Dir aber jedes CAM Programm mit dem Parameter Zustellung. Wenn Du im CAM Programm eine Frästiefe von z.B. 5 mm eingibst mit einer Zustellung von z.B. 2 mm wird ein G-Code erstellt der genau macht was Du möchtetst. Aber vieleicht habe ich Dich ja falsch verstanden? Marco schrieb: > Auf dem kleinen Bildschirm passt die Anwendung so gerade drauf. Schön > wäre es wenn man einstellen könnte, daß das Programm immer im Vollbild > startet Es freut micht, dass Du mit der Software zufrieden bist. Ab der nächsten Version kann das Arbeitsfenster beliebig vergrössert werden und die aktuelle Position/Grösse wird bei Programmende gespeichert.
Albert schrieb: > WertLoops werden in GRBL nicht Unterstützt. Was Du brauchst bietet Dir > aber jedes CAM Programm mit dem Parameter Zustellung. Wenn Du im CAM > Programm eine Frästiefe von z.B. 5 mm eingibst mit einer Zustellung von > z.B. 2 mm > wird ein G-Code erstellt der genau macht was Du möchtetst. Aber > vieleicht habe ich Dich ja falsch verstanden? ja wenn ich ein CAM Programm nutze ist das schon klar, aber bei einem kleinen Easy Job müsste ich Z ändern und den Rest noch einmal kopieren klar kann ich machen. Nur hatte ich mir gedacht wenn schon im Easy Job mit Parametern gearbeitet wird dann wäre das eine Möglichkeit, so wie bei plt Dateien. Eigendlich will ich das Programm nur loben heinz
Heinz schrieb: > ja wenn ich ein CAM Programm nutze ist das schon klar, aber bei einem > kleinen Easy Job müsste ich Z ändern und den Rest noch einmal kopieren > klar kann ich machen. Nur hatte ich mir gedacht wenn schon im Easy Job > mit Parametern gearbeitet wird dann wäre das eine Möglichkeit Dass Du den EasyJob meintest, ging aus Deinem ersten Post nicht so klar hervor. Der EasyJob erzeugt daselbe wie ein CAM Programm, damit geht dann genau das was Du möchtest.
Albert M. schrieb: > Es freut micht, dass Du mit der Software zufrieden bist. Ab der nächsten > Version kann das Arbeitsfenster beliebig vergrössert werden und die > aktuelle Position/Grösse wird bei Programmende gespeichert. Juhuu ! Vielen Dank ! Freue mich drauf. Bis bald Marco
Hallo Albert. Vielen dank für das gigantische Programm und für die ständige weiterentwiklung! L.G. aus Italien LM317
Hallo Albert,
ich teste v0.9d mit selbst gebautem Kreuztisch und Stift in der Z-Achse.
Im manuellem Prozess verfahre ich x und y um je +20mm setze x und y
auf 0, starte ein einfachen G-Code, bis dahin alles ok.
Komme aber nun nicht mehr auf die Home Position.
Mit v0.7 kann ich mit Reset die aktuelle Position in die Anzeige zurück
bringen und dann Home Position fahren.
Ist es vieleicht möglich es in der nächsten Version wieder wie in v0.7
zu machen?
Freue mich aber auch so die neue Version deines Super Programms zu
testen.
Im jetzigem Stadium meiner Stiftfräse verwende ich halt bis
auf weiteres v0.7.
Gruß
Frank
Frank schrieb: > Im manuellem Prozess verfahre ich x und y um je +20mm setze x und y > auf 0, starte ein einfachen G-Code, bis dahin alles ok. > Komme aber nun nicht mehr auf die Home Position. > Mit v0.7 kann ich mit Reset die aktuelle Position in die Anzeige zurück > bringen und dann Home Position fahren. Version 0.9d: Ich verstehe die Vorgehensweise nicht wirklich :) Normalerweise setzt man die gewünschte Home Position mit dem Button "Setze XYZ Null". Wenn man irgendwann auf Home zurück will betätigt man den * Button. Der Reset Button ist da kontraproguktiv, weil dann die Home Position gelöscht wird. LM317 schrieb im Beitrag #4121921: > Hallo Albert. > Vielen dank für das gigantische Programm und für die ständige > weiterentwiklung! > L.G. aus Italien > LM317 Freut mich, dass es Dir gefällt! Gruss Ulrich Albert
Albert M. schrieb: > Version 0.9d: > Ich verstehe die Vorgehensweise nicht wirklich :) > Normalerweise setzt man die gewünschte Home Position mit dem Button > "Setze XYZ Null". Wenn man irgendwann auf Home zurück will betätigt man > den * Button. Der Reset Button ist da kontraproguktiv, weil dann die > Home Position gelöscht wird. Um ein gleiches Objekt an verschiedenen Positionen zu fräsen(noch zeichnen) und am Ende wieder an die Maschinen Home Position zu gelangen ;) Ist vieleicht doof aber funktioniert mit v0.7. Gruß Frank
Frank schrieb: > Um ein gleiches Objekt an verschiedenen Positionen zu fräsen(noch > zeichnen) > und am Ende wieder an die Maschinen Home Position zu gelangen ;) > Ist vieleicht doof aber funktioniert mit v0.7. Also: Die Version 0.9d macht genau das was Du möchstet, wenn nicht hat das andere Ursachen. Das alles wurde oben im Thread bereits ausgiebig diskutiert.
Hallo Albert, ich glaube ich habe die Tastaturfunktion nicht kapiert: welche Tasten sind denn den einzelnen Achsen zugeordnet ? Die Cursor-Tasten machen jedenfalls nichts. Danke für eine kurze Rückmeldung. Marco
Marco schrieb: > welche Tasten > sind denn den einzelnen Achsen zugeordnet ? Die Cursor-Tasten machen > jedenfalls nichts. Bei "Tastatur" muss der Haken gesetzt sein. Die Steuerung erfolgt dann über den rechten numerischen Block der PC Tastatur (dabei darf die Num-Funktion der Tastatur nicht aktiviert sein). Der allererste Tastenanschlag nach Aktivierung von "Tastatur" wird immer ignoriert. X-Achse = Pfeil rechts/links (Tasten 6/4) Y-Achse = Pfeil oben/unten (Tasten 8/2) Z-Achse = Page Up/down (Tasten 9/3) Es muss natürlich vorher Feed und Vorschub passend gesetzt werden. Wenn man den numerischen Tastaturblock nicht verwenden will können alternativ auch die 4 Pfeil-Tasten und Page up/down der Tastatur genutzt werden. Vorsicht ist jedoch geboten die Tasten nicht solange gedrückt zu halten, dass die Repetierfunktion der Tastatur aufgerufen und beliebig oft in den Tastaturpuffer geschrieben wird und damit die Fräse mit Kommandos überflutet. Also immer nur kurz hintereinander die Tasten drücken :)
Hallo Albert, danke für die Antwort. Gerade im Keller gewesen, ausprobiert und für (fast) gut befunden. Mein Netbook hat weder einen Nummernblock noch Page up/down Tasten die nicht über die "FN" Taste aufgerufen werden. Aber ich habe schon eine Idee: ich habe hier noch einen Arduino pro micro (Leonardo) liegen, der als HID Device programmiert werden kann. Damit werde ich mir einen kleine Handsteuerrung bauen. Ach ja, was war denn nun mein Fehler ? Ich hatte vergessen Feed und Vorschub zu setzen. Wenn man das noch automatisch auf seine gewünschten Werte setzen könnte wäre das Prima: Netbook ein, SerialComCNC im Autostart, zum GRBL verbinden, Feed wird automatisch gesetzt, Handsteuerung ist ein, Fräser positionieren, auf Null setzen, G-Code aufrufen, Drehzahl festlegen und los gehts. Klasse ! Wieder einmal herzlichen Dank ! Das Tool macht immer mehr Spaß Marco
Albert M. schrieb: > Also: Die Version 0.9d macht genau das was Du möchstet, wenn nicht hat > das andere Ursachen. Das alles wurde oben im Thread bereits ausgiebig > diskutiert. Welche Ursachen könnten es sein? Kann machen was ich will es funktioniert einfach nicht. Vieleicht falsche Einstellung in GRBL? Hat oder hatte sonst noch jemand das gleich Problem. Bei Betätigung von * neben "Weiter" fährt nur die z-Achse 10mm hoch und wieder 10mm runter. x und y bleiben auf 0. Über Anregungen oder Lösung würde ich mich freuen. Frank
Frank schrieb: > Kann machen was ich will es funktioniert einfach nicht. Wir machen jetzt mal einen Versuch, gerade bei mir getestet :) Lade folgenden Code (macht einen Kreis um den Nullpunkt) M3 G0 Z2.00 G0 X20.000 Y40.000 G0 Z0.8 F400 G1 Z-3 F800 G2 X60.000 Y40.000 I20.000 G2 X20.000 Y40.000 I-20.000 G0 Z2.00 M5 M30 Setze den gewünschten Nullpunkt mit "Setze XYZ Null". Start Datei. Nachdem die Datei abgearbeitet ist steht in der Anzeige: X 20 Y 40 Z 2 Drücke jetzt den * Button (neben Weiter). Z fährt dann auf 10 hoch X und Y fahren auf Null Z fährt auf Null Somit bist Du nun genau wieder auf Deinen Nullpunkt zurückgefahren. Sollte auch bei Dir problemlos gehen. Wenn mit Deinem eigenem Code die Vorgehensweise nicht funktioniert, würde ich überprüfen ob darin das Koordinatensystem irgendwie beinflusst wird. Wenn bei Dir mit meiner obigen Demo nicht die angebenen Werte in X,Y,Z stehen, sondern Null, probiere das Ganze mal mit ausgeschalteten Treibern, also mit dem Arduino alleine. Funktioniert es dann, hast Du ein EMV Problem.
Hallo Albert, vielen Dank für die schnelle Antwort. Ist aber nicht das eigentliche Problem. Wenn ich z.B. diesen Kreis mehrmals zeichnen möchte in Abstäden von z.B 40mm, komme ich nicht mehr auf den den ursprünglichen Nullpunkt. Was wie schon gesagt mit v0.7 möglich war. Trotzdem Danke! Gruß Frank
@ Frank wie sieht das Programm aus? möchte mit meinem Programm testen... Gruß Tany
Frank schrieb: > Wenn ich z.B. diesen Kreis mehrmals zeichnen möchte in Abstäden von z.B > 40mm, komme ich nicht mehr auf den den ursprünglichen Nullpunkt. Ich könnte event. einen Master-Nullpunkt einführen, der beim Setzen von den Maschinenkoordinaten abgeleitet wird. Beim Aufrufen werden diese dann mit den aktuellen Maschinenkoordinaten verrechnet, d.h. mit den Differenz-Beträgen wird dann auf den Master-Nullpunkt zurückgefahren. Setzen und Aufrufen des Master-Nullpunktes würde dann über das Menue abgewickelt, um nicht noch mehr Buttons auf der Oberfläche zu haben. Der Master-Nullpunkt wäre auch gegen ein Soft-Reset resistent, da die Maschinenkoordinaten nur durch ein Hard-Reset zurück gesetzt weden können.
Angehängte Dateien:
-
Test.jpg
91 KB
Hallo Tany, hier das Programm und ein Foto fürs bessere Verständnis. G17 G90 G21 G00 Z2 G00 X10 Y15.099 M03 G01 Z-1 F200 G02 X15.099 Y10 I0 J-5.099 F700 G02 X10 Y4.9 I-5.099 J0 G02 X4.9 Y10 I0 J5.099 G02 X10 Y15.099 I5.099 J0 G00 Z2 G90 X0 Y0 G00 Z2 G01 Z-1 F200 X20 Y0 F700 X20 Y20 X0 Y20 X0 Y0 G00 Z0 M05 Erstes zeichnen +20mm,dann nullen, zweites zeichnen und so weiter. Mit v0.7 war es kein Problem nach dem Neunten wieder zum Start Nullpunkt zurück zu gelangen. Reset-Button drücken Koordinaten vom Start Nullpunkt stehen in Anzeige und dann Homefahrt ausführen. Ist alles ist nicht ganz so dramatisch, brauchte ich bis jetzt nur zur Überprüfung der Genauigkeit meines Prototypen. Und funktioniert ja noch immer mit v0.7. Gruß und Danke fürs Interesse Frank
Albert M. schrieb: > Ich könnte event. einen Master-Nullpunkt einführen, Hallo Albert, habe deinen Post gerade erst gesehen. Möchte dich nicht von den wichtigen Aufgaben abhalten sprich "Easy Job" usw. Habe nur gedacht da das Ganze in v0.7 ja schon einmal vorhanden war und auch ohne Probleme funktionierte. Wie in meinem Post an Tany schon geschrieben komme ich für meinen Zweck mit v0.7 klar. Wenn es mit dem Master-Nullpunkt für dich kein zu großer Aufwand ist und das Ganze auch so funktioniert wäre das mega Toll. Gruß Frank
Hallo Frank, bei mir funktioniert so tadellos; G17 G90 G21 G00 Z2 G00 X10 Y15.099 M03 G01 Z-1 F200 G02 X15.099 Y10 I0 J-5.099 F700 G02 X10 Y4.9 I-5.099 J0 G02 X4.9 Y10 I0 J5.099 G02 X10 Y15.099 I5.099 J0 G00 Z2 G90 X0 Y0 G00 Z2 G01 Z-1 F200 X20 Y0 F700 X20 Y20 X0 Y20 X0 Y0 G00 Z0 G54 x40Y0 G92X0Y0 G00 Z2 .... G00 Z0 G54 x40 Y-40 G92X0Y0 G00 Z2 .... G00 Z0 G92.1 G00 X0 Y0 M5 M30 Die Maschine fährt exakt auf 1. Nullpunkt zurück. Ich glaube M30 nutzt die echte CNC Maschine zur Zeilensprung (GOTO MarkeX:) Da die gbrl sehr beschränkt ist, kann man dies auch per Software ergänzen. Probiere mal mit G54 und G92/G92.1, vielleicht klapp's bei dir. Gruß Tany
Frank schrieb: > Wenn es mit dem Master-Nullpunkt für dich kein zu großer Aufwand ist und > das Ganze auch so funktioniert wäre das mega Toll. Ich habe die neue Funktion "Master Zero Point" implementiert: Set Master Zero Point Goto Master Zero Point Nach Setzen des Master Zero Point kann man beliebig oft normale Nullpunkte setzen, G-Code Files abarbeiten oder den Reset-Button betätigen. Nach Aufruf von "Goto Master Zero Point" wird danach immer genau auf den Master Zero Point zurückgefahren. Dabei wird die Z-Offset Einstellung berücksichtigt (Z hoch, verfahren, Z runter).
Albert M. schrieb: > Ich habe die neue Funktion "Master Zero Point" implementiert: Hallo Albert, freue mich schon auf die ersten Tests. Danke für deine Mühe. Hoffe das Thema hat dich nicht zu sehr von den anderen Aufgaben abgehalten. Viele Grüße Frank
Angehängte Dateien:
Oben seht ihr eine Vorschau auf die nächste Version im Entwicklungsstadium. Vorgesehen ist unter anderem ein Software JogDial, mal sehen ob sich der problemlos implementieren lässt. Bis jetzt funktioniert es im Prinzip, hat aber noch so einige Tücken. Die JogDial Funktion wird erst bei vergrössertem Programmfenster eingeblendet. Beim Drehen des JogDials verfährt die angewählte Achse je schneller je weiter die Drehung beträgt, beim Loslassen der Mouse-Taste springt der JogDial auf Null zurück. Die Auswertung der jeweiligen Drehposition ist logarithmisch, um bei kleineren Werten einen feinfühligeren Vorschub zu gewährleisten. Die max. Drehung nach rechts/links beträgt 180 Grad. Ausserdem gibt es eine umfangreiche neue Hilfe im HTML Browser Format und im CHM Format. Die EasyJob Funktionen dauern noch.
Angehängte Dateien:
-
Foto.JPG
150 KB
Hallo Albert, habe meine alte Handsteuerung für GRBL, die niemals funktioniert hat, wieder rausgekramt und die Platine darin geändert für den Arduino pro micro. Jetzt habe ich noch eine freie Taste (die runde in der Mitte). Kann man noch das "Set all axis to zero" - also Nullpunktsetzen auf eine Taste legen, welche ich dann nutzen kann ? Dann kann ich die Fräse mit der Handsteuerung positionieren und auch gleich den Nullpunkt setzen. Vielen Dank & schönen Sonntag Marco
Marco schrieb: > Jetzt habe ich noch eine freie Taste (die runde in der Mitte). Kann man > noch das "Set all axis to zero" - also Nullpunktsetzen auf eine Taste > legen, welche ich dann nutzen kann ? Dann kann ich die Fräse mit der > Handsteuerung positionieren und auch gleich den Nullpunkt setzen. Werde ich für die nächste Version berücksichtigen. Als Tastenzuordnung werde ich Z benutzen und nicht im Tastatur-Zehnerblock die 5, um versehentliches Nullsetzten für alle die die Pfeiltasten verwenden, zu vermeiden.
Schönen Sontag Abend allerseits. Seit kurzem habe ich begonnen mir eine kleine cnc fräse zu bauen. Da ich bereits einige Erfahrung mit Arduino habe ist die Entscheidung auf grbl gefallen, und als Steuersoftware würde ich gerne deine Software benutzen. Ich habe zwar noch fast noch nie mit einer cnc fräse gearbeitet, aber da ein Bekannter von mir eine „Professionelle“ Maschine besitzt, und ich ihm schon einige Male über die Schulter geschaut habe, wenn er für mich eine leiterplatte gefräst hat, traue ich mir die Bedienung durchaus zu. Seine Maschiene läuft über die Software kay, bei der es die Möglichkeit gibt den gcode zu vervielfältigen, zu drehen und zu spiegeln. Da ich meine fräse in erster Linie zum gravieren und bohren von Leiterplatten verwenden werde, wäre vor allem die Funktion zum Vervielfältigen und zum spiegeln sehr hilfreich. Könnten diese Funktionen eventuell in der nächsten Version eingebaut werden? Es hat aber keine Eile, da ich die Hardware meiner fräse auch erst bauen muss, was bei meinem handwerklichen Geschick einige Tage länger dauern könnte :-). Ich wäre dir sehr dankbar! Ich habe schon etwas mit deiner Software rumgespielt, und da ist mir die Funktion Excelon Drill Data Converter aufgefallen, kann ich damit also CAM direkt mit EAGLE erzeugen und Importieren, ohne irgendein ULP? Ich habe auch noch eine Frage an alle: Was für einen fräsmotor verwendet ihr? Bei meinem bekannten ist ein Bosch (Isel) UFM 500 verbaut, der allerdings für meine Verwendung mit 500W leicht überdimensioniert ist oder was sagt ihr dazu? Ich habe einen Dremel herumliegen, den ich immer zum aufbohren und schneiden von Lochraster verwende. Er hat 130W und geht bis auf 33.000U/min kann ich in verwenden? Reichen 130W wenn ich auch mal etwas dickeres z.B. eine Alu frontplatte fräsen will? Der dremel ist zudem nicht lastgeregelt, was bedeutet, das er bei zu hoher last langsamer wird, ist das ein Problem? Das ist für mich komplettes Neuland, weshalb ich für sämtliche Anregungen offen bin. Hoffe auf zahlreiche Antworten! Thomas D. P.S. Link zu Kay: http://www.galaad.net/galaad3-deu.exe (vielleicht findest du ja sonst noch nützliche funktionen)
Thomas D. schrieb: > Ich habe einen Dremel herumliegen Ich rate dir von der Verwendung eines Dremels als Spindel ab, ich habe selbst einen dremel 3000 an meiner Fräsmaschine und er hat schon zwei Mal mitten bei der Arbeit aufgehört zu drehen und musste repariert werden (zum Glück noch unter Garantie). Zur Leistung kann ich sagen, dass 130W zum Fräsen von Platinen und anderen weichen Materialien durchaus ausreichen. Wie es mit Alu aussieht weiß ich nicht, es hängt aber vor allem vom Durchmesser des Fräsers und dem Vorschub ab.
Albert M. schrieb: > Werde ich für die nächste Version berücksichtigen. Als Tastenzuordnung > werde ich Z benutzen und nicht im Tastatur-Zehnerblock die 5, um > versehentliches Nullsetzten für alle die die Pfeiltasten verwenden, zu > vermeiden. Hallo Albert, tolle News ! Danke ! Gruß Marco
Hallo Albert, ich habe nun einen Arduino Nano V3 mit CH340 seriell/USB Wandler mit GRBL 0.9i im Einsatz. Leider braucht es häufig einen Reset des Controllers mittels Reset-Taster, damit dieser von Deinem Programm erkannt wird. Ein Arduino pro Mini mit einem CP2122 seriell/USB Wandler wird dagegen sofort erkannt. Es scheint so als ob der Controller (ATMega 328P) nicht immer beim Initialisieren der Schnittstelle einen Reset bekommt. Hast Du eine Idee ? Gruß Marco
Marco schrieb: > ich habe nun einen Arduino Nano V3 mit CH340 seriell/USB Wandler mit > GRBL 0.9i im Einsatz. Leider braucht es häufig einen Reset des > Controllers mittels Reset-Taster, damit dieser von Deinem Programm > erkannt wird. Ein Arduino pro Mini mit einem CP2122 seriell/USB Wandler > wird dagegen sofort erkannt. Das sind Treiber Probleme die mit meiner Software nichts zu tun haben. Leider weiss ich da auch keinen Rat. Versuche es doch mal hier: https://github.com/grbl/grbl/issues
Angehängte Dateien:
-
SerialComCNC_v0.9e.png
110 KB
Anbei SerialComCNC Version 0.9e Change Log V0.9e ---------------- Neue ausführliche Hilfe im HTML Browser Format. Es wird dabei der default Web-Browser aufgerufen. Alternativ befindet sich ein CHM-Hilfe File im Ordner. Das Programmfenster kann jetzt beliebig vergrössert werden. Die unter Einstellungen/Graphic vordefinierten Skalierungen können nun auch im Monitor/Graphic Fenster direkt am oberen rechten Graphic-Fensterrand aufgerufen werden. Graphische Darstellung jetzt immer isometrisch. Bei der Einstellung der Achsen können nun nur noch Xmin, Xmax und Ymin geändert werden. Ymax wird daraus autom. bei Klick auf "Update Graphic" so berechnet, dass sich eine isometrische Darstellung (Kreis ist immer rund) ergibt. Beim Vergrössern/Verkleinern des Programmfensters bleibt die Isometrie erhalten. Wenn unter Einstellungen/Graphic "Supress Lines" markiert ist, werden nicht mehr alle XY-Bewegungen schwarz dargestellt, sondern nur noch bei einer Z Höhe kleiner Null. Bei einer Z-Höhe grösser und gleich Null wird die Bewegung nur noch als dünne blaue Linie gezeichnet (siehe Bild oben). Der Video-Modus kann jetzt nicht mehr während des Fräsbetriebes (File-Mode) gestartet werden. Fehler bei den Einstellungen bei Set Move mm behoben. Die benutzte Einstellung wird mit einer roten Button-Beschriftung markiert. Zusätzlich zu den Pfeiltasten an der Eingabebox lassen sich die Werte auch mit mit den Pfeiltasten (Up/Down) des numerischen Keyboards ändern und mit den PageUp/PageDown Tasten um jeweil dem 10 fachen des vorgegebenen Wertes. Fehler nach Notstop "kein gültiger Gleitkommawert" behoben. Bei Programmende werden gespeichert: ComPort und Baudrate, "Home Offs Z0", Position und Grösse des Programm-Fensters. Zusätzlich zum M30 Befehl wird nun auch M2 ignoriert, d.h. diese File-Ende Befehle werden nicht ausgeführt um ein Reset zu vermeiden. M2 und M30 können damit optional am File-Ende stehen, bewirken aber weiter nichts. Hintergründe siehe dazu: https://github.com/grbl/grbl/issues/681 Neue Funktion "Master Zero Point" implementiert, erreichbar über Einstellungen: Set Master Zero Point / Goto Master Zero Point Nach Setzen des Master Zero Point kann man beliebig oft normale Nullpunkte setzen, G-Code Files abarbeiten oder den Reset-Button betätigen. Nach Aufruf von "Goto Master Zero Point" wird danach immer genau auf den Master Zero Point zurückgefahren. Dabei wird die Z-Offset Einstellung berücksichtigt (Z hoch, verfahren, Z runter). Änderung der Menue-Struktur unter Einstellungen. Erweiterung des XYZ Verfahrens über die Tastatur: Über die Taste Z kann jetzt der Button "Set XYZ Zero" simuliert werden. Experimental: Software-JogDial für langsamen manuellen Vorschub. Über Einstellungen/System/JogDial zu aktivieren und erscheint erst beim Vergrössern des Programm-Fensters. Die numerische Anzeige über dem JogDial zeigt lediglich die Umdrehung des Dials von -3 bis +3 an und hat ansonsten keine Relevanz. Da die JogDial Funktion systembedingt erheblich von der Standard-Kommunikation negativ beeinflusst wird und der Nutzen eher Zweifelhaft ist, ist es zur Zeit ungewiss ob es diese Funktion in Zukunft weiter gibt. Dies hängt auch von der Reaktion der Anwender ab. Gruss Ulrich Albert http://www.serialcominstruments.com/
Bug Report Ich habe noch Fehler in der neuen Version festgestellt: Bei der Fenstervergrösserung auf Full-Screen gibt es beim erneuten Start eine Zugriffsverletzung. Diese bis zur Fehlerbehebung einfach ignorieren oder am Besten den FullScreen Mode vermeiden. Der JogDial wird beim Neustart nicht immer angezeigt. Dann unter Einstellungen/System das Häkchen bei JogDial entfernen und neu setzen um den JogDial anzuzeigen. Die Fehler werden inder nächsten Version behoben.
Albert M. schrieb: > Das sind Treiber Probleme die mit meiner Software nichts zu tun haben. Hallo Albert, ich habe gestern Abend noch weiter getestet und kann das bestätigen ! Auf einem ICH7 Board (Samsung Netbook NC10 oder NC110) kommt kein Reset beim Öffnen der Schnittstelle. Nur wenn ich z.B. in Termite explizit die Schnittstellen Parameter auf DTR-Flowcontrol einstelle kommt ein Resst. Bei meinem Desktop Rechner (irgendwas Intel Series 7) funktioniert es mit dem selben Treiber wunderbar und der ATMega wird sauber resetet. Verdammt, langsam verliere ich die Geduld mit dem Netbook. Also weiter testen ... Danke für Deine Geduld ! Marco
Marco schrieb: > Hallo Albert, Ich sehe jetzt erst das Dein Name Ulrich ist und Albert Dein Nachname peinlich ! Tut mir leid das ich das verwechselt habe. Gruß Marco
Marco schrieb: > Ich sehe jetzt erst das Dein Name Ulrich ist und Albert Dein Nachname > peinlich ! Tut mir leid das ich das verwechselt habe. Auch daneben, aber macht nichts. Brauchst nur in mein Programm schauen, da steht der Name vollständig :)
Betr. Viruswarung bei der neuen Version von SerielComCNC Ich habe eine Mitteilung von einem Anwender erhalten, dass die Software einen Virus-Alarm auslöst. Dazu folgendes: Die Software SerialComCNC ist ab Version 0.9c durch eine Virtualisierungs-Software vor Hacker, Analyse, Modifikation und Disassembierung geschützt. Durch die Virtualisierung und die interne Virtual Maschine können Codefragmente entstehen, die Ähnlichkeiten mit Virus Signaturen haben und daher bei einigen Virenscannern in der Heuristik Alarm auslösen, vermeiden lässt sich das leider nicht. Ich versichere aber ausdrücklich, dass meine Software keinerlei Virus enthält. Gruss Ulrich Albert
Angehängte Dateien:
-
Unbenannt.JPG
20 KB
Schönes Wochenende Allerseits! Da ich gesehen habe, dass SerialComCNC immer noch kein eigenes Logo bekommen hat, habe ich schnell eines Zusammengezimmert (der orange/rosa Hintergrund soll Kupfer darstellen). Ich hoffe es gefällt jemanden. Im Anhang das .ico file. Grüße Gabriel
Gabriel M. schrieb: > immer noch kein eigenes Logo bekommen hat Da war ich bis jetzt zu faul für. Dein Vorschlag sieht aber schon mal gut aus :)
Gabriel M. schrieb: > Ich hoffe es gefällt jemanden Jepp, sieht klasse aus und auch gleich gesichert ! Danke & frohe Pfingsten. Marco
Hallo Ulrich, ich gebe auf mit dem CH340G USB-seriell Wandler auf meinem Arduino Nano V3 Clone. Habe mir gerade ein CP2102 Wandler Board bei eBay ersteigert und einen Arduino Pro Mini fertig gemacht. Das passt (läuft ja so schon im Versuchsaufbau) und läuft streßfrei (das wichtigste). Gruß Marco
Hallo Albert,
Goto Master Zero Point funktioniert nach abarbeiten von G-Code bei
mir nicht. Bleibt grau (nicht wählbar) ist das nur bei mir so?
Funktioniert nur wenn ich in Hand verfahre null setze, danach erneut
verfahre null setze usw. dann Goto Master Zero Point.
Alles andere was ich bis jetzt testen konnte sieht super aus.
Gruß
Frank
Frank schrieb: > Goto Master Zero Point funktioniert nach abarbeiten von G-Code bei > mir nicht. Wird in den nächsten Tagen mit neuer Version korrigiert.
Anbei SerialComCNC Version 0.9e1 - Maintenance Release Change Log V0.9e1 ----------------- Fehler behoben: - Goto Master Zero Point wurde nicht korrekt freigegeben. - JogDial wurde beim Programmstart nicht immer angezeigt. - Zugriffsverletzung beim Programmstart behoben. Neues Programm-Icon. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Ulrich, ich habe gestern Abend Deine neue Version getestet. Leider lässt sich diese nicht im Vollbild Modus auf dem Netbook starten. Das merken der letzten Fenstergröße funktioniert aber ! Gruß Marco
Marco schrieb: > nicht im Vollbild Modus auf dem Netbook starten. Das merken der > letzten Fenstergröße funktioniert aber ! Im Vollbildmodus zickt die Komponente welche die Programm-Properties und andere Einstellungen speichert, warum hab ich noch nicht rausgefunden und daher habe ich Vollbilmodus z.Z. deaktiviert. Es ist aber möglich das Fenster bis auf fast Vollbildmodus zu vergrössern, dabei funktioniert auch das Speichern der Fensterposition + Grösse.
Albert M. schrieb: > - Goto Master Zero Point wurde nicht korrekt freigegeben. > - JogDial wurde beim Programmstart nicht immer angezeigt. Hallo Albert, kurze Rückmeldung, Goto Master Zero Point funktioniert prima. :-) JogDial läst sich bei mir nicht aktivieren. Gruß Frank
Frank schrieb: > JogDial läst sich bei mir nicht aktivieren JogDial wird erst eingeblendet wenn die Programmfensterbreite grösser als 1740 Pixel wird. Auf kleinen Bildschirmen passt das nicht.
Warum nicht aktivieren die vierte Achse?
Weil: Grbl is for three axis machines. No rotation axes (yet) – just X, Y, and Z. https://github.com/grbl/grbl/wiki
Slavoljub schrieb: > https://www.synthetos.com/project/tinyg/ This board is not compatible to Arduino/GRBL because there is no Arduino firmware for the ATxmega192. There are also Arduino compatible boards like the RAMBo v1.3 (http://reprap.org/wiki/Rambo_v1.3) with four and more axes, but they are designed for 3d printing with Marlin or Teacup. GRBL supports only 3 axes, because on the Arduino UNO for which it is officially written, there are only just enough pins for 3 axes and one end stop per axe. There are a few solutions working with the Arduino 2560 and a modified GRBL version (https://github.com/LETARTARE/Grbl-xx_with_Arduino) for 4 axes, but Ulrich wrote: Albert M. schrieb: > Ändern möchte ich GRBL auf keinen Fall. Ich will mich bei meinem > Programm immer auf die aktuelle/offizielle GRBL Version stützen. and Albert M. schrieb: > Daher möchte ich mich, zumindest vorerst, auf die offiziellen GRBL > Version stützen, auch wenn das ein odere andere noch fehlt.
Hallo!!! Ich wollte eigentlich nur nachfragen ob es mittlerweile eine neue version von deinem tollen programm gibt. Gabriel M. schrieb: > Thomas D. schrieb: >> Ich habe einen Dremel herumliegen > > Ich rate dir von der Verwendung eines Dremels als Spindel ab, ich habe > selbst einen dremel 3000 an meiner Fräsmaschine und er hat schon zwei > Mal mitten bei der Arbeit aufgehört zu drehen und musste repariert > werden (zum Glück noch unter Garantie). Zur Leistung kann ich sagen, > dass 130W zum Fräsen von Platinen und anderen weichen Materialien > durchaus ausreichen. Wie es mit Alu aussieht weiß ich nicht, es hängt > aber vor allem vom Durchmesser des Fräsers und dem Vorschub ab. danke gabriel für deine erfarungen, was würdet ihr mir als alternative empfehlen? hoffe wie immer auf zahlreiche antworten!
Thomas D. schrieb: > Ich wollte eigentlich nur nachfragen ob es mittlerweile eine neue > version von deinem tollen programm gibt. Sorry, aber im Sommer häng ich lieber ab als Code zu schreiben oder gehe anderen Hobbies nach, z.B. http://www.fotocommunity.de/fotograf/ulrich-maassen/fotos/1508221
Ich habe schon 6h am Stück mit einem Proxxon IB/E gefräst. Die alte Version mit einem Lager hat das Problem, daß das Lager nach 15-20h getauscht werden muß. Die neue Version hat 2 Lager, die für ein deutlich geringeres Axialspiel sorgen und leichter getauscht werden können aber der neue/andere Lüfterflügel ist wohl daran Schuld, daß das Gehäuse viel heißer wird (45-50°C nach 50min).
你好！ schrieb: > 你好！我不知道为什么出现这个问题，能不能帮我一下。谢谢 If you are not able to open that web link contact your internet provider or your government authorities. https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9
Die Software hat sich super entwickelt! Ich habe kürzlich ein Upgrade von Win 7 auf Win 10 durchgeführt. Seither kann ich mich nicht mehr mit dem GRBL-Board verbinden. Im Geräte-Manager wird das Board mit passendem Com-Port (COM6) angezeigt, doch in SerialComCNC lässt sicht dieser nicht auswählen. Es steht nur "COM" zurverfügung und führt natürlich zu keiner erfolgreichen Verbindung.(Ein Starten als Administrator bringt auch keine Besserung) Hat noch irgenwer ähnliche Probleme? Gibt es schon eine Lösung?
Ich habe Windows 10 drehen und kein Problem mit Com-Port. Alles funktioniert perfekt. Es ist auch möglich, dass man irgendwo in den G-Code gestartet werden kann. Wenn vorhanden ist, bricht ein Fräsen. Wann wird es ein neues Update von geben?
Hallo Erst mal ein großes Lob Das ist genau die Software die man braucht und nicht mehr. Ich habe mir eine Fräse gebaut und dann lange nach einer Kosten günstigen und verständlichen Software gesucht. Die hier topt sie alle! Danke. Was mir allerdings aufgefallen ist: Der Befehl G91 im G-Code verursacht bei allen Programmen einige Probleme. Direkt eingabe ist kein Problem aber aufrufen im G-Code Programm. Ich hoffe der link funktioniert: https://dl.dropboxusercontent.com/u/17761293/Neues%20Textdokument.txt last das programm mal simulieren und dann löscht die zeile G91. Bei mir ist es einmal ein Kreis mit 4 Linien und einmal 4 Kreise mit einer Linie. Danke moch mal an den Autor super Arbeit!
Hallo Rüdiger teste mal mit G92
Rüdiger H. schrieb: > Der Befehl G91 im G-Code verursacht > bei allen Programmen einige Probleme. Bist du sicher, daß G91 da passt? G91 ist für relative Bemaßung. http://www.projekte.sbsz-hildburghausen.de/didakt2/bemass.htm
Tolle Software!!! Leider wird die Schnittstelle vom Arduino-Mega-2560 nicht erkannt. Von anderen Programmen(z.B. Glrb-Controller, universal-Glrb-Controler...) wird der Arduino-Mega-2560 erkannt. Andere USB/Serielladapter werden von SerialCNC erkannt. Gruß, Manfred
Manfred schrieb: > Leider wird die Schnittstelle vom Arduino-Mega-2560 nicht erkannt. Bei mir wird die die Arduino Mega 2560 ohne weiteres auch von SerialComCNC erkannt, und funktioniert auch problemlos damit. Versuche mal den PC neu zu starten, oder den Treiber neu zu installieren. Grüße Gabriel
Hallo zusammen, zunächst mal vielen Dank für die großartige APP an Albert!!! Kurz meine Motivation: Die meiste Zeit arbeite ich mit Ubuntu, sowohl Office und als Coder. Als Musiker bisher mit WIN neuerdings mit einem Hackintosh, wegen meinen heiß geliebten APPs (Studio One, Bidule, Ableton Live...) Als Elektroniker fehlte mir nun WIN für mein Hantek DSO und OpenLogicSniffer. Deshalb habe ich mir kurzerhand ein preiswertes WIN8.1/10 8,9 Zoll Tablet mit 1200 x 800 px gekauft. Auf 125% Vergrößerung lasst sich nun alles am Touchscreen gut bedienen, macht richtig Spaß, und nimmt wenig Platz weg ;-) Nun liegt es nahe, auch SerialComCNC dort laufen zu lassen, was auch wunderbar funst. Bisher habe ich den UniversalGcodeSender unter Ubuntu benutzt. SerialComCNC ist natürlich um Längen besser, vor allem auch in Erwartung auf EasyJob ;-) Also Albert, genieße das schöne Wetter, mach ich die nächsten Wochen auch, und dann würde ich mit Dir und der Community hier, gerne meine Vorschläge diskutieren....... Da ich nun an meinem Tablet keine "große" Tastatur anschließen möchte, suche ich eine Alternative zur (Hand)Steuerung. Ich könnte mir gut vorstellen, alles mit einem USB Nummernblock zu bedienen! - Die X,Y,Z Steuerung ist ja schon da Erweiterungen: - Auf der "5" könnte man noch den Home Button installieren, so wie in der SerialComCNC GUI - Das JogDial wird ja bei meiner Auflösung von 1200 x 800 px nicht angezeigt. Mann könnte alternativ eine "zweite Ebene" über die X,Y,Z Steuerung legen, und dann die Feinjustierung vornehmen. Eventuell mit der Num Taste auf Zahleneingabe umschalten, und dann die Entsprechenden Zahlen verwenden. Die liefern die einen anderen Code wie die "normalen Zahlentasten". - Mit den +/- Tasten die FeedRate in 100er Schritten verändern - Alternativ +/- Spindel Rate Weiter Ideen? Cheers, ToM
Gabriel M. schrieb: > Versuche > mal den PC neu zu starten, oder den Treiber neu zu installieren. Tja, hab schon alles durch, liegt wohl an Win-10. Habe es auf 2 Rechnern mit Win-10 probiert, ohne Erfolg. Im Terminalprogramm meldet sich der Arduino mit der entsprechenden Grbl 0.9 Version. Ich kann ja auch den Arduino ohne weiteres flashen. Die Software "Universal G-Code-Sender" arbeitet ja auch unter Win-10 mit dem Arduino, nur SerialCncCom erkennt den Port nicht. Auf einem Win-XP Rechner läuft alles ohne Probleme. Gruß, Manfred
Hallo Manfred, auf meinem oben erwähnten Tablet WIN8.1, nach Update WIN10, verhält es sich genau umgekehrt. Also UniversalGcodeSender läuft NICHT und SerialComCNC erkennt GRBL!? Ich habe allerdings noch andere USB Serial Treiber/Geräte angeschlossen... Habe auch schon mit den Treibern experimentiert, immer mit dem o.gen. Ergebnis (was mir natürlich recht ist). Als ich das Tablet neu hatte WIN8.1 ohne Updates, lief der UniversalGcodeSender... Gruß, ToM
Hallo Manfred Hatte ein änliches problem. Als ich den Aduino aus dem usb3 rauszog und durch zufall auf nen usb2 Port setzte hats gefunzt. Allerdings muß ich bei jedem start von SerialComCNC die Baud zwischen 9600 und custom hin und her schalten.
Hallo Leute, erst einmal vielen Dank an den Autor für die Bereitstellung der Software!!! Zuvor hatte ich als Gast (Manfred) ja schon einmal auf das Port-Scann-Problem unter Win-10 geschrieben. Da mich das Thema interessiert habe ich mich nun hier im Forum angemeldet. Ich möchte mich kurz vorstellen: Mein Vorname ist Manfred, Alter:58,leider EU-Rentner,unterwegs in Industriesteuerungen(SPS),Elektronik,Layoutentwicklung, PIC-Controllern, neuerdings Arduino. Eine CNC-Fräse(700X400) benutze ich bereits unter WinPCNC_USB. Da bei mir eine kleine Fräse(340X240) frei geworden ist, plane ich eine Kombi aus Fräse + 3-Drucker. Da kommt jetzt der Arduino + SerialCncCom ins Spiel. Gruß, Manfred
Rüdiger H. schrieb: > Als ich den Aduino aus dem usb3 rauszog und durch zufall auf nen usb2 > Port setzte hats gefunzt. Hallo Rüdiger, danke für deinen Tip!! hat leider nicht funktioniert, selbst mit zwischengeschaltetem 2.0-HUB. Ich denke, dass der Atmega 2560 sich auf eine Weise registriert, die im Portscan von SeriaCncCom nicht berücksichtigt wird. Win-10 hat da eventuell eine Falltür eingebaut. Was mich nur stuzt, die anderen Programme(Terminal, Grbl-Controller,Arduino) erkennen den Port. Gruß, Manfred
Hi ich habe nun auch einen UNO Clone mit CH340. Nach dem Reduzieren der Baudrate von der Standardeinstellung auf 9600 funktioniert Es wie es soll. Auch von mir ein riesen Lob an dieses überaus gelungene Tool. Respekt, Daumen hoch und weiter so!
Hallo Albert, konntest Du bereits einmal über meinen Vorschlag nachdenken? Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" 1. Nun habe ich eine konkrete Frage um Thema "tool table": Wir haben in den letzten Tagen eine große Holzfräse mit GRBL verbunden, und sie läuft wunderbar. Die Werkzuge werden hier mit einem Kegel montiert, der pneumatisch wechselbar ist. Es sind mehrere Werkzeuge auf verschiedenen Kegeln vormontiert, und die verschiedenen Längen müssen berücksichtigt werden! Könnte man SerialComCNC um eine "tool table" erweitern die den "tool length offset (G43.1)" berücksichtigt? Oder sonst eine Idee, wie man das lösen kann? 2. In diesem Zusammenhang: Kann man im "G-Code Datei Display" den Prozess hinten "Werkezugwechsel Txx" so verändern, dass eine definierte XYZ Position zum Werkzeugwechsel angefahren wird? Bei großen Maschinen ist das sehr hilfreich..... Gruß, ToM
@ ToM ToM Im Moment bin ich mit meinen anderen Projekten beschäftigt. Wenn ich wieder Zeit und Motivation für SerialComCNC habe komme ich auf Deine Anliegen zurück :) Gruss Ulrich Albert
Hallo Ulrich. Wie können wir dich motivieren, dieses herausragende Projekt weiterzuführen ? Wir könnten ja mal eine Umfrage starten, wieviel dankbare Nutzer deines Programms es gibt. @ToM würde ich allerdings etwas mehr Bescheidenheit empfehlen...
Hallo Können Sie mir Eventuell sagen ob der CNC Xpro V2 auch unterstützt wird ? Es ist quasi ein Arduino welcher mit Stepper Steuerung erweitert wurde http://www.spark-concepts.com/cnc-xpro-controller-v2/ Auf der Homepage steht The CNC xPRO is designed to run the opensource gcode interpreter GRBL, opensource programming environment Arduino, or anything you can write in AVR studio. The xPRO comes pre-flashed with GRBL so all you need to do is wire up your motors! Danke Peter
boskap schrieb: > Können Sie mir Eventuell sagen ob der CNC Xpro V2 auch unterstützt wird > ? > Es ist quasi ein Arduino welcher mit Stepper Steuerung erweitert wurde > http://www.spark-concepts.com/cnc-xpro-controller-v2/ Sorry, zu dem 129 $ Teil kann ich nichts sagen. Nur soviel: Den darauf verbauten DRV8825 Stepper Drivers würde ich nicht trauen, da ohne Kühlkörper verbaut. Und wenn Dir darauf ein Driver oder sonst was stirbt, darft Du gleich ein neues Board kaufen. Normalerweise ist ein 10 Euro Arduino Uno und 3 zusätzliche Stepper Driver Boards (mit grossem Kühlkörper) für ca. 8 Euro alles was man braucht um SerialComCNC zu betreiben. http://www.ebay.de/itm/CNC-Router-Single-Axis-3A-TB6560-Stepper-Motor-Driver-Board-for-axiscontrol-/221782471247?hash=item33a343f24f Gibt es auch hier, allerdings für ca. 14 Euro. Gruss Ulrich Albert
Hallo Nun ich habe ja das Teil und verwende das GBRL Panel oder den Universal G Code Sender Und ich will unbedingt die Sache mit der Webcam Positionierung realisieren Doch die Weiterführung der oben genannten Software lässt auf sich warten Und nun bin auch auf Ihr Tool gestoßen und war gleich mal überwältigt. Also habe ich die Software Installiert und Connect gedrückt und siehe da Ohne Probleme eine Verbindung Doch manueles bewegen über die Pfeil Buttons funktioniert nicht Auch die Maschinen Position wird nicht ausgelessen Mir ist aufgefallen das die GRPL Panel SW bei 1 MM Step Y -1 einen anderen Gocde übertragt als Ihre Nehm ich den Code und sende in mauel im SerialcomCNC so funktioniert es Ich würde mich sehr freuen wenn es irgendwie funktionieren würde Kann ich Ihnen ein etwas schicken was dazu hilft ? Danke Peter
Hallo Ich muss mich gleich entschuldigen Es funktioniert ich hatte einen denkfehler ich dache wenn ich auf den button 10 klicke und dann einen der pfeile so fährt er 10mm doch mann muss bei move mm den wert einsetzen und dann funktionierts gibt es eine möglichkeit sich die maschinenkoordinaten anzeigen zu lassen ? Und bitte die Webcam funktion nicht entfernen (hab ich irgendwo im forum gelesen) danke
boskap schrieb: > Doch manueles bewegen über die Pfeil Buttons funktioniert nicht Oft wird vergessen den "Set Feed" Button zum Übernehmen des in "Move mm" eingestellten Wertes zu klicken. boskap schrieb: > Auch die Maschinen Position wird nicht ausgelessen Es wird in SerialComCNC nicht mit Maschinen-Koordinaten gearbeitet, sondern mit Welt-Koordinaten. Diese setzt man am gewünschten Werkstellnullpunkt mittels Button "Set XYZ Null" auf Null. Auf diesen Nullpunkt beziehen sich dann die angezeigten Werte nach Bewegen von X, Y, oder Z. boskap schrieb: > Kann ich Ihnen ein etwas schicken was dazu hilft ? Sorry, aber dazu fehlt mir die Zeit. Leider kann ich mich nicht auch noch mit irgendwelchen mehr oder weniger exotischen Boards befassen. Aber ich denke mal wenn das GBRL Panel oder der Universal G Code Sender auf dem Board laufen, spricht eigentlich nichts dagegen, dass auch SerialComCNC funktioniert. P.S. meine Antwort hat sich wohl mit Deinem obigen Post überschnitten, schön dass es bei Dir jetzt läuft :)
Hallo Ja danke es dürfte sich überschnitten haben jetzt kämpf ich nur mehr mit der webcam Die sw sagt immer no webcam found Aber die logitech sw findet sie oder gehen nur bestimmte cams ? lg und danke nochmals Peter
boskap schrieb: > jetzt kämpf ich nur mehr mit der webcam > Die sw sagt immer no webcam found > Aber die logitech sw findet sie > oder gehen nur bestimmte cams ? Es kann etwas länger dauern bis dass die Webcam zum ersten Mal gefunden wird. Das ist auch bei meinem sehr schnellen PC so. Ob alle WebCams funktionieren kann ich nicht sagen, Logitech habe ich selber dran.
Angehängte Dateien:
-
Picture_1.jpg
26 KB -
Picture_2.jpg
23 KB
OK Ich würde nämlich gerne die c525 bzw c615 verwenden die kann man nämlich öffnen und die mit kleber fixierte Optik vorsichtig lösen damit kann man dann fast in den Makro Bereich gehen Bild 1 Lineal Bild 2 Dremel Fräser
Angehängte Dateien:
-
webcam.png
22 KB
Hallo Das Webcam Problem ist gelöst es funktioniert sofort wenn ich SerialComCNC mit rechtsklick und "als Administrator starten" starte Also eine Rechte sache Eine Frage noch das Webcam Fenster ist dann nur 2x2 cm gross wie kann ich es grösser darstellen ? danke Peter
boskap schrieb: > das Webcam Fenster ist dann nur 2x2 cm gross Da hat sich in der letzten Version ein Fehler eingeschlichen. Wird in der nächsten Version korrigiert. Da Du bisher der Einzige bist, der den Bug bemerkt hat, zeigt dass die Video Funktion mehr ein Gimmik ist als wirklich verwendet. Für die nächste Version bleibt die Video Funktion noch erhalten, für weitere Versionen bin ich noch unschlüssig, da wegen Treiberprobleme und schlechter Performance auf langsamen PCs es zu viele Kontras gibt.
Hallo ggg Ja das kann passieren Ich würde den erhalt der Funktion Begrüssen weil es ist die einzige Software die es bei GRBL unterstützt Man kann ja auf die schlechte Performance bei schwachen PC's hinweisen Aber es ware schade für jeden der einen Schnellen Rechner hat. Somit kann jeder selbst entscheiden ob er die Funktion nutzt.
Anbei SerialComCNC Version 0.9e2 Maintenance Release, nur interessant für Anweder der Video Funktion. Change Log V0.9e2 ----------------- Bug in der Video Skalierung behoben. http://www.serialcominstruments.com/
Na ist ja Cool Danke werde es gleich Testen Danke für die Rasche Unterstützung Darf ich fragen was für zukünftige Features geplant sind
boskap schrieb: > Darf ich fragen was für zukünftige Features geplant sind Suche mal hier im Thread nach "EasyJob" oder schau Dir das Video an. Das ist noch eine offene umfangreiche Baustelle. Video Link: https://www.youtube.com/watch?v=PAm-B0i21cY
Ja das hab ich schon gesehen Was ein Cooles aber auch sehr schwieriges Feature ware Nesting glaub ich heist das d.h. ich habe mehrere bauteile und sie warden so nah wie möglich zusammen geordnet um material zu sparen Aber ich glaube das muss vor der Gcode Erstellung passieren
Hallo Albert, leider bekomme ich das Programm unter Win10 nicht ans laufen. Er zeigt mir den COM-Port des Arduino einfach nicht an. Ich hab nur "COM" und "COM1" zur Auswahl.
Kryptoenergie schrieb: > leider bekomme ich das Programm unter Win10 nicht ans laufen. > Er zeigt mir den COM-Port des Arduino einfach nicht an. > Ich hab nur "COM" und "COM1" zur Auswahl. Ich kann bei mir nur mit Win7 Prof testen. Die Anzeige COM1 ist allerdings ein Hinweis darauf das Ports erkannt werden, bei Nichterkennung bleibt die Anzeige leer. Schau mal unter Computerverwaltung im Geräte-Manager nach, ob da Dein Arduino überhaupt erkannt und unter welchem Port er eingetragen ist, wenn nicht kann SerialComCNC auch nichts finden und es liegt nicht am Programm. Ich habe hier mit einigen Arduinos ein Problem wenn diese beim Hochfahren des PCs bereits angeschlossen sind. Diese Problem-Arduinos werden dabei nicht erkannt und ich muss explizit das USB Kabel aus/einstecken damit diese als neue Devices im Geräte-Manager erscheinen. Das ist allerdings kein Problem von SerialComCNC. China Arduinos haben zudem fast immer grottige USB Kabel beigelegt, die kommen immer sofort in die Tonne.
Hi, WinOS 10 ? - Da sind noch so viele Parts nicht richtig getestet und unterstützt, so dass man erst in 1 - 2 Jahren damit arbeiten könnte. Albert hat natürlich die richtigen Hinweise gegen, und ein Blick in den Gerätemanager und die Systemlogfiles hilft, ein Problem zu lokalisieren.
Anscheinend ist Kryptoenergie mit dem Problem nicht alleine: Beitrag "Win10 und bluetooth virtual com ports"
Hallo, Es ist so, dass alles funktioniert. Der bzw.die Arduino werden in der Gerätesteuerung korrekt erkannt. Com2 bzw. Com3. Alles was an Software verfügbar ist funktioniert. Nur SerialComCnc halt nicht. Das ist die einzige SW die den Port nicht kennt. Also schließe ich meine Hardware und Software aus. SerialComCnc ist nicht win10 tauglich.
ToM T. schrieb: > auf meinem oben erwähnten Tablet WIN8.1, nach Update WIN10, verhält es > sich genau umgekehrt. Also UniversalGcodeSender läuft NICHT und > SerialComCNC erkennt GRBL Bei manchen geht wohl doch mit Win10.
Die Software an sich funktioniert ja auch. Nur werden die COM-Ports der Sardinien nicht angezeigt. Somit komm ich damit leider nicht weiter. Unter Win7 hatte ich schon am Laufen. Allerdings musste ich aus Zeitgründen das etwas zurückstellen. Und mit dem neuen Rechner und Win10 kann ich nicht weitermachen.
Nur kurz zur Info, bei mir wird der COM Port von SerialComCNC unter WIN10 auch nicht erkannt. Er ist im Gerätemanager beim Anstecken des Arduinos vorhanden, bei mir als COM4, erscheint in SerialComCNC aber nur als "COM" (ohen Zahl). Beim Verbinden kommt "Serial Port connection error". Die anderen beiden COM Ports, die in meinem Falle im Gerätemanager angezeigt werden (COM3 und COM1), werden in SerialComCNC erkannt, erzeugen beim Verbinden aber - logischerweise - den Fehler "Falscher ComPort oder noch nicht erkannt. Veruchen Sie es nochmal".
Windows 10 und ComPort Könnten diejenigen bei denen Proble auftreten bitte mal testen, ob in SerialComInstruments bei Einstellung der passenden Port Nummer der ComPort connected? Der Hintergrund: Im Gegensatz zu SerialComCNC werden bei SerialComInstruments nicht die offenen Ports automatisch eingetragen, sondern der gewünschte ComPort muss explizit gewählt werden. Wenn das unter Win10 funktioniert, würde ich zum selben Verfahren in SerialComCNC wechseln und dies in der nächsten Version bereitstellen.
Ich benutze SerialComInstruments nicht, habe es aber mal schnell unter Win10 installiert. Mit Details der Bedienung bin ich nicht vertraut (und werde mich auch nicht vertraut machen), aber ich glaube ich bin auch so zu einem eindeutigen Ergebnis gekommen: Ich konnte den COM-Port des GRBL-Arduinos manuell auswählen und die Verbindung herstellen. Ich konnte außerdem mit "$$" bzw "$#" die entsprechenden Infos aus GRBL auslesen, die dann in SerialComInstruments angezeigt wurden. Kurz und gut: Die COM-Kommunikation scheint bei SerialComInstruments unter Win10 zu funktionieren.
zu win 10 Startet mal SerialComCnc als admin d.h. rechts auf das Icon klicken und "als Admin starten" auswählen wenn ihr den Punkt nicht habt Shift halten und Rechtsklick auf das Icon Wenn die Benutzerkontensteuerung aktiv ist so dürfen Programme nicht Direkt auf Hardware zugreifen
Hallo, Mit "Als Admin ausführen" hab ich es natürlich schon probiert. Bringt aber nichts. Wie John schon schrieb erscheint nur "COM" in der Auswahl. Damit kann man aber nicht connecten. Serialcominstruments hab ich nicht.
Die Problematik unter Win-10 hatte ich weiter oben ja schon beschrieben. Gruß, Manfred
@Manfred: Ja hab ich jetzt auch gelesen. Es scheint jedoch am Arduino-Treiber zu liegen. Ich habe jetzt mal einen alten Duemilanove ausgegraben, der einen FTDI Chip drauf hat. Dieser installiert sich als "echter" USB2Serial Wandler. Und damit funktioniert es auch unter WIN10 einwandfrei. Es funktioniert also nicht mit den UNO-Boards, die einen Atmega32u2 oder Atmega32u4 als USB2Serial drauf haben, mit dem von Arduino mitgelieferten Treiber.
Angehängte Dateien:
-
SerialComCNC_v0.9e3.png
12 KB
Anbei SerialComCNC Version 0.9e3 Testversion für Win10 Change Log V0.9e3 ----------------- Für Win10 das Häkchen vor Port entfernen (autom. Portsuche aus) und dann den gewünschten ComPort aus der Liste wählen. Bin ja mal gespannt ob das mit Win10 funktioniert. http://www.serialcominstruments.com/
Albert M. schrieb: > Bin ja mal gespannt ob das mit Win10 funktioniert. Ja, das hat funktioniert. Jetzt kann ich COM3 auswählen und connecten. Super, die kommenden dunklen Abende bei schlechtem Wetter sind gerettet..:-) Danke Albert für die schnelle Umsetzung.
Läuft auch bei mir!!! Danke Albert!!! Gruß, Manfred
Anbei SerialComCNC Version 0.9e4 Change Log V0.9e4 ----------------- Excellon Drill Datei Import - Scale Factor Eingabe-Box zugefügt (Std.Factor = 1,0) Z.B. für DipTrace Drill-File auf 0,01 (Division durch 100) einstellen. http://www.serialcominstruments.com/
hallo gibt es die Möglichkeit einen Button bei der Webcam einzubauen die das Bild um 90 grad nach links oder rechts dreht ? Danke Peter
boskap schrieb: > gibt es die Möglichkeit einen Button bei der Webcam einzubauen die das > Bild um 90 grad nach links oder rechts dreht ? Leider nicht. Manche WebCam Treiber ermöglichen 180 Grad, aber keine 90 Grad.
Hallo, steuert hier jemand seine Spindel mit PWM? Das soll sich ja so verhalten: *******Set Spdl (Spindel) Wählen Sie im Eingabefeld die gewünschte Umdrehungsgeschwindigkeit des Spindel-Motors in U/min und bestätigen diese mit dem "Set Spdl" Button. ******* Der Wert ist bei Programm Start mit 5000 vorbelegt. Das entspricht auch der Definition im G code. Hier würde dann "S5000" erwartet. Nun verhält sich das bei meinem Grbl v0.9j anders: Mit dem DSO gemessen (PWM on D11): - 0V ist "aus" - 500 ist ein Tastverhältniss von 1:1 - 999 ist 5V "volle Drehzahl" - Frequenz ist ca. 8kHz Demnach ist hier nicht die absolute Drehzahl sondern ein Wert zwischen 0 und 999 einzugeben. Kann das jemand bestätigen? Ist das ein Fehler in Grbl v0.9j? Gruß, ToM
ToM T. schrieb: > Demnach ist hier nicht die absolute Drehzahl sondern ein Wert zwischen 0 > und 999 einzugeben. Würde ja auch Sinn machen, da ein bestimmtes Tastverhältnis je nach Spindel-Motor eine andere Drehzahl ergibt. Ansonsten müsste das man ja für jeden Motor skalieren. Leider finde ich bei GRBL nichts weiter dokumentiert und so denke ich, dass Deine Erkenntnis stimmig ist. Ich messe das Morgen auch mal nach. Stellt sich dann nur noch die Frage, ob ich als Vorgabewert 0 oder 999 anbieten soll. Wahrscheinlich ist Full Speed, also 999 sinnig.
Hallo Albert, S5000 als Vorbelegung stört auch nicht, dann stellet sich ein konstantes 5V Signal ein. Das könnte man dann als Enable Signal interpretieren, für diejenigen, die kein PWM verwenden..... Verwirrend ist, dass es auf der GRBL Seite keine Definition gibt.... Ich habe auch schon gesucht..... ToM
in config.h ist max. Drehrahl definiert:
#define SPINDLE_MAX_RPM 1000.0
#define SPINDLE_MIN_RPM 0.0.
und in spindle_control.c:
...
if ( rpm > SPINDLE_RPM_RANGE ) { rpm = SPINDLE_RPM_RANGE; } // Prevent
uint8 overflow
....
Also bei Bedarf muß max. Drehzahl in config.h angepaßt werden.
> Also bei Bedarf muß max. Drehzahl in config.h angepaßt werden.
oder im Frontend anhand der Motordrehzahl runter skalieren.
Wegen eines aktuellen Anwendungsfalls überlege ich gerade eine Modifikation der Video Funktion von SerialComCNC. Problem: Werkstück soll nachträglich an bestimmten Stellen gebohrt werden, die Koordinaten dafür sind aber nicht bekannt und lassen sich wegen der Form des Werkstückes auch nur umständlich genau ermitteln. Event. Lösung: Mit der Video-Funktion lässt sich ja bereits mittels WebCam der XY-Nullpunkt festlegen. Verfahre ich jetzt die Fräse/WebCam über alle vorgesehenen Bohrstellen und speichere jeweils die Koordinaten, lassen sich die Bohrungen danach schnell und genau automatisch durchführen. Meine Frage: Ist so eine Modifikation von Interesse? Nur für meinen einmaligen Anwendungsfall will ich da ansonsten nichts zusätzlich programmieren.
Guten Tag ich wollte einfach nur mal Dank sagen für die viele Arbeit die in diesem Projekt steckt. Habe seit eben endlich meine MF70 damit zum laufen bekommen... Eine Frage hab ich allerdings alle Achsen bei mir sind vertauscht also die Richtung bei Z + fährt Z ins Minus und umgekehrt bei den anderen beiden Achsen das selbe. Liegts an der Verkabelung oder kann man die Achsen im Programm invertieren bzw wäre das ja eventuell noch eine Idee die man mit einbauen könnte. Liebe Grüße Sebastian G.
Angehängte Dateien:
-
Direction_Table.png
130 KB
Sebastian G. schrieb: > Eine Frage hab ich allerdings alle Achsen bei mir sind vertauscht also > die Richtung bei Z + fährt Z ins Minus und umgekehrt bei den anderen > beiden Achsen das selbe. Alle GRBL Einstellungungen findest Du hier: https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9) Die siehst Du einfach durch Klick auf den $$ Button. Es werden dann alle GRBL Einstellungen angezeigt. Änderungen erfolgen durch Eingabe in das untere manuelle G-Code Eingabefeld. Für die Richtungsumkehr aller Achsen ist $3 zuständig. Schau nun in obige angefügte Tabelle (aus dem obigen Link): Beispiele: Keine Richtungsumkehr: $3=0 Nur X umkehren: $3=1 Nur Y umkehren: $3=2 Nur X und Z umkehren: $3=5 Alle Achsen umkehren: $3=7 (ist bei Dir einzustellen) usw. Das Gewünschte gibst Du unten in das Eingabefeld ein (z.B. $3=7) und drückst die PC Return-Taste. Jetzt noch mal Button $$ klicken um zu sehen ob die Änderung korrekt übernommen wurde. Die Änderungen werden permanent im Mikrocontroller gespeichert. Auf diese Weise kannst Du alle aufgelisteten GRBL Einstellungen verändern. Häufig gebraucht für die Grundeinstellung werden: $1 - steht bei mir auf 255 $3 - siehe oben $100 bis 102 - step/mm, abhängig von Steps/Umdrehung der Motoren und der Einstellung des Microstepping auf dem Treiberboard. Standardwerte wären z.B. 200, 400, 800, 1600. Durch leichte Variation dieser Werte kannst Du die Achsen einzeln kalibrieren. $110 bis 112 - max rate in mm/min, max.Vorschubgeschwindigkeit(G0) $120 bis 122 - accel, mm/sec^2, Bescheunigung der Achsen (zuerst mal nicht ändern) Es ist sinvoll sich das über GRBL durchzulesen: https://github.com/grbl/grbl/wiki
Angehängte Dateien:
-
VideoDrillPoints1.png
200 KB -
VideoDrillPoints2.png
190 KB
Anbei SerialComCNC Version 0.9f
Change Log V0.9f
-----------------
Video Drill Funktion zugefügt.
Damit können an durch Video bestimmten Positionen Bohrungen gemacht
werden. Die Anzahl der möglichen Bohrungen ist beliebig.
Vorgehensweise (noch nicht in der Hilfe dokumentiert):
1. Video einschalten. Es wird vorausgesetz das eine
Video Offset Kalibrierung bereits erfolgt ist.
2. Button "SP" klicken, Parameter einstellen, mit Exit verlassen.
3. Fadenkreuz auf gewünschten Werkstük-Nullpunkt verfahren.
4. "Setze XYZ Null" klicken
5. Auf die gewünschte Bohrposition verfahren.
6. Button "SP" klicken, es öffnet sich das Video Drill Fenster.
Darin wird der erzeugte G-Code (editierbar) angezeigt.
7. Für weitere Bohrungen Button "Next Video Point" klicken
und mit 5. weitermachen.
8. Mit Button "Ready / Process Data" die Eingaben abschliessen.
9. Der erzeugte G-Code wird nun im Haupt-Fenster angezeigt.
Jetzt mit Button "*" auf den Video-Nullpunkt verfahren und
Button "Use" (Offset) klicken. Die Frässpindel fährt nun auf den
Werkzeug-Nullpunkt. Dann Z-Achse auf Werkstück-Null fahren.
"Setze XYZ Null" klicken und Fräsen starten.
http://www.serialcominstruments.com/
Hallo, ich wollte die neue Funktion direkt mal ausprobieren. Allerdings bekomme ich kein Webcambild. Ich bekomme nur eine Fehlermeldung "No Webcam found". Was mache ich falsch? Die Webcam ist zwar schon etwas älter, funktioniert jedoch mit allen Programmen. Bei Klick auf Start bekomme ich noch eine Auswahl angezeigt, jedoch nach Auswahl der USB Camera die o.g. Fehlermeldung. Gruß Manuel
Kryptoenergie schrieb: > Ich bekomme nur eine Fehlermeldung "No Webcam found". > Was mache ich falsch? Dazu gab es oben schein einige Diskussionen: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" boskap (Gast) schrieb dazu: Das Webcam Problem ist gelöst es funktioniert sofort wenn ich SerialComCNC mit rechtsklick und "als Administrator starten" starte Bei mir kann es beim ersten Aktivieren schon mal bis zu 10s dauern bis die WebCam erkannt wird. Danach ist sie immer sofort da. Zur WebCam Problematik kann ich ansonsten keine weitere Hilfestellung geben (siehe Links). Sorry wenn es bei Dir nicht funktionieren sollte. Ich wollte die WebCam Funktion schon mal aus diesen Gründen ganz aus der Software rausnehmen, auf Wunsch ist sie aber noch vorerst drin.
Hallo Albert, danke für die Info. Hatte nicht erst den gesamten Thread gelesen. Ich habe diese Funktion bis jetzt auch nicht vermisst, aber das mit den Bohrlöchern klang halt interessant. Ich habe es jetzt mal an einem zweiten Rechner mit einer anderen Cam (Laptop mit eingebauter USB Cam) ausprobiert. Da funktioniert es mit den Adminrechten. Nur so eine eingebaute ist halt schlecht zum Ausrichten.:-) Ich werde es an meinem neuen Bastelrechner mit einer anderen Cam nochmal probieren. Irgendwie wird das wohl schon klappen..:-) Das mit den Bohrlöchern reizt mich ja doch, da ich dies als sinnvoll erachte. Gruß Manuel
Hallo Albert, das mit der Cam habe ich nun hinbekommen. Lag tatsächlich an der Web-Cam und dem Treiber. Eine Frage habe ich derzeit noch: Warum ist Fenster maximieren deaktiviert? Wenn ich es manuell vergößer funktioniert die Skalierung doch ordentlich. Hat das einen besonderen Grund? Oder habe ich oben wieder was nicht gelesen...:-)
Kryptoenergie schrieb: > Warum ist Fenster maximieren deaktiviert? > Wenn ich es manuell vergößer funktioniert die Skalierung doch > ordentlich. > Hat das einen besonderen Grund? > Oder habe ich oben wieder was nicht gelesen...:-) Hm, dazu gab es mal das hier: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Seit dem fehlt die Maximierung des Fensters und ich habe vergessen mich weiter darum zu kümmern :)
Danke für die Info. Ich glaub ich muss es dann doch mal ein paar Monate zurücklegen. :) Mein Problem ist halt, dass ich immer mit dem kleinen Fenster starte und dann alle erst wieder auf Größe bringen muss. Die Einstellungen werden nicht gespeichert. Gibt es denn Hoffnung für die Zukunft?
Hallo Albert, ich hab das Problem nun für mich erstmal gelöst. Ich habe die SerialComCnc.ini manuell angepasst. Jetzt startet das Programm praktisch im Vollbildmodus. :-) Es gibt immer einen Weg, man muss ihn nur finden. Gruß Manuel
Ich hatte eben eine Konversation mit dem Entwickler von "NC Corrector": http://nc-corrector.inf.ua/index_EN.htm Ich habe seine schriftliche Erlaubnis bekommen seine äusserst hilfreiche Software in das Setup von SerialComCNC einzubinden, beizufügen oder aus SerialComCNC heraus auszuführen. Dazu habe ich folgende Überlegung: Das Einbinden in das Setup wäre zwar die einfachste Möglichkeit, würde aber die Distributable um über das Doppelte auf über 10 MB aufblähen. Daher denke ich, dass jeder Anwender selber entscheiden sollte, ob er NC Corrector überhaupt benutzen will und die Software dann selbst von der obigen Herstellerseite downloaden und installieren. Entsprechende Konfigurations- und Aufruf-Möglichkeiten für den installierten NC Corrector werden dann in SerialComCNC angeboten.
Da bin ich ja mal gespannt drauf sieht schick aus ;) Achja hatte mit den Einstellungen rumgespielt weil es mit $3=7 nicht funktioniert hatte... alle Achsen hatten sich umgekehrt nur Z nicht... Mit $3=1 ging es schließlich obwohl nicht nur die X Achse Falsch war. Irgendwie skuriel aber nun ja nun funktioniert alles. Danke nochmal
Angehängte Dateien:
-
Unbenannt.jpg
22 KB
Hallo habe mal eine Frage zur Pin Belegung . Verwende Arduino Nano da ist bei SerialComCnc die Pin D2 X Step -- D3 X Step -- D4 Z Step -- D5 X DIR -- D6 Y DIR -- D7 Z DIR – belegt . Habe mir ein 3dv4 cnc-schild v4 gekauft da sind die Pin Belegung genau anders herum . Pin D2 X DIR -- D3 X DIR -- D4 Z DIR-- D5 X Step -- D6 Y Step -- D7 Z Step – belegt . Wie Kann man die PIN Belegung bei SerialComCnc ändern . Bin für jede Hilfe Dankbar
Hallo Carlos, die Pinbelegung für die Ansteuerung Stepperplatinen kommt nicht aus dem SerialCNC heraus, sondern wird durch das geladene GRBL-Programm auf dem Arduino vorgegeben. Wenn du also dort was anpassen muss, suche bitte in der Beschreibung für die (nicht von Albert programmierte) GRBL-Software. Als Hinweis, kann ich deich schonmal auf die cpu_map.h Datei aus der GRBL-Bibliothek verweisen (siehe Anhang). das anpassen solltest du selber machen (können), da sonst alles weitere nicht zielführend ist. Leider funzt die Code-Funktion bei mir iwie net...deswegen im Anhang die entsprechende (unangepasste!!!) Datei. Diese musst du in deiner Arduino Lib anpassen, und dann neu kompilieren und auf den Arduino laden (die gesamte GRBL-Lib Gruß EGS
Erst einmal vielen Dank für das Programm. Das Folgende soll kein Argument gegen den Videomodus sein (den ich gerne weiter im Programm hätte), sondern eine Information für Webcamkäufer. Es wäre nützlich, wenn auch andere Anwender ihre Erfahrung mit den verschiedenen Webcam-Typen mitteilen würden. NeuerGast schrieb: > Webcam ist die "Hama Black Tube" > Treiber ist der "Microsoft WDM Image Capture (Win32)" > Das Programm meint aber keine Webcam zu finden. Das gleiche Problem tritt bei der "Hama Evolution Zero" auf: Starte ich SerialComCNC als einfacher Benutzer, wird keine Webcam gefunden. Starte ich das Programm als Administrator und versuche, die Webcam zu starten, kommt es zu einer Endlosschleife von Popup-Fenstern mit der Nachricht "Format der Zwischenablage wird nicht unterstützt". Das Programm ist dann nicht mehr bedienbar und kann nur über den Taskmanager abgebrochen werden. Scheint ein grundsätzliches Problem mit dem von Hama verwendeten Treiber zu sein. Die mit der Webcam mitgelieferten Programme laufen übrigens einwandfrei. SerialComCNC V0.9f Webcam Hama Evolution Zero Treiber: Microsoft WDM Image Capture (WIN32) V 6.1.7601.17514 Mit freundlichen Grüssen Heinz
Hallo Albert Danke für das das super Programm. Ich habe die Version v0.9f auf meinem ASUS Laptop mit Window7(64Bit) installiert. Auf dem ArduinoUNO 16 MHz (kein Clone) läuft grbl_v0_9i_atmega328p_16mhz_115200.hex. Die manuelle Steuerung funktioniert bei allen 3 Achsen. Was jedoch fehlt ist die Positionsrückmeldung, die Anzeige zeigt 3x -----. Wenn ich mit dem Serial Monitor (Device Monitoring Studio) den Datenverkehr der USB-Schnittstelle beobachte, sehe ich das alle 100-200ms die Fragezeichen gesendet werden und der Arduino diese Antwort schickt: <Idle,MPos:0.000,-10.000,30.000,WPos:0.000,-10.000,30.000> Beim Abarbeiten einer G-Code Datei bleibt das Programm nach dem ersten send-OK stehen und wartet wahrscheinlich auf eine Antwort. Kennt jemand dieses Verhalten und was kann man dagegen tun?
Hallo Helmut, genau das Problem habe ich auch, siehe Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Ich bastel mir nun meinen eigenen GRBL-Sender Gruß Sven
Nachtrag: als Admin eingelogt funktioniert es, als User eingelogt aber mit Admin-Berechtigung gestartet geht es auch nicht
Hallo @Albert: Danke für das geniale Programm! Hat mich motiviert meine low-Budget-Fräse endlich fertigzustellen. Alles läuft eigentlich wunderbar, warte im Moment nur auf neue Arduino Nano's, da ich die Fräse momentan provisorisch mit einem Uno betreibe. Gibt es eigentlich Neuigkeiten zur Easy-Job Funktion? Schau fast täglich nach, ob es ein Update gibt;) @Helmut: Ja dieses Problem kenne ich! Ist bei meinen beiden alten Nano's (clones) auch plötzlich passiert. Der manuelle Modus hatte nach wie vor funktioniert und ansonsten verhielt es sich genau wie du beschrieben hast. Allerdings ließ sich die Grbl-Software oder andere Programme nicht mehr auf die nano's flashen. Da ist irgendwas an der Hardware kaputt gegangen. Meine Vermutung ist, es liegt an meinem Relais, welches 230V schaltet und nicht mit einem Optokoppler galvanisch getrennt ist. Vielleicht ist es bei dir ja das gleiche Problem. Neue nano's sind bestellt ebenso wie ein besseres Relais... Schöne Grüße Philipp
Helmut schrieb: > <Idle,MPos:0.000,-10.000,30.000,WPos:0.000,-10.000,30.000> > Beim Abarbeiten einer G-Code Datei bleibt das Programm nach dem ersten > send-OK stehen und wartet wahrscheinlich auf eine Antwort. Kennt jemand > dieses Verhalten und was kann man dagegen tun? Auf welche Sprache ist dein System eingestellt? Eventuell zurückstellen aud DE und die Zahlenformat.
Tany schrieb: > Helmut schrieb: >> <Idle,MPos:0.000,-10.000,30.000,WPos:0.000,-10.000,30.000> >> Beim Abarbeiten einer G-Code Datei bleibt das Programm nach dem ersten >> send-OK stehen und wartet wahrscheinlich auf eine Antwort. Kennt jemand >> dieses Verhalten und was kann man dagegen tun? > > Auf welche Sprache ist dein System eingestellt? > Eventuell zurückstellen aud DE und die Zahlenformat. Hat keine Auswirkung die Systemsprache, da die Software direkt id Daten aus dem (virtuellen) COM-Port verarbeitet. Es ist, wie er schon feststellte ein Problem der Nutzeranmeldung, die den zugriff auf den Port einschränkt. Es ist auch ein unterschied ober als Admin angemeldet ist oder als Admin ausführt. Wurde aber bereits häufiger erläutert in diesem Thread...?
EGS schrieb: > Es ist, wie er schon feststellte ein Problem der Nutzeranmeldung, die > den zugriff auf den Port einschränkt. hm...Ich hab grad mit stinknormalem User getestet, funktioniert doch einwandfrei. (win7x64)
@Helmut Bei mir ist es übrigens auch ein ASUS Notebook (X7BJ - N73JF Series) mit Win7 64Bit...
Danke Tany Dein Tipp war richtig. Es lag am Dezimaltrennzeichen in der Einstellung "Region und Sprache" unter "Weitere Einstellungen". In Deutschlang wird ein Komma als Dezimaltrennzeichen verwendet und in der Schweiz einen Punkt. Der Fehler liegt also im Programm und nicht in den Einstellungen, Zugriffsrechten, ASUS Laptop, Window7(32/64Bit)oder Arduino Uno/Nano (Original/Clone). Das Programme SerialComCNC sollte sich diese Informationen von dort zur Weiterverwendung holen. Dasselbe Problem hatte ich schon mal mit Excel. Albert: Kann man das anpassen? Danke Grüsse Helmut
Helmut schrieb: > Dein Tipp war richtig. Es lag am Dezimaltrennzeichen in der Einstellung > "Region und Sprache" Intern werden eigentlich alle Kommas zu Punkten als Dezimaltrennzeichen konvertiert. Irgendwo muss ich wohl was übersehen haben. Helmut schrieb: > Albert: Kann man das anpassen? Danke Werde ich für die nächste, spätestens übernächste Version korrigieren.
Heinz K. schrieb: > Es wäre nützlich, wenn auch andere Anwender ihre Erfahrung mit den > verschiedenen Webcam-Typen mitteilen würden. Will wirklich keiner seine Erfahrungen teilen? :'( Nochmals vielen Dank an Albert und einen schönen 1. Advent! Heinz
Hallo Albert, ich habe eine kleine Proxxon-Fräse umgebaut um ein bisserl mit CNC-Maschinen zu üben. Der Umbau ist dort http://www.herberts-n-projekt.de/basteleien-1/cnc-... beschrieben. Im Arduino werkelt die grbl v0.9 aktuellste Version. Beim Einsatz von serialcomcnc (aktuellste Version) kommt über USB (als Com6) eine Verbindung zum Arduino zustande, jedoch flattern dann die TX/RX-LEDs auf dem Arduino nur noch und nach ca. 30-60 Sekunden kommt der Abbruch wegen schweren Kommunikationsfehlern. Wenn ich den Universal-G-Code-Sender https://github.com/winder/Universal-G-Code-Sender einsetze, kann ich die Maschine steuern. Die Einstellungen für den Port Com6 sind identisch. Es gibt keine Kommunikationsabbrüche. Ich kann auch mit dem eingebauten Kommunikationsinterface ähnlich einem Telnet-Cleint mit dem Arduino kommunizieren. Gibt es bei seriacomcnc unter Win10 etwas besonderes zu beachten? Danke für Info Gruss Thomas
Hi, super Programm! Aber nachdem ich meine grbl Software auf v1.0c aktualisiert habe geht irgendwie nix.. Ferhalten ist wie bei Helmut. Gruß Paul
Paul schrieb: > grbl Software auf v1.0c Ich glaube, Du verwechselst grbl mit GrblHoming. grbl gibt es laut https://github.com/grbl/grbl nur bis Version v0.9j vom 2015-09-30. MfG Heinz
Heinz K. schrieb: > Ich glaube, Du verwechselst grbl mit GrblHoming. > grbl gibt es laut https://github.com/grbl/grbl nur bis Version v0.9j vom > 2015-09-30. Nö, v1.0c vom Nov 10 2015 im edge-Zweig... Gruß Paul
Sorry, hatte nur im Master branch geschaut und nicht bei den beta-Versionen. Viel Erfolg bei der Fehlersuche! MfG Heinz
Angehängte Dateien:
-
Ablaufdatumg.png
4,9 KB
Hallo Albert, wie gehabt ist SerialCNC eine super Software und ich freue mich schon auf die neuste Version. Leider hat aber meine Version von SerialCNC anscheinend ein MDH (siehe Bild oben). Hast du da was implementiert, hatte das bei keiner deiner vorherigen Versionen. Die aktuelle Version ist auch die aktuellste von hier (0.9f). Gruß EGS
Hallo Albert, zu allererst muss ich mich natürlich den bisherigen Beiträgen anschließen, es ist in jedem Fall eine große Leistung ein bestehendes Problem (für sich) selbst zu lösen, es dann aber auch mit anderen zu teilen und nicht eifersüchtig unter Verschluss zu halten ist nochmal was ganz anderes. Respekt! Ganz besonders der Support, den du hier bietest, und da sind wir auch schon da, worauf ich hinauswollte: da ich leider komplett neu mit der Thematik angefangen habe und sich meine Programmierkenntnisse darauf beschränken, was man heutzutage so in der Schule lernt (Java Grundlagen anhand der BlueJ Plattform bei einer Lehrkraft, die... naja - d.h. hängengeblieben ist praktisch nix), seht mal alle bitte darüber hinweg, auf welchem Niveau ich hier alles von mir gebe (bzw. ich bin über jede Zurechtweisung Dankbar, egal in welchem Ton). Meine Frage also: es ist immer von Treiberboards die Rede, mir gefällt der Gedanke an eine Realisierung mit drei einzelnen H-Brücken allerdings besser (bis jetzt; dass die Lösung allerdings nicht besonders elegant ist weis ich bereits) Kommt die Software also auch mit drei einzelnen L298N Treibern (angeschlossen über je vier Pins) klar, ist diese Frage trivial, weil es keinen Unterschied darstellt, oder entstehen dabei größere Probleme?
Hallo lieber Autor (Albert) SerialCom ist bisher das beste Programm für CnC Eigenbauer "die nicht erst eine Software Lehrgang machen möchten" welches ich bisher gesehen habe. Einfach, schlicht und gut zu verstehen! Nun meine Frage hast Du dich mal mit einem Cam Programm befasst. Die Cam Programme die mir bisher sind , sind der Horror. Deine Zeit ist sicher begrenzt aber ein neues Projekt ist immer eine neue Herausforderung. Gruß R.
Rüdiger H. schrieb: > Nun meine Frage hast Du dich mal mit einem Cam Programm befasst. > Die Cam Programme die mir bisher sind , sind der Horror. Schonmal Estlcam probiert? Ich bin damit bisher eigentlich ganz zufrieden. http://www.estlcam.de/
chris schrieb: > > Schonmal Estlcam probiert? > Ich bin damit bisher eigentlich ganz zufrieden. > Ja hab ich! Es ist mir einfach zu Radien überlastet "ja das ist die Werkzeug korektur", jeder rechte Winkel wird als Radius gefahren und dem nach sind selbst kleine Programme sehr unübersichtlich. Da schreib ich lieber selbst den Gcode.
Hallo Albert, da hast du ein Super Programm mit vielen Funktionen auf die Beine gestellt. Vielen Dank für die Zurverfügungstellung!! Ich habe gerade die Drehzahlsteuerung meiner Spindel auf Analogeingang umgestellt und festgestellt, dass der mögliche Spannungshub am Ausgang des Arduino Nano V3 mit in SerialComCNC eingestellten Werten von 0..1000 ausgereizt ist. Damit kann man sicher leben, aber einfacher wäre es in meinen Augen, wenn man die gewünschte Drehzahl in der Box direkt eingeben könnte. Wenn ich mich nicht täusche werden z.B. von Estlcam ebenfalls Drehzahlwerte in G-Code angegeben und die würden von SerialComCNC ebenfalls unskaliert an den Arduino übergeben. Abhilfe würde hier eine Möglichkeit zur Skalierung im Programm bieten. Lässt sich so eine Funktion in einer der nächsten Versionen einbauen? Sicher :-), aber kannst du dir auch vorstellen, das umzusetzen? Oder habe ich einfach die entsprechende, schon vorhandene Möglichkeit übersehen? Harry
Hallo Albert, noch eine Frage bzw. eine Anmerkung zur Realisierung. Du hast zum manuellen Verfahren das JogDial eingebaut, das sich auf meinem alten Gurkenmonitor aber standhaft der Darstellung (und damit der Nutzung) entzieht, weil der Monitor "nur" eine Auflösung von 1200x1024 hat. Ich konnte das Dial noch nicht ausprobieren, denke aber, dessen Funktion soweit verstanden zu haben, dass das dargestellte Rad nicht gedreht sondern nur aus der Mittellage ausgelenkt wird, um die Bewegung der Achsen zu initiieren. Eine identische Funktion ließe sich mit einem Slider ebenfalls realisieren, der sich auf dem Bildschirm deutlich weniger breit machen würde und somit die Nutzung dieser an sich tollen Funktion auch auf kleineren Bilschirmen ermöglichen würde. Hier böte sich dann die Darstellung von drei Slidern an um alle Achsen direkt bewegen zu können. Das Ganze macht natürlich nur Sinn, wenn das Dial bzw. die Slider nicht nur eine andere Bedienungsmöglichkeit der per Mausclick schon in der Standarddarstellung möglichen Bewegung darstellt, sondern eine kontinuierliche Bewegung bewirkt, solange das Dial aus der Nullage ausgelenkt ist. Nur so eine Idee... :-) Harry
Tippfehler: Der Monitor hat natürlich 1280x1024 Pixel. Und inzwischen habe ich das Dial auch mal im Trockenen ausprobiert. Alles wie angenommen, die Slidervariante könnte also wirkllich zum Tragen kommen... :-)
Hallo zusammen, erstmal großes Lob und Dank @Albert! Super Programm, easy und komplex zugleich - einfach perfekt! Ich hatte zwar anfangs ein paar Probleme (v.a. Hardware-technisch), aber nachdem ich die vielen hilfreichen Beiträge (bzgl. EMV Störungen und so) hier durchgelesen hatte, war alles im Lot ... Eine Frage hätte ich allerdings noch in die Runde: worauf bezieht sich die Achsendefinition in SerialComCNC genau? y+ ist Spindel hoch fahren, das ist klar. Aber bezieht sich z.B. x+ auf die Bewegung des Frästisches (nach rechts) oder auf die Bewegung des Fräskopfes auf dem Werkstück? (in dem Fall würde der Tisch nach links fahren). Ich wünsch euch noch einen schönen Abend golgi
sorry - ich Hirsch meinte natürlich Z+ Spindel = hochfahren ...
Moin, moin, jetzt hat es mich auch erwischt: SCC (in der aktuellen Version) meint, dass das Ablaufdatum erreicht sei und verweigert die Mitarbeit. Blöd, wenn man gerade in einem Nacht-Projekt stecken bleibt. Gut ist aber, dass man merkt, wie wichtig es geworden ist .... ;) ;) ;) Nur das Beste und die Bitte um einen schnelle Lösung, Tillmann
golgi schrieb: > y+ ist Spindel hoch fahren, das ist klar. Aber bezieht sich z.B. x+ auf > die Bewegung des Frästisches (nach rechts) oder auf die Bewegung des > Fräskopfes auf dem Werkstück? (in dem Fall würde der Tisch nach links > fahren). Hallo Golgi, das mit Z hast du ja schon selbst gemerkt. Ich interpretiere deine Frage so, dass du eine Ständer-Fräse hast (Tisch bewegt sich unter der statischen Spindel hin und her). In diesem Fall bedeutet X+ dass sich der Tisch nach links bewegen muss. Für Y+ muss der Tisch nach vorne wandern. Harry
Wenn ich schon hier bin... Weiß einer von euch, ob Albert noch in dieses Forum reinschaut? Die letzten paar Seiten wurden ohne ihn gefüllt... Danke! Harry
Hallo Harry, besten Dank für die Aufklärung. Ist ne Vertikalfräse (Proxxon MF70 Käsefräse) - sorry, das hatte ich vergessen zu erwähnen ... Bei mir ist übrigens jetzt auch das "Ablaufdatum" erreicht, was auch immer das bedeuten soll. Ich musste eben das Programm neu installieren, was auf die Dauer natürlich alles andere als optimal wäre. Um Abhilfe wäre auch ich sehr dankbar. Ansonsten ist das wirklich ein höchst lobens- und bewundernswertes Software-Projekt. Vielen Dank nochmal Albert! Viele Grüße und allen hier ein angenehmes 4. Adventswochenende, golgi
Harry schrieb: > Weiß einer von euch, ob Albert noch in dieses Forum reinschaut? Vielleicht gibt es für uns was schönes zu Weihnachten von ihm ? Und wie können wir uns für diese geniale Software bedanken ? Vorschläge willkommen.
Hallo golgi, ja, genau, Vertikalfräse war der Ausdruck :-) "Ablaufdatum" kenne ich bisher nicht. Eventuell gibt's ne neue Version? ... Nachschau ... Nö, eher nicht. Harry
Angehängte Dateien:
-
Isolationsfraesen_1.png
15 KB -
Isolationsfraesen_2.png
17 KB -
Isolationsfraesen_3.png
15 KB -
2015-12-19_17_51_53-HPGL_Converter.png
35 KB -
20151219_172102.jpg
220 KB
Hallo, zuerst mal vielen Dank für dein Super Programm Albert. Ich sammle gerade meine ersten Erfahrungen mit meiner CNC Fräse. Als Controller benutze ich ein Arduino Nano mit GRBL und SerialComCNC. Heute habe ich zum ersten Mal versucht eine Platine zu fräsen und anschließend zu bohren. Das Fräßergebnis sieht für den 1. Versuch mit einer Gravierstichel mit 0,1 mm und 30° für mein Empfinden sehr gut aus :) Ich benutze Target 3001 und habe zum Isolationsfräsen eine HPGL Datei erstellt. Meine Einstellungen zum Erzeugen der Datei und die Einstellungen in SerialComCNC sind im Anhang. Allerdings bekomme ich es nicht hin eine Bohrdatei zu erstellen, welche auch von der Platinenunterseite zum Bohren ist, damit ich die zuvor gefräste Platine nicht wenden muss. Zum Bohren habe ich die Bohrausgabe von Target versucht zu benutzen. Als Ausgabedatei habe ich natürlich eine Excellon Datei erstellt. Allerdings stimmen bei keiner Einstellung die Koordinaten der Bohrlöcher, wenn ich diese von der Platinenunterseite versuche zu bohren. Egal ob ich gedreht oder gespiegelt auswähle. Hat schon jemand erfolgreich eine Platine gefräst und von der Platinenunterseite gebohrt mit Target? Wie ist dabei vorzugehen?
Zum Isolationsfräsen: Ich benutze auch Target und habe schon viele Platinen gefräst, allerdings mit Win-PCNC, sollte aber mit SerialCom ähnlich gehen. Zunächst ist es von Vorteil, bei der Layouterstellung alle Löcher mit dem gleichen Durchmesser zu versehen, dann hast du in der späteren HPGL-Datei nur 2-Werkzeuge.(Fräser + Bohrer) Für eine einseitige Platine wählst du in Target Kupfer-unten mit bohren. Ob das Bohren am Anfang oder Ende geschieht ist egal. Zum Fräsen der Konturen wählst du dann in SerialCom zunächst nur das Werkzeug für den Isolationsfräser. Nach dem Fräsen der Kontur bleibt die gefräste Platine eingespannt. Nun wählst du das Werkzeug für den Isolationsfräser ab, und aktivierst das Werkzeug für den Bohrer. Den Bohrer in der Z-Achse neu einrichten, X+Y sind ja noch aktiv vom Fräsen. Jetzt den Job erneut ausführen, es wird nur gebohrt, fertig. Gruß, Manfred
Ach ja, als Ausgabeformat in Target kannst du auch DIN-ISO wählen, dann bekommst du eine G-Code Datei, wahrscheinlich genauer, weil der Teilungsfaktor 1/40 von HPGL entfällt. Manfred
Danke für die schnelle Antwort. Auf die Idee bin ich auch schon gekommen. Allerdings wird bei SerialComCNC nur bei einem excellon File der Werkzeugwechsel ermöglicht. Oft sind es ja auch wirklich mehrere verschiedene Durchmesser die man benötigt. @Albert Das sollte doch nicht schwer sein eine Option für hpgl-Dateien einzufügen, welche einen Werkzeugwechsel ermöglicht. Natürlich bräcuhte man dann noch eine 2. Bohrlochtiefe für Löcher und noch eine 3. Tiefe um den Platinenumriss zu fräßen.
Das verstehe ich jetzt nicht ganz. Du kannst doch als Ausgabeformat auch excelon wählen, dann brauchst du nur die Jobs einzeln zu fahren, natürlich muß jedes Werkzeug eingerichtet werden. In Target kannst du doch auch die Eintauchtiefe wählen.
@Albert: Mir ist gerade noch ein "Fehler" aufgefallen. Gibt man bei einer hpgl Datei eine negative Bohrlichtiefe an, dann wird ein G-Code mit einem doppelten negativen Wert erzeugt. hier ein Beispiel: F200 G01 Z--3.00 Dies führt natürlich zu einem Fehler. Bei einer excellon-Datei wird es allerdings "richtig" behandelt und es ergibt sich dabei kein doppelter negativer Wert. Zudem hätte ich noch ein paar weitere Frage. Z.B. wie der Werkzeugwechsel mit einer Probe nun genau funktioniert. Soweit ich das verstanden habe, wird bei einem Werkzeugwechsel der aktuelle G-Code angehalten und ich kann die Achsen beliebig verfahren. Nun wechsle ich das Werkzeug. Danach mache ich mit meinem Werkzeuglängensensor ein Probing auf der Platine. Muss ich danach noch "UP" drücken oder ist dies nicht nötig? Ist ja eigentlich nicht nötig. Anschließend lasse ich das Hauptprogramm weiterlaufen ? Mit welcher Taste kann ich die Z-Achse hoch und runterfahren. Die Pfeile sind ja für die X-und Y-Achse.
Die excellon-Datei, welche vom Isolationsfräsen kommt, kann von SerialComCNC nicht interpretiert werden. Nur die excellon-Dateien aus der Bohrausgabe werden richtig zum G-Code umgesetzt..
Ein Ansatz wäre eventuell die Ausgabe in DIN-ISO. (mit bohren + Umriss) Die einzelnen Werkzeuge werden ja nacheinander abgearbeitet. Die G-Code Datei öffnen und die Jobs der Werkzeuge in eigene Dateien speichern. (mit Texteditor) Werkstück(Platine) eingespannt lassen (der XY-Nullpunkt wird ja nicht verändert) Z-Parameter für das entsprechende Werkzeug einrichten + die "Werkzeugdatei" abarbeiten.
Das o.g. kann auch für HPGL-Dateien angewendet werden. Die Einzelnen Werkzeuge mit ihren Parametern stehen in einer "Projekt".txt Datei Einfach nach den einzelnen Werkzeugen in der Ausgabedatei suchen. (SP.. HPGL, T.. DDIN-ISO u.s.w.)
Ich habe mir nun mal den erzeugten G-Code von Target angeschaut. Der sieht sehr brauchbar aus. Der Werkzeugwechsel sollte damit auch möglich sein. das "T" Kommando sollte von SerialComCNC erkannt werden. Allerdings irritiert mich ein wenig das G71 Kommando, welches von GRBL nicht unterstützt wird. Im Internet konnte ich dazu nur wenig finden. Das G71 Kommando wird im englischen mit "rough turning cycle" bezeichnet. Allerdings verstehe ich nicht ganz, was dieses G-Kommando ohne Zusatz in diesem Code zu suchen hat. Macht das G71 Kommando nicht eher auch beim Drehen als beim fräsen Sinn?
Oh man, das G71 Kommando scheint auch das alte Kommando für G21 zu sein... Also doch einfach löschen, da G21 ja schon enthalten ist?
@Albert: Ich habe mir gerade nochmals Gedanken über den Werkzeugwechsel gemacht. Aus meiner Sicht müsste der im optimalen Fall so aussehen. 1. Zuerst muss die Stelle, an welcher der Werkezuglängensensor fest montiert ist, bestimmt werden und in einer .ini oder ähnlichem gespeichert werden. 2. Wenn es in einem G-Code zu einem Werkzeugwechsel kommt muss die Fräse zuerst ein Probing mit dem noch eingespannten altem Fräser/Bohrer beim Werkzeuglängensensor gemacht werden. 3. Die Z-Achse so weit hochfahren, wie man eingestellt hat. 4. Fräser/Bohrer wechseln 5. Erneutes Probing mit dem neuem Fräser/Bohrer 6. Die Differenz aus den beiden Z-Koordinaten aus beiden Probings errechnen und den Z-Nullpunkt dementsprechend verschieben. 7. Programm weiter laufen lassen
So ähnlich ist der Ablauf mit Wz-Längensesor in WinPCNC beim Wz Wechsel auch. Als Referenz dient der Nullpunkt des 1. Werkzeug. Das ist für Albert erstmal viel Arbeit. Nach meiner o.g. Methode müsstest du auch klar kommen.
Deine oben genannte Methode ist natürlich machbar und diese werde ich auch erst einmal umsetzen. Bzw. habe ich schon umgesetzt. Allerdings spricht ja nix dagegen sich über den Ablauf Gedanken zu machen und diese zu Posten. Außerdem darf man doch auch ab und zu wünsche äußern. Ist doch bald Weihnachten :)
theblackraven schrieb: > Außerdem darf man doch auch ab und zu wünsche äußern. Ist doch bald > Weihnachten :) eben, das mit dem "Weihnachten" gilt für den Programmierer auch. Nebenbei darf man sich bei Hilfestellungen auch bedanken!!!
Ich habe mich doch schon ein paar posts zuvor bei dir bedankt. Aber trotzdem noch mals danke. Ich habe ja auch nicht geschrieben, dass albert meinen wunsch bis weihnachten erfüllen soll. Albert darf natürlich selbst entscheiden welche wünsche/verbesserungen wann, wie und überhaupt einfließen. Nix desto trotz lebt ein gutes und erfolgreiches Programm durch Anregungen und Rûckmeldungen der User. Aber lass uns bitte nicht ,wie in dutzenden anderen threats, mit einer emotionalen Diskussion anfangen und sachlich bleiben. Fände ich für diesen Threat nämlich sehr schade.
Schon gut, das ganze Projekt ist in dieser Form ein tolles Geschenk von Albert. Für normale Fräsaufgaben absolut ausreichend!!! Das Arbeiten mit mehreren Werkzeugen + Wz-Längensensor sprengt meiner Ansicht nach den Rahmen einer Freeware. Die Betonung liegt auf Freeware, da sollte solch ein Projekt nicht ausufern, zumal der Programmierer alles in seiner Freizeit (unentgeldlich) durchführt. Solch ein Projekt wird nie fertig!!! Für o.g. Anforderungen gibt es für "kleines Geld" tolle Lösungen. Wer solche Lösungen benötigt, darf ruhig ein paar @ in die Hand nehmen, für die Hardware zahlt er ja auch. Das ist meine Meinung Manfred
Unabhängig davon ob diese Funktion für den Werkzeugwechsel in eine Freeware gehört und Albert dieses Funktion in seine super Software weiter ausweiten will, habe ich mir weiter darüber Gedanken gemacht. Eventuell ist der Programmieraufwand nämlich garnicht so groß. Mit dem Kommando ? kann man sich die aktuelle Position der Maschine Ausgeben lassen. Das Ergbnis kann so aussehen: <Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000> MPos entspricht der absoluten Maschinenkoordinate WPos entspricht der Arbeitskoordinate, also der relativen Koordinaten zu dem vor Beginn der Fräsarbeit festgelegten Nullposition. Mit dem Kommando G90 werden die neu eingegeben Positionen mit den Maschinenkoordinaten angefahren. Mit dem Kommando G91 werden die neu eingegeben Positionen mit den Arbeitskoordinaten angefahren. Dadurch kann man dann einen festverbauten Werkzeuglängensensor genau anfahren (über die MPos und G90). Mit dem Kommando G38.2 wird ein Probing durchgeführt. Man erhält dabei einen Rückgabewert der folgendermaßen aussehen kann: PRB:0.000,0.000,1.492:1 Ob dies nun eine Mpos der WPos ist, wird in der Doku von GRBL leider nicht vermerkt. Dies müsste Albert aber schon wissen, da er ja schon ein Probing unterstützt. Durch diese Hilfsmittel müsste deshalb wie folgt vorgegangen werden. Einmaliges einrichten der Maschinenkoordinaten des Werkzeuglängensensors. 1. Bei einem Txx im GCode, muss das aktuelle Programm angehalten werden( Dies wird mit der aktuellen Version von SerialComCNC schon gemacht). 2. Befehl G90 um GRBL in den Maschinenkoordinatenmodus zu setzen. 3. Die Maschinenkoordinate des aktuellen relativen Nullpunkts der Z-Achse der Werkzeugspitze sollte SerialComCNC eigentlich bekannt sein. Ansonsten müsste man die beim Setzen der relativen Nullposition in den Speicher von SerialComCNC schreiben 4. Anfahren des Werkzeuglängensensors mit den Maschinenkoordinaten und einem leichten Offset in der Z-Achse 5. Probing mit G38.2 6. Den Rückgabewert speichern 7. Z-Achse von Hand hochfahren und Werkzeug wechseln 8. Erneutes Probing mit G38.2 9. Differenz von beiden Probings errechnen 10. Neuen relativen Nullpunkt setzen 11. Programm weiterlaufen lassen Und warum sollte denn eine Freeware nicht auch einige Funktionen der großen Programme besitzen? Es gibt unzählige Programme, welche Freeware sind und jeweils von wenigen (einer) Personen geschrieben werden. Dabei führen die verschiedensten Beweggründe dazu, dass Programm als Freeware oder Opensource anzubieten. Die Beweggründe von Albert liegen ja nach eigener Aussage daran, dass ihm die anderen vorhanden Frontends für GRBL nicht zugesagt haben. D.h. dass ihm eventuell auch Funktionen gefehlt haben, wie eine halbautomatisierter Werkzeugwechsel. Sonst wäre diese Funktion nicht schon vorhanden... Bei einigen Freewareprogrammen gibt es sogar extra Foren dafür und oft dann auch einen gewünschten Post für Funktionswünsche. So jetzt ist aber genug diskutiert. Das nächste Wort dazu sollte Albert haben. Ich hoffe aber, dass Albert seinen Spass an diesem Programm nicht verliert und uns weiterhin an tollen neuen Funktionen teilhaben lässt.
theblackraven schrieb: > Mit dem Kommando G90 werden die neu eingegeben Positionen mit den > Maschinenkoordinaten angefahren. > Mit dem Kommando G91 werden die neu eingegeben Positionen mit den > Arbeitskoordinaten angefahren. Falsch. G90=Absolut; G91=Relativ.
Für ich waren die absoluten Koordinaten die Maschinenkoordinaten, da diese fix sind (Also G90). Relativ werden für mich die Koordinaten, wenn ich vor Beginn der Fräsarbeiten einen neuen Nullpunkt setze und diesen von nun an als Bezug nehme (Also G91). Evtl. habe ich dies auch falsch verstanden.
Oder bedeutet relativ, dass ich immer vom aktuellsten Punkt die neuen Koordinaten relativ zu diesem anfahre? Dann ist meine Aussage natürlich falsch
Servus zusammen, Werkzeugwechsel in Verbindung mit GRBL währe astrein eventuell hier mal ein Gedankenanstoß.
1 | M9 ( Kühlwasser aus ) |
2 | M5 ( Spindel aus ) |
3 | G53 G0 Z-1 ( Anwahl MKS und in Z auf -1 Fahren ) |
4 | T02 M6 ( Werkzeugwechsel Aufruf ) |
5 | G53 G0 X33 Y33 ( Anwahl MKS auf Wechselpunkt fahren ) |
6 | G38.2 Z-66 F66 ( Probing mit G38.2 [Z-=Verfahrweg | F=Vorschub ] ) |
7 | G91 G0 Z1 ( G91 relativ vom aktuellen Punkt 1mm in Z nach oben fahren ) |
8 | G38.2 Z-2 F5 ( Probing mit G38.2 [Z-=Verfahrweg | F=Vorschub ] ) |
9 | G10 L2 P1 Z0 ( NP [G54] setzen aktueller wert ist 0 ) |
10 | G53 G0 Z-1 ( Anwahl MKS und in Z auf -1 Fahren ) |
11 | G54 ( Anwahl NP [G45] ) |
12 | S6789 M3 M8 ( Spindel Start und Kühlwasser ein ] |
13 | G0 X10 Y-1 ( Eilgang Positionierung in X & Y ) |
14 | G0 Z1 ( Eilgang Positionierung in Z ) |
15 | G1 Z-0.75 F150 ( Vorschubbewegung in Z ) |
Gruß, Jojo
Hallo Jojo, ich denke dein Code soll während einer Programmunterbrechung (M0) für einen Werkzeugwechsel ausgeführt werden? Man sollte direkt nach der Unterbrechung $G (View gcode parser state) ausführen und das Ergebnis speichern um die die bis dahin aktiven Modes wieder herstellen zu können vor Programweiterführung (sehr blöd wenn G90 verwendet wurde, dann aber in der Unterbrechung auf G91 umgeschaltet wurde). Das manuelle Einschalten der Spindle und Cooling würde auch entfallen. Bei Ausführung von G38.2 (oder .3 .4 .5) stimmt normalerweise die zurückgegebene Probeposition nicht mit der Stopposition (Machine coordinates) überein da nach Triggern des Probe-Pins (Schalter) noch die Bremsrampe gefahren wird, bei mir sind es 0,1 bis 0,5mm Unterschied. Man müsste sehr sehr langsam fahren um diesen Effekt zu minimieren. D.h. das Nullen an der Stoppostion (G10 L2 P1 Z0 oder G92 Z0) führt zu einem Fehler. D.h. das Steuerprogramm müsste das G38-Ergebnis verarbeiten und on the fly das Z-Probingergebnis verarbeiten (evtl. G53 G0 Z#Probeergebnis). D.h. man müsste eine Variablenverarbeitung einbauen... Alles nicht so Einfach wie es auf den ersten Blick aussieht. Gruß Sven
I am a student. You can share source code. I very need it. Thank you very much.
Gia Bao schrieb: > You can share source code. I very need it. We understand. And when we can buy it in China with a little CNC machine ?
Das ist schon länger so. Kurzfristig war da mal ein Link zum Verkauf der Seite.
Günter N. schrieb: > Was ist los??? Die Seite ist wieder ereichbar ! http://www.serialcominstruments.com/
Das ist ja ganz schön - aber es ist schade um das schöne Projekt. Solange die zeitliche Begrenzung der Software aktiv ist, werde ich sie nicht mehr anfassen. Vielleicht könnte Ulrich uns aufklären ob eine kommerzielle Version geplant ist und wie diese Version zu erwerben wäre.
Einhart P. schrieb: > Solange die zeitliche Begrenzung der Software aktiv ist Die zeitliche Begrenzung der aktuellen Version beträgt, wie auch für weitere Versionen, jeweils 2 Jahre. Einhart P. schrieb: > Vielleicht könnte Ulrich uns aufklären ob eine > kommerzielle Version geplant ist Ist nicht geplant. Würde sich auch nicht lohnen, weil: Die aktuelle Version wurde ca. 1300 mal runter geladen. Ich schätze mal vielleicht 10% oder weniger der Downloader würden die Software auch kaufen, wenn der Preis im Rahmen bleibt. Hier setze ich mal 49 Euro an. Dafür ein Gewerbe anmelden lohnt sich nun wirklich nicht. Und mit meinen 66 Jahren habe ich auch keine Lust mir irgendeinen Stress zu machen.
Sehr schön wieder was von dir zu hören Ullrich. Und ich geb dir recht, es lohnt sich wirklich nicht sich irgendwelchen Stress auszusetzen. Genügt ja schon, in deinen Threats hoch und runter zu lesen... Ansprüche, Wünsche, "Hinweise" usw...... Danke lese ich dort recht wenig.
Danke für die Klarstellung Ullrich. Wenn du die Software nicht verkaufen willst - warum die Zeitbegrenzung? Meine Fräse sollte auch in 2 Jahren noch laufen. Natürlich kann man die Zeit des PCs zurückstellen. Das gibt aber z.B. im Internet Probleme. Und nocheinmal: das Programm ist das Beste, dass ich als Frontend für GRBL gesehen habe. Vielen Dank dafür!
Einhart P. schrieb: >Meine Fräse sollte auch in 2 Jahren noch laufen. Wenn Du immer eine einigermassen aktuelle Version benutzt läuft die Software auch noch in mehr als 2 Jahren. Jede neue Version läuft die nächsten 24 Monate problemlos. Falls ich das Projekt mal beende, werde ich als letzte Version das Zeitlimit aufheben. Einhart P. schrieb: > Natürlich kann man die Zeit des PCs zurückstellen. Kannst Du machen, die Software wird aber nicht laufen :) Falls es Dich interessiert: http://enigmaprotector.com/en/about.html Einhart P. schrieb: > Wenn du die Software nicht verkaufen > willst - warum die Zeitbegrenzung? Einfach um mir alle Möglichkeiten offen zu halten. Einhart P. schrieb: > Und nocheinmal: das Programm ist das Beste, dass ich als Frontend für > GRBL gesehen habe. Vielen Dank dafür! Ist doch nur ein Bastelprojekt, trotzdem Danke.
Hallo Ulrich, schön wieder von dir zu hören, ich hatte schon die schlimmsten Befürchtungen... :-) Gruß Harald
Hallo Ulrich, schön wieder von Dir zu hören. Nachdem Du hier sehr ruhig geworden bist und dann auch noch die Meldung kam, dass die Homepage offline ist hatte ich auch schon die schlimmsten Befürchtungen. Auch wenn Du es "nur" als Bastelobjekt bezeichnest, muss ich sagen, dass es "nur" ein hervorragendes Bastelobjekt ist. Jetzt kann ich mich auch ruhigen Gewissens daran machen mich mit der Kamerafunktion zu beschäftigen.
Hallo Edgar, was meinst du mit "...mich mit der Kamerafunktion zu beschäftigen."? Bist du dran, das kleine Manko von Ulrichs Meisterwerk - mancher Kameratreiber ist nicht kompatibel mit seiner Implementierung - für uns alle zu beheben? Das wäre natürlich der Hammer, denn ich habe mir eine schöne kleine feine 8 mm Stiftkamera in HD gekauft, aber leider schlägt Murphy bei mir ebenfalls zu, keine Kooperation von SerialComCNC und meiner Kamera :-( Die üblichen Tipps und Kniffe (als Admin starten usw.) haben alle nicht gefruchtet. Harald
Hallo Harald, ich muss dich leider enttäuschen, ich meinte mit Kamera beschäftigen lediglich: "meine" Cam mit dem Programm zu testen und dann an der Fräse anzubringen um zu sehen ob es sinnvoll ist die dort zu nutzen. Für Fehlersuche in Ulrichs Programm bin ich total unterqualifiziert, sorry. Deswegen bin ich ja auch so froh, das Ulrich dieses toole Tool zur Verfügung stellt. Das ich bisher überhaupt alles zum Laufen bekommen habe grenzt schon an ein Wunder. Edgar
Schade... Ich würde die Cam sehr gerne ebenfalls anbauen. Eine andere Eigenheit von Ulrichs tollem Proggie hat mich nicht losgelassen: Die Art und Weise, wie die Spindel über dem Werkstück positioniert werden kann, ist für mich sehr unhandlich, viel zu viel geklicke mit der Maus. Da mein Monitor am Fräsen-Rechner zu klein ist um das Jog-Dial anzuzeigen, konnte ich diese Methode der manuellen Steuerung nicht ausprobieren, also habe ich mich hingesetzt und eine manuelle Steuerung mit zwei Joysticks gebaut, die einfach parallel zu dem GRBL-Arduino auf die Stepper-Treiber wirkt. Natürlich ist eine gegenseitige Verriegelung eingebaut. Vereinfacht wurde das Unterfangen durch Verwendung der Interfaceplatine, die bei meinem Stepper-Set dabei war. Das Teil hat einen zweiten Eingang für eine manuelle Steuerung, den ich verwende. Die beiden Joysticks habe ich zusammen mit zwei Schaltern (ein Taster, ein Schalter, beide haben eine steuerbare LED-Beleuchtung) in ein Alu-Gehäuse eingebaut, der zusätzliche Arduino sitzt im Rechner und bekommt seine Daten über drei geschirmte Leitungen. Ein Enable per Schalter ist ebenfalls dabei, ansonsten erzeugt der Arduino Step-Impulse, umso schneller, je weiter der Joystick ausgelenkt wird. Beschleunigungskurven konnte ich mir sparen, die mechanische Trägheit der Sticks reicht aus um die Motoren (sanft genug) anfahren zu lassen. Über die virtuelle serielle Schnittstelle des Arduino können die wesentlichen Parameter der Steperzeugung zur Laufzeit eingestellt werden. Fehlt nur noch ein Interface zu SerialComCNC, so dass die über die Joystick implizierten Steps mitgerechnet werden... :-) Wenn Interesse an Einzelheiten des Projektes besteht, bin ich gerne bereit diese zu liefern. Ich habe gerade ein kurzes Video [https://vimeo.com/154491224] auf Vimeo hochgeladen... Harald
Harald S. schrieb: > Ich habe gerade ein kurzes Video [https://vimeo.com/154491224] auf Vimeo > hochgeladen... >>>Seite nicht gefunden >>> >>>Hier gibt es leider kein Video. >>> >>>Entweder wurde es gelöscht oder es war nie vorhanden. Die richtige Antwort wird >>>sich mit an Sicherheit grenzender Wahrscheinlichkeit nicht mehr aufklären >>>lassen
Angehängte Dateien:
Ja, sorry, mein Vimeo-Account ist die Freeware-Variante. Das heißt, ein hochgeladenes Video kommt in eine Queue und wird abgearbeitet, wenn alle Bezahl-Vimeoer gerade keinen Auftrag mehr am Laufen haben. Gemeinhin dauert das so ein paar halbe Stunden, bis meine Videos umgewandelt werden und dann noch ein paar Minuten mehr, bis sie angezeigt werden. Dazu kommt bei diesem Video noch, dass Vimeo mir mehrmals die Konvertierung abgelehnt hat, weil das Format nicht gepasst hat. Als ich meinen Kommentar hier im Forum gepostet habe, hat der Upload erstmnalig geklappt und das Video wurde angenommen. Kann natürlich sein, dass die Meldung von Vimeo, jetzt wäre alles ok, irrtümlich erfolgte... In meinem Account wird das Video immerhin als vorhanden aber noch nicht gewandelt angezeigt. Ich gebe Bescheid, wenn es sichtbar ist. Hier vorweg ein Bild vom Aufbau. Der Aluklotz ist natürlich frei bewegbar und steht nur für den Film auf der Fräse. Harald
Sorry, ich schaffe es nicht, eine Vimeo genehm erscheindende Datei hochzuladen :-( Ich versuche das die Tage ncohmal in Ruhe... Harald 8(
So, ich weiß zwar nicht, warum sich Vimeo eines Besseren besonnen hat, denn ich habe seit dem letzten, angeblich nicht erfolgreichen Upload einer Nicht-HD-Aufnahme gestern abend nichts mehr geändert, aber jetzt ist der Film online und unter dem angegebenen Link [https://vimeo.com/154491224] erreichbar. Entschuldigt das Hin und her. Harald
Falls die Frage schon einmal gestellt wurde - Entschuldigung. Kann ich den g-code hinter den Pfeilbuttons zur manuellen Bewegung anpassen? Mein Ultimaker mag den g-code nämlich nicht, der hinterlegt ist...
Conny G. schrieb: > Kann ich den g-code hinter den Pfeilbuttons zur manuellen Bewegung > anpassen? > Mein Ultimaker mag den g-code nämlich nicht, der hinterlegt ist... Falscher Thread? Hier geht es um CNC Fräsen nicht um 3D Drucker.
Bastler schrieb: > Falscher Thread? Hier geht es um CNC Fräsen nicht um 3D Drucker. Dass ihr Jungs immer so freundlich seid :-) Hier geht es um ein Tool das g-code an eine Gerät schickt, dass ihn versteht. Das kann man doch auch für andere Zwecke als CNC Fräsen verwenden.
Hallo Conny benutze CURA als CAM fürs Drucken. SerialCom unterstützt nur drei Achsen.
Hallo, das Programm ist bisher das beste, was ich im Bereich grbl-Steuerung gefunden habe. Einzelheiten will ich keine nennen, da mir der Funktionsumfang sehr gefällt. Leider gibt es doch gewisse Probleme, die mir aufgefallen sind. Bei manchen Fräsarbeiten arbeite ich mit der Z-Achse recht knapp am oberen Endschalter und wenn ich die Maschine per * auf Home fahren will, fahre ich in den Endschalter hinein. Das zweite ist, wenn ich alle Achsen auf 0 setze, wird auch G28.1 geschrieben, was mir meine Parkposition der Maschine löscht. Die Koordinaten werden ja im ROM gespeichert und ich fahre nach einem Job auf "G28 Z-1" (Maschinen-Nullpunkt ist die untere linke Ecke mit Z-Achse ganz oben, G28 liegt am oberen rechten Ende des Fahrweges um das Werkstück einfach rausnehmen zu können). Wäre es möglich, die Belegung einiger Buttons einstellbar zu machen? Besonders die Buttons "*" und "Setze XYZ Null". Oder alternativ in den Einstellungen eine Checkbox "Maschine besitzt Home-Endschalter", wo dann meinetwegen per "G53 G0 Z-1 | G0 X0 Y0 Z0" auf die Home-Position gefahren wird?
Archer schrieb: > Wäre es möglich, die Belegung einiger Buttons einstellbar zu machen? > Besonders die Buttons "*" und "Setze XYZ Null". Oder alternativ in den > Einstellungen eine Checkbox "Maschine besitzt Home-Endschalter", wo dann > meinetwegen per "G53 G0 Z-1 | G0 X0 Y0 Z0" auf die Home-Position > gefahren wird? Warum definierst Du Dir dafür kein Makro (es sind 4 Makros verfügbar)?
Hallo zusammen, ich muss mal diesen Beitrag pushen, da ich mich frage ob Albert außer am SerialCOM Visualisierung noch hier was tut. Ich weiß, dass er diese Software in der Freizeit und alleine programmiert, und habe bereits erfolgreich mit dieser Teile gefräst. Auch bin ich Albert wie bereits mehrfach geschrieben sehr dankbar, und würde sogar eine Spende/Unkostenbeitrag zukommen lassen. Mich wundert nur aktuell, dass das Projekt aktuell einen "toten" Eindruck macht, leider. Daher die Frage, weiß jemand ob es hier noch was neues gibt oder ist die Entwicklung eingestellt? Mit freundlichen Grüßen EGS
EGS schrieb: > da ich mich frage ob Albert außer am > SerialCOM Visualisierung noch hier was tut. SerialComCNC wird von mir auf jeden Fall weitergeführt. Alles gleichzeitg machen kann ich allerdings nicht und würde keinem Projekt gut tun. Daher bitte noch etwas Geduld haben :) Den schon lange versprochene EasyJob Modus werde ich als nächstes in Angriff nehmen. Gruss Ulrich Albert
und was spuckt der Terminalprogramm bei Command $$ raus? Die Konfiguration ist falsch, glaube ich.
Ach sorry, habe falsche Thread geantwortet.
Hallo, Erstmal das wichtigste: Klasse Programm. Würde das auch mit einem Arduino Mega 2560 irgendwie funktionieren?
Albert M. schrieb: > SerialComCNC wird von mir auf jeden Fall weitergeführt. Hallo Albert, danke für das Feedback. Das sind super Nachrichten und ich freu mich schon Wahnsinn auf den Easy-Job Modus. Dann frohe Ostern zusammen, MFG EGS
Ich arbeite auch mit dem Programm und es funktioniert recht gut bei mir. Nur die WebCam die ich daran gebaut habe, ärgert mich etwas. Mal geht Sie und dann mal wieder nicht. Gibt es irgendwie die Möglichkeit, diese Kamerafunktion noch zu verbessern. Oder einen eigenen Driver da mit einzubinden ? Weil direkt aus dem Windows funktioniert die Kamera. Aber das Programm SerialComCNC verweigert meistens die Zusammenarbeit mit der WebCam. Habt ihr da schon mehr Erfolge gehabt oder könnt mir eine Kamera empfehlen ? So eine kleine Inspektionskamera für Rohre wäre ja auch Klasse. Nur das geht auch nicht mit dem Programm. Oder man schreibt nochmal ein kleines Programm nur für die Kamera, was einfach auf das Bild ein Kreuz erzeugt. Wäre ja auch nicht schlecht.
Norbert S. schrieb: > Ich arbeite auch mit dem Programm und es funktioniert recht gut bei mir. > Nur die WebCam die ich daran gebaut habe, ärgert mich etwas. > Mal geht Sie und dann mal wieder nicht. > Gibt es irgendwie die Möglichkeit, diese Kamerafunktion noch zu > verbessern. Oder einen eigenen Driver da mit einzubinden ? Hallo Norbert, Albert baut die Steuerzentrale, alles Drumherum musst du selber anpassen. Auch an alle andern die hier über Schwierigkeiten mit WebCam´s sprechen. Man sollte hier nach der eigentlichen Ursache suchen, und diese liegt meist im System selbst. Nicht unbedingt die Treiber der Webcam oder USB Kontroller, aber das Ganze in Zusammenspiel. Ich habe schon ein paar Jahre Erfahrung in Bezug auf PC Hard- und Software. (seit 286, MS-DOS, Win 3.11.) Wo die Störung Auftritt ist nicht immer die Ursache. Das hat bei mir schon mal ein paar Nächte gedauert bis ich die Ursache finden konnte. Da ich auch das System nicht gleich wieder neu aufspiele sondern Grundsätzlich versuche die Ursache zu finden. Des Öfteren war es ein alter Treiber Und auch Programme die dazwischen gefunkt haben. Grade Tools die im Hintergrund das System sauber halten wollen. Ist unnötig, die Platte kann man selbst defragmentieren. Bei mir Läuft alles auf Compactflash Karte 16GB. (IDE Adapter) keine Treiber notwendig. Reicht vollkommen, 8GB würden schon reichen da die reine XP SP3 Installation mit Treiber grade 1,5GB brauch. keine Defragmentierung notwendig. Schnellen Zugriff. Es kann auch ein Programm im Hintergrund für die Störung sorgen. Grade Antivieren oder Firewall Programme belasten meist unnötig das System. Ein Programm blockierte mit unter den IRQ für ein paar sec. Und brachte das ganze System ins stocken. Ich hatte erst die Treiber in Verdacht. Es kann schon hilfreich sein einen anderen UBS Anschluss zu nutzen. Ich hatte Störung durch billige USB Verlängerung´s Kabel. Oder durch schlechte IRQ Belegung vom System. Von daher alles im Bios abschalten was nicht unbedingt notwendig ist. Albert kann da auch nichts machen. Sein Programm greift nur auf das zurück was schon da ist. Ich nutze einen etwas älteren Mini Rechner mit XP SP3 2x2,1 GHz 2GB RAM. 22 Zoll mit Touchscreen. (lässt sich gut bedienen) dazu noch ein alter USB- Joystick zur manueller Steuerung. Ursprünglich war dort Vista drauf. XP ist immer noch für mich die Nr. 1 in Sachen Stabilität. Es muss nicht gleich Windows 8.1 oder gar 10 sein. Auf Windows 7 würde ich noch mit gehen aber nur wenn es notwendig ist. Ich nutze eine WebCam von Logitech C910 mit Autofokus und beim ersten Start dauert es auch lange c.a. 10 sec. Habe nur die Treiber installiert. Nicht die ganze Software. Aber dann läuft sie ohne Störung. Ich hatte es auch mit einer billigeren versucht ging auch. War aber nur zwei Wochen. Auf dem XP ist nur das nötigste drauf. Hat kein Internet, kein Antivieren Programm oder Firewall. Was sich nicht ausbauen lässt habe ich im Bios abgeschaltet Daten werden auf einen anderen Rechner erstellt und über USB-Stick eingespielt. Ich würde sogar auf Touchscreen, Funk Maus, Funk Tastatur und USB- Joystick in Bezug auf Stabilität verzichten. Hatte anfangs auch mit EMV Störung zu kämpfen, die ich durch ein paar zusätzliche Kondensatoren und dickeren Masseleitung in den Griff bekam. Albert hatte so schon Schwierigkeiten sein Programm für sämtliche Aktuellen Windows Systeme Störungsfrei zum Laufen zu bringen. Und hier ging es nur um die für das Programm notwendige Funktion. Norbert. Ich weiß jetzt nicht mit welchem System Du arbeitest. Ich Empfehle dir einen etwas betagten PC oder Laptop mit XP und nur das notwendigste drauf. Selbst Sound ist nicht unbedingt notwendig. Und dann nach und nach erweitern. Ich hatte Serialcomcnc auf einen PIII mit 800 MHz und 512MB Monate erfolgreich getestet. Das Bild der Webcam muss doch nicht in 4K sein VGA, SVGA oder WXGA reicht völlig. Hallo Albert ich würde mich sehr darüber freuen wenn ich das Programm Zeitlich unbegrenzt nutzten darf. Eine alternative möchte ich mir nicht vorstellen. Gruß Daniel.
Angehängte Dateien:
-
SerialComCNC_0.9f.jpg
110 KB
Hi Albert, I am diying a GRBL CNC. Just need a multi-function control program. Your SerailComCNC is great! But when I install the V0.9f on my Win7 the error message: Cannot open/create C:\SerialComCNC\Doku\Configuring Grbl v0.9 ?grbl Wiki ?GitHub.url file!. I also use admin authority to install the same error occur. Other V9 version has the same error. Steven
On Win10 programm after stat immediately close, any reason? thx
Angehängte Dateien:
-
DSC00100.jpg
240 KB
Hallo Ulrich, vielen Dank für die Mühe, die in SerialComCNC steckt. Bei uns ist die MF70 dadurch erst richtig zur Geltung gekommen. Die G-Code Erzeugung passiert mit Estlcam. Es funktionierte alles auf Anhieb perfekt. Dank vieler Foren-Beiträge haben wir gängige Anfängerfehler vermeiden können. Der Toolwechsel war hier ja schon öfter ein Thema. Dazu habe ich noch folgenden Vorschlag: Da der veränderbare Z-Pos Preset in die ini Datei geschrieben wird, ist es meiner Meinung nach wünschenswert auch den angewählten Tool-Wechsel zu speichern. Dann könnte man komfortabel die z.B. von Estlcam für den Tool-Wechsel geschriebenen Mxx durch Txx ersetzen und müsste nicht bei jedem neuen Job das Kästchen wieder ankreuzen. schöne Grüße aus dem Bastelkeller Herbert
Hallo Herbert, warum machst Du nicht gleich alles mit Estlcam? Das steuert doch auch den Arduino an, und die Positionierung mit dem xBox Controller ist genial..... SerialComCNC funktioniert sehr gut, jedoch passiert hier seit langem nichts mehr. Ich habe schon etliche Vorschläge gemacht, stattdessen wird man von Leuten angelabert "das man den armen Autor nicht überfordern sollte"..... Der Autor äußert sich überhaupt nicht..... Dem Projekt würde die Öffnung des Sourcecodes gut tun! ToM
ToM schrieb: > SerialComCNC funktioniert sehr gut, jedoch passiert hier seit langem > nichts mehr. Sehr schade, dass das sich so entwickelt hat. Ich habe auch mal sehr viel darauf gegeben. Mittlerweile benutze ich auch Estlcam und kann nur meine volle Zufriedenheit kund tun. ToM schrieb: > Dem Projekt würde die Öffnung des Sourcecodes gut tun! Das sehe ich auch so, aber vermute mal, das wird nie passieren ... :(
ToM schrieb: > warum machst Du nicht gleich alles mit Estlcam? > Das steuert doch auch den Arduino an, und die Positionierung mit dem > xBox Controller ist genial..... Hallo ToM wir arbeiten hier an mehreren Projekten (Robotik i.d. Schule/HTL), da gibt es also alle möglichen g-code Dateien, Selbsterstellte, aus CREO über Estlcam erstellte etc. Die Möglichkeit, diese Dateien/Teile auf Machbarkeit, Plausibilität und Verträglichkeit mit grbl zu testen und sofort zu ändern und abzuspeichern (z. B. auf altem XP-Laptop mit Arduino-Clone der Maschinensteuerung für 4€) ohne Material und Zeitverlust bietet uns bisher nur SerialComCNC. Estlcam ist genial für die Übersetzung von dxf Dateien etc., erfordert aber erheblich mehr Rechenleistung (Windowskonformität ??) und hat keinen Simulationsmodus für nc Dateien (oder hab ich da was übersehen ?). Zur Handsteuerung hat sich bisher ein kleiner Selbstbaujoystick mit USB Treiber aus einem Keyboard bewährt. xBox Controller wird vielleicht noch folgen, nachdem ich einen Gamimg-Kurs belegt habe....zu viele Knöpfe... Bei Gelegenheit werden wir auch mal Estlcam zum Ansteuern der Maschine verwenden und wahrscheinlich ebenso zufrieden sein. ..never change a running system..oder doch? Herbert
Hallo, > Dem Projekt würde die Öffnung des Sourcecodes gut tun! Ich habe mal versucht die Funktionalität von SerialComCNC nach zu programmieren und zu erweitern - falls der Code nicht gefällt: ich bin nur Hobbyprogrammierer und das ist bis jetzt mein größtes Projekt. Ich hoffe ich blamiere mich hier nicht und das Tool läuft auch bei anderen Leuten: https://github.com/svenhb/GRBL-Plotter Benutzung auf eigene Gefahr - das Tool ist vermutlich nicht Fehlerfrei. Die Oberfläche ist zwar auf 2D Bearbeitung ausgelegt, aber der GCode an sich (auch 3D) wird ja einfach nur an den Arduino durchgereicht. Gruß Sven
Hallo zusammen, schön, dass sich so viele melden, und das sich Innovationen auftun.... Bei Estlcam (Lizenzierte Version) habe ich bisher das Problem, dass Komplexe G-Codes nur stockend ablaufen. Laut dem Autor passiert das bei "zu vielen Engen Kurven". Ich habe ihm bereits mitgeteilt, dass der selbe Code einwandfrei mit SerialComCNC und GRBL zusammen sauber abläuft. Zudem habe ich vorgeschlagen eventuell einen leistungsstärksten Arduino einzusetzen: https://www.arduino.cc/en/Main/ArduinoBoardMega2560..... Leider noch keine Lösung.... Auf jeden Fall solltet ihr Estlcam mal testen. Mann kann direkt aus Estlacm den Arduino flashen! Und er spielt auch sauber wieder die vorgerige Firmaware (GRBL) zurück! ToM
Angehängte Dateien:
-
P1020844_small.jpg
240 KB
ToM schrieb: > Der Autor äußert sich überhaupt nicht..... Der Autor hat in den schönen Jahreszeiten Sommerpause. Der Autor geniesst da sein Rentnerleben, macht viel Urlaub und vertrödelt seine Zeit mit seinen Sommerhobbies. Der Autor hat während dieser Zeit überhaupt keine Lust auf Elektronik und Programmieren. Und dann auch keine Motivation hier dauernd reinzuschauen und Posts zu beantworten. Gruss Ulrich Albert
Hallo Albert, Grundsätzlich auch richtig, zumal alles in Freizeit und nicht kommerziell passiert. Aber ohne der Böse sein zu wollen: Da war auch die "schlechte Jahreszeit" echt ne Weile Ruhe. Nichts desto trotz geniess das gute Wetter?, hab auch grad wenig Lust auf Technik. Der nächste Herbst/Winter kommt leider mit Gewissheit. MfG, EGS, der sich auf die Easy-Jobs freut ☺
Albert M. schrieb: > Der Autor hat in den schönen Jahreszeiten Sommerpause. > > Der Autor geniesst da sein Rentnerleben, macht viel Urlaub und > vertrödelt seine Zeit mit seinen Sommerhobbies. > > Der Autor hat während dieser Zeit überhaupt keine Lust auf Elektronik > und Programmieren. Das ist eindeutig und sein gutes Recht. Mal ein kurzes " Machts gut, liebe Leute, bin mal weg bis zum Herbst weil -siehe oben- " haette wohl den meisten hier ein neidisches und wohlwollendes verstaendnisvolles Gefuehl abgelockt und nicht dazu gefuehrt, sich sorgenvolle oder enttaeuschte Fragen zu stellen... Die letzten Regentage hier war ich z.B. viel im Bastelkeller und habe die anderen Programme mal ausprobiert. Sven schrieb: > Ich hoffe ich blamiere mich hier nicht und das Tool läuft auch bei > anderen Leuten: https://github.com/svenhb/GRBL-Plotter Blamieren wirst du dich damit sicher nicht, das Gegenteil wird eintreten. Bleib dran und eroeffne bitte dazu UNBEDINGT einen eigenen Thread, um gebuehrende Aufmerksamkeit zu bekommen. Ein sehr interessantes Programm. DANKE Sven
Hobbiest schrieb: > Blamieren wirst du dich damit sicher nicht, das Gegenteil wird > eintreten. > Für Hobbyprogrammierer ist's aureichend. > Bleib dran und eroeffne bitte dazu UNBEDINGT einen eigenen Thread, um > gebuehrende Aufmerksamkeit zu bekommen. ja, bitte, würde dir paar Fehler auflisten. EGS schrieb: > ...der sich auf die Easy-Jobs freut Mach dir nicht so sehr große Hoffnung.
Hallo, (Wie) Ist es möglich (eagle cad) DRILL Daten an GRBL ohne viel Aufwand weiterzugeben? Freundliche Grüße, Richard
Hallo Richard, unter http://www.einfach-cnc.de/platinen_frasen.html findest Du eine Beschreibung wie das mit einem Plugin für Eagle einfach generiert werden kann. Gruß crix
Hallo Albert, ich nutze jetzt schon eine ganze Weile dein GRBL Frontend. Es ist bisher das Beste was ich finden konnte! Ich weiß dass Du den Sommer geniesst und rechne auch nicht mit einer baldigen Antwort ;-) Will aber trotzdem schonmal einige Beobachtungen und Vorschläge notieren: 1) Ich fräse ab und an in Styrodur, was dazu neigt zu schmelzen und am Fräser hängenzubleiben. Es wäre schön wenn man nach Anhalten des Fräsprogramms den Motor stoppen könnte um den Fräser zu reinigen. Aktuell sind allerdings alle Bedienmöglichkeiten unterbunden wenn man auf die Halt Taste drückt. 2) Wenn ich eine Datei geladen habe und auf Start Drücke, passiert es manchmal daß ein Not Stopp ausgelöst wird. In dem Fall scheint der Tastenzustand programmintern nicht synchron zu sein, da die Taste grün ist aber einen not-halt auslöst. 3) Die Koordinaten nach einem Not Halt stimmen oft nicht. Besser ist es wenn man vorher die Halt Taste drückt und dann erst den Not Halt auslöst 4) Nach einem GRBL Neustart ist keine Feed Rate gesetzt, was dann beim Verfahren jedesmal eine entsprechende Fehlermeldung provoziert. Ich würde eine Option begrüssen die automatisch eine default- oder die letzte eingestellte Feedrate setzt. Vielleicht kann man für jede Achse optional eine Default Feedrate setzten die automatisch beim betätigen der Pfeiltasten mitgeschickt wird. Gruß crix
Christoph C. schrieb: > 2) Wenn ich eine Datei geladen habe und auf Start Drücke, passiert es > manchmal daß ein Not Stopp ausgelöst wird. Hallo Christoph, dieses Phänomen beobachte ich bei meinem Rechner ebenfalls. Ich glaube, dass das an einer prellenden Maustaste liegt. Die Lösung von Alberts Seite wäre in diesem Fall, eine (kleine) Pause nach dem Click einzubauen um das Prellen abzufangen/auszublenden -> Entprellroutine. Harald
Angehängte Dateien:
-
SerialComCNC_error_msg.jpg
100 KB
Hi, Any one can give me an answer? I am a diying GRBL CNC. Just need a multi-function control program. your SerailComCNC is great! But when i install the V0.9f on my Win7 the error message: Can not open / create C: \ SerialComCNC \ Doku \ Configuring GRBL v0.9 ? Grbl Wiki? GitHub.url file !. I therefore use admin authority to install the same error occur. Other V9 version has the same error. Steven
Hello Steven, seems that you installed SerialComCNC (SCC) on drive C:\ Don't know exactly, but perhaps your windows is configured in a way that you have no/not enough access rights to the given path. I installed SCC to drive D:\Programme\SerialComCNC\... and had no problems. My system is german. I suppose yours is english. Might be part of the problem, too, but don't know. Harald
Harald, Thanks for your prompt reply. I already try drive D:\. But the issue is the same. I am using Chinese Win7. Steven
Hi Steven, sorry, no better idea :( Did you try to create this file manually? The exact notation (on my computer) is: "Configuring Grbl v0.9 · grblgrbl Wiki · GitHub" (without quote). Note those centered dots between "v0.9 " and " grblgrbl" and "Wiki " and " GitHub". I suppose, those characters are not recognized in chinese windows or have a different meaning. This theory is hardened by the two "?" in your error message picture. I found this "middle dot" as "U+00B7 · c2 b7 MIDDLE DOT" in UTF-8-Code tabele with Unicode characters. I don't know whether you can change your chinese windows to accept UTF-8 characters as filenames, but in my opinion that seems the only way to succeed. Ulrich Maassen may be able to change this silly name to somthing more feasible, but I think the chance to get Ulrich doing something on that problem just now is very small. He does programming only when the weather is bad and we now have summer.
Hi Harald, Thank you for your effort to solve my problem. As you suggest,I am trying to do two things: 1. Change my chinese windows to accept UTF-8 characters as filenames. (finding out how to do it) 2. Install a English language package and change the display and keyboard to US English. I'll let you know the result. Best, Steven
Hi Harald, You are right. The Chinese Windows does not recognize the character"·" as a filename. I installed SCC successfully after changing the Windows's language and time zone to US English. Thank you so much, Steven
Hi Steven, fine! Thank you for your feedback! Harald
Mal eine Frage. Zur Zeit kann ich ja nur eine GRBL Karte anschließen, was auch super arbeitet. Ich brauche nun aber eine 2. Karte, da ich eine 4. & 5. Achse brauche, ich baue mir gerade eine 2. Spindel dran und die müssen gleichzeitig arbeiten. Was kann ich machen? Gibt es sinnvolle alternativen? Mfg Uli
Ja, gibt es, siehe hier: https://github.com/svenhb/GRBL-Plotter Video: http://www.youtube.com/watch?v=x5UTHpgsfII Allerdings wird entweder das eine oder das andere GRBL-Board angesteuert. Gruß Sven
Auch ein schönes Projekt, nur leider brauche ich keinen Plotter oder 3D Drucker, oder .... Ich muss halt nur in mein Werkstück von der Seite ein paar Schlitze fräsen, ein umspannen ist aufgrund der Abmessungen nicht möglich! Aber für dieses Projekt wäre der Wechsler doch eine wunderschöne Erweiterung. Oder einfach eine 2. Karte die man mit ansteuern kann. Auch hilfreich wären dann Maschinen bezogene M-Befehle die ich aus dem Programm aufrufen kann. Um zB. ein Toolchange aufzurufen oder eine Positions Korrektur (mehr dazu unten). Auch wäre es toll wenn man eine Korrektur Möglichkeit hätte die von einer Kamera gesteuert würde. Hier im Forum denke ich da logischerweise an einen SMD Bestücker, aber ich könnte so was gebrauchen um Winkelschwankungen beim einspannen von Werkstücken zur Nachbearbeitung auszugleichen oder vorhandene Löcher automatisch sauber anzufahren. Das ist immer eine scheiß arbeit solche fremden Teile nachzuarbeiten, nur um noch ein paar eigene Löcher rein zu bekommen. Mfg, Uli
>nur leider brauche ich keinen Plotter oder 3D Drucker Alle bekannten GCode Befehle werden an den Arduino weitergereicht... >Aber für dieses Projekt wäre der Wechsler doch eine wunderschöne Erweiterung. Es liegt ja an dir die entsprechenden Befehle zu definieren - siehe Video >Auch wäre es toll wenn man eine Korrektur Möglichkeit hätte die von einer Kamera gesteuert Kamera ist auch drin - habe ich aber lange nicht mehr getestet... Ansonsten einfach bei Github runterladen und selber erweitern... Gruß Sven
> Ansonsten einfach bei Github runterladen und selber erweitern... Dann könnte ich auch gleich die GRBL Karte ändern oder was eigens schreiben, aber das ist doch genau das was ich nicht will. Die Welt braucht nicht noch ein Projekt zu diesem Thema, mal abgesehen davon das ich mit PC Programmierung nichts zu tun habe. > Es liegt ja an dir die entsprechenden Befehle zu definieren Nur wenn keine 2. Karte im Code drin ist dann kann man nichts definieren. Die Kamera kann aber nicht das machen was ich brauche, keine Winkel Bestimmung oder sonstiges. Die ist nur eine Positionshilfe für den Ref-Punkt, das nutzte ich immer zum nach Bohren. Aber zum nacharbeiten ist das nichts. Die Kamera wird nach der REF Erkennung auch abgeschaltet. Vielleicht kann ja der Entwickler der Software mehr dazu sagen. Mfg, Uli
Angehängte Dateien:
-
Fehlermeldung.jpg
150 KB
Hallo alle miteinander! Kommt irgendjemandem die Fehlermeldung bekannt vor und hat bestenfalls sogar noch eine Idee, wie man das behebt? Das ganze tritt nach spätestens zwei Minuten relativ unabhängig von irgendwelchen Eingaben auf. Ich bin gerade noch im Aufbau, hab das hex file (ursprünglich das "mitgelieferte", dann manuell installiert, mit gleichem Ergebnis) auf meinem Arduino Uno installiert und wollte eigentlich erstmal nur die Einstellungen prüfen, aber es tut sich nichts, bis zur Fehlermeldung. Wenn der Fehler banal und blamabel ist, ist mir das gerade auch egal, es wäre einfach nur toll, wenns endlich weiterginge. Danke schonmal im voraus!
Hallo Jakob, die Fehlermeldung kommt mir in der Tat bekannt vor. Es dürfte sich hier m.E. nicht um ein Softwareproblem handeln, sondern eher um eine EMV-Störung (aller Wahrscheinlichkeit nach im USB-Kabel). Probier einfach mal ein anderes USB-Kabel aus (am besten mit Ferritringen an beiden Enden, gut abgeschirmt und möglichst kurz). Möglicherweise ist damit das Problem schon beseitigt. Anderenfalls solltest Du checken, ob sich an der benutzten Steckdose irgendwelche "verdächtigen" Verbraucher (z.B. Leuchtstoffröhre mit normalem Starter) befinden - bei mir war das der Grund für die Fehlermeldung ... Ansonsten könnte auf ein Netzfilter hilfreich sein ... Viele Grüße Thomas
Hallo Thomas Erstmal Danke für die schnelle Antwort, das hört sich alles absolut nachvollziehbar an. Auf die Idee mit dem anderen Kabel bin ich auch schon gekommen, allerdings ist das noch länger, auch nicht hochwertiger und das Ergebnis war das selbe. Intressant ist allerdings, dass ich inzwischen auch ein Programm namens UniversalGcodeSender installiert habe. Mit diesem läuft bisher alles Problemlos. Bisher hab ich schon die Einstellungen vorangepasst und mich ein paar Minuten mit dem Programm beschäftigt und es scheint stabil zu laufen. Wenn das Problem also auf Rauschen zurückzuführen sein sollte, würde SerialComCNC scheinbar wesentlich empfindlicher darauf reagieren. Also vielleicht doch in irgendeiner weise Bastelmaterial für die, die sich mit dem Programm beschäftigen ;)
Angehängte Dateien:
-
SerialComCNC.jpg
140 KB -
SerialComCNC_Antivir_Meldung.jpg
62 KB
Hallo, ich möchte mich zunächst beim Autor dieses Produktes ganz herzlich für das zur Verfügung stellen von SerialComCNC bedanken. Ich möchte dieses auch sehr gerne für meine kleine umgebaute Proxxon Fräsmaschine einsetzten. Leider melded mein Avira Antivirus ständig, das dieses Programm scheinbar eine Malware beinhaltet "HEUR/APC (Cloud)"... siehe dazu auch das erste hochgeladene Foto. Daraufhin habe ich direkt mit Avira Kontakt aufgenommen und die sind der Meinung, dass dort zumindest Teile eine Malware beinhaltet sind. Bitte nicht über die kryptischen Dateinamen im zweiten Bild wundern, das passiert wenn man die Datei an Avira sendet. Nun meine Frage, ggf. auch an den Autor... könnte tas mal bitte jemand überprüfen und /oder bestätigen? Wenn ich die Datei von online Scannern prüfen lasse, kommen unterschiedliche Antworten von OK bis... Virusmeldung. Vielen lieben Dank Torsten
Albert M. schrieb: > Betr. Viruswarung bei der neuen Version von SerielComCNC > > Ich habe eine Mitteilung von einem Anwender erhalten, dass die Software > einen Virus-Alarm auslöst. > Dazu folgendes: > Die Software SerialComCNC ist ab Version 0.9c durch eine > Virtualisierungs-Software vor Hacker, Analyse, Modifikation und > Disassembierung geschützt. > Durch die Virtualisierung und die interne Virtual Maschine können > Codefragmente entstehen, die Ähnlichkeiten mit Virus Signaturen haben > und daher bei einigen Virenscannern in der Heuristik Alarm auslösen, > vermeiden lässt sich das leider nicht. > Ich versichere aber ausdrücklich, dass meine Software keinerlei Virus > enthält. Grüße
Vielen lieben Dank für die Antwort. LG Torsten
Hallo Torsten, wegen der Viruswarnung musst du dir wohl keine Gedanken machen. Wahrscheinlich liegt das an dem von Ulrich eingebundenen Tool für die Zeitbegrenzung der Software. Allerdings habe ich die neueren Versionen nicht mehr genutzt - also Aussage ohne Gewähr. Gruß Einhart
Is this software compatible with Arduino Mega 2560 - I can not access the COM port on my Mega to connect!? Thank you Sorry my German writing is bad! Mike
Will this software run with Atmega 2560 + LCD 12864 + ramps 1.4 A4988.? I tried but my COM port is not getting connected... Mfg, Mike
Angehängte Dateien:
Dear Mike, I had the same problem and just fixed this using the following branch supporting the ATMEGA2560 https://github.com/gnea/grbl-Mega/ Just download the git files as a zip file, remove the previous grbl library from your Arduino library, unzip the new version and put it into the library path. Then use the library function within the Arduino IDE to load the new library. before starting to compile and to upload this to your ATMega2560, just change the MAKEFILE accordingly by romoving the questionmarks starting line 31 of the makefile. Following is how it should look like DEVICE = atmega2560 CLOCK = 16000000L PROGRAMMER = -c avrisp2 -P usb SOURCE = main.c motion_control.c gcode.c spindle_control.c coolant_control.c serial.c \ protocol.c stepper.c eeprom.c settings.c planner.c nuts_bolts.c limits.c \ print.c probe.c report.c system.c sleep.c BUILDDIR = build SOURCEDIR = grbl # FUSES = -U hfuse:w:0xd9:m -U lfuse:w:0x24:m FUSES = -U hfuse:w:0xd2:m -U lfuse:w:0xff:m Now you can compile and upload the hex file using the Arduino IDE. Afterwards SerialComCNC should allow communication with your ATMega2560 board. Hope this helps... Greetings from Berlin (Germany)
Anbei neue Version SerialComCNC 1.0 Alle Beschränkungen entfernt: - Keine zeitliche Beschränkung mehr (bisher 2 Jahre). - Obfuscation, Virtuelle Protection Maschine und Länderbeschränkungen entfernt. Techn. entspricht die Version 1.0 der letzten Version, allerdings mit oben genannten Änderungen. Die Entwicklung wird in den nächsten Wochen fortgeführt. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo Albert, super wieder von dir zu hören. Freue mich schon auf die weitere Entwicklung deines tollen Programmes. Gruß Frank
Sehr schön das alles. Vielen Dank Ulrich
Hallo Ulrich, super, dass sich hier wieder was tut :-) Ich bin gespannt... Gruß Harald
Schön das es weiter geht. Denk mal nach über: eine 2. GRBL Karte, verbesserte Kamera Positionierung und spezielle Makros die man aufrufen kann. Damit man zB. einen Wechsler, 2. Antrieb, nach arbeiten von schräg eingespannten Teilen, ... machen kann. VG, Uli
Beim Thema Erweiterungsideen fällt mir sofort ein Interface in SCC (SerialComCNC) für extern eingespeiste Koordinaten/Steps ein, die z.B. von einer externen Joystick-Steuerung erzeugt werden. Ja, ich gebe zu, dass ich dabei an meinen Joystick-Controller denke http://www.harald-sattler.de/html/joystick-steuerung.htm#Ausblick den ich hier schon mal vorgestellt habe Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Gruß Harald
@Uli Ich warte die Entwicklung für GRBL 1.0 für Arduino Mega ab. Hier das Statement von Cham (Entwickler von GRBL): chamnit commented on 6 Jun I've recently decided that 4th axis will not be available in the 328p version of Grbl. It's a memory and flash constraint. The Mega2560 version of Grbl will be pulled out of this repo and has been placed here. This will contain 4th axis in the near future. Link zum Thread hier: https://github.com/grbl/grbl/issues/1001 Das Kamera-Interface ist ein Thema für sich. Ich habe diverse Interfaces bis hin zu DirectX getestet, alle hatten irgendwelche Probleme. Keines hat alle bei mir vorhandenen 3 unterschiedliche USB-Cams auf Anhieb erkennen können. Es ist schwierig herauszufinden ob es an den zum Teil grottigen Cam-Treibern oder den Interfaces liegt. Zudem steigt die PC-Prozessor Auslastung z.T. auf bis zu 20% an und das bei meinem i5 PC. Bei älteren PCs ist daher der kontinuierliche Cam Betrieb nicht zu empfehlen. Ich versuche aber weiter eine praktikable Lösung zu finden. @Harald Sattler Ich schau mir die älteren Einträge an. Kann aber ca. 2 Wochen dauern bis ich dazu was sagen kann, da ich mich z.Z. um familiäre Angelegenheiten meiner Eltern kümmern muss.
Auf das Mega2560 System wollte ich nicht gerade umsteigen, habe erst seit wenigen Monaten den ganzen Aufbau in einem Gehäuse sauber drin. Bin mit dem 328 auch voll zufrieden bis auf das ich eigentlich noch 2 Achsen mehr brauche. Aber wenn es dann nötig wird muss ich halt alles wieder zerlegen und neu bauen. VG, Uli
Albert M. schrieb: > Ich warte die Entwicklung für GRBL 1.0 für Arduino Mega ab hm...ich habe die Version 1d hier für Mega2560. Es war schon eine Weile her. Allerdings nur für 3 Achen, was ich i.O finde. Der Link dazu finde ich nicht mehr :-(
Ich hab hier ebenfalls den Mega 2560 mit Ramps 1.4 und A4988 Aber wie bekomm ich das alles zum laufen? English kann ich leider nicht und der Beitrag von Torsten K. versteh ich nicht so genau, vor allem was ich mit dieser Makefile anstellen soll. Ich hoffe mir kann jemand helfen, die Software scheint ja echt der Hammer zu sein.
Serial_Connect schrieb: > Aber wie bekomm ich das alles zum laufen? an welche Stelle hast du Problem?
Es fängt ja schon damit an wie ich die Daten auf den Mega 2560 bekomme,habe den grbl Ordner in die Bibliothek vom Arduino Verzeichnis kopiert, bekomme dieses aber nicht auf den Arduino gespielt.
Serial_Connect schrieb: >...habe den grbl Ordner in die Bibliothek vom Arduino Verzeichnis > kopiert, bekomme dieses aber nicht auf den Arduino gespielt. Schritt für Schritt steht doch alles da: https://github.com/grbl/grbl/wiki/Compiling-Grbl
Ich glaube er schrieb weiter oben "...Englisch kann ich leider nicht..." insofn hilft hier der Wiki Link wenig bis garnicht. Nun im grbl Verzeichnis findest Du ein/das Makefile welches Du an die weiter oben in meinem Post geschriebenen Werte anpassen musst. Danach wechselst Du in das Verzeichnis "Examples->Grbl" unterhalb des "grbl" Hauptvzeichnisses und rufst die Datei "grblupload" auf. Hier sind keine Änderungen vorzunehmen. Diese kannst Du nun in der Arduino GUI kompilieren und auf Deinen angeschlossenen Arduino MEGA laden lassen. Vorher musst Du sicherstellen, dass Du die richtige Serielle/USB Schnittstelle ausgewählt hast, an welchem Dein Arduino hängt. Wenn Du alles richtig gemacht hast, wird das grbl Mega Paket kompiliert und dann auf Deinen Arduino geladen. Dann solltest Du den Arduino nach verlassen der Arduino GUI via SerialComCNC (auch hier nach Auswahl der richtigen PC Schnittstelle) ansprechen können, bzw. mit dem links oben befindlichen Button "Connect" eine Verbindung zu Deinem Arduino hstellen können. Have fun...
Wenn man die Sprache nicht so gut kann dann hilft doch meistens einer der Online Übersetzer. Ich muss mich regelmässig mit Chinesisch herum schlagen, kann aber nichts davon lesen oder schreiben.
Hi, grbl in Version 1.1d ist online! Da hat sich ganz schön was getan. https://github.com/gnea/grbl Gruß
Cnc schrieb: > grbl in Version 1.1d ist online! Da hat sich ganz schön was getan. Und was? Da reisst mich nichts vom Hocker. Ein bischen Spindel RPM Gefrickel und Jogging, aber sonst? "Optimizing" hier und da.
Hi, das sehe ich nicht so! -Real-time Overrides: ist wohl das wichtigte Feature für mich. Denn es kommt oft vor, dass man wärend des Fräsjobs feststellt, dass die Feedrate zu gross oder zu klein ist. Erstes kostet den Fräser, zweites die Zeit. -Jogging Mode -Laser Mode -Sleep Mode -Significant Interface Improvements: und da liegt der Haase im Pfeffer, denn dafür müsste SerialComCNC angepasst werden! Gruss Cnc
Hallo Albert M. können wir mit einem Update rechnen? Gruß Cnc
Cnc schrieb: > können wir mit einem Update rechnen? Ja, sobald es von GRBL 1.0 eine Stable Version gibt. Eigentlich wollte ich in diesem Winter zuerst die "Easy Job" Erweiterung zufügen. Da aber noch nicht wirklich klar ist, welche Änderungen für die GRBL 1.0 Version letztlich in SerialComCNC notwendig sind, möchte ich eigentlich bis zur Stable Version abwarten. Cnc schrieb: > -Significant Interface Improvements: > und da liegt der Haase im Pfeffer, denn dafür müsste SerialComCNC > angepasst werden! Nicht so tragisch, was ich bisher bei GRBL 1.0 sehe, dürfte das relativ schnell machbar sein. Gruss Ulrich Albert
Angehängte Dateien:
-
job.jpg
160 KB
Hallo Herr Albert M., vielen Dank für die tolle Software! ein großartiges Projekt mit welchen Tasten auf der Tastaur kann man Getrenntes Setzen des X, Y, Z Nullpunktes den Button Halt, den Button Weiter und Not Stop betätigen? Es macht sich sehr schlecht die Button mit ein Laptop oder Mausschubsen zu betätigen. Freu mich schon auf die "Easy Job" Erweiterung. Gruß Wolfgang
Hallo Ulrich Albert, ich habe mir eine Proxxon MF70 gekauft (Käsefräse??) und möchte diese auf eine CNC Steuerung umbauen, um erste Erfahrungen damit zu sammeln. Eventuell reicht sie sogar für meine Bedürfnisse aus (Flugmodellbau). Ich bin über die Seite „Herberts-Spur N-Projekt“ auf deine HP gestossen, weil ich mir eigentlich die Fräse von Herbert genauso nachbauen möchte. Ich denke, er hat da ein super Preis/Leistungsverhältnis hinbekommen. Ein Arduino Uno R3 Board habe ich bereits gekauft, 3 Motor Stepper Boards TB6560, sowie 3 Nema 17 Motoren sind bestellt. Als CAD Programm habe ich mir ein 2D CAD Programm von Franzi`s installiert, eine Testversion von ESTLCAM habe ich auch auf einen alten XP-Laptop installiert. Und natürlich dein Frontend in der Version 1.0. Ich muss dich an dieser Stelle aber erst mal loben, was du da Tolles für dich und die Allgemeinheit erstellt hast. Einfach klasse! Auf deinen „Easy Job“ freue ich mich besonders, denn ohne diese Verbesserung, muss man schon Aufwand betreiben und 3 Programme bemühen (so die Theorie), auch um nur Kleinigkeiten zu fräsen. Ich habe erst mal die gesamte Software installiert und nur die Arduino Karte über USB verbunden. Erkennen und flashen klappte, die Handsteuerung über die Pfeiltasten klappt auch. Bei ganz einfachen Formenfräsen lief die Automatik auch durch, nur bei etwas komplexeren Formen (Kreis, Radien oder Textgravuren) startete das Programm nicht, unterbrach die Verbindung zum Arduino Uno und verband sich neu. Ich habe es dann nach mehreren Versuchen (nach Achsennullen, Reset, Feed drücken) irgendwie zum Laufen bekommen, weiß aber nicht recht, was ich falsch oder richtig mache. Vielleicht kann mir da mal jemand helfen (bin blutiger Anfänger auf diesem Gebiet). Die bald anstehende Verkabelung (Uno mit Drivern und Motoren) bekomme ich hin, soweit habe ich mich über die Foren eingelesen. Ich würde nur gerne später einen mechanischen „Not-Aus“ anschließen, weiß aber nicht, an welche Pins vom Uno ich diese legen muss. Kann mir da auch jemand mal einen Tip geben… Ach ja, reicht eigentlich ein 12 V Netzteil mit 10A aus, um die gesamte Steurung zu betreiben? Gemäß Datenblatt der Motoren sollen diese sowieso nur 3,1V brauchen ?!? Vielen Dank im Voraus Sven
Hi, >unterbrach die Verbindung zum Arduino Uno und verband sich neu. Wichtig ist ein gut geschirmtes USB Kabel. Geschirmte Motorkabel können auch nicht schaden. Sowie getrennte Stromversorgung für Motortreiber und Arduino. >Ach ja, reicht eigentlich ein 12 V Netzteil mit 10A aus Sollte dicke reichen für Nema 17 / 23 Motoren. Allerdings wäre eine höhere Spannung besser um den nötigen Strom schneller in die Motoren zu bekommen. Die Treiber können ja meistens 35V. Vergiss das Datenblatt der Motoren, Du stellst den max. Strom in den Treibern ein, wird der Motor heiß war es zu viel und drehst den Strom wieder etwas runter.
Danke Sven, Auf den Motortreibern stelle ich aber nur die Stromstärke ein (A) und nicht die Spannung, korrekt?
>Auf den Motortreibern stelle ich aber nur die Stromstärke ein
Korrekt
Man fängt mit einer kleinen Stromstärke an und guckt wie sich die
Mechanik verhält (Schrittverluste). Und erhöht den Strom so weit wie
nötig damit die Mechanik gut arbeitet.
Hallo Albert, Grbl 1.1 (Master) ist online! Wir freuen uns schon auf die neue kommende Version. Gruß Cnc
Cnc schrieb: > Grbl 1.1 (Master) ist online! Danke für die Info, hatte ich noch nicht bemerkt! Mehr über die neue GRBL Version 1.1 gibt es hier: https://github.com/gnea/grbl/wiki Da gibt es so viel Neues, das muss erst mal verdaut werden. Wie auch immer, gerade habe ich SerialComCNC soweit upgedatet, dass es mit der neuen GRBL 1.1e Version zumindest problemlos läuft. Die ganzen Feinheiten und neuen Möglichkeiten werde ich jetzt mal in Ruhe angehen :) Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo, Ich bräuchte dringend Hilfe, wo ich am Arduino eine Reset Schalter und einen Werkzeuglängensesor anschließe. Oder funktioniert das gar nicht?
Der Reset-Schalter kommt an den Reset-Pin, wo Du den findest kommt auf Deinen Arduino an. Bei dem Sensor kommt es auf die Art bzw den Anschluß an. Erzähl mal ein bischen mehr.
Hallo Albert! Danke für deine ganze Arbeit, dein Programm ist echt klasse. Dickes LOB! Albert M. schrieb: > Wie auch immer, gerade habe ich SerialComCNC soweit upgedatet, dass es > mit der neuen GRBL 1.1e Version zumindest problemlos läuft. Gibt es die Version auch zum Download? Sven P.
Hallo Won Ko, Ich habe den Uno R3 Reset Pin habe ich gefunden, über der Analogen Pinleiste. Geht die Funktion dann mit dem Verbinden auf Masse?
Sven P. schrieb: > Albert M. schrieb: >> Wie auch immer, gerade habe ich SerialComCNC soweit upgedatet, dass es >> mit der neuen GRBL 1.1e Version zumindest problemlos läuft. > > Gibt es die Version auch zum Download? Der Download würde Dir z.Z. nicht viel helfen, da Du damit die erweiterte GRBL 1.1e Funktionalität noch nicht benutzen kannst. Die neuen GRBL Features bedingen eine Änderung/Erweiterung der Bedienoberfläche. Momentan habe ich nur den internen Command Interpreter soweit geändert, dass die GRBL 1.1e Version damit klaglos läuft.
Angehängte Dateien:
-
SCC_2.0.png
69 KB
Hier eine Vorschau auf das neue Layout für SerialComCNC 2.0 angepasst auf GRBL 1.1e. Mit den zusätzlichen Buttons in der Prozess Anzeige lässt sich nun in Realtime während der laufenden Bearbeitung der Feed (Vorschub) sowie der Rapid-Feed verändern und damit die programmierten Feeds überschreiben. Beim Feed bei jedem Klick um +/- 10%, sowie wieder auf 100% rücksetzen. Beim Rapid Feed ist eine Reduzierung auf 50% oder 25% möglich. Der programmierte Feed Fs (Feed soll) und der tatsächliche Feed (Fi Feed ist) werden in den Realtime Statusanzeigen laufend aktualisiert. Eine Anpassung an die neuen Jogging Möglichkeiten von GRBL 1.1e folgt. Zusätzlich erwäge ich die Ansteuerung einer weiteren seriellen Schnittstelle mit den Prozess-Parameteren, so dass eine Anzeige direkt an der Fräse ohne grossen Aufwand für jeden möglich ist. Ich verweise da mal auf die günstigen intelligenten seriellen Touch Displays von NEXTION. Gruss Ulrich Albert http://www.serialcominstruments.com/
Angehängte Dateien:
Hallo Albert, das sieht ja schon mal gut aus :-) Hast du den schon mal in Erwägung gezogen einen probe Button und home Button anzulegen, mit der Möglichkeit die Offsetwerte zu speichern?? Mal abgesehen davon das meine Fräse sich noch im Aufbau befindet und nichts ausser der Steuerung schon Funktioniert (auch der WZLS(eigenbau)) :-) , bin ich schon sehr zufrieden mit deinem Tool. Hast du schon ein Display in Benutzung? Wie kann ich mir das Vorstellen? Sendet das Programm die Daten an das Display? Das wäre mal Klasse, aber dann müsste mann doch noch einen Usb-Hub in der Fräse einbauen?! Oder zweites Kabel an den PC? :-) Sorry für die Fragen, aber ich bin halt ein Bastelnoob :-) Was ich habe ist noch nicht viel siehe Fotos, das Material für die Mechanik ist noch unterwegs :-) Sven
Hallo Sven, ich vermute mal, dass die Anbindung des Touch-Displays direkt über den Arduino via SPI (Two-Wire Interface) erfolgt (das wäre zumindest einfach machbar) ... Grüße Thomas
Die Anbindung des Nextion Displays ist über ein 2 Euro USB-TTL Wandler Modul realisiert. Die Kommunikation ist string-orientiert, die optionalen HEX-Codes vom Display werden nicht genutzt. Das Nextion Display ist programmierbar und beliebig konfigurierbar über den kostenlosen Nextion Editor. SerialComCNC schickt dem Display die Werte mit vorangestelltem Objekt Identifikator. Die entsprechenden Objekte auf dem Display sind dabei die numerischen Anzeigefelder. Das Layout der Anzeige kann im Editor frei designed werden. Einfach mal den Editor downloaden und mit rum spielen, geht auch ohne angeschlossenes Display über die integrierte Simulation. Die Displays kosten zwischen 12 Euro und 70 Euro je nach Grösse und Bezugsquelle. Ich selber benutze ein 2.4", 3.2" und ein 3.5" Display. Das 3.2" dabei mit integrierter RTC und GPIOs. Nextion Display Seiten: https://www.itead.cc/display/nextion.html Nextion Instruction Set: https://www.itead.cc/wiki/Nextion_Instruction_Set Und hier noch ein Video mit meinem ersten Display Test. Es ist dabei kein MC an das Display angeschlossen, alle Aktionen bedient das Display selbst: https://www.youtube.com/watch?v=59U_KtUAX9Q Ein Standard Display Layout für die Koordinatenanzeige füge ich der kommenden Version von SerialComCNC bei. Dieses kann dann einfach auf das Display geladen werden. Damit ist das Display sofort betriebsbereit ohne dass der Anwender irgend etwas programmieren muss.
Hallo Albert, super! Das ist ja noch einfacher als ich gedacht hatte - von diesen Nextion Displays hab ich bis jetzt noch nichts gehört, aber die scheinen ja geradezu ideal für den Einsatzweck - klasse! Und übrigens nochmals vielen Dank für Deine Mühe und das suuper Programm, das Du auf die Beine gestellt hast und uns hier einfach so zur Verfügung stellst. Viele Grüße Thomas
Hallo Albert, ist das die Frontendversion im Beitrag vom 22.09. die mit der Grbl-Version 1.1e zusammenarbeitet? Vielen Dank Hans
Hallo Hans, das Frontend für die GRBL 1.1e Version wird ähnlich wie in meinem Beitrag vom 20.12.2016 gezeigt. Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Die neue Version von SerialComCNC wird zusätzlich (wie oben beschrieben) ein zweites serielles Interface zur Kommunikation mit einem Nextion Touch Display haben. Damit lassen sich die wichtigsten Prozess-Parameter direkt an der Fräse anzeigen. Geplant ist demnächst auch eine direkte Bedienung über das Nextion Display, wie Start, Stop, simples Jogging usw. Gruss Ulrich Albert
Neues zum Bedienen und Monitoring über ein serielles 3.5" Nextion Touch Panel für die kommende Version von SerialComCNC. Die Bilder oben zeigen die bereits vorhandenen Pages auf dem Display.
Feine Sache, Ulrich. Habe gleich mal ein passendes Nextion geordert. Danke für deine Arbeit und alles Gute für 2017
Anbei neue Version SerialComCNC 2.0 Alpha zum Vorabtest Change Log V2.0 Alpha --------------------- Update auf GRBL 1.1e - Achtung: Diese Programm-Version funktioniert nicht mehr mit GRBL Versionen kleiner 1.0 - Das Hex-File für GRBL 1.1e liegt der Software bei und kann mit dem ebenfalls beigefügten XLoader auf einen Arduino Uno direkt geflasht werden. Wichtig: Bitte die Konfiguration auf $10=0 einstellen. (Die komplette Konfiguration kann mittels $$ angezeigt werden) Implementierte neue Funktionen - Realtime Feed Korrekturen (Process Anzeige Buttons F) - Realtime Rapid Feed Korrekturen (Process Anzeige Buttons Fr) - Zusätzliche Realtime Feed Anzeige im Process Display. Add On: Nextion Touch Display (Status z.Z. Experimental) - Ansteuerung eines seriellen Nextion 3.5" Display über einen zusätzlichen virtuellen Com Port. Konfiguration über Menue Einstellungen / System. Das Display benötigt lediglich ein billiges TTL-USB Wandler Modul, sowie eine Versorgung von 5V DC mit ca. 150mA. Das benötigte HMI File sowie die Fonts sind beigefügt und können einfach über den kostenlosen Nextion Editor auf das Display geflasht werden. Damit ist das Display betriebsbereit. Besitzer von Nextion Displays in anderen Grössen als 3.5" können mittels Nextion Editor das Layout einfach anpassen. - Funktionsfähig ist z.Z. die Menueseite "Monitor" mit folgender Funktionalität: - Realtime Anzeige von X, Y, Z, Feed - Starten eines Fräsfiles - Halt und Weiter während des laufenden Fräsvorgangs - Not Stop - Feed 100%, Feed um jeweils 10% erhöhen, Feed um 10% verringern Die Hilfe wurde noch nicht angepasst. Hier gibt es, wenn auch ein schlechtes, Video vom Betrieb: https://youtu.be/Gx5W_z9Vbsk Gruss Ulrich Albert http://www.serialcominstruments.com/
Anbei neue Version SerialComCNC 2.0.1 Alpha Video hier: https://youtu.be/A4_mC6n_ajc Change Log V2.0.1 Alpha ----------------------- SerialComCNC - Interface für Nextion Display auf die Main Page verlegt - Kommunication mit Nextion Display erweitert Nextion Display - Jogging Page nun funktionsfähig - Zugehöriges HMI Display File upgedatet und beigefügt Download für den kostenlosen Nextion Editor hier: https://nextion.itead.cc/download.html Dieser kann auch ohne Display genutzt werden mittels integriertem Simulator. Gruss Ulrich Albert http://www.serialcominstruments.com/
Hallo, da ich halt mehr Achsen brauche als die XYZ habe ich bei den Jungs von openPnP eine grbl Variante (0.9g) gefunden die zusätzlich die C Achse hat. Jetzt die Grosse Frage was würde Passieren wenn ich diese Variante an Deine Software dran hängen würde und im G-Code die C-Achse benutzen würde. Um die C-Achse zu bekommen wäre es nett wenn Du so was vorsehen könntest. Kann ja ein/ab-schatbar sein. Den grbl Code würde ich mir selber zusammen stellen damit das in der 1.1 drin wäre. Noch etwas Kritik: Die ganzen netten Display spielchen bringen übrigens nicht viel wenn der Rest (Toolchange, Autopositionsfindung / Werkstückausrichtung durch Kammera, 2. grbl karte, ...) noch nicht da ist. Das ist zwar nur meine Meinung aber mir und dem Projekt würde es glaube ich mehr bringen. VG, Uli
Uli schrieb: > Noch etwas Kritik: > Die ganzen netten Display spielchen bringen übrigens nicht viel wenn der > Rest (Toolchange, Autopositionsfindung / Werkstückausrichtung durch > Kammera, 2. grbl karte, ...) noch nicht da ist. > Das ist zwar nur meine Meinung aber mir und dem Projekt würde es glaube > ich mehr bringen. Dann bist Du hier bei meinem Projekt falsch. Das ist ein Projekt für den normalen Hobby Fräser, wenn Du eher Profi Features sucht musst Du Dich anderswo umsehen und dafür zahlen. Nach meiner langen Erfahrung hier im Forum kann ich dazu nur eins sagen: Diese Software und auch die anderen Projekte erstelle ich zu MEINER eigenen Erbauung und Zeitvertreib und teile sie hier. Ich implementiere Features die ICH gerade brauche oder die MIR Spass machen. Wenn das auch anderen nützlich ist freue ich mich. Anpruchsdenken von Anwendern ist hier jedoch völlig daneben.
Angehängte Dateien:
-
Fehler.png
180 KB -
Fehler1.png
240 KB
Hallo Albert, Ich habe ein Problem mit deinem Programm. Wenn ich die Kamera Starten will Stürzt dein Programm ab. Treiber sind alle Aktuell, die Kamera ist neu und funktioniert einwandfrei, nur eben nicht mit deinem Programm. Egal ob Version 1.0 oder 2.1. Hast du einen Tipp? An bei mal die Fehlermeldung. Sven P.
Es spricht doch nichts dagengen das Du und andere das Display super finden. Und Du deine Freizeit dafür einsetzt und uns daran teilhaben läst. Ich selber habe mir gerade auch eins gekauft. Ist ein schönes Spielzeug nur es hilft mir nicht wirklich weiter! Zumal der PC gleich daneben steht. Ich habe 3 Fräsen alle liefen mit MACH3, alles Hobby! Ob da überhaupt eine Kammera dran arbeitet habe ich noch nie getestet. Meine Shapeoko habe ich aber auf grbl wieder umgebaut. Und da brauche ich inzwischen halt etliche Sachen mehr wie früher. Das wichtigste ist halt die dumme 4. Achse. Zur Zeit löse ich das in dem ich anhand der Spindel Richtung und Speed die 4. Achse steuere, das ist aber umständlich. VG Uli
@Uli Das Problem bei speziellen Erweiterungen ist die Kompatibilität zu den Standard GRBL veröffentlichung. Ich will davon nicht abweichen. Wenn Du jedoch in der Lage bist GRBL selbst zu ändern, dann ist es wichtig das Format des Status String, der nach der zyklischen Eingabe von "?" von GRBL ausgegeben wird nicht zu ändern. Damit bleibst Du dann erst mal kompatibel zu meiner Software. Ich lasse von GRBL die Work Koordinaten, sowie danach den Feed ausgeben. Das hat sich ja in GRBL 1.1 geändert.
Sven P. schrieb: > Wenn ich die Kamera Starten will Stürzt dein Programm ab. Dazu ist im Thread schon von anderen und mir einiges geschrieben worden. Vielleicht hilft es Dir.
Angehängte Dateien:
-
Fehler2.png
74 KB -
Fehler3.png
71 KB -
Fehler4.png
72 KB
Hmm, Kamera ist jetzt erstmal egal. Ich habe da noch andere Probleme siehe Bilder: Die Rückmeldung scheint nicht mehr zu funktionieren. Im Monitor sehe ich nix mehr. Auch Spinnt ab und zu die X-Achsen Anzeige da fehlt dann die 0 vor dem Punkt. Fahre ich Manuell(G-Code eingabe) bewegen sich alle Achsen, nur Anzeigen tut er nix mehr. Ich habe kein Display angeschlossen, liegt das daran? Sven P.
Hallo Sven, sollte daran liegen. Wichtig: Bitte die Konfiguration auf $10=0 einstellen. Von Albert beschrieben. Gruß Frank
Angehängte Dateien:
-
GRBL.jpg
110 KB
Hallo Sven P. Ich hatte das selbe problem ... Der Gute Albert , dem ich sehr dankbar für seine Arbeit bin . erwähnte folgendes : Update auf GRBL 1.1e - Achtung: Diese Programm-Version funktioniert nicht mehr mit GRBL Versionen kleiner 1.0 Mir viel auf das ich immer noch auf 0.9 war und dabei deine gleichen fehler erhielt . Trotz upload der hex datei von albert . Fix GRBL Datei gedonloadet und via Arduino IDE Geflascht seriellen monitor an und sihe da 1.1 und Fehlerfrei Ich hoffe ich konnte helfen
Angehängte Dateien:
-
Autolevel.jpg
79 KB
Autoleveling wie im Bild zu sehen (andere freie Software) Wie macht ihr das habt ihr dazu ein Macro , da mir SerialComCNC ansonsten super gefällt . Wäre Dankbar für Anregungen . Schöne grüße und guten rutsch Sven W.
Sven.W schrieb: > Autoleveling wie im Bild zu sehen (andere freie Software) > Wie macht ihr das habt ihr dazu ein Macro Ich denke darüber auch schon einige Zeit nach. Das Problem dabei ist eher die mechanische Seite. Die üblichen Höhentaster sind mehr auf harte Materialien ausgelegt und drücken durch die zu starre Feder im Innern die zu vermessende Platine nach unten durch, so dass das Messergebnis verfälscht wird. Vielleicht kennt jemand einen bruchbaren Taster, möglichst mit 3mm Schaftdurchmesser. Ich würde mir da gerne etwas ganz Neues konstruieren, etwa ein kleines Rad welches mittels Fräse über die Platine geführt wird und dabei die Höhenänderung in der leichtgängigen, flexiblen Vertikalachse vermessen wird. Nur so eine Idee. Oder hat schon mal jemand versucht die Platine mit Unterdruck gerade auf die Auflage zu bekommen? Eure Vorschläge würden mich interessieren, das Programmtechnische ist nicht das Problem. Ansonsten ist die Entwicklung für den Anschluss eines Nextion Displays jetzt soweit komplett fertig. Die noch fehlende GCode Eingabe über das Display funktioniert nun. Die neue Version dazu gibt es in der nächsten Woche.
Hallo erstmal. Zu aller erst mal ein RIESEN Lob an Albert. Was du da so alles Entwickelst, und es auch noch für uns bereitstellst, ist schon Genial. Das Nextion Display ist seit heute auch angekommen und läuft. Zur Autoprobe: Schau mal bei Gelegenheit nach BLTouch. Viele verwenden den für das Bedleveling beim 3D-Druck. Hier mal ein Video welches die Funktion zeigt. https://www.youtube.com/watch?v=3bPx5PDBLzc Gruß Detlef
Frank schrieb: > Wichtig: Bitte die Konfiguration auf $10=0 einstellen. > Von Albert beschrieben. Danke Frank, daran lag es. Allen einen guten Rutsch ins neue Jahr!! Grüße aus Berlin Sven P.
Hallo, zum Thema Autolevel Schau dir doch mal an wie das Christian Knüll bei Estlcam macht: https://www.youtube.com/watch?v=ApBfHW7AhsM https://www.youtube.com/watch?v=bhZdbgM6S70 Ich glaube bCNC macht das ähnlich https://www.youtube.com/watch?v=Z59BkvBOx5A Und noch ein anderer: https://www.youtube.com/watch?v=kzXzvcUAuus Mit diesen Methoden hat man keinen zusätzlichen Hardwareaufwand. Wäre super wenn du das integrieren könntest mit dem Autolevel. Danke nochmal für dein super Programm und ein frohes 2017 an alle. Max
Hallo Albert , da ja nun schon einiges genannt wurde ....in BCNC mache ich es halt so ,mit den Platienen, ein kontackt am fräser, den anderen an der Platiene, Klabt super .... bei Holz und Ähnlichen habe ich mir einen taster seber gebau, ein Stück Pom ,wo im innen ein alter Gravierfräser drin ist der dann auf einen drucktaster trifft .....bisher nur gute erfahrungen damit gemacht . Wenn Du magst kannst Du es ja Softwahremäßig einfügen , ich Denke es sind genügend freiwillige zum testen ... werde Die Tage vom Tasten noch Bilder hochstellen .
Danke für alle Antworte für eine event. neue Leveling Funktion. Die simple Methode möchte ich nicht anwenden, da das Leveling auch für nicht leitende Oberflächen arbeiten soll. Interessant ist der von Deltef genannte Taster BLTouch. Der Software Aufwand ist doch ziemlich umfangreich. Ich würde die Topologie des Objektes auf Quadrate reduzieren, den GCode untersuchen wo welche Quadrate gequert werden und falls die vom GCode vorgegebene Vektoren Quadratkanten überqueren den Vector im GCode jeweils aufteilen und in einer weiteren GCode Zeile mit geänderter Höheninformation fortführen. Das machen wohl alle so, die Levelling in ihrer Software anbieten. Bei geradlinien Bewegungen scheint es problemlos, inwieweit das auch für Kreissegmente zutrifft müsste ich untersuchen (Böses Beispiel Spirale, die mehrere Topologie-Quadrate schneidet, auch wieder die Ursprungsquadrate). Ich werde mir jetzt erst mal einen BLTouch Taster bestellen.
Hallo Albert , Ich habe mir den Taster mal angeschaut ... er besitzt 5 Anschlüße 3Pin: braun (-,GND) rot (+5V) orange (Kontrol Signal) 2Pin Schwarz (-,GND) weiss (Zmin) GND 5V wären klar Zmin eventuell A5 bein arduino aber das Krontrol Signal ?! dazu müsste er ja auch noch daten emfangen um den Taststift zu heben und senken . Bisher nur gefunden das es in der marlin firmenware bei den 3D Druckern verwendedt wird GRBL wüste ich nicht wie .... Ansonsten schönes teil .
Wäre so ein Taster nicht besser ? http://www.robocnc.nl/?p=1699 Der wäre ja auch leicht herzustellen ... Schöne grüße
Hallo, erst einmal wünsche ich ein gesundes + erfolgreiches neues Jahr. Sven.W schrieb: > GND 5V wären klar Zmin eventuell A5 bein arduino aber das Krontrol > Signal ?! > dazu müsste er ja auch noch daten emfangen um den Taststift zu heben und > senken . > Bisher nur gefunden das es in der marlin firmenware bei den 3D Druckern > verwendedt wird GRBL wüste ich nicht wie .... Bei den 3D-Druckern wird für die Leveling Funktion (Pin heben/senken) ein PWM-Signal wie für ein Servo im Modellbau benutzt. Einige Leveling-Systeme benutzen auch ein Modellbauservo zum auf-/abschwenken eines Endschalters. Bei der PWM wird eine Impulslänge von ca. 1mSek.(links)--> 1,5mSek.(mitte)--> 2mSek.(rechts) generiert.siehe: https://www.mikrocontroller.net/articles/Modellbauservo_Ansteuerung Gruß, Manfred
OK das habe ich verstanden, habe selber mal einen Servo mit Hilfe von Arduino und einen Poti betrieben ... Habe mir mal das pinout von Grbl angeschaut A4 wäre noch frei , den müsste man dann mit einem der der Limit X oder Y Achse tauschen um einen freien Port fürs PWM zu bekommen, und dann noch in GRBL Einfügen ...um den Taster zu benutzen ... Aber das ist Software wovon ich nix verstehe da lass ich mich gerne überraschen was Albert Zaubert .... Und ich betone noch einmal eine super Software und ganz herzlichen dank für die Super Arbeit hier
Albert M. schrieb: > Die simple Methode möchte ich nicht anwenden, da das Leveling auch für > nicht leitende Oberflächen arbeiten soll. Interessant ist der von Deltef > genannte Taster BLTouch. Hallo Albert, so als Gedanke nebenbei... Vielfach wird Leveling doch sicher bei der Platinenherstellung verwendet. Immanent hat man hierbei die leitende Oberfläche zur Abtastung ohnehin zur Verfügung und der Zusatzaufwand in Sachen Hardware für perfekte Platinen würde sich mit einer Level-Funktion in deiner Software auf Null belaufen. Das benötigte Signal wird in Form des Probe-Tasters auch schon passend durch den Arduino durchgeleitet. Insofern würde ich mir die neue Funktion in deiner Software parametrierbar wünschen, also einfaches Tasten gegen Masse mit geringer Vorschubgeschwindigkeit für die Leiterplattenfraktion und für die Künstler unter uns (die beliebige, auch nichtleitende Oberflächen mit Gravur verschönern wollen) die Option mit BLTouch. Nur zum drüber nachdenken :-) Danke! Gruß Harald
Angehängte Dateien:
-
Scc_Nextion.jpg
220 KB
Anbei neue Version SerialComCNC 2.0.2
Change Log V2.0.2
-----------------
Wichtig: Alle SerialComCNC Versionen ab Version 2
benötigen GRBL ab Version 1.1e
Nextion Touch Display Erweiterung
- GCode Eingabe Page funktionsfähig.
Damit ist nun die Steuerung über das Display voll einsatzbereit.
- Der über die Display-Tastatur eingegebene GCode wird beim
Drücken des Enter Buttons an SerialComCNC gesendet und
sofort ausgeführt, sowie dort im Process Monitor protokolliert
und im Fehlerfall der entsprechende Error-Code angezeigt.
Eine Fehler-Rückmeldung zum Nextion Display erfolgt z.Z. nicht,
könnte ich aber nachrüsten.
- Die Bezeichner für GCode Kreiselemente (I,J,K) sind auf der
Display Tastatur nicht aufgeführt, weil sich diese nicht
für die ad hoc Eingabe sonderlich eignen. Sollte ein
dringlicher Wunsch danach laut werden, kann ich die
3 Bezeichner gerne einfügen.
- Das notwendige HMI Display File und die Font Files sind
im Unterordner Nextion zu finden.
Wen es interessiert, hier einige Infos über die "Innereien":
Die bidirektionale Kommunikation zwischen Nextion Display
und SerialComCNC geschieht in Klartext (ASCII).
Richtung SerialComCNC wird die Übertragung vom Display mit #
als Startzeichen eingeleitet und mit < beendet.
Richtung Nextion Display wird kein Startzeichen benötigt,
das Ende der Übertragung verlangt 3x ASC255 (3x Hex FF).
SerialComCNC kann auf alle Display Objekte anhand ihres
internen Namens und Property direkt zugreifen.
Die komplette Menue- und Button Logik geschieht auf dem
Display selbst in einer BASIC ähnlichen Sprache und bleibt
auch nach Ausschalten der Versorgungsspannung erhalten.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
Vielen Dank ! Es macht von Version zu Version mehr Spaß. Möge es dir beim Programmieren auch so gehen, lieber Ulrich
Angehängte Dateien:
-
CIMG1783.JPG
230 KB -
CIMG1784.JPG
230 KB
Wie Versprochen mein Taster der als Öffner fungiert ... Ca 25 mm in durchmesse und direkt in der Spindel einzusetzen wenn ich damit eine Platine fräse ist das Super die feder ist nur dazu da um den Taster in Position zu halten .. Schöne grüße
Hallo Sven! Ah, Öffner! Das heißt, wenn Albert so einen Taster und einen BLTouch und die Sparversion für Leiterplatten unterstützen wollte, müsste er zumindest die Polarität parametrierbar machen... Du schreibst, "wenn ich damit eine Platine fräse"... Welche Software(kette) verwendest du bis dato? GrblHeightProbe2[[https://github.com/martin2250/GrblHeightProbe2]]?
Harald S. schrieb: > Welche Software(kette) verwendest du bis dato? > GrblHeightProbe2[[https://github.com/martin2250/GrblHeightProbe2]]? Hallo Harald , GrblHeightProbe2 angeschaut ist mir aber zu aufwendig da BCNC dieses enthält Da ich bisher nur klein teile gemacht habe fürs Arduino , wurde die Zeichnung mit Fritzing erstellt und die Gerber/Exelon Datei dann mit Flatcam in Gcode umgesetzt, Gefräst mit BCNC wegen dem Leveling , obwohl mir eigentlich SerialCom lieber ist , . Das Öffnen bzw Schießen säst sich aber in Grbl einstellen unter $6=0 schließen $6=1 Öffnen Beste grüße Sven
Hi, Ich wollte ebenfalls das schoene Programm von Albert M. verwenden. Leider tritt bei mir exakt der gleiche Effekt auf, den User Sven am 26.2.2015 zum ersten Mal beschrieben hat. Das Programm laesst sich initialisieren, verbindet sich korrekt und verschluckt sich dann. Ich kann G-code Kommandos an den Arduino schicken, es kommt aber keine Antwort mehr. TX und RX LEDs blinken im Takt der Statusabfrage. Nach reproduzierbar exakt 60sec scheint ein Puffer ueberzulaufen/Timeout zuzuschlagen und das Programm bricht ab. GRBL 1.1e, SerialCNC v2.02, Windows10 Home V1607, DELL Laptop. Mir scheint, das Problem ist nicht ganz so selten. Vermutlich geben viele User nach dem ersten Versuch auf... Gibt es inzwischen eine Loesung? Regards Henry
Ich vergass noch: Arduino IDE/Monitor 1.6.9 USB Driver Version 1.2.3.0 Programm ausgefuehrt mit/ohne Administratorberechtigung. Mit dem Serial Monitor des Arduino laesst sich GRBL ohne Probleme ansteuern. Alle Parameter in GBBL auf Default gesetzt, $10=0. Henry
Hi >Leider tritt bei mir exakt der gleiche Effekt auf, den User Sven am >26.2.2015 zum ersten Mal beschrieben hat >Gibt es inzwischen eine Loesung? Da Du das Problem anscheinend immer noch hast, scheint es leider noch keine Lösung zu geben... Die Lösung für mich war: >Ich bastel mir nun meinen eigenen GRBL-Sender: https://github.com/svenhb/GRBL-Plotter Gruß Sven
Hallo zusammen, erst mal vielen Dank an Albert für die Arbeit! Ich beobachte und benutze die Entwicklung schon fast seit Anfang an. Aber leider läuft das Programm seit Version 0.9f und GRBL 0.9 nicht mehr einwandtfrei. Ich habe mit den selben Problemen wie viele andere hier zu kämpfen: - Kommunikation - Webcam - uvm. Ich benutze unter anderem auch bCNC, GRBL-Plotter, Candle und Estlcam. Jedes hat so seine Vor - und Nachteile. Vor kurzem bin ich bei meiner Suche nach weiteren Frontends auf ein sehr gut funktionierendes (auch WebCam und Probe) gestossen und möchte es gerne mit euch teilen. Es heisst einfach nur CNC und wird von Cheton Wu entwickelt. Hier die Beschreibung: https://github.com/cheton/cnc/wiki/Desktop-App Und hier der Download: https://github.com/cheton/cnc/releases Viel Spaß und viele Grüsse Wolf
Nachtrag: Ich habe das von Wolf angefuehrte Programm mal äusprobiert mit unveraenderter Arduiono Firmware/Treiber. Spasseshalber habe ich das billigste chinesische USB Kabel verwendet, das ich finden konnte. Ergebnis: Mehrere Stunden Betrieb mit einem 1000+ langen G-Code File ohne Stoerung. Auch auf meinem alten XP Rechner lief das Paket. SerialComCNC scheint ein Problem in der Kommunikation zu haben. Regards (aus Silicon Valley) Henry
Erratum: Der alte Computer war Win7, nicht XP. Das Programm laeuft nicht unter XP. Henry
Schade das CNC nicht unter XP läuft. Hatte mich schon gewundert warum ich ständig eine Fehlermeldung bekommen hatte. Und nur dafür einen alten PC zu ersetzen ist mir dann doch zu Blöd. SerialComCNC wird bestimmt den Fehler auch bald nicht mehr haben, wobei der mir noch nicht untergekommen ist. Peter
@Sven (GRBL-Plotter) Hast Du auch irgentwo ein Forum? Du hast zwar einiges drin was mir helfen würde aber einiges auch so gemacht das es für mich nicht brauchbar ist. Es gibt auch einiges was mich schon nach 20sec genervt hat. SerialComCNC ist zwar auch nicht perfekt und ich bräuche echt dringent eine 2 GRBL Karte da dran, aber genervt hat mich hier noch nie was. VG, Peter
Hallo Peter, nein ein Forum hab ich (bisher) nicht. Aber man kann ja im GitHub 'Issues' erzeugen die ich dann bearbeiten würde. Allerdings muss ich feststellen dass meine weiteren Funktionswünsche (für mich) einen immer größeren Aufwand bereiten. Parallel dazu stelle ich fest das Estlcam inzwischen eigentlich alles kann was mir nützlich erscheint (z.B. SVG-Import) - ausser der echten GRBL-Unterstüzung (immerhin wird nun das GRBL-Pinlayout unterstützt), die Estlcam Firmware habe ich bisher aber noch nicht getestet. >Es gibt auch einiges was mich schon nach 20sec genervt hat. Hm, das ging ja schnell. Wenn es was einfaches ist könnte ich evtl. Abhilfe schaffen... >SerialComCNC ..., aber genervt hat mich hier noch nie was. Wenn es denn bei mir korrekt laufen würde... Mich nervt, dass man gefühlt zigmal ok drücken muss bis man arbeiten kann. Da finde ich mein Auto-Reconnect echt toll ;-) Gruß Sven
Sven da fällt mir sontan ein: Frei herum fliegende Fenster, die übereinander lagen und ich suchen musste. SVG Import dein Test Bild-> Speicher zu klein???? Kann bei 4Gb RAM nicht sein! Da waren noch einige Punkte an die ich mich jetzt nicht mehr so genau erinnere. Das man gefühlt zigmal ok drücken muss ist mir nicht aufgefallen, oder ich bin in der Bezieung unempfilndlich. Aber was mir gestern abend aufgefallen ist, ist das mir die Verbindung 3 mal abgebrochen wurde. Ich denke nun gehöre ich auch zu denen mit dem Serial Bug. VG, Peter
Moin, erstmal vielen Dank an Albert für seine Bemühungen. Software ist großee Klasse!!!!! Nun zu meinem Anliegen: Komme seit gestern nicht mehr auf meinem Nano ins $$ was kann das sein? Hab mir einen neuen zugelegt da geht es wieder! Hoffe es weis einer was?
Hallo Klaus, Gib mal im Befehlsfeld $10=0 ein. Danach einmal disconnect und wieder connect. Dann solltest du mit $$ wieder alles sehen. Gruß Detlef
moin Detlef, danke für die schnelle Antwort. Habs probiert geht nicht. Hab in neu geflasht, nochmal probiert wieder nix. Glaub ist defekt!!! Klaus
moin, ich schon wieder. Beim neuen GBRL sind im $$ viele neue Angaben. Kann mir einer sagen, was die neuen alle bedeuten. Hab noch keine neue Liste dafür gefunden! Klaus
>Hab noch keine neue Liste dafür gefunden! Steht alles im Wiki: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration
Hallo Albert/all, verwende SerialComCNC testweise um ins Thema CNC reinzukommen, sieht sehr gut aus, aber kaempfe etwas mit der manuellen Steuerung. Benutze Arduino Uno (Grbl 0.9j), TB6560 treiber und Nema17 motoren. Mit'grbl controller' kann ich die motoren ansteuern (manuell, x, y, z und verschiedene 'schrittweiten)), unter SerialComCNC hab ich den Dreh noch nicht raus. Deshalb ein paar Fragen (und Bitten) hier: a) sind fuer SerialComCNC besondere grbl settings ($$) noetig? In der Doku nichts gefunden hierzu. b) gibt es etwas Besonderes zu beachten bei der manuellen Steuerung fuer SerialComCNC? Besondere Initialisierung o. ae. wie der anfaengliche Hinweis (Nullpunkt/Feed)? Falls ja, waere etwas ausfuehrlichere Doku hilfreich! c) hab auch versucht ein einfaches 'Testprogamm' under SerialComCNC laufen zu lassen, aber nach den ersten Kommandos scheint nichts mehr zu passieren. War irgendein vermeintlich einfacher g-code aus dem web (Rechteck, Kreis, Schriftzug etc.), aber vermute eher das Problem ist allgemeiner Natur weil die manuelle Steuerung auch nicht klappt. Hat jemand ein einfaches, kurzes g-code Beispiel mit dem ich SerialComCNC und mein setup mal testen kann? Danke schonmal fuer alle Hinweise und Tipps! Gruesse, Martin
Sorry Leute, zur Zeit bin ich Out Of Order. Ein echter Mann kennt keinen Schmerz habe ich gedacht und meine Bauchschmerzen 3 Tage ertragen. War wohl zu lange. Nach einer nächtlichen Not-OP wegen durchgebrochenem Blinddarm bin ich nun gerade wieder Zuhause aber alles andere als fit. Sicher könnt ihr euch erstmal gegenseitig helfen :) Gruss Ulrich Albert
Gute Besserung, kurier dich ordentlich aus. Alles Andere kann warten!
Gute Besserung , Erst wieder Fitt werden alles andere ist Zweitrangig
Hallo Martin SerialComCNC 2.xx benötigt GRBL ab Version 1.1e settings $10 =0 und was deine CNC so benötigt. Nullpunkt, Feed und Move setzen. Wenn in Move 0,00 bewegt sich nichts. Gruß Wolfgang G0 Z 10.000 (*** LAYER: Kontur ***) T2 (Fraeser 1mm) S6000 (* SHAPE Nr: 1 *) G0 X 27.300 Y 5.500 M3 M8 G0 Z 3.000 F100 G1 Z -0.500 F250 G1 X 27.300 Y 15.200 G1 X 38.700 Y 15.200 G1 X 38.700 Y 5.500 G1 X 27.300 Y 5.500 F100 G1 Z -1.00 F250 G1 X 27.300 Y 15.200 G1 X 38.700 Y 15.200 G1 X 38.700 Y 5.500 G1 X 27.300 Y 5.500 F100 G1 Z -1.500 F250 G1 X 27.300 Y 15.200 G1 X 38.700 Y 15.200 G1 X 38.700 Y 5.500 G1 X 27.300 Y 5.500 F100 G1 Z -2.000 F250 G1 X 27.300 Y 15.200 G1 X 38.700 Y 15.200 G1 X 38.700 Y 5.500 G1 X 27.300 Y 5.500 F100 G1 Z -2.500 F250 G1 X 27.300 Y 15.200 G1 X 38.700 Y 15.200 G1 X 38.700 Y 5.500 G1 X 27.300 Y 5.500 F100 G1 Z 3.000 G0 Z 10.000 M9 M5 G0 X 0.000 Y 0.000 M30 (Program end)
Gute Besserung und werd wieder Gesund.
Hallo, ich habe da mal eine Frage zu Unterprogrammen im G-Code. Laut Befehlsliste von GRBL kann der ja kein M98 und M99. Gibt es aber trozdem eine Lösung die ich übersehe? Mir ist aufgefallen das ich alle alten Programme nach arbeiten muss, weil die Kommentare von SerialComCNC falsch eingelesen werden. Ich habe neben "()" auch ";" kommentare sowie etliche Leerzeilen. MACH3 schlukt das ohne Probleme! Lösche ich die ganzen Zeilen geht der G-Code. Und noch eine weiter Frage an alle, gibt es schon so was wie ein Überwachungssystem für eine Fräse? Damit meine ich nicht die >5000€ Varianten der Marktführer. Ich habe nun sehr sehr lange Erfarung darin und wollte nun privat ein solches Projekt starten. Wird dann aber im ersten schritt nur eine Einfache Überwachung werden im bereich der normalen 5000€ Klasse, nur halt für 0€. Aber wenn es so was schon gibt züchte ich lieber Rosen. Auch von mir gute Besserung. Klaus
Hallo Klaus , Definiere doch bitte mal Überwachung ... wenn Du meinst CNC Raum 1 ,Benutzer Raum 10 , Zuschauen auf dem Monitor ? So etwas kostest ja keine 5000 Kreuser ,mit IP Cam realisierbar . Das Aufrufen von Standgig wiederholbaren Unterprogrammen (das meinst Du doch mit M98/99 denke ich könnte man bestimmt aber Softwaretechnisch im Gcode sender Implementieren , ähnlich wie ein Werkzeugwechsel?! Aber das wäre ja etwas für Albert . Grüße Sven
Nun den Werkzeugwechsel gibt es in SerialComCNC leider noch nicht. Das man das alles machen kann, wenn man (Albert) will, ist doch klar. Selber hinsetzen und eine eigene Software zuschreiben könnte ich zwar, aber vielleicht kann man Albert ja überreden. Da zu muss er aber erst mal wieder gesund sein. Wenn Du bei dem Begriff "Überwachung" am eine IP-Kammera dennkst solltes Du die Suchmaschinen mal benutzen, sorry aber das hat mit sowas absolut nichts zutun. Aber ich nehme Dir mal etwas Arbeit ab. Überwachung der XYZ Achsen & Spindel auf wiederholbare Wirkleisung, Strom, Drehmoment oder jede andere messbare Grösse. Die einfachste Art ist eine Maximal Prüffung der Signale, das bekommt man sogar mit einem OP einfach hin. Ab da wird es dann kommplizierter (Fehlt Erkennung, Stumpf Erkennung). Das ganze bezieht sich dann meistens auf gelernet Werte, ist damit nichts für einmalige Teile. Aber dafür gibt es auch andere Arten der Überwachung. So was kann man dann kaufen (und auch meine Gehalt sichern), oder so was in kleiner gibt es halt frei wenn interesse besteht. VG, Klaus
Angehängte Dateien:
-
Tool.jpg
68 KB
Hallo Klaus , Deswegen ja die Definierung . Also eine Fehlerüberwachung ... Der Werkzeugwechsel ist doch drin . Schon selber benutzt und ist super ..... Grüße Sven
Automatischer Wechsel ist das was interessant ist! Den manuellen nutze ich jetzt auch, nur ich könnte bei mir auch ein Magazin anfahren und dort wechseln, wenn es denn drin wäre. Da mein Magazin aber auf einer Kette ist kann ich nicht mal eben den Wechsel im Code einbauen. Da wäre dann ein Unterprogram auch sehr hilfreich! Für einen Kettenmagazinwechsler bräuchte man eine 4. Achse + einen Kontakt und wie ich gesehen habe, brauchen andere die auch. Ich hatte zwar jetzt geplant mir ein Magazin mit festen Positionen dran zu bauen, aber auch das wäre immer viel manuelles eingreifen in den Code. Darum meine Frage wegen dem Umterprogram. Eine Fehlerüberwachung ist es nur indireckt, man kann halt auch erkennen ob der Fräser stumpf wird. Aber ansonsten ist es eine Klassische Fräserbrucherkennung, die bei fast allen als Standartüberwachung verkauft wird. VG, Klaus
Nun gut ... Also das mit den Unterprogrammen kann ich voll und ganz nachvollziehen . Deine Überwachung im Hobbybereich Sinnvoll ?! Nicht das Du mich falsch verstehst generell eine schöne Sache so etwas haben wir auf Arbeit auch . Aber ob sich der aufwand lohnt .Da ich nicht den Hintergrund kenne in diesem Bereich bin ich nur Benutzer ohne jegliche Kenntnisse Zu Achse 4 . Wer so etwas braucht sollte sich echt mal grbl-plotter anschauen , den zugriff über ein 2tes Arduino wo zwar jedes mal die Achsen so angesteuert werden müssen (Turn pen storage a little bit to touch gripper) (^2 G91 G0 X0.15) (Close gripper - RC-Servo via Spinde PWM) (^2 M5) (^2 G4 P0.5) (#TOOL-IN) Gute Idee aber noch derbe Luft nach oben mit einer Doko bzw Anleitung da irgendwie nicht wirklich vorhanden und alles auf englisch warum nicht gleich zweisprachig aber alles eine persönliche Meinung Da das eine oder andere nur schwer nachvollziehbar ist Aber wer hat den schon die EierlegendeWollmichsau ... Ich finde SerialCom schon echt klasse besonders mit dem Nexiton und lobe Noch einmal Albert
Mir wäre es lieber das Albert so was einbaut wie das ich was anderes benutze oder gar was selber schreibe. Manche Wünsche die an Albert ran getragen werden kann ich auch nachvollziehen, leider aber auch das er nur das macht was ihm spass macht. Hoffentlich lässt er sich erweichen und macht eine 2. Karte in die Software rein und bitte auch Unterprogramme. Aber ich denke das der Serialbug wohl den meinsten helfen wird, so wie ich das es hier lese, ich habe den aber noch nie bemerkt. Zur Überwachung: Bei Holz und anderen weichen Stoffen bringt eine Überwachung nicht viel. Auch wenn ich in meinen 3KW Motor einen 1mm Fräser überwachen wollte. Aber so ab 3mm in ALU ist das schon recht hilfreich. Ich mache recht häufig immer wieder die selben Teile für einen Verein und bin bis jetzt recht gut gefahren mit einer Überwachung. Diese ist zwar eine Alte von der Arbeit aber die läuft gerade noch so. Als Überwachung für den kleinen Beutel würde ich das ganze auf ein Minimum reduzieren, wobei ich alles neu schreiben würde und viele neue Ideen die ich woanders nicht umsetzen darf hier einbauen. VG, Klaus
Hallo Albert, Was ist denn zeitlich geplant für das Update mit dem Easyjob?
Hallo, Albert M. schrieb: > Wichtig: Alle SerialComCNC Versionen ab Version 2 > benötigen GRBL ab Version 1.1e Vielleicht kann mir jemand bei folgendem Problem helfen: nach erfolgtem Update auf o.a. Versionen, gibt SerialComCNC nach Anfahren eines beliebigen HardLimits (#define DEFAULT_HARD_LIMIT_ENABLE 1) den Error 9 (STATUS_SYSTEM_GC_LOCK) aus. Error 9 ist so lange nicht rücksetzbar, bis der Schalter wieder deaktiviert ist. Freifahren der Achse ist also nicht möglich. Sind die Änderungen in report.h bzw. protocol.c umgesetzt ? Hat noch jemand dieses Problem, mach ich was falsch ? Andere Programme wie GrblPanel etc. funktionieren einwandfrei. viele Grüße Herbert
Herbert Janssen schrieb: > nach erfolgtem Update auf o.a. Versionen, gibt SerialComCNC nach > Anfahren eines beliebigen HardLimits (#define DEFAULT_HARD_LIMIT_ENABLE > 1) den Error 9 (STATUS_SYSTEM_GC_LOCK) aus. > Error 9 ist so lange nicht rücksetzbar, bis der Schalter wieder > deaktiviert ist. Freifahren der Achse ist also nicht möglich. Hallo Herbert , mir ist das auch schon aufgefallen aber keine Sache von SerialCom glaube ich , hatte es auch schon mit BCNC und CNC . Die Ausgabe ist so gewollt von GRBL zu lesen unter : https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface Im Abschnitt : Grbl Response Messages Hmm weiß gar nicht mehr was ich gemacht habe entweder Homing oder per Hand frei geschoben . Grüße Sven
Hallo Leute. . Heute ist mein nextion Display gekommen. Ich habe es geschafft mit dem editor die hmi datei aufzuspielen und es werden mir auch die daten von x y z angezeigt nach einer Bewegung. . Nur kann ich vom Display aus nichts steuern. Senden von Display zu pc funktioniert wohl iwie nicht.. auch weiß ich nicht wofür die anderen 3 datein sein sollen die im Ordner von nextion zu finden sind.. kann sie im Editor nicht mal öffnen. . Weiß jemand Rat? Danke im voraus. Dom
Konverter ist ein pl2303hx von ebay..
Hallo Dominic, hast du denn im Menü Jogging die feedrate und weite ausgewählt? Sprich z.b. F500 und 10mm angeklickt bzw. gedrückt. Danach solltest du die Fräse vom Display aus steuern können. Gruß Detlef
Ja. Habe ich. Jedoch ohne Resultate . Notstop funktioniert nicht. G-code abschicken auch nicht.. also alles was von Display zu pc geht..
Hmmmm, wenn dein Display daten von SC CNC empfängt, du aber nix senden kannst. Ich schieße jetzt mal so ins Blaue. 1. Treiber nicht ok. ( Ich habe da auch so meine Probleme mit Prolific unter Win 10 gehabt) 2. USB TTL wandler defekt (Hast du evtl. noch nen anderen?) 3. Kabel am TTL Wandeler falsch gesteckt. 4. Buchse am Nextion Display hat nen lockeren Lötanschluß. Detlef
Bei meinem Rechner mit Win10 64bit funktionierte es mit dem Treiber pl2303_64bit_installer.exe im Anhang. (Ich hoffe das ich den Treiber hochladen kann und darf) Gruß Detlef
Hey... ich bin mir nicht sicher bei der kabelbelegung vom Konverter. . Ich habe nur einen.. bei dem soll es sein das .. Rot - 5v Schwarz - gnd Grün - tx Weiß - rx ist. Da habe ich aber meine Zweifel dran.. laut diverser Bilder im netz soll grün tx sein.. da funtionierte aber nichts.. also hab ich tx und rx vertauscht und ich konnte die hmi datei aufspielen. . Ich werde den konverter öffnen und direkt an der Platine nachsehen wie es sein muss( ist im Gehäuse mit kabel dran.. dann versuche ich nen anderen treiber.. von zweien Ging nämlich nur einer.. mein Betriebssystem für die fräse ist xp sp3... Mfg dom
Angehängte Dateien:
-
20170129_120730_resized.jpg
420 KB
Hallo Dominic, ich glaub das du da den gleichen Wandler hast, wie den ich gerade nutze. ich hab dir mal ein Foto von meiner Verkabelung gemacht. Gruß Detlef
Hey.. ja. Sieht identisch aus... ich gucke mir das butz noch mal an.. grün geht bei dir auf tx.. ich hab das kurze kabel vom Display weggelassen und direkt die 1pol buchsen am Display angeschlossen. ..
habe mich veguckt,. grün geht bei dir auf RX.. habe einen anderen/neueren Treiber installiert,.. jetzt geht es,.. zwischendurch... eher nur kurzzeitig,.. komisch auch.. ich habe denn konverter geöffnet,.. dort geht das grüne kabel auf txd.. weiß auf RXD.. am display weiß auf TX, grün auf RX.. ist das so richtig weil senden von display auf empfänger vom konverter muss und anders rum senden von konverter auf empfänger display ? ich dachte die ganze zeit an rx auf rx,. tx auf tx,...
Neee, TX vom Sender muss immer auf RX beim Empfänger und RX vom Sender auf TX vom Empfänger. Na wenn es jetzt funktioniert ist alles gut. Gruß Detlef
Hallo Albert . Zum Nextion . Könntest Du bitte noch eine vierte Seite hinzufügen und dort das probe wie auch die Macaos unterbringen . Beste Grüße Sven und ich hoffe Du bist wieder fit .
Danke erstmal an Detlef,.. Funktionieren bei einem von euch die Button [10] - [1] - [0,1] - [0,01] ? Bei mir sind die iwie ohne Funktion, oder ich benutze sie falsch,.. Hat jemand schon Makros erstellt ? Mich würde interessieren was ihr sie machen lasst,.. MfG Dom
Angehängte Dateien:
-
Move_Set.jpg
14 KB
Dominic H. schrieb: > Funktionieren bei einem von euch die Button [10] - [1] - [0,1] - [0,01] > ? Im Nextion Display oder in SerialCom Funktionieren beide sind dazu da um die Distanz festzulegen die bei den Richtungstasten gefahren werden sollen In Serial Com muss zusätzlich (siehe Bild) die menge eingestellt werden
im display funtioniert es,.. die menge zusätzlich ? dann hab ich das wohl falsch interpretiert,.. ich dachte ich klicke zb auf [10] und dann zb X+ und er fährt dann 10 mm nach rechts,..
Dominic H. schrieb: > ich dachte ich klicke zb auf [10] und dann zb X+ und er fährt dann 10 mm > nach rechts,.. Ebend nicht ... ist der wert Null fahrt sie nicht außer über das Display da geht es so
Angehängte Dateien:
-
Nextion.jpg
310 KB
Albert M. schrieb: > Die bidirektionale Kommunikation zwischen Nextion Display > und SerialComCNC geschieht in Klartext (ASCII). > Richtung SerialComCNC wird die Übertragung vom Display mit # > als Startzeichen eingeleitet und mit < beendet. > Richtung Nextion Display wird kein Startzeichen benötigt, > das Ende der Übertragung verlangt 3x ASC255 (3x Hex FF). > SerialComCNC kann auf alle Display Objekte anhand ihres > internen Namens und Property direkt zugreifen. > Die komplette Menue- und Button Logik geschieht auf dem > Display selbst in einer BASIC ähnlichen Sprache und bleibt > auch nach Ausschalten der Versorgungsspannung erhalten. Folgendes Probiert Eine 4te Seite hin zugeführt (Siehe Bild ) Die Menü Steuerung geht tadellos aber SerialCom Reagiert nicht drauf Wo Liegt Mein Fehler print "#G38.2F10Z-10<" page 1 Danke Für eure Hilfe Sven
SvenW. schrieb: > Folgendes Probiert > Eine 4te Seite hin zugeführt (Siehe Bild ) > Die Menü Steuerung geht tadellos aber SerialCom Reagiert nicht drauf > Wo Liegt Mein Fehler > > print "#G38.2F10Z-10<" > page 1 Der Befehlsinterpreter von SerialComCNC reagiert nur auf vordefinierte Befehle. Um vom Nextion Display GCode direkt auf die andere Schnittstelle (Über SerialComCNC zum Arduino) zu schreiben kann der Prefix GC benutzt werden. Alles was hinter GC kommt wird dann als GCode interpretiert. Beispiel für Nextion Display: va1.txt="#GC"+MeinGcode+"<" print va1.txt Das Anlegen einer Variablen im Display (hier va1) ist dann notwendig, wenn der Befehlsstring erst zusammengesetzt werden soll. Ansonsten geht es auch direkt im print Befehl: print "#GCG38.2F10Z-10<" Habe ich jetzt nicht getestet, müsste aber so funktionieren. Gruss Ulrich Albert
Hallo Albert besten Dank klapt super Grüße Sven
Schade, das so viel Energie in das Nextion Display verwendet wird... nettes Gimmick, wäre der EasyJob nicht viel schöner? Was meint ihr? Viele Grüße Sven
Würde ich auch sofort unterschreiben und habe ich auch hier schon so ähnlich gesagt. Auch wenn ich inzwischen selber so ein Display dran habe, wäre mir trozdem lieber hiermit würde es vorran gehen: - Serial Probleme - 2. Karte (Wechsler 456 Achse ???) - EasyJob - Unterprogramme Das ist nur so eine Auflistung der von mir gefunden Wünsche, von mir und Anderen. Das würde dem Projekt echt viel mehr bringen. VG Peter
Freut euch doch einfach über das Geschenk von Albert. Ich gehe mal davon aus, daß er wenn er Spaß daran findet, das eine oder andere Entwickeln wird. Aber mal Ehrlich: Würdet Ihr eure Zeit vergeuden, etwas zu Programmieren, was Ihr selbst nicht braucht? @Albert Schön mal wieder was von dir zu lesen. Hoffendlich get´s dir wieder besser! Gruß Detlef
Peter schrieb: > - Serial Probleme > - 2. Karte (Wechsler 456 Achse ???) > - EasyJob > - Unterprogramme Serial Probleme kann ich keinesfalls feststellen . Wo habt ihr die ? 2. Karte braucht ihr wirklich eine 4te Achse ? und wozu ? Easy Job hey Gcode ist nicht schwer ein Viereck oder Kreis oder ein paar Bohrlöcher sind doch schnell geschrieben dazu brauch man noch nicht einmahl ein CAD Programm Aber Ja Klick Klick Klick ist schneller Unterprogramme ja das wäre auch für mich etwas ... Was der Gute Alber umsetzt und wann liegt bei ihm .... lassen wir und doch überraschen ... Ich persönlich finde das es sich bisher super entwickelt hat. Beste Grüße Sven
Hallo, falls jemand es gebrauchen kann... Ich habe von meiner Steuerung mal einen Schaltplan gebastelt. Ich hoffe der ist als pdf.Dokument lesbar. Verbaut habe ich einen Arduino Uno, drei Treiber TB6560. Der MPX Stecker dient nur zum Trennen der Leitungen beim Öffnen der Steuerbox. Die 1 LED (rot) zeigt die angelegte 12 V Spannung der externen Stromquelle an, die 2. LED (gelb) zeigt die Bereitschaft vom Uno Board an (5V). Die 3.LED (im Plan braun, in Wirklichkeit grün) leuchtet wenn alle Motoren mit der Steuerung verbunden sind. End-Stops sind NO Schalter. Weiter sind zwei 5V Lüfter verbaut, einen Reset-Schalter und ein Anschluss für ein Werkzeuglängenmesser. Der Plan ist natürlich ohne Gewähr und ein Nachbau ist ausdrücklich "eigenes Risiko". Viele Grüße Sven
Sven W. schrieb: > Dominic H. schrieb: >> Funktionieren bei einem von euch die Button [10] - [1] - [0,1] - [0,01] >> ? > > > Im Nextion Display oder in SerialCom > Funktionieren beide sind dazu da um die Distanz festzulegen die bei den > Richtungstasten gefahren werden sollen > > In Serial Com muss zusätzlich (siehe Bild) die menge eingestellt werden habe heute noch mal getestet,.. tut sich nichts,. iwie sind die ohne funktion es wird immer nur gefahren was ich manuell ins feld eintrage zb beispiel steht oben 1,00 ( wo du sagtest - menge) und ein klick auf [10], dann fährt er 1 ...
Detlef Schufen schrieb: > @Albert > Schön mal wieder was von dir zu lesen. > Hoffendlich get´s dir wieder besser! Danke der Nachfrage, leider nicht wirklich. Kinder oder Jugendliche stecken eine Op wegen Blinddarmdurchbruch besser weg, aber mit meinen 67 laboriere ich noch schwer dran rum. Dauert wohl noch was bis dass ich wieder auf dem Damm bin. Zur Fernbedienung mit dem Nextion Display: Also für mich ist das kein Gimmik wie oben gesagt, sondern eine erhebliche Hilfe direkt an der Fräse. Deshalb werde ich diese Funktionalität auch noch weiter ausbauen. Zum Wunsch des Anschlusses eines weiteren Arduino für eine 4. Achse: Abgesehen von der Machbarkeit werde ich keine 4. Achse andenken. Ich, wie wahrscheinlich die Mehrzahl der anderen Nutzer, habe keinen Bedarf dafür. Easy Job (Siehe auch das Video): https://www.youtube.com/watch?v=PAm-B0i21cY Die Easy Job Funktionalität ist ja bei mir schon lange zu ca. 50% betriebsbereit. Allerdings habe ich da Quick und Dirty programmiert, so dass alles eigentlich neu geproggt werden muss, um einiges zu optimieren und damit ich auch später noch mein eigenes Programm nachvollziehen kann. Der Easy Job ist nicht so trivial wie zuerst gedacht, sondern mit vielen Fallstricken gespickt. Man soll es nicht glauben, aber die Anzahl der Codezeilen des Easy Job entsprechen inzwischen der des restlichen Programms. Da muss ich mich erst wirklich aufraffen und Bock drauf haben. Probleme bei einigen Usern mit der Schnittstelle: Sorry Leute, ich kann davon hier auf 3 verschiedenen PCs nichts nachvollziehen. Solche Fehler treten bei mir nicht auf, daher kann ich da auch nicht auf Fehlersuche gehen. Gruss Ulrich Albert
Albert M. schrieb: > Probleme bei einigen Usern mit der Schnittstelle: > Sorry Leute, ich kann davon hier auf 3 verschiedenen PCs nichts > nachvollziehen. Solche Fehler treten bei mir nicht auf, daher kann ich > da auch nicht auf Fehlersuche gehen. > > Gruss Ulrich Albert Ersteinmal gute besserung Ich selber benutze das auf 2 Pc´s Einer meine Fräse der andere Haupt Pc wo ich mit einem 2ten Uno ohne dahinter wirkende Hardware experimentiere mir ist auch aufgefallen das wenn es mal da mal dort und immer wieder einen anderen ComPort bekommt Probleme mit sich bringt oder man diverse andere Gcode Sender installiert hat (in welchen Zusammenhang sich das beeinflusst ist mir unklar). Zuerst wollte das Nextion gar nicht am Experimenten Rechner wären es am Fräsrechner sofort ohne Probleme lief . Da hilft nur eines ,System Sauber halten oder nachträglich bereinigen. Ist sonne persönliche Ansicht bei mir geht das Schnell da ich Software Testen immer in einer VM Mache . Beste grüße und munter Bleiben Sven W.
Das Du mit 67 so eine OP nicht so gut verkraftest kann ich mir gut vorstellen, hoffe das Du bald wieder gesund bist. Ich für meinen Teil brauche Easy Job wirklich nicht um ein paar Zeilen billigen Code zu generieren. Habe das halt nur mit aufgeschrieben. Schade das Du keine 2. Karte einbauen willst, wäre hilfreich. Vielleicht machst Du es ja doch auch wenn Du es persönlich nicht brauchst. Aber Du wirst sehen wenn es einmal dirn ist findet man auch eine Anwendung, sogar Du. Ein Drehteller ist was wunderbares, ein WZW auch. Vielleicht kommt ja das mit den Unterprogrammen. Mein PC ist ganz frisch nur für die Frase aufgebaut und hat so wie es aussieht auch gelegentlich Serial Probleme. Wo das nun herkommt kann ich nicht sagen. VG, Peter
Peter schrieb: > Mein PC ist ganz frisch nur für die Frase aufgebaut und hat so wie es > aussieht auch gelegentlich Serial Probleme. Wo das nun herkommt kann ich > nicht sagen. Häufig ist das USB-Kabel schuld. Mal ein hochwertiges Kabel probieren. Eventuell kann auch eine Anpassung des FIFO-Puffers hilfreich sein. Gruß, Manfred
Was ist denn so ein Fifo Puffer? Ich habe auch immer mal Probleme wenn ich eine Fräsdatei starte. Nach ein paar mal Nullen oder bisschen hin und her fahren geht es dann meistens. Habe das Problem sporadisch auf allen Rechnern und mit verschieden USB Kabel. Allerdings ist mein Uno Board ein Clone, kann es daran liegen? Viele Grüße Sven
Peter schrieb: > Schade das Du keine 2. Karte einbauen willst, wäre hilfreich. Für die 4. Achse gibt es 2 völlig verschiedene Schwierigkeitstufen für die Implementation in SerialComCNC. 1. Asynchroner Modus Damit meine ich folgendes: Die 4. Achse wird verfahren, erst danach machen jeweils die anderen 3 Achsen irgend etwas während die 4. Achse still steht. Das ist relativ einfach zu implementieren und reicht vielleicht für viele Bearbeitungen. 2. Synchroner Modus Die 4. Achse bewegt sich, während gleichzeitig die anderen Achsen verfahren werden und das Werkstück bearbeiten. Hierzu wüsste ich z.Z. keine Lösung, da beide Karten mit GRBL nicht wirklich zu synchronisieren sind. Zu den bei manchen auftretenden Störung auf der Schnittstelle und Board. Hilfreich ist: - Gutes USB Kabel - Schirmung aller Kabel die von der Fräse zum Arduino führen. Die Schirmung nur auf der Arduino Seite zusammen auf Masse legen. - Einbau des Arduino in ein geschirmtes Gehäuse. - Unbeding getrennte Spannungsversorgung für Treiber Boards und Arduino. - Abstand zwischen den Leistungskabeln und den Steuerkabeln halten.
Angehängte Dateien:
-
so_nicht.jpg
41 KB -
bitte_so.jpg
42 KB
USB Verbindungsfehler Mögliche Ursache : Da Grbl ja mit 115200 bits pro sec funkt hab ihr das auch so in der Geräte Manager (comport) angegeben der ist doch Standarte auf 9600 Siehe Bilder
Die Baudraten Einstellung im Geräte Manager von Windows ist egal und hat keine Bedeutung.
Hallo Albert , Ok das wusste ich nicht , das es für Grbl und Serial egal ist , Da ich auch noch einen Plotter besitze und dem ist das halt nicht egal wenn die Bautrate dort anders eingestellt ist als im Prg . Grüße Sven
Jetzt aber mal an die Elektriker . Folgendes vor : Relay um die Spindel an und aus zu schalten via Pin 11 . Anschluss ist mir soweit bekannt aber nun die frage , da das relay 5v brauch direkt ans Arduino oder eigene Stromquelle oder egal , beim googeln bin ich da schon so auf diverses gestoßen aber aus nichts wirklich schlau geworden
@ SvenW Ich würde nie ein Relais direkt an den Port eines Arduino´s anschließen. Also entweder über nen Optokoppler oder mit nem Transistor und Freilaufdiode. Soweit ich es in Erinnerung habe kann der Port nur max. 20mA. Du würdest Ihn warscheinlich überlasten, und das mögen die Fiecher garnicht. Es gibt in der Bucht diverse Relais mit Optokoppler auf einer Platine. In jedem Fall würde ich dir zu einer zusätzlichen Stromquelle raten. Nimm nen einfachen Stepdownwandler und stell den auf 5V ein. Bei meiner Fräse hab ich zur Steuerung der Schrittmotoren die sog. Easystepper verwendet. Die kosten im 5er Pack so 10 Euro und haben einen 5V 1A Spannungsregler on Board, der für so etwas prima geeignet ist. Aber wenn du deinen Spindelmotor damit steuern möchtest(sprich ein und ausschalten), nimm doch ein Solid State Relais. Das kannste direkt am Port anschließen und die können je nach Typ etliche Ampere schalten. (meiner macht 30A bei 24V) Pass aber bitte auf ob du einen für Wechselspannung oder Gleichspannung brauchst. Mein erster war für AC und den hab ich bei einem DC Motor verwendet. Fazit: Einschalten ging aber nicht mehr ausschalten. Gruß Detlef
@Detlef Hallo Detlef , das hatte ich mir schon so gedacht deswegen diese Relais besorgt . http://www.ebay.de/itm/381254348275?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT War mir halt nur nicht sicher mit den 5 Volt ob vom Arduino oder extern . Da ich in meiner Schaltkiste ein 24V Netzteil Drin verbaut habe und einen Dual DC Wandler da ich 12 Volt brauche für den Laser und die LED Strips kann ich ja den zweiten Anschluss auf 5 Volt stellen Dann brauche ich ja In1 nur noch mit Pin 11 Verbinden . Da es Ja ein Dual Relais ist war es so von mir gedacht das ich dann halt 2 Steckdosen damit schalte 1mal Pin 11 für die Spindel 1mal Pin öhhm wars jetzt 3 oder 4 für das Kühlwasser ... egal ich weiß ja wo es steht um es nachzulesen sollte man da auch einen Kondensator / Widerstand Zwischensetzen wie bei den Endschaltern ? Grüße Sven
Hallo Albert. Ich denke das der "Asynchroner Modus" völlig reichen wird. Wäre dann so wie in dem GRBL-Plotter von Sven. Die Ansteuerung würde ich so von Sven übernehmen, da hat er sich was gutes ausgedacht. Wenn man dann noch Makros (Unterprogramme) aus dem Code aufrufen könnte, wäre Dein Program fast perfekt (irgendwas gibt es immer was fehlt). Einen Syncronen Modus mit 2 Karten zu machen glaube ich auch nicht das man den wirklich syncron bekommt. Übrigens ich habe gelegentlich die Serialprobleme troz einer sauberen Verkablung mit guter Abschirmung und guten Kabeln. Ob das nun am PC, GRBL, Kabel oder Wetter liegt kann ich nicht erkennen. Viele Grüsse, Peter
>Ich denke das der "Asynchroner Modus" völlig reichen wird. >Wäre dann so wie in dem GRBL-Plotter von Sven. Bei mir ist es 50%/50% synchron / asynchron: Die zweite GRBL-Steuerung bekommt erst Daten wenn die erste fertig - also 'IDLE' ist. Die erste GRBL-Steuerung bekommt solange keine neuen Daten, solange die zweite GRBL noch in Bewegung ist, also nicht in 'IDLE' ist. Gruß Sven
Sven das hintereinander bearbeiten wäre sowieso das einzige was Sinn macht. Sonst bekommst Du nur ablauf Probleme, weil Du quasi Syncron arbeiten würdest. Die 2. Karte muss nicht in der Visu angezeigt werden, das würde die ganze Sache nur unnötig kompliziert machen. VG, Peter
Peter schrieb: > Übrigens ich habe gelegentlich die Serialprobleme troz einer sauberen > Verkablung mit guter Abschirmung und guten Kabeln. > Ob das nun am PC, GRBL, Kabel oder Wetter liegt kann ich nicht erkennen. > > Viele Grüsse, Peter Hallo Jungs, mit der Fräsensteuerung hatte ich bisher keine Probleme in Sachen Störungen, nur mit der Darstellung der Koordinaten meiner Joystick-Steuerungüber SerialComInstruments (SCI V3). Auf meinem Entwicklungsrechnen im Büro lief alles immer perfekt, auf dem Fräsenrechner hat sich mein Code im Arduino sofort verklemmt, wenn ich SCI online geschaltet habe. Es hat ein Weilchen gedauert, bis ich möglicher Weise zufällig auf das Problem gestoßen bin. Die Anschlüsse für den GRBL-Arduino und den Joystick-Arduino habe ich beide über den auf dem Motherboard vorhandenen USB3.0-Anschluss ausgeführt. Dabei habe ich in der Krabbelkiste vorhandene 2mm Pitch Buchsenleisten verwendet. Das hat für die Steuerung der Fräse ziemlich lange gut funktioniert und die Kommunikation zwischen der Joystick-Steuerung und anderen Programmen (verschiedene Seriell-Konsolen) ebenfalls. Kürzlich habe ich mal wieder was fräsen müssen und da konnte ich keine Verbindung mehr zwischen SerialComCNC und dem Arduino aufbauen. Erst als ich die beiden USB-Anschlüsse vertauscht habe, konnte ich die Fräse wieder steuern. Ok, also habe ich Kontaktprobleme zwischen Steuerrechner und Arduino. Ich habe daraufhin ein normales USB3.0-Kabel (die blaue 10pol Buchse) auf 8 pin Pfostenstecker gekauft, eingebaut und alles ist gut, jetzt auch die Kommunikation zu SCI. Die beiden Arduinos sitzen mit im Rechnergehäuse, alle Kabel nach draußen sind geschirmt, die wesentlichen innen ebenfalls. Die drei Endstufen sitzen auch in der Nähe, stören aber offenscihtlich nicht. Gruß Harald
Hallo Albert und Fan-Gemeinde, ich muss doch nochmal nerven... Ich habe immer wieder Schwierigkeiten eine Fräsdatei zu starten. Das Programm bricht die Verbindung zum UNO ab und verbindet sich neu. Dann wieder "Nullen", Feed einstellen etc. Das mache ich ein paar mal und plötzlich geht die Bearbeitung. Ich habe das Problem mit kompletter Steuerung aber auch nur mit dem nackten Arduino Board mit sehr kurzem, geschirmten USB Kabel. Am Rechner kann es nicht liegen, habe drei Rechner getestet (XP, Vista und WIN 7). Könnte es doch ein Bug im Programm geben oder bin ich der Einzige mit diesem Problem. Hilfe ist erwünscht. Danke im Voraus. Viele Grüße Sven
Sven L. schrieb: > Könnte es doch ein Bug im Programm geben oder bin ich der Einzige mit > diesem Problem manchmal hilft's auch, wenn man Arduino Booard separat Strom versorgt, statt von USB.
Ich habe das gleiche Problem und festgestellt, dass das Schweinderl das
Tastenprellen der Maus ist.
Zimperlicher Click -> Programm stoppt sofort wieder
Beherzter Druck auf die Taste -> alles gut, Programm läuft
Hier könnte eine kleine Pause nach dem Click helfen, das müsste aber
Ulrich in SCC einbauen.
Problem: Er kanns wahrscheinlich nicht testen, weil seine Maus das
Problem wohl nicht hat -> wird wohl nicht eingebaut werden
Alternative: Ein Shortcut ("Alt-L" für Los geht's ;-) für den Button
oder ein anderer Accelerator. Damit könnten dann alle mit dem gleichen
Problem mal testen, ob es damit zuverlässig funktioniert.
Gruß
Harald
Brett Vorm Kopf . Werkzeugwechsel : Automatischer Werkzeugwechsel wird von GRBL 0.9b nicht unterstützt. SerialComCNC unterstützt jedoch einen manueller Werkzeugwechsel und reagiert auf die Werkzeugwechsel-Befehle Txx im G-Code: 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, werden die Steppermotoren mittels M0 angehalten, die aktuelle Position gespeichert und die Z-Achse um den Wert in der "Change Pos" Eingabe-Box hochgefahren. Bis hierhin funktioniert alles ........ 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-Achse und danach die Z-Achse werden nun auf die gespeicherte Position gefahren und das G-Code Programm fortgesetzt. Achsen bewegen nicht möglich . "Cont" nicht auffindbar . Ich habe das doch schon gemacht .... ist zwar schon eine weile her .. wurde das geändert und ich habe das nicht mitbekommen ? Grüße Sven
Nimm doch das Icon "Weiter" Gruß Detlef
Tany schrieb: > manchmal hilft's auch, wenn man Arduino Booard separat Strom versorgt, > statt von USB. Wichtig ist es auch, in den Energiespareinstellungen von Windows die Energiesparoption für den USB-Port zu deaktivieren, damit Windows den Port nicht ausschaltet um Energie zu sparen. Helfen könnte auch, Serialcom eine höhere Priorität zu geben. Gruß, Manfred
Detlef Schufen schrieb: > Nimm doch das Icon "Weiter" > > Gruß Detlef Noch schlimmer "Gcode Fehler " kein T für Werkzeugwechsel .... was für eine Schande ....# läuft wieder alles Grüße Sven W.
Hallo Albert, Was sagst du zu dem Tastenprellen-Problem? Kann das der Fehler sein, bzw. kannst du das ändern? Viele Grüße Sven
Hallo, da ich es (endlich) leid bin, mit den Fehlern von MACH3 weiter zu leben, kam Deine Software gerade rechtzeitig. Was mir bis jetzt nicht aufgefallen ist: Kann die Software "Wiederholungen" machen? Also ich designe ein Stück was am Ende 30mm tief sein soll, möchte aber pro Durchgang nur 1mm fräsen. Gibt es da eine Möglichkeit, die Z-Achse um n zu veringern und das GCode Programm n-mal zu durchlaufen, bis Z= Z im GCode ist? Gruß, Wolfram
Hallo Wolfram, das macht doch dein CAM Programm bei der Erzeugung der G-Codes. Beispielsweise gibst du in ESTLCAM die Frästiefe vom Bauteil an und beim Werkzeug ist die Frästiefe pro Durchgang eingestellt. ESTLCAM errechnet dann die Fräsrunden und gibt dieses im G-Code aus. Viele Grüße Sven
öhmm... mein Cam-Programm... ich hab so gesehen keins. Meist benutze ich Eagle oder CorelDraw und mit HPGL2GCODE wird gewandelt. Mit Mach3 gab es eine Multipass Funktion die ich immer benutzte. Ist ESTLCAM free?
Wolfram F. schrieb: > Ist ESTLCAM free? Ja und nein voll nutzbar ohne Lizenz aber pro erstellten gcode verlängert sich eine warte zeit . Ich besitze die 8er Version und bin vollkommen zufrieden damit http://estlcam.de anschauen lohnt sich Grüße Sven W.
sieht gut aus! Kann man die neueste Version von GRBL nicht mehr in die Arduino IDE einladen und vor dem kompelieren anpassen?
Wolfram F. schrieb: > Kann man die neueste Version von GRBL nicht mehr in die Arduino IDE > einladen und vor dem kompelieren anpassen? Natürlich geht das wo liegt das Problem ?
Angehängte Dateien:
-
Bild1.jpg
240 KB -
Bild2.jpg
360 KB -
Jog-Dail_Display.jpg
230 KB -
Jog-Dail_Front.jpg
86 KB
Hallo, Dank Alberts implementierung eines zweites serielles Interface zur Kommunikation mit einem Nextion Display ein Jogdail mit Display. Realisiert wird das mit ein Arduino-Nano, Rotaryencoder, NOKIA 5110 LCD Dispay und einige Taster. Ich warte leider immer noch auf das bestellte Gehäuse Hamond 1553D sonst hätte ich noch ein Bild vom fertigen Gerät beigefügt.:-( Das HEX File kann mit XLoader in den Arduino-Nano geladen werden. Der Arduino-Nano sollte mit ein FTDI Chip sein. Der CH340 Chip bzw Treiber macht einigen Arger spziell mit MacOsX. Nachtrag: unter Windos7 scheint der CH340 Chip bzw Treiber zu laufen. Gruß Wolfgang
Wolfgang B schrieb: > Dank Alberts implementierung eines zweites serielles Interface > zur Kommunikation mit einem Nextion Display ein Jogdail mit Display. Hallo Wolfgang, mit welchen G-Code Befehlen arbeitest du? Vielleicht kann ich meinen Joystick ebenfalls über dieses Interface an SCC anflanschen? [[http://www.harald-sattler.de/html/joystick-steuerung.htm#Ausblick]] Der Joystick erzeugt halt im Gegensatz zu einem JogDial die Impulse für alle drei Achsen gleichzeitig (zumindest kann er das, im Allgemeinen verfahre ich jedoch meist nur mit einer Achse gleichzeitig). Die Impulserzeugung im Arduino meines Joystick so zu ändern, dass IMMER nur eine Achse gleichzeitig bedient wird, wäre trivial, dann würde sich der Joystick wie dein JogDial verhalten, oder? Gruß Harald
Hallo Harald, spezielle G-Code Befehle benutze ich eigendlich nicht es ist bidirektionale Kommunikation zwischen Nextion Display und SerialComCNC wie Albert vorgesehen hat. es läßt sich aber jeder G-Code Befehl übertragen mit #GC'Befehl'< Gruß Wolfgang
Hallo Wolfgang, ja, das hatte ich soweit verstanden. Mein gedankliches Problem ist eventuell der funktionale Unterschied zwischen einem JogDial und einem Joystick. Soweit ich das überblicke, erzeugt das JogDial einzelne Schritte, je "Raste" einen Schritt, dessen Größe (in mm oder Steps) und Richtung (pos/neg und Achse X, Y oder Z) vorher festgelegt wird. Also genauso wie in SCC im Feld rechts unten per Mausclicks auf die Buttons. Der Joystick erzeugt jedoch je nach Weite der Auslenkung vom Nullpunkt immer schnellere Impulse, ggf. auch entlang einer Beschleunigungsrampe. Zur Zeit schalte ich diese Impulse direkt auf die Stepper-Verstärker, SCC ist dabie vollkommen abgekoppelt und bekommt nichts davon mit, mit allen denkbaren Nachteilen :-( Genial wäre jetzt für mich, wenn ich die Kopplung an SCC über die zweite Schnittstelle realisieren könnte, so wie du das offenbar gemacht hast. Nur fehlen mir die Hintergründe in Sachen G-Code, so dass ich nicht weiß, ob es G-Code Befehle gibt, die ich quasi durch SCC hindurch an GRBL streamen kann, so dass die von mir errechneten Stepimpulse in G-Code abgebildet werden und GRBL daraus die gewünschte Bewegung erzeugt. Mhmm, auch schlecht zu verstehen, was ich da schreibe... verstehe ich selbst kaum, und ich weiß, was ich meine :( Konkret: Muss ich für die Bewegung z.B. einzelne relative G1-Codes senden und vorher z.B. die max Feedrate festlegen. Die ideale Entfernung für einen einzelnen "Step" müsste ich dann austesten. Wäre das ein gangbarer Weg, oder denke ich falsch? Gruß Harald
Hallo Harald, um je nach Weite der Auslenkung deines Joystick vom Nullpunkt immer schnellere Impulse zu erreichen müsstes Du mit jeden oder nStepp F erhöhen zB #GCF100 G91 G1 X1< #GCF120 G91 G1 X1< #GCF150 G91 G1 X1< und so weiter mit #GC’G-Code’< kannst Du quasi alle G-Code Befehle durch SCC hindurch an GRBL streamen Gruß Wolfgang
SvenW. schrieb: > Wolfram F. schrieb: >> Kann man die neueste Version von GRBL nicht mehr in die Arduino IDE >> einladen und vor dem kompelieren anpassen? > > Natürlich geht das wo liegt das Problem ? Na, ich finde da nur ne hex-datei! Und eine .ino, die nicht will... bei der ersten version die ich sah (v0.4 oder so) war noch alles schön editierbar...
Wolfram F. schrieb: > SvenW. schrieb: >> Wolfram F. schrieb: >>> Kann man die neueste Version von GRBL nicht mehr in die Arduino IDE >>> einladen und vor dem kompelieren anpassen? >> >> Natürlich geht das wo liegt das Problem ? > > Na, ich finde da nur ne hex-datei! > Und eine .ino, die nicht will... > > bei der ersten version die ich sah (v0.4 oder so) war noch alles schön > editierbar... Hey, versuch es mal hier mit.. Ist sogar schon die 1.1f Version. https://github.com/gnea/grbl/releases Mfg Dom
Hallo, ich arbeite hier mit GRBL 1.1 sowie SerialComCNC v2.0.2 Aber das Programm zeigt keine X-Y-Koordinaten an und wenn ich eine GCode-Datei ausführen will, bleibt das Programm nach den ersten G-Befehlen hängen. Es sieht so aus, als würde SerialComCNC auf irgend eine Rückmeldung warten, die aber nicht, oder falsch kommt. Es scheint mir so, als wenn hier prinzipiell etwas falsch ist. Googlen hat mich nicht wirklich weiter gebracht. Die Achsen an sich kann ich von Hand verfahren und Homing funktioniert auch. Also die Hardware scheint zu funktionieren Hat jemand einen Tipp für mich? Danke...
Andreas E. schrieb: > Aber das Programm zeigt keine X-Y-Koordinaten an $10=0 setzen bei SerialComCNC > v2 Wolfgang
Hallo, danke für den Tip. Jetzt werden zwar Koordinaten angezeigt, sie verändern sich aber nicht beim Verfahren der Achsen :-(
Andreas E. schrieb: > Hallo, > > ich arbeite hier mit GRBL 1.1 sowie SerialComCNC v2.0.2 > > Aber das Programm zeigt keine X-Y-Koordinaten an und wenn ich eine > GCode-Datei ausführen will, bleibt das Programm nach den ersten > G-Befehlen hängen. Hallo Andreas, hast du den grbl Parameter 10 auf 0 umgestellt ? Wurde weiter oben schon mal erwähnt.... https://github.com/gnea/grbl/blob/master/doc/csv/setting_codes_en_US.csv Viele Grüße Herbert
Hallo Herbert, es scheint so, als hätte er den Befehl nicht angenommen. Ich habe den Befehl dann noch mal mit dem Programm GRBL Controller eingegeben und jetzt funktioniert es auch bei SerialComCNC Danke für die Hilfe....
Andreas E. schrieb: > Hallo Herbert, > > es scheint so, als hätte er den Befehl nicht angenommen. Hallo Andreas, Änderungen an grbl Dateien kannst du mit einem Texteditor oder besser mit diversen grbl Editoren durchführen. SCCNC akzeptiert nur G-code. Viele Grüße Herbert
Wolfgang B schrieb: > mit #GC’G-Code’< kannst Du quasi alle G-Code Befehle durch SCC hindurch > an GRBL streamen Das ist zwar für die 2. Schnittstelle (Nextion) zwar soweit richtig, allerdings mit Vorsicht zu geniessen: Die mit dieser Schnittstelle an GRBL über SerialComCNC gesendeten GCode Befehle werden direkt unter Umgehung der internen Ablaufsteuerung von SCC weitergeleitet. Das impliziert, dass wenn GCode Befehle zu schnell hintereinander gesendet werden der GRBL Puffer überlaufen kann, da vorherige Befehle noch nicht abgearbeitet sind. Bei der manuellen Eingabe über das Nextion Display, für das die zusätzliche Schnittstelle eigentlich gedacht ist, besteht diese Gefahr eher nicht. Wird an diese Schnittstelle allerdings ein Mikrocontroller angeschlossen, ist unbedingt auf die obige Problematik zu achten.
Hallo Albert, danke für den Hinweis! Ich vermute mal, dass die Schnittstelle nicht bidirektional arbeitet? Oder kann ich Statusabfragen an den GRBL-Arduino senden, und somit die Ausgabegeschwindigkeit an den Abarbeitungsfortschritt anpassen? Gruß Harald
Harald S. schrieb: > Ich vermute mal, dass die Schnittstelle nicht bidirektional arbeitet? > > Oder kann ich Statusabfragen an den GRBL-Arduino senden, und somit die > Ausgabegeschwindigkeit an den Abarbeitungsfortschritt anpassen? Nein, dafür ist die Nextion Schnittstelle nicht gedacht. Eine Status-Abfrage ("?") über diese Schnittstelle birgt die Gefahr den internen Ablauf erheblich zu stören. Die Status-Antwort kann über diese Schnittstelle nicht erhalten werden. Die Nextion Schnittstelle kennt nur die von mir festgelegten und von Wolfgang B dokumentierten Befehle : Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" oder eignet sich zum Streamen von einzelnen Gcode Befehlen mittels "GC" Prefix. Mit der baldigen Erweiterung zum Nextion Display kommen da noch einige Befehle zu, aber ansonsten wird der Befehlssatz dieser Schnittstelle begrenzt bleiben.
Albert M. schrieb: > Eine Status-Abfrage ("?") über diese Schnittstelle Hallo Albert, ok, dann muss ich selbst darauf achten, den GRBL nicht zu überfahren und die Komandos langsam (genug) abgeben. Hört sich nach implementieren und testen an :-) Ich berichte, wenn ich was vorweisen kann. Identische Probleme müsste doch auch Wolfgang B mit seinem JogDial haben, oder ist die Abarbeitung bei einem JogDial so prinzipiell anders, dass es hier keine run conditions geben kann? Gruß Harald
Harald S. schrieb: > Identische Probleme müsste doch auch Wolfgang B mit seinem JogDial > haben, oder ist die Abarbeitung bei einem JogDial so prinzipiell anders, > dass es hier keine run conditions geben kann? Doch, da könnte er eventuell schon Probleme bekommen. Die für die Nextion Schnitttselle in Frage kommende interne GRBL 1.1 Verarbeitung ist diese (aus GitHub): Grbl essentially has two buffers between the execution of steps and the host PC interface. One of them is the serial receive buffer. This briefly stores up to 127 characters of data received from the host PC until Grbl has time to fetch and parse the line of G-code. The other buffer is the look-ahead planner buffer. This buffer stores up to 17 line motions that are acceleration-planned and optimized for step execution. Since the send-response protocol receives a line of G-code while the host PC waits for a response, Grbl's serial receive buffer is usually empty and under-utilized. If Grbl is actively running and executing steps, Grbl will immediately begin to execute and empty the look-ahead planner buffer, while it sends the response to the host PC, waits for the next line from the host PC, upon receiving it, parse and plan it, and add it to the end of the look-ahead buffer. Vielleicht berichtet Wolfgang B mal über seine Erfahrungen.
Hallo Albert,
die Problematik das der GRBL Puffer überlaufen kann wenn GCode Befehle
zu schnell hintereinander gesendet werden ist mir bekannt.
Das kann auch auftreten wenn mit der Tastatur in SerialComCNC die Achsen
verfaren werden.
Die Abarbeitung mit meinen JogDial ist prinzipiell nicht anders als wenn
auf den Nextion Display die Arrow botton betätigt werden.
hastige Umdrehungen am Rotaryencoder sollte man vermeiden. Die Arrow
botton
haben keine repeat funktinon da kann das Problem nicht auftereten.
Zum Einrichten am Werkstück ist ein Jogdail eine feine Sache.
Mehr Probleme bereiteten mir der Seriele Streame da kein eindeutiges
Startzeichen gesendet wird und ich nur auf "t“ abfagen konnte.
…..
do { c=ser_getc(); }while(c!='t'); // Hole den Anfang einer Message
GetLine('"');// Hole die Message bis "
if(strcmp(line,"x.txt=")==0) RxD('X');
if(strcmp(line,"y.txt=")==0) RxD('Y');
if(strcmp(line,"z.txt=")==0) RxD('Z');
if(strcmp(line,"f.txt=")==0) RxD('F');
if(strcmp(line,"0.txt=")==0) RxD('X');
if(strcmp(line,"1.txt=")==0) RxD('Y');
if(strcmp(line,"2.txt=")==0) RxD('Z');
if(strcmp(line,"3.txt=")==0) RxD('F');
….
Eine feine Sache deine zweite Schnittstelle
Gruß Wolfgang
Wolfgang B schrieb: > Mehr Probleme bereiteten mir der Seriele Streame da kein eindeutiges > Startzeichen gesendet wird Das ist eine merkwürdige Eigenschaft der Nextion Displays, ebenso wie die 3 Endezeichen. Leider nicht zu ändern, wenn ein Nextion Display angeschlossen ist. Alternativ könnte ich zum universelleren Betrieb der 2. Schnittstelle eine Option mit definiertem Startzeichen und nur einem Endezeichen beim Senden von SerialComCNC zufügen. Wenn die Option aktiviert ist lässt sich natürlich kein Nextion Display an der Schnittstelle betreiben.
Albert M. schrieb: > Alternativ könnte ich zum universelleren Betrieb der 2. Schnittstelle > eine Option mit definiertem Startzeichen zufügen. Beim Aktivieren der > Option lässt sich dann allerdings kein Nextion Display anschliessen. wenn sich das Protokoll nicht grundlegend ändert ist das nicht nötig. Danke Gruß Wolfgang
Hallo Albert, Was sagst du zu dem Tastenprellen-Problem? Kann das der Fehler sein, bzw. kannst du das ändern? Viele Grüße Sven
Albert M schrieb: > Alternativ könnte ich zum universelleren Betrieb der 2. Schnittstelle eine Option mit definiertem Startzeichen und nur einem Endezeichen beim Senden von SerialComCNC zufügen. Wolfgang B schrieb: > wenn sich das Protokoll nicht grundlegend ändert ist das nicht nötig. Jetzt zitier ich mich schon sebst.:-) Die Alternativ könnte für ein universelleren Betrieb der 2. Schnittstelle doch sehr hilfreich sein. Gruß Wolfgang
Hallo Albert, ich schließe mich Wolfgang bzgl. der von dir angedachten Erweiterung an, auch wenn ich zur Zeit noch nicht ganz verstehe, wie ich mit der Schnittstelle umgehen muss, damit SCC und meine Fräse das tun, was ich erwarte, wenn ich an meinem Joystick wackele. Aber das wird noch, denke ich :-) Noch eine Frage zur Funktion: Wenn ich G-Code durch SCC hindurch an den anderen Arduino sende, dann bekommt SCC davon erstmal nichts mit. Da SCC aber in Verbindung mit GRBL steht und zyklisch die Statusmeldungen von GRBL abruft, spiegeln sich die über den Joystick oder das JogDial implizierten Änderungen dennoch in den Anzeigen von SCC wieder, richtig? Gruß Harald
Hallo Harald, zum Testen kannst Du einen zweiten Rechner und ein Terminal zb hterm benutzen. Gruß Wolfgang
Hallo Wolfgang, muss nicht am "Ausgang" Richtung GRBL auch wirklich ein GRBL-Controller angeschlossen sein? Sonst fehlen doch die Statusmeldungen und SCC zeigt nichts an. Vielleicht habe ich dich falsch verstanden? Die Ausgaben des Joystick (genauer des Arduino des Joystick) sehe ich ohnehin im seriellen Monitor der Entwicklungsumgebung (AtmelStudio V7 + VisualMicro AddOn). Zur Zeit sende ich auf der Seriellen SS die im Joystick-Arduino berechneten Koordinaten an eine SerialComInstruments-Anzeige mit drei "LED-Displays". Gruß Harald
ohne GRBL-Controller an SerialComCNC geht das Programm nicht. Wenn Du mit ein Terminal über die zweite Schnittstelle deine Befehle sendes dann siehs Du wie das Programm reagiert. Gruß Wolfgang
also ich hab grbl 1.1 nun auf dem Arduino-Uno, SerialCom stürzt aber nach ein paar Minuten ab mit Fehlermeldung "Schwerwiegender Verbindungsfehler Programm wird geschlossen" Was kann das sein? OS ist Win10/64Bit
anscheinend will ein UNO nicht so, der NANO funktioniert. Allerdings bekomme ich weder bei $ noch bei $$ irgendwas zurück!
Hallo Harald Hast du das Tastenprellen-Problem schon lösen können oder lebst du damit, bzw. was kann ich dagegen tun. Das nervt schon ungemein. Leider hat sich Albert noch nicht hierzu zu Wort gemeldet. Viele Grüße Sven
So, endlich habe ich es hinbekommen! Also ein UNO Verschnitt macht nach 2-3min Fehler, bricht die Ser.Verindung ab. Aber ein NANO (selbst mit CH340) läuft nun, warum ich 2-3x die HEX-Datei mit XLOADER flashen musste, k.A. Nun habe ich seit einigen Stunden eine GCODE Datei "gefräst" (ohne Hardware am NANO) und alles sieht gut aus, $ und $$ funktionieren ebenfalls. Was mich etwas irretiert: Wenn ich SetFeed drücke (100), wird dieser Wert von Werten aus dem GCODE File dann überschrieben oder ist das ein maximaler Wert? Dann noch was ganz wichtiges: Ulrich Albert, erstmal recht herzlichen Dank dafür daß Du Dein tolles Programm so öffentlich teilst! Sowas ist nicht selbstverständlich und ich (und sicher auch viele andere) rechnen Dir das sauhoch an! Weiter so! Wie ist denn der Stand des EasyJobs? Und wofür genau muss man $10 auf 0 setzen? Gruß, Wolfram.
Wolfram F. schrieb: > Was mich etwas irretiert: Wenn ich SetFeed drücke (100), wird dieser > Wert von Werten aus dem GCODE File dann überschrieben oder ist das ein > maximaler Wert? das ist der Feed für den Manuellen Prozess und hat mit den Werten aus dem GCODE File nichts zu tun. > Und wofür genau muss man $10 auf 0 setzen? das ist für die status report options, mask von GRBL Gruß Wolfgang
Hallo an alle, bei mir erscheinen "error 9", "error 22" kann mir einer die genaue Liste für die Fehler mailen? Danke nochmal an Albert und gute Besserung. MfG Klaus
Sven schrieb: > Hast du das Tastenprellen-Problem schon lösen können oder lebst du > damit Hallo Sven, ich lebe damit, weil ich, wie beschrieben, einfach "beherzt" auf die Taste "haue" und damit in 98% aller Fälle Erfolg habe. Du könntest auf jeden Fall mal versuchsweise die Maus durch eine andere ersetzen. Ich muss noch dazu sagen, dass Maus, Tastatur und Monitor rechts von der Fräse aufgebaut sind, der Rechner mit der Steuerung steht links der Fräse. Die Geräte sind mit PS2- bzw. HDMI-Verlängerungen am Rechner angeschlossen, die Kabel laufen hinter der Fräse an der Wand lang. Die langen Kabel helfen sicher nicht unbedingt bei der Signalformung, aber da nicht die Tastenkontakte direkt durchgeleitet werden, sondern Telegramme mit den passenden Informationen, glaube ich nicht, dass es an den Kabeln liegt. Gruß Harald
viel Dank, Wolfgang! Hat jemand schon Erfahrungen mit PC - SerialComCnc - XLCD - GRBL - Endstufen?
Klaus schrieb: > Hallo an alle, > > bei mir erscheinen "error 9", "error 22" > > kann mir einer die genaue Liste für die Fehler mailen? > > Danke nochmal an Albert und gute Besserung. > > > MfG > > Klaus Die kommen bei mir auch. Ob es da eine Liste gibt weiß ich nicht. Error 9 und 22 kommen wenn du nur einmal Alarm Reset gedrückt hast nach zb fahren in einen Endschalter und wenn du nach ALARM RESET nicht wieder die FEET RATE neu bestimmt hast. MfG Dom
>Ob es da eine Liste gibt weiß ich nicht. Nicht schwer zu finden: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#grbl-response-messages Für das leidige Thema dass die Feed Rate nicht gesetzt ist, gibt es hiermit Abhilfe: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#n---view-startup-blocks
Sven schrieb: >>Ob es da eine Liste gibt weiß ich nicht. > Nicht schwer zu finden: > https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#grbl-response-messages > > Für das leidige Thema dass die Feed Rate nicht gesetzt ist, gibt es > hiermit Abhilfe: > https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#n---view-startup-blocks Danke Sven. Sehr nützlich! Wo wir gerade bei Error sind,.. Wenn meine Maschine in die Endschalter fährt, muss ich Alarm Reset drücken, vollkommen richtig.. Wenn ich aber aus den Endschaltern heraus fahre, schmiert sie mir wieder ab,, wieder Alarm Reseten,.. Ist das bei euch auch so und kann man das abstellen? Ich finde es recht nervig.. Könnte eher wie beim Homing sein,.. MfG Dom
Dominic H. schrieb: > Ich finde es recht nervig.. dann schalt doch die Endschalter aus. $21=0 (Arbeitsbereich per Endschalter kontrollieren, bool) Wolfgang
Hallo, ich kann jetzt dieses Problem mit dem Tastenprellen beim Drücken der Starttaste bestätigen. Da der Schalter nach dem aktivieren zum Notaus-Schalter wird, kann es sein, dass er sozusagen beim Aktivieren gleich wieder in den Notaus geht. @ Albert: Das Problem kannst du bestimmt lösen, wenn du im Programm eine kleine Pause nach dem Drücken vorsiehst, oder die Doppelbelegung rausnimmst und einen eigenen Notausschalter einfügst. Wäre Klasse, wenn du das hinbekommst. Betreust du eigentlich auch noch deine Version 1.x oder muss man beim Update auf die GRBL 1.1 immer umsteigen? Danke und viele Grüße Sven
Sven schrieb: > Tastenprellen beim Drücken der Starttaste Das Problem liegt an der verwendeten Tasten-Komponente. Ich versuche eine Lösung zu finden, event. wird diese Komponente durch einen normalen Button ersetzt. Sven schrieb: > Betreust du eigentlich auch noch deine Version 1.x oder muss man beim > Update auf die GRBL 1.1 immer umsteigen? Zwei Versionen zu betreuen ist mir zu aufwändig. Ich arbeite nur noch an der Version ab GRBL 1.1. Endlich habe ich meine 3040 China Fräse zurück. Die war seit einigen Monaten an meinen Vater (94 Jahre) verliehen, der damit fleissig gewerkelt hat. Jetzt können alle Änderungen an SerialComCNC auch wieder in der Praxis getestet werden :)
Albert M. schrieb: > Vater (94 Jahre) Nicht schlecht - mit 94 an der Fräse arbeiten. Wenn sich die Langlebigkeit vererbt hat dann können wir uns ja auf viele weitere Verbesserungen der Software freuen - wenn du ein bischen mehr auf deine Gesundheit achtest ;-) Danke Albert!
Hallo Albert, wäre es möglich die Werte für SET FEED,SET SPDL und MOVE MM auch in das .INI File abzuspeichern und beim starten wieder einzuladen, so daß man nicht immer erst draufdrücken muss?
Hallo Leute, seit meiner Umstellung auf GBRL 1.1 findet meine Maschine den Endschalter der Z-Achse nicht mehr! alle Kabel abgezogen mit Meßgerät durchgang geprüft ok was kann das sein ? Klaus
Klaus schrieb: > Hallo Leute, > > seit meiner Umstellung auf GBRL 1.1 findet meine Maschine den > Endschalter der Z-Achse nicht mehr! Hallo Klaus, An welchem Pin ist der z-Endschalter angeschlossen. GRBL 1.1 ist standardmäßig auf pwm eingestellt, also z an D12. Viele Grüße Herbert
Albert M. schrieb: > Alternativ könnte ich zum universelleren Betrieb der 2. Schnittstelle > eine Option mit definiertem Startzeichen und nur einem Endezeichen beim > Senden von SerialComCNC zufügen. Wenn die Option aktiviert ist lässt > sich natürlich kein Nextion Display an der Schnittstelle betreiben. Hallo Albert, ich habe mich mal in den bei GRBL 1.1 neuen Jog-Betrieb eingelesen und quick&dirty für eine Achse in meinem Joystick-Controller implementiert. Problem scheint zu sein, dass der Befehl "Jog Cancel" (ein 0x85 EinByte-Befehl) nicht an den GRBL durchgereicht wird. Ziel dieses Jog-Cancel ist, den Jog-Buffer spontan zu leeren wenn der Joystick wieder in Nullstellung geht und somit die Bewegung anzuhalten, auch wenn der geplante (durch Jog-Kommandos eingeleitete) Weg noch nicht zu Ende gefahren ist. Um das Ganze noch abzurunden, sprich, um die zweite SS um die von GRBL 1.1 zur Verfügung gestellten Jog-Befehle zu erweitern, wäre es toll, wenn du aus den Antworten des GRBL ein "ok" filtern und an die zweite SS senden könntest. Das ist das ACK der Jog-Queue, wenn der Befehl erkannt wurde und ein Neuer kommen darf. Zitat aus [[https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging]]: Basic Implementation Overview: - Create a loop to read the joystick signal and translate it to a desired jog motion vector. - Send Grbl a very short G91 incremental distance jog command with a feed rate based on the joystick throw. - Wait for an 'ok' acknowledgement before restarting the loop. - Continually read the joystick input and send Grbl short jog motions to keep Grbl's planner buffer full. - If the joystick is returned to its neutral position, stop the jog loop and simply send Grbl a jog cancel real-time command. This will stop motion immediately somewhere along the programmed jog path with virtually zero-latency and automatically flush Grbl's planner queue. Bitte gib mal durch, wie du zu der Idee stehst. Danke! Gruß Harald
Hallo Albert, Entwarnung! Ich vermute, ich habe lediglich den Job-Cancel falsch formatiert abgesendet. Verifikation heute abend oder morgen. Sorry! Aber der Trick mit dem "ok" wäre trotzdem prima :-) Gruß Harald
Ich habe das Jogging per Joystick prinzipiell implementiert und eine Achse schon erfolgreich verfahren können. SCC trackt dabei sauber den zurück gelegten Weg und ein Homing-Befehl führt den Motor auch wieder auf die Ausgangsposition zurück. Allerdings erreicht die Feedrate nicht den angegebenen Wert, ich vermute, dass ich die Jog-Queue nicht ausreichend voll halten kann, da mir die Rückmeldung fehlt, dass der laufende Jog-Befehl in die Queue aufgenommen ist (das "ok" von GRBL). Gruß Harald
Es ist scheinbar doch etwas komplizierter als bisher beobachtet. Der "Jog cancel" (0x85) wird zwar mit #GC durch SCC an den GRBL übertragen, wenn ich den Befehl mit '<' abschließe, allerdings reagiert GRBL scheinbar nicht darauf, denn die Jog Queue wird nicht spontan ausgeräumt, wie in der Jog-Anleitung beschrieben, sondern die Queue wird bis zum Schluss abgearbeitet. Schließe ich hingegen den Befehl an SCC nicht mit '<' ab, hält zwar GRBL (mit Bremsrampe, also im Zweifelsfall mit "Überschwinger") an, aber es werden Fehlercodes erzeugt und in SCC angezeigt. Da muss ich noch weiter forschen... Gruß Harald
@Harald: nur zum Verständnis für mich: Du probierst das JogDial über die 2. Serielle Schnittstelle von SCC? Gibt es eine Liste/Übersicht, was da alles durchkommt oder gefiltert wird? Gruß, Wolfram.
deHarry schrieb: > Schließe ich hingegen den Befehl an SCC nicht mit '<' ab, Alle mit GC durchgereichten G-Code Befehle müssen mit < abgeschlossen werden, ansonsten werden folgende Zeichen mit eingebunden und erzeugen natürlich Fehler. Bist Du beim Senden von (0x85) auch im Jog-Mode? Mir kommt das unter https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging beschriebene Jogging Verfahren nicht besonders ausgegoren vor. Daher wird es von mir noch nicht implementiert, da ich es momentan als Zeitverschwendung ansehe. @Wolfram Fischer Die Nextion Schnittstelle kennt nur die von mir festgelegten und von Wolfgang B dokumentierten Befehle : https://www.mikrocontroller.net/attachment/320042/Kommunikation_Nextion_Display.txt oder eignet sich zum Streamen von einzelnen Gcode Befehlen mittels "GC" Prefix. Weiteres wurde oben bereits diskutiert. Heute oder morgen gibt es eine neue SerialComCNC Version mit einer zusätzlichen Nextion Probe Page, Sofort-Abruch beim Joggen, sowie erweiterten Verfahrweiten beim Joggen.
@Albert danke Albert, das hatte ich übersehen. Wie weit bist du denn mit den EasyJob?
Albert M. schrieb: > Bist Du beim Senden von (0x85) auch im Jog-Mode? Das kann ich leider nicht beurteilen. Der letzte Befehl an GRBL vor dem 0x85 ist auf jeden Fall ein Jog-Befehl. Insofern nehme ich an, dass GRBL zu dem Zeitpunkt noch im Jog-Modus ist. > Heute oder morgen gibt es eine neue SerialComCNC Version mit einer > zusätzlichen Nextion Probe Page, Sofort-Abruch beim Joggen, sowie > erweiterten Verfahrweiten beim Joggen. Ich bin gespannt auf die Unterschiede. Vielen Dank! Gruß Harald
Wolfram F. schrieb: > Du probierst das JogDial über die 2. Serielle Schnittstelle von SCC? Jein... fast richtig. Meine Hardware ist kein JogDial sondern zwei kleine Daumen-Joysticks. > Gibt es eine Liste/Übersicht, was da alles durchkommt oder gefiltert > wird? Albert war schneller, siehe seine Antwort.
deHarry schrieb: >> Heute oder morgen gibt es eine neue SerialComCNC Version mit einer >> zusätzlichen Nextion Probe Page, Sofort-Abruch beim Joggen, sowie >> erweiterten Verfahrweiten beim Joggen. > > Ich bin gespannt auf die Unterschiede. Die Änderungen beziehen sich ausschliesslich auf die Jogging Page beim Nextion Display. Die neuen GRBL Jog Befehle werden aus den oben dargestellten Gründen von mir nicht benutzt. Da ich eine neue Schrittweite von 100mm eingeführt habe, ist es sinnvoll das Verfahren der Achsen ohne "Not Halt" abbrechen zu können wenn man sich mal verschätzt hat.
Angehängte Dateien:
-
Nextion_for_SCC.jpg
130 KB
Anbei neue Version SerialComCNC 2.1 Neues Video: https://youtu.be/wr8Tif5CjHs Change Log V2.1 --------------- Wichtig: Alle SerialComCNC Versionen ab Version 2 benötigen GRBL ab Version 1.1e Nextion Touch Display Erweiterung - Probe Page zugefügt. (Die Probe muss vorher in SCC eingerichtet sein) Button "Probe Start" (Entspricht dem Button P in SCC) Die Z-Achse wird in Probe Mode auf die Probe abgesenkt und beim Schalten des Kontaktes wieder hochgefahren. Button "Goto Werkst. Z0" (Entspricht dem Button PU in SCC) Die Z-Achse wird auf den Werkzeug Nullpunkt abgesenkt. Zur Sicherheit müssen weiterhin die Warnhinweise in SCC bestätigt werden. - Im Menue-Punkt Jogging Button H+R zugefügt (Halt+Reset). Damit wird das Verfahren der Achsen abgebrochen und alle weiteren im Puffer befindlichen Befehle gelöscht. Nach erneutem Setzen von Feed und Verfahrweite kann das Jogging fortgesetzt werden. - Im Menue-Punkt Jogging Verfahrweite 100mm zugefügt und 0,01mm entfernt. Die Einstellungen von ComPort Nextion, sowie im Manual Prozess von Spindel und Feed werden beim Benden des Programms gespeichert. Das Hex-File der neuen Version GRBL 1.1f wurde beigefügt. Das angepasste HMI-File für Nextion Editor v0.43 wurde beigefügt. P.S. Änderung des Start Buttons kommt event. in der nächsten Version. Gruss Ulrich Albert http://www.serialcominstruments.com/
Albert M. schrieb: > Die Änderungen beziehen sich ausschliesslich auf die Jogging Page beim > Nextion Display. Achso, schade, zu früh gefreut ;-) Gibt es eine - offizielle - Aufstellung der an der 2. SS unterstützten Befehle (mit dem jetzt neuen "Sofort-Abruch beim Joggen"), die über die von Wolfram bereits zur Verfügung gestellte Version hinaus geht? Wolframs Version scheint mir mit einem Serial-Sniffer mitgeschnitten(?) Danke! Gruß Harald
Harald S. schrieb: > Wolframs Version scheint mir mit einem Serial-Sniffer mitgeschnitten(?) Wolframs? nein mit den Nextion Editor @ Albert >- Im Menue-Punkt Jogging Verfahrweite 100mm zugefügt > und 0,01mm entfernt. ist die Verfahrweite 0,01 nur in Nextion Display entfernt worden? Danke für die neue Version Gruß Wolfgang
Wolfgang B. schrieb: > Wolframs? Na ja, Albert verlinkt halt immer auf deinen Beitrag mit der Datei... :-) > nein mit den Nextion Editor Danke für den Tipp, das wusste ich nicht. Ich habe nur selbst gerade mit einem Sniffer an der SS rumgetüftelt und die Darstellung war sehr ähnlich. Gruß Harald
Moin zusammen, mal wieder ne vielleicht bl.... Frage: würde gerne wenn Maschine Home gefahren ist, immer die gleichen Wege fahren um auf meinem Tisch fast den Nullpunkt für XYZ zu erreichen? Machbar oder nicht! Klaus
Die Definitionen der 2. Schnittstelle ist kein Geheimnis.
Wer die Schnittstelle mit eigener Elektronik bedienen möchte, wird hier
fündig. Es werden z.Z. nicht alle Befehle tatsächlich im Nextion Display
genutzt.
Die 2. Schnittstelle (Nextion Display) kennt z.Z. die nachstehend
aufgeführten Kommandos beim Empfang von Daten. Alle Kommandos
benötigen als Präfix ein # und als Delimiter ein <
GC Ermöglicht das Senden beliebigen G-Codes.
Der G-Code wird an die 1. Schnittstelle durchgereicht.
Beispiel: #GCG1X12Y4< sendet G1X12Y4 an GRBL.
Achtung: Die normale G-Code Verabeitung in SCC wird durch
das direkte Durchreichen umgangen. Es findet hier also
keine Überprüfung auf Pufferüberlauf in GRBL statt. Für das
korrekte Timing ist jeder selbst verantwortlich.
Start Betätigt den Start Button in SCC
Halt Betätigt den Halt Button in SCC
Weiter Betätigt den Weiter Button in SCC
NotStop Betätigt den Not-Stop Button in SCC
Probe Betätigt den P Button in SCC
SetProbe Betätigt den PU Button in SCC
F100 Sendet Hex 90 an GRBL (wie SCC Button F100)
F+10 Sendet Hex 91 an GRBL (wie SCC Button F+10)
F-10 Sendet Hex 92 an GRBL (wie SCC Button F-10)
H+R Betätigt 2x den AlarmReset Button in SCC
(Notlösung, da GRBL nach einem Halt keinen
Befehl hat den Command Buffer zu löschen)
Home Betätigt den GoHome * Button in SCC
Zero Betätigt den Setze XYZ Zero Button in SCC
Xminus Betätigt den X- Button in SCC
Xplus Betätigt den X+ Button in SCC
Yminus Betätigt den Y- Button in SCC
Yplus Betätigt den Y+ Button in SCC
Zminus Betätigt den Z- Button in SCC
Zplus Betätigt den Z+ Button in SCC
Fjog1000 Setzt Feed auf 1000
Fjog500 Setzt Feed auf 500
Fjog100 Setzt Feed auf 100
Fjog10 Setzt Feed auf 10
Fjog5 Setzt Feed auf 5
Fjog2 Setzt Feed auf 2
Fjog1 Setzt Feed auf 1
Jog100 Setzt Move auf 100
Jog50 Setzt Move auf 50
Jog10 Setzt Move auf 10
Jog1 Setzt Move auf 1
Jog0,1 Setzt Move auf 0,1
Jog0,01 Setzt Move auf 0,01
Von der 2. Schnittstelle werden nachstehende Daten gesendet.
Wegen der Eigenheiten des Nextion Displays wird kein
Startzeichen benötig jedoch 3x ASCII 255 (Hex FF)als Delimiter
ohne CR oder CRLF.
Aktuelle X, Y und Z Koordinaten
Aktueller Feed
Alle Daten jeweils mit Prefix des Nextion Zielobjektes.
Gruss Ulrich Albert
Danke Ulrich Albert! Gruß Harald
Vielen Dank für die neue Version!!! Da ich noch etliche 128x128 GLCDs habe und tonnenweise nette SMD-Taster, hab ich mich drangesetzt und ein Mobiles-Einricht-Werkzeug angefangen. Nun, nach etlichen probieren mit Seriellen Filtern und mächtig Probleme hab ich schon fast daran gezweifelt, daß ich zu blöd bin, ne einfache Serielle auszulesen! Bis ich darauf gekommen bin, daß SCC sich anscheinend nicht oder fast nie mit nem Arduino-UNO "unterhalten" kann! Senden von Befehlen hingegen funktioniert 100%ig. Umstieg auf nen NANO mit CH340 Chip und alle Probleme sind weg. Albert, woran liegt das? Denn viele andere Programme haben mit dem UNO keine Probleme! Nun denn, das LCD hat im Textmodus 16x16 oder 16x20 Zeichen, ist grün hinterleuchtet und für mich ideal für diesen Zweck. Gerade die Möglichkeiten die sich in Kombinationen mit einigen Tastern ergeben, sind super! An meiner CNC-Portalfräse ist z.Z. noch ein PC mit MACH3 und POKEYS Erweiterung dran, ich behaupte mal, der Arduino an der 2. seriellen von SCC hat etliche mehr Möglichkeiten als die POKEYS! Ist nur noch ne Frage der Zeit bis ich ganz auf SCC und GRBL umsteige! Einziger Wehrmutstropfen: ich müsste dann irgendwie die A-Achse des Rundtisches simulieren. Wäre es nicht möglich, für einen 2. GRBL Controller eine weitere serielle mit einzubinden die nur GCODE-Befehle die G00 A300, oder B300 oder C300 in G00 X300, Y300 und Z300 umzuwandeln? Dann hätte man die Möglichkeit bis zu 6 Achsen anzusteuern (und zum einrichten einen Button GRBL1/2). Ist das viel Aufwand?
Wolfram F. schrieb: > Umstieg auf nen NANO mit CH340 Chip und alle Probleme sind weg. > Albert, woran liegt das? Kann ich dir nicht sagen. Ich habe hier meherer PCs, diverse Unos und Nanos, aber nie Probleme gehabt, kann sie daher auch nicht nachvollziehen und korrigieren. Wolfram F. schrieb: > ich müsste dann irgendwie die A-Achse des > Rundtisches simulieren. > Wäre es nicht möglich, für einen 2. GRBL Controller eine weitere > serielle mit einzubinden die nur GCODE-Befehle die G00 A300, oder B300 > oder C300 in G00 X300, Y300 und Z300 umzuwandeln? Dann hätte man die > Möglichkeit bis zu 6 Achsen anzusteuern Dazu habe ich oben schon mal was gesagt. Ja, ist möglich, allerdings mit der Einschränkung dass man die zusätzlichen Achsen nicht verfahren kann während die X, Y oder Z Achse aktiv ist (und umgekehrt). GRBL lässt sich nicht über mehrere Boards in irgend einer Weise synchronisieren. Wolfram F. schrieb: > Ist das viel Aufwand? Nicht wirklich. Allerdings fehlt mir dazu etwas die Motivation, da ich selber keine weiteren Achsen habe :) Vorrangig schreibe und aktualisiere ich momentan das Manual für SerialComCNC komplett neu im PDF-Format.
ok, danke für die Erklärungen. Ich habe einen 2560 basierenden Controller "PiBot" an meinem 3D-Drucker, der kann bis 5 Achsen ansteuern und hat eine angepasste GRBL Firmware. Wäre nur die Frage, ob SCC nur X,Y,Z Befehle oder alles durchlässt? Viel Erfolg mit der Dokumentation! Wirklich ein SUPER Projekt!
Anbei vorab das neue Manual / Doku für SerialComCNC 2.1 im PDF-Format. Das Aufrufen über Menue/Hilfe ist allerdings erst ab der nächsten Version möglich. Sollte ich was vergessen haben oder Fehler aufgetreten sein, bitte melden. Gruss Ulrich Albert
Angehängte Dateien:
-
P1010276.jpg
290 KB -
P1010278.jpg
380 KB -
Jog-Dail_Tasten.jpg
220 KB -
Jog-Dail_Nano.jpg
230 KB
JogDail_V2 - Button Verfahrweite 0,01mm entfernt dafür Halt/Weiter - Beim wechseln der XY oder Z Achse wird beim Button press kein Jog Befehl gesendet. - alt Button + Rotaryencoder Verfahrweite 0,02 mm. JogDial_V2 benötigt SerialComCNC ab 2.xx Gruß Wolfgang
Albert M. schrieb: > Sollte ich was vergessen haben oder Fehler aufgetreten sein, bitte > melden. Hallo Ulrich Albert, ich habe die PDF-Datei redigiert und kommentiert. Soll ich das Dokument hier wieder einstellen? Dann können Andere ggf. meine Kommentare erweitern und du hast nur eine Datei als auszuwertenden Input. ... falls ich Erster war ;-) Gruß Harald
@Wolfgang B Cooles Projekt und Danke fürs Einstellen! @Harald Sattler Danke für Deine Mühe das Manual zu redigieren. Über die Verfahrensweise habe ich nachgedacht und denke dass es nur Verwirrung stiftet, wenn hier weitere Versionen des Manuals eingestellt werden. Bitte sende mir die korrigierte Version per email zu wenn Du möchtest. Ansonsten die Änderungswünsche einach hier diskutieren. Mir ist aufgefallen, dass ich im Manual auf die Bedienung des Nextion Displays nicht weiter eingegangen bin, da diese eigentlich selbsterklärend ist. Wenn ich dazu doch etwas eintragen soll, bitte melden. Gruss Ulrich Albert
Albert M. schrieb: > Bitte sende mir die korrigierte Version per email zu schon unterwegs... :-) Gruß Harald
Hallo Albert, da scheint noch ein kleiner Bug vorhanden zusein, denn der CommPort für das Nextion Display ist zwar gespeichert connectet beim Klick aber nicht. Erst nach erneute Auswahl imm Pulldown Menue ist ein connect möglich. Das Verhalten des ComPorts für GRBL ist OK. Gruß Wolfgang
Hallo Ulrich, mir ist aufgefallen, dass (ohne Nextion Display) der zweite COM Port immer mit COM1 vorbelegt ist, mein Joystick hängt aber an COM3. Ich muss also immer umstellen. COM5 hingegen, auf SS 1 für den GRBL, bleibt eingestellt, solange beim Start GRBL angeschlossen ist. Daraus schließe ich, dass der eingestelle Port der zweiten SS gar nicht gespeichert wird (oder nach dem Nextion sucht?). Gruß Harald
Hallo, es passt nicht direkt hierher. Weiß jemand wie hoch die Summensteprate als Ausgangssignal für die Schrittmotore bei dem AtMega ist? MfG Hans
Hallo, erstmal ein RIESEN DANKE an den Entwickler und alle die bis jetzt an diesem Programm mitgewirkt haben. Nachdem ich das serialcnc com nun auf meinem Notebook installiert habe bekomme ich nach ca. 30 - 60 sec folgenden Fehler angezeigt. " schwerwiegender Verbindungs Fehler Programm wird geschlossen. Ich habe die Version 2.1 installiert und das Hex File per Xloader auf den Arduino Uno geladen. Serialcnc com kann gestartet werden und stürzt nach kurzer Zeit wieder ab. Das Häkchen für Win 10 habe ich deselektiert. Ich habe im Forum nach diesem Fehler gesucht, bin aber nicht fündig geworden. Ich weiß im Moment nicht weiter und brauche Hilfe. Kann mir bitte jemand sagen was ich ändern muss damit es läuft.
Joachim schrieb: > Hallo, > erstmal ein RIESEN DANKE an den Entwickler und alle die bis jetzt an > diesem Programm mitgewirkt haben. > Nachdem ich das serialcnc com nun auf meinem Notebook installiert habe > bekomme ich nach ca. 30 - 60 sec folgenden Fehler angezeigt. > > " schwerwiegender Verbindungs Fehler Programm wird geschlossen. > > Ich habe die Version 2.1 installiert und das Hex File per Xloader auf > den Arduino Uno geladen. Serialcnc com kann gestartet werden und stürzt > nach kurzer Zeit wieder ab. Das Häkchen für Win 10 habe ich > deselektiert. Ich habe im Forum nach diesem Fehler gesucht, bin aber > nicht fündig geworden. > Ich weiß im Moment nicht weiter und brauche Hilfe. Kann mir bitte jemand > sagen was ich ändern muss damit es läuft. Einen Schritt weiter ..... Vers. 1.0 mit GRBL 0.9g läuft ohne Probleme !
Angehängte Dateien:
-
Bild_003.JPG
62 KB
Moin, seither habe ich immer nur Fragen gestellt, nun aber mal was für die Fräse: Bin zur Zeit am Bau meiner neuen Fräse Maße Y 1200 X 1000 Z 150 Hab jetzt meine Z-Achse fertig läuft gut. Bild ist von dem Wechselsystem der Z-Achse (43mm), da ich noch einen Fräsmotor mit 34 mm Durchmesser an der Aufnahme fahre. Schönen Sonntag MfG Klaus
Harald S. schrieb: > Hallo Ulrich, > > mir ist aufgefallen, dass (ohne Nextion Display) der zweite COM Port > immer mit COM1 vorbelegt ist, mein Joystick hängt aber an COM3. > Ich muss also immer umstellen. > COM5 hingegen, auf SS 1 für den GRBL, bleibt eingestellt, solange beim > Start GRBL angeschlossen ist. > > Daraus schließe ich, dass der eingestelle Port der zweiten SS gar nicht > gespeichert wird (oder nach dem Nextion sucht?). > > Gruß Harald Hallo Harald, ich habe kein Nextion Display bin aber am programmieren und nutze die 2.Serielle dafür. Bei mir wird der zuletzt benutzte COM Port benutzt, brauche auch nur auf Connect klicken, dann gehts. Was mich nun für Stunden zurückgeworfen hat ist die eigenartige Benutzung der Seriellen! Ich lese die Daten der 2.Seriellen ein und vergleiche mit
1 | if (!strcmp(inStr, "tx.txt=")) |
auf die x-achsen werte... Am Anfang lief es prima, dann irgendwann erkennt der Arduino nix mehr, egal ob ich auf tx oder txt oder tx.txt= vergleiche. Dachte ich hätte da irgendwo ne bug mit eingebaut... Bis ich auf die Idee kam, anstatt SCC den Seriellen Monitor der Arduino-IDE zu benutzen und selber mal tx.txt= einzugeben. Es wird sofort erkannt! Egal auf was ich vergleiche und wie lang der String ist, es funktioniert immer! Auch mit Hterm getestet. Nur SCC macht es mal und mal nicht. @Albert, da es auch Probleme mit verschiedenen Arduinos (GRBL) gibt, kannst Du da nicht nochmal nachschauen, ob die Seriellen in deinem Programm irgendwas spezielles oder etwas vom standart angesprochen werden? Anscheinend bin ich auch nicht der einzige, der mit verschiedener HW Probleme hat! Joachim schrieb: > Nachdem ich das serialcnc com nun auf meinem Notebook installiert habe > bekomme ich nach ca. 30 - 60 sec folgenden Fehler angezeigt. > > " schwerwiegender Verbindungs Fehler Programm wird geschlossen. > > Ich habe die Version 2.1 installiert und das Hex File per Xloader auf > den Arduino Uno geladen. Serialcnc com kann gestartet werden und stürzt > nach kurzer Zeit wieder ab. Das Häkchen für Win 10 habe ich > deselektiert. Ich habe im Forum nach diesem Fehler gesucht, bin aber > nicht fündig geworden. > Ich weiß im Moment nicht weiter und brauche Hilfe. Kann mir bitte jemand > sagen was ich ändern muss damit es läuft. >Das Häkchen für Win 10 ? Wo ist dieses Häkchen?
Wolfram F. schrieb: > ich habe kein Nextion Display Hallo Wolfram und Wolfgang, ich bitte um Entschuldigung, ich habe eure beiden Namen beim Zitieren durcheinander gebracht. Soll nicht wieder vorkommen! ;-) So, jetzt zu Deinem Schnittstellenproblem. SCC schießt mit 115200 Baud auf den Arduino und die Strings sind nicht die kürzesten, oder? (Deren Format habe ich mir noch nicht angeschaut, da für meinen Joystick nichts Brauchbares dabei ist - ich bräuchte das "ok" vom GRBL, nachdem ich einen Jog-Befehl rausgehauen habe). Kann es sein, dass dein Arduino nach einer Weile einfach nicht mehr mitkommt und Pufferüberlauf hat oder Ähnliches? Falls das der Grund ist, müsste es jeweils nach einem Reset des µC wieder eine Weile laufen. Ich habe ein kleines Menu in meinen Joystick-Controller eingebaut und mit einer länglichen if()-Kette die möglichen Befehle für die Parametrierung meines Joystick aus dem Input rausgefischt. Bei den Tests mit den neuen Jog-Befehlen (hier benötige ich die Menu-Befehle erst mal nicht, habe sie aber drin gelassen) habe ich bemerkt, dass die Laufzeit durch die Schleife zu lang ist und das Lauern auf "ok" in den if-Zweig, alle anderen Befehle in den else-Zweig des "ok" gelegt, dann klappte es wieder. (Vorher wurden alle if-Abfragen der Reihe nach durchlaufen). Ich habe allerdings, ähnlich wie du, SCC für die Entwicklung erst mal beiseite gelegt und die beiden Schnittstellen der Arduinos mit Termite gekoppelt. SCC liefert das "ok" des GRBL ja nicht durch, mit Termite spreche ich direkt mit dem GRBL-Controller, also kommt auch das "ok". Aber ich schweife ab... Gruß Harald
Wolfram F. schrieb: > Am Anfang lief es prima, dann irgendwann erkennt der Arduino nix mehr, > egal ob ich auf tx oder txt oder tx.txt= vergleiche. vermutlich ist das ein laufzeit Problem deiner SW auf den Arduino Harald S. schrieb: >habe ich bemerkt, dass die Laufzeit durch die Schleife zu lang ist ähnliches Problem hatte ich auch bei der Entwicklung der SW für den JogDail. Es wurden teilweise die X, Z oder F, Y Strings nicht erkannt. 115200 Baud kontinuierlichen Streame und strcmp erfordert schon einiges an Optimierung der Laufzeit. Gruß Wolfgang
Hallo zusammen, ich bräuchte mal eure Hilfe. Ich versuche bei mir SerialComCNC in der aktuellen Version zum Laufen zu bekommen. Auf dem Funduino Uno läuft GRBL 1.1f. Ich kann SerialComCNC nach dem Start mit den Funduino verbinden, und auch einige Kommandos ausführen, aber nach einigen Minuten scheint die USB-Verbindung zusammenzubrechen. Die LEDs TX/RX leuchten nach anfänglichem Flackern dann dauerhaft und der Funduino nimmt keine Kommandos mehr an. Merkwürdig ist auch, die die X/Y-Koordinaten von Anfang an auf 0 stehen und sich auch nicht ändern, bei Z stehen nur Bindestriche. Ich hatte gleiches Phänomen auch mit der Vorgängerversion von SerialComCNC. Unter Candle läuft die Steuerung ohne Probleme, damit kann ich meine Fräse (Proxxon MF70) betreiben. Trotzdem würde ich gerne auf SerialComCNC umsteigen. Vielen Dank schon mal für eure Kommentare. Grüße, Jörg
Wolfgang B. schrieb: > ähnliches Problem hatte ich auch bei der Entwicklung der SW für den > JogDail. Es wurden teilweise die X, Z oder F, Y Strings nicht erkannt. > 115200 Baud kontinuierlichen Streame und strcmp erfordert schon einiges > an Optimierung der Laufzeit. Hallo Wolfgang, wie konntest du das optimieren? ich habe nun anstatt mit strcmp ne lange if-schleife probiert die erst nach 't' abfragt dann verzweigt, je nach x,y oder z., dann .txt=" usw. X Werte kommen so nach etwa 3-5sek, Y-Werte nach evt. 2-3min(!) und Z-Werte nie. Es scheint auch die u8glib für das t6963-128x128 LCD nicht unschuldig für "Zeitverschwendung" zu sein, habe deshalb die Daten fürs Display nur alle 2sek übertragen, dies hat jedoch nicht spürbar Verbesserung gebracht. Sollte man den Arduino vielleicht einen anderen Quarzoszillator spendieren?
Joachim schrieb: > Joachim schrieb: >> Hallo, >> erstmal ein RIESEN DANKE an den Entwickler und alle die bis jetzt an >> diesem Programm mitgewirkt haben. >> Nachdem ich das serialcnc com nun auf meinem Notebook installiert habe >> bekomme ich nach ca. 30 - 60 sec folgenden Fehler angezeigt. >> >> " schwerwiegender Verbindungs Fehler Programm wird geschlossen. >> >> Ich habe die Version 2.1 installiert und das Hex File per Xloader auf >> den Arduino Uno geladen. Serialcnc com kann gestartet werden und stürzt >> nach kurzer Zeit wieder ab. Das Häkchen für Win 10 habe ich >> deselektiert. Ich habe im Forum nach diesem Fehler gesucht, bin aber >> nicht fündig geworden. >> Ich weiß im Moment nicht weiter und brauche Hilfe. Kann mir bitte jemand >> sagen was ich ändern muss damit es läuft. > > Einen Schritt weiter ..... > > Vers. 1.0 mit GRBL 0.9g läuft ohne Probleme ! ....................................................... Change Log V2.1 --------------- Wichtig: Alle SerialComCNC Versionen ab Version 2 benötigen GRBL ab Version 1.1e MfG Dom
Wolfgang B. schrieb: > Dominic H. schrieb: >> Ich finde es recht nervig.. > > dann schalt doch die Endschalter aus. > > $21=0 (Arbeitsbereich per Endschalter kontrollieren, bool) > > Wolfgang ^^Das ist für mich keine Lösung.............................. Wolfram F. schrieb: > Hallo Albert, > > wäre es möglich die Werte für SET FEED,SET SPDL und MOVE MM auch in das > .INI File abzuspeichern und beim starten wieder einzuladen, so daß man > nicht immer erst draufdrücken muss? ^^Da bin ich auch für........................................ MfG Dom
Jörg Wagner schrieb: > Merkwürdig ist auch, die die X/Y-Koordinaten von Anfang an auf 0 stehen > und sich auch nicht ändern, bei Z stehen nur Bindestriche. $10=0 setzen in GRBL >1.1e
deHarry schrieb: > ich bräuchte das > "ok" vom GRBL, nachdem ich einen Jog-Befehl rausgehauen habe Nur im ersten Schnittstellen-Thread von SerialComCNC wird die volle bidirektionale Kommunikation mit GRBL behandelt. Der zweite Schnittstellen-Thread war eigentlich ausschliesslich zum Betrieb eines Nextion Touch Display entworfen, d.h. für die Kommunikation zwischen SerialComCNC (PC) und Nextion Display. Nun haben ja findige Anwender die zweite Schnittstelle genutzt, um eigene Elektronik anzuschliessen. Das ist ja so weit in Ordnung und wird von mir auch, so weit möglich und sinnvoll, unterstützt. Der Wunsch von Harald für ein OK-Response auf die von der zweiten Schnittstelle auf die erste Schnittstelle durchgereichten G-Code Kommandos ist verständlich, aber nur umständlich umzusetzen. Beim normalen Betrieb des Displays an der 2. Schnittstelle würde durch ein "OK" auf der Schnittstelle die Anzeige erheblich gestört. Da im Normalbetrieb je nach G-Code Kommandos viele Male pro Sekunde der OK Befehl von der ersten Schnittstelle kommen kann, müsste eine Abfrage auf externen Jog-Betrieb stattfinden (z.B. zusätzlicher Button) und nur im Jog-Betrieb die OKs auf die zweite Schnittstelle zum Senden umgeleitet werden. Das ist mit einigen Tücken und noch zu prüfenden event. Timing Problemen behaftet und mir z.Z. zu aufwändig.
Hans L. schrieb: > Weiß jemand wie hoch die Summensteprate > als Ausgangssignal für die Schrittmotore bei dem AtMega ist? Siehe Manual SerialComCNC v2.1: Es ist unbedingt zu beachten die max. Ausgabefrequenz von ca. 30 kHz der GRBL/Arduino Kombination nicht zu überschreiten. Es können sonst unerwartete Effekte, vom Schrittverlust bis zum Überschreiben der Arduino Speicher auftreten. Berechnung der aktuellen Ausgabe-Frequenz in kHz: (XYZ step/mm)*(XYZ mm/min)/60/1000 Beispiel für die Einstellungvon 1600 steps/mm und 800 mm/min: 1600*800/60/1000 = 21,33 kHz liegt also noch im akzeptablen Bereich
@Albert könntest Du BITTE BITTE dies mit einbauen: > Werte für SET FEED,SET SPDL und MOVE MM auch in das > .INI File abzuspeichern und beim starten wieder einzuladen, so daß man > nicht immer erst draufdrücken muss? Mir sind noch ein paar Dinge aufgefallen: Wenn ich den Haken unter Einstellungen/System "Enable Jogdial" setzte oder nicht setze, gibt es keine Änderung! Ebenso werden die Einstellungen für die Farbwahl nicht richtig dargestellt! Wenn ich "blau" anwähle, wird es auch blau. Beim Neustart ist es auch Blau, aber der Radio-Button steht auf grün! Dann unter Einstellungen/Graphic: Warum ist Ymax nicht editierbar? Meine Fräse hat einen Arbeitsbereich von X630 und Y450, kann ich diese Werte als Default-Werte irgendwo einstellen? Das Problem, das man für die 2.Serielle erst nochmals auf COM5 (in meinem Fall) drücken muss, besteht auch noch immer! Drückt man einfach nur auf Connect, passiert nix. Dies gilt jedoch nur, wenn man das Programm neu gestartet hat! Optisch hat es die Einstellung zwar übernommen, programm technisch ist jedoch keine COM ausgewählt! hier meine unter C:\Users\mega-\AppData\Local\SerialComCNC\ gespeicherte SerialComCNC.ini: (Win10-64)
1 | [FormEinstellung] |
2 | FormVersion=0 |
3 | ShowCmd=1 |
4 | Flags=0 |
5 | PixelsPerInch=96 |
6 | MinMaxPos(3520x1200)=-1,-1,-1,-1 |
7 | MinMaxPos=-1,-1,-1,-1 |
8 | NormPos(3520x1200)=401,301,991,706 |
9 | NormPos=401,301,991,706 |
10 | sliderTimerMS_Position=200 |
11 | checkBoxSupressConnectionLines_Checked=TRUE |
12 | checkboxEnableJogDial_Checked=TRUE |
13 | |
14 | [FormEinstellung\MemoMakro1_Lines] |
15 | Item0= |
16 | Count=1 |
17 | |
18 | [FormEinstellung\MemoMakro2_Lines] |
19 | Item0= |
20 | Count=1 |
21 | |
22 | [FormEinstellung\MemoMakro3_Lines] |
23 | Item0= |
24 | Count=1 |
25 | |
26 | [FormEinstellung\MemoMakro4_Lines] |
27 | Item0= |
28 | Count=2 |
29 | Item1= |
30 | |
31 | [Form1] |
32 | FormVersion=0 |
33 | ShowCmd=1 |
34 | Flags=0 |
35 | PixelsPerInch=96 |
36 | MinMaxPos(3520x1200)=-1,-1,-4,-4 |
37 | MinMaxPos=-1,-1,-4,-4 |
38 | NormPos(3520x1200)=145,23,1635,933 |
39 | NormPos=145,23,1635,933 |
40 | lblCalX_Caption=lblCalX |
41 | lblCalY_Caption=lblCalY |
42 | editToolChangeWaitPos_Text=20 |
43 | lblProbeVal_Caption= |
44 | PanelBackColor_Color=15127230 |
45 | PanelBackDarkColor_Color=10521720 |
46 | PanelBtnColor_Color=16312548 |
47 | PanelPanelColor_Color=13811370 |
48 | PanelTextColor_Color=12548683 |
49 | PanelTextHeadColor_Color=10574893 |
50 | CheckBoxSupressLines_Checked=TRUE |
51 | ComComboBox1_Text=COM10 |
52 | ComBaudBox1_Text=115200 |
53 | EditOffsZ0_Value=10 |
54 | checkboxEnableJogDialClone_Checked=TRUE |
55 | ComComboBox2_Text=COM5 |
56 | EditSpindel_Value=22000 |
57 | editFeed_Value=540 |
58 | editManualmm_Value=1 |
Gruß, Wolfram.
Wolfram F. schrieb: > Wenn ich den Haken unter Einstellungen/System "Enable Jogdial" setzte > oder nicht setze, gibt es keine Änderung! Die Anzeige des simulierten JogDial ist erst ab einer Fensterbreite von über 1740 Pixel horizontal sichtbar. Diese Anzeige wird bei nachfolgenden Versionen event. nicht mehr unterstützt. Wolfram F. schrieb: > Dann unter Einstellungen/Graphic: > Warum ist Ymax nicht editierbar? > Meine Fräse hat einen Arbeitsbereich von X630 und Y450, kann ich diese > Werte als Default-Werte irgendwo einstellen? Ymax ist nicht editierbar um das korrekte Seitenverhältnis der Graphik immer beizubehalten (sonst würden die Fräsbahnen gestaucht/gestreckt aussehen). Wenn Du bei Deinem Arbeitsbereich Xmax auf 1000 einstellst passt Dein Xmax von 630 rein. Event. auch die Fensterbreite ändern, da die Graphik autom. jeweils neu kalibriert wird. Bei ungefähr quadratischer Fenstergrösse geht Xmax=700, dann wird Ymax auch 700. Die anderen Punkte werde ich üperprüfen/korrigieren.
Albert M. schrieb: > Die Anzeige des simulierten JogDial ist erst ab einer Fensterbreite von > über 1740 Pixel horizontal sichtbar. Diese Anzeige wird bei > nachfolgenden Versionen event. nicht mehr unterstützt. Aha, ok, das geht, aber warum ist das "maximize Window"-Icon nicht anwählbar?
deHarry schrieb: > SCC liefert das "ok" des GRBL ja nicht durch, mit Termite > spreche ich direkt mit dem GRBL-Controller, also kommt auch das "ok". etw kannst Du das HW mässig lösen? ist zwar ne Krücke aber was soll's Gruß Wolfgang
Angehängte Dateien:
So, mein Display läuft! Und auch super stabil! Es zeigt XYZ und FEED an, seit Stunden ohne Probleme! Ich habe aber erstmal wegen Bedenken um die 115200 Baud keinen UNO sondern nen ESP8266 und ein ILxxx TFT genommen. Die Tests auf nem UNO kommen noch! (Serenifly, vielen Dank für die Hilfe!) hier das Listing:
1 | #include "SPI.h" |
2 | #include "Adafruit_GFX.h" |
3 | #include "Adafruit_ILI9341.h" |
4 | |
5 | #define TFT_DC 15
|
6 | #define TFT_CS 2
|
7 | |
8 | |
9 | Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC); |
10 | |
11 | unsigned long previousMillis = 0; |
12 | const int SERIAL_BUFFER_SIZE = 20; |
13 | char serialBuffer[SERIAL_BUFFER_SIZE]; |
14 | |
15 | const unsigned char END_CHAR = 0xFF; |
16 | |
17 | void setup ( void ) |
18 | {
|
19 | SPI.begin(); |
20 | tft.begin(); |
21 | tft.setRotation(0); |
22 | tft.setCursor(0, 0); |
23 | tft.fillScreen(ILI9341_BLACK); |
24 | tft.setTextSize(2); |
25 | tft.fillRect(0, 32, 240, 110, ILI9341_BLUE); |
26 | tft.setTextColor(ILI9341_WHITE); |
27 | tft.setCursor(20, 10); |
28 | tft.print ( "SCC-GRBL Display" ); |
29 | |
30 | Serial.begin(115200); |
31 | while (!Serial.available()) |
32 | {
|
33 | tft.setCursor(90, 45); |
34 | tft.setTextColor(ILI9341_RED, ILI9341_BLUE); |
35 | tft.setTextSize(3); |
36 | tft.print("NO"); |
37 | tft.setCursor(30, 75); |
38 | tft.print("CONNECTION"); |
39 | tft.setCursor(50, 105); |
40 | tft.print("to SCC!"); |
41 | delay(500); |
42 | tft.setCursor(90, 45); |
43 | tft.setTextColor(ILI9341_BLUE, ILI9341_BLUE); |
44 | tft.print("NO"); |
45 | tft.setCursor(30, 75); |
46 | tft.print("CONNECTION"); |
47 | tft.setCursor(50, 105); |
48 | tft.print("to SCC!"); |
49 | delay(250); |
50 | }
|
51 | |
52 | }
|
53 | |
54 | void loop ( void ) |
55 | {
|
56 | unsigned long currentMillis = millis(); |
57 | // if (currentMillis - previousMillis >= 5000)
|
58 | // {
|
59 | // previousMillis = currentMillis;
|
60 | //
|
61 | // Serial.print("#GCG91G1X1<");
|
62 | // Serial.print("#GCG91G1Y2<");
|
63 | // Serial.print("#GCG91G1Z1<");
|
64 | // }
|
65 | |
66 | if (readSerial(Serial) == true) |
67 | {
|
68 | parseSerial(); |
69 | }
|
70 | |
71 | }
|
72 | |
73 | bool readSerial(Stream & stream) |
74 | {
|
75 | static byte index; |
76 | static byte endLine; |
77 | |
78 | while (stream.available()) |
79 | {
|
80 | unsigned char c = stream.read(); |
81 | |
82 | if (c == END_CHAR) |
83 | {
|
84 | endLine++; |
85 | }
|
86 | else if (c >= 32 && index < SERIAL_BUFFER_SIZE - 1) |
87 | {
|
88 | serialBuffer[index++] = c; |
89 | }
|
90 | |
91 | if (endLine == 3) |
92 | {
|
93 | serialBuffer[index - 1] = '\0'; // -1 um das " zu ignorieren |
94 | index = 0; |
95 | endLine = 0; |
96 | return true; |
97 | }
|
98 | }
|
99 | return false; |
100 | }
|
101 | |
102 | void parseSerial() |
103 | {
|
104 | if (strncmp_P(serialBuffer, PSTR("tx.txt=\""), 8) == 0) |
105 | {
|
106 | tft.setCursor(15, 45); |
107 | tft.setTextColor(ILI9341_YELLOW, ILI9341_BLUE); |
108 | tft.print("X: "); |
109 | tft.print(serialBuffer + 8); |
110 | }
|
111 | else if (strncmp_P(serialBuffer, PSTR("ty.txt=\""), 8) == 0) |
112 | {
|
113 | tft.setCursor(15, 75); |
114 | tft.setTextColor(ILI9341_YELLOW, ILI9341_BLUE); |
115 | tft.print("Y: "); |
116 | tft.print(serialBuffer + 8); |
117 | }
|
118 | else if (strncmp_P(serialBuffer, PSTR("tz.txt=\""), 8) == 0) |
119 | {
|
120 | tft.setCursor(15, 105); |
121 | tft.setTextColor(ILI9341_YELLOW, ILI9341_BLUE); |
122 | tft.print("Z: "); |
123 | tft.print(serialBuffer + 8); |
124 | }
|
125 | else if (strncmp_P(serialBuffer, PSTR("tf.txt=\""), 8) == 0) |
126 | {
|
127 | tft.setCursor(15, 150); |
128 | tft.setTextColor(ILI9341_GREEN, ILI9341_BLACK); |
129 | tft.print("FEED: "); |
130 | tft.print(serialBuffer + 8); |
131 | }
|
132 | }
|
Gruß, Wolfram
@ Wolfram Fischer Warum spamst Du hier den Thread mit Deinen Programm-Listings zu. Das ist unhöflich den Mitlesern gegenüber. Einfach als ZIP anhängen und schon bleibt der Thread lesbar.
Angehängte Dateien:
So, mein Display läuft! Und auch super stabil! Es zeigt XYZ und FEED an, seit Stunden ohne Probleme! Ich habe aber erstmal wegen Bedenken um die 115200 Baud keinen UNO sondern nen ESP8266 und ein ILxxx TFT genommen. Die Tests auf nem UNO kommen noch! (Serenifly, vielen Dank für die Hilfe!) anbei das Listing.. @Admins: den Beitrag mit dem Listing als [code] bitte löschen! (und diese Zeile auch, danke)
Albert M. schrieb: > Einfach als ZIP anhängen und schon bleibt der Thread lesbar. "ZIP ist das ungeeigneste Format!" schreibt einer vom Smartphone aus, weil er es nicht auspacken kann. Sinnvollerweise werden einfach *.c oder *.bas oder *.ino Dateien angehängt. Man kann auch mehrere Dateien anhängen... BTW: Weil Arduino Quelltext das selbe wie C ist, ist [c] der geeignete Token zum Formatieren.
Wolfram F. schrieb: > also ich hab grbl 1.1 nun auf dem Arduino-Uno, SerialCom stürzt > aber > nach ein paar Minuten ab mit Fehlermeldung "Schwerwiegender > Verbindungsfehler Programm wird geschlossen" > Was kann das sein? > > OS ist Win10/64Bit Hey, das hatte ich auch, nachdem ich das setup in C/Programme installiert habe läufts
Möchte mal wieder mein Feedback dazu geben, Hallo Albert M.! Erst mal Vielen Dank von meinem Kumpel Hannes und mir für dieses sehr gute Projekt! Wir verfolgen dies schon seit 1 ½ Jahren. SCC Ver. 0.9f lief jetzt schon seit einem Jahr fehlerfrei bei Uns. (XP SP3) Aktuell läuft SCC Ver. 2.0.2 und GRBL 1.1e (UNO) mit 3,5“ Nextion Display Hannes Prüft seit einer Woche die 2.0.2 ohne das ein Fehler auftrat (XP SP3 und UNO) Das Update 2.2 und 1.1f wird demnächst aufgespielt. Eine CAM Hat noch keiner von uns beiden an der Fräse. Hatte bis jetzt keine Priorität Störung in der Verbindung konnte ich bis jetzt fasst immer Auf EMV oder Wackelkontakt zurückführen. Wenn ich zum Beispiel das Licht (Neonröhre)Einsteckte an der gleichen Steckdose. Abgeschirmte USB Kabel ist ein Muss, die bei denen nur 4 Drähtchen drin sind reichen nicht. Einfach mit einem Durchgangsprüfer beide enden Buchse und Stecker direkt am Metall messen. Sollte gegen null Ohm liegen. Wenn nicht. Kabel tauschen! War bei mir der fall. Danach hatte ich ruhe. Ich kann das Nextion Display nicht gleich mit Connect Verbinden obwohl der COM Anschluss der richtige ist. Erst wenn ich den selben COM Port erneut Auswähle und erneut auf Connect klicke. Ist bei Hannes ebenso. Find ich aber jetzt nicht so tragisch. Fräse manchmal zwei drei Stunden ohne die Verbindung zwischendurch zu trennen. Überwiegend nutzen wir das Programm Sprint-Layout 6.0 zur Leiterplatten Erstellung. In SCC wird diese Datei über den HPGL Import in G-Code umgewandelt. Eine Möglichkeit die noch nützlich wäre ist das Einstellen einer Materialstärke. Wenn zum Beispiel die Stärke 4mm beträgt und in 4x Durchgängen -1mm tief gefräst werden soll. Importiere ich die Datei nach jeden Durchgang neu ein und erhöhe um 1mm. Hat jemand einen Tipp wie ich das doch in einen Fräsvorgang machen könnte? Gruß Daniel!
Moin Albert, moin all, Fehler: Mein "Display Zeit" rührt sich nicht. Wunsch: Anzeige des aktuellen Spindlespeed. Wird gebraucht, um im Lasermodus schneller Erfahrungen sammeln zu können ... @Albert: Gute Besserung ...
Sorry: SerialComCNC 2.2 gibt es noch nicht. Ich meinte 2.1. Albert M. ich wollt nichts vorwegnehmen.;) Hallo Jörg, ich habe es folgender weise gemacht: Mit dem XLoader Das Hex-File der neuen Version GRBL 1.1f aufspielen. SerialComCNC 2.1 starten und Verbindung aufbauen. Danach sofort unten rechts $10=0 und Enter drücken. Jetzt die Verbindung wieder trennen und Neu Verbinden. Wenn alles geklappt Hat Meldet sich der UNO mit " Grbl 1.1f ['$' for help] OK OK Jetzt kann die Taste $$ unten rechts gedrückt werden um die Parameter zu sehen und zu ändern. Gruß Daniel
Wolfram F. schrieb: > Es zeigt XYZ und FEED an, seit Stunden ohne Probleme! Hmm, DAS war gestern! Ohne was zu ändern bekomme ich heute wieder Zeichen hinter den Zahlen die da nicht hingehören! Mal hier, mal da.... Also an der Geschwindigkeit des µC kann es wohl nicht liegen, 80 oder 160Mhz sollten keine Probleme machen. Sende ich einen langen Stream mit den Nexion-Daten per Hterm an den ESP, treten NIE Fehler auf! @Albert: gibt es vielleicht Unterschiede ob SCC unter C:\ oder C:\Programme installiert ist? Vielleicht etwas mit Rechten oder so? Und noch einen weiteren BUG gefunden: Wenn man eine HPGL Datei einlädt (habe etliche versucht), kommt beim druck auf "Process Datei" eine Fehlermeldung: "ist kein gültiger Gleitkommawert! @Wolfgang: Wie hast Du diese Probleme gelöst? Ich spiele schon mit dem Gedanken, nen SERIAL-PROXY zu programmieren der alle Befehle zum/vom GRBL durchschleift, sollte der ESP schaffen. A la dem XLCD... Ist mir ein Rätsel mit den SCC Seriellen...
Wolfram F. schrieb: > Wie hast Du diese Probleme gelöst? ich habe das Problem nicht, begrenze die Ausgabe auf maximal 9 Zeichen Gruß Wolfgang
Daniel S. schrieb: > Möchte mal wieder mein Feedback dazu geben, > > Hallo Albert M.! Erst mal Vielen Dank von meinem Kumpel Hannes und mir > für dieses sehr gute Projekt! > Wir verfolgen dies schon seit 1 ½ Jahren. > SCC Ver. 0.9f lief jetzt schon seit einem Jahr fehlerfrei bei Uns. (XP > SP3) > Aktuell läuft SCC Ver. 2.0.2 und GRBL 1.1e (UNO) mit 3,5“ Nextion > Display > Hannes Prüft seit einer Woche die 2.0.2 ohne das ein Fehler auftrat > (XP SP3 und UNO) > Das Update 2.2 und 1.1f wird demnächst aufgespielt. > Eine CAM Hat noch keiner von uns beiden an der Fräse. Hatte bis jetzt > keine Priorität > > Störung in der Verbindung konnte ich bis jetzt fasst immer Auf EMV oder > Wackelkontakt zurückführen. > Wenn ich zum Beispiel das Licht (Neonröhre)Einsteckte an der gleichen > Steckdose. > Abgeschirmte USB Kabel ist ein Muss, die bei denen nur 4 Drähtchen drin > sind reichen nicht. > Einfach mit einem Durchgangsprüfer beide enden Buchse und Stecker direkt > am Metall messen. > Sollte gegen null Ohm liegen. Wenn nicht. Kabel tauschen! War bei mir > der fall. Danach hatte ich ruhe. > > Ich kann das Nextion Display nicht gleich mit Connect Verbinden obwohl > der COM Anschluss der richtige ist. > Erst wenn ich den selben COM Port erneut Auswähle und erneut auf Connect > klicke. Ist bei Hannes ebenso. > Find ich aber jetzt nicht so tragisch. Fräse manchmal zwei drei Stunden > ohne die Verbindung zwischendurch zu trennen. > > Überwiegend nutzen wir das Programm Sprint-Layout 6.0 zur Leiterplatten > Erstellung. > In SCC wird diese Datei über den HPGL Import in G-Code umgewandelt. > Eine Möglichkeit die noch nützlich wäre ist das Einstellen einer > Materialstärke. Wenn zum Beispiel die Stärke 4mm beträgt und in 4x > Durchgängen -1mm tief gefräst werden soll. Importiere ich die Datei nach > jeden Durchgang neu ein und erhöhe um 1mm. > Hat jemand einen Tipp wie ich das doch in einen Fräsvorgang machen > könnte? > > Gruß Daniel! Normalerweise geht das mit dem Cam Programm. Wenn du sagst, 4mm tief fräsen und in der Werkzeugliste dein ausgewählter Fräser auf 1mm Zustellung eingestellt ist, dann berechnet das Cam Programm automatisch 4 Durchläufe und stellt pro weiteren Durchgang 1mm mehr zu.. Ein Bsp wäre Estlcam. Wenn dein Sprint Layout das nicht kann, vllt kann Eagle es dann. MfG Dom
$10 schrieb: >> Merkwürdig ist auch, die die X/Y-Koordinaten von Anfang an auf 0 stehen >> und sich auch nicht ändern, bei Z stehen nur Bindestriche. > > $10=0 setzen in GRBL >1.1e Der Tipp war Gold wert, nachdem ich $10=0 gesetzt hatte, waren alle Probleme, die ich hatte, mit einem Schlag verschwunden. SerialComCNC läuft, das Nextion Display läuft, super. Ich danke Dir. Grüße, Jörg
>Wenn dein Sprint Layout > das nicht kann, vllt kann Eagle es dann. Eagle kann mit dem gcode.ulp bis zu 4 Durchgänge! Wobei sogar 4 Nutzen-Ausbruch-Bereiche stehen bleiben können (einstellbar)
@Wolfgang: was bedeutet
1 | …. |
in deiner Routine? 0xFF und ?
Wolfram F. schrieb: > was bedeutet…. > in deiner Routine? 0xFF und ? Keine Ahnung was Du damit meinst. Gruß Wolfgang
Wolfgang B. schrieb: > Keine Ahnung was Du damit meinst. Jetzt hab ichs Windofs ist nur zu sich selbst kompatibel.:-( Darstellung Unicode (UTF-8) Gruß Wolfgang
moin, was muß genau für den Werkzeugwechsel im G-Code stehen? Estlcam!! MfG Klaus
T und die Werkzeug NR zB. T2 Gruß Wolfgang
Angehängte Dateien:
-
EasyJob.png
37 KB
Anbei neue Version SerialComCNC 2.2
(Nochmal eingesetzt, da eben gepostete Version fehlerhaft war)
Change Log V2.2
---------------
Easy Job teilweise freigegeben (Experimental)
Video, allerdings noch mit der alten Bedienoberfläche von SCC:
Youtube-Video "SerialComCNC neuer EasyJob Modus"
Easy Job stellt einfache Bearbeitungmöglichkeiten zur Verfügung
ohne CAD- und CAM- Programme benutzen zu müssen.
Nach Eingabe des gewünschten Jobs und Parameter wird automatisch
G-Code erstellt und in das "G-Code Datei" Fenster des Hauptfensters
eingefügt.
Es können mehrere Jobs erstellt und in der Reihenfolge geändert
werden. Die Jobs lassen sich einzeln oder insgesamt zu G-Code
konvertieren.
Freigegebene Jobs:
- Drill Hole
Ein Loch an der angegebene Position bohren.
- Line of Holes
Beliebige Anzahl von Löchern in einer Reihe bohren.
Vertikal, horizontal oder diagonal.
- Rectangle
Rechteck fräsen.
- Rounded Rectangle
Rechteck mit gerundeten Ecken fräsen. Eckenradius wählbar.
Weitere Jobs kommen demnächst dazu.
Update des PDF-Manuals, aufrufbar über Menue Hilfe.
Gruss Ulrich Albert
http://www.serialcominstruments.com/
wow! SUPER! Darauf hab ich gewartet! Danke Vielmals! @all: sollten wir nicht mal "zusammenschmeissen" und ne nette Spende an Albert schicken? freu...
Wolfgang B. schrieb: > Wolfgang B. schrieb: >> Keine Ahnung was Du damit meinst. > > Jetzt hab ichs > > Windofs ist nur zu sich selbst kompatibel.:-( > > > Darstellung Unicode (UTF-8) > > > Gruß Wolfgang Hmmm... aber was die Zeichen darstellen sollen oder machen, weiss ich noch immer nicht. Kannst Du nicht mal mein Listing an Dein Display anpassen und testen? Meiner Meinung nach ist doch alles richtig, oder?
Wolfram F. schrieb: > Hmmm... aber was die Zeichen darstellen sollen oder machen, weiss ich > noch immer nicht. Wenn Du mal die Darstellung Textcodierung auf Unicode (UTF-8) einstellst siehst Du dass das nur einfach ... . ist. bedeutet der Rest ist Ausgeschnitten.... Gruß Wolfgang
:-) Achso ! Grins... Trotzdem könntest Du das mal testen? Ich habe gerade noch was geändert, hatte ja direkt aus dem String einen Teil aufs Display dargestellt, da ich es aber schön rechtsbündig haben wollte, habe ich einen 2. String lcdBuffer zusammengestellt und diesen lasse ich jetzt darstellen. Nun scheint das Problem mit evt. mal andere Zeichen im TFT weg zu sein! (Klopf auf Holz, morgen ist es wieder da...) In readSerial(Stream & stream) wird der String zusammengesetzt. Natürlich laienhafte Programmierung, bin aber auch nicht sooo der Programmierer. Anbei das aktuelle Listing. Gruß, Wolfram.
Wolfram F. schrieb: > da ich es aber schön rechtsbündig haben > wollte, habe ich einen 2. String lcdBuffer zusammengestellt und diesen > lasse ich jetzt darstellen. Warum so umständlich? du brauch's doch nur die Zeichen zwischen den " " und die kann man beim einsammeln mit zählen und man hat gleich die cursor Position. Mit den .ino kann ich so nichts anfangen das ist für die Arduino Umgebung und das benutze ich nicht, ist mir zu undurchsichtig.:-( Die HW ist ganz OK. Gruß Wolfgang
Lothar M. schrieb: > BTW: > Weil Arduino Quelltext das selbe wie C ist, ist [c] der geeignete Token > zum Formatieren. Was ist denn undurchsichtig? Was sind eigentlich die Unterschiede zwischen tx.txt und t0.txt usw.?
Wolfram F. schrieb: > Was ist denn undurchsichtig? Die gesammte Strucktur angefangen mit den Pin/Port Bezeichnungen, Libraries und behandlung der Timer. Ich Progammiere mit Xcode in C und da weis ich meistens was ich mache. Aber diese Diskussion gehört hier nicht hin. >Was sind eigentlich die Unterschiede zwischen tx.txt und t0.txt usw.? sind beides die gleichen daten, wird wohl für das Nextion Display so gebraucht. Gruß Wolfgang
Danke Albert M. ! Werde mir den Easy Job heute noch ansehen. Da meine Maschine im Moment nicht einsatzbereit ist muss mein Kumpel Hannes dies testen. Hallo Dominic H. Danke für den Hinweis! Ich werde mir Estlcam und Eagle anschauen da das Sprint-Layout auf Leiterplatten Erstellung ausgelegt ist. Die Materialstärke oder frästiefe lässt sich nicht definieren. Dank Albert M. Kann ich die *.plt Dateien in SCC Importieren. Gruß Daniel
Hallo Albert M, erst mal Vielen Dank für die neue version mit Easy Job. Ich habe mir mal den Easy Job einfache Bearbeitungmöglichkeiten angeschaut. Währe es nicht einfacher beim Rectangle (Rechteck fräsen) den Bezugspunkt in die Mitte vom Rechteck zulegen X,Y und für das Rechteck Höhe,Breite eingeben? ewt. auch den Punkt als Dezimaltrennzeichen abfangen sonst werden aus 2.5mm schnell 25mm.:-( Gruß Wolfgang
Wolfgang B. schrieb: >>Was sind eigentlich die Unterschiede zwischen tx.txt und t0.txt usw.? > > sind beides die gleichen daten, wird wohl für das Nextion Display > so gebraucht. Leider lassen sich ankommende Daten im Nextion Display nicht mit z.B. einem OnChangeEvent an andere (Text)Objekte weiterleiten. Eine Anfrage bei Nextion/Itead ergab, dass daran nichts geändert wird. Daher müssen, wenn die gleichen Daten auf mehreren Display Pages gezeigt werden sollen, diese auch mehrmals von SCC geschickt werden. Das verdoppelt den Datenverkehr auf der zweiten Schnittstelle. Ich versuche dazu eine Lösung zu finden, z.B. die Daten nur einmalig an Variablen-Objekte des Displays zu senden und mit einem Timer des Display 10 mal pro Sekunde diese Variablen an die Text-Objekte der Pages weiterzuleiten. Damit ist es möglich, dass sich die Bezeichner in den von der zweiten Schnittstelle gesendeten Daten in Zukunft ändern, ebenso wie das HMI-File des Displays. Wolfgang B. schrieb: > Währe es nicht einfacher beim Rectangle (Rechteck fräsen) > den Bezugspunkt in die Mitte vom Rechteck zulegen X,Y und > für das Rechteck Höhe,Breite eingeben? Dass die Position eines Rechtecks durch seinen Mittelpunkt bestimmt wird ist wohl eher unüblich. Durch die bestehende Angabe der Koordinaten der linken unteren und rechten oberen Ecke ist das Rechteck ausreichend und exakt definiert.
Albert M. schrieb: > Ich versuche dazu eine Lösung zu finden, z.B. die Daten nur einmalig an > Variablen-Objekte des Displays zu senden und mit einem Timer des Display > 10 mal pro Sekunde diese Variablen an die Text-Objekte der Pages > weiterzuleiten. Da Timer im Nextion-Display leider auch nicht global sind, musst du einen Timer pro Page verwenden. Also eine globale Variable, die du über die serielle fütterst. Dann einen Timer pro Seide, der dann die globale Variable auf die gewünschten Objekte DIESER Seite spiegelt. Das ist zwar etwas aufwendig, läuft aber ganz gut.
Albert M. schrieb: > Dass die Position eines Rechtecks durch seinen Mittelpunkt bestimmt wird > ist wohl eher unüblich. Das mag vielleicht so sein, aber für die Platzierung eines Rechtecks Bzw. Durchbruch auf den Werkstück ist es meines Erachtens einfacher. Durch die Angabe der Koordinaten die Größe des Rechtecks zu bestimmen ist schon etwas abstrakt. Gruß Wolfgang
Angehängte Dateien:
-
EasyJob.png
37 KB
Wolfgang B. schrieb: > Albert M. schrieb: >> Dass die Position eines Rechtecks durch seinen Mittelpunkt bestimmt wird >> ist wohl eher unüblich. > > Das mag vielleicht so sein, aber für die Platzierung eines Rechtecks > Bzw. Durchbruch auf den Werkstück ist es meines Erachtens einfacher. > > Durch die Angabe der Koordinaten die Größe des Rechtecks zu bestimmen > ist schon etwas abstrakt. Was ist daran abstrakt? Ich habe das User Interface für den Easy Job oben nochmals zur Verdeutlichung für die Mitleser eingefügt. Wie würdes Du es dann weniger abstrakt z.B. mit einer Linie halten die nicht senkrecht oder wagerecht ist, sonder schräg verläuft? Jetzt sag nicht Länge und Winkel angeben. Das hat schon seinen Grund wie das User Interface aufgebaut ist. Damit lassen sich alle Möglichkeiten erschlagen. Wer mit CNC arbeitet hat sich an Koordinaten eigentlich gewöhnt. Am User Interface des EasyJob werde ich daher nichts ändern.
ich bin deiner Meinung, Albert! Wenn allerdings irgendwann Kreise dazukommen, sollte man x und y als Kreismittelpunkt sowie Radius und ob innen oder aussen angeben können. Hat eigentlich jemand SUB-D-Makros um "mal eben" Löcher für SUB-D Buchsen (oder Lüfter usw.) an X,Y zu fräsen?
Wolfram F. schrieb: > Wenn allerdings irgendwann Kreise dazukommen, sollte man x und y als > Kreismittelpunkt sowie Radius und ob innen oder aussen angeben können. Ist alles schon genau so seit langem fertig, der Kreismittelpunkt wird in der "Startpunkt" Box und der Radius in der "Radius" Box eingegeben. Nicht passende Boxen werden bei den verschiedenen Jobs ausgeblendet. Ich hatte vor einiger Zeit schon mal geschrieben, dass ich den komplettem EasyJob neu überarbeite. Das dauert halt seine Zeit. Folgende Jobs werden der Reihe nach als nächste veröffentlicht: - Kreis, auch benutzbar für "Bohrungen" grösser als Fräserdurchmesser - Reihe von Kreisen - Teilkreis - Rechteck-Tasche, Rechteck Tasche mit gerundeten Ecken - Kreistasche, Kreis-Tasche mit Insel - n Bohrungen auf Kreisbahn - n Bohrungen auf Teilkreis
Albert M. schrieb: > Was ist daran abstrakt? Hallo Albert M., wenn ich für einer Frontplatte ein 20mm x 80mm (BxH) Durchbruch auf der Position Y60mm X160mm benötige muss ich erstmal umrechnen. X1 = X160-80/2 Y1 = Y60-20/2 Y2 = Y1+20 X2 = X1+80 Albert das war keine Kritik sondern nur ein Vorschlag den Jop zu vereinfachen. >Wer mit CNC arbeitet hat sich an Koordinaten eigentlich gewöhnt. keine Bange das hab ich.:-) Gruß Wolfgang
Angehängte Dateien:
-
nullpunkt.png
933 Bytes
Wie wäre es mit einer Auswahl wo der Nullpunkt liegen soll? Braucht ja nicht viel Platz...
Wolfgang B. schrieb: > Hallo Albert M., > wenn ich für einer Frontplatte ein 20mm x 80mm (BxH) Durchbruch auf > der Position Y60mm X160mm benötige muss ich erstmal umrechnen. > > X1 = X160-80/2 > Y1 = Y60-20/2 > Y2 = Y1+20 > X2 = X1+80 > > Albert das war keine Kritik sondern nur ein Vorschlag den Jop > zu vereinfachen. Deine Gedankengänge versteh ich jetzt nicht. Ich glaube Du denkst da viel zu kompliziert :) Es ist ganz einfach: Unter Startpunkt (Ecke links unten) eingeben: X1 = 160 , Y1 = 60 Das sind ja die Entfernungen von Deinem gewählten Nullpunkt auf den sich alle weiteren Angaben beziehen. Unter Endpunkt (Ecke rechts oben) eingeben: X2 = 160 + 20 , Y2 = 60 + 80 Fertig
sven schrieb: > Wie wäre es mit einer Auswahl wo der Nullpunkt liegen soll? > Braucht ja nicht viel Platz... Da gibt es nichts auszuwählen. Den legt man einmalig fest. Der Nullpunkt auf den sich alle Job-Koordinaten beziehen ist der bei der Fräse aktuell gesetzte Nullpunkt. Am Besten legt man den auf die linke untere Ecke seines Werkstückes, kann aber auch sonst wo liegen. Alle eingetragenen Jobs in der Liste beziehen sich ausschliesslich auf diesen Nullpunkt.
Albert M. schrieb: > Es ist ganz einfach: > so einfach ist das nicht, Die Position Y60mm X160mm ist der Mittelpunkt des Rechteck.:-(
>Unter Startpunkt (Ecke links unten) eingeben: >X1 = 160 , Y1 = 60 >Das sind ja die Entfernungen von Deinem gewählten Nullpunkt >auf den sich alle weiteren Angaben beziehen. >Unter Endpunkt (Ecke rechts oben) eingeben: >X2 = 160 + 20 , Y2 = 60 + 80 das Objekt wird beschrieben Ecke links unten X1 160, Y1 60 und Ecke rechts oben X2=X1+20, Y2 = Y1+80. das heißt ich brauch X1 und Y1 (Startpunkt Ecke links unten), des weiteren X2=X1+Breite, Y2=Y1+Länge (Ecke rechts oben)! beim Mittelpunkt des Objekt brauch ich lediglich X,Y die Position und Länge und Breite des Objeckt die bekannt sind! Die Fräser Position + Kompensation kann das Programm berechnen. ist ähnlich wie bei einen Kreis Kreismittelpunkt + radius was soll's war nur ein Vorschlag.
Wolfgang B. schrieb: > brauch ich lediglich X,Y die Position und Länge und Breite des Objeckt Wenn das Objekt parallel zur Achsen liegt, kann man nach Lust und Laune das Objekt beschreiben(bemaßen). Es sieht anders aus, wenn dies ein beliebigen Winkel zur Achsen hat, beschreibt man übriger weise erst die Lage und dann die Eigenschaften.
Tany schrieb: > Es sieht anders aus, wenn dies ein > beliebigen Winkel zur Achsen hat auch das lässt sich über den Winkel zur Achse berechnen. Wolfgang
So, der Test mit dem Display auf dem Arduino-Uno war erfolgreich! Dort habe ich nicht das SPI-TFT sondern ein 128x128 T6963 LCD angeschlossen. Der eigentliche sporadische Fehler für Scchrott-Zeichen war die fehlende 0-Ende-Kennung des LCD-Strings! Alles funktioniert nun wunderbar! Als nächstes kommen Tasten und Endschalter Abfragen sowie Referenzfahrt hinzu! @Albert: hier nochmal ne kleine Liste mit Bugs und Wünschen: 1) BUG: Wenn man eine HPGL Datei einlädt (habe etliche versucht), kommt beim druck auf "Process Datei" eine Fehlermeldung: "ist kein gültiger Gleitkommawert! 2) BUG: 2.Serielle COM3 (z.B.) ist dargestellt, connect geht aber erst, wenn man die COM3 erneut anwählt! (Nur, wenn das Prg neu gestartet wurde!) 3) Wunsch: Feedrate in ini datei abspeichern und beim start wieder einladen und auch setzen! 4) Wunsch: Spindel Wert in ini datei abspeichern und beim start wieder einladen und auch setzen! 5) Wunsch: Move mm Wert in ini datei abspeichern und beim start wieder einladen und auch setzen! 6) BUG: Wärend des Fräsens darf der Easy-Job nicht anwählbar sein! 7) BUG?: Maximize Window nicht anwählbar. 8) Wunsch: EasyJob: Tisch plan fräsen, Angabe von Xmax,Ymax, Fräser dm. 9) Wunsch: Weiterleitung der Endschalter von GRBL zur 2. Seriellen 10) Wunsch: Anzahl der Programmdurchläufe mit einstellbaren Z Zähler/Durchlauf. Gruß, Wolfram.
Ich möchte mich dieser "Wunschliste" von Wolfgang gern anschließen mit der Bitte an Ullrich, diese Vorschläge in die nächsten Releases evtl. nach und nach mit einfließen zu lassen. Interessant wäre bei dem Easyjob vielleicht noch die Möglichkeit, auch Lochfelder zu bohren mit Angabe von X und Y x Anzahl Löcher mit Abstand n Vielen Dank für deine Arbeit. Kann ich ständig nur wiederholen.
Hardy F. schrieb: > Ich möchte mich dieser "Wunschliste" von Wolfgang gern anschließen mit Wolfram, nicht Wolfgang :-)
Angehängte Dateien:
-
CNC_Apps.png
150 KB
Hardy F. schrieb: > Interessant wäre bei dem Easyjob vielleicht noch die Möglichkeit, auch > Lochfelder zu bohren mit Angabe von X und Y x Anzahl Löcher mit Abstand so?
Hi Wolfram F. schrieb: > 8) Wunsch: > EasyJob: Tisch plan fräsen, Angabe von Xmax,Ymax, Fräser dm. Tasche Rechteck sollte Das machen, wobei ich da dann auf Maschinen-Koordinaten gehen würde und nicht die Eingabe vom aktuellen Nullpunkt aus, da sich Dieser wohl mit jedem Werkstück ändert, der Tisch selber aber wohl 'an Ort und Stelle' bleibt. Müsste im Keller gucken, was ich mir da aufgekritzelt habe, benutzte aber auch LinuxCNC an meiner Käse-Fräse. MfG
ja, würde auch gehen, dann als Makro speichern. Da an meinem SCC-Display auch noch Taster und die Endschalter abgefragt werden, wäre der Maschinen-Nullpunkt auch kein Problem.
@ Tany Das ist ja schon eine Größenordnung weiter als ich es mir vorstellte. Also noch besser ! Sehr gute Erweiterung. Möge es ebenfalls eine Anregung für Ulrich Albert sein.
@Wolfgang B. Thema Jog-Dial... welchen Alps Encoder hast Du denn für Dein Jog-Dial verwendet? Ich hab Interesse an Deinem kleinen Projekt gefunden und würde das ggf. gerne nachbauen und daher gerade bei TME geschaut, den aber irgendwie nicht gefunden. Danke für eine kurze Info...
Torsten K. schrieb: > welchen Alps Encoder hast Du denn für Dein Jog-Dial verwendet? hatte ich noch in der Bastelkiste rumliegen steht leider nur Alps drauf.:-( ALPS STEC11B müsste passen ggf. die Achse kürzen. Gruß Wolfgang
dafür kann man anstelle eines Encoders auch prima einen Schrittmotor nehmen! Siehe hier : http://www.b-pahl.de/bastel/portalfraese/handrad/inkrementalgeber.GIF http://www.b-pahl.de/bastel/portalfraese/handrad/handrad.html Funktiert super und ist robust! Ist an meiner Fräse für die Feedrate mittels Pokeys und MACH3 angeschlossen.
Hallo Wolfgang, zuerst mal Entschuldigung für die lange Pause, ich habe wohl mal verpasst, mich hier einzuloggen, und somit den Fortgang verpasst. Den Trick mit der Hardware Lösung für die Kommunikation meines Joystick muss ich unbedingt verifizieren, klingt aber erst mal genial :-) Danke dafür! Es kann aber durchaus sein, dass mein Controller nicht schnell genug ist, um die Analogdaten der drei Joysticks genügend schnell einzulesen, so dass ein kontinuierlicher Datenstrom für den GRBL zur Verfügung gestellt werden kann. Momentan klappte es ganz gut für eine Achse, doch sobald eine dazu kommt, stockten die Motoren. Es kann also gut sein, dass die Umwandlung der drei analogen Werte in Jog-Kommandos auf dem Rechner erfolgen muss. Damit wäre das Thema für SCC gestorben. Ich werde berichten. Gruß Harald
Hallo Albert M. Ich habe heute den Easy Job ausprobiert.. Das abgerundete Rechteck. Wie ich festgestellt habe gibt es bei Fräser innen aussen mitte keinen Unterschied.. Wenn ich x2 und y2 auf 20mm setze, sage ich habe einen 8mm Fräser und der soll aussen fahren, müsste er dann nicht zb 28mm oder 36mm verfahren? Er hält sich strickt an die Koordinaten und mein 20x20mm Quadrat wird 12x12mm !? MfG Dominic
Hallo Wolfgang B. Danke für Deine Antwort zum Drehgeber. Es ist wahrscheinlich völlig egal wieviele Impulse pro Umdrehung ausgegeben werden. Ich denke ich nehme einen mit 24 Pulsen pro 360Grad. Ich hab das mal alles in KiCad eingegeben und damit auch gleich die Platinenumrisse entsprechend der Hammond Gehäuse Spezifikation angegeben. Ich versuche auch, dass die Platinen mittels Steckkontakte verbunden werden. Wenn Du das ggf. als Gerberdatei haben möchtest sowie dann die fertigen KiCAD Dateien, kann ich Dir diese gerne zusenden. Noch muss ich einige Arbeiten in KiCAD abschliessen und die Bauteilabstände prüfen. LG Avantasia (Torsten K.)
Avantasia schrieb: > Wenn Du das ggf. als Gerberdatei haben möchtest sowie > dann die fertigen KiCAD Dateien, kann ich Dir diese gerne zusenden. Danke für das Angebot, aber das ist nicht nötig. viel Spass beim Basteln. Gruß Wolfgang
Dominic H. schrieb: > Wenn ich x2 und y2 auf 20mm setze, sage ich habe einen 8mm Fräser und > der soll aussen fahren, müsste er dann nicht zb 28mm oder 36mm > verfahren? nein wenn x2 und y2 = 20mm dann ist x1,y1 = 0 und der Fräser auf -4mm und 24mm, Radius der Ecken = 0 ich habe es mir gerade angeschaut mit und ohne Radius da ist kein Fehler. Gruß Wolfgang
@Dominic alles zurück.:-( Das abgerundete Rechteck beim Easy Job ist doch fehlerhaft. Die Fräser Kompensation wird nicht berücksichtigt. hab mich von der Graphic Anzeige Täuschen lassen.:-( Gruß Wolfgang
Wolfgang B. schrieb: > Das abgerundete Rechteck beim Easy Job ist doch fehlerhaft. > Die Fräser Kompensation wird nicht berücksichtigt. Sorry, Fräser Kompensation ist zwar im Programmcode drin, wird aber falsch aufgerufen. Wird zur nächsten Version berichtigt.
Warum Albert beim "Rectangle Rechteck fräsen“ "Rounded Rectangle Rechteck mit gerundeten Ecken fräsen Eckenradius wählbar“ zwei Jops macht ist mir unergründlich. Wolfgang
Hallo, viel Arbeit so ein Programm. Es ist sehr unvorteilhaft wenn man das Programm nicht anhalten kann ohne Notaus zu machen. z.B bei Werkzeugwechsel ohne Probe. Ich habe versucht aus dem Forum etwas zu erfahren aber ohne Erfolg.Wenn ich nun ein Notstop mache sind die Positionsdaten weg. Ich helfe mir indem ich die Daten aufschreibe und nach einem Reset wieder per Hand mit dem gemerkten Offset wieder auf die alte Position fahre. Diese Prozedur ist auf die Dauer nicht praktikabel. Ich möchte hier nicht stänkern, nur eine Antwort auf meine Fragen. Mit freundlichen Grüßen Udo
Udo schrieb: > Es ist sehr unvorteilhaft wenn man das Programm nicht anhalten kann ohne > Notaus zu machen. z.B bei Werkzeugwechsel ohne Probe. Den laufenden G-Code kann man mittels den nicht zu übersehenden Halt/Weiter Buttons anhalten und weiter laufen lassen. Da das Lesen des Manuals vielleicht mühsam ist zitiere ich hier gerne nochmal den Abschnitt über Werkzeugwechsel: Werkzeugwechsel Txx Automatischer Werkzeugwechsel wird von GRBL nicht unterstützt. SerialComCNC unterstützt jedoch einen manueller Werkzeugwechsel und reagiert auf die Werkzeugwechsel-Befehle Txx im G-Code: Wenn die Checkbox "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, werden die Steppermotoren mittels M0 angehalten, die aktuelle Position gespeichert und die Z-Achse um den Wert in der "Change Pos" Eingabe-Box 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-Achse und danach die Z-Achse werden nun auf die gespeicherte Position gefahren und das G-Code Programm fortgesetzt.
Hallo, und danke für die schnelle Antwort. Natürlich konnte ich das Programm anhalten und weiter fahren lassen. Die Funktion Toolwechsel funktioniert wie beschrieben bei mir nicht. Der Haken ist gesetzt. Im Programm steht an den Wechselpositionen der Befehl M6 T2 z.B. hintereinander. Ich habe dann selber den Befehl M00 reingeschrieben dann hielt die Maschine an. Aber die Lösung war das natürlich für mich nicht. Ich habe die letzte Softwareversion installiert. Gibt es noch ein Parameter was diese Funktion sperrt ? Gruß Udo
Udo schrieb: > Die > Funktion Toolwechsel funktioniert wie beschrieben bei mir nicht. Der > Haken ist gesetzt. Im Programm steht an den Wechselpositionen der Befehl > M6 T2 z.B. hintereinander. M6 muss entfallen, einfach nur T2 alleine in eine Zeile schreiben. Wenn der Interpreter T2 oder weitere Tx erreicht erfolgt die Meldung: Werkzeugwechsel T2 steht bevor. Ende der laufenden Bearbeitung (Idle) abwarten. Die Maschine hält bei Erreichen von T2 an. Die aktuelle Position wird gespeichert und die Achsen können über das Bedienfeld verfahren werden. (Die Verfahrweite muss vorher in "Move mm" festgelegt sein) Nach Werkzeugwechsel weiter mit "Cont" ("Weiter"). Es wird dann über die gespeicherte Position fortgefahren.
Hallo Albert, darf ich hier einhaken und nach dem Nullen der Z-Achse nach dem Werkzeugwechsel fragen? Merkt sich SCC nicht nur die Koordinaten des Txx-Stop, sondern rechnet ebenfalls den neuen Tool-Offset des getauschten Werkzeugs mit ein, wenn ich eine erneute Probe-Fahrt mit dem neuen Werkzeug durchführe? Ist also die Spitze des neuen Werkzeugs an exakt der identischen Position wie die des alten, ausgewechselten Werkzeugs, wenn ich "Cont" klicke (bzw. geklickt habe)? Du hast ja den Absatz aus der Anleitung kopiert, dort steht aber nicht (oder ist zumindest für mich nicht erschließbar), ob ich "mechanisch" beim Einspannen des neuen Werkzeugs für die gleiche Werkzeuglänge sorgen muss, oder ob SCC mich dabei unterstützt (und wenn ja, wie?). Eine kurze Erklärung würde für mich die Sache durchschaubar machen. Danke! Gruß Harald
Hallo Harald, Harald S. schrieb: > ob ich "mechanisch" beim Einspannen des neuen Werkzeugs > für die gleiche Werkzeuglänge sorgen muss Zur Zeit wahrscheinlich ja, siehe unten. >oder ob SCC mich dabei unterstützt (und wenn ja, wie?). Vielleicht: Ich noch nie getestet, ob man die Probe Funktionen von SCC gefahrlos während des Anhaltens nach Tx nutzen kann und ob das überhaupt machbar ist. Leider kann ich diesen Test momentan nicht durchführen, weil ich meine China Fräse wieder mal verliehen habe.
Hallo Albert, nun, ich hätte erwartet, dass du die Funktion "Probe nutzen" explizit in die Bearbeitung der Werkzeugwechsel-Funktion hättest einprogrammieren müssen. Immerhin müsste dafür ja ein neuer Offset für die Z-Achse mit eingerechnet werden, wenn mit "Cont" an die alte Stelle zurück gefahren wird, um mit dem Job fortzufahren. Da du nicht weißt, ob das geht, gehe ich mal davon aus, dass du das nicht getan hast. Und somit würde ich das Probing während Txx in die Ecke "eher unwahrscheinlich" schieben (weil ich mir nicht so recht vorstellen kann, dass so eine komplexe Funktion automatisch mit abfällt). Was müsste ich denn tun, wenn ich die Funktionalität überprüfen wollte?
Harald S. schrieb: > Was müsste ich denn tun, wenn ich die Funktionalität überprüfen wollte? Ich sehe gerade das geht nicht, da der Probe Button P während der Verarbeitung gesperrt ist. Ich werde mich um diese Thematik aber demnächst kümmern.
Ok, danke! :-) [edit] Ich habe gerade mal in der aktuellsten Version SCC 2.2 eine NC-Datei mit 3 Werkzeugen eingespielt und versucht, wenigstens mit den Tasten mal ein bisschen zu verfahren. Leider Fehlanzeige. Der Job pausiert mit dem Hinweis auf Werkzeugwechsel, dann tut sich erst mal nichts. "Weiter" ist inaktiv. Ich muss also "Halt" klicken, damit "Weiter" funktioniert. In der Zeit zwischen "Halt" und "Weiter" reagiert meine Version von SCC auf nichts, alle Tasten in den Feldern "Set" und "Manueller Prozess" sind deaktiviert. Habe ich da etwas übersehen? [\edit] Gruß Harald
@Wolfgang B. eine kleine Frage habe ich noch zu Deiner Jog-Dial Schaltung... wenn ich es richtig verstehe, dann ist der Jog-Dial Drucktaster (Home) parallel zum Taster 8 (Spindel Stop/Weiter) geschaltet. Ist das korrekt interpretiert? Sprich durch alt+Jog-Dial Taster wird eine Homefahrt veranlasst? Gleiches würde dann doch auch bei alt+Taster 8 ausgelöst oder? Lieben Dank für eine kurze Antwort...
Harald S. schrieb: > Ich habe gerade mal in der aktuellsten Version SCC 2.2 eine NC-Datei mit > 3 Werkzeugen eingespielt und versucht, wenigstens mit den Tasten mal ein > bisschen zu verfahren. Ich hatte eben schon geschrieben: Die Verfahrweite muss vorher in "Move mm" festgelegt sein. (Vor Start des G-Codes. Wird demnächst geändert) > Leider Fehlanzeige. Der Job pausiert mit dem Hinweis auf > Werkzeugwechsel, dann tut sich erst mal nichts. > "Weiter" ist inaktiv. Ich muss also "Halt" klicken, damit "Weiter" > funktioniert. Ich habs gerade noch mal getestet, "Weiter" ist bei mir bei jedem T aktiv und lässt sich bedienen. Natürlich das "Weiter" neben dem "Start" Button.
Torsten K. schrieb: > Sprich durch alt+Jog-Dial Taster wird eine Homefahrt veranlasst? > Gleiches würde dann doch auch bei alt+Taster 8 ausgelöst oder? keine Home/Referenzfahrt sondern Home/Nullpunktfahrt. ja, hab ich so beschaltet dass man auch ein Rotaryencoder ohne Taster verwenden kann. Wolfgang
Alles klar, Danke für Deine Antwort Wolfgang.
Albert M. schrieb: > Die Verfahrweite muss vorher in "Move mm" festgelegt sein. Ah, das war mir nicht klar, danke! > Natürlich das "Weiter" neben dem "Start" Button. Bei mir sind beide "Weiter" inaktiv. Vielleicht fehlt noch etwas im G-Code? Ich erzeuge die NC-Datei mit Estlcam V8. Muss ich morgen mal anschauen... Gruß Harald
Harald S. schrieb: > Bei mir sind beide "Weiter" inaktiv. > Vielleicht fehlt noch etwas im G-Code? > Ich erzeuge die NC-Datei mit Estlcam V8. Hallo Harald, das Problem liegt bei ESTLCAM. Das Programm erzeugt bei einem Werkzeugwechsel keinen Tx Befehl, sondern nur M00 (wobei SCC auch stoppt). Um die Funktionen von Albert zu nutzen mußt du einfach im Editor den M00 Befehl in einen Tx Befehl ändern, dann funktioniert alles so wie im Handbuch beschrieben :-) Viele Grüße Sven @Albert: Tolles Programm, Tausend Dank!!
Harald S. schrieb: > ob ich "mechanisch" > beim Einspannen des neuen Werkzeugs für die gleiche Werkzeuglänge sorgen > muss, oder ob SCC mich dabei unterstützt Hallo Harald, Albert, das ist richtig, die Werkzeuglängen müssen exakt gleich sein oder das Offset zwischen den Werkzeugen in deiner Frätiefe in der Fräsdatei berücksichtigen. Vielleicht würde es einfach gehen, wenn man Zugang zum Nullen der Z-Achse beim Werkzeugwechsel hätte. Dann könnten man das wenigstens Manuell machen...oder was meinst du dazu, Albert? Viele Grüße Sven L.
Sven L. schrieb: > Vielleicht würde es einfach gehen, wenn man Zugang zum Nullen der > Z-Achse beim Werkzeugwechsel hätte. Dann könnten man das wenigstens > Manuell machen...oder was meinst du dazu, Albert? Das wäre zuerst mal die einfachste Lösung! Ich werde in der nächsten Version während des Werkzeugwechsel die Boxen "Manueller Prozess" und "Set" freigeben, so dass beliebiges Verfahren sowie ein Nullen der Z Achse über den Button Z0 möglich ist. Für das Nextion Display (zweite Schnittstelle) muss dann nur noch auf der Monitor Page die Möglichkeit zum Z-Nullen geschaffen werden. Um die Page nicht zu überfrachten würde ich die Beschriftungen (links) der Achsenanzeigen X Y Z als Buttons umfunktionieren. Also mit Touch auf die jeweilige Beschriftung wird die entsprechende Achse genullt. Was meint ihr?
Hallo Albert, ich habe bemerkt wenn ein Prozess läuft (Gcode oder HPGL) man über die zweite Schnittstelle JogBefehle senden kann. Das stört natürlich den Ablauf erheblich. Wie hast Du das den mit den Nextion Display gelöst? Eigendlich sollte die Annahme von Befehle über die zweite Schnittstelle während des Prozesslauf bis auf Nothalt/Halt Weiter ggf. Werkzeugwechsel gesperrt sein. Vermutlich vehält sich das mit den Nextion Display genau so. Gruß Wolfgang
habe heute den ganzen Tag getestet mit dem Ergebnis das ich mir etwas kauf was funktioniert.
Sven L. schrieb: > im > Editor den M00 Befehl in einen Tx Befehl ändern, dann funktioniert alles > so wie im Handbuch beschrieben :-) Hallo Sven, das war der Trick, danke für den Hinweis! Gruß Harald
Albert M. schrieb: > > > Ich werde in der nächsten Version während des Werkzeugwechsel die Boxen > "Manueller Prozess" und "Set" freigeben, so dass beliebiges Verfahren > sowie ein Nullen der Z Achse über den Button Z0 möglich ist. > Hallo Albert M., vor einiger Zeit habe ich schon mal vorgeschlagen, doch auch die Einstellung des Toolwechselbuttons in der ini Datei abzuspeichern. Vielleicht lässt sich das nun realisieren, wenn's nicht nur für mich von Interesse ist ?! Habe den easyjob verwendet, um den Gehäuseausschnitt für das Nextion Display zu fräsen. Danke für die wesentliche Erweiterung von SCC. Viele Grüße Herbert
Wolfgang B. schrieb: > ich habe bemerkt wenn ein Prozess läuft (Gcode oder HPGL) > man über die zweite Schnittstelle JogBefehle senden kann. > Das stört natürlich den Ablauf erheblich. > Wie hast Du das den mit den Nextion Display gelöst? Wird in einer der nächsten Versionen geändert, incl. Nextion. Sven L. schrieb: > das Problem liegt bei ESTLCAM. Das Programm erzeugt bei einem > Werkzeugwechsel keinen Tx Befehl, sondern nur M00 (wobei SCC auch > stoppt). Um die Funktionen von Albert zu nutzen mußt du einfach im > Editor den M00 Befehl in einen Tx Befehl ändern, dann funktioniert alles > so wie im Handbuch beschrieben :-) Werde ich im Manual vermerken. Herbert Janssen schrieb: > vor einiger Zeit habe ich schon mal vorgeschlagen, doch auch die > Einstellung des Toolwechselbuttons in der ini Datei abzuspeichern. Kommt mit der nächsten Version. Herbert Janssen schrieb: > Habe den easyjob verwendet, um den Gehäuseausschnitt für das Nextion > Display zu fräsen. Danke für die wesentliche Erweiterung von SCC. Freut mich und Danke. Den Fehler im EasyJob beim Rounded Rectangle (Innen/Aussen) habe ich inzwischen behoben und den G-Code für die ARCs von I und J Parameter auf den R Parameter umgestellt. Das vereinfacht nicht nur die Programmierung, sondern macht auch den erzeugten G-Code leserlicher.
Angehängte Dateien:
-
EasyJob_2.3.png
91 KB
Anbei neue Version SerialComCNC 2.3 Change Log V2.3 --------------- EasyJob - Neuer Job Circle Fräst einen Kreis, Fäser mittig/innen/aussen. - Rounded Rectangle Modi Innen/Aussen jetz funktionsfähig. Box Toolwechsel Txx - Status wird bei Programmende gespeichert, incl. Txx Pos Z Nextion Display Schnittstelle - Status der Port Nummer wird nun korrekt gespeichert. - Neues Kommando beim Empfang von Daten: "SetZ0" Nullt die Z-Achse, hilfreich bei Werkzeugwechsel Werkzeugwechsel - Während eines Werkzeugwechsel wird die "Set" Box freigegeben, so dass volles Verfahren, sowie Nullsetzen von Z möglich ist. Zur Sicherheit sollte man nach dem Tx des Werkzeugwechsel im G-Code eine Zeile mit dem gewünschtem Feed für G1 des nächsten Befehls eingeben, falls dieser keine Feed Information beinhaltet. - Während des Werkzeugwechsel ist ein Nullsetzen der Z-Achse mittels Z0 Button oder auf dem Nextion Display durch Tippen auf die Z Beschriftung (links der Z-Anzeige) auf der Monitor Page möglich. - Button Home im "Manuellen Prozess" wird nun immer nach einem beendetem G-Code Programm wieder freigegeben. Update des PDF-Manuals, aufrufbar über Menue Hilfe, sowie des Online Manual auf der Webseite. Gruss Ulrich Albert http://www.serialcominstruments.com/
Super Job Albert, vielen Dank. Dein Programm wird immer besser!!! Viele Grüße Sven L.
Super Albert!
Allerdings sind mir 2 Dinge aufgefallen:
1) man muss noch immer auf (z.B.) COM3 bei der 2.Seriellen klicken bzw.
neu auswählen, erst dann funktioniert ein Connect, also wie bisher.
2) Wenn man beim /EasyJob/Circle die Tiefe Z=10 einstellt und bei Z
Zustellung 3, dann fräst er 3,6,9 und 12mm! Es dürfte aber beim letzten
Durchgang nie mehr als in Z-Tiefe eingestellt gefräst werden!
Müsste also so aussehen: 3,6,9,10mm.
If Zustellung >= Tiefe
{
Zustellung = Tiefe
}
Das gleiche gilt auch für die Rechteck Funktion!
Wenn das wie o.g. funktionieren sollte, hätte man die Möglichkeit,
z.B. Tiefe=10, Zustellung=3.3 einzugeben und es würde der letzte
Durchgang schön fein mit 0.1 gefräst.
Wolfram F. schrieb: > man muss noch immer auf (z.B.) COM3 bei der 2.Seriellen klicken bzw. > neu auswählen, erst dann funktioniert ein Connect, also wie bisher. Bei mir funktioniert das auf zwei PCs unter Win 7 und Win XP. Daher ist es schwierig diesen Fehler zu lokalsieren. Welches Betriebssystem nutzt Du? Wolfram F. schrieb: > Wenn man beim /EasyJob/Circle die Tiefe Z=10 einstellt und bei Z > Zustellung 3, dann fräst er 3,6,9 und 12mm! Es dürfte aber beim letzten > Durchgang nie mehr als in Z-Tiefe eingestellt gefräst werden! > Müsste also so aussehen: 3,6,9,10mm Da hast Du Recht. Wird in der nächsten Version für alle Jobs geändert.
Anbei neue Version SerialComCNC 2.3.1 Change Log V2.3.1 ----------------- EasyJob - Fehler bei der Zustellung behoben. Die Zustellung kann jetzt nicht mehr grösser als die eingestellte Tiefe Zd werden. Die Korrektur wurde bei allen Jobs vorgenommen. Sonstige Änderungen siehe oben bei Version 2.3 Gruss Ulrich Albert http://www.serialcominstruments.com/
ich benutze win10/64, an der Fräse aber XP. Problem mit der COM ist behoben! Funktioniert nun! Ebenso das mit der Zustellung! Allerdings ist da ein "schönheitsfehler": Wie im Beispiel habe ich Z-Tiefe auf 10mm und Zustellung auf 3.3mm gestellt, im GCODE steht dann G1 Z-3.29999995231628 G1 Z-6.59999990463257 G1 Z-9.89999961853027 Die Anzeigen und das Display zeigen aber die richtigen Werte an (3.3/6.6/9.9/10) Danke Albert! Klasse Programm!
Wolfram F. schrieb: > Allerdings ist da ein "schönheitsfehler": > Wie im Beispiel habe ich Z-Tiefe auf 10mm und Zustellung auf 3.3mm > gestellt, > im GCODE steht dann > G1 Z-3.29999995231628 > G1 Z-6.59999990463257 > G1 Z-9.89999961853027 Vielleicht hast Du die letzte G-Code Zeile übersehen :) Da steht bei mir dann richtigerweise (bei Drill Hole): F100 G1 Z-10 Das passt dann damit zusammen: Wolfram F. schrieb: > Die Anzeigen und das Display zeigen aber die richtigen Werte an > (3.3/6.6/9.9/10)
nein, die habe ich gesehen! So soll es sein! kam mir nur komisch vor, das da soviele Nachkommastellen sind! denn 3.3 + 3.3 sind ja 6.6 und nicht 6.59999.... :-)
Wolfram F. schrieb: > kam mir nur komisch vor, das da soviele Nachkommastellen sind! > denn 3.3 + 3.3 sind ja 6.6 und nicht 6.59999.... :-) Ja, da habe ich die Format-Routine die ich sonst benutze vergessen. Die Rundungsfehler lassen sich prinzipbedingt bei Fliesskomma-Berechnungen nicht vermeiden. Die Fräsgenauigkeit wird dadurch nicht beeinflusst. In der nächsten Version setzte ich die Format-Routine wieder ein, die dann die Rundungsfehler weitmöglichst eliminiert (3 oder 4 Nachkommastellen). Ich will dafür jetzt nicht direkt wieder eine korrigierte Version hier abladen :)
Prima! Wie ist denn deine Meinung zu den Bugs/Wunschliste? 1) BUG: Wenn man eine HPGL Datei einlädt (habe etliche versucht), kommt beim druck auf "Process Datei" eine Fehlermeldung: "ist kein gültiger Gleitkommawert! ##################### erledigt ################################## 2) BUG: 2.Serielle COM3 (z.B.) ist dargestellt, connect geht aber erst, wenn man die COM3 erneut anwählt! (Nur, wenn das Prg neu gestartet wurde!) ################################################################# 3) Wunsch: Feedrate in ini datei abspeichern und beim start wieder einladen und auch setzen! 4) Wunsch: Spindel Wert in ini datei abspeichern und beim start wieder einladen und auch setzen! 5) Wunsch: Move mm Wert in ini datei abspeichern und beim start wieder einladen und auch setzen! 6) BUG: Wärend des Fräsens darf der Easy-Job nicht anwählbar sein! 7) BUG?: Maximize Window nicht anwählbar. 8) Wunsch: EasyJob: Tisch plan fräsen, Angabe von Xmax,Ymax, Fräser dm. 9) Wunsch: Weiterleitung der Endschalter von GRBL zur 2. Seriellen 10) Wunsch: Anzahl der Programmdurchläufe mit einstellbaren Z Zähler/Durchlauf.
Wolfram F. schrieb: > Wie ist denn deine Meinung zu den Bugs/Wunschliste? > > 1) BUG: > Wenn man eine HPGL Datei einlädt (habe etliche versucht), kommt beim > druck auf "Process Datei" eine Fehlermeldung: > "ist kein gültiger Gleitkommawert! Jeder Grafik/Draw/CAD Programm Hersteller kocht sein eigenes HPGL Formate Süppchen, inzwischen gibt es über 30 Derivate, die ich nicht alle supporten kann und will. Es gibt einige HPGL Format-Konverter, vielleicht die mal auf Brauchbarkeit prüfen. Stelle mal einige Zeilen Deines HPGL Codes hier ein. Vielleicht fällt mir da auf Anhieb was auf. Wolfram F. schrieb: > 2) BUG: 2.Serielle COM3 (z.B.) ist dargestellt, connect geht aber erst, > wenn man die COM3 erneut anwählt! (Nur, wenn das Prg neu gestartet > wurde!) Dazu hatte ich ja bereits oben was geschrieben. Wolfram F. schrieb: > 3) Wunsch: > Feedrate, Spindel Wert und Move mm in ini datei abspeichern und > beim start wieder einladen und auch setzen! Die Werte werden ja bereits gespeichert und wieder geladen. Das Setzen der Werte beim Laden möchte ich aus Sicherheitsgründen vermeiden, da man durch das händische Akzeptieren der Werte nochmal darüber nachdenken kann :) Wolfram F. schrieb: > 6) BUG: Wärend des Fräsens darf der Easy-Job nicht anwählbar sein! Werde ich in einer der nächsten Versionen korrigieren. Wolfram F. schrieb: > 7) BUG?: Maximize Window nicht anwählbar. Das hat technische Gründe, da eine von mir benutzte Delphi Komponente da seltsam reagiert. Das Fenster lässt sich aber von Hand vergrössern. Wolfram F. schrieb: > 8) Wunsch: > EasyJob: Tisch plan fräsen, Angabe von Xmax,Ymax, Fräser dm. Werde ich in einer der nächsten Versionen in EasyJob implementieren. Wolfram F. schrieb: > 9) Wunsch: > Weiterleitung der Endschalter von GRBL zur 2. Seriellen Da werde ich mir mal irgendwann Gedanken drüber machen. Wolfram F. schrieb: > 10) Wunsch: > Anzahl der Programmdurchläufe mit einstellbaren Z Zähler/Durchlauf Bitte genauer erklären was damit gemeint ist. Und bitte nicht Wünsche und Bugs dauernd wiederholen. Alles was hier diesbezüglich geäussert wird notiere ich mir und äussere mich dazu soweit notwendig. Ich habe es ja schon mehrfach betont: Dies ist ein Hobby-Projekt und ich arbeite daran nach dem Lust-Prinzip. Mal habe ich welche und mal eine lange Zeit überhaupt nicht. Über die Sommermonate fröne ich anderen Hobbies. Wünsche arbeite ich zuerst nach meinen eigenen Anforderungen ab oder wenn ich an einer Idee Spass habe ziehe ich diese vor. Wer damit nicht klarkommt findet bestimmt Besseres. Gruss Ulrich Albert
Anbei neue Version SerialComCNC 2.3.2 Change Log V2.3.2 ----------------- EasyJob - Rundungsfehler mit vielen Nachkommastellen behoben. Die G-Code Koordinaten werden wieder mit 3 Nachkommastellen ausgegeben. Sonstige Änderungen siehe oben bei Version 2.3 Gruss Ulrich Albert http://www.serialcominstruments.com/
anbei eine plt-datei, erzeugt von CorelDraw(9) Albert M. schrieb: >> 10) Wunsch: >> Anzahl der Programmdurchläufe mit einstellbaren Z Zähler/Durchlauf > > Bitte genauer erklären was damit gemeint ist. Angenommen, ich möchte ein Loch für eine Sub-D Buchse in eine 5mm Aluplatte fräsen, wäre es cool, wenn man nur die Zeichnung macht mit der END-Tiefe und im Programm dann angeben kann, mit welcher Zustellung das GCODE Programm gefahren wird, ähnlich wie beim EasyJob/Rechteck oder Kreis! Ich weiss, normalerweise ist das Sache des CAD Programms, aber mit CorelDraw z.B. wäre das ideal. Albert M. schrieb: > Dies ist ein Hobby-Projekt... Das respektieren wir auch alle! Sind ja nur Anregungen von denen Du sicher auch etwas hast. Wir sind Dir ja so dankbar daß Du Dein Programm überhaupt öffentlich machst! Da fällt mir noch etwas ein, wie groß darf ein Makro-GCODE sein?
Wolfram F. schrieb: > anbei eine plt-datei, erzeugt von CorelDraw(9) unterstützt werden: 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 Falsch: PU4583 7338 Richtig: PU PA4583,7338 Schau mal hier nach dem Inkscape Konverter: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Vielleicht kannst Du damit die Corel plt Datei passend konvertieren. Oder gleich in Inkscape zeichnen, hab ich allerdings nie versucht. P.S. Die Bohrtiefe im SerialComCNC HPGL Konverter muss als positiver Wert eingegeben werden.
Hallo Albert, zum leidige Thema Werkzeugwechsel.:-( der Befehl "#Weiter<" nach dem Werkzeugwechseln wird über die zweite Schnittstelle nicht angenommen nur der Weiter Button im Programm. Es währe hilfreich beim Werkzeugwechsel wenn Weiter auch über die zweite Schnittstelle bzw Nextion Display angenommen wird. Für ein "Hobby-Projekt" ein Super Programm Danke. PS: ich war mal auf deine anderen Web Seiten, heiße Käfer.:-) Gruß Wolfgang
Wolfgang B. schrieb: > der Befehl "#Weiter<" nach dem Werkzeugwechseln wird über die zweite > Schnittstelle nicht angenommen nur der Weiter Button im Programm. > Es währe hilfreich beim Werkzeugwechsel wenn Weiter auch über > die zweite Schnittstelle bzw Nextion Display angenommen wird. Die Nextion Anbindung habe ich mit heisser Nadel gestrickt und konnte sie nicht überprüfen da ich Fräse und Nextion wieder mal an meinen Vater verliehen habe. Ich denke Du hast korrekt auf den Buchstaben Z auf der Monitor Page getippt. Wird schnellstmöglich korrigiert. Wolfgang B. schrieb: > PS: ich war mal auf deine anderen Web Seiten, heiße Käfer.:-) Eines meiner Sommer Hobbies :) Diesbezüglich bin ich inzwischen hauptsächlich in Facebook aktiv. Die obigen HPGL Informationen habe ich dem Manual für die nächste Version zugefügt. Wolfram F. schrieb: > Da fällt mir noch etwas ein, wie groß darf ein Makro-GCODE sein? Siehe Manual unter Menue Leiste, Makro
Albert M. schrieb: > Ich denke Du hast korrekt auf den Buchstaben Z auf der > Monitor Page getippt Ich habe leider kein Nextion Display ich benutze mein JogDail Werkzeugwechsel klappt alles Verfahren der Achsen, Nullsetzen der Z-Achse bis auf der Befehl "#Weiter<". Weiter leider nur mit Programm Button.:-( Wolfgang
Wolfgang B. schrieb: > Ich habe leider kein Nextion Display ich benutze mein JogDail > Werkzeugwechsel klappt alles Verfahren der Achsen, Nullsetzen der > Z-Achse > bis auf der Befehl "#Weiter<". Weiter leider nur mit Programm Button.:-( Müsste aber eigentlich gehen, da es mit dem Nextion funktioniert. Das Nextion sendet ja auch nur "#Weiter<". Intern wird auf den eingehenden Befehl #Weiter< von der zweiten Schnittstelle ein "~" (also Continue) an GRBL auf der ersten Schnittstelle gesendet. Zu HPGL Konverter: Google mal unter "dxf to hpgl", da gibt es so einiges.
>Müsste aber eigentlich gehen, da es mit dem Nextion funktioniert >Das Nextion sendet ja auch nur "#Weiter<". hast Du es auch mal beim Werkzeugwechsel getestet? beim Programmdurchlauf funktionieren Halt/Weiter. Wenn ein Werkzeugwechsel erfolgt ist wartet das Programm ja auf "Weiter" wird aber über die zweite Schnittstelle nicht angenommen. Habe mal versucht einfach die Tilde zusenden "#GC~<" wird auch nicht angenommen. Gruß Wolfgang
Hallo Albert, warum machst Du eigentlich beim /EasyJob/Circle 2 halb Kreise? Ich wollte den erzeugten Code mal mit meinem Vergleichen und hatte mich gewundert. Für die Funktion macht das nichts! Ausser ich will anders herum fahren. Kann ich gerade nicth testen, geht das überhaupt? Viele Grüsse, Peter
Wolfgang B. schrieb: > Wenn ein Werkzeugwechsel erfolgt ist wartet das Programm ja auf "Weiter" > wird aber über die zweite Schnittstelle nicht angenommen. > Habe mal versucht einfach die Tilde zusenden "#GC~<" > wird auch nicht angenommen. Ich habe die Ursache gefunden und korrigiert (kommt in der nächsten Version). Falls Du es übers Wochenende probieren möchtest schick mir an meine email Adresse (steht unter Info oder im Manual) eine kurze Nachricht, ich sende Dir dann die korrigierte Version zu. Bin allerdings nur noch 30 Minuten erreichbar. Peter schrieb: > warum machst Du eigentlich beim /EasyJob/Circle 2 halb Kreise? Geht natürlich auch in einer Zeile mit Vollkreis, war mir aber mit 2 Halbkreisen sicherer. Änder ich vielleicht demnächst mal. Peter schrieb: > Für die Funktion macht das nichts! > Ausser ich will anders herum fahren. Das ist für den EasyJob Modus nicht vorgesehen, ebenso wenig wie Rampen usw. Wer das braucht muss seine CAM Software benutzen.
Hallo Albert, hab dir ne mail geschickt Danke Wolfgang
Hallo Albert M. Die Idee mit dem Plan fräsen finde ich Super. Wäre gut wenn Du so etwas umsetzen kannst. Mein Kumpel Hannes fragte mich letztens danach wie er am besten das Brett Plan fräst. Das Programm was er nutzt bietet diese Möglichkeit nicht. Ich habe es bis jetzt immer mit dem Makro Modus in SCC eher umständlich realisiert. Gruß Daniel
Wolfgang B. Beitrag #4913932: jogDial_V2.01 Änderungen: V2.01 09.03.2017 - Toogle Button Halt/Weiter und alt feet F1 entfernt dafür Halt und alt Weiter der Toogle Button Halt/Weiter verursachte Störungen beim Werkzeugwechsel! über die zweite Schnittstelle dürfen wenn ein Prozess läuft (Gcode oder HPGL etc..) keine JogBefehle gesendet werden. Albert arbeitet an einer Lösung. Gruß Wolfgang
Hallo Albert, Du musst wegen mir nicht von Deinen 2 halb Kreisen weg gehen, weil funktionieren tut es ja auch so. Bei mir zeigt es sich öfter das ich je nach Material und Stärke mal so oder so herum fahren muss um ein besseres Kantenbild zu erreichen. Darum wäre andersherum fahren halt noch eine nette Variante. Wenn dann logischerweise bei allen Jobs, wenn schon unverschämt dann richtig. Bei den ganzen netten Sachen denk bitte an die ganzen wirklich hilfreichen, wie 2. Karte, aufrufbare Makros, ... . Viele Grüsse, Peter
Hallo Albert, vorschlag für eine der nächsten Versionen. Der Programmdurchlauf kann ja mit „Halt“ angehalten werden. Es währe schön wenn dann auch die aktuelle Position gespeichert wird und die Achsen zum Verfahren freigegeben werden. (ähnlich wie bein Wekzeugwechsel) Das bitet die Möglichkeiten Korrekturen vorzunehmen zB. wenn eine Spannpratze sich im Fäsweg befindet oder eine nachträgliche Nullpunkt Korrektur der Z Achse etc. Zum Fortfahren den Button "Cont" betätigt. Die X, Y-Achse und danach die Z-Achse auf die gespeicherte Position fahren und das G-Code Programm fortgesetzt. Gruß Wolfgang
ja, das vermisse ich auch sehr bei SSC...
Mir ist aufgefallen dass das Fenster in der aktuellen Version nach Beendigung und erneutem öffnen wieder seine ursprüngliche Größe hat und nicht die, in die man es gezogen hat,.. Desweiteren habe ich immer Probleme mit dem Nextion Display... Ich kann zu Anfang eigentlich alles damit machen,.. Aber dann auf einmal nicht mehr zb nach kürzerem nicht benutzen,.. Muss es dann immer abklemmen, anklemmen und neu connecten, meistens sogar SCC neu starten.. Daten empfängt es glaube ich noch, zb aktuelle Position aber es geht nichts mehr raus.. Was kann das sein und wer weiß Abhilfe? Und zu guter letzt,.. Kann ich und wenn wie kann ich in SCC einen gcode in einer bestimmten Zeile starten bzw fortführen? MfG Dom
Hallo Albert , Du wolltest Dir doch einen Bl Touch Sensor zulegen . Hast Du da schon irgendwelche Infos Drüber ? Danke Für Info und tolle Arbeit
Master Zero Point . Funktioniert nicht wirklich mehr bei mir . Nach setzen des MZP und neuem setzen des Nullpunktes wird zum neuen Nullpunkt angefahren bei go to Master Zero Point aber nicht zum MZP der ursprunglich gesetzt worden ist . Kann das jemand beständigen ? Unter Grbl 0,9 funktionierte dieses noch . Beste grüße Sven
SvenW. schrieb: > Master Zero Point . > Funktioniert nicht wirklich mehr bei mir . Master Zero Point ist nicht mehr funktionsfähig, da das Datenformat in GRBL 1.1 geändert wurde. SerialComCNC arbeitet mit Welt-Koordinaten und benötigt in der GRBL Einstellung $10=0 (senden der Welt-Koordinaten). Die für die Funktion "Master Zero Point" benötigten Maschinen-Koordinaten wurden bei GRBL 0.9 immer mitgesendet, ab GRBL 1.1 aber nur noch ab und an. Daher werden diese nicht mehr ausgewertet. Ich habe nur vergessen "Master Zero Point" zu entfernen bis eine Lösung für das Problem gefunden ist.
Albert, ich hab da auch noch ne Frage: neben den Limit Schaltern hat GRBL ja auch noch Eingänge für Tasten Abort,Hold, Resume und E-Stop. Sollte man die benutzten in Verbindung mit SCC oder besser nicht? Werden die von SCC abgefragt?
Albert M. schrieb: > bis eine Lösung für das Problem gefunden ist. Ich glaube, ich hatte dich darauf Aufmerksam gemacht, wolltest aber keine Gedanken darüber machen. Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
Hallo, ich bin zufällig auf serialComcnc gestossen und betreibe damit einen Plotter. In der Version 1.0 und Grbl 0.9J konnte ich die Enschalter aktivieren, die dann auch ordnungsgemäß funktioniert haben. Bei der Version 2.3 und Grbl 1.1f gibt es nach dem Anfahren der Endschalter und dem anschließenden Reset die Meldung Error 9. Auch durch Alarmreset lässt sich diese Meldung nicht beseitigen; erst wenn die Verbindung neu hergestellt wird, funktioniert es wieder. Über einen Hinweis zur Lösung wäre ich dankbar.
Beitrag #4935694 wurde von einem Moderator gelöscht.
Hier steht der Fehlercode: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#grbl-response-messages 9 G-code locked out during alarm or jog state Vermutlich wird das Jogging nicht wieder ausgeschaltet oder der Alarm-reset funktioniert nicht? Hier mal gucken: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging
Beitrag #4935790 wurde von einem Moderator gelöscht.
Liegt das problem bei serialcomcnc oder bei GRBL???
Wilfried W. schrieb: > Hallo, > > ich bin zufällig auf serialComcnc gestossen und betreibe damit einen > Plotter. > > In der Version 1.0 und Grbl 0.9J konnte ich die Enschalter aktivieren, > die dann auch ordnungsgemäß funktioniert haben. > > Bei der Version 2.3 und Grbl 1.1f gibt es nach dem Anfahren der > Endschalter > > und dem anschließenden Reset die Meldung Error 9. > > Auch durch Alarmreset lässt sich diese Meldung nicht beseitigen; erst > wenn die Verbindung neu hergestellt wird, funktioniert es wieder. > > Über einen Hinweis zur Lösung wäre ich dankbar. Ist wohl normal, habe ich auch.. einfach 2 mal hintereinander Alarm Reset drücken. Sollte Error 22 kommen muss die Feed Rate auch erneut gesetzt werden. MfG Dom
Sven schrieb: > Hier steht der Fehlercode: > https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#grbl-response-messages > > 9 G-code locked out during alarm or jog state > > Vermutlich wird das Jogging nicht wieder ausgeschaltet oder der > Alarm-reset funktioniert nicht? > > Hier mal gucken: > https://github.com/gnea/grbl/wiki/Grbl-v1.1-Jogging Dem ist nicht so .... Es muss ein Homing durchführt werden ... auf jeden Fall ist es bei meiner fräse der Fall und kann auch so auf Github nachgelesen werden Joggen oder ähnliches ist nicht möglich da man den Fehler nicht Quittieren kann . Abhilfe Schaft: Homefahrt. Disconect und neu verbinden oder einfach die Option abschalten @ Albert Stimmt das hattest Du erwähnt aber es war mir nicht wirklich bewusst das es auch den MZP Betrifft . Danke Für Info @ Mega-Hz Die kannst Du benutzen A5 must Du sogar, wenn Du das mit dem tasten Benutzen Möchtest und Hold Start usw leuft Problemlos bei mir
@ Albert Danke dann weiß ich ja jetzt warum @Wilfried Wurch Homefart hilft und löst das Problem hein Problem SCC sondern ist So Gewollt , nachzulesen auf : https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface#grbl-response-messages @ Wolfram Fischer (mega-hz) Ich benutze Halt /weiter und Start wie auch das Probing und konnte bisher nichts negatives feststellen in Verbindung mit SCC beim Uno A5 Probing A2 cycle start A1 feed hold
Entschuldigung für 2 mal Posten bin mit der 3ten Seite durcheinander gekommen
@Sven, ja danke für die Rückmeldung! Klingt gut! Habe mir gerade so ein Arduino-GRBL Shield bestellt (bzw. ist angekommen), musste das erstmal für die V1.1 von GRBL umstricken, D11/D12 sind ja getauscht worden! Klar, man hätte auch die Spindel am Z-Limit und Z-Limit and SpindelEN anschliessen können, aber wenn man nach nem Jahr mal reinschaut, wundert man sich. So hab ich die Leiterbahnen getrennt und mit Fädeldraht gekreuzt. Passt nun mit dem Bestückungsdruck. Hat jemand Erfahrungen mit dem Spindel-PWM Ausgang i.V. mit nem FU ? Ich habe nen Siemens Micromaster-Vector, der bislang nur manuell bedient wurde. Wie verhält sich das, wenn der nur 0-5V anstatt 0-10V bekommt? Sollte man noch nen Kondensator an den PWM zum glätten anklemmen oder geht das so?
Jogdail_V2.02 Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Änderungen: V2.02 13.03.2017 - Bug in der Statusanzeige beseitigt. V2.01 09.03.2017 - Toogle Button Halt/Weiter und alt feet F1 entfernt dafür Halt und alt Weiter der Toogle Button Halt/Weiter verursachte Störungen beim Werkzeugwechsel! Gruß Wolfgang
Wolfram F. schrieb: > Wie verhält sich das, wenn der nur 0-5V anstatt 0-10V bekommt? > Sollte man noch nen Kondensator an den PWM zum glätten anklemmen oder > geht das so? Am Pwm betreibe ich meine kress 1050 und einen laser je nach dem was ich benutze sind im Bedienfeld Schalter zum manuellen schalten , Genareal dazu gesagt, das Pwm mit dem Laser super kalbt(nicht nur an und aus sonder auch leistung von 0-255) und sich auch via relay die kress perfekt an und aus schalten lässt . alles ohne Kondensator. Benutze beim fräsen folgenden zusatz G4 Px Damit der Motor einen Moment hat um auf turen zu kommen bevor er mit dem eigentlichen gcode beginnt . G4 warte Befehl P X Zeit in sec. (x= wert in sec.) vielleicht konnte ich dir damit helfen . Grüße Sven
Wolfram F. schrieb: > Hat jemand Erfahrungen mit dem Spindel-PWM Ausgang i.V. mit nem FU ? > Ich habe nen Siemens Micromaster-Vector, der bislang nur manuell bedient > wurde. > Wie verhält sich das, wenn der nur 0-5V anstatt 0-10V bekommt? > Sollte man noch nen Kondensator an den PWM zum glätten anklemmen oder > geht das so? Hallo Wolfram, ich nutze den PWM-Ausgang in Verbindung mit einer China-Spindel. Den Controller der Spindel kann man parametrieren, dass er mit 0..10 V arbeitet (das ist der Default), aber in den Tiefen der Parametertabellen findet sich ein Wert, mit dem man den Eingang auf 0..5 V umstellen kann. SCC gibt den als Drehzahlvorgabe eingestellten Wert als 10tel% aus, soll heißen, bei 800 werden per PWM 80% Tasverhältnis am Ausgang des GRBL eingestellt. Ich habe ein R-C-Glied ein die Leitung zum Spindel-Controller eingesetzt um den Controller vor Impulsen am Eingang zu schützen, weiß aber nicht, ob das notwendig ist. Nachteil des Filters: Der Serienwiderstand verhindert, dass der Eingang des Controllers auf 5 V angehoben werden kann, er bleibt bei ca. 4,7 V maximal stehen, somit ist die Spindeldrehzahl entsprechend kleiner (22600 statt 24000). nota bene: Du kannst versuchen, über den Parameter "Maximalfrequenz bei analoger Steuerung" eine doppelt so hohe Maximalfrequenz einzustellen, so dass deine Spindel ihre Max-Drehzahl bereits bei 5 V erreicht. Achtung! Ich kenne deinen Controller nicht, habe nur in der online zu findenden Anleitung [[https://support.industry.siemens.com/cs/document/16749533]] geschmökert. Also auf eigene Gefahr!!! Harald
Hallo Albert M., leider hab ich ein fiesen Bug in SerialComCNC v2.3.2 gefunden.:-( Wenn ein Macro ausgeführt wude und man anschließend in den Menue Einstellungen geht um zum Beispiel Grapic auswählt, dann öffnet sich das Fenster "Macro“. Dieses lässt sich nicht schließen. Dadurch ist das Programm leider blokiert und lässt sich nur noch über den Taskmager beenden.:-( Mein System Win7 32Bit vielleicht kann das auch am System liegen? Gruß Wolfgang
Harald S. schrieb: > Du kannst versuchen, über den Parameter "Maximalfrequenz bei analoger > Steuerung" eine doppelt so hohe Maximalfrequenz einzustellen, genau daran habe ich auch schon gedacht. wären dann 400Hz! mal testen, wenns soweit ist. Ansonsten nen OP, der x2 verstärkt. Die 10V liefert der FU ja. Sven.W schrieb: > Genareal dazu gesagt, das Pwm mit dem Laser super kalbt(nicht nur an > und aus sonder auch leistung von 0-255) cool, hat der Laser nen TTL-Steuereingang? wäre schön, wenn mein Laser mit 200% PWM 6 anstatt 3Watt machen würde :-)
Wolfram F. schrieb: > cool, hat der Laser nen TTL-Steuereingang? > wäre schön, wenn mein Laser mit 200% PWM 6 anstatt 3Watt machen würde Ja hat TTL Meiner hat nur 1Watt da ich ihn nur zum Gravieren und Fotos verwende (In Holz ) dazu reicht er ...ich würde ihn nicht unbedingt dauerhaft überlasten das mögen die Dioden überhaupt nicht und dazu sind sie einfach zu teuer . soltest Du ihn aber zum Schneiden verwenden wollen das hat nen Kumpel von mir aufgegeben und hat sich einen Cina Plasma Laser oder war es os ?!geholt Grüße Sven
Anbei neue Version SerialComCNC 2.4 Change Log V2.4 --------------- EasyJob - Neuer Job Pocket/Tasche fräsen. Es wird zuerst innen geräumt, danach der Rand gefräst. Kann auch zum Planfräsen genutzt werden. Einstellungen - Master Zero Point entfernt. Entfällt wegen der Änderungen in GRBL ab 1.1 EasyJob Menue - Ist gesperrt während BUSY. Der neue Job Pocket ist noch experimental, also mit Vorsicht zu geniessen. Gruss Ulrich Albert http://www.serialcominstruments.com/
Albert M. schrieb: > Anbei neue Version SerialComCNC 2.4 Hallo Albert, Danke für die neue Version. Steuerung über die zweite Schnittstelle beim Werkzeugwechsel (Button Weiter) ist jetzt Einwandfrei. leider ist auch in dieser Version der Bug siehe: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Gruß Wolfgang
Wolfgang B. schrieb: > leider ist auch in dieser Version der Bug siehe: > Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit > ATMega" Wird in der nächsten Version behoben.
Wolfram F. schrieb: > Harald S. schrieb: >> Du kannst versuchen, über den Parameter "Maximalfrequenz bei analoger >> Steuerung" eine doppelt so hohe Maximalfrequenz einzustellen, Also das würde ich auf keinen Fall machen, unter umständen "platzt" die Spindel. PWM mit Tiefpass glätten und mit OP verstärken wäre der richtige Weg. Gruß Manfred
Manfred A. schrieb: > unter umständen "platzt" die Spindel Das kann nur passieren, wenn die Eingangsspannung größer als 5 V werden könnte. Da der Eingang im beschriebenen Fall aber an einem Arduino hängt, wird hier unter allen Umständen die Spannung kleiner 5 V sein. Zur Sicherheit kann er noch eine 5 V Z- Diode dranhängen. Aber ich gebe dir recht, was den richtigen Weg angeht, keine Frage. Gruß, Harald
Angehängte Dateien:
-
Jobs_Row_of_Circles_und_Pocket.png
98 KB -
Jobs.png
34 KB
Anbei neue Version SerialComCNC 2.5 Change Log V2.5 --------------- EasyJob - Neuer Job "Row of Circles" Fräst eine Reihe von Kreisen, Fräserposition innen. Richtung der Reihe und Anzahl der Kreise ist beliebig. Makros - Fehler nach Makro-Aufruf (M) im Menue "Einstellungen" behoben. Das Bild zeigt 2 Jobs (Row of Circles und Pocket) die in einem EasyJob Batch abgearbeitet wurden. Gruss Ulrich Albert http://www.serialcominstruments.com/
@ Albert Super Arbeit Danke . Bitte aber noch dran Denken und vielleicht schaffst Du es ja noch bevor Du in deine verdiente Sommer pause gehst . Nach Werzeugwechsel kein Nullen Möglich (per Z0 ) Probe auch nicht möglich. Auch ist dann noch die Manuelle Gcode Eingabe Gesperrt Set move und Set Feed Funktionieren ja mittlerweile Super ! Schade das Die Cam jetzt weg ist .....aber das sagtest Du ja schon wegen Performanz Problemen . Beste Grüße Sven
Sven W. schrieb: > Schade das Die Cam jetzt weg ist .....aber das sagtest Du ja schon wegen > Performanz Problemen . Mein fehler ist Doch noch da ... Grüße Sven
Hallo Albert,
>Fehler nach Makro-Aufruf (M) im Menue "Einstellungen" behoben.
Danke für den schnellen Fix und die Erweiterungen für EasyJob
@ Sven W. (Gast)
Nach Werkzeugwechsel Nullen der Z Achse (per Z0 ) ist ab V2.3 möglich
und Funktioniert auch.
Gruß Wolfgang
Angehängte Dateien:
-
Z_0_Werkzeugwechsel.jpg
220 KB
Wolfgang B. schrieb: > Nach Werkzeugwechsel Nullen der Z Achse (per Z0 ) ist ab V2.3 möglich > und Funktioniert auch. Egal wie oft ich Z0 klicke (Im Monitor erscheint auch G92 Z0 ) Bleibt Z Unverändert .... Habe allerdings danach nicht auf weiter gedrückt ..... um ein crash zu vermeiden Grüß Sven
Sven W. schrieb: > Egal wie oft ich Z0 klicke (Im Monitor erscheint auch G92 Z0 ) Bleibt Z > Unverändert .... wo den? In der Anzeige der Z Achse ändert sich der Wert erst nach Weiter. Probier es in einer sicheren Höhe aus. Gruß Wolfgang
Wolfgang B. schrieb: > wo den? In der Anzeige der Z Achse ändert sich der Wert erst nach > Weiter. > Probier es in einer sicheren Höhe aus. Grrrr Verdammt Du hast recht .... es geht .... ich kenne es halt nur so das sich der wert dann sofort ändert und nicht erst nach dem man weiter Drückt um auch eine Visuelle Bestätigung zu bekommen . Besten dank
im G-Code in deinem Bild würde ich Z erstmal in eine sicheren Höhe fahren nach T1 Wolfgang
Wolfram F. schrieb: > mal testen, wenns soweit ist. Ansonsten nen OP, der x2 verstärkt. > Die 10V liefert der FU ja. ha, grade ne ganz einfache Idee bekommen: man nehme einen kleine mosfet und schliesst diesen an die 0-5V pwm an, die andere seite an die +10v des FU's mit Widerstand und evt. noch nen Kondensator zum glätten, fertig ist der 0-5 zu 0-10v Wandler!
Angehängte Dateien:
Hallo Wolfram, wenn du das fertig hast, gib bitte Bescheid! Ich habe sowas schon probiert, möglicher Weise zu kompliziert (2 FETS wegen Phasendrehen), aber es hat nicht funktioniert :-( Das ist zwar fast ausschließlich digital, aber schon noch ein bisschen analog, so dass ich mich mir gegenüber rausreden konnte: Analog verstehe ich nicht bis in die letzte Konsequenz, zumindest nicht soweit wie Digital :-) Mich interessiert dieses Thema, weil der PWM-Eingang des FU mit der Filterung (Serien-R und Prallel-C) keine vollen 5 V erreicht und somit meine Spindel nur noch maximal 22000 (statt 24000) Ump schafft. Hatte ich oben schon mal erwähnt aber einen falschen Wert angegeben. Gruß, Harald
Angehängte Dateien:
-
Pegelwandlung.jpg
21 KB
Harald S. schrieb: > Ich habe sowas schon probiert, möglicher Weise zu kompliziert (2 FETS > wegen Phasendrehen), aber es hat nicht funktioniert :-( Hallo Harald, versuch es mal so. Gruß Wolfgang
Der klassische Level-Shifter... Genial!! DA hätte ich auch selbst drauf kommen können, die habe ich schon mehrfach in meinen Quadro- und HexaCoptern verbaut. Dann muss nur noch am Ausgang ein Glättungsglied eingebaut werden, ggf. mein schon vorhandener RC-Tiefpass, und schon ist alles in Butter? Werden an dem Tiefpass nicht wieder ein paar 100 Millivolt abfallen und ich bin so weit wie vorher? Gut, bei 10 V (statt 5 V) und gleichem Spannungsabfall am R bin ich dann geschätzt schon bei 23000 Upm, aber immer noch nicht Vollgas. Danke! Gruß, Harald
Harald S. schrieb: > Werden an dem Tiefpass nicht wieder ein paar 100 Millivolt abfallen und > ich bin so weit wie vorher? dann leg doch die 10V etwas höher.:-) Wolfgang
Das könnte ich ja auch mit den 5 V schon tun, aber falls da dann etwas schief geht, kann die Spindel tatsächlich durchgehen, wie von Manfred angemerkt... obwohl... das ist wohl eher ein anderes Problem als eine zu hohe Steuerspannung. Die Höchstfrequenz wird ja im FU eingestellt und sollte dann auch nicht überschritten werden, wenn die Steuerspannung über den Maxiamlwert steigt. Viel schlimmer in meinem Zusammenhang: Die 10 V wird vom FU erzeugt und zur Verfügung gestellt. Daran rumfuddeln ist nicht so mein Ding, wer weiß, wozu diese Spanung intern noch alles herhalten muss? Und dafür (für 0,3 V) außen noch einen Stepup Converter dranbauen ist dann doch etwas zu aufwändig, oder? :-) Will sagen: 22000 sind ja auch schon ganz schön schnell. Gruß, Harald
22000 sind bei meiner isel-spindel das maximum, schnell genug für alles was ich so fräse. man kann auch einfach nen max232 nehmen, aber so wie wolfgangs schaltung reicht es sicher auch. Ob das Ausgangssignal nun invertiert ist oder nicht spielt keine Rolle denk ich. Ich sag Bescheid, wenn ich es probiert habe. Noch läuft meine Fräse mit MACH3 und meiner alten 1/8tel Schritt Steuerung, GRBL ist noch nicht einsatzbereit (Gehäuse, NT usw.)
Harald S. schrieb: > Und dafür (für 0,3 V) außen noch einen Stepup Converter dranbauen ist > dann doch etwas zu aufwändig, oder? :-) > Will sagen: 22000 sind ja auch schon ganz schön schnell. Das einfachste ist doch, das PWM-Signal über einen Tiefpass auf einen "Rail to Rail" Opamp mit einstellbarer Verstärkung(X2) zu geben. Der Opamp wird durch die 10V des FUs versorgt. Am Besten du nimmst einen 2-Fach Opamp (mit Rail to Rail Ausgang) im Dip-Gehäuse. Der erste Opamp wird als Impedanzwandler hinter dem Tiefpass geschaltet, der zweite als einstellbarer Verstärker für den ersten Opamp. Diese Schaltung liefert dann auch bei 100%-PWM 10V am Ausgang. Als Opamp könnte ein TS912B funktionieren. Wichtig: An der Spannungsversorgung des Opamps direkt am Gehäuse einen Keramikkondensator 100nF anbringen. Gruß, Manfred
Dieser Opamp dürfte gehen. Nicht vergessen: Am Verorgungsanschluss des Opamps einen Keramikkondensator 100nF anbringen. Gruß, Manfred
Angehängte Dateien:
-
RollerControl4.png
3,3 MB
Hallo Manfred, du schüttelst solche Schaltungen einfach aus dem Ärmel, ja? Toll! :-) Ok, ich versuche das und berichte hier. DIP muss ja nicht sein, ich habe ein Fräse und die Lizenz zu löten, da frickle ich schnell ein Platinchen zusammen und schmeiß den Kram drauf, das klappt gut. Habe gerade gestern abend dieses gefräst: (siehe Bild) Der Bohrer im Bild hat 0,8 mm Durchmesser, die Leiterbahnen 0,3 - 0,4 mm, die Zwischenräume teilweise nur 0,1 mm. Hat mich einige Versuche und Tests gekostet, aber dann hats ganz prima geklappt. Ich habe OpenCNCPilot verwendet, weil SCC noch kein Abtasten unterstützt. Gruß, Harald
Harald S. schrieb: > weil SCC noch kein Abtasten unterstützt. Auto Levelling für Platinen-Fräsen habe ich bei mir schon als Proof of Concept in SerialComCNC erfolgreich laufen. Für ein Release dauert es aber noch etwas.
Manfred A. schrieb: > Das einfachste ist doch, das PWM-Signal über einen Tiefpass auf einen > "Rail to Rail" Opamp mit einstellbarer Verstärkung(X2) zu geben. > Der Opamp wird durch die 10V des FUs versorgt. > Am Besten du nimmst einen 2-Fach Opamp (mit Rail to Rail Ausgang) im > Dip-Gehäuse. Das mit dem Schaltung und Bauteildimensionierung wird nicht richtig Funktionieren. Du hast am Eingang vor deinem Tiefpass einen Spannungsteiler eingebaut der die 5V PWM auf max. 1,24V Gleichspannung reduziert. 100k + 33k Ohm. Der Impedanzwaldler hat keine Verstärkung und der Sollwert Opamp maximale Verstärkung von 2 was am Ausgang max. 2,48V liefert. Gruß Waldemar
Angehängte Dateien:
-
Beleuchtung_1.JPG
61 KB -
Beleuchtung_3.JPG
62 KB
Moin zusammen, meine neue Z-Achse ist nun an der Maschine, hier nun das erste Teil. MfG Klaus
Hallo, erstmal Glückwunsch zu diesem Superprogramm. Es gibt so verschiedene Übertragungen von Grbl auf 32bit Controller. Funktioniert SerialComCNC auch mit so einer geänderten Version? Oder kennt jemand eine funktionierende 32bit Grbl Version die funktioniert und auch mit SerialComCNC funktioniert? MfG Hans
Früher wurde zuerst mal ins Manual geschaut und dann gefragt. Im Manual steht alles was Du brauchst.
Albert M. schrieb: > Auto Levelling für Platinen-Fräsen habe ich bei mir schon als Proof of > Concept in SerialComCNC erfolgreich laufen. Hallo Albert, das klingt gut :-) > Für ein Release dauert es aber noch etwas. das wiederum hilft mir zur Zeit nicht weiter, weshalb ich auf die Alternative ausgewichen bin. Für andere Arbeiten verwende ich bisher weiterhin dein SCC, keine Frage. Gut ist, dass beide Tools GRBL 1.1 unterstützen, man kann leicht hin und her schalten. Gruß, Harald
Waldi schrieb: > der Sollwert Opamp maximale Verstärkung von 2 was am Ausgang max. 2,48V > liefert. Da hast du recht!. Ich hatte diesen Teil zur Anschauung aus meiner Spindelansteuerung kopiert. Dabei hatte ich übersehen, dass bei meiner Ansteuerung ja alle 5V Signale wegen der Potentialtrennung über Optokoppler zu 24V Signalen werden(24V vom FU). Die Opamps werden mit 10V vom FU versorgt. Bei einem 5V-Signal muss Teilerwiderstand natürlich raus. Ich würde allerdings nie auf eine Potentialtrennung verzichten (Störungen,Schutz der Rechnerhardware) Gruß, Manfred
Klaus S. schrieb: > Moin zusammen, > > meine neue Z-Achse ist nun an der Maschine, hier nun das erste Teil. > > MfG Klaus Schön wenn etwas funktioniert. Ich bin dazu übergegangen LED-Ringe mit Inverter für 12/24VDC zur Beleuchtung einzusetzen. Die gibt es in verschiedenen Größen für ein paar € in der Bucht Gruß, Manfred
Manfred A. schrieb: > LED-Ringe mit Inverter für 12/24VDC Tipp: die Dinger laufen auch gerne mal unter "angel eyes" Gruß Harald
Dominic H. schrieb: > Mir ist aufgefallen dass das Fenster in der aktuellen Version nach > Beendigung und erneutem öffnen wieder seine ursprüngliche Größe hat und > nicht die, in die man es gezogen hat,.. > > Desweiteren habe ich immer Probleme mit dem Nextion Display... Ich kann > zu Anfang eigentlich alles damit machen,.. Aber dann auf einmal nicht > mehr zb nach kürzerem nicht benutzen,.. Muss es dann immer abklemmen, > anklemmen und neu connecten, meistens sogar SCC neu starten.. Daten > empfängt es glaube ich noch, zb aktuelle Position aber es geht nichts > mehr raus.. > > Was kann das sein und wer weiß Abhilfe? > > Und zu guter letzt,.. Kann ich und wenn wie kann ich in SCC einen gcode > in einer bestimmten Zeile starten bzw fortführen? > Diese Probleme habe ich leider immer noch, komme auch nicht weiter. Auch versuche ich immer noch krampfhaft, da ich bei grbl eine Änderung in der config.h gemacht habe, mit winavr eine neu hex datei zu erstellen. Bei grbl 0.9 ging das ohne Probleme. Mit Eingabeaufforderung ins Verzeichnis navigiert, wo das makefile ist, make eingeben, enter gedrückt, fertig.. Jetzt bei 1.1f bekomme ich immer nur Error 1. cc1.exe: error: unrecognized command line option "-flto" make.exe:***[build/main.o] Error 1 ich verstehe da mal überhaupt nichts, und hoffe es weiß jemand Rat :( MfG Dom
Warum nimmst DU nicht den vorgeschlagenen Workflow über die Arduino IDE? https://github.com/gnea/grbl/wiki/Flashing-Grbl-to-an-Arduino
"-flto" bei dem alten WINAVR wird nicht gehen. Entweder raus werfen oder einen neueren GCC nehmen. VG, Uli
Hallo Dominic, die Erstellung einer HEX_Datei mit WINAVR hat bei mir auch nicht mehr mit GRBL 1.1 geklappt, gleicher Fehler. Habe da Problem auch mit dem Arduino IDE umgangen. Klappt super und ist eigentlich auch einfacher ;-) Viele Grüße Sven L.
Hallo liebe Gemeinde, wie schließt man den so ein Nextion Dislay eigentlich an? Man braucht das Display und ein USB-TTL Wandler und dann?? Um kurze Info wäre ich dankbar, eventuell gönne ich mir auch solch ein Teil ;-) MfG Sven
Steht in der Hilfe beschrieben :)
Toll, wenn mir die Hilfe gereicht hätte, hätte ich nicht gefragt. Solche Kommentare helfen nicht weiter...
Sven schrieb: > wie schließt man den so ein Nextion Dislay eigentlich an? Man braucht > das Display und ein USB-TTL Wandler und dann?? Bastler schrieb: > Steht in der Hilfe beschrieben :) Sven schrieb: > Toll, wenn mir die Hilfe gereicht hätte, hätte ich nicht gefragt. Solche > Kommentare helfen nicht weiter... Zitat aus der SerialComCNC Hilfe: Über die 2. Schnittstelle kann ein 3.5" Nextion Touch Display angeschlossen werden. Das passende HMI File für das Nextion ist in der SerialComCNC Distribution enthalten. Im HMI File ist die komplette Menue Struktur und interne Verknüpfungen für das Display enthalten. Die notwendigen Fonts werden ebenfalls mitgeliefert. Für die Integration des Nextion Display gehen Sie wie folgt vor: Laden Sie von der Nextion / Itead Webseite den Nextion Editor herunter und installieren diesen auf ihrem PC. Das Display benötigt 150 mA, die von der USB-Schnittstelle nicht in allen Fällen zur Verfügung gestellt werden. Ansonsten verwenden Sie eine andere 5 V DC Quelle für die Versorgung des Displays. Verbinden Sie das Display über ein Serial/USB Wandler Modul (wenige Euro über ebay) mit der zweiten Schnittstelle von SerialComCNC. Laden Sie das HMI File in den Nextion-Editor. Klicken Sie im Nextion Editor auf "Upload", stellen Sie dort die Port Nummer des Serial/USB Wandlers ein und belassen die Baudrate auf 115200. Die Nextion Schnittstelle von SerialComCNC darf dabei nicht aktiv sein! Klicken Sie auf "Go". Das compilierte HMI File wird nun auf das Display geladen. Das kann etwas dauern, den Fortschritt können Sie im Editor und dem Display sehen. Nach den Upload klicken Sie auf "Exit" und beenden den Editor. Dieser wird nun nicht mehr benötigt, es sei denn es gibt neue Version des HMI Files. Klicken Sie nun in SerialComCNC bei der Nextion Schnittstelle auf "Connect". Das Display ist nun einsatzbereit. Zitat Ende Welche Informationen benötigst Du noch? Auf Deine Bemerkung: "das Display und ein USB-TTL Wandler und dann??" kann man nur tief in die Glaskugel schauen. Konkrete Fragen wären hilfreich.
Sven L. schrieb: > Hallo Dominic, > > die Erstellung einer HEX_Datei mit WINAVR hat bei mir auch nicht mehr > mit GRBL 1.1 geklappt, gleicher Fehler. Habe da Problem auch mit dem > Arduino IDE umgangen. Klappt super und ist eigentlich auch einfacher ;-) > > Viele Grüße > > Sven L. Hey Sven,.. Gut zu hören.. Habe es mittlerweile auch mit arduino Ide hinbekommen. Ging auch erst nicht.. Immer neue Bibliotheken hinzugefügt, testweise grbl 2 , 3 usw genannt und trotzdem war es im Nachhinein immer grbl 0.9j.. Habe dann alle alten grbl Bibliotheken gelöscht aus der liberie von arduino und dann gings.. Danke MfG Dom
Das löschen der vorherigen GRBL Version in der Arduino IDE ist explizit in dem GRBL Link, den Sven gepostet hatte, beschrieben. https://github.com/gnea/grbl/wiki/Flashing-Grbl-to-an-Arduino Da hättest Du Dir sicher viele Versuche sparen können. Merke, es hilft das Lesen einer Anleitung ;-)
Nachtrag: NOTE: Before starting, delete prior Grbl library installations from the Arduino IDE. Otherwise, you'll have compiling issues! https://github.com/gnea/grbl/wiki/Compiling-Grbl
Avantasia schrieb: > Das löschen der vorherigen GRBL Version in der Arduino IDE ist explizit > in dem GRBL Link, den Sven gepostet hatte, beschrieben. > > https://github.com/gnea/grbl/wiki/Flashing-Grbl-to-an-Arduino > > Da hättest Du Dir sicher viele Versuche sparen können. Merke, es hilft > das Lesen einer Anleitung ;-) Da hast du vollkommen recht.. Ich lese es auch meistens. Nur wird aus dem Lesen meist schnell ein überfliegen, da man/ ich nicht jedes Fremdwort auf englisch kennt und dann den Sinn nicht versteht.. ^^Danke MfG Dom
Hallo Albert, ich habe mich mal durch das Internet, die Hilfe und die Foren gewühlt… Folgendes habe ich jetzt verstanden: Ich brauche das Nextion (am besten 3,5“, bei Ebay für 35€) und einen USB-TTL Converter (ca. 3€). Beide verbinde ich mit einen vieraderigen Kabel und dem USB Anschluss vom Converter mit einem zweiten USB Anschluss vom Fräs-Laptop. Falls der USB Anschluss keine 5V 150mA liefert muss ich zusätzlich 5V ins USB Kabel einspeisen (oder erst am Nextion?). Das ist schon die gesamte Verkabelung oder? Der Rest mit der Software ist klar in der Doku beschrieben Ist das so korrekt verstanden? Danke und viele Grüße Sven
Angehängte Dateien:
-
HeightMap.png
74 KB
Platinenfräsen mit SerialComCNC Ich überarbeite gerade die Darstellung und die Algorithmen für die demnächst freigegebene Funktion "Height Map". Es lassen sich automatisch Höhenprofile einer kupferbeschichteten Platine erstellen. Das Höhenprofil wird in einer Matrix abgespeichert und in Polynom-Funktionen für die verschiedenen Richtungen transformiert. Die Vectoren im Excellon File (vom Platinen-Layout Programm) werden aufgesplittet und mittels des jeweilig passenden Polynoms verrechnet. Das Ergebnis wird in direkt ausführbaren G-Code überführt und in das Hauptfenster von SerialComCNC zum sofortigen Fräsen eingetragen. Das Bild oben zeigt einen Test mit einer 50x40 mm Platine. Gruss Ulrich Albert
Sven schrieb: > Falls der USB Anschluss > keine 5V 150mA liefert muss ich zusätzlich 5V ins USB Kabel einspeisen > (oder erst am Nextion?). 5 VDC Versorgung direkt am Nextion Display anschliessen. Den USB/TTL Serial Converter würde ich auch direkt am Nextion platzieren. Sven schrieb: > Das ist schon die gesamte Verkabelung oder? Der Rest mit der Software > ist klar in der Doku beschrieben > Ist das so korrekt verstanden? Ja.
Hallo Bastler, ich habe das Manual gelesen. Ich habe zu 32bit Controllern nichts gefunden. Könntest Du mir mal sagen wo ich suchen muß? Wenn Du weißt das es nicht geht wäre es natürlich einfacher gewesen wenn Du gesagt hättest das es nicht geht. Hat jemand Kenntnis über SCC und grbl auf 32bit Controllern? MfG Hans
Albert M. schrieb: > Ich überarbeite gerade die Darstellung und die Algorithmen für die > demnächst freigegebene Funktion "Height Map". Hallo Ulrich Albert, da tut sich ja was. Klasse! Ich habe die Tage ja schon ein bisschen mit OpenCNCPilot Platinen fräsen geübt und bin über die eine oder andere Hürde gestolpert. Mit dabei z.B. die Wahl der abzutastenden Fläche. Muss das abgetastete Rechteck alle Leiterbahnen umspannen? Ich frage wegen "2 mm innerhalb der Umrisse" (sinngemäß). Wird also eine Leiterbahn, die am Rand entlang und somit außerhalb deines Abtastrechtecks verläuft, gefräst werden, oder wird die ausgelassen? OpenCNCPilot nimmt solche Bahnen aus. Dann fällt mir auf, dass du Excellon-Daten verarbeitest. Ich habe einen 0.1 mm Stichel mit 15° verwendet um die feinen Strukturen auf meiner Platine auflösen zu können. Wenn ich mit so einem feinen Stichel nur einmal die Kontur einer Leiterbahn umfräse, habe ich im Zweifelsfall mit 0,1 mm Abstand zum umgebenden Kupfer Lötprobleme (Tiefe war auf 50µ eingestellt, die Kupferschicht wurde also gerade so durchtrennt). Im EAGLE-ULP pcb-gcode.ulp wird deshalb jede/s Leiterbahn/Via/Lötauge mehrfach mit jeweils erhöhtem Abstand umfahren, so dass die Zwischenräume entsprechend breiter werden. Hast du das bei der Umrechnung von Excellon auf G-Code berücksichtigt? Die Reihenfolge bei der Bearbeitung ist auch ein Thema, das Aufmerksamkeit erfordert. (Eher kein Thema für das Programm sondern für den Nutzer) Werden zuerst die Löcher für Vias/Lötaugen/Passlöcher gebohrt, ist es nicht ganz unwahrscheinlich, dass einzelne Tastungen genau in einem Loch landen und somit die Abtastung insgesamt schief geht (es sei denn, du fängst im Programm solche als "zu tief" erkannten Proben ab und interpolierst mit den umliegenden Proben). Hat man erfolgreich (weil noch keine Löcher gebohrt wurden) eine Seite abgetastet und bohrt jetzt die Löcher von der ersten Seite komplett durch, ergibt sich das identische Problem auf der Rückseite. Somit empfiehlt es sich, die Löcher von jeder Seite nur etwas über die Hälfte der Dicke der Platine zu bohren (Passlöcher ausgenommen, aber die kann man ja außerhalb der Platinenumrisse anlegen). So, erst mal Pause Gruß, Harald
Hallo Zusammen! Ich hatte vor ein paar Wochen oder schon Monaten mal die Frage gestellt, ob Ulrich Albert eine Funktion in SCC einbauen könnte, mit der man die Drehzahlangaben im S G-Code auf die echte Drehzahl der Spindel umrechnen kann. Alte Fräsen-Hasen werden damals vielleicht müde mit den Schultern gezuckt haben, weil das so trivial ist... Gestern habe ich gelernt, dass dieses Problem keines ist, da GRBL mit den Angaben $30 und $31 die Maximal- und Minimaldrehzahl für 100% bzw. das Minimum der auszugebenden PWM lernt und damit die Drehzahlangaben des S-Befehls linear in 255 Schritten auf den verfügbaren Drehzahlbereich mappt. Die Defaulteinstellung für $30 ist 1000 (der MaxWert), somit erklärt sich die Angabe in 10tel Prozent, wie von Ulrich in seiner Hilfe angegeben. Erfahrungsgemäß muss man ein bisschen mit den Grenzwerten spielen, bis das Mapping bestmöglich passt. Der untere Grenzwert ($31) muss auf 0 stehen, sonst klappt es gar nicht. Gruß, Harald
Harald S. schrieb: > Mit dabei z.B. die Wahl der abzutastenden Fläche. > Muss das abgetastete Rechteck alle Leiterbahnen umspannen? Ich frage > wegen "2 mm innerhalb der Umrisse" (sinngemäß). Wird also eine > Leiterbahn, die am Rand entlang und somit außerhalb deines > Abtastrechtecks verläuft, gefräst werden, oder wird die ausgelassen? Diese erste Abtastung mit 2 mm Abstand von den Rändern innerhalb der Platine in der unteren linken Ecke bestimmt nur den Nullpunkt auf den sich die nachfolgenden Abtastungen beziehen. Die Fräsbahnen können beliebig auf der Platine verlaufen. Die Fräsbahnen müssen im HPGL- / PLT-Format vorliegen, die Bohrdaten im Excellon-Format. Die Excellon Daten werden ausgeführt wie empfangen. Eine zusätzliche Eingabe für die gewünschte Tiefe der Löcher muss ich noch einführen. Die Reihenfolge der Bearbeitung wird bestimmt durch die Boardabtastung, diese muss vor dem Ausführen der Bohr(Excellon)-Datei erfolgen. Lass Dich nicht von der momentanen Menueführung verwirren, da wird sich noch einiges ändern. Ein grundsätzliches Problem gibt es allerdings bei Verwendung von relativ dünnen und biegsamen Platinen für das ich keine Lösung finde: Wenn diese z.B. in der Mitte höchgewölbt sind, so ist das bei der Abtastung eigentlich kein Problem, da der Stichel bei Berührung sofort stehen bleibt ohne die Platine durchzudrücken. Beim Fräsvorgang werden allerdings diese Platinen durch den Sticheldruck nach unten gebogen, so das die ganze Höhenabtastung für die Katz ist.
Albert M. schrieb: > relativ dünnen und biegsamen Platinen Ich habe "normales" 1,5 mm FR4 Material verwendet, da kommt das natürlich nicht vor. Aber die Art der Befestigung hilft bei den dünnen Platinen eventuell weiter. Ich verwende doppelseitiges Teppichklebeband um die Platine auf einem plangefrästen Bett aufzukleben, an zwei Seiten ergibt sich durch das planfräsen jeweils eine Kante als Anschlag. Für das Fräsen der Leiterbahnen ist diese Befestigung stabil genug, nur beim Konturenfräsen muss ich mir noch etwas anderes ausdenken, denn die Platine verdreht sich etwas durch den seitlichen Fräserdruck (Außenmaß der Platine 30 x 40 mm, die Klebefläche ist also nicht besonders groß). Mit dem Klebeband, ggf. vollflächig verklebt, nicht nur an zwei Punkten, sollte die Aufwölbung in der Mitte unterbunden werden können, oder? Gruß, Harald
Hans L. schrieb: > Hat jemand Kenntnis über SCC und grbl auf 32bit Controllern? Hier im Thread war mal irgendwann jemand der GRBL auf einen STM Controller portiert hat. Vielleicht gibt es bei GitHub auch einen Fork dazu. Aber warum willst Du unbedingt GRBL auf einem 32 Bitter laufen lassen? Nehm einen Arduino und gut is. Dann gibt es auch keine Kompatibilitätsprobleme mit SerialComCNC.
Harald S. schrieb: >> relativ dünnen und biegsamen Platinen > > Ich habe "normales" 1,5 mm FR4 Material verwendet, da kommt das > natürlich nicht vor. Ich teste hier mit einer 1,6 mm Pertinax Platine, die sich bei Fräsen kräftig durchbiegt. Wegen dem schädlichen Staub bei FR4 Material wollte ich dies fürs Probieren eigentlich nicht nehmen :) Da muss ich mir wohl doch mal FR4 Platinen bestellen.
Albert M. schrieb: > Ich teste hier mit einer 1,6 mm Pertinax Platine Ah, dann tastest du in der Tat mit einem Taster und nicht per metallischem Kontakt ab... Aber davon abgesehen sollte sich auch 1,5 mm Pertinax, flächig auf geklebt, nicht verbiegen. Spannst du die Platine seitlich ein? Ohne Unterlage?
Harald S. schrieb: > Albert M. schrieb: >> Ich teste hier mit einer 1,6 mm Pertinax Platine > > Ah, dann tastest du in der Tat mit einem Taster und nicht per > metallischem Kontakt ab... Sorry, nicht Pertinax, sondern einseitig kupferbeschichtete Hartpapier Platine. Und Abtastung mittels elektrischem Stichel-Kontakt auf die Kupferoberfläche der Platine.
Albert M. schrieb: > kupferbeschichtete Hartpapier Da kann ich die Wölbung nachvollziehen, das Zeug ist aus meiner (sehr! frühen. Wir reden über Jahrzehnte :-) Erfahrung schon in sich verzogen, wenn es aus der Verpackung kommt. Aber dem Stichel ausweichen... wie gesagt, auf eine Unterlage pappen und das Problem sollte weg sein.
Angehängte Dateien:
-
Vakuum1.jpg
230 KB -
Vakuum2.jpg
230 KB
Hallo, ich denke das die Taktfrequenz mit einem 32bit Controller höher ist. Könnte bei einem UHU was bringen. Ich habe das Durchbiegeproblem mit einer Vakuumplatte die ich aus einem Alurest gefräst habe, für meine Ansprüche ist das ausreichend. Die Auflagen habe ich vorher mit der Kress-Spindel in der gleichen Z-Höhe überfräst. MfG Hans
Hans L. schrieb: > ich denke das die Taktfrequenz mit einem 32bit Controller höher ist. Welche Taktfrequenz meinst du? Der GRBL Arduino liefert maximal gegen 30 kHz Step-Impulse, das reicht zumindest für meine Fräse längstens aus. Mehr als 600 mm/Minute schafft meine Mechanik nicht, bei 200 Steps/Umdrehung und 8tel Schritten sowie 3 mm Steigung der Gewindespindel verwende ich also maximal etwa 5,3 kHz, habe also jede Menge Luft nach oben. Der GRBL Controller braucht also in meinen Augen keine höhere Taktrate als die gegebenen 16 MHz. Hilft dir das weiter? > Könnte bei einem UHU was bringen. Mhmm, du meinst sicher nicht den altehrwürdigen Hochstartsegler? Gruß, Harald
Danke Albert für deine Antwort. Ich habe mir eben ein Nextion Display bestellt, sowie ein USB TTL Modul. Ich hoffe, dass ich das Richtige gekauft habe (gab so viele verschiedene Bauformen) 3V/5.5V USB to RS232 Serial TTL PL2303 USB UART Board PL-2303HX CP12004 C54 http://www.ebay.de/itm/3V-5-5V-USB-to-RS232-Serial-TTL-PL2303-USB-UART-Board-PL-2303HX-CP12004-C54-/281353505760?hash=item4181f9cbe0:g:2-MAAOSwnbZYFRMc#rwid Viele Grüße Sven
Sven schrieb: > Ich hoffe, dass ich das Richtige > gekauft habe (gab so viele verschiedene Bauformen) > > 3V/5.5V USB to RS232 Serial TTL PL2303 USB UART Board PL-2303HX CP12004 > C54 Braucht natürlich noch den passenden Windows treiber für das Board.
@Hans Lang: Was für eine Pumpe nimmst du für das Fixieren der Platine auf der Vakuumplatte?
zum Platinenfräsen: Ich mache das seit Jahren schon und benutze immer Teppichklebeband. Da muss man aber aufpassen: NICHT das billigste benutzen! Ich habe die besten Erfahrungen mit Faserverstärkten Klebeband gemacht. Es kommt zudem noch dazu, wenn es mal kalt in der Werkstatt ist, kleben die billigen schlecht bis garnicht. @Albert: Es wäre schön, wenn das Modul nicht nur plt sondern auch GCODE Dateien einlesen könnte! zum Frequenzumrichter per PWM: Ich habe es gestern erfolgreich ausprobiert, einen kleinen Mosfet, Gate an den PWM Ausgang mit 5V und Drain an die +10V des FU's, Source an den AnalogEingang des FU's mit nem 47µF Elko gegen Masse. Da dies jedoch eine Invertierung erzeugt, habe ich im FU die Werte für min und max Drehzahl einfach vertauscht. Das ansteuern des FU klappt damit prima! Allerdings habe ich mich entschlossen, doch einfach nur per Relays die Spindel ein/auszuschalten. Die Drehzahl stelle ich per Hand am FU ein. Ist einfacher für mich, da die meist sowieso mit 22000U/min läuft. Wenns mal weniger sein soll, muss ich die Drehzahl sowieso von Hand anpassen, wie z.B. bei Kunstoffen. Dann noch etwas: Ich habe unter der Spindel eine Aluscheibe mit 4x 3W LEDs zur Beleuchtung. In diese Scheibe sind nun 2 Löcher für Linienlaser dazugekommen, um Werkstücke winklig aufspannen zu können. Das funktioniert auch recht gut, allerdings musste ich feststellen, daß das Gehäuse der Linienlaser mit + verbunden ist! Ich habe mir nen Wolf gesucht, da die Steuerung nicht mehr wollte und rumgesponnen hatte! Also aufpassen, wenn solche Laser an die gleiche Stromversorgung angeschlossen werden sollen! Ich habs nun so gelöst: +der Laser an GND und -der Laser an -5V des ATX Netzteils! da die nur etwa 40mA ziehen, reichen die -5V vom Netzteil aus. Gruß, Wolfram.
Wolfram F. schrieb: > @Albert: > Es wäre schön, wenn das Modul nicht nur plt sondern auch GCODE Dateien > einlesen könnte! Ich schließe mich dem unbedingt an. Gcode sollte eigentlich an erster Stelle stehen. Danach dann die anderen Formate... Bitte nochmal darüber nachdenken, Ulrich. Vielen Dank
Angehängte Dateien:
-
VacPump.jpg
500 KB
Hallo, ich hatte in meinem Fundus eine alte Laborvakuumpumpe, die habe ich mit Festoschlauch an die Pumpe angeschlossen. MfG Hans
zum Thema Vakuumpumpen: Ich habe mehrere Pumpen die aus der ZV von VW/Seat oder auch älteren Mercedes stammen. Diese eignen sich sowohl für Druck als auch zum saugen sehr gut und kosten auf dem Schrottplatz fast nix. Z.B. habe ich so eine an meiner Lötstation zum entlöten i.V. mit dem Weller Entlötkolben seit Jahren im Einsatz. Ich plane noch, 2 Vakuumplatten herzustellen, eine kleine, ca. A4 groß für Platinen und eine große 630x450 für den ganzen Tisch (diese wird aber wohl einen Staubsauger benötigen). für die kleine sollte so eine KFZ-Pumpe jedoch ausreichen.
Hallo liebe SCC-Gemeinde, ich habe mir jetzt auch ein Nextion und einen USB-TTL Converter bestellt und habe den Tipp bekommen, das Display an eine externe 5VDC Stromquelle anzuschließen. Habt ihr Nextion-Nutzer das auch so gemacht oder geht es nicht auch alles über USB. Ich würde gerne so wenig wie möglich „Kabelsalat“ haben. Sonst kämen ja zwei Kabel aus den Nextion-Gehäuse, eines zum USB Anschluss zum Laptop und eines zur Stromquelle. Wie habt ihr die Verkabelung gelöst? Um Tipps und Hinweise wäre ich dankbar. Viele Grüße Sven
Sven schrieb: > ich habe mir jetzt auch ein Nextion und einen USB-TTL Converter bestellt > und habe den Tipp bekommen, das Display an eine externe 5VDC Stromquelle > anzuschließen. > Habt ihr Nextion-Nutzer das auch so gemacht oder geht es nicht auch > alles über USB. Das 3.5 Nextion benötigt bis zu 150 mA @ 5 VDC. Für kurzes Testen versorge ich es über USB. Für längere Fräss-Sessions ist mir das aber nicht geheuer. Ich habe keine Lust mein PC Motherboard aufs Spiel zu setzen. Wahrscheinlich bin ich aber auch nur zu vorsichtig :) Letztendlich musst Du selber wissen was Du machst.
Bastler schrieb: > keine Lust mein PC Motherboard aufs Spiel zu setzen. Da brauchst du keine Angst haben, die USB-Anschlüsse sind abgesichert und liefern prinziell bis zu 500 mA (wenn das angeschlossene USB Device dem Port mitgeteilt hat, dass es so viel bzw. mehr als den defaulmäßig zur Verfügung gestellten Strom benötigt). Die USB-Seriell Converter handeln im Allgemeinen keinen höheren Strom mit dem USB Controller im Rechner aus, somit ist der nach USB Norm zur Verfügung gestellte Strom max 100 mA. Damit läuft das Display nach den Aussagen hier im Forum nicht. Ich kenne aber kein Motherboard bei dem der Strom tatsächlich begrenzt wird, wenn das Device (der USB-Seriell-Wandler) mehr als ausgehandelt (oder eben mehr als 100 mA ohne Aushandlung) zieht. Über den Eigenschaftendialog des USB-Controllers kannst du überprüfen, ob der Controller "Überstrom" meldet, oder ob ihm der höhere Strom egal ist. Von älteren USB-Festplattengehäusen kenne ich solche USB-Anschlusskabel mit zwei USB-A-Steckern auf der Rechner-Seite. Damit wird der Ausgangsstrom von zwei USB-Ports parallel geschaltet. Damit könntest du ebenfalls eine Abschaltung des USB-Ports vermeiden. (Ich habe aber auch schon Stimmen gehört, die vor der Verwendung dieser Doppel-Stecker-Kabel warnen). Aber auch von meiner Seite: Du musst selbst wissen, welches Risiko dir das eingesparte Kabel wert ist. Gruß, Harald
Hallo Wolfram Fischer was sind das genau für Pumpen? Ich brauche aktuell auch eine Pumpe und bin gereade auf der suche nach einer. Uli
Ok, danke schon mal für die Antworten. Könnte ihr ein paar Bilder von euren Nextion incl. Verkabelung einstellen. Würde mir helfen. Danke und viele Grüße Sven
Uli schrieb: > Hallo Wolfram Fischer was sind das genau für Pumpen? > > Ich brauche aktuell auch eine Pumpe und bin gereade auf der suche nach > einer. > > Uli meiner Meinung nach sind das Drehschieberpumpen. http://www.gutmbh.de/Bilder/Vakuumpumpen/DrehschieberPrinzip.gif
Habe mich wohl falsch ausgedrückt. Das Prinzip ist mir dabei egal nur wo ist die verbaut und als was? Ist das eine Scheibenwischerpumpe, Hydraulikpumpe, Ölpumpe, ..... ? Und ist die überhaupt als Luftpumpe haltbar? Uli
Wolfram F. schrieb: > Ich habe mehrere Pumpen die aus der ZV von VW/Seat oder auch älteren > Mercedes stammen. das hab ich doch geschrieben! und haltbar sind die auch, damit kannst du auch prima 100erte Luftballons für nen Kindergeburtstag aufblasen! :-) nur darauf achten, daß sie nicht zu heiss werden, daher besser mit drehzahlregler. Einfach mal probieren...
Height Map für Platinen fräsen Ich werfe gerade die bisherige Mathematik für die Höhenkarte über Board. Das bisherige Konzept hatte zwar soweit funktioniert, war aber teilweise unbefriedigend. Also was anderes ausprobiert, man hat ja sonst nichts zu tun :) Neuer Ansatz: Mit den Werten der Platinen-Abtastung (z.B. alle 10 mm in X und Y) wird eine farbcodierte 3-D Contour mit interpolierten Werten (eine Interpolation pro 2 mm) zwischen den Abtaststellen erstellt. Damit ist zu jedem beliebigen XY Wert, auch zwischen den Interpolationsstellen, die zugehörige Höhe in der 3D-Contour mit ausreichender Genauigkeit bekannt. Das zu verarbeitende File (HPGL, PLT oder G-Code) wird nun wie folgt verarbeitet: Jeder Verfahrweg (z.B. G1 X30 Y0) wird in Sub-Steps von z.B. 5 mm aufgesplittet. Bei jedem Step wird die zugehörige Höhe aus der 3-D Countour ermittelt und verrechnet. Bei nicht rechtwinkligen Verfahrwegen werden die Werte mit passendem Vector berrechnet. Das funktioniert so weit ganz gut. Die erzeugte G-Code Datei ist danach natürlich um ein Vielfaches grösser als die Ursprungs Datei (Abhängig von der Sub-Step Grösse). Gruss Ulrich Albert
Hallo Albert, Chapeau, da kann man nur seinen Hut ziehen, bei dem was du auf die Beine stellst. Ich kann es kaum erwarteten die Abtastung zu testen. Sobald ich meinen Frästisch wieder plangefräst habe werde ich die neue Version testen... ach halt ich nehme die gleich zum Planfräsen :) Wie gesagt, meine Hochachtung und danke für die Software. MFG EGS
EGS schrieb: > ach halt ich nehme die gleich zum Planfräsen :) Achtung, Scherz! Nicht jeder kennt die Smilies... ;-)
EGS schrieb: > ach halt ich nehme die gleich zum Planfräsen :) Achtung, Scherz! Nicht jeder kennt die Smilies... ;-) Wolfram F. schrieb: > Wolfram F. schrieb: >> Ich habe mehrere Pumpen die aus der ZV von VW/Seat oder auch älteren >> Mercedes stammen. > > das hab ich doch geschrieben! ZV=Zentralverriegelung
Angehängte Dateien:
-
2017-03-24_112420.png
210 KB -
2017-03-24_112949.jpg
270 KB
Albert M. schrieb: > eine farbcodierte 3-D Contour mit interpolierten Werten (eine > Interpolation pro 2 mm) zwischen den Abtaststellen erstellt. Hallo Albert, klingt gut und vertraut ;-) > Das zu verarbeitende File (HPGL, PLT oder G-Code) G-code: Prima, vielen Dank! Das erlaubt die Verwendung von z.B. PCB-GCODE.ULP in EAGLE, das in meinen Augen sehr ausgereift mit der Aufgabe umgeht. > Jeder Verfahrweg (z.B. G1 X30 Y0) wird in Sub-Steps von z.B. 5 mm aufgesplittet. Spannend wird's dann bei Kreisen und Radien... > Platinen-Abtastung (z.B. alle 10 mm in X und Y) Nur als Anregung: Einige meiner Platinen sind kleiner als das Raster (Beispiel: Platine für MPU9150 - 9DOF Bewegungssensor. Der Chip ist 4x4 mm groß). Man kann anführen, dass dann auch keine allzu großen Abweichungen auf der Z-Achse zu erwarten sind. Bei Platinen stimmt das sicher (eine schräge Aufspannung beim Fräsen mal außen vor gelassen). Aber erinnern wir uns zurück... du wolltest ursprünglich mit einem Taster auch nicht leitendes Material abtasten. In diesem Umfeld kann ich mir durchaus Oberflächen vorstellen, die ein engeres Abtastraster fordern. Kurz: Vielleicht solltest du das Raster einstellbar machen? Gruß, Harald
Hallo, hat denn keiner mal Bilder von seinem Nextion inclusive der Verkabelung für mich zum Abgucken? Danke im Voraus ;-) Sven
Sven schrieb: > Hallo, hat denn keiner mal Bilder von seinem Nextion inclusive der > Verkabelung für mich zum Abgucken? > > Danke im Voraus ;-) > > Sven Was ist daran so Schwer ? kable die Beschriftest sind TX/RX sind Gekreutzt +5V ----+5V GND ---- GND TX ----RX RX ----TX Grüße Sven
Angehängte Dateien:
-
SerialCom.jpg
250 KB
Hallo, ich bin hier neu und habe folgendes Problem. Ich habe zwei Arduino Nano v3 ATmega328P USB ch340 in der Bucht gekauft. Damit der Rechner den Arduino erkannte, musste ich einen Treiber von deren Verkaufsseite runterladen. Der Arduino wurde dann erkannt, ich konnte aber mit den XLoader den Arduino nicht flashen. Das habe ich dann mit dem AVRStudio gemacht. Mit einem Terminalprogramm kann ich $ oder $$ eingeben und bekomme die Status entsprechend angezeigt. Starte ich SerialComCNC kann ich den Arduino connecten, bekomme auch die Meldung das conneted ist etc. Aber wenn ich das Fenster weg klicke, dann kann ich z. b. die Status abfrage kommt nichts im Monitorfenster... Die TX LED des Arduino blinkt so ca. 5 x in der Sekunde.. Vor daher denke ich das der Arduino richtig läuft... Weiß jemand Rat??
Thomas schrieb: > Starte ich SerialComCNC kann ich den Arduino connecten, bekomme auch die > Meldung das conneted ist etc. Aber wenn ich das Fenster weg klicke, dann > kann ich z. b. die Status abfrage kommt nichts im Monitorfenster... > > Die TX LED des Arduino blinkt so ca. 5 x in der Sekunde.. Vor daher > denke ich das der Arduino richtig läuft... > > Weiß jemand Rat?? Meist hift SerialComCNC Manual lesen ungemein. Schau mal auf die Seite "GRBL konfigurieren". Da sind 4 Zeilen extra für Dich in fetter Schrift :)
Manual Leser schrieb: > Meist hift SerialComCNC Manual lesen ungemein. > Schau mal auf die Seite "GRBL konfigurieren". > Da sind 4 Zeilen extra für Dich in fetter Schrift :) Du hättest auch schreiben können das er $10=0 eingeben muß um die Statusanzeigen anzupassen So ist ihm doch nicht geholfen da er ja Die Ursache nicht kennt Manchmal sieht man den Wald vor Bäumen halt nicht Einfache frage = Einfache Antwort Kundendienst sagt ja auch nicht lesen Sie das User Manuel da Steht es drin Grüße Sven W
Manual Leser schrieb: > Meist hift SerialComCNC Manual lesen ungemein. > Schau mal auf die Seite "GRBL konfigurieren". > Da sind 4 Zeilen extra für Dich in fetter Schrift :) Hallo Manual Leser, joo, das war es... Jetzt wird mir in SerialComCNC auch die Status angezeigt. Hatte zwar schon gelesen - die Stelle aber überlesen... Musste den Befehl mit einem Terminalprogramm eingeben... Danke für den Hinweis. Gruß Thomas
Hallo Sven,
Das mit dem Nextion Display ist keine große Sache.
Der USB TLL und auch das NEXTION Display ist beschriftet.
Kabel liegt dem NEXTION bei das passt perfekt an den USB TLL (zumindest
bei mir )
USB TTL 3V3
TXD ---------RXD
RXD ---------TXD NEXTION
GND ---------GND
+5V ---------+5V
Den 3V3 am TLL brauchst Du nicht.
Das Display benötigt bis zu 160mA bei 100% (Nachgemessen)
Ich habe es mit „Dims=30“ auf 30% runder gestellt dies bleibt auch nach
dem Ausschalten erhalten und schon sind es nur noch 54 mA. Damit ist
kein externes Netzteil notwendig.
Bis 50% Helligkeit geht es noch am USB Port. Mir reicht es vollkommen
aus. Der USB Port würde bei Überlastung Abschalten.
Wenn es Dir zu heikel ist, nimm ein 5V Netzteil denke dabei daran das
der TLL und NEXTION gemeinsame Masse haben müssen.
Gruß Daniel
Wenn mir jemand zv übersetzt dann kann ich die. Pumpe auch einordnen. Vg, Uli
Hans L. schrieb: > ich hatte in meinem Fundus eine alte Laborvakuumpumpe Ich denke nicht, dass diese Pumpen auf einer Raster-Vakuumplatte eine gebohrte Platine halten, das geförderte Volumen ist zu klein. Ungebohrte Platinen könnten wohl gehalten werden. Um die Leckagen der Bohrungen auszugleichen brauchte man schon einen Staubsauger oder Seitenkanalverdichter.
uli schrieb: > Wenn mir jemand zv übersetzt dann kann ich die. Pumpe auch einordnen. > Vg, Uli Hallo Uli! Du musst schon alle Beiträge mal anschauen, wenn du in einem Forum geholfen haben möchtest, z.B. diesen hier: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Und natürlich sinnbegreifnd lesen :-) Gruß, Harald
Manfred A. schrieb: > brauchte man schon einen Staubsauger Hallo Manfred, klappt das wirklich? Das Ansaugen wohl sicher, aber ich fürchte, der Staubsuger läuft heiß, denn normaler Weise dient die angesaugte Luft auch der Motorkühlung, und in diesem Fall strömt ja kaum Luft, oder? Ich habe schon Probleme (Staubi schaltet nach eine paar zig-Minuten ab wegen Überhitzung) wenn ich den Saugschnorchel vorne mit einem 20er Installationsrohr verkleinere um die Luftgeschwindigkeit zu erhöhen und näher an den Fräser zu kommen. Gruß, Harald
Hallo, ich körne die Bohrungen mit dem Gravierstichel nur an und bohre dann manuell weil meine Z-Achse pneumatisch hoch bzw. runterfährt. MfG Hans
Bezüglich Staubsauger läuft heiss... dem kann man abhelfen, in dem man einen zusätzlichen Lufteingang schafft. Viele käufliche Staubsauger haben so eine Art Luftschlitz am Saugrohr oben am Handgriff, wo man zusätzliche Luft einströmen lassen kann. Soetwas halt auch für den CNC Staubsauger und die Gefahr des heißlaufens auf Grund geringer Luftmenge ist behoben.
Angehängte Dateien:
-
20170325_174200.jpg
220 KB -
20170325_174414.jpg
230 KB -
20170325_174524_001.jpg
220 KB -
20170325_174528.jpg
230 KB -
20170325_174604.jpg
240 KB
Avantasia schrieb: > und die Gefahr des > heißlaufens auf Grund geringer Luftmenge ist behoben. So gehe ich auch vor. Zum Platinenfräsen benutze ich eine Lochraster-Vakuumplatte mit 0,2mm Bohrungen und Staubsauger, funktioniert einwandfrei. Link zur Vakuumplatte: https://www.vakuumtisch.de/index.php?page=product&info=560 Zum Isolationsfräsen: Die besten Erfahrungen habe ich mit einem sebstgebauten Tiefenregler (mit Staubabsaugung) und einem 230V Proxxon Bohrschleifer gemacht. Dabei liegt die gesamte Fräseinheit durch Eigengewicht mit einem Kunststoffstopfen auf der Platine auf. Im Zentrum des Stopfens läuft der Fräser. Der Stopfen hat ein Aussengewinde. Die Frästiefe wird durch verdrehen des Stopfens eingestellt. So habe ich immer die richtige Frästiefe, egal wie krumm das Platinenmaterial ist. Den Poxxon habe noch mit einer Kühlung und zusätzlichen Lagern vesehen(durch verspannen der Lager von aussen konnte ein besserer Rundlauf eingestellt werden). Gruß, Manfred
Hi Da hier aktuell auch über Vakuum-Pumpen gesprochen wird: Selber habe ich neben einer Drehschieberpumpe auch Kühlschrank-Kompressoren am laufen. Letztere brauchen im Vakuum-Betrieb <10W, im Druck-Betrieb steigt die aufgenommene Leistung mit dem Druck stark an, über 20bar kann man im INet findet, habe selber aber nur bis 10bar probiert (kalte Füße und so). Auch ist der Kühlschrank deutlich leiser als die Drehschieber-Pumpe. Beide stoßen aber Öl-Nebel aus, wobei der Kühlschrank hier um Längen weniger davon produziert. Die Drehschieberpumpe fördert wesentlich mehr Volumen, ist also um Längen unempfindlicher auf Leckagen! (sprich: der Unterdruck ist nicht so schnell weg) Die weiter oben gezeigten Vakuum-Pads kommen mir bekannt vor, selber nehme ich 4mm Moosgummi-Schnüre, was Besseres fiel mir auch noch nicht ein. Die ebenfalls 4mm messenden Luftschläuche sind allerdings nicht für große Volumen gedacht, auf 500mbar sinkt der Druck bereits bei völlig offenem Pad nur wegen dem Schlauch. MfG
Angehängte Dateien:
-
20170326_160312_resized.jpg
240 KB
Hallo Albert, zuerst einmal VIELEN DANK für deine wirklich Tolle Arbeit. Ich finde es Genial was du alles machst. Ich hab heute mal wieder ein wenig mit dem Easy Job rumgespielt. Dabei bin ich warscheinlich auf einen kleinen Fehler beim Rounded Rectangle gestoßen. Ich hab als Startpunkt 0,0 und endpunkt 40,40 mit Radius 5mm eingegeben. Beim fräsen ist der Fräser jedesmal nach Ende eines Durchgangs erst wieder auf 0,0 gefahren, ist dann auf die nächste Tiefe gegangen und anschließend den nächsten Durchgang gestartet. Das hatte zur folge, daß ich unten links eine Kante hatte. Kannst du dir das mal bei gelegenheit ansehen? Gruß Detlef
Detlef S. schrieb: > Ich hab als Startpunkt 0,0 und endpunkt 40,40 mit Radius 5mm eingegeben. > Beim fräsen ist der Fräser jedesmal nach Ende eines Durchgangs erst > wieder > auf 0,0 gefahren Das ist natürlich ein Bug. Wird in der nächsten Version behoben.
Anbei neue Version SerialComCNC 2.5.1 Change Log V2.5.1 ----------------- EasyJob - Fehler bei der G-Code Erzeugung in Rounded Rectangle behoben. - Speichern/Laden der Jobs nun unter eigenem Namen mit der File-Extension ".job" Gruss Ulrich Albert http://www.serialcominstruments.com/
Angehängte Dateien:
-
Nextion_Display_Menue.png
1,7 KB -
Nextion_Display_Einstellen.png
1,2 KB
Anbei eine Erweiterung zum 3.5" Nextion Touch Display:
Über den neuen Menue-Punkt "Display" lässt sich die
Helligkeit des Displays von 20% bis 100% einstellen.
Mit Verringerung der Helligkeit wird auch der Strombedarf
des Displays gesenkt. Gemessene Werte:
Helligkeit % mA
100 145
75 110
50 80
30 60
Eine Einstellung zwischen 50% und 75% bietet ausreichend
Helligkeit. Damit lässt sich dann das Display direkt
gefahrlos über USB betreiben (ohne zusätzliches Netzteil).
Das neue HMI-File incl. Fonts befinden sich im beigefügten
ZIP-File. Die entpackten Dateien in den Unterordner
"Nextion Display" von SeriaComCNC kopieren.
Die Bilder sind eine Screen-Copy vom Nextion Editor/Debugger.
Gruss Ulrich Albert
Angehängte Dateien:
-
CIMG0035.JPG
62 KB -
CIMG0036.JPG
64 KB -
CIMG0037.JPG
68 KB
Moin, habe nochmals eine Z-Achse gebaut - läuft unter SCC mit 1500 U/min Wünsche allen ein frohes Osterfest MfG Klaus
Klaus, was willst du mit mit so einer Spielzeugachse?
Hallo Albert, kannst du in deine Dokumentation die Touch-Funktionen vom Nextion mit aufnehmen. Vieles ist zwar selbsterklärend, aber einige Funktionen könnten vielleicht eine kurze Erklärung bekommen. In den Forum ist zwar irgendwo alles beschrieben, ist aber sehr müssig alles durchzulesen und zu finden. Ansonsten funktioniert alles und sehr klasse ist das letzte Update mit der Anpassung der Helligkeit. Ich habe meins auf 68% eingestellt und spare mir die damit den Kabelsalat. Super, danke!!! Viele Grüße Sven
Hallo Albert, unterstützt GRBL eigentlich auch user-definierte variablen so wie MACH3? z.B. #500 = 20 Wenn ja, wäre es recht einfach eine Autoleveling Routine zu schreiben! Z-runter bis Probe Kontakt hat, Z-Wert in Variable speichern, weiter mit nächster Position... Später dann den GCODE mit (#500 - Z-0.07) ergänzen.. Wenn nicht, wie würdest Du es machen? Gruß, Wolfram
Wolfram F. schrieb: > unterstützt GRBL eigentlich auch user-definierte variablen so wie MACH3? > z.B. #500 = 20 > Wenn ja, wäre es recht einfach eine Autoleveling Routine zu schreiben! > > Z-runter bis Probe Kontakt hat, Z-Wert in Variable speichern, weiter > mit > nächster Position... > Später dann den GCODE mit (#500 - Z-0.07) ergänzen.. > > Wenn nicht, wie würdest Du es machen? Nein, User-definierte Variablen werden nicht unterstützt. Und Dein Beispiel ist etwas zu kurz gedacht und funktioniert nicht :) Dazu habe ich hier bereits einiges geschrieben: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" und Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
Mir ist ein Bug im EasyJob aufgefallen: Wird ein Job mit einer Fräserposition Aussen/Innen gewählt und anschliessend ein Job DrillHole/RowOfHoles/Line gewählt, so bleibt die Position Aussen/Innen eingestellt, obwohl Mittig richtig wäre. Abhilfe: EasyJob Fenster schliessen und neu aufrufen. Dieser Fehler wird in der nächsten Version behoben.
Hallo Albert, Erstmal vielen Dank für dieses Programm! Müssen wir erstmal acht geben beim EasyJob bis zur nächsten Version. Ich erstelle den Gcode mit inkscape. Nach dem laden der Datei in SCC und starten des Vorgangs erhalte ich eine Error Meldung. Dabei steht hinter jeder Zeile im gecode Error und die Maschine fährt in eine Richtung und lässt sich nur durch not stop anhalten. Lasse ich den code durch den Test laufen werden keine Fehler gefunden. Starte ich dann kommt es vor das es klappt. Oder wieder error und nochmal test.keine errors. jetzt weiß ich nicht woran es liegt? Manchmal braucht es vier oder fünf Anläufe bis es klappt. Läuft es einmal, läuft der code auch bis zum Ende durch ohne error. Bei den code aus inkscape steht in der ersten und letzten Zeile nur ein "%" die erste Zeile lösche ich raus da der test dort immer einen error anzeigt. Die letzte wird von SCC ignoriert da der code bis dahin fertig ist. Es handelt sich dabei immer um die gleiche Datei Frohe Ostern! Daniel
Daniel S. schrieb: > Ich erstelle den Gcode mit inkscape. Nach dem laden der Datei in SCC und > starten des Vorgangs erhalte ich eine Error Meldung Zur Inkscape kann ich nichts sagen. Wenn der erzeugte GCode GRBL kompatibel ist, wird er auch ordnungsgemäss funktionieren. Wenn nicht, versuche mit einem anderen CAM Tool, wie z.B. Estlcam, die Zeichnung zu konvertieren. Daniel S. schrieb: > Lasse ich den code durch den Test laufen werden keine Fehler gefunden. > Starte ich dann kommt es vor das es klappt. Oder wieder error und > nochmal test.keine errors. > jetzt weiß ich nicht woran es liegt? > Manchmal braucht es vier oder fünf Anläufe bis es klappt. Läuft es > einmal, läuft der code auch bis zum Ende durch ohne error. Das hört sich eher nach EMV Problemen an. Dazu wurde hier im Thread schon mehrfach einiges geschrieben und Tips zur Vermeidung gegeben. Um den Fehler einzugrenzen, würde ich zuerst mal die Zeichnung mit der Testversion von Estlcam in GCode konvertieren und in SerialComCNC laufen lassen. Treten dann noch immer die von Dir beschriebenen Fehler auf, hast Du ein EMV Problem.
Hallo Albert, ich werde es mit der Testversion von Estlcam versuchen, Das es an SCC liegt glaube ich nicht, die HPGL (*.plt)Dateien liefen immer fehlerfrei mit SCC und das schon seit über einem Jahr, Es hat den Anschein als ob GRBL mit den Daten Format Schwierigkeiten hat. Denn die Error Meldung kommt doch von GRBL oder? Aktuell ist GRBL 1.1f und SCC Ver. 2.5.1 und NEXTION Ver. 2.5.2 , Der Fehler trat auch schon mit SCC Ver. 0.9f und GRBL 0.9 auf. Ich habe es mir heute nochmal genauer angesehen. In den Moment wo die Maschine verrücktspielt. Zum Ablauf: Ich lade den Gcode ein. Lösche die erste Zeile raus. Da sie nur „%“ enthält. Setze Nullpunkt. Lege Spindelgeschwindigkeit fest und Drücke „Start File“ Der Spindelmotor läuft an. Die Z Achse fährt auf Z 5mm hoch. Die Maschine fährt (X,Y)in Richtung ersten Ziel. Und JETZT! bleiben die Code Zeilen stehen, hinter jeder Zeile steht jetzt Error. Maschine bewegt sich immer noch in Richtung erstem Ziel. Sie hält dort aber nicht an um Z Abzusenken sondern fährt über den Wert hinaus. Das Grafikfenster in SCC, Fadenkreuz läuft weiter. Auch werden die X,Y koordinaten Fortgesetzt, Auch am NEXTION Display. SCC bekommt also die Aktuelle Position vom UNO mitgeteilt. An Hand der X,Y koordinaten erkennt man das die Maschine über das Ziel hinaus fährt und droht zu kollidieren! Ich habe dann immer ein NOT-STOP ausgelöst. Ein Stoppt des Vorgangs würde auch gehen, SCC Lässt sich in den Moment normal bedienen. (Ohne NEXTION Display passiert dies auch.) Ich drücke dann den Code-Test Knopf bei SCC. Der ganze Code saust durch und in roter Schrift die Meldung! 0 Errors gefunden. Fahre die Maschine wieder auf den Nullpunkt zurück, prüfe Spindelgeschwindigkeit setze nochmal „Set Spdl“ Und drücke „Start File“ Maschine setzt sich in Bewegung und läuft bis zum Code ende Fehlerfrei durch. Was mir Aufgefallen ist, Wenn ich den Gcode nach dem einladen in SCC erst mit „Test Code“ prüfen lasse und danach Fräse, ist die Wahrscheinlichkeit das dieses Fehlverhalten auftritt gering. Wer nutzt ebenfalls inkscape (Ver.0.92) ? Und kann mir über seine Erfahrung mit Gcode Erstellung für SCC berichten? Viel Spaß beim Eier suchen! Gruß, Daniel!
Daniel S. schrieb: > ich werde es mit der Testversion von Estlcam versuchen Hallo Daniel, lass deinen G-Code mal durch den freien NC-Corrector (nc-corrector.inf.ua)laufen. Man kann dort auch Einzelschritte beobachten. Hat uns schon geholfen, Fehler zu finden. Diese Fehler waren Unterbrechungen im Zeichnungsverlauf, insbesondere in Kurven. Wenn mit anderen Dateiformaten alles fehlerfrei funktioniert hat, kann man EMV Probleme wohl eher ausschließen ?! Zu inkscape kann ich leider nichts sagen,da wir CREO benutzen. Die Konvertierung durch Estlcam funktioniert bei uns in allen Fällen tadellos. Daniel S. schrieb: > Das es an SCC liegt glaube ich nicht Nach unserer Erfahrung glaube ich das auch nicht. Das aktuelle Projekt hat über 1000 Zeilen und läuft über 60min problemlos, wobei man sich auf die Verarbeitung durch SCC(danke an Albert)verlassen kann. Wenn du deinen Code hier einstellst, kann man das Problem vielleicht besser nachvollziehen und statt Eier Fehler suchen... viele Grüße Herbert
Hallo Herbert, Habe die Datei mal hier rein gestellt. Zu den Einstellung in inkscape: Einheit = mm Unterpfad für Unterpfad Maximale Teilungstiefe = 1 (1 -10 Einstellbar) Minimaler Bogenradius 0,05 Postprozessor > Alle Werde auf vier stellen runden Z- Sicherheitshöhe G00 = 5 mm Skalieren entlang der Z Achse = 1,00000 Versatz entlang der Z Achse = 0,00000 Tool: diameter =0.5 feed =200 penetration angle =90 penetration feed = 100 depth step = 0.5 tool change gcode (None) Spindel geschwindigkeit lege ich dann in SCC fesst. Ich prüfe Die Datei immer mit „OpenSCAM“ Mit NC Corrector konnte ich auch keine Auffälligkeiten feststellen. Läuft fehlerfrei durch. Ich danke Dir für die mühe! Gruß Daniel!
Hallo Daniel, dein Problem hat mich ebenfalls interessiert, weshalb ich deinen Code einfach mal in meine Testumgebung am Bürorechner geladen habe. Ich bin genauso verfahren, wie du oben beschrieben hast (erste Zeile löschen und dann loslaufen lassen), habe allerdings keinerlei Probleme erfahren. Der Code wird einfach abgearbeitet, keine Fehlermeldungen, das Grafic-Display wird aktualisiert und zeigt das ZAhnrad an. Mittlerweile werdne dier Zähne in der dritten RUnde gezeihcnet, ich denke nach deiner Beschreibung wäre ein Fehler inzwishcen aufgetreten, oder? Ich habe allerdings keine Fräse dran, was aber keinen Unterschied machen dürfte, denn GRBL (hier läuft gerade V1.1f zusammen mit SCC 2.5.1) liefert ja keine Rückmeldungen von der Fräse (Endschalter und Tiefensensor mal ausgenommen). Ich würde also sagen, der von inkscape (und deinen sonstigen Tools) gelieferte G-Code ist einwandfrei. Gruß, Harald
Daniel S. schrieb: > Habe die Datei mal hier rein gestellt. Harald S. schrieb : > Der Code wird einfach abgearbeitet, keine Fehlermeldungen, das > Grafic-Display wird aktualisiert und zeigt das ZAhnrad an. Hallo Daniel, nachdem Eier suchen sowieso ins Wasser gefallen ist, habe ich deine Datei auf unserer Minifräse versucht laufen zu lassen. Wie bei dir und beim Harald auch, lief der Testmodus in SCC (erste Zeile gelöscht) ohne Fehler durch. Mit Maschine dran gab's aber bei Zeilen mit I und J Errormeldungen, in diesem Fall Error 33 bei allen Zeilen mit I und J und die Maschine fuhr gegen die Endschalter. Daraufhin wurde Estlcam mit der Datei gefüttert und meckerte über wahnwitzige F Raten und das die Maschine vor jeder Kurve abbremsen müsste. Der nächste Test fand mit GRBL-Panel (V1.0.9.13) statt, wo ich dein Zahnrad ohne ändern der Datei und ohne Probleme (nur Spindel aus) mehrfach fräsen konnte. Danach habe ich sämtliche F Werte von .000 befreit und auf für unsere Maschine verträgliche Werte reduziert. Mit dieser Änderung habe ich dein Zahnrad auch mit SCC mehrfach problemlos gefräst. So richtig werde ich nicht schlau draus, warum die Originaldatei mit GRBL-Panel funktioniert und mit SCC nicht. Viele Grüße Herbert
Herbert Janssen schrieb: > beim Harald auch, lief der Testmodus in SCC Nein, ich habe die Datei normal abgearbeitet, nur auf meinem TestSYSTEM (nicht Testmodus in SCC), also auf meinem Rechner im Büro, wo keine Fräse angeschlossen ist, nur ein Arduino Nano mit GRBL 1.1f drauf. Für den Rechner und damit für SCC ist das wie mit Fräse, nur laufen keine Motoren. Aber das nur am Rande. Gruß, Harald
Hallo Harald und die andern. Ja! Zwischen Start und Fehler liegen nur 5 sec. Der Fehler wäre schon längst Aufgetreten. Ist bis dahin alles OK läuft es auch bis zum Ende durch. Die Fräse läuft bei mir nur unter XP. Ohne Internet. Und nur das notwendigste drauf. Als ich letztens beim Kumpel Hannes war haben wir auch Dateien von Inkscape gefräst. Er nutzt an seiner Fräse die gleiche Hardware und gleiche Software wie ich. Bei der dritten oder vierten Datei trat dann der Fehler auf. Ich habe fünf versuche gebraucht damit es lief. Er nutzt auch nur PC mit XP Keiner von uns beiden hat Aktuell eine Webcam im Einsatz, Das System hat auch keine Auslastung Pentium 4 mit 2 Ghz und 2 GB RAM. Der Fräsvorgang der letzten drei Zahnräder hat 1 ½ Stunde gedauert. Da bin ich sogar runder vom Boden und habe erst mal Kaffee getrunken. Lief fehlerfrei. Soviel vertrauen habe ich in meine Fräse und Alberts Proramm. Bei den Gcode Zeilen in SCC Steht dahinter immer OK bei Send und OK Bei Antwort. Wenn der Fehler auftritt steht bei Antwort error und für die nächsten c.a. 10 Zeilen. Ich mache mal ein Foto wenn es wieder auftritt. Ich habe Die Datei ebenfalls an einen anderen PC (XP) trocken Laufen lassen, nur UNO Ohne Motortreiber. Bis jetzt habe ich c.a 10 Dateien von Inkscape gefräst. So viel Erfahrung habe ich mit dem Programm noch nicht. Das letzte Jahr habe ich Ausschließlich nur mit Sprint-Layout 6.0 von Abacom gearbeitet. Damit habe ich *.plt Dateien zum isolationsfräsen erstellt. Einfache Geometrische Figuren waren auch möglich. Den Gcode konnte ich dank Albert von SCC erzeugen lassen. Beim Fräsen gab es nie diese Störung. Meine EMV Störung hatte ich in Griff bekommen. Es ist auf jeden Fall empfehlenswert den PE mit an die Fräse zu legen. Kurzes Abgeschirmtes USB Kabel. Seit dem habe ich bei meiner aus Alu ruhe mit EMV. Vorher musste ich aufpassen das ich das Licht (Leuchtstoffröhre) vorher anmachte. Machte ich es wäret der Verbindung SCC > UNO An kam sofort ein Fenster Verbindungsfehler!!! Ich habe grade alle Dateien (6) durch SCC laufen lassen ohne Motortreiber. Keine Fehler! So wie es aussieht bin ich und Hannes die bei denen der Fehler auftritt sonst niemand? Wenn ich eine Lösung habe werde ich darüber hier berichten. Schöne Grüße ! Daniel!
Hallo Herbert. Ich Danke Dir für die Analyse! Was mich stutzig macht das Die gleiche Datei einmall läuft und einmal nicht. Habe bis heute früh. Einige Dadeien durchlaufen lassen genau wie Harald ohne fräse. Nur UNO am Pc mit SCC. Bei keiner trat der Fehler auf! Wollte so spät nicht nochmal auf dem Boden wo die fräse steht. Vielleicht ist auch eine Einstellung in Inkscape die Ursache. Was ich nicht verstehe ist die Datei fehlerhaft oder nicht? Du bekommst die dabei zum laufen (fräsen) wenn Du den Test bei SCC vorher durchlaufen lässt. Dann werden auch keine Fehler mehr angezeigt. ohne den Test kam häufig der Fehler. Habe mitunter die Datei fünf mal laden müssen bis sie von GBRL Akzeptiert wurde.Ich habe bis jetzt jede Datei fräsen können. Gruß Daniel
Da Du das Thema Leuchtstoffröhre angesprochen hast... ich habe bei mir einen grösseren Netzfilter für die Steckdosen der CNC Geräte installiert... damit waren dann solche Probleme wie das Einschalten der Leuchtstoffröhren Vergangenheit.
Hallo Avantasia, das mit dem Netzfilter ist eine gute Idee. Ich habe noch so eine Steckdose mit Überspannung- Blitz –Schutz. Ist da ein solcher Filter drin? Ich hatte einige EMV Störung als ich die Ganze Steuerung für die Fräse inklusive UNO in ein Metallgehäuse steckte. Dachte grade mit PE geerdet und gut. Ergebnis war ich konnte überhaupt nicht mehr Fräsen, Nach dem Verbinden in SCC Kam nach 10 sec. Ein Fenster Verbindungsfehler!!!! Als ich die Uno Platine raushing lies ging es wieder ohne Probleme. Musste nur auf die Leuchtstofflampe aufpassen. Als ich letztens den UNO wieder rein steckte und den PE an die Fräse klemmte war der Fehler weg. Eindeutig EMV. Allerdings war die UNO Platine vorher so verbaut das die USB Buchse direkt hinten raus schaute und Kontakt mit dem Gehäuse hatte. Jetzt habe ich sie weiter rein genommen so das der kontakt USB-Buchse und Gehäuse nicht mehr besteht. Werde ich vielleicht isolieren. Hallo Herbert und Harald Ich werde mir die Datei nochmal genauer anschauen. In Bezug auf Zeilen mit I und J und F Werte mit .000 ich vermute das GRBL damit überfordert ist. Ich werde versuchen das bei der Gcode Erstellung mit Inkscape zu optimieren. Vielleicht übermittelt GRBL-Panel (V1.0.9.13) die .000 nicht mit und deshalb kein Fehler? Zur Zeit Plane ich noch ein Display (20*4) an die Fräse zu bauen, Was mir die Spindel Umdrehung (U/min) Anzeigt und die Temperatur (Spindel, Schrittmotoren und Steuerung) überwacht. Bei Übertemperatur einen NOT-STOP Auslöst. Allerdings nach dem Fräsvorgang. Das ganze läuft unabhängig von dem Rest der Elektronik. Am Spindelmotor Kommt oben am Lüfter-Rad eine Lichtschranke und Reflektoren (4) am Lüfter. Die Berechnung und Anzeige übernimmt ein Atmega8 mit 16 Mhz, Damit habe ich 4 Pegel/U oder 8 Flankenwechsel/U die der Atmega8 pro Sekunde Zählt und auf eine Minute hoch rechnet. Aktualisiert wird einmal pro sec. über die analogen Eingänge kommen die fünf Temperatursensoren. Ich finde die Anzeige sehr hilfreich. Grade bei unbekannten Plexiglas aus alten LCD Fernseher hatte ich schon öfters Schwierigkeiten bis es lief. Als Hannes dann anfing mit Plexiglas, konnte ich ihn von meine Erfahrung berichten. Aber zu sagen ich habe bei SCC 200 bei „Set Spdl“ Angegeben nutzt ihm nichts Da seine Spindel mit 20V Läuft und meine mit 49V. Er müsste grob das Doppelte angeben Um auf die gleiche U/min zu kommen. Da ich ihm auch so ein Drehzahlmesser mit Atmega8 und Display bauen werde kann er die U/min direkt ablesen. Gruß Daniel!
Also ein EMV Filter ist kein Überspannungsblitzschutz. Ich habe soetwas (jetzt nicht genau diesen) in meinen Brüstungskanal mit Steckdosen eingebaut... Beispiel: https://www.buerklin.com/de/entstoerfilter-einphasig/p/73d240
Hallo Avantasia, Ich werde mir die Stecker-Leiste heute Abend mal von innen anschauen ob da ein Netzfilter mit drin ist, wenn nicht kommt einer rein. Die leiste ist nicht länglich sondern Quadratisch Aufgebaut 2x3 Dosen. Da ist sicherlich noch Platz drin. Da sind auch Anschlüsse für Antennen-Kabel dran. Gruß Daniel
Daniel S. schrieb: > ich habe bei SCC 200 bei „Set Spdl“ Angegeben nutzt ihm > nichts Da seine Spindel mit 20V Läuft und meine mit 49V. Er müsste grob > das Doppelte angeben Um auf die gleiche U/min zu kommen. Hallo Daniel, vielleicht hilft dir dieser Beitrag weiter (zumindest, was die Drehzahl angeht): [[Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"]] Ich denke schon :-) Gruß, Harald
Hallo Harald S. Daran kann ich mich gut erinnern. Soweit ich das richtig verstehe sollte $31 auf 0 bleiben und $30 Standard 1000 (Maximalwert) Nach unten hin anpassen bis die Eingabe bei „Set Spdl“ direkt die Spindel Drehzahl in 10tel Wert entspricht. Bei Eingabe von 240 müsste die Spindel mit 2400 U/min laufen. Je nach Spannung und Maximal Speed der Spindel muss ich das an Hand der $30 Austesten. Quasi Kalibrieren. Dazu bräuchte ich ja auch einen Drehzahlmesser um zu prüfen wann es passt. Mir würde es nicht auf die korrekte U/min drauf ankommen da ich weiß das 255 Stufen ziemlich grob ist. Die Einstellung müsste bei jeder Maschine separat und mit eigen wert erfolgen. Wie in den Beispiel bei Hannes 20V und bei mir mit 49V brächte er auch einen andern Wert. Wie weit bist du damit gekommen? Konntest du es damit Anpassen damit Du eine gute Abstimmung hast? Daniel!
Hallo Daniel, ich habe das gut anpassen können, bis auf ein paar Upm stimmt die Anzeige meines Spindel-Umrichters mit der Vorgabe in SCC überein. Allerdings habe ich mich wohl etwas ungenau ausgedrückt. Ich versuche es nochmal... $31, für den unteren Grenzwert muss auf 0 bleiben, sonst funkt der Offset dazwischen, den man mit einem anderen Wert für $31 einstellen würde. Also $31=0. $30, für den oberen Grenzwert stellt man in erster Näherung auf die Maximaldrehzahl der Spindel ein, bei einer Chinaspindel wie meiner also z.B. 24000. GRBL teilt die Drehzahlspanne dann in 255 gleiche Teile ein und gibt am Ausgang für die analoge (PWM) Drehzahleinstellung dann eine Spanunng (genaugenommen eine PWM die geglättet eine Spannung ergibt) aus, die den Spindel-Controller dazu animiert, die in SCC gewählte Drehzahl einzustellen. Dabei muss in SCC dann die gewünschte Drehzahl ohne Mathematik eingestellt werden: Du willst 18500 Upm, du gibst in SCC 18500 an. Mein Spindel-Controller hat eine Digitalanzeige, die unter anderem auch die aktuelle Drehzahl ausgibt. Da ich nicht wusste, wie die Angaben in SCC mit der Drehzahl korrelieren, habe ich recht früh mit einer Reflexionslichtschranke und einem Oszi die echte Drehzahl der Spindel gemessen, während ich Werte in SCC eingestellt habe. Mit der erhaltenen Tabelle konnte ich dann, ähnlich wie du das gemacht hast, dedizierte Werte in SCC einstellen um die gewünschte Drehzahl zu erhalten. Zu diesem Zeitpunkt hatte ich den Trick mit GRBL noch nicht gekannt, möglicher Weise kannte GRBL den Trick damals (V0.9) ebenfalls noch nicht. Mit Umstieg auf GRBL V1.1 klappt das jedenfalls prima. Was jetzt die unterschiedlichen Spannungen für Vollgas angeht, ist das GRBL (und SCC) eigentlich egal. Der Arduino kann sowieso nur Spanungen bis 5 V (genaugenommen sind es bei mir maximal 4,7 V durch den Tiefpass, ein R in Reihe, ein C parallel am Eingang des Spindel-Controllers) ausgeben, ihr müsst also für eure Controller einen Spannungs-Converter zwischen Ausgang des Arduino und den Eingang des Spindel-Controllers schalten, der die 255 Stufen zwischen 0 und 5 V des Arduino in 255 Stufen zwischen 0 und 20 bzw. 0 und 49 V verstärkt. Das habe ich selbst bisher noch nicht geschafft, meine Spindel dreht deshalb maximal bis 22400 (statt der erreichbaren 24000). Das ist auch der Grund, weshalb ich "etwas mit den Einstellungen spielen musste". Mein Controller versteht übrigens von Hause aus 0..10 V (und 24mA Stromschleife und noch ein paar andere Eingangssignale), das kann ich aber umparametrieren auf 0..5 V, was ich getan habe. Irgendwann setze ich einen der von den Kollegen hier im Forum vorgeschlagenen Pegelwandler (weiter oben suchen) ein um die vollen 24000 Upm zu erreichen, dann kann ich für $30=24000 einsetzen. Ich hoffe, das ist jetzt besser verständlich? Gruß, Harald
Hallo Albert, erst einmal vielen Dank für dein Programm. Bisher das beste, was mir untergekommen ist. Habe nach einer langen Fraespause jetzt auf die neueste Version mit Nextion Display aufgerüstet. Betriebsystem ist win10 ohne Cam. Scc Läuft immer allein auf dem Rechner. Mit Grbl 09f und SCC wurden meine Profili-Dateien korrekt abgearbeitet. Mit der neuen Version habe ich mit von Profili erzeugten Dateien das gleiche Problem wie Daniel Steinboeck mit inkscape. Der Test ist immer Fehlerfrei. Die Fraese fährt auf die erste Position, senkt die Z-Achse ein bisschen ab( jetzt gibt es einen Errorcode) und fährt dann in die Endschalter. In NC-Korrektor läuft alles einwandfrei. Mit Estlcam erzeugte Dateien laufen immer einwandfrei. EMV kann ich, glaube ich, ausschließen; hatte noch nie ein Problem damit. Werde morgen mal auf die alte Version zurück gehen und erneut testen.
Hallo Harald, Jetzt ist es klar. die 1000 ist nicht die Obergrenze sondern die Voreinstellung und entspricht 5V auf dem PWM Ausgang. Die Spindel läuft bei angabe in Scc 1000 mit 100% 49V wenn ich denn wert für 100% Leistung also $30=12000 setze muss ich in SCC 12000 eingeben um auch auf 12000 =100% Zu kommen. 12000 ist bei meiner daß maximale U/min. Und bei Eingabe von 2400 in SCC müsste dann auch 2400 U/min raus kommen. Werde es mit dem Ozzi nach messen. Mein Spindeltreiber bekommen direkt den PWM Ausgang vom UNO und der liegt bei 100% bei 5V (Jetzt $30=1000 und Eingabe SCC 1000 ) ich werde es mal mit $30=12000 ausprobieren. Ich hoffe ich kann den wert auch höher als 5000 in SCC eingeben? Hatte ich noch nie versucht. Gruß Daniel!
Hallo Daniel, genau so ist es. Gruß, Harald
Ich habe es auch kurz mal probiert, max. war 22000U/min. Hat auch funktioniert, sowohl mit SCC/GRBL als auch mit MACH3/PC. In der Praxis jedoch fand ich es eher störend, immer die passende Drehzahl angeben zu müssen. Ich habe es zurückgerüstet, daß die Spindel nur ein oder ausgeschaltet wird, die Drehzahl ist meist immer 22000U/min, nur bei Holz und Kunstoffen muss ich die von Hand anpassen, das geht prima am FU. Aber ist ja trotzdem ne nette technische Möglichkeit!
Hallo! Ich habe das mit der Spindel Umdrehung mal umgesetzt. Zuerst habe ich den Wert bei $30=1000 so belassen und 1000 in SCC angegeben damit ich bei 100% liege. Mit dem Oszilloskop habe ich mir die PWM Angeschaut. Die lag genau auf 5V. Am Lüftungsrad der Spindel ist ein streifen schwarzes Isolierband angebracht. Damit habe ich ein Signal pro Umdrehung. Sollte reichen. mit der Eigenbau Lichtschranke aus IR Diode und einer Foto Diode. Diese habe ich in einen Winkel von c.a. 30° Angeordnet. Naja eher habe ich solange rumprobiert bis das Signal gut zu sehen war. Sieht fast so aus wie die PWM mit 80% 20% Verhältnis und um einiges langsamer. Rund 204 Hz *60 = 12240 U/min . Also habe ich bei SCC $30=12240 Eingetragen. Und bei „Set Spdl“ ebenfalls 12240. Messung wie erwartet 204 Hz. Bei der Angabe von 2400 „Set Spdl“ 40 Hz *60 =2400 U/min. das dies passt ist eher Zufall Bei Eingabe von 3000 müsste ich auf 50Hz kommen. Es schwankt bei 50,5 Hz = 3030 U/min bei 2999 dreht sie nur mit 2970 U/min dies ist auch nicht verwunderlich. Bei 255 Stufen bekommt man immer eine U/min von +- 50. Und das reicht mir vollkommen aus. Mir kommt es dabei nicht auf die genaue Umdrehung an. Ich finde dies ziemlich brauchbar. Den wenn ich Hannes meine Werte für Plexiglas gebe und grade das Bastelglas was ohnehin Empfindlich ist. Und ich sage 2400 U/min 0,94mm Fräser 2-schneider ,F200 und Max 0,3 mm Zustellung. Denn kann er auch damit etwas anfangen. Seine läuft nur auf 20V mit gleichem Motor. Wenn ich sage: habe 200 bei SCC eingestellt würde es bei ihm keinen Sinn machen. Sie würde viel zu langsam laufen. c.a. nur mit 1000 U/min .was ihn sicherlich seinen Fräser kosten würde. So kann ich bei seiner Maschine die gleiche kalibrierung durchführen und dann kommt bei ihm auch 2400 U/min raus, wenn er 2400 bei SCC Angibt. Das ist der Hintergrund warum ich das mit der Drehzahl haben möchte. Man sollte nur die Maximale U/min im Kopf haben damit man weiß wo die Grenze ist. Vielen Dank noch mal an Harald S. Gruß Daniel!
Wenn Du oft das gleiche Material (plexiglas etc.) fräst und diese Daten dann noch weitergeben möchtest, ist die Drehzahlregelung natürlich sehr sinnvoll! In meinem Fall ist es aber oft so, daß bei Kunstoffen alles mögliche "anfällt" und ich immer die Drehzahl anpassen muss, ob das Bastlerglas aus dem Baumarkt, nen alten Plattenspieler-Deckel (immer ein guter Materialspender ;-) ), ganz frisches oder ganz altes Plexiglas, da gibt es dann doch große Unterschiede, daher brauche ich diese automatische Drehzahleinstellung nicht. Noch ein Tip: wenn Ihr einen Mosfet mit RC-Glied zum glätten an die 10V vom FU anschliesst, wird das PWM invertiert. Bei meinem FU habe ich dann einfach minimum Drehzahl auf 22000 und maximum Drehzahl auf 0 im Setup des FUs eingestellt. Weiss nicht, ob das bei jedem FU geht, bei der Siemens Micromaster Serie gehts. Interessant wird die PWM Steuerung für mich, wenn der Laser an die Fräse kommt! Dann kann man prima die Leistung regeln. Schönen Abend noch und Albert, weiter so! Daumen hoch!
Hallo Hr. Massen, würde die Möglichkeit bestehen einen weitere Funktion um eine Kühlmittelpumpe einzuschalten in Ihre Software einzubauen (Nano Pin A3) Würde mich über eine Antwort freuen.
K.S. schrieb: > würde die Möglichkeit bestehen einen weitere Funktion um eine > Kühlmittelpumpe > einzuschalten eine Kühlmittelpumpe kann im G-Code mit M8 eingeschaltet M9 ausgeschaltet werden oder in SerialComCNC mittels Manuelle G-Code Eingabe. M8 eingeschaltet = Nano Pin A3 5V M9 ausgeschaltet = Nano Pin A3 0V Gruß Wolfgang
Hallo, Das mit der Spindelsteuerung über GRBL Funktioniert nicht so wie erwartet. Auch wenn es bei 2400 U/min noch passt bei 3400 U/min verläuft es nicht linear, sondern in einer Kurve. Die Geschwindigkeit nimmt im unteren PWM Bereich sehr schnell zu so das man bei Angabe von 6000 U/min auf 10000 kommt. Im obersten Bereich nimmt die Geschwindigkeit nur noch gering zu. Was die Sache wieder unbrauchbar macht. Mit den zwei Werten $30 und $31 zu spielen macht für mich keinen Sinn, damit würde man die Kurve nicht glätten können. Man bräuchte Da schon eine Zwischenschaltung die aus dieser Spannungs Kennlinie eine lineare Funktion macht. Ich habe meine Einstellung wieder zurück genommen. Es bleibt erst mal bei $31=0 und $30=1000. Werde mir doch das Display für die Drehzahlanzeige bauen, damit ich zumindest einen Eindruck auf die tatsächliche Drehzahl habe. Hallo Avantasia! In der Stecker Leiste ist kein Netzfilter (EMV Filter)drin. Werde da noch einen mit einbauen. Hallo Herbert Janssen, Das mit den F Werten (.0000) bei inkscape konnte ich bis jetzt nicht lösen. Ich habe mir die Einstellung beim Postprozessor angeschaut und probiert. Es wird Empfohlen dort die Einstellung „Auf Vier Stellen nach dem Komma zu Runden“ zu wählen wenn die Datei mit GRBL Gefräst wird. Das hatte ich bis jetzt auch getan. Bei anderen Einstellung sind es sogar noch mehr nullen hinter dem Komma bei den F Werten. Nur wenn ich die F Werte von .0000 befreie ist der Fehler weg. Wie du beschrieben hast. Ein Feed von 200,0000 macht für mich auch keinen Sinn. Wie es Harald S. auch beschrieben hat tritt der Fehler nicht auf wenn keine Fräse Beziehungsweise keine Motortreiber Verbunden sind. Das Gleiche habe ich auch Festgestellt. Meines achtendes kann Der UNO beziehungsweise GRBL das nicht unterscheiden da keinerlei Rückmeldung erfolgt. Mir ist dies ein Rätzel. Der Fehler müsste doch in beiden Fällen auftreten?? Konntet Ihr den Fehler lösen? Außer die Werte selbst zu korrigieren? Hallo Isensewa! Liegt es bei dir auch an den F Werten mit „ ,0000“ Angabe? Hast Du den Fehler bei Dir beseitigen können? Gruß Daniel!
wozu sollen die F-Werte überhaupt Stellen nach dem Komma haben? Wen interesiert es, ob die Spindel 10000 oder 10000.123 U/min macht? Die schwankt beim fräsen und selbst im Leerlauf doch sowieso.
Angehängte Dateien:
Hallo Hat jemand für mich eine Idee wo das Problem sein könnte das SerialComCNC (Version 2.51) die USB Schnittstelle (Com3, Baud 115200)nicht mehr erkennt (siehe Fehlermeldung). Den Ardunio habe ich schon auch an anderen PC angeschlossen gleiches Problem. Die Schnittstelle hat schon mal funktioniert mit SerialComCNC (evt. ältere Version) Hat jemand eine Idee für mich an was es liegen könnte? (PC W10 64-bit und W10 32-bit). Mit anderer Softsoftware wird Arduino erkannt. Grüße Uwe
Hallo Uwe W. Wenn du es bis jetzt nicht lösen konntest, hier ein paar Tipps! Arduino an einen USB 2.0 Port anschließen (Kein USB 3.0). Den Arduino erst anstecken wenn der PC bereits läuft. Wenn bei Windows 10 die Benutzerkontensteuerung aktiv ist, dürfen Programme nicht Direkt auf Hardware zugreifen, es sei denn Sie werden als Admin ausgeführt. Starte SerialComCnc mal als admin. Bei SerialComCnc das Häkchen vor Port entfernen (autom. Portsuche aus) und dann den gewünschten ComPort aus der Liste wählen. Den Arduino angesteckt lassen und den Treiber deinstallieren, Arduino ab und dran stecken, Treiber erneut installieren. Gruß Daniel!
Hallo Daniel Danke für die Tips mit den USB Port. Leider bin ich nicht weitergekommen, habe alles ausprobiert wie du beschrieben hast. Das seltsame ist mit Estlcam und Ardunino Entwicklungsumgeben wird das Board problemlos erkannt nur nicht mit SerialComCNC. Hast du noch eine Idee für mich? Grüße Uwe
Mir fällt gerade nichts ein. Das mit dem Häkchen raus nehmen hast Du probiert? Ich nutze es nur unter XP. Da gab es nie etwas damit. Unter Windows 7 läuft es auch. SCC hat auf die Treiber keinen Einfluss. Es könnte allerdings der imstallations Ordner damit zusammen hängen. Imstalliere das SCC in einen separaten Ordner. Ich habe es auf C:\Programm installiert. Dort installiere ich immer meine Programme hin. Mache ich schon seit Windows 98 so. Einen Versuch wäre es wert. Gruß Daniel!
Hallo Uwe, Erkannt denn Windows deinen Arduino im Gerätemanager? Eventuell ist das Bosrd defekt, hatte ich auch mal... Kauf dir einen neuen Arduino und probiere es nochmal. Die Dinger kann man immer gebrauchen ? Viele Grüße Sven
Oder einfach mal einen anderen USB Port versuchen und das Kabel tauschen
Mir fällt noch etwas ein, du musst bei SCC 2.x die Grbl1.x auf den Arduino korrekt geflasht haben, sonst kann es nicht klappen mit der Erkennung im SCC
Daniel S. schrieb: > Es wird Empfohlen dort die Einstellung „Auf Vier Stellen nach dem Komma > zu Runden“ zu wählen wenn die Datei mit GRBL Gefräst wird. Hallo Daniel, da deine Datei zumindest bei mir mit einem anderen Programm (Grbl-Panel) klaglos (mit Fräse !) läuft, liegt es vielleicht an der unterschiedlichen Prozessdatenaufbereitung in Richtung GRBL. Die Fehlergrenze für ijk Berechnung liegt bei "0.005mm AND 0.1% radius" (siehe gcode.c) und erzeugt bei Überschreitung den Fehler 33, der bei mir ab dem ersten G02 Kommando entsteht. Für die Mathematiker unter uns ist es sicher ein Leichtes auszurechnen, ob es da einen Zusammenhang gibt, wenn auf 4 statt auf 3 Nachkommastellen gerundet wird !? Estlcam bietet nicht umsonst verschiedene Optionen der Gcode-Erzeugung bezogen auf Kreisinterpolationen an. Vielleicht ist der UNO mit eventuellen Rundungsaufgaben überfordert, wenn die Hardware angeschlossen ist ?. Aber vielleicht bin ich mit diesen Überlegungen völlig auf dem Holzweg, da ja die Probleme nur bei uns auftreten. Möglicherweise kann uns Albert ja bei der Lösung weiterhelfen ? Daniel S. schrieb: > In der Stecker Leiste ist kein Netzfilter (EMV Filter)drin. > Werde da noch einen mit einbauen. Die Probleme mit EMV Störungen haben wir nicht. Beim Zusammenbau der Komponenten habe ich mich von Beginn an geweigert, die 5V Versorgung und die UNO I/O Konnektoren mehr als 10 cm von der Platine zu entfernen. Einzig der gemeinsame Gnd der Versorgungsspannungen (Motortreiber 20V und UNO Versorgung 5V) liegt an den Schaltern an der Maschine. Endschalter und Sensor sind über Relais entkoppelt. Im Umkreis von 2 m haben wir in der Werkstatt Bohrmaschine mit FU, Drehmaschine, Schleifbock Elekronikarbeitsplatz und etliche Leuchtstoffröhren in Betrieb. Am Rechner sind zusätzlich Wlan-Stick, Kamera, N-Display + Jogging-Bedieneinheit aktiv. Bisher gab's keine Probleme. Wenn Interesse besteht, kann ich den Verdrahtungsplan einstellen. viele Grüße Herbert
Hallo Sven Der Tip mit den flashen auf die aktuelle GBRL war Gold richtig. Muss ich beim letzten Update von SerialComCNC wohl vergessen haben. Vielen Dank nochmal. Grüße Uwe
Hallo Uwe, Aber gerne doch, freut mich wenn ich dir helfen konnte und deine Fräse wieder funktioniert Viele Grüße Sven
> Daniel S. schrieb: >> Es wird Empfohlen dort die Einstellung „Auf Vier Stellen nach dem Komma >> zu Runden“ zu wählen wenn die Datei mit GRBL Gefräst wird. Hallo Daniel, nochmal zum Thema Inkscape und Gcode-Erzeugung: das Problem ist offensichlich die Kreisinterpolation (wie schon vermutet) hat aber wohl weniger mit den Nachkommastellen zu tun. GRBL akzeptiert nur inkrementelle Kreiskoordinaten (relativ zur letzten Position). Kann man in SCC einfach testen: G90.1 (abs. IJ) error:20 G91.1 (inc. IJ) ok Schau mal in Inkscape, ob du das einstellen kannst. Estlcam erzeugt je nach Einstellung unterschiedlichen Code, der eine funktioniert, der andere macht error 33 (in SCC). Vielleicht wird bei anderen Programmen der Gode GRBL verträglich gemacht. Das NC Corrector keine Fehler erkennt, ist damit auch klar, denn der Code ist in beiden Fällen ja korrekt, nur in einem Fall nicht GRBL kompatibel ! viele Grüße Herbert
Hallo Herbert, Erst mal danke für deine Analyse! Es ist erst mal sehr gut das Du die eigentliche Ursache finden konntest und den Fehler reproduziert hast. Ich werde versuchen das in Inkscape zu Optimieren. Gruß Daniel!
Was ist denn mit Albert los? Geht es dir gut? Mann hört ( oder liest) gar nichts mehr von dir ... Viele Grüße Sven
Hallo Sven, du musst den ganzen Thread lesen, dann weißt du Bescheid ;-) Im Sommer ist Albert draußen mit dem Foto unterwegs. Gruß, Harald
Ok, dann brauche ich mir also keine Sorgen machen...
Hallo Ich bin gerade dabei mich in Sachen CNC einzuarbeiten. Ich habe ein Arduino Uno mit einem CNC-Shield V3 und GRBL 1.1. Durch Suchen bin ich auf das geniale Programm hier gestoßen. Ich würde gerne bei meiner Fräse Endschalter verbauen. Auf dem CNC-Shield habe ich die Möglichkeit, für alle 3 Achsen, Endschalter anzuschließen. Aus der Industrie kenne ich es so, das für Hardwareendschalter immer Öffner benutzt werden. Ich würde das genau so machen wollen. Bei Tests haben sich jetzt aber einige Fragen aufgetan. Die GRBL-Parameter $21 und $5 habe ich auf 1 gesetzt. Fahre ich jetzt in einen Hardwareschalter rein, bleibt die Fräse auch mit entsprechender Meldung stehen. Meine Fragen wären: Ist es möglich, aus dem Hardwarschalter wieder heraus zu fahren oder kann ich die Achse nur per Hand verschieben? Ich kann nachdem ich auf einen Hardwareschalter gefahren bin den Fehler nicht quittieren, weder mit "Reset" noch mit "Alarm Reset", ich bekomme immer wieder "error9". Erst nach einem kompletten Neustart läuft wieder alles. Wie quittiert man einen Alarm, wenn man auf einen Hardwareendschalter aufgefahren ist? Schon mal Danke für eure Hilfe! MfG computerpap
Hallo Andreas, Im Moment habe ich keine Erschallter dran, hatte es vor einiger Zeit (1 Jahr) selbst versucht (SCC Ver. 0.9f) Soweit ich mich erinnern kann musste ich immer „Alarm Reset“ Drücken nach den ich in einen der Schalter gefahren bin. Ich hatte sie genau wie Du es vorhast als Öffner und in Reihe für jeweils einer Achse. Es waren Kontaktschalter. Ich musste die Pins vom UNO XYZ Achse Limit mit Kondensatoren gegen Masse legen damit es als Öffner funktionierte. Allerdings trat das Schalterprellen auf. Wenn man nach dem Alarm Reset aus den Schalter raus fuhr, kam gleich wieder Alarm! So das man mehrmals Reset drücken muss damit man wieder raus kam. Habe dann die Achse von Hand rausgefahren da es schneller ging. GRBL-Parameter $21 und $5 auf 1 Also Endschalter Funktion eingeschaltet und löst bei fallender Flanke aus. Wenn ich mich nicht irre. Laut GBRL Wird beim auslösen des Schalters sofort gestoppt ohne abzubremsen, und nimmt dabei Schrittverluste im Kauf. Das heißt Dein Nullpunkt ist ohnehin dahin! Weiterhin heißt es der Alarm muss erst quittiert werden damit man wieder fahren kann. Jetzt kann ich nicht sagen in wie weit Änderung in der GBRL 1.1f vorgenommen wurden, das der „Alarm Reset“ nicht mehr so funktioniert. Und wenn der „Alarm Reset“ nicht Funktioniert kannst du auch ein Komplett Reset machen. Dies dient ja als Not-Fall. Bevor etwas kaputtgeht. Nach dem Umbau der Maschine hatte ich dann die Schalter weg gelassen und wollte dann mit Lichtschraken testen. Das geht bestimmt besser. Bin bis jetzt noch nicht dazu gekommen es zu testen. Ich muss sagen ich habe sie auch nicht vermisst. Wenn ich die Maschine verbinde fahren ich Manuel auf meinen Null- Punkt und Nulle. Dieser liegt meist immer an der gleichen Stelle, Ich weiß aus dem Kopf wie weit ich fahren kann. Und wenn ich denke es könnte knapp werden messe ich nochmal nach. Als ich letztens die Störung mit dem GCODE von inkscape hatte, währen die Endschalter nützlich gewesen. Da ich aber daneben stand und merkte das die Maschine über das Ziel hinaus fuhr, löste ich sofort einen NOT-Aus aus. Zumal der Fehler gleich in den ersten 5 Sekunden auftrat. Gruß Daniel!
Daniel S. schrieb: > Allerdings trat das Schalterprellen auf. Wenn man nach dem Alarm Reset > aus den Schalter raus fuhr, kam gleich wieder Alarm! Hallo Daniel, Der erneute Alarm ist, glaube ich kein Schalterprellen, sondern entspricht der GRBL Endschalter Überwachung, die auf jede Änderung der Schalter reagiert ! Blöderweise kann man nach dem Reset in die gleiche Richtung weiter fahren, da die Auslöserichtung, wenn sie denn gespeichert/gesperrt würde, auch verloren geht. Viele Grüsse Herbert
Andreas V. schrieb: > Wie quittiert man einen Alarm, wenn man auf einen > Hardwareendschalter aufgefahren ist? > Schon mal Danke für eure Hilfe! > > MfG > computerpap Normalerweise unterstützt GRBL dafür den Parameter Homing debounce. Hier wird angegeben, wieviel mm die jeweilige Achse nach dem erreichen der Homing-Endschalter wieder aus dem Schalter fahren soll um den Homing-Zyklus abzuschließen. Die Endlagenschalter sind entweder im Normalbetrieb als Schutzfunktion zu sehen, die verhindern sollen, dass die Fräse das Portal "verlassen" will. In zweiter Funktion dienen Sie dazu die Home-Position zu definieren. Ablauf: Homing starten -> Fräse verfährt die Achsen mit der Homing Geschwindigkeit (Achtung in GRBL festgelegt!!! anzupassen) -> bei erreichen der Home-Position wird noch ein Debounce ausgeführt um die in GRBL eingestellte Distanz mit der Debounce-Geschwindigkeit -> die Maschinenpositionsdaten sind nun auf 0;0;0 gesetzt. Wenn die Endlagen im normalen Programmablauf erreicht wurden, kann man diese nur durch händischen Eingriff wieder verlassen. Ein Homing-Zyklus ist auch dann nicht möglich. Irwie hab ich das Gefühl, dass kaum einer die GRBL-Doku liest... MfG EGS
Herbert Janssen schrieb: > > Der erneute Alarm ist, glaube ich kein Schalterprellen, sondern > entspricht der GRBL Endschalter Überwachung, die auf jede Änderung der > Schalter reagiert ! > > Blöderweise kann man nach dem Reset in die gleiche Richtung weiter > fahren, da die Auslöserichtung, wenn sie denn gespeichert/gesperrt > würde,... Die Auslöserichtung wird nicht erfasst, die Endlagen sind in GRBL nur Achsbezogen. entweder der eine oder andere Endlagenschalter löst den Alarm aus. ES IST ABER IMMER DER GLEICHE ALARM! Also entweder Z-, X- oder Y-Achse hat eine Endlage erreicht, nicht oben/unten oder links/rechts. Da gibt es keine Differenzierung bei GRBL. Außerdem ist es einstellbar wie GRBL das Endlagenschalter-Signal verarbeiten soll. Entweder high oder low-aktiv. Lest die Doku zu GRBL!!! MfG EGS
So hier mal was zum lesen: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration Parameter die für die letzten 4 Beiträge relevant sind: $5, $21-$27 Wer kein Englisch kann, ich übersetz dass auch gerne mal ;-) MfG EGS
Hallo Daniel und Herbert Danke für eure Hilfe. Ich habe es jetzt rausbekommen, wie ich die Achsen nach einen Anfahren des Endschalters wieder bewegen kann. Mann muß nach einem "Reset" noch ein "$X" für die X-Achse)an GRBL senden, dann kann man die Achsen wieder verfahren. Das bekommt man als Nachricht angezeigt, ich hatte das überlesen. Ich versuche meine Endschalter jetzt mal über Optokoppler anzuschließen, ich hatte da was im Netz gefunden. Mal sehen ob das besser funktioniert als die Widerstand-Kondensator-Schaltung. @EGS, sicher hab ich mir die Doku zu GRBL angeschaut und weil ich nicht perfekt englisch spreche, hab ich mir diese übersetzen lassen. Meine Fragen galten jedoch der Software "SerialComCNC" und da findet man in der Doku zu GRBL logischerweise nichts. Homing-Zyklus ist noch gar nicht aktiviert, weil ich erstmal die Endschalter nur als reine Hardwareendschalter einsetzen möchte. MfG computerpap
> Meine Fragen galten jedoch der Software "SerialComCNC" und da findet man > in der Doku zu GRBL logischerweise nichts. Homing-Zyklus ist noch gar > nicht aktiviert, weil ich erstmal die Endschalter nur als reine > Hardwareendschalter einsetzen möchte. > > MfG > computerpap Da SCC nur ein Frontend ist, ist es schon relevant was GRBL macht. SCC erzeugt auch nur den G-Code der diese Funktionen ausführt. Zusätzlich hat Albert nette Funktionen zum automatischen erzeugen von bestimmten Codes und Erleichterungen eingebaut, damit man nicht immer mit einer Terminalsitzung G-Code verschicken muss. Alles was SCC macht könnte man auch mit Putty machen, nur nicht so schön angenehm wie mit Alberts Tool. Wenn du die Endtaster in HW benutzt, schließt du diese an dein GRBL fähiges Controllerboard an und schon ist es immer GRBL das relevant ist. Albert hat seine Funktionen auch hinreichend dokumentiert (in der Software). Die Softlimits sind da noch ein ganz anderes Thema... Ich will dich nicht angehen, es ist aber nun mal so, dass die GRBL-Doku 80% der Fragen dieses Threads klären kann :P Gruß EGS
Andreas V. schrieb : > Ich versuche meine Endschalter jetzt mal über Optokoppler anzuschließen, > ich hatte da was im Netz gefunden. Mal sehen ob das besser funktioniert > als die Widerstand-Kondensator-Schaltung. Hallo Andreas, was genau funktioniert mit deinen Endschaltern nicht ? Ist es der erneute Alarm beim Zurückfahren der Achse ? Diese Schalter haben 2 Funktionen in grbl: a) Sicherheitsfunktion (Endanschläge) b) HOMING Alles was jetzt kommt, habe ich mit meinem mangelhaften Englisch so verstanden ( Bitte um Korrektur, wenn's falsch ist..) Beim Zurückfahren der Achsen aus den Endschaltern kommt der Alarm erneut weil bei der Sicherheitsfunktion der Endschalter JEDE Kontaktänderung zum Alarm führt !? Beim Homing kann sich grbl offensichtlich die Bewegungsrichtung merken und selbstständig wieder aus dem Endschalter herausfahren. ... Es steht nämlich geschrieben, das die Sicherheitsfunktion der Endschalter beim Homing deaktiviert ist (deshalb kein Notausschalter an Endschalter Pins ! Hoffentlich stimmt das jetzt...? Endschalter Verdrahtung ist hier: https://github.com/gnea/grbl/wiki/Wiring-Limit-Switches EGS schrieb : > Lest die Doku zu GRBL!!! und > Ich will dich nicht angehen, es ist aber..... Das ist jetzt nicht wirklich hilfreich, sehrwohl aber mal eine Übersetzung der Grbl Doku, ich würde mich drüber freuen! Viele Grüsse Herbert
@Harald Wo hast du deine Fräse her? Ist das die hier->https://de.aliexpress.com/item/200W-Three-axis-Ball-Screw-CNC-Router-Engraver-Engraving-Milling-Drilling-Cutting-Machine-CNC-3040-Z/32712744259.html?spm=2114.13010208.99999999.264.BidAjG Wie hast du die Joystick Steuerung eingebunden?
Hallo Richard, ich dachte, mit der Angabe des Namens "LCF-1" wäre alles erklärt... Der Hersteller des Bausatzes ist Reinhold Müller [http://county24.de/shop47/CNC-Fraesmaschinen/CNC-Fraesmaschine-Bausatz-LCF-1-A4.html], Google liefert den Link mit "LCF-1" als Suchbegriff gleich an oberster Stelle. Die Anbindung des Joystick ist momentan wie im Text auf meiner Homepage beschrieben gelöst, einfach über das Interface, das bei meinen Stepper-Treibern dabei war. Wie du das Interface findest, ist auf meiner Seite ebenfalls beschrieben. Wenn du weitere Fragen hast, die auf meiner Seite nicht beschrieben sind, einfach nochmal melden, aber ich möchte eigentlich Alberts Thread nicht für sowas kapern. Gruß, Harald
Christoph C. schrieb: > unter http://www.einfach-cnc.de/platinen_frasen.html findest > Du eine Beschreibung wie das mit einem Plugin für > Eagle einfach generiert werden kann. Welches G-code Style soll ich fürs Bohren/Fräsen mit GRBL nehmen? @Harald Danke. Ich werde mir deine Seite nochmal durchlesen. Es sind mittlerweile über 1150 Einträge. Da wird man von Informationen fast schon erschlagen...
Richard B. schrieb: > Es sind mittlerweile über 1150 Einträge. Da wird man von > Informationen fast schon erschlagen... Joh, der Thread ist länglich und ich finde hin und wieder auch Beiträge nicht mehr, von denen ich weiß, dass ich sie selbst irgendwann geschrieben habe (weil ich den genauen Wortlaut zum Suchen nicht mehr kenne :( Mit ein Grund, Fragen nach bestimmten Teilen einer speziellen Lösung nicht hier zu diskutieren. Gruß, Harald
Hallo Harald, Schick uns doch nochmal den Link auf deine Homepage. Viele Grüße Sven
[Www.Harald-Sattler.de] oder über [Stler.de]
Hallo Herbert Das Problem mit den Endschaltern war, dass ich egal ob ich Reset oder Alarm Reset gedrückt habe, immer wieder error 9 bekam. Wie ich schon schrieb habe ich die Nachricht überlesen, die beim Auffahren auf einen Endschalter kommt, nämlich das man noch ein $X für z.B. die X-Achse an GRBL schicken muß, um diese wieder zu "entsperren". Das Problem ist damit glücklicher Weise behoben. >Das ist jetzt nicht wirklich hilfreich, sehrwohl aber mal eine >Übersetzung der Grbl Doku, ich würde mich drüber freuen! Da kann ich nur zustimmen! MfG computerpap
EGS schrieb: > Wer kein Englisch kann, ich übersetz dass auch gerne mal ;-) > > MfG EGS Dann freuen wir uns alle mal auf deine Übersetzung!!
Hallo Albert, erst einmal tolles Programm, doch einige Fragen habe ich dazu. und zwar woran könnte es Liegen das ich Trotz druck auf "$$" keine Grbl Einstellungen angezeigt bekomme? meine grbl verion ist die aktuellste "1.1f" und benutze einen Arduino nano so wie die Aktuellste Version von SCC. mit einer vorgänger version von SCC und GRBL hat es super funktioniert, aber nach dem update gestern nachdem ich für mein neues projekt grbl 1.1f aufgespielt habe geht das nicht mehr.
Setze bitte $10=0, danach sollte es funktionieren. Wurde weiter oben schon mal beschrieben...
hallo und guten Tag, ich wollte "SerialComCNC" ausprobieren, war aber nichts. was herauskam :siehe unten. Das Verfahren der 3 Achsen in positiver Richtung funktioniert, in negativer Richtung-unabhaenging von der Achse-funktioniert nicht. Die Status Anzeige bleibt auf Idle und die Anzeige der Achsen springt auf irgendwelche zufaellige Werte. Spielwiese: Windows 7 32 bit, Arduino UNO ,GRBL 1.1f und 1.1e. Hier die Ausgabe des Monitor-Fensters: ok G91 G1 Y8 ok G91 G1 Y-8 ok ALARM:3 G92 X0 Y0 Z0 Grbl 1.1e ['$' for help] [MSG:'$H'|'$X' to unlock] G92 X0 Y0 Z0 Grbl 1.1e ['$' for help] [MSG:'$H'|'$X' to unlock] error:9 error:9 Fuer einen erhellenden Hinweis waere ich dankbar. Gruss Klaus
Hallo Klaus, hast du den GRBL-Parameter $10=0 eingestellt? error 9 bedeutet "G-code lock G-code commands are locked out during alarm or jog state." Irgend etwas an deiner Fräse setzt GRBL in den ALARM-Zustand? Könnte also sein, dass du Limit-Schalter eingebaut und enabled hast, diese aber nicht auf OPERATE stehen, sprich, die Schalter melden GRBL, dass die Fräse irgendwo auf Anschlag gelaufen ist. Falls das der Fall ist, kannst du die Polarität der Schalter invertieren. Das geht mit dem GRBL Parameter 5. Gruß, Harald
hallo Harald, vielen Dank fuer Deine schnelle Antwort.$10=0 ist gesetzt.Das Teil funktioniert ja, nur nicht richtig.Die Fraese mit irgendwelchen Limits kann es auch nicht sein, die ist abgehaengt.Ich nehme doch an dass dies keine Rolle spielt?,oder doch?. In der Zwischenzeit habe ich das Ganze mit dem UniversalGcodeSender-musste dafuer Java installieren-probiert.Das Ergebnis ist identisch,d.h. Fehler bei Verfahren der Achsen in negativer Richtung. Damit scheidet fuer mich die Anwendung,egal welche, als Ursache aus.Hier klemmt es zwischen Hardware und Firmware.und damit glaube ich bin ich im falschen Forum. Danke nochmal und Gruss Klaus
hallo, Ergänzung zu meinem vorigen Post: Nach Wechsel auf einen anderen UNO(musste ihn erst aus einem Geraet ausbauen)funktionierte alles bestens.Ein gwisses Unbehagen bleibt allerdings weil letztlich die Ursache fuer das Nichtfunktioniern unbekannt bleibt.Sei's drum. Jedenfalls konnte ich, was ich urspruenglich vorhatte, die Software testen, und ich muss sagen ein gelungenes Stueck Arbeit, Dank dafuer. Gruss Klaus
Hallo Cnc Freunde, bin Rentner, habe mir eine Cnc Fräse (Maxyposi) gebaut. Auf der Suche nach einer Software bin auf dieses Forum gestoßen. Daraufhin habe ich diese Programm SerialComCNC auf meine Laptop eingerichtet. Nachdem ich $10=0 eingegeben habe wollte ich den 1. Versuch starten. Manuell die einzelnen Achsen starten. Leider brachte er den Fehler Error 22. Mein Betriebssystem ist Windows 7 Ultimate, Arduino Uno mit Cnc-Shield und 3 A4988 Treiber mit 3 Nema 17 Motoren. Der Versuch eine passende Datei einzufügen ging, aber Ausführung ging auch nicht das Programm hat deinen einen Restart gemacht ( Serialport wurde wieder geladen) Wer gibt mir etwas Hilfestellung, weil ich nicht mehr weiter weis. Gruß Fritz
GRBL kennt deine Feedrate nicht. Drück mal auf der rechten Seite auf "Set Feed". Danach solltest du die Achsen steuern können. Gruß Detlef
Hallo Detlef, erst einmal vielen Dank für die schnelle Antwort. Den set Feed habe ich gedrückt was er mit F100 und ok bestätigt hat. Wenn ich dann auf manuell gehe bestätigt er mir mit G91 G1 Y0 und ok, aber es passiert nichts. auch x oder z das gleiche. Manuell über die Eingabe geht alles. Was nun?
Ich noch einmal, Habe gerade festgestellt das bei Move mm 0,00 eingestellt war. Das bedeutet es geht jetzt. Aber wenn ich eine Datei hochlade und Start file drücke bricht er ab und startet neu.
Hallo Fritz, möglicher Weise hast du das Problem mit der prellenden Maustaste. Das wurde hier im Forum schon mehrfach thematisiert. Das Tasten-Control, das Albert verwendet hat, ist ein Toggle-Control, das heißt, wenn das Control zweimal bedient wird, schaltet es ein und sofort wieder aus. Wenn ich ihn richtig verstanden habe, versucht er (Albert), das Control durch ein Solches mit besserem Verhalten zu ersetzen. Oder das Ganze hat bei dir einen anderen Grund... Testweise könntest du z.B. mal eine andere Maus anschließen, oder die linke Maustaste für den Programmstart sehr beherzt betätigen (feste druff). Das hilft bei mir meistens, das Prellen zu unterdrücken. Gruß, Harald
Hallo Harald, Erst einmal vielen Dank für die Antwort. ich habe noch eine andere Maus die ich genommen habe. Geht leider auch nicht. Nur noch einmal zur Kontrolle ich meine wenn ich eine Datei reinlade und Sie ausführen möchte bringt er diese Information wie schon beschrieben. Die Set feet Taste muss immer drücken wenn ich was laden will. Gruß Fritz
Hallo Fritz, hmm, wie sieht denn deine Datei aus? Ich erstelle meinen G-Code mit Estlcam, da werden die Feedrate(s) und die Drehzahl(en) für den Fräser schon mitgegeben, die stehen als Fxxx und Sxxx Werte in der Datei drin. Weiterhin wird das Bezugssystem angegeben sowie absolute oder relative Koordinaten eingestellt (G21, G90, G94). Hier bin ich aber kein Profi, das kann eventuell jemand anderes besser erklären (wahrscheinlich Jeder ;-) Die ganzen Voreinstellungen damit GRBL dein Fräse kennt, hast du eingestellt (Steps/Umdrehung, max Speed auf den verschiedenen Achsen, und was der Dinge mehr sind)? Die Werte, die GRBL kennt kannst du mit $$ abrufen. Da die Ausgaben (Antworten) von GRBL seit dem Umstieg auf V1.x nicht mehr sprechend sind (Platzbedarf im ROM des µC), musst du dir auf der GRBL-Seite erlesen, welcher Wert was bedeutet. -> [[https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration]]. Wichtig: auf jeden Fall $100..102, $110..112 und $120..122, wenn deine Fräse eine variable SPindel-Drehzahl hat auch $30, $31. Ist der G-Code fehlerfrei? Das kannst du testen, indem du vor "Start" den Button "Test Code" drückst. Dabei wird der komplette Code, zeilenweise wie immer, an GRBL übergeben und GRBL checkt, ob es mit allen Befehlen etwas anfangen kann. Die ganzen Buttons im Bereich "Manueller Prozess" und "Set" haben mit der Abarbeitung einer G-Code-Datei nichts zu tun, die kannst du in diesem Fall ignorieren (wenn deine Fräse zum Zeitpunkt des Starts schon auf dem Nullpunkt deines Werkstücks positioniert ist. Ist das nicht der Fall, musst du natürlich das Voodoo um das manuelle Positionieren herum durchziehen und anschließend X, Y, und Z auf Null setzen). Gruß, Harald
Hallo Harald, Ich wollte erst einmal einen Test machen. Der Schriftzug wurde mit Estlcam erstellt. Habe ich evtl. da einen Fehler gemacht? Im Moment kann ich meinen Schriftzug nicht mehr nachvollziehen. Müsste noch einmal einen erstellen. Was muss ich beachten? Gruß Fritz
Hallo Fritz, also in Estlcam kannst du auf jeden Fall mal dein Projekt speichern, so dass du ggf. später Änderungen vornehmen kannst und nicht alles neu anlegen musst. Das hilft dir jetzt wahrscheinlich nicht weiter, aber sicher beim nächsten Mal. Das prinzipielle Vorgehen vom ersten Schritt im Designprozess bis zur fertigen G-Code-Datei sollten wir nicht hier in Alberts SCC-Thread breit treten. Christian Knüll (Autor von Estlcam) hat dazu ausführliche Tutorials erstellt. Vielleicht erst mal ein einfacheres Gebilde als einen Schriftzug für den Einstieg verwenden: Rechteck, Kreis? Dann wird auch der erzeugte (und in SCC angezeigte) G-Code übersichtlicher und man kann ihn verstehen. Dazu musst du allerdings ein Design-Programm vorschalten. Ich verwende die von RS elektronik gestellte Freeware DesignSpark mechanical (gegen kostenfreie Registrierung). Gruß, Harald
Hallo Kann es sein das bei der umwandlung von Excellon zu g-code ein Fehler drin ist? Es müsste doch ein minus Zeichen in der Zeile stehen. Bohrer auf Werkstück nullen. Ich stelle ein 4mm Sicherheitshöhe 2mm Tiefe Bei Programmstart fährt die Achse 4mm hoch ,und bohrt dann frei in der Luft herum. Gruss Marco
Marco schrieb: > Hallo > > Kann es sein das bei der umwandlung von Excellon zu g-code ein Fehler > drin ist? > Es müsste doch ein minus Zeichen in der Zeile stehen. > > Bohrer auf Werkstück nullen. > Ich stelle ein 4mm Sicherheitshöhe 2mm Tiefe > > Bei Programmstart fährt die Achse 4mm hoch ,und bohrt dann frei > in der Luft herum. > > Gruss Marco Hallo Marco, definitiv ein Fehler, aber nicht im Programm. Wenn du in der Tiefe zustellen willst, musst du ins minus gehen. Vorgehensweise bei den meisten CAM-Softwares: -Werkstück definieren (Maße XYZ) -Nullpunktfestlegen -Objekt erstellen -Sicherheitshöhe festlegen (deine 4 mm), hier ist die Höhe über Z 0 gemeint in der keine Hindernisse zu erwarten sind. Die Fräse verfährt in dieser Höhe zu neune Koordinaten. Z 0 ist entweder die Werkstück-Oberfläche oder dein Frästisch. -Zustellung der Bearbeitungen in Z-Richtung festlegen. Wenn Z 0 gleich Werkstückoberfläche, dann alles negative Werte. Ist dein Frästisch die Eben Z 0 dann musst die höhe verringert werden. -Maschinencode ausgeben Sollte hier es immer noch vorkommen, dass die Fräse "Luft bearbeitet", fährt die Z-Achse verkehrt herum. Dann muss die Z-Achse entweder umgestellt werden oder der Motor anders angeschlossen werden. Ob die generell richtig arbeitet erst einmal im manuellen Verfahrmodus testen. MFG EGS
Grad nochmal gelesen...du meinst den Excellon import von SCC. Ich sollte erst nach dem Frühstück schreiben :\
Hallo EGS Meine Daten kommen von SprintLayout6. Mit HPGL bzw PLT Datein geht es. Auch mit den gcode Generator von burger-web.com klappt es. Es ist also definitiv ein Fehler von SCC . Gruss Marco
Angehängte Dateien:
-
Excelon.jpg
120 KB
so geht es.:-) bei Excelon Bohrtiefe negativ - angeben! Bei HPGL positiv + angeben! Gruß Wolfgang
Hallo Wolfgang Das habe ich schon Versucht. Es geht einfach nicht ins Minus , bei null ist Ende. Gruss Marco
Marco schrieb: > Es geht einfach nicht ins Minus , bei null ist Ende. benutze die Pfeile vom Eingabefeld der Bohrtiefe (up/down) Gruß Wolfgang
Wolfgang B. schrieb: > benutze die Pfeile vom Eingabefeld der Bohrtiefe (up/down) Habe ich gemacht bei null ist schluss. Auch das anklicken mit der Maus und eingabe von minus kommt kein minus. Gruss Marco
Marco schrieb: > Habe ich gemacht bei null ist schluss. > Auch das anklicken mit der Maus und eingabe von minus kommt kein minus. das kann nicht sein. ist deine Maus defekt? ggf. das Programm noch mal neu installieren. Gruß Wolfgang
Habe mit CCleaner aufgeräumt. SCC neu installiert. Nichts - geht immer noch nicht. Maus funktioniert. Gruss Marco
Marco schrieb: > Nichts - geht immer noch nicht. muss eigentlich gehen.:-( keine Ahnung was mit dein System los ist. Gruß Wolfgang
Wolfgang B. schrieb: > keine Ahnung was mit dein System los ist. Habe es noch auf einen anderen Rechner mit Win7 probiert, auch nichts . Hast du denn bei dir die Probe installiert? ich habe es nicht , könnte daran liegen.
DA FLIEGT MIR DOCH DIE SICHERUNG RAUS......... Version 2.5.1 hat denn Fehler - die alte Version 2.5 funktioniert :-) Werde Albert mal eine email schicken und auf den Fehler hinweisen. Danke dir Wolfgang Gruss Marco
Marco schrieb: > Hast du denn bei dir die Probe installiert? Was für eine Probe? >Version 2.5.1 hat denn Fehler... In der Tat, ich habe auf mein Testrechner sogar nur Version 2.1 :-( Gruß Wolfgang
Wolfgang B. schrieb: > Was für eine Probe? Probe ist die Werkzeuglängenmessung. Taste neben $$ oder über Einstellung Probe
Marco schrieb: > Hast du denn bei dir die Probe installiert? ich habe es nicht Marco schrieb: > Wolfgang B. schrieb: >> Was für eine Probe? > > Probe ist die Werkzeuglängenmessung. > > Taste neben $$ oder über Einstellung Probe Das ist eine Funktion von SCC was soll da installiert oder nicht installiert werden? Du meinst sicherlich die Einstellung? Gruß Wolfgang
Angehängte Dateien:
-
IMG_0857.JPG
240 KB
Hallo, ich wollte meinen Fräsenaufbau mit einer Proxon MF 70 CNC zeigen und eine Erfahrung weitergeben. Meine Proxxon hat nach einem Defekt des Orginalmotors und und der Platine einen Brushless-Motor aus des Helikoptermodellbau der über einen Regler durch einen Servotester gesteuert wird erhalten. Die Stromversorgung erfolgt über ein umgebautes PC Netzteil. Wichtig ist, dass der verwendete Regler den Governor-Mode unterstützt das ist das Hochdrehen des Motors aus dem Stand. Wie Ihr auf dem Bild seht habe ich die komplette Installation mit den Steuerungsplatinen für den Schrittmotor und dem Arduino-Board halbseitig in eine Holzbox eingebaut auf der die Fräse auf der anderen Seite oben befestigt wurde. Unter der Fräse ist eine Schublade für die benötigten Zubehörteile. Die benötigten Versorgungskabel habe ich mit diversen Steckern und Durchführungen aus dem unteren Installationsbereich heraus verbunden Die Stromversorgung erfolgt über den Kaltgerätestecker, die Verteilung für PC-Netzteil, Laptop-Netzteil und Schaltnetzteil ist in der grauen Verteilerdose untergebracht Auch ich hatte bei der ersten Inbetriebnahme erhebliche Probleme mit der Kommunikation des Arduino-Boards und des PCs. Alle Tipps mit abgeschirmten Kabeln etc. brachten keinen Erfolg. Erst nachdem ich das Board gegen ein neues getauscht hatte lief alles problemlos und funktioniert sogar mit dem einfachsten Kabelmaterial und USB-Steckverbindungen. Das Nextion Display habe ich über ein FT232RL 3.3V 5.5V FTDI USB zu TTL Serial Adapter Modul Arduino TE203 verbunden weil auch der USB zu TTL RS232 5V PL2303 HX Adapter Kabel Seriell Konverter Modul für Arduino unter Windows 10 bei mir nicht kommuniziert was anscheinend mit dem Chip zusammenhängt. Viele Grüße Michael
Beitrag #5071925 wurde von einem Moderator gelöscht.
Hallo, wollte mitteilen, wie ich die Videofunktion bei mir zum Laufen gebracht habe. Betriebssystem Windows 10, 4 verschiedene USB-WebCams und die festverbaute Camera im Notebookdeckel haben NICHT funktioniert. Meine Idee war jetzt, die Webcam (mein Favorit ist https://de.aliexpress.com/item/Mini-USB-30M-Mega-Pixel-Webcam-Video-Camera-Web-Cam-For-PC-Laptop-Notebook-Clip-Worldwide/32640706064.html?spm=2114.13010608.0.0.pQYYx6 ) mit dem kostenfreien VLC-Mediaplayer (Medien,Aufnahmegerät öffnen) zum Laufen zu bringen, unter Werkzeuge, Effekte und Filter, Videoeffekte, Overlay, Text hinzufügen (zentriert) "X" als Markierung und den Versatz als Makro in SerialCom zu speichern. Das funktioniert auch, jetzt aber die Überrasschung: Wenn jetzt in SerialCom die Videofunktion geöffnet wird, funktioniert dieses und es kommt ein grünes Bild. Wenn jetzt noch VLC geschlossen wird, ist das Vidobild in Serialcom zu sehen. Klingt komplizierter als es ist . . . Die o.g. Webcam kostet weniger als 3 Euro und hat einen manuellen Fokus der sich z.B. auf drei Zentimeter Abstand einstellen lässt! Viel Erfolg
Uwe R. schrieb: > die Webcam mein Favorit ist Eine schlechtere Kamera hättest du nicht finden können? Für ~35 EUR bekommst du gescheite Kameras samt Linse von ELP.
Hi. Ich bin auch noch cnc Neuling und nach unterschiedlichen grbl Programmen (inklusive dem meiner China cnc2418) bin ich auf serialcomcnc gestoßen. Sieht echt Klasse aus! Der manuelle Mode funktioniert bei mir einwandfrei nachdem ich gemerkt hatte, das die feedrate erst mal setzen muss. Das war in anderen Programmen nicht so. Egal, ich schreibe hier, weil ich mit dem Ausführen von g-code Schwierigkeiten habe. Ich nutze cambam oder fengrave, bei cambam gcode stoppt serialcomcnc bei der ersten Zeile und steht auf busy, nichts passiert mehr. Ich hatte auch schon mal Kommentar Zeilen gelöscht, ohne Erfolg. Kann mir jemand den Fehler zwischen meinen Ohren erklären? Ich nutze übrigens v2.5.1, ich glaube aktuell latest. Danke und Respekt an den Programmierer!
Guten Tag, ich habe SerialComCNC installiert und meine Proxxon Fräse bewegt sich auch. Leider sind die zurückgelegten Strecken in allen Achsen viel kürzer als eingegeben. Nicht um einen festen Faktor, z.B. 1/10, sondern um völlig "krumme" Werte. Wie kann ich das lösen? Vielen Dank Peter Uk.
Den GRBL Konfigurieren und an deine Fräse anpassen Gruß Waldemar
Peter Uk. schrieb: > ich habe SerialComCNC installiert und meine Proxxon Fräse bewegt sich > auch. Leider sind die zurückgelegten Strecken in allen Achsen viel > kürzer als eingegeben. Nicht um einen festen Faktor, z.B. 1/10, sondern > um völlig "krumme" Werte. > Wie kann ich das lösen? SerialComCNC Manual lesen unter "GRBL konfigurieren"
Bei drücken von $$ sieht man die eingestellten Parameter. $100, $101 und $102 müssen auf 3200 stehen. 1,8° Grad pro Schritt, 16 Teilschritte (Einstellung auf Stepperansteuerung) und 1mm pro Umdrehung des Motors bei 6mm Gewinde: 1,8/16*3200=1xUmdrehung des Motors. Also unten rechts im Eingabefeld einmalig $100=3200 usw. eingeben. Viel Erfolg.
Hallo, ich wollte das Programm auch nutzen in verbindung mit meiner umgebauten Proxxon mf70, einem Arduino Uno und CNC Shield. Leider bekomme ich nach ca. 1 min. probleme mit der Verbindung zum Arduino, soll heißen es bricht ab. Mit HTerm keinerlei problem. Wäre für jeden Tip dankbar...
Moinsen, ich habe exakt das gleiche Problem. Die ältere Version (0.9f) funktioniert bei mir. Mit einem Arduino Nano bekomme ich keine Verbindungsfehler mehr, allerdings funktioniert die (manuelle) Steuerung auch nicht (X,Y,Z Werte stimmen in der Anzeige auch nicht). Ich werde das ganze nächste Woche mal mit einem Laptop ausprobieren, auf dem Windows 7 läuft). Z.zt. verwende ich die Arduino Schnittstelle aus Estlcam direkt. Das funktioniert ebenfalls sehr gut. Vielleicht kann Albert ein Debug Binary zur Verfügung stellen um den Fehler zu analysieren (sofern er dafür Zeit hat - Respekt und Dank für die ganze Arbeit die er sich bis jetzt gemacht hat). VG Tommy
Tommy schrieb: > allerdings funktioniert die (manuelle) Steuerung > auch nicht (X,Y,Z Werte stimmen in der Anzeige auch nicht) ewt. solltest Du dir mal deine GRBL Einstellungen anschauen. $100 bis $102 und $10 Gruß Wolfgang
Hallo Wolfgang, 100 - 102 sollten richtig sein. Trotztdem bricht die Verbindung mit einem Arduino Uno mit einem Verbindungsfehler nach kurzer Zeit ab. Version 0.9f funktioniert mit den ghleichen Grbl-Einstellungen. Ich werde mal nach einmal untersuchen. Danke und VG
Tommy schrieb: > Trotztdem bricht die > Verbindung mit einem Arduino Uno mit einem Verbindungsfehler nach kurzer > Zeit ab Hallo Tommy. die Einstellungen $100 bis $102 und $10 sind für die X,Y,Z Werte und Anzeige wichtig und verursachen nicht Verbindungsfehler. SCC >= 2.1 benötigt GRBL ab 1.1e und $10 Status report, mask = 0 Wie oder wann tritt den der Verbindungsfehler nach kurzer Zeit auf? Ich benutze auch ein Arduino Uno und habe keine Probleme mit Verbindungsfehler auch bei Stundenlangen jobs. Es gibt ein Problem bei SCC mit den Startboton wenn die Maustasten Prellen.:-( Gruß Wolfgang
Hallo Wolfgang, GRBL läuft in der Version 1.1e. Ich prüfe später mal die Config und teste das noch einmal mit dem Uno und dem Nano (der hat zumindest keine Verbindungsabbrüche an der seriellen Schnittstelle). Vielleicht ist es auch ein Problem mit Win10/64Bit. Danke schon einmal und VG Tommy
Hallo Tommy, ich mische mich kurz ein... Prinzipiell gibt es keine Probleme mit Win10/64 bit, mein Fräsenrechner läuft damit seit Anfang prima. Das System ist voll gepatcht (alle MS Updates werden eingespielt, wenn ich den Rechner hin und wieder einschalte). Zuerst mit SCC V1.x und GRBL 0.9x, seit Ulrich umgestellt hat mit SCC V2.5 und GRBL 1.1x. Mein Controller ist ein Nano V3.0 Nachbau. Gruß, Harald
Ob Uno, Nano, Nachbau oder Orginal es ist alles der gleiche Mikrocontroler. Der Unterschied ist der USB/RS232-TTL Chip auf den Dingern. Ich würde bei Probleme bzw Verbindungsabbrüche etc bei der USB Treiber Software suchen. Gruß Wolfgang
Sehe ich auch so. Es geht verschiedentlich die Rede, dass USB-Controller des Typs CH340 etwas liederlicher arbeiten als die guten alten FTI-Chips. Das kann ich so nicht unterschreiben, denn ich verwende gezielt ausschließlich die CH340-Versionen und habe keine Probleme damit. Der Grund für diese meine Vorliebe ist die Tatsache, dass in meinem Rechner die Nanos mit FT232 zwar funktionierten wenn man den Arduino nach Hochfahren des Rechners an den USB angesteckt hat, dass die Kommunikation aber nicht zustande kommt, wenn der USB-Anschluss des Arduino beim Einschalten des Rechners bereits eingesteckt war. Da ich den GRBL-Arduino im Innern des Rechners an einen OnBoard-USB-Port angeschlossen habe, war das nachträgliche Anstecken natürlich keine Option. Der Test mit Arduinos mit CH340 Chip ergab: Läuft immer :-) Nachtrag: Der CH340-Chip benötigt einen anderen Treiber als der FT232. Gruß, Harald
Ja so sind die Erfahrungen verschieden. bei mir laufen unter Windows beide Chips problemlos. Unter MacOs bringt der CH340 Chip beim einstecken die gesammte USB Schnittstelle zum Absturz nur wenn der Chip beim Einschalten des Rechners bereits eingesteckt war klapps. Ein eindeutiges Treiber Problem.:-( Gruß Wolfgang
Moinsen, $10=0 !!!! das wars. Beim Uno stand es nach dem flashen auf 1 und beim Nano auf 3??? Jetzt läuft es auch mit der aktuellen Version! Vielen lieben Dank!!!! VG Tommy
Stromchaos schrieb: > Hallo, ich wollte das Programm auch nutzen in verbindung mit meiner > umgebauten Proxxon mf70, einem Arduino Uno und CNC Shield. Leider > bekomme ich nach ca. 1 min. probleme mit der Verbindung zum Arduino, > soll heißen es bricht ab. Mit HTerm keinerlei problem. Wäre für jeden > Tip dankbar... Schau mal nach $10 (sollte den Wert 0 haben). Viel Erfolg.
Hallo zusammen, bin Anfänger und sitze schon seit zwei Tagen ohne Erfolg vor meiner neuen Fräse. Sie hat ein Board(Woodpecker 2.6), das über USB angesteuert wird. Nach der Installation des Treibers CH340 läuft nur GBRControl einwandfrei, nicht aber SerialComCNC v. 2.5 von Albert Maassen! Port und Übertragungsrate sind korrekt. Kurz nach dem connect kommt die Fehlermeldung: "Falscher Port oder noch nicht erkannt" Sie zeigt sich auch, wenn ich ein Arduino UNO mit GRBL-Controller(hex-file zuvor geflasht) anschließe und unter SerialComCNC betreiben möchte. Aber der Arduino läuft mit dem Treiber für TTY!? Er funktioniert auch direkt mit einem ESP8266 als USB-TTL-Converter, sodass ich vermute, dass es nicht am Treiber liegt.Er läuft ja einwandfrei mit WIN10 bei anderen Anwendungen. Ich kriege es einfach nicht hin, das Programm SerialComCNC unter WIN10 zu aktivieren. Es meldet den Fehler nach 3 Sekunden. Hat jemand eine ähnliche Erfahrung und kann helfen? Bernd
Angehängte Dateien:
-
IMG_1638_1_.JPG
220 KB -
IMG_1637_1_.JPG
230 KB
Hallo an alle, habe dieses Programm jetzt erst gefunden und natürlich möchte ich es doch gleich testen. Ich habe das Arduino/Uno und das CNC Shield v.3 das CNC Shield habe ich an ein Netzteil angeschlossen. Ein Motor ans Shield und wollte diesen testen. Leider sagt das Programm immer "error:22" wenn ich den Motor bewegen möchte. Eingestellt ist alles nach Anleitung. Weiss jemand mit dem Fehler was anzufangen - gibt es eine Fehlerliste? Gruß Jörg
Hi Marco, da komm ich irgendwie nicht weiter. Ich habe das original HEX.File aufgespielt die bei der Software dabei war. Gruß Jörg
Hollo, der erste Motor bewegt sich: Man muss halt das lesen was am Anfang im Bildschirm erscheint: setze Vorschub - das war es. MfG
Hallo, Ich habe noch Probleme mit den Einstellungen. Mein Nema17 Motor 17hs19-2004s1 hat im Stillstand null Haltemoment. Im Einsatz ist de CNC-Shield 3 und der A4988 und der DRV 8825. Wie müssen denn die Einstellungen aussehen und wie stelle ich den Motorstrom ein? Mein Netzteil ist ein 24V Schaltnetzteil. Kann einer seine Einstellungen verraten der die gleiche Konfiguration hat? Die Feineinstellungen würde ich später machen, Hauptsache es läuft erst einmal richtig. Über eine Antwort würde ich mich sehr freuen. Gruß Jörg
Jörg schrieb: > Hallo, > Ich habe noch Probleme mit den Einstellungen. > Mein Nema17 Motor 17hs19-2004s1 hat im Stillstand null Haltemoment. Im > Einsatz ist de CNC-Shield 3 und der A4988 und der DRV 8825. Wie müssen > denn die Einstellungen aussehen und wie stelle ich den Motorstrom ein? Hallo Jörg, Der Parameter "$1 = 255" bewirkt, dass die Motoren dauerhaft bestromt sind. Ansonsten werden diese nach 25ms abgeschaltet. Dann haben die Stepper keinen Haltemoment... Wenn du dies verwenden willst, musst du deine Treiber (die A4988) aktiv kühlen. Die müssen dann nämlich den maximalen Motorstrom dauerhaft liefern. Wie der Motorstrom an den A4988 eingestellt wird steht im Datenblatt. Das solltest du selber lesen. suche mal nach "A4988 Setting current". Ist bei den DRV8825 der gleiche Weg. Ohne Datenblatt zu den Steppern kann übrig keiner was zu denen sagen, es gibt zigg verschieden Stepper als Nema17. Nema17 bezeichnet nur die Bauform. Schau einfach nen paar Beiträge weiter oben, da sind die passenden Links schon vorhanden. Bei diesem Thema kann man nix vorkauen. Sonst wirst du nie richtige eigene Arbeiten mit der CNC machen. Gruß EGS
Hallo EGS, super - hat geklappt. Wo bekommt man denn die Einstellmöglichkeiten her?? Eine Liste , was welcher wert bedeutet, habe ich schon gesehen - aber eben nicht welche Werte dann was bedeuten. Gruß Jörg
Hallo Jörg, Bei der Plattform im Netz für GRBL sind die ganzen Parameter erlöst erläutert. Auch wird dazu ein Beispiel und die mögliche Verwendung erklärt. Hier findest du weitere Infos: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Configuration Gruß EGS
Hi, Oh weh - ENGLISCH Trotzdem Dankeschön , es gibt ja Übersetzer. Ich habe zwar noch lange nicht meine Fräse fertig aber ich benötige noch Infos zum Anschluss von einem Lasermodul wie dieses ( eBay-Artikelnummer:152336816828 ) Ich möchte später Platinen Fräsen und Lasern können. Hat das schon einer mit dieser Software gemacht und kann ein paar erklärende Worte dazu sagen? Ich möchte mich auch erst einmal bei allen recht herzlich für die Hilfe bedanken. Gruß Jörg
Hallo, hier auch ein Jörg, aber ein anderer ;-) Vorab: ich bin Neuling der CNC-Szene, bitte daher um Verständnis, falls ich mich dämlich anstellen sollte. Ich habe gestern meine MF 70 CNC-ready gemacht. Arduino ONE mit beigefügter hex geflashed und mit einem Terminal (putty) war ich auch in der Lage den Moter zu bewegen: G91 G1 X1. So weit so gut. Wenn ich nun mit SerialComCNC gegen den Arduino verbinde funktioniert das auch (zumindest alles grün und keine Fehlermeldung) aber alle Befehle via "Manuelle G-Code Eingabe" bleiben unbestätigt (kein"ok") und drehen tut sich auch nichts. Auch ein "$$" liefert nichts --> auch das funktioniert im Terminal. Irgendwelche Ideen? "$0=10" habe ich im Terminal gesetzt und wurde mit "ok" bestätigt. Bevor es im Terminal funktioniert hat musste ich noch einen Feed bestimmen: G1 F100.0. Herzlichen Dank & Gruß, Jörg Meine Komponenten: MF 70 TB6560 (driver Boards) Arduino Uno grbl_v1.1f.20170131.hex Nema 17 2,5A Schrittmotoren
Nochmal Jörg_2, also jetzt bekomme ich es hin, dass sich die Schrittmotoren ansprechen lassen. Der Trick: auch im Tool musste ich zunächst das Feed setzen. Ich bekomme aber leider weiterhin keine Rückgabewerte (also "ok" oder eben "error") angezeigt. Das hätte mir beim ersten Problem vermutlich viel Zeit gespart ;-) Ideen woran das liegen könnte? Danke & Gruß, Jörg
Jörg A. schrieb: > "$0=10" habe ich im Terminal gesetzt und wurde mit "ok" bestätigt. $10=0 wäre richtig. Solange $$ keine Antwort liefert (eine ganze Seite mit den $Einstellungen) ist etwas NICHT in Ordnung. Viel Erfolg
Hi! $$ liefert im Terminal die Liste der $Einstellung. Nur im SerialComCNC bekomme ich grundsätzlich keiner Rückmeldung. Steuerung funktioniert aber inzwischen wie gesagt. Gruß, Jörg
Hallo zusammen, Am Ende war es ganz einfach: SerielComCNC neu installiert und alles läuft wie es soll. Gruß, Jörg
Hallo, ich habe gerade ein ähnliches Problem. Mit einem Terminal Programm funktioniert $ und $$ perfekt. Aber unter SerialComCNC wird nichts angezeigt. $10=0 ist gesetzt! Mit dem Stift Plotter Programm hier von jemanden scheint es aber zulaufen. Hat jemand einen Tipp. VG, Klaus
Hier ein Tipp von mir. SerialComCNC kommt nicht mit geänderten GRBL Versionen zurecht. Da müsste der Programmierer mal nachlegen! Wenn man die "Variable Spindel" abschaltet gibt es ärger. Noch schlimmer ist es wenn man eine 4. Achse einbaut. Dann kommt als Status halt auch eine 4. Achse raus und unser lieber Albert M. hat eine Spielzeug Pseudoauswertung der Informationen eingebaut. Da geht dann überhaupt nichts mehr. Hier würde ich gerne eine optionale 4 Achse im Programm haben, aber das sage ich ja schon seit langem. Den Code für 4 Achsen werde ich die Tage mal hier abliefern. VG, Peter
Hallo Peter, über welchen Parameter wird die 4. Achse angesteuert - A? Ist es dann eine echte Drehachse, welche nach 360° wieder bei Null beginnt? Ich hatte ein wenig mit einer Drehachsensteuerung durch "axis substitution" rum gespielt, da stört es wenn der Schrittzähler ständig weiter hoch läuft... https://github.com/svenhb/GRBL-Plotter/wiki/Drehachse Gruß Sven
Da ich an der selben Steuerung auch meinen OpenPnP Bestücker betreiben will habe ich die C-Achse benutzt. Den Code muss ich denen dann auch zukommen lassen zum einbauen! Auf der Fräse habe ich einen Drehtisch, der ist aber noch nicht in betrieb. Da fehlt mir halt noch die 4. Achse hier im Program. Am Ende ist es nur eine Stelle wo auf C oder A geprüft wird. Die ist genauso wie die XYZ drin, das war so auch bei OpenPnP eingebaut. Ich kann aber mal nach sehen ob das auf 360° um zu biegen geht. Wenn JA :: bei 350->10 über 0 oder den langen weg? Ich denken das der lange weg richtiger ist. Damit das überhaupt arbeitet musste ich für den NANO aber einiges ändern: - Pin Belegung - Start/holt/Res sind raus (wegen Pin change int und Speicher) - Laser Mode ist raus (wegen Speicher) - Senden der Status Info der 4. Achse ist raus (leider) Ansonsten ist alles noch drin und geht.
> Wenn JA :: bei 350->10 über 0 oder den langen weg?
Gute Frage - ich hätte jetzt angenommen den kurzen Weg.
Die Änderung der Pin-Belegung ist natürlich heftig - betrifft es auch
step/dir für X,Y und Z?
Angehängte Dateien:
-
gbr_pin.png
97 KB
Der Lange weg ist der richtige ich kann ja auch nicht von X-200 auf X200 springen sondern muss die 400 abfahren. Na so schlimm ist das mit der Belegung nun auch wieder nicht. Die paar Leitungen! In der Tabelle ist mein Anschluss für eine Karte mit angegeben und kann ignoriert werden. VG, Peter
Peter schrieb: > Hier ein Tipp von mir. > > SerialComCNC kommt nicht mit geänderten GRBL Versionen zurecht. > Da müsste der Programmierer mal nachlegen! > > Wenn man die "Variable Spindel" abschaltet gibt es ärger. > > Noch schlimmer ist es wenn man eine 4. Achse einbaut. > Dann kommt als Status halt auch eine 4. Achse raus und unser lieber > Albert M. > hat eine Spielzeug Pseudoauswertung der Informationen eingebaut. Da geht > dann überhaupt nichts mehr. > Hier würde ich gerne eine optionale 4 Achse im Programm haben, aber das > sage ich ja schon seit langem. > > Den Code für 4 Achsen werde ich die Tage mal hier abliefern. > > VG, Peter Hallo Peter, die Diskussion wegen der 4. Achse brauchst du nicht wieder lostreten. Albert hatte gesagt, dass ER die 4. Achse nicht braucht und das Programm diese (vorerst) nicht unterstützen wird. Das ist seine Entscheidung. Es steht jedem drei wenn er diese benötigt sich auch damit auseinanderzusetzen. SerialCNC kommt mit der GRBL v1.1 klar, habe hier bisher nie Probleme gehabt. Wenn du deine Version anpasst, ist die Kompatibilität nicht mehr gegeben, liegt aber nicht an SerialCNC... Und immer dran denken Albrecht macht es als Freizeitprojekt. PS: GRBL ist nicht für eine 4. Achse ausgelegt. steht auch auf der Seite vom Entwickler(=!Albrecht)! Die ausgeführte A-Achse ist zum Ansteuern eines 2. Motors an der X/Z-Achse gedacht, damit ein Portal beidseitig angetrieben werden kann um ein verkanten/verwinden zu verhindern. Mit eigenen Anpassungen, so die Aussage der Entwickler kann hiermit eine 4. Achse angetrieben werden. Kann man hier nachlesen: https://github.com/gnea/grbl/wiki "Grbl is for three axis machines. No rotation axes (yet) – just X, Y, and Z." MFG EGS
UND was willst Du nun sagen? Klar hat Albert das gesagt, aber wenn man sich einfach sagt dann halt nicht dann wird so was auch nie kommen. Albert hat eine Fixe und damit schlechte Statusauswertung, da kann man sich jetzt streiten bis zum umfallen, es ist aber leider so. Ich arbeite selber an einigen Projekten für lau und da muss auch immer alles passen und alles mögliche abgefangen werden. Da sind die User um einiges härter drauf wie wie hier. Ich bin ja auch 1.1F kompatibel!
Hm, also auf: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Interface beschriebene Interaktionsmöglichkeiten sind in meinen Augen relativ statisch, da hier ja immer vorab definierte Daten übertragen werden. Peter schrieb: > Albert hat eine Fixe und damit schlechte Statusauswertung, da kann man > sich jetzt streiten bis zum umfallen, es ist aber leider so. Das ist halt ein vorgegebene "API" die er anspricht und die ihm antwortet. Eventuell sind dann GUI abhängige Funktionen zu statisch oder "schlecht", aber die Informationen aus der "API" sind für alle gleich. Sobald ich wieder Zeit habe werde ich mir dein Programm mal installieren und testen. Peter schrieb: > Ich arbeite selber an einigen Projekten für lau und da muss auch immer > alles passen und alles mögliche abgefangen werden. Da sind die User um > einiges härter drauf wie wie hier. Wenn du dich aber für dein "Für-lau_Projekte" triezen lässt, kann keiner was für, denn selbst da gibt es einen beschriebenen Leistungsumfang (Pflichtenheft) den nicht die Nutzer, die ein für den Entwickler selbst geschriebenes Programm nutzen, sondern der Entwickler selber. Wenn die Nutzer dann hier Fehler finden, werden diese behoben, wenn diese so gravierend sind, das Handlungsbedarf besteht., alles andere sind Sonderwünsche die bei Bedarf umgesetzt werden. Es wird niemand gezwungen SerialComCNC zu benutzen und auch keiner hat dafür bezahlt! Sonst gilt "u get what u pay 4", nix bezahlt, dann nicht fordern (darum geht es). MfG EGS
Es geht bei diesen Projekten logischerweise auch um Fehler, aber meistens mehr um wann kommt das endlich, wann verbessert ihr jenes. Geld verdienen tut damit keiner und wir stecken da locker einige hundert Stunden jedes Jahr rein. Das die API fest ist und auf die fixe Byteposition ausgewertet werden kann ist auf der einen Seite ja hübsch, aber wenn man es halt dann so macht stollpert man bei jeder Version in die Falle. Einmal sauber richtig gemacht und es ist egal welche Version und ob 1,2,3,4,5 oder 6 Werte kommen. Das ich auf Albert angewiesen bin ist halt leider so, wenn er nicht will dann muss ich halt auf eine andere Software ausweichen, da gibt dann wenigstes auch den Code und man kann da was ändern und das dann weiter bringen. Peter
Peter schrieb: > Das die API fest ist und auf die fixe Byteposition ausgewertet werden > kann ist auf der einen Seite ja hübsch, aber wenn man es halt dann so > macht stollpert man bei jeder Version in die Falle. Einmal sauber > richtig gemacht und es ist egal welche Version und ob 1,2,3,4,5 oder 6 > Werte kommen. Hallo Peter, wieso byteweise? Die Schnittstelle ist mit Start- und Stoppzeichen beschrieben, sowie Trennzeichen. Also hört man auf die serielle Schnittstelle und empfängt bis zum Stoppzeichen (Linefeed o.ä.). Dann nimmt man dass empfangene auseinander anhand der definierten Trennzeichen und ordnet dies anhand der Reihenfolge dem jeweiligen Soll-Inhalt zu. Dies stellt man nun dar und daran ist kein Problem zu finden. Wenn GRBL um Funktionen erweitert wird werden die "angehängt" an den Datensatz, der immer noch Trenne- und Stoppzeichen enthält. Das Problem ist es nicht die Werte zu empfangen, man muss sie darstellen können. Und hier ist der Knackpunkt. SerialComCNC stellt alles zum Zeitpunkt der Version 1.1 von GRBL empfangbare dar. Wenn aber die API erweitert/angepasst wird läuft man immer in die Falle. Denn woher sollst du vorher wissen was wann wo dazu kommt?!? Da kannst du noch so Flexibel sein mit der Auswertung, neue Formate und Inhalte kannst du nicht auswerten, da du ja nicht wissen kannst was sie bedeuten, man kann sie höchstens einfach ohne zusätzliche Information darstellen! Beispiel: alte Übertragung: Startzeichen(2000;33;$10=0;255;10010111)Stoppzeichen neue Übertragung: Startzeichen(2000;33;$10=0;255;10010111;4000;abrakadabra)Stopzeichen Jetzt zeigt mir die Software, die trotz flexibler Auswertung der Schnittstelle weiß, wofür "4000" und "Abrakadabra" stehen. 4000x Abrakadabra sagen, mit 4000x Zeichen/s das sagen oder $10 wird zu 4000 wenn das Zauberwort eingegeben wird? (geschweige denn von vorne rein weiß ob "4000h" oder "4000d" gemeint ist, oder isses BCD ;-) ) MFG EGS
Mal abgesehen davon das das so nicht aussieht, kann man auch einfach unbekanntes einlesen und dann verwerfen. Wenn etwas neues dazu kommt, also richtig was neues dann wird man immer wieder ran müssen. Aber man kann trotzdem kompatibel bleiben und bis zu einem gewissen Grad das neue ignorieren. Besonders wenn es einen erst mal nicht interessiert. Aber warum streiten wir uns hier eigentlich, Albert ist der Ansprechpartner und Er muss sagen was los ist. Wir können hier nur Bitte Bitte sagen und hoffen das er es macht. Wenn nicht, es gibt genug alternativen! Auch für mich!
Für alle die immer noch glauben das das einlesen richtig gemacht wird: Ich habe zufällig beim Testen die Ausgaben verhunst und nun bekomme ich als Speed nette Ascii Zeichen und zwar genau so wie ich die sende. Wird also als Fixe Position 1:1 als Text eingelesen. Das Text wird bei mir zwar nur kurz angezeigt aber ich kann ihn sehen. Albert hier wäre es wirklich gut wenn Du das beheben würdest. Die 4. Achse musst Du ja nicht einbauen, wenn DU nicht willst aber den Status solltest Du bitte überleben. VG, Peter
Hallo Peter, SerialCNC unterstützt immer die aktuelle/offizielle GRBL Version. Wenn du deine GRBL Version anpasst/änderst, ist das dein Problem und liegt nicht an SerialCNC... Die Diskussion ist unnötig. Gruß Wolfgang
Hallo Wolfgang, dein Kommentar ist aber auch unnötig, außerdem bringt es dem Programm nichts. Das Peter einen "Fehler" gefunden hat, der anscheinend durch eine mittelmäßige Implementierung einer Statusauswertung zustande kommt ist doch super. Da muss Albert ran, egal was hier jemand sagt! Das kann wie Peter schon sagte bei einem Zeichenverlust schnell böse enden. Vielleicht arbeiten darum auch gelegentlich NANO-Clones schlechter. Ich wünschte bei meinen Projekten würde jemand gelegentlich so was finden. Und den Mut haben es mir zusagen. Gruß Klaus
Peter hat zufällig beim Testen die Ausgaben verhunst. Das dann Alberts Statusauswertung damit nicht zurecht kommt ist meines Erachtens kein Fehler. Das Albert eine „Spielzeug“ Pseudoauswertung der Informationen eingebaut hat ist eine nicht angebrachte Kritik. Zu den NANO-Clones Ob Nachbau oder Orginal es ist alles der gleiche Mikrocontroller. Der Unterschied ist der USB/RS232-TTL Chip auf den Dingern. Ok bei einen NANO-Clone den ich hatte lag der 16MHz Resonator erheblich daneben. Gruß Wolfgang
Wollen wir uns doch mal alle beruhigen. Ich selber habe auch noch nie mit einem Clone probleme gehabt, nur ich lese das hier gelegentlich. Ob es daran liegt oder nicht, werden wir hier so nicht feststellen können. Ich KLAUS sage nur das Albert sich das mal ansehen sollte! Ich denke das Peter da was gefunden hat was zwar fast nie passieren wird, aber da hat Peter recht es wäre besser Albert würde diesen Teil überarbeiten. Ich habe mir mal den Status angesehen und finde das GRBL die ganzen Elemente super getrennt sendet. Die kann man perfekt einlesen und auch unsinnige Teile davon super verwerfen. Ob man mit einer Überarbeiteten Version dann alles und jede GRBL Version benutzen kann würde sich dann zeigen. Ich gebe nur den Tipp ändern, schaden kann es nicht. Grüsse, Klaus
So hier mal etwas Code eigentlich nur für Sven, die anderen haben ja sowieso kein Interesse. Peter
So hier ist was für Sven, die anderen haben ja sowieso kein Interesse. Peter
Einfach etwas hochladen ohne jegliche Erläuterung was Du ggf. daran geändert hast ist aber auch nicht gerade hilfreich, oder ? Auf dieser Basis kommt sicher keine gute und fruchtbare Zusammenarbeit zustande. Aber vielleicht ist das ja auch nicht gewollt? LG Avantasia
Eine zusammenarbeit ist zwar gewollt, nur hier wird ja alles immer ignoriert oder nieder gemacht. So weit ich das hier lesen kann hatte ich eigentlich alles wichtige schon gesagt. Ist die 1.1f mit eingebauter C_Achse und geändertem Pinning. Der Laser musste weichen wegen Speicher. Die Control Pins (Start/hold/reset) kann man abschalten (ist so drin weil ich die nicht brauche- gehen aber). Das wichtigste ist das ich die Reportfunktion kastriert habe um die C-Achse. Sonst geht mit SerialComCNC nichts mehr. Die OpenPNP Daten habe ich gleich mit rein gebaut, denen muss ich das auch noch irgentwie zusenden, wenn ich den den Herrn "vonnieda" mal erreiche. Peter
Ich bin langsam am Verzweifeln. Serialcomcnc bleibt beim Bohren und Fräsen in immer kürzeren Abständen einfach so stehen. Habe SCC und Ardunio schon neu instaliert. Im Programm code steht dann MSG:Preset to Continue Die Uhr läuft dann weiter ,auch der Ardunio flackert und scheint Daten zu bekommen
Angehängte Dateien:
-
Unbenannt.JPG
43 KB
Ich verstehe immer noch nicht warum SCC einfach stehen bleibt. Habe das Betriebssystem schon gewechselt. Warum wird Alarm ausgelöst?
Hi Y-Grenzwert überschritten? Bei X warst Du bereits drunter und drüber, bleibt nur Y über bei diesem Befehl. MfG
Marco schrieb: > Ich verstehe immer noch nicht warum SCC einfach stehen bleibt. > Habe das Betriebssystem schon gewechselt. > > Warum wird Alarm ausgelöst? Hallo Marco, Um Endschalterprobleme auszuschliessen (eigentlich deutet Alarm 1 darauf hin....) - hast du überhaupt welche angeschlossen ? - wenn ja, $21 = 0 setzen und Verdrahtung zum Arduino auf Minimum reduzieren (Endschalter am Arduino abklemmen) - nochmal testen (in report.c ist die Erzeugung der MSG Texte beschrieben...) Viele Grüsse Herbert
Herbert Janssen schrieb: > Um Endschalterprobleme auszuschliessen (eigentlich deutet Alarm 1 darauf > hin....) > - hast du überhaupt welche angeschlossen ? > - wenn ja, $21 = 0 setzen und Verdrahtung zum Arduino auf Minimum > reduzieren (Endschalter am Arduino abklemmen) > - nochmal testen Hallo Herbert Danke für den Hinweis - werde das heute Abend mal Testen. Die Home/Referenzfahrt geht einwandfrei. Und meine Endschalter sind mit Optokoppler abgesichert, was bis vor 2 Tagen immer Störungsfrei lief. Gruss Marco
Herbert Janssen schrieb: > Um Endschalterprobleme auszuschliessen (eigentlich deutet Alarm 1 darauf > hin....) > - hast du überhaupt welche angeschlossen ? > - wenn ja, $21 = 0 setzen und Verdrahtung zum Arduino auf Minimum > reduzieren (Endschalter am Arduino abklemmen) > - nochmal testen Hallo Herbert Wie du sagtest ,lag es an den Endschaltern -oder auch nicht ??????? Nach dem ich $21 auf null setzte, lief das Programm sauber durch. Dann überprüfte ich alle Kabel auf Brüche ,fand aber nichts. Also ging ich zurück auf $21=1 - und bis jetzt läuft alles . Für den Fall das es wieder passiert, weiß ich jetzt Bescheidt wo es hackt. Danke und Beste Grüße Marco
Angehängte Dateien:
-
CIMG0064.JPG
51 KB -
CIMG0065.JPG
49 KB -
CIMG0066.JPG
50 KB -
CIMG0067.JPG
51 KB -
CIMG0068.JPG
53 KB
Hier mal ein paar Arbeiten mit SCC
Hallo, Hat schon wer mal mit nem HC05 Bluetoothmodul und GRBL gearbeitet (unter Windows 10). LG
Hallo CNC Experten, auch ich mag das Programm sehr und habe Respekt vor der vielen Arbeit und Pflege damit. Leider funktioniert bei mir die Version 2.5 und 2.51 nicht. Der Schrittmotor lässt sich zwar steuern, aber die Digitalanzeige und das Grafikdisplay arbeitet nicht. Bei der alten Version v0.9e funktioniert alles einwandfrei, aber leider ist der Easyjob Modus nicht aktiv. Ich weiß nicht, woran der Fehler liegt. Gerade der Easyjob Modus gefällt mir sehr gut, da ich im Grunde genommen nicht viel mehr brauche. Deshalb wäre mir sehr daran gelegen, die Version v2.5 bzw. v2.51 zum Laufen zu bekommen oder aber den Easyjob in der alten Version. Ich habe alles an zwei Computern probiert und auch verschiedene Grpl-Versionen getestet, leider ohne Erfolg. Vielleicht hat jemand (oder gar der Autor) ähnliche Erfahrungen gemacht und kennt eine Lösung. Viele Grüße aus Nürnberg Wolfram
Hallo Wolfram, die neue Version von SCC arbeitet ausschließlich mit GRBL V1.x zusammen, du musst also deinen GRBL-Arduino auf die aktuelle GRBL-Version hochziehen. Nicht vergessen, die Konfiguration anzupassen: $10=0 Gruß, Harald
Lieber Harald, herzlichen Dank für Deine Hilfestellung. Den Grbl-File v1.1f habe ich aufgespielt, aber es ist alles beim Alten geblieben. Seltsamerweise funktioniert der Universal Gcode Sender auch nicht mehr. Ich wollte mit den Firmware Settings die Konfiguration anpassen, aber die Seite ist leer. Vielleicht fällt Dir noch was ein, wofür ich sehr dankbar wäre. Viele Grüße Wolfram
Gibts Albert überhaupt noch? Sehe keine Posts mehr von ihm.
Abdul K. schrieb: > Gibts Albert überhaupt noch? Sehe keine Posts mehr von ihm. Traditionell hat Albert im Sommer andere Interessen und wird sich sicher im Winter wieder melden :-)
Oh, im Rest von DE ist noch Sommer? Wir sind hier kurz vor Schnee.
Wolfram schrieb: > Universal Gcode Sender auch > nicht mehr. Ich wollte mit den Firmware Settings die Konfiguration > anpassen, aber die Seite ist leer. Hallo Wolfram, ich lese das so, dass du die Konfiguration mit UGS anpassen wolltest. Falls ich das richtig verstanden habe, nehme ich mal an, dass der UGS in einer Version vorliegt, die sich noch mit dem alten GRBL (V0.9xx) verstanden hat. Da dein Arduino jetzt aber GRBL 1.1f spricht, muss UGS wahrscheinlich ebenfalls aktualisiert werden (wenn es eine Version gibt, die GRBL V1.x versteht). Du kannst in SCC ebenfalls die Konfiguration auslesen (Befehl $$) und einzelne Werte einstellen -> Anleitung lesen, falls du das noch nicht getan hast ;-) Gruß, Harald
Abdul K. schrieb: > Oh, im Rest von DE ist noch Sommer? Wir sind hier kurz vor Schnee. Hihi, für das Wetter kann ich nichts, aber in den letzten Jahren hat sich Albert irgendwann wieder gemeldet. Ich hoffe, das ist auch dieses Jahr so :-) Wann Albert Winter beschließt, ist mir ebenfalls ein Rätsel.
Vielleicht hat er ja den Rückflug aus Südafrika verpaßt ;-)
Lieber Harald, nochmals vielen Dank für Deine Hilfe. Du hast Recht, ich sollte erst mal eingehend mit der sehr guten und ausführlichen Hilfe-Dokumentation beschäftigen. Dabei wird mir bewusst, dass ich mich nicht ausreichend mit den tieferen Computer-Grundlagen auskenne. So habe ich noch nie mit einem Serial Terminalprogramm gearbeitet und es gelingt mir nicht einmal die Grbl-Datei zu laden und zu editieren. Auch im SCC lässt sich bei mir die Konfiguration nicht auslesen. Testweise habe ich noch einmal die alte Grbl-Datei mit dem XLoader hochgeladen. Damit arbeitet auch der neueste UniversalCodeSender einwandfrei und ich kann die Grbl Datei editieren. Ich werde mich also die nächsten Tage damit beschäftigen, oder ganz aufgeben, aber meistens beiße ich mich bis zur Lösung hoffnungslos fest!!!. Viele Grüße Wolfram
Hallo Wolfram,
wenn du deinen Arduino per XLoader mit dem neuen GRBL V1.1 geladen hast
und in SCC den Connect Knopf clickst, meldet SCC dann mit einer
Messagebox
"Der ComPort ist jetzt aktiv..." oder
"Falscher ComPort oder noch nicht erkannt..."?
Im ersten Fall klappt die Kommunikation zwischen SCC und GRBL schon mal
prinzipiell.
Aber das scheint gar nicht das Problem zu sein, da du ja weiter oben
schon geschrieben hast, dass die Stepper sich drehen, wenn du
entsprechende Befehle gibst ("Der Schrittmotor lässt sich zwar
steuern...").
Wenn das stimmt, dann weiter:
Dein Hinweis "aber die Digitalanzeige und das Grafikdisplay arbeitet
nicht." deutet darauf hin, dass lediglich die Anzeigen nicht
aktualisiert werden.
"Digitalanzeige" und "Grafikdisplay" sind die grünen Zahlen für X, Y, Z
und F sowie das große Fenster rechts daneben im "Graphic"-Modus,
richtig?
Beim Start steht das große Fenster rechts auf "Monitor" und zeigt Texte
an, im Bestfall 4mal "Check port..." untereinander, nach kurzer Pause
dann folgende Ausgabe:1 | G92 X0 Y0 Z0 |
2 | Grbl 1.1f ['$' for help] |
3 | ok |
4 | ok |
5 | $X |
6 | ok |
dann kommt die Messagebox mit "Der ComPort ist jetzt aktiv...".
Wird die Box quittiert, wird der "Monitor" gelöscht.
Wenn du jetzt entweder in der Zeile ganz unten ("Manuelle G-Code
Eingabe") $$ und <Enter-Taste> eingibst oder alternativ den Knopf mit
"$$" clickst, sollte sich der "Monitor" mit den GRBL-Parametern füllen.
Jetzt Achtung!
Erscheint im "Monitor" lediglich das Echo "$$" in grüner Schrift, gib
über "Manuelle G-Code Eingabe" folgendes ein:1 | $10=0 |
und schließe die Eingabe mit der <Enter-Taste> ab.
Das sollte wieder mit dem passenden Echo ("$10=0") in grüner Schrift im
"Monitor" quittiert werden.
Jetzt einmal "Disconnect" clicken, die Messagebox quittieren, dann
"Connect" und Messagebox quittieren.
Wenn du jetzt auf $$ clickst, erscheinen die GRBL-Werte im "Monitor".
Ab jetzt sollten sich auch die Koordianten ändern und die Grafik
aktualisiert werden.
Das alles setzt voraus, dass dein Arduino wieder mit GRBL V1.1x
programmiert ist (per XLoader).
Gib mal durch, ob das des Rätsels Lösung war ;-)
Gruß, Harald
Lieber Harald, dank Deiner hervorragenden Anleitung habe ich es geschafft, die Maschine zum Laufen zu bringen. Was genau der Fehler war, habe ich nicht genau feststellen können. Ich habe Deine Anleitung mindestens zehnmal durchexerziert, x-mal ohne Wirkung die $$ gedrückt, bis plötzlich die Grbl-Datei ausgelesen wurde und von da an alles tadellos funktionierte. Das Einzige, was ich noch nicht geschafft habe, ist die Einstellung der Schrittweiten. So läuft meine Maschine statt 1 mm etwa 75 mm und ich kann im Monitor nichts editieren. Aber das wird ich auch noch lösen lassen. Ich möchte Dir noch einmal ganz herzlich für Deine Superanleitung und für die Zeit, die Du mir geopfert hast, herzlich bedanken. Viele Grüße Wolfram
Hallo Wolfram, gerne geschehen, kein Ding... Die Parameter kannst du nicht im Monitor editieren. Du musst die Parameter einzeln in der Eingabezeile ganz unten eingeben. Der Monitor zeigt immer nur das Ergebnis an. Gruß, Harald
Das habe ich soeben auch rausbekommen. Nochmals vielen Dank, lieber Harald!
Moin, mich würde interssieren ob die Möglichkeit besteht auch einen Kantentaster anzuschließen?
Hallo zusammen ich ich hoffe ich bin hier im richtigen Forum für meine Fragen Ich hab heute meine Proxxon MF70 auf CNC umgebaut Arduino Uno CNC Shild 3 und Serial ComCNC ich habe nun eine Platinenfile im Gcode. Hab den mal zur Probe laufen lassen scheint alles zu laufen x y z Achsen bewegen sich Nun zu meinem Problem ich weiß nicht wie ich das mit dem Nullpunkt mache. Wie findet die Maschine den Anfangspunkt die Platine ist 40x54 und im Eagleformat es ist kein Nullpunkt definiert worden. Ich bekommen die File von einem Kollegen als Gcode . Wie definiere ich zwischen der Maschine und Serial COMCNC den Nullpunkt und wie gleich ich den Tisch an so der er dann auch die 40x50 abfahren kann. Sorry bin absoluter Neuling vor einer Woche wusste ich nicht das e CNC gibt . Danke für die Hilfe Peter PS ich hoffe ich habe nicht zufiel Verwirrung erzeugt,
Hallo zusammen, Habe ein ähnliches Problem wie Harald am 28.11 ein paar Zeilen weiter oben. Ich kann mit dem X Loader nicht den Arduino Clone von banggood flashen: Grbl 1.1 es läuft .08 und $$ funktioniert wie oben beschrieben nicht. Wahrscheinlich Geekcreit® ATmega328P Nano V3 Controller Board Compatible Arduino Improved Version. Der X Loader startet, hört aber nicht mehr auf, kann mir bitte jemand einen Tipp geben. G92 X0 Y0 Z0 Grbl .8f ['$' for help] ok ok $X ok wird angezeigt, Verbindung funktioniert. Schöne Weihnachten Grüße
Hallo Leute wie ich lesen kann habt ihr div. Probleme und Lösungen gefunden. Mein Problem.... Meldung: Freeware abgelaufen... bitte prüfen Sie ob eine neue Version vorhanden ist. Ist, Ver. 2.51, diese habe ich dann mal installiert aber in dieser Version wird die Z Achse nicht erkannt und das Programm wird beendet " Schwerwiegender Fehler...." Y und X Achsen sind da? Wer hatte auch schon diesen Fehler und hat eine Lösung für das Problem gefunden. Gruß Wolfgang
Wolfgang schrieb: > in dieser Version wird die Z Achse nicht erkannt Hallo Wolfgang, was genau meinst du damit? SCC "erkennt" keine Achsen, der GRBL-Controller meldet auch keine Achseninformationen zurück, die man mit einer Software auf dem Rechner "erkennen" könnte. Nur die Werte für X-, Y- und Z-Position sowie ggf. End- oder Home-Schalter werden gemeldet (auch noch andere Werte, aber nicht das Vorhandensein oder die Anzahl der an der Fräse verbauten Achsen). Sicher nur ein Missverständnis meinerseits ;-) Von welcher Version von SCC hast du auf V2.5.1 aktualisiert? Gruß, Harald
Wolfgang schrieb: > Ist, Ver. 2.51, diese habe ich dann mal installiert Vermutlich liegt dein Problem an eine GRBL Version < 1.1 auf dein Arduino Board. SerialComCNC benötigt GRBL Version >= 1.1, es muss zuerst GRBL Version >= 1.1 auf das Arduino Board geflasht werden. Wichtig danach die passende Einstellen von GRBL-Configuration. $3 Einstellun der Verfahrrichtung der X, Y und Z Achse. $10 Status Report Mask. Muss auf $10=0 gesetzt sein. $100, $101 und $102 – [X,Y,Z] steps/mm $110, $111 and $112 – [X,Y,Z] Max rate, mm/min dann sollte es laufen Gruß Wolfgang
Angehängte Dateien:
-
Xload.png
8,1 KB -
Meldung.png
160 KB
Hallo, danke für die Antworten aber... Ich habe das Board geflasht auf v. 1.1.............. siehe Anhang aber leider immer noch der gleiche Effekt........... siehe Anhang Gruß Wolfgang
Hallo noch mal.. die alte Version war "Setup_SerialComCNC_0.9f(2).zip" und hat hervorragend gefunnzt. Alte *.hex grbl_v0_9i_atmega328p_16mhz_115200_for_SO2.hex und diese ist jetzt geladen: grbl_v1.1f.20170801.hex Gruß Wolfgang
Wolfgang schrieb: > Ich habe das Board geflasht auf v. 1.1 Hallo Wolfgang, nach dem Flashen auf die neue Version musst du (wie Wolfgang B. weiter oben schon geschrieben hat!) auf jeden Fall noch den Parameter $10=0 einstellen. -> Ohne diese Umstellung versteht SCC sich nicht mit GRBL V1.1x und SCC findet keine passenden Variablen zum Anzeigen. Das steht auch dick und fett im Manual zu SCC drin, das Albert für uns (er kennt sein Programm, unterstelle ich) geschrieben hat. Diese Frage ("ich habe von GRBL V0.x auf GRBL V1.x aktualisiert, jetzt funktioniert nichts mehr, vorher war alles ok") ist hier im Forum schon gefühlt hundert mal gestellt und beantwortet worden. Ja, der Thread ist inszwischen ziemlich lang, aber die letzten paar Seiten ab der Umstellung auf GRBL V1.1 und das Nexion Display (das ist etwa März 2017 gewesen) sollte man schon mal schmökern. Gruß, Harald
Eigentlich sollte der Autor von SCC ja auch wieder aus dem Urlaub zurück sein... Schade - man hört nichts mehr von ihm.
Das würde den Nichtlesern der Anleitung auch nicht weiter helfen, mehr als er in seiner Anleitung bereits geschrieben hat, kann er nicht zum Besten geben. Aber ja, ich würde mich auch über ein Lebenszeichen von Albert freuen :-)
auch ich würde mich über ein Lebenszeichen von Albert freuen, da noch einige Bugs in der 2.51 Version vohanden sind.:-( Gruß Wolfgang
Hallo User, meine Maschine läuft wieder danke für die Hilfe. Ein Effekt hatte ich aber: Die Achsen "Z" und "X" liefen in die falsche Richtung, ich hab sie einfach umgepolt. Gibt es einen $ Wert der das auch erledigt? Das würde mich noch interessieren. Danke und einen guten Rutsch ins Neue ;-) Wolfgang
Hallo Danke auch an den generften Gast. Aber ich bin Modellbauer und nutze meine Fräse dafür. Wenn die dann nicht funzt wenn ich sie brauche nerft mich das. Dann muß ich erst wieder am dem Teil rumfummeln und nur weil die FREEWARE ein Timeout hat.... wofür? Ok die neue Version hat neue Funktionen wie Handradvorbereitung sprich zweiter com und die Easyfunktion..... brauche ich erst mal nicht. Mache alles mit Autocad usw. Gruß und guten Rutsch
Wolfgang schrieb: > > Die Achsen "Z" und "X" liefen in die falsche Richtung, ich hab sie > einfach umgepolt. > Gibt es einen $ Wert der das auch erledigt? > Das würde mich noch interessieren. > Hallo Wolfgang, der gesuchte Wert für deine Konfiguration (vor dem Umpolen von X und Z !) lautet: $3=5 lt. folgender Tabelle: $3 – Direction port invert, mask Setting Value X Y Z 0 00000000 N N N 1 00000001 Y N N 2 00000010 N Y N 3 00000011 Y Y N 4 00000100 N N Y 5 00000101 Y N Y 6 00000110 N Y Y 7 00000111 Y Y Y Dadurch wechselt grbl die Drehrichtung von X und Z ! Lass es aber lieber bei der jetzigen Hardwarekonfiguration, du musst sonst bei jeder neuen Version wieder $3=5 setzen, denn Standard ist $3=0 (keine Drehrichtungsänderung an X,Y und Z). viele Grüsse und das es nur draußen knallt, nicht in der Werkstatt... Herbert
Danke Herbert und an Alle Guten Rutsch
Btw, ich finde Albert super. Hat jemand in den letzten Monaten noch ein Lebenszeichen gesehen? Habe aus Neugier gestern ein bisschen gegoogelt, nach ca. Nov 2016 keine Aktivitäten mehr auffindbar. Viele Grüße, Conny
Hi Conny, schön, dass sich offenbar noch jemand um Albert sorgt, geht mir genauso. Etwas aktuellere Infos gibt es von ihm selbst hier im Thread. Am 01.02.2017 schreibt er uns, dass er einen Blinddarmdurchbruch überstanden hat: Siehe Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega" Am 14.April kam der letzte Post hier im Forum. Hoffen wir alle, dass Albert soweit in Ordnung ist! Gruß, Harald
Conny G. schrieb: > Hat jemand in den letzten Monaten noch ein > Lebenszeichen gesehen? https://www.facebook.com/Ulrich.A.Maassen .
Da kommt bei mir nur ein Hinweis, dass die Seite nicht existiert. (Kann daran liegen, dass ich in FB nicht vertreten bin)
Harald S. schrieb: > Da kommt bei mir nur ein Hinweis, dass die Seite nicht existiert. > (Kann daran liegen, dass ich in FB nicht vertreten bin) genau so ist es
8.8.2017 hat er ein Naturvideo hochgeladen.
Letzter Facebook Post im November, dann ist ja alles ok würde ich sagen. Er hat wahrscheinlich nur keine Lust auf die Nörgler und Prolls hier.
Harald S. schrieb: > Conny G. schrieb: >> auf die Nörgler und Prolls hier > > Danke, das war unnötig Das ist in diesem Thread ja noch recht moderat, aber generell ist es auf Mikrocontroller.net echt anstrengend.
Hallo zusammen, Ich kann mit dem X Loader nicht Grbl 1.1 flashen: Es läuft .08 und $$ funktioniert wie oben beschrieben nicht. Wahrscheinlich Geekcreit® ATmega328P Nano V3 Controller Board Compatible Arduino Improved Version. Der X Loader startet, hört aber nicht mehr auf, kann mir bitte jemand einen Tipp geben. Das Programm bleibt bei Grbl .8 hat aber kaum Funktionen. Hab es auch mit dem Arduino Programm probiert, geht nicht. G92 X0 Y0 Z0 Grbl .8f ['$' for help] ok ok $X ok wird angezeigt, Verbindung funktioniert. Grüße
Hi siegi! Ich habe das gerade mal mit einem Arduino nano V3 (ein China-Clone mit CH340 USB-Seriell-Wandler-Chip) getestet (ich habe den XLoader vorher nie verwendet ). Wenn der COM-Port korrekt eingestellt ist (auf den Port, der beim Einstecken des USB-Kabels an den Arduino in der Gerätesteuerung neu erscheint -> dort mal beobachten. Aber du kennst den Port ja, die Kommunikation mit GRBL V0.8 läuft ja, das sollte also richtig von dir eingestellt sein), wird der HEX file problemfrei auf den Arduino geflasht. Den HEX fiel habe ich über den Dateiauswahlbrowser in XLoader ausgewählt. "Device" muss auf "Duemilanove/Nano(ATmega328)" stehen, Baudrate 57600. Diese Werte waren bei mir Default, musste ich nicht ändern. Der COM-Port war defaultmäßig falsch ausgewählt. Das von dir beschrieben Verhalten erreiche ich, wenn ich den COM port bewusst auf einen falschen Port stelle. Steht der COM port richtig, flackern die LEDs auf dem Arduino. Steht der Port falsch, leuchtet nur die Power-LED, die Kommunikations-LEDs bleiben aus. Hilft das? Gruß, Harald
Hallo Harald, vielen Dank, ich bin einen Schritt weitergekommen: Dein Tipp geht offensichtlich in die richtige Richtung. Der XLoader (was vorher der Fall war) hängt sich nicht mehr auf und die LEDs flackern jetzt. Nach etwa 30 Sekunden kommt aber die Fehlermeldung "Upload failed". Ich habe ebenso den China-Clone mit "CH340 USB-Seriell-Wandler-Chip". Duemilanove/Nano(ATmega328)" stehen, Baudrate 57600 ist eingestellt. grbl_v1.1f.20170131 HEX file und auch andere Versionen gehen leider nicht. Beim Starten des Programms kommt weiterhin "Grbl .8f ['$' for help]". Com Port3 stimmt Systemsteuerung: "USB-SERIAL CH340 (COM3)" Danke nochmal, ich probiere es weiter und bin für jeden Tipp aufgeschlossen Grüße, Siegi
siegi schrieb: > Danke nochmal, ich probiere es weiter und bin für jeden Tipp > aufgeschlossen Hallo siegi, hast du mit der Arduino IDE (1.8.5) schon versucht, deinen Nano anzusprechen ( was meintest du mit geht nicht )? COM Port und Arduino Typ müssen passend eingestellt werden, dann sollte es gehen. Vor dem upload von irgendwas versuche das EPROM zu löschen mit dem "eeprom clear" sketch. Danach versuche nochmal mit xloader die hexdatei zu laden bzw. mit der IDE den grbl upload durchzuführen. Nach meiner Erfahrung sollte immer nur eine grbl Version im libraries Ordner sein... Viel Erfolg und Grüsse Herbert
Hi Siegi, ich beobachte hier bei mir einen etwas seltsamen Effekt beim Rumspielen mit dem XLoader. Der XLoader schlägt mir als Download Geschwindigkeit 57600 Baud vor - damit funktioniert das Flashen. SCC kommuniziert aber mit 115200 Baud mit dem Arduino - das klappt auch, der Arduino arbeitet also mit diese Baudrate am Port, denke ich. Stelle ich im XLoader die hohe Baudrate ein, flackern die LEDs am Arduino kurz auf, bleiben dann aber aus und der XLoader hängt -> kein Download. Im Netz gibt es Seiten, die die Arbeitsweise mit XLoader beschreiben, eine davon sagt, der Download auf den Arduino muss mit 115200 erfolgen - das klappt bei mir aber nicht, siehe oben. Vielleicht ist es bei dir ja umgekehrt... Stelle versuchsweise mal die Buadrate um. Harald
Herbert Janssen schrieb: > Vor dem upload von irgendwas versuche das EPROM zu löschen mit dem > "eeprom clear" sketch. Das ist wohl ein guter Hinweis. Wenn XLoader avrdude nicht per Parameter dazu animiert, vor dem Programiervorgang das Flash zu löschen, dann muss das irgendwie anders gemacht werden. Bei mir hier klappt das Flashen ohne Fehler, weil ich den identischen File geflasht habe. ...Soweit die Theorie In der Praxis kann ich das nicht bestätigen, zumindest GRBL 1.1e und 1.1f lassen sich problemfrei nacheinander flashen und funktionieren dann auch. Nicht faul habe ich auch noch einen GRBL V0.9j geflasht, auch das funktionierte, genauso der Rückweg nach GRBL V1.1f. ABER... jetzt wird zwar die Kommunikation mit SCC V2.5.1 aufgebaut, aber der Befehl $$ führt zu nichts, es werden nciht die Parameter ausgegeben. Auch $10=0 in der "manuell G-Code Eingabe" wird nicht beantwortet. Dann fällt mir ein, dass nach dem Flashen einer neuen Version von GRBL SerialComCNC neu gestartet werden muss, also Neustart von SCC, $$ -> die Parameter werden wieder korrekt angezeigt. Also nochmal zusammengefasst: - XLoader löscht offenbar das Flash vor dem Download, "eprom clear" sketch ist also eher unnötig - vor dem Flashen mit XLoader SCC schließen, nach dem Flashen SCC neu starten (die beiden Programme geben den COM-Port jeweils wieder frei und behindern sich nicht gegenseitig, wenn in SCC vor dem FLashen ein Disconnect ausgeführt wird, aber offenbar merkt sich SCC irgendwo im Getriebe etwas, das ihn mit neuem GRBL stört(?)) Probiere das mal... Harald
Hallo Harald, die Download Geschwindigkeit des XLoader ist abhängig vom Bootloader deines Arduino Clone. sigi schrieb: >Der XLoader (was vorher der Fall war) hängt sich nicht mehr auf und die >LEDs flackern jetzt. >Nach etwa 30 Sekunden kommt aber die Fehlermeldung "Upload failed". Die verschidene Bootloader der Clone haben auch unterschidliche Baudraten und Übertragunsprotokolle mit der der Xloader und AVRDUDE teilweise nicht zurecht kommt. Um diesen „Wildwuchs“ vorzubeugen flashe ich den Bootloader in den Clone neu mit den orginal Bootloader vom Arduino/Genuino Uno. Gruß Wolfgang
Hallo Herbert, Hallo Harald, Hallo Wolfgang,
danke für eure Hinweise und Unterstützung:
wie vorgeschlagen habe ich mit Arduino IDE (1.8.5)
vor dem upload versucht das EPROM zu löschen mit dem
"eeprom clear" sketch.
folgende Fehlermeldung erscheint:
Arduino: 1.8.5 (Windows 10), Board: "Arduino Nano, ATmega328P"
Der Sketch verwendet 764 Bytes (2%) des Programmspeicherplatzes. Das
Maximum sind 30720 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers, 2039
Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
avrdude: verification error, first mismatch at byte 0x0002
0xe6 != 0x5c
avrdude: verification error; content mismatch
avrdude: verification error; content mismatch
Ungültige Bibliothek C:\Users\siegfried\Documents\Arduino\libraries\grbl
in C:\Users\siegfried\Documents\Arduino\libraries\grbl gefunden
Ungültige Bibliothek C:\Users\siegfried\Documents\Arduino\libraries\grbl
in C:\Users\siegfried\Documents\Arduino\libraries\grbl gefunden
Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.
Viele Grüße
Siegfried
PS
beim auswählen des Arduino/Genuino Uno tritt folgender Ffehler auf:
Arduino: 1.8.5 (Windows 10), Board: "Arduino/Genuino Uno"
Der Sketch verwendet 764 Bytes (2%) des Programmspeicherplatzes. Das
Maximum sind 32256 Bytes.
Globale Variablen verwenden 9 Bytes (0%) des dynamischen Speichers, 2039
Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x0d
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x0a
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x47
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x72
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x62
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x6c
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x20
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x30
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x2e
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x38
Beim Hochladen des Sketches ist ein Fehler aufgetreten
Ungültige Bibliothek C:\Users\siegfried\Documents\Arduino\libraries\grbl
in C:\Users\siegfried\Documents\Arduino\libraries\grbl gefunden
Ungültige Bibliothek C:\Users\siegfried\Documents\Arduino\libraries\grbl
in C:\Users\siegfried\Documents\Arduino\libraries\grbl gefunden
Dieser Bericht wäre detaillierter, wenn die Option
"Ausführliche Ausgabe während der Kompilierung"
in Datei -> Voreinstellungen aktiviert wäre.
Wolfgang B. schrieb: > die Download Geschwindigkeit des XLoader ist abhängig vom Bootloader > deines Arduino Clone. Hallo Wolfgang, ich denke, die verwendete Baudrate steht im INI-file des XLoader (im gleichen Verzeichnis, die Datei "devices.txt") und ist eine zufällige Übereinstimmung. Wie geschrieben ist der von mir verwendete Bootloader meist der von Lady Ada (Adafruit), weil der eine recht kurze Wartezeit nach dem Reset hat und ansonsten problemlos funktioniert. Es kann aber sein, dass der von mir für die Versuche für Siegi verwendete Nano noch seinen ursprünglichen Bootloader hat. Hier fliegen gerade eine Handvoll Nanos auf dem Tisch rum, irgendwie habe ich den Überblick verloren... Gruß, Harald Ach so... Siegis Problem scheint ja nicht am verwendeten Flash-Tool zu liegen, sondern an seinem Nano Clone (da weder XLoader noch die Arduino IDE seinen Nano beschreiben können). @Siegi: Eventuell kannst du noch versuchen, in der IDE (die Arduino Oberfläche) über "Werkzeuge->Bootloader brennen" deinen Nano zur Zusammenarbeit zu überreden, aber da beide Tools das Programm avrdude verwenden, dürfte das vergebene Liebesmüh sein. Einen alternativen (und von avrdude verstandenen) Bootloader bekommst du nur mit einem echten Flash-Tool auf deinen Nano. So ein "Brenner" verwendet die 6 Pins am Rand deines Arduino und umgeht bzw. ignoriert den im Arduino vorhandenen Bootloader und brennt den Inhalt des HEX-file direkt ins Flash. Diesen Vorgang einem nicht vorbelasteten Anwender (entschuldige, wenn ich dich damit falsch einschätze) so zu beschreiben, dass nichts schief geht, möchte ich mir allerdings ersparen. Zudem wirst du kein Flash-Tool dein Eigen nennen und wahrscheinlich auch in Zukunft keines mehr benötigen (wenn dein Nano mal GRBL richtig vestanden hat). Der billigste mir bekannte Flasher ist "mySmartUSB light" (www.myAVR.de), ich habe auch schon Bausätze für so einen Brenner gesehen, die für ca. 5 Euronen über die Theke gehen. Für das Geld (für den MySmartUSB light) kannst du dir aber auch beim Chinamann ein oder zwei Fünferpacks Arduino Nano V3.0 bestellen, deren Bootloader dann wieder funktionieren dürften. Nur ein Vorschlag... Gruß, Harald
Harald S. schrieb: > Hier fliegen > gerade eine Handvoll Nanos auf dem Tisch rum, irgendwie habe ich den > Überblick verloren... geht mir genauso.:-( des wegen flashe ich den Bootloader in den Clone neu. in devices.txt steht auch das verwendete Übertragunsprotokoll. Gruß Wolfgang
Hallo Zusammen, vielen Dank für die eifrige Diskussion und die vielen Beiträge. Ich probiere weiter und melde mich wieder. Ich habe noch einen flash-Tool im Keller von einer anderen Aktivität mit dem probiere ich es. (Übertragungsraten wurden alle getestet). Viele Grüße Siegfried
Hallo zusammen, Großer Erfolg. Bei Amazon bestellt mit FT Prozessor, ist aber wieder der CH340 gekommen (eigentlich nicht gut). Aber x Loader und 1.1 Version sofort geflashed. Software geöffnet und passt. Jetzt löte ich noch die Beinchen dran (waren bei 7€ nicht dabei vom China Man wäre es billiger gewesen). Und dann geht's hoffentlich los, nach langem Kampf.... Vielen Dank an Euch! Siegi
Hallo zusammen, ich trau mich`s fast gar nicht zu sagen. G92 X0 Y0 Z= Gbr 1.1f [´$`for help] ok $X ok ok und nach$$ $0=10 $1=25 $2=0 $3=0 $4=0 $5=0 $6=0 $10=0 $11=0.010 $12=0.002 $13=0 $20=0 $21=0 $22=0 $23=0 $24=25.000 $25=500.000 $26=250 $27=1.000 $30=1000 $31=0 $32=0 $100=250.000 $101=250.000 $102=250.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=200.000 $131=200.000 $132=200.000 $$ leider brummt dann zwar immer was aber die Achsen fahren nicht...
Ergänzung die live anzeige in der Software funktioniert. Könnt Ihr bitte nochmal einen Tipp geben. Grüße Siegfried
siegi schrieb: > leider brummt dann zwar immer was aber die Achsen fahren nicht... - Motoranschlüsse vertauscht - Motor zu Schwach /Mechanik schwergängig - zu wenig Strom am Treiber eingestellt - Netzteil liefert nicht die Leistung ....
siegi schrieb: > Ergänzung Error 22 Feed rate has not yet been set or is undefined. die Feed rate ist nicht eingestellt bzw. gesetzt worden. Gruß Wolfgang
Hallo liebe Arduino Freunde, mit dem alten Arduino und on Bord grbl0.8 mit dem PC Programm GRBl läuft das iphone200 Testprogramm mit allen Achsen. Leider gehen da eben nicht alle Manuellen Funktionen und die Koordinatenanzeigen gehen nicht. -> Alle Achsen sind richtig angeschlossen. Das geht nicht mehr mit der Version 1.1 auf dem neuen Ardu Board. Bei der Serial Com CNC Software laufen die Koordinatenanzeigen mit, die Motoren brummeln ein bisschen. Sonst geht nichts. Oben sind die Programm Parameter, was kann man an der Feed rate aussetzen? Viele Grüße Siegfried
Angehängte Dateien:
-
SCC_2.0.jpg
110 KB
kannst du den die Achsen manuell fahren? Versuch das doch erstmal. Gruß Wolfgang
Es geht um die initiale feed rate beim manuellen Verfahren: sie muss im SCNC expliziet gesendet werden. Andere GCode-Sender senden die Feed rate gleich mit... Man kann sie aber auch über $Nx=line (save startup block) abspeichern... Bist Du sicher dass alle $$-Einstellungen in deinen beiden GRBL-Versionen gleich sind?
sven schrieb: > Bist Du sicher dass alle $$-Einstellungen in deinen beiden > GRBL-Versionen gleich sind? $10 muss auf =0 sein! Wolfgang
Hallo Zusammen, vielen Dank, zu Wolfgang: die manuellen Achsen fahren nicht nur manchmal die X Achse, kann aber keine Korrelation finden. Nur wenn ich den Knopf in der Mitte der Pfeile drücke brummt es für 5 Sekunden Motoren funktionieren aber offensichtlich und sind richtig angeschlossen. Wolfgang B. schrieb: > kannst du den die Achsen manuell fahren? > > Versuch das doch erstmal. > > Gruß Wolfgang zu Sven: Mir ist das nicht ganz klar wo ich was ich ändern kann die Feed rate ist so eingestellt "Man kann sie aber auch über $Nx=line (save startup block) abspeichern..." $100=250.000 $101=250.000 $102=250.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 zu Wolfgang $=0 ist gesetzt. Die Pin Lötungen vom Board hab ich überprüft die sehen optisch gut aus. Grüße Siegfried
Sind denn die $100 bis $120 Einstellungen gleich für beide GRBL Versionen? Die mit $110-$112 eingestellte feed rate ist die maximal von GRBL verwendete - auch wenn per GCode eine höhere feed rate gesetzt wird. Aber SCNC setzt gar keine feed rate wenn man nur auf einen Pfeil klickt... Und das gibt den Fehler 22. $120=10 ist die Beschleunigung, die eher sehr gering ist... Es dauert also bis die max. Geschwindigkeit erreicht ist - falls der gesetzte Weg ausreicht. Du kannst eine initiale feed rate 'einbrennen' welche automatisch nach Reset gesetzt wird z.B. sende $N0=F100 Dann ist es erstmal egal dass SCNC keine feedrate sendet... Siehe https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands#n---view-startup-blocks
siegi schrieb: > die manuellen Achsen fahren nicht nur manchmal die X Achse, kann aber > keine Korrelation finden. > Nur wenn ich den Knopf in der Mitte der Pfeile drücke brummt es für 5 > Sekunden SCNC scheint grundsätzlich zu laufen. so wie ich das lese ist das wohl ein hardware Problem oder die Einstellungen stimmen nicht. Gruß Wolfgang
Hallo zusammen bin völlig verzweifelt. 3. Board mit FTDI-Chip und es geht immer noch nicht. Grüße
Sind deine beiden GRBL-Hex files (Du nutzt Vers 1.1 und 0.8 ?) evtl. verschieden konfiguriert? D.h. Stp und Dir liegen auf verschiedenen Pins? Sonst versuch nochmal einen anderen GRBL-Sender (z.B. https://github.com/svenhb/GRBL-Plotter)
BTW: wie hast Du deine Treiber angeschlossen? Ich interessiere mich gerade für das CNC Shield V4 für A-nano - dort sind leider Stp und Dir vertauscht (für default GRBL 1.1 Settings). Siehe auch https://forum.arduino.cc/index.php?topic=406110.0
Hallo Sven, beim GRBL Plotter fährt die X Achse wenn ein Programm läuft aber immer nur nach links. Mir ist nicht klar wie ich nachprüfen kann ob Step und Dir vertauscht sind. Grüße Siegi
@Sven Dein Programm GRBL-Plotter gefällt mir außerordentlich gut. Es hat das Zeug, alles, was ich bisher so probiert habe (und das waren so einige) zu übertreffen. Funktionsumfang, Bedienung lassen eigentlich kaum noch Wünsche offen. Mit Spannung erwarte ich jedes neue Update... Danke
siegi schrieb: > Mir ist nicht klar wie ich nachprüfen kann ob Step und Dir vertauscht > sind. Hi Siegi, wenn es wirklich um Step und Dir geht, dann tausche einfach die beiden Leitungen (entweder am Arduino, oder wenn das einfacher ist, am Eingang des Treibers/Endstufe). Da kann nichts kaputt gehen, beides sind Digitalsignale und beide Eingänge erwarten das. Das Ergebnis wird für scih sprechen (also wenn es danach läuft, waren die Anschlüsse in der Tat vertauscht, geht es nicht, dann wieder zurück tauschen). Erwartungshaltung: Wenn der Step-Eingang mit dem Richtungssignal beaufschlagt wird, macht er genau einen Schritt. Ob dabei die Richtungsumschaltung mit dem Step-Signal zu Brummen führt, weiß ich nicht. Nachtrag: Da du schreibst, "die X-Achse fährt, aber immer nur in eine Richtung", ist zumindest der Step-Anschluss korrekt. Also musst du herausfinden, wo die Unterbrechung des DIR-Signals passiert. Je nachdem wie deine Steuerung aufgebaut ist, kannst du ja mal die DIR-Leitung am Arduino lösen und jeweils an Plus 5V und anschließend an Masse halten/anschließen und dann Steps applizieren. So findest du heraus, ob deine Endstufen korrekt arbeiten. Ich muss nochmal nachfragen: Mit ansonsten identischem Aufbau und identischer Verkabelung zwischen Arduino und Endstufen läuft deine Fräse mit GRBL V0.8? Ich muss mal angestrengt überlegen, was ich ändern musste, als ich die GRBL-Version gewechselt habe... ist schon eine Weile her. Harald
Hallo Harald, hallo Sven danke nochmal für eure Mühe. Zusammenfasend: Die Fräse läuft mit dem Board 1 CH340 und der Software 0.8 (das Board lässt sich nicht neu flashen). Alle drei Achsen Funktionen mit Test Programm, das ganze nur mit der Grbl Control Software (Git Hub). Leider gehen auch hier nicht alle Schritte und Anzeigen. Aber die Fräsmaschine fährt die Schrift nach. Meiner Meinung nach folgt daraus a) -> Motoren funktionieren und sind richtig auf dem CNC Shield angeschlossen. Funktonen fehlen da 0,8 nicht mit Version Software am PC kompatibel. b) die Änderung des Board 2 ch340 und Board 3 FTDI Chip erlauben es die Version 1.1 aber hier scheint wie Sven oben beschrieben ein Setting nicht zu stimmen. Einzig und allein lässt sich der Spindelmotor ein und ausschalten. Sowie beim grbl Plotter fährt bei Testprogrammen nur die x Achse aber immer nur in eine Richtung bis zum Anschlag. Viele Grüße Siegfried
Hallo Siegi und Harald, Harald S. schrieb: > GRBL V0.8? > > Ich muss mal angestrengt überlegen, was ich ändern musste, als ich die > GRBL-Version gewechselt habe... ist schon eine Weile her Die Pins D11 und D12 sind vertauscht worden, möglicherweise kommt da ein Blödsinn bei raus, wenn man das nicht beachtet, da ja IN und OUT vertauscht werden. Möchte ich jetzt nicht simulieren... vielleicht nur mal kontrollieren viele Grüsse Herbert
Herbert Janssen schrieb: > Die Pins D11 und D12 sind vertauscht worden Hallo Herbert, super Hinweis, danke! Ich hatte seit meinem letzten Post gesucht, aber bisher nichts gefunden :-( Harald
Hallo Herbert , hallo Harald, habe Pin 11 und 12 vertauscht. Board 2 ch340 Version 1.1 mit Seriell Com CNC 2.5.1 -> Reaktion gleich: Textprogramm nur X Achse fährt und nur nach links. Spindel ein aus geht. Error 22 bei manueller Eingabe. Grüße Siegi
Habe übrigens folgendes Gerät mit Bord: https://www.banggood.com/de/2417-3-Axis-Mini-DIY-CNC-Router-Wood-Craving-Engraving-Cutting-Milling-Desktop-Engraver-Machine-240x170x65mm-p-1209292.html?rmmds=myorder&cur_warehouse=CN Grüße Siegi
Woher stammt deine 0.8 Version? Evtl ist das die orginal mitgelieferte (https://www.banggood.com/de/2417-3-Axis-Mini-DIY-C...) Version - dann hat man sich evtl. auch den Bootloader gespart, so dass Du nicht ohne weiteres updaten kannst.
Angehängte Dateien:
-
GRBL_11.jpg
51 KB
>Mir ist nicht klar wie ich nachprüfen kann ob Step und Dir vertauscht
sind.
Nachmessen oder Leiterbahnen verfolgen...
Ich denke es müsste so verdrahtet sein für GRBL 1.1
siegi schrieb: > Habe übrigens folgendes Gerät mit Bord Hallo Siegi, Nochmal zu deiner Konfiguration: sind $2 - $4 und $100 - $132 bei beiden grbl Versionen gleich ? vielleicht hast du's schon überprüft ( und beantwortet? ) aber nur nochmal zur Sicherheit... nur nicht verzagen..irgendwann geht's schon ! Viele Grüsse Herbert
Angehängte Dateien:
-
GRBL_11.jpg
94 KB
Hallo Sven, ja die Version wurde mitgeliefert. Ich habe die Verschaltung nachgemessen. Bitte schau Dir das Bild an. Grüße Siegfried
Hallo Herbert, auf der Version 1.1 ist folgendes eingestellt. Leider kann ich die Version0.8 nicht auslesen. $0=10 $1=25 $2=0 $3=0 $4=0 $5=0 $6=0 $10=0 $11=0.010 $12=0.002 $13=0 $20=0 $21=0 $22=0 $23=0 $24=25.000 $25=500.000 $26=250 $27=1.000 $30=1000 $31=0 $32=0 $100=250.000 $101=250.000 $102=250.000 $110=500.000 $111=500.000 $112=500.000 $120=10.000 $121=10.000 $122=10.000 $130=200.000 $131=200.000 $132=200.000 ok
Angehängte Dateien:
Anbei noch eine Info. Siehe bitte Bild.
Hallo Sven, soll ich alles umlöten oder gibt es andere Option? sieh oben: Autor: sven (Gast) Datum: 12.01.2018 21:24 Bild Sollzustand? Autor: siegi (Gast) Datum: 13.01.2018 07:13 Bild Istzustand Grüße Siegfried
Hallo Siegi, die einfachste Option ist vermutlich sich die Arduino Umgebung zu installieren, die GRBL-Settings anzupassen und neu zu compilieren. Allerdings musst Du das dann für jede neue GRBL Version machen... In dieser Datei ab Zeil 39 und 47 musst Du deine Konfig eintragen... https://github.com/gnea/grbl/blob/master/grbl/cpu_map.h Beschreibung über das ganze gibt es hier: https://github.com/gnea/grbl/wiki/Compiling-Grbl Gruß Sven
siegi schrieb: > Leider kann ich die Version0.8 nicht auslesen. $100, $101 und $102 = [X,Y,Z] steps/mm steps/mm = (stepsProUmdrehung * microsteps) / mmProUmdrehung stepsProUmdrehung ist wie viele steps deine Schrittmotoren für eine Umdrehung benötigen. mmProUmdrehung ist die Steigung deiner Spindel/Achse (X,Y,Z) microsteps ist auf dein Stepperboard mit den Schaltern eingestellt. Wenn die Parameter $100, $101 und $102 nicht stimmen laufen die Schrittmotoren nicht korreckt. Du solltest versuchen deine 0.8 Version auszulesen und die Werte in der 1.1x Version übernehmen. Oder schau in den Daten deiner Maschine/Schrittmotoren nach ob die Werte angegeben sind. Gruß Wolfgang
siegi schrieb: > auf der Version 1.1 ist folgendes eingestellt. > Leider kann ich die Version0.8 nicht auslesen Hallo Siegi, dir wird kaum anderes übrig bleiben, als die Originalversion auszulesen. Hast du einen mit Version 0.8 funktionsfähigen Arduino ? Wenn ja, verbinde dich (ohne externe Verdrahtung sollte es auch gehen) mit SCC z.B. in der Version von folgendem link: Beitrag "Re: Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega". Lese die config. mit $$ aus und vergleiche sie mit der von grbl 1.1 Vielleicht klappt das ja... Viele Grüsse Herbert
Hallo Zusammen, nach hartem Kampf hab ich die Pins wie oben von Euch vorgeschlagen in der Software geändert. Ich hab dazu die Datei CPU_MAP geändert. Dazu war ein durchmessen der Schaltung (Hinweis von Sven) erforderlich. Die Werte gab es auch unter "grbl-laseraxe = Code für China Board". Dann hab ich alles neu geflashed. Und siehe da nach einigen 10 Stunden geht es. Vielen Dank nochmal an euch ich werde sicher nochmal Hilfe brauchen. Grüße Siegi
Prima, freut mich dass Du es hinbekommen hast.
Hallo Siegi, habe noch was gefunden in: https://forum.banggood.com/forum-topic-67340.html How did you perform the upgrade? Did you modify the hardware aswell (as D11 and D12 are swapped)? I did the upgrade to 9i but the laser wouldn't turn on (just the pilot light). grbl 9 has way more settings than 8c.. Care to share? UPDATE: Nevermind, just found out that 0.9i has the option to pwm on as default, thus switching D11 and D12. grbl 0.9g works fine on this machine. MAke sure you backup your original settings first. For documentation i'll list mine here: Grbl 0.8c ['$' for help] ok $0=100.000 (x, step/mm) $1=100.000 (y, step/mm) $2=100.000 (z, step/mm) $3=10 (step pulse, usec) $4=250.000 (default feed, mm/min) $5=500.000 (default seek, mm/min) $6=192 (step port invert mask, int:11000000) $7=25 (step idle delay, msec) $8=20.000 (acceleration, mm/sec^2) $9=0.050 (junction deviation, mm) $10=0.100 (arc, mm/segment) $11=25 (n-arc correction, int) $12=3 (n-decimals, int) $13=0 (report inches, bool) $14=1 (auto start, bool) $15=0 (invert step enable, bool) $16=0 (hard limits, bool) $17=0 (homing cycle, bool) $18=0 (homing dir invert mask, int:00000000) $19=25.000 (homing feed, mm/min) $20=250.000 (homing seek, mm/min) $21=100 (homing debounce, msec) $22=1.000 (homing pull-off, mm) ok offensichtlich wird hier eine eigene/ältere grbl Version verwendet, oder ich bin auf dem Holzweg.. versuche mal z.B. $2=192 !! $100-102=100 $120-122=20.000 zu ändern, die anderen aber auch überprüfen und ggf. ändern. Viel Erfolg Herbert
Angehängte Dateien:
-
Steuerung_2.JPG
56 KB
Moin liebe SCC Gemeinde, wollte Euch ein Teil meiner neuen Fräse y 1200 x 1000 z ca.300 zeigen. Grüsse aus dem Norden der BRD Klaus
Hallo Herbert, danke nochmals, es funktioniert jetzt (siehe oben). Bin beim Feintuning Grüße
siegi schrieb: > danke nochmals, es funktioniert jetzt Hallo Siegi, freut mich und was dazu gelernt haben wir nebenbei auch noch. Viele Grüsse Herbert
Hallo,
hab noch ein wahrscheinlich triviales Problem, komme aber nicht drauf.
Die Drehrichtung des Fräsers lässt sich nicht umdrehen.
Habs in der CPU_MAP mit verschiedenen Zuweisungen probiert.
#ifdef VARIABLE_SPINDLE
#ifdef USE_SPINDLE_DIR_AS_ENABLE_PIN
// If enabled, spindle direction pin now used as spindle enable,
while PWM remains on D11.
#define SPINDLE_ENABLE_BIT 5 // Uno Digital Pin 13 (NOTE: D13
can't be pulled-high input due to LED.)
#else
#define SPINDLE_ENABLE_BIT 3 // Uno Digital Pin 11
#endif
#else
#define SPINDLE_ENABLE_BIT 4 // Uno Digital Pin 12
#endif
#ifndef USE_SPINDLE_DIR_AS_ENABLE_PIN
#define SPINDLE_DIRECTION_DDR DDRB
#define SPINDLE_DIRECTION_PORT PORTB
#define SPINDLE_DIRECTION_BIT 5 // Uno Digital Pin 13 (NOTE: D13
can't be pulled-high input due to LED.)
#endif
Viele Grüße
Siegi
Möglicherweise auch Pinbelegung? Deine HW wurde mit GRBL 0.8 ausgeliefert - also dafür gebaut. Ab GRBL 0.9 wurde die Pinbelegung Limit-Z / Spindle PWM vertauscht... https://github.com/gnea/grbl/wiki/Connecting-Grbl#grbls-pins Da würde ich mal nachforschen...
Angehängte Dateien:
-
Achse_X___Z-1.jpg
240 KB -
Achse_Z_m._Fraesmotor.jpg
210 KB -
Mass_Achse_X.jpg
230 KB -
Wagen_Achse_Y-1.jpg
230 KB -
Wagen_Achse_X-1.jpg
220 KB
Moin, hier noch ein paar Bilder von "CNC 77" schönen Sonntag Klaus
Angehängte Dateien:
-
Rohbau_1.jpg
230 KB -
Rohbau_2.jpg
240 KB -
Rohbau_3.jpg
200 KB
moin, und weiter geht es!!!
ist das ein Model oder, falls eine "Maschine" ist, was kann man damit machen und mit welcher zu erwartende Genaugigkeit?
ist kein Modell, Genauigkeit weis noch nicht
Hallo allemaal, Heeft iemand messchien al voor de nextion 2,4" al een file gemaakt? vriendelijke groet nonaak
Hallo Nonaka, Ik denk dat maar weinigen Nederlands kunnen spreken. Dus alstublieft in het Duits (goggel helpt vertalen) Het bestand Nextion is opgenomen in de installatiemap van seriële Com.
Hat sich Ulrich Albert eigentlich nun komplett aus seinem Projekt zurückgezogen ?
Hallo, könnte mir bitte jemand ein bisschen Starthilfe geben? Ich möchte meine Käsefräse nun doch umrüsten auf GRBL und wollte erst ein paar Trockenübungen machen. Ich habe per XLOADER meinen Nano mit dem beiliegenden Hex-File (grbl_v1.1f.20170131.hex) geflasht und bekomme auch nach dem Connect "Grbl 1.1f" im Monitor angezeigt. Wenn ich dann z.B. die Achsen bewegen möchte, wird der GCode im Monitor angezeigt, aber unter Graphic tut sich nichts. Dann habe ich noch einen EasyJob angelegt und wollte diesen als GCode mit "TestCode" abarbeiten lassen, geht auch nicht. Bleibt als "Busy" nach der ersten Zeile (G90) hängen, diese ist noch mit "ok" gekennzeichnet. Habe das Ganze auch mit einer älteren Version v2.5 und grbl_v1.1e probiert, mit gleichem Ergebnis. Ev. wichtig: Win 10. Hat vielleicht jemand einen Tipp für mich? Danke! Gruß Sebastian
Haste die Maskierung für die Schnittstelle umgestellt? Siehe auch vorherige Postings: "Vermutlich liegt dein Problem an eine GRBL Version < 1.1 auf dein Arduino Board. SerialComCNC benötigt GRBL Version >= 1.1, es muss zuerst GRBL Version >= 1.1 auf das Arduino Board geflasht werden. Wichtig danach die passende Einstellen von GRBL-Configuration. $3 Einstellun der Verfahrrichtung der X, Y und Z Achse. $10 Status Report Mask. Muss auf $10=0 gesetzt sein." Mal probieren... Gruß EGS
Danke EGS, nun bin ich schon mal etwas weiter. $10=0 und "set Feed" haben dann weitergeholfen. Es war etwas verwirrend, dass sich nichts getan hatte und auch keine Fehlermeldung kam. Gruß Sebastian
HI Sebastian, lies dir doch mal die Anleitung von SerialComCNC durch. Das steht vieles drin, was hier immer wieder nachgefragt wird. Nur so am Rande angemerkt... ;-) Gruß, Harald
Angehängte Dateien:
-
Oberflaeche.JPG
100 KB
Hallo Gemeinde! Ich habe mal eine Frage. Nach dem ich den Bau meiner "Käse Frässe" fertig habe bin ich auf das Programm SerialComCNC 2.5.1 gestossen, und habe damit seit geraumer Zeit herum experimentiert Auf meinen Arduino Nano habe ich Grbl 1.1f und Grbl 1.1e getestet aber überall das gleiche Problem. Alle Funktionen für die manuelle Steuerung funktionieren perfekt, aber wenn ich ein G-code lade und ab arbeiten möchte dann arbeitet das Programm die erste Code Zeile ab und bestätigt mit "OK" und dann passiert nichts mehr. Ein leider schlechtes Bild hänge ich mal an. Ich hoffe es kann mir jemand weiterhelfen. Tshüss Günter
ohne deinen G-code und ewt. Einstellungen deiner Setings für GRBL wird dir wohl keiner weiterhelfen können. Error Code? Gruß Wolfgang
Kennst Du den schon? $10 Status Report Mask. Muss auf $10=0 gesetzt sein.
Hallo Hat jemand von euch ein Nextion-Display in Verbindung mit SerialComCnc angeschlossen? Es kommt keine Verbindung zwischen SCC und den Nextion zustande. Ich kann zwar connecten, aber eine Bedienung ist nicht möglich. Ich muß noch dazu sagen, dass ich das Nextion-Projekt, welches original für ein 3,5' Display ist, auf mein 2,8'Display geändert habe. Ich bin mir aber ziemlich sicher, da keinen Fehler gemacht zu haben. Für Hilfe wäre ich sehr dankbar. MfG computerpap
Hallo Wolfgang,Hallo 123! Ich habe das Programm komplett zum Laufen bekommen, und der Tipp mit der einstellung $10=0 war genau richtig. Und siehe da beim nochmaligen durchlesen der Bedienanleitug stand es Fett geschrieben. Ich möchte hier auf diese weise auch mal den Autoren und Machern meinen Dank und Anerkennung zum Ausdruck bringen. Eine wirklich tolles Programm! Danke !! Günter F.
Hast du echt noch nicht mitgekriegt wie man direkt vom Bildschirm eine Ablichtung in ne Datei schreibt?
Hat sich geklärt, Problem saß direkt vorm PC!
After testing, the software does not support the Chinese windows system. The test discovery software seems to have a code for Chinese language kernel detection, and it detects the Chinese language and crashes. it is unclear how software developers implanted these codes，I'm sorry, this is my judgment
it is possible that the developer and owner wants to prevent reengeneering and using the software from chinese developers and companys for her own business.
Richard B. schrieb: > ? Wenn man des Englischen mächtig wäre und den kompletten Post gelesen hätte wäre klar: "Rückwärtsentwicklung und Nutzen für eigene Software oder Tools durch Chinesen soll eventuell verhindert werden..." MfG EGS, der letzte Woche wieder mit SCC gearbeitet hat...
EGS schrieb: > Wenn man des Englischen mächtig wäre und > den kompletten Post gelesen hätte wäre klar Wieso sagst du das gerade mir? Sein "Satz" ist voll mit Fehler.
Hallo, ich hätte eine Frage zu dem Programm SerialComcnc. Kann ich dieses auch mit dem Arduino Mega 2560 benutzen. Was für Treiber werden benötigt. Muss ich auf was besonderes achten. Vielen Dank
Einfach grbl auf deinen Mega laden (suche auf github nach passender Version ) und loslegen. SCC und alle anderen Gcode Sender senden nur den Code an grbl - egal worauf grbl läuft (Uno, Nano, etc.)
Hallo Sven, erst einmal vielen Dank für die Antwort. Ich habe mit X-Loader die Version 8c draufgespielt. Serialcomcnc erkennt den Port nicht an, bzw. nicht erkannt. Was tun?
$10=0 ist eine wichtige Einstellung die oft vergessen wird, aber ich denke es ist folgendes: Mit grbl 1.1 hat sich das Com-Protokoll geändert. SCC unterstützt nur noch 1.1 (denke ich). Du hast vermutlich Version 0.8. Versuche einen anderen Gcode Sender oder finde eine grbl 1.1 Version für deinen Mega. Der Gcode Sender GRBL-Plotter kann auch das alte Protokoll verstehen.
Hallo Sven, ich habe die Version 1.1 e drauf gespielt aber er erkennt es trotzdem nicht.
Siehst Du denn wenigstens die Grbl-Version im SCC nach Reset? Richtige Baudrate eingestellt? Sonst mal Alternativen ausprobieren.
Im Xloader sehe ich das er 30338 Bytes geladen hat mit eine Baudrate von 115200. Im Programm sage ich unter Serielles Interface Com 5, Baudrate 115200 und Connect und dann kommt die Meldung.
Oder sollte ich es mit einem anderen Programm machen? Wenn ja mit welchem
>..und dann kommt die Meldung
Welche?
Hast Du $10=0 gesetzt?
Info Comport oder nicht erkannt. Versuchen sie es nochmal.
sven schrieb: > https://github.com/svenhb/GRBL-Plotter Kann ich nur waermstens empfehlen - meine ehemalige Begeisterung fuer Serialcom ist schon lange verflogen. @Sven, bitte das gelbe Feld der Quasi-Joysticksteuerung mit sichtbaren Begrenzungen(Linien) zur Unterscheidung der einzelnen Segmente versehen. Man weiss nur durch Raten, wo die naechste Stufe beginnt. Danke dafuer.
@Nutzer: Danke für das Feedback >@Sven, bitte das gelbe Feld der Quasi-Joysticksteuerung mit sichtbaren >Begrenzungen(Linien) zur Unterscheidung der einzelnen Segmente versehen. Das war Anlass die versprochene Erweiterung (und Deinen Vorschlag) zu veröffentlichen.
Hi Sven, ich habe schon mal hier im Thread versucht, den Autor zu überreden, mit mir eine Kooperation in Sachen (echter) Joystick anzuleiern, das hat aber leider nicht geklappt. Konkret geht es um meine Entwicklung eines Hardware-Joystick - [[http://www.harald-sattler.de/html/body_joystick-steuerung.htm#Joysticks]] - für meine CNC-Fräse, der zwar tapfer Stepimpulse für die Motoren erzeugt, von denen aber der G-Code-Sender nichts mitbekommt, so dass die Nutzbarkeit im echten Betrieb sehr eingeschränkt ist. Besteht Interesse deinerseits, so einen Joystick in deine GUI einzubinden? Würde mich freuen. Die Kopplung zwischen Joystick und GUI müsste, wie bei GRBL, über eine serielle SS erfolgen, wobei ich Steps oder auch Entfernungen in mm ausgeben kann (oder ggf. auch etwas anderes, besser geeignetes). (Auch ich habe mich in letzter Zeit immer weiter von SCC abgewandt, da Ulrich (für mich nachvollziehbar und verständlicher Weise) andere Projekte vorzieht. Zur Zeit arbeite ich vorwiegend mit Martins OpenCNCPilot, nicht zuletzt, weil OCP das height mapping unterstützt, das ich für meine Schaltungen benötige)). Gruß, Harald
Hallo Bastler, ich bin gerade beim Bau der CNC Fräse mit der Proxxon MF70. Ich habe viel gelesen, ist ja auch nötig um es zu verstehen. Mein Problem ist eigentlich erst mal nur die bgrl Firmware aus den Adurino Nano zu bekommen. Ich mache es über den XLoader. Dieser ist ja bei der SerialComCNC dabei. Ich starte die Software mit dem File. Dann flackern kurz die LEDs (neben Betrieb die Rote und Grüne). Ab und zu flackert die Rote unten. Das Programm Xloader regiert nicht mehr (Alle Felder wie verkleinern, Info, Beenden) reagieren nicht. Die Anzeige unten ist "Uploading". Das Programm habe ich als Administrator ausgeführt. Nun meine Frage: Wie lange dauert das Upload und was sollten die LEDs machen? Mache ich evtl. was falsch. Vielen Dank im Voraus. Gruß Uwe
sven schrieb: > Das war Anlass die versprochene Erweiterung (und Deinen Vorschlag) zu > veröffentlichen. Danke sehr, Sven. Meine Unterstuetzung habe ich bereits vor einiger Zeit an deine PP-Adresse geschickt. Weiter so