The nature of Grbl and m3/m4/m5

Software / Firmware
1

Hi,

There were a few similar threads, but they were old, so etiquette wise, not sure if I could just reply or I would be called a necromancer. :slight_smile:

Some of you have either been using GrBL or are starting to, thought I mention this:

Have upi ever found your laser is not drawing the first few cm of a box or is going past the edge when filling? Had a drawbot lazily scawl across the page when it should have lifted the pen?

I ran into this with both my laser and drawbot, and found a delay is required in the gcode for just about everything to do with m3/m4/m5 in Grbl. It is 10 times more obvious with a pen as the pen skids on landing and takeoff. Not only is a delay required, but not always the same delay, if you send a long sequence of g1 moves or arcs it will be busy processing them for a bit, changing the nature of the problem, either hiding the need for a delay or requiring a larger one. If you put in a large delay, your drawing takes forever, if it is too short some things will be fine, but others not. Last I looked, the J-Tech inkscape plugin had a delay in there but the gcode was only putting it at the beginning of an m3 or something, not after m5s, it was only via writing my own code that I learned about needing more delays, but it turns out you can only get within hand grenade distance, which is ok for most things, the corner cases will stump you, unless you are doing gcode by hand or fine tuning it based on the actual hardware speeds you will land on a frustating problem eventually. That is probably why cam software requires blood sacrifices to own.

I decided on it’s the async nature of Grbl, or software vs hardware, you send a g1 command to go somewhere and it returns immediately, it doesn’t wait for all the electronics and motors to atart or stop. Same with laser power and pen actuator commands, you tell it to lower a pen, then move, the firmware reads the code, sets the hardware to do it’s thing and goes to the next thing, it doesn’t wait for the hardware to actually do it. So as your pen is lowering (or cheap china laser is getting ready to turn on) the firmware went ahead and told the motors to move, hence the gap, this also causes issues raising the pen (or turning off laser), it starts to go up but since it is under pressure (rubber band) it doesn’t immediately leave the surface and the motors happily drag it along.

Thought I’d mention my thoughts on it, it doesn’t come up much in regular conversation. :slight_smile:

Cheers!

2

Grbl defaults to including a pause on tool start/stop or rpm changes so the spindle gets to the desired speed. If you’re using a laser, you can disable the delay with $32=1, called enabling laser mode.
Not surprisingly, $32=0 turns the delay back on.

3

This is very true for Grbl versions 1.1f and later. No laser mode for earlier versions.

4

You would think, Aliexpress, a few years ago now for me, was totally averse to selling anything with 1.1f it seemed, probably still are for all I know, there was a larger code break going from 0.92 if I recall correctly, so a lag in support is understandable, especially if English is not familiar, yet laser support was bolted on, in whatever way they could I guess. I never knew what changes were done to the firmware, I still have 0.92 on my drawbot, no idea what pins are used for input output or what mods was enabled for the novel pully movement system, but it works, so I didn’t try to upgrade it.

Turn laser support off isn’t intuitive when trying to troubleshoot lasers, but I am pretty sure I tried everything, including $32=0 and 1.1f on the laser before it blew up.

Cheers!