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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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,
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
Hallo Harald, ich denke das einfachste wäre, wenn dein Joystick Gcode sendet, welcher einfach durchgereicht wird (sofern nicht gerade Code gestreamt wird ). Ansonsten ist ja der Support für ein Gamepad eingebaut. @Nutzer - vielen Dank
sven schrieb: > wenn dein Joystick Gcode sendet Hi Sven, mhmm, das muss ich erst mal sich setzen lassen... Das habe ich schon mal über den zweiten COM-Port in SCC probiert, habe aber nicht geschafft, schnell genug die Queues für drei Achsen zu füllen, so dass die Stepper durchlaufen. Dabei hat aber möglicherweise das von SCC für das Nextion-Display aufgezwungene Protokoll gehemmt. Prinzipiell könnte dein GRBL-Plotter solche Jog-Befehle also durchreichen? Das wäre dann ja schon mal ein Ansatz. Gruß, Harald
>Prinzipiell könnte dein GRBL-Plotter solche Jog->Befehle also durchreichen?
Natürlich muss ich das auch erst einbauen.
Es scheint mir die universellste Lösung zu sein.
Allerdings solltest Du dann nur die speziellen Jog-Befehle senden.
Ok, dann setze ich mich die Tage da vielleicht mal ran... Wenn du diese Funktionalität nicht ohnehin für etwas anderes benötigst, unternimm erst mal nichts, ich gebe dir Bescheid, wenn ich soweit bin (bzw. sein sollte - immerhin habe ich es schon mal nicht geschafft ;-) Gibt es eine passende Platform für dieses Vorhaben? Wir sollten nicht Ulrichs Thread damit zuspammen, meine ich. Vielleicht öffne ich ein Issue auf Github? Gruß, Harald
>Vielleicht öffne ich ein Issue auf Github?
Ja, das wäre die richtige Plattform
Zuerst meine Gratulation an den Author des Programms - eine tolle Sache Mein Beitrag: Verbindungspbrobleme- Abbruch der COM-Verbindung. Mein Betriebssystem: WIN 10 Professinal/ 64 bit SerialComCNC 2.5.1 Nach Abschalten der FIFO-Puffers in den erweiterten Anschlusseinstellungen meines Arduino UNO (Atmeg328) funktioniert die Software jetzt einwandfrei. Vielleicht kann dieser Input jemanden weiter helfen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.