Mike, yeah I just verified with the oscope and resistor… d44 goes high on reboot. So this must be one of those things Chamnit was referring to.
On another note, I ran into a bug in grblmega5x that breaks pausing an M4 cut. An issue is already posted, but does not appear to be any PR for it. Seems simple, since M4 files aren’t calling M3 all the time, using M5 for pause won’t work. It needs to do something like send a G91G0X0Y0 for safety when pausing from M4 I think… or use M4 when restarting a laser cut. I saw some info related to running both laser and router at the same time… sounds like getting cam pp to handle the $32 is not going to be possible anyways… so the latter solution may be no go. The former solution I don’t think would work when using M3 though.
I know the dev is busy, but I am not sure I have the skills to handle this one. Anyone else looking into this?
On a related note, I think the same bug exists with flood and restarts… or at least in testing I don’t remember my flood turning back on either.
I found what so far has been a reliable workaround for this. I commented out #define DISABLE_LASER_DURING_HOLD in config.h, and now resuming a paused laser job works. I have played with it a bit pausing in many different scenarios (middle of a large laser on move, near several small mixed moves, etc), and the laser turned itself off during pause every time. Better yet, the laser also now turns itself back on after a pause.
This just allowed me to get 2hrs ahead on an etch before I went to bed last night. I continued it when I woke up this morning. I don’t normally babysit my cnc, but I am not quite to the point where I’m comfy sleeping while it is working.
I am late to the party, but I am using the mainline grbl5x, and originally my laser was not shutting off using the default spindle pin. I chnaged it to use the D6 pin ( #define SPINDLE_PWM_ON_D6) and that fixed my issues. This only works if your laser supports a 5v pwm signal.
Good post Dan. I also recognized the latest code on the “most official” grblmega5x has options to configure pwm on d6 or d8. It has a few other changes to the pinout from the older version I am using right now (aka enducross grblmega5x). Since all else is working well I have not ported my config to the latest grblmega5x. I likely won’t ever either, since I am currently in the process of upgrading to grbl esp32 anyways. However for those working with ramps, using the latest grblmega5x w/ the d6/d8 options is the way to go… d8 for a fet, or d6 for ttl.
I have just ordered a Two Trees K30 laser module and will be using a Uno board and a CNC shield with GRBL 1.1h.
Does anyone know if this laser module has the same problem?
I can’t speak to that laser module, but depending on the version of the CNC shield board, you may need to swap the Z endstop and SpindleEnable pins to get PWM control on the spindle.
I know I’ve had to do this on my CNC Sheld v3.00 boards, one on my K40 laser and one on my MPCNC. I don’t know if/when the board design was updated to match the pin swap that was done in the grbl configuration.
Thanks for the reply Tom.
When I didn’t get a speedy reply I did some heavy research and found the solution.
I am using the older version 3 CNC shield that has Z+ swapped to use PWM. A change in the GRBL 1.1h config.h file on line 339 to rem it out fixes the problem and makes Z+ usable again for the limit pin, and the PWM for the laser is automatically moved to spind EN
line 339 // #define VARIABLE_SPINDLE // Default enabled. Comment to disable.
To be clear, what I’ve done on mine is to plug the Z endstop to what’s marked on the board as SpinEn, and the PWM pin on the Z endstop. Versions of grbl after 0.9i (I think, not 100% sure of the letter) swapped these pins to allow for PWM spindle control.
The pins are properly assigned in the firmware, it’s just that the silkscreen on the boards doesn’t match what the pins are doing. Another example of this is the endstops - the shield provides 2 points to attach separate switches even though they end up connected to the same Arduino pin (per axis). The firmware interprets “min” or “max” based on the direction it knows the axis is moving.
