bin der neue, Guido, 46 aus Petershagen / NRW. Komme eigentlich aus der Showlaserecke wo ich meine eigene Software hab.
Die Langeweile trieb mir besagten China-Lasergravierer in die Arme. Bei dem Ding hängt die Laserdiode am PWM Spindelausgang.
Beim connecten per Software oder Terminalprogramm geht der Laser für 1sec auf Vollgas, kurz bevor die Startmeldung "grbl v.1.1 . . " kommt.
Das ist natürlich nicht nur nervig sondern auch nicht ungefährlich. Also mal den Code gesaugt, lässt sich auch per Arduino "IDE" wenn man das mal so nennen will kompilieren und flashen.
In der main.c findet mal auch kurz vor der Startmeldungsausgabe die Initalisierung der PWM. Hab die dann mal an den Anfang der main.c verschoben und einen Stop - Aufruf gleich dahinter geknallt.
Ich befürchte das der kleine 328p VOR der Main noch irgend einen anderen Blödsinn veranstaltet. Finde es aber nicht. In "richtigen" IDE´s geht's wirklich in der Main los.
Da ich auch noch keine Software gefunden hab die das macht was ich möchte hab ich da auch mal angefangen.. GCode abspielen geht, manuell verfahren, Laser auf 1% um den Nullpunkt anzufahren ohne das Werkstück zu verkokeln, PLT lesen und direkt gravieren. Projekte anhalten / fortsetzen,....
Also: Nutzt noch jemand hier gbrl zum Lasern und kennt das Problem und weiss mehr als ich vom Ablauf im Arduino ?
das ist der Bootloader des Arduino/Atmega. Der wartet eine Weile auf uart befehle bevor er die applikation startet. Wenn Du die entsprechende Fuse abschaltest, startet er direkt in die Applikation. Du kannst dann allerdings nicht mehr über Seriell die Software flashen und kommst nur noch über ISP dran. Das brauchst du allerdings ja zum setzen der Fuse sowiso.
Alternativ könntest Du den PWM Ausgang per Hardware invertieren oder mit einem Laserfreigabeschalter verunden.
es ist auch möglich durch Pull Up / Down Widerstände an den Ausgängen des Arduinos einen Definierten Zustand herzustellen, bis der Arduino das Programm gestartet hat, und z.b. seine eigenen internen Pull Up Widerstände zugeschaltet hat.
Mit externen Externen Pull Up Widerständen, kann man dann aber auch auf die internen Pull Up Widerstände verzichten.
Ist vielleicht minimal mehr Arbeit durch die externe beschaltung, aber sicherer weil es keine undefinierten zustände mehr an den ausgängen gibt, wenn der Arduino startet, einen Reset macht oder anderweitig sich irgendwie aufhängen sollte.
@cali: Das hilft nur für die undefinierten Zustände beim anschwingen. Während der Bootloader aktiv ist, befindet sich der Atmega im regulären Betrieb. Da hängt es vom Bootloader ab was am Port anliegt. In den meisten fällen wird er die nichtbenötigten Ports auf Eingang konfiguriert lassen, so dass ein Pulldown da hilft. Wenn der aber ausgrechnet den PWM Pin als Ausgang schaltet und auf 1 setzt, richtet ein Pulldown da nichts mehr aus. Darf er ja auch nicht, da das dann im normalen Programm auch nicht gehen würde. Immer vorrausgesetzt der Laser ist bei Low auf der PWM Leitung aus.
diese "undefinierten" Portzustände treten beim starten des Prozessors auf. Solange, bis der Prozessor selber seinen Microcode zum initialisieren durchgeführt hat. Ob der Bootloader dann tatsächlich am PWM-Ausgang (D11) was rumfummelt, kann ich nicht sagen.
Auf jeden Fall sind die meisten Laser-PWM Ausgänge 'active low' verwendet. Das ist auch der Fall bei dem /ENABLE Signal für die Treiberbausteine der Schrittmotoren. Einige Schaltungen sehen daher einen Pull-Up Widerstand für genau diesen Zweck vor. Damit die Motoren während der Initialisiertungsphase nicht undefiniert los laufen.
Auf jeden Fall kann ich nur Empfehlen, den PWM wirklich schaltbar zu machen. Entweder per manuellem Schalter oder mit einem MOSFET und einem weiteren Arduino-Pin den MOSFET nach der Initialisierung und kurz vor dem Lasern zu schalten. Z.B. mit dem Pin A3 (coolant) der dann auch einfach über den GRBL-Code geschaltet werden kann. Und dann auch gleich eine Wasserpumpe (bei CO² Lasern) einschalten kann.
das war mir neu, das auch durch den Bootloader irgendwelche Aktivitäten ausgelöst werden, die zu ungewollten Pegeländerungen führen.
Danach werde ich bei Gelegenheit mal gezielt suchen, da ich derzeit an einem doch etwas größerem Arduinoprojekt sitze und ein derartiges Verhalten absolut nicht gebrauchen kann.
Wenn du nähere Infos zu dem Problem hast, würde ich mich über einen Link freuen, danke.
Einen Laser würde ich vermutlich mit einem Schlüsselschalter absichern, wenn andere Personen zugang haben sollten und über Schalter das der Laser nur eingeschaltet werden kann, wenn das Gehäuse geschloßen ist, Kühlung und eventuell eine Absauganlage läuft.
das ist nicht direkt ein bekanntes Problem. Aber was der Bootloader macht, bestimmt der Programmierer des Bootloaders. Es hängt also davon ab welcher bootloader verwendet wird. Die Arduino Bootloader sind vermutlich als Quellcode verfügbar, da kann man dann sehen was die genau machen. Prinzipiell kann ein Bootloader jeden Portpin kontrollieren. Ob er das tut steht auf einem anderen Blatt.
Wenn Du entsprechende Probleme suchst, und der bootloader verdächtigst, kannst du testweise ja den Bootloader deaktivieren. Das geht soweit ich weiss nur über die ISP schnittstelle. Am komfortabelsten mit einem AVRISP MK II und dem AtmelStudio, günstiger mit einem USB ASP und passenden Tools wie PonyProg oder ggf. auch der Arduino IDE.
Beim Atmega 328 der auf den Arduinos sitzt ist für den Bootloader die BOOTRST fuse zuständig.
das mit dem Bootloader mit ein "Schlag vor den Kopf mit einer Gerüstbohle"
Controller sind mir seit 8051 Assembler nicht fremd. Bin aber mit dem AVR Studio und Keil groß geworden. Quer durch die AVR Familie bis zu Sam3x / 4x und M0. Gearbeitet aber mit IDE´s die Ihren Namen auch verdienen :-) Nix AVR ISP, JTAG Ice mit Debugger bitte bzw. Ulink Pro. Ein Bootloader hat eigentlich ausser mit dem UART nix am Hut mit externen Pins. Sollte er zumindestens :-) Einen seriellen Bootloader würde ich nicht in die Warteschleife schicken sondern auf eine Handshakeleitung horchen lassen.
Das war meine erste Berührung mit Arduino ausser ein paar flüchtigen Blicken. Würde jedem der sich mit Controllern beschäftigen muss davon abraten. So viele schöne fertige Libs machen das Leben auf den ersten Blick einfacher, aber wenn man einfach mal Datenblätter liesst versteht man den Blödsinn der da passiert.
Der kleine 328 wird sich auch sicher schnell in die Hose machen wenn man BMPs in Graustufen gravieren möchte und mal ne richtige Hand voll GCode reinjagt. Ab einer Min Speed wird's zum Überlauf kommen.
Wie gesagt, es "stinkt" nach Bootloader. Also ISP rauslegen und tot das Ding. Melde mich zu dem Thema.
Grundsätzliches zum Bootloader: Wenn die BOOTRST fuse gesetzt ist, springt der Atmega nach dem einschalten in einen speziellen Speicherbereich und führt den dort plazierten programmcode(bootloader) aus. Beim Arduino wartet dann der bootloader ca. 1s auf kommandos von der seriellen Schnittstelle um bequem über die serielle schnittstelle eine neue firmware auf den atmega laden zu können, wenn das gewünscht ist. In deser zeit belässt er (sehr warscheinlich) die Ports im initialisierungszustand. Sie sind dann als Eingang geschaltet. Am PWM pin hängt dann der PWM eingang des Lasers. Zwei eingänge zusammen sind was den zustand angeht nicht wirklich definiert. Wenn der Laser active low gesteuert ist und in dieser zeit voll an ist, liegt es nahe dass der hochohmige zustand am Atmega Pin als low = aktiv interpretiert wird. Passiert in der einen sekunde nichts, wird der bootloader beendet und das reguläre programm, in dem Fall grbl startet. Hier wird dann der PWM Pin entsprechend als Ausgang geschaltet und nimmt einen definierten Zustand an und der Laser geht aus.
Daraus ergeben sich mehrere ansätze das problem anzugehen: Bootloader abschalten (GRBL updates nur noch über ISP, GRBL startet sofort, undefiniert nur noch während der atmega startet ca. 100ms) Bootloader modifizieren so dass der Port schon dort korrekt konfiguriert wird Portpin mit Pullup versehen (bei aktiv low laser) Portpin extern mit schaltsignal verunden.
Anmelden
