I’ve just completed a GRBL controlled (1.1h gnea with Uno) laser diode cutter specifically for balsa. After lots of problem solving, it is working well. The laser is housed in a box, with good extraction, a camera, and cooling.
To improve safety I fitted a microswitch to the lid, the intention being for the job to pause when the lid is open and resume once closed again.
My firmware $32 is set to 1 so it is running in laser mode.
The config file has been changed. ENABLE_SAFETY_DOOR_INPUT_PIN has been uncommented and the code recompiled.
The microswitch has the common pin going to ground. NO (normally open) is wired to A1 the feed hold pin. NC (normally closed) is wired to A2 the resume pin. Therefore when the lid is closed, A1 is pulled to ground whilst A2 is high ensuring the job continues. However, when the lid is open, A1 is high and A2 low, pausing the job.
Pressing the microswitch changes the status on Universal GCode Sender to IDLE, releasing it (lid up) changes it to DOOR. All working as expected. This proves the microswitch wiring is correct and the config changes.
When running a job, opening the door does pause the job and the laser switches off; perfect. However when shutting the lid, the job restarts, but the laser does not switch on again.
The laser power is controlled by a transistor. This is switched from the SpinDr pin on the Arduino shield. I’ve had a multimeter on that and it remains high suggesting that the laser is not receiving PWM after the restart.
I’ve trawled the internet and reached out for help without success. Has anyone wired a safety door switch when running a laser and if so did it work for them? Does anyone have any pointers or advice.
It would be the cherry on the cake to get this working.
I don’t use a door, so can’t speak from direct experience. It sounds, from my recent readings, that by default there should be a 4 second delay before the machine starts to move again once the feed hold (i.e. machine motion pause) is released. This is supposedly to allow the spindle to come back up to speed if it was stopped. Does that delay give you time to hit M3 (to re-enable the “spindle”)?
Again, my reading indicates that “door open” usually means either “freeze the machine where it is” or “park the machine” (by either raising Z to a preset height or raising Z then moving to predefined X Y parking coordinates), but including spindle behavior is much less standardized, so explicit behavior for it is not included in default configurations.
Is it common to wire the switch legs to both the pause and resume pins? I thought the door feature was smart enough to release the feed hold when the state of the door switch changed back to the “closed” state.
It may be possible to recompile grbl with different door behavior, but I’d think you would have seen that in control.h when you were setting your current configuration up. Again I haven’t looked into this for my implementation since I don’t have a door.
Thanks for chipping in Tom, your points are much appreciated.
Chamnit the custodian of GNEA/GRBL says on github “The safety door will disable the spindle and coolant outputs and will only allow you to resume via ‘~’ once the switch is closed. It’ll repower the spindle and coolant after a configurable dwell before resuming the program.”
However config.h comments suggest a different behaviour “This option causes the feed hold input to act as a safety door switch. A safety door, when triggered, immediately forces a feed hold and then safely de-energizes the machine. Resuming is blocked until the safety door is re-engaged. When it is, Grbl will re-energize the machine and then resume on the previous tool path, as if nothing happened”.
No mention of a resume being required.
The reason I have both switch legs wired is that making A2 go high is the same as sending a ‘~’ command to resume the job.
Interestingly, if I press the pause button in Universal GCode Sender during a job, it pauses exactly as when the door is opened. Then when I press the play button it resumes, however once again with no laser. That points towards it being a software fault rather than hardware switches and wiring.
I assume, because $G32 is set to 1 (laser mode) the behaviour of invoking feed hold is different i.e, raise Z and move X, Y to predefined park coordinates. You raise an interesting point about the 4 second delay to allow the spindle to get up to speed, In laser mode, I’m not seeing that 4 second delay at all, as soon as the switch goes normally closed, cancelling the feed hold the gantry start to move. However looking in config.h I notice the following
“// After the safety door switch has been toggled and restored, this setting sets the power-up delay
// between restoring the spindle and coolant and resuming the cycle. #define SAFETY_DOOR_SPINDLE_DELAY 4.0 // Float (seconds) #define SAFETY_DOOR_COOLANT_DELAY 1.0 // Float (seconds)”
It might be worth me changing the spindle delay down to 0, on the off chance it makes a difference, however I’m not seeing a 4 second delay on resume so suspect this is ignored by the code if laser mode is set in firmware. Feels like clutching at straws.
If nobody here has used a safety door with a laser, I might be walking down an unknown path.
I’m certainly no expert in the grbl source code, but I suggest trying $32=0 as a test. If the 4 second pause comes back and the laser fires again when the ~ is sent (the door is closed) then that points to there being something in the laser mode code that’s not honoring the pause and resume settings or otherwise impacting their expected behavior. Then you could file a bug report with the grbl project.
I’m not sure that will work. Laser mode swaps pins about, using D13 for the laser, because they needed to use PWM. Switching laser mode off will still result in the laser never switching on at all so the test won’t tell me anything.
I might have a strong coffee and take a look at the GRBL code, but it will be quite a task. No further responses does suggest nobody has done this before. I did put a post on the GRBL forum on github but Chamnit does not seem to be active at the moment.
I though the PWM pin mapping change was part of a grbl version (1.1g??) update, not related to laser mode. On my MPCNC I’ve got a variable speed spindle (so laser mode is not enabled) that uses PWM and is plugged into the “Z end stop” in of my CNC Shield 3.00 controller, which I believe is mapped to D13 on the arduino uno. This is the same pin the laser is connected to on my K40 which is running the same controller and grbl version, with laser mode enabled.
My understanding is that laser mode does automatic PWM intensity reduction aligned with velocity slowdowns so corners don’t get burned, and removes “ramp up” times since laser intensity changes are instantaneous whereas spindles take time to speed up/slow down due to rotational inertia. It’s this removal of ramp up times that I though might be related to the issue you’ve described.
You could be right. I thought it was changing to laser mode that swapped the pins.
This build has been a long, challenging one. At one stage I’d built my box, affixed the rails, installed GRBL and was memorised moving the gantry back and forth. Universal GCode sender has a really good machine setup wizard that took me through each step, including getting the physical end stop setup correctly. All was working fine, until I changed $G32=1 for laser mode. At that point my Z end stop no longer worked. The setup wizard confirmed this. All the wiring and optocouplers were fine. After a lot of head scratching I used the philosophy that the last change broke it. The internet pointed me to moving the Z end stop wire to D12. D11 then came available for the laser PWM. D13 which does not use PWM, was then used with a MOSFET to turn on the 12 volt supply to the laser.
I therefore thought it was the changing to laser mode that remapped the pins.
With 1.1g, config.h has a new command of #DEFINE VARIABLE_SPINDLE which did swap D13 to D11. If you were using D11 for an endstop prior to 1.1g, your spindle would suddenly crash unless you swapped endstop with spindle or commented out the line.
Sure I read somewhere that this line has to be commented out for laser mode, but when I tried that, it failed to compile. That suggests you are right and perhaps I have something wrong in my configuration.
It’s all a bit vague now. I might do a simple prototype from scratch on the bench, to try out your suggestion. I’m away this weekend so will have time to do some more reading.
Thanks for you help Tom. Really appreciated. Hope I can help you out sometime.
Thanks for all your help and ideas. Well I did some reading over the weekend and can see nothing to back up my zany idea that setting laser mode remapped pins.
I did the test you suggested, changed $32=0 and ran a job again. When releasing the door microswitch the job stopped and the laser switched off. When depressing the microswitch again, the laser came on instantly, however it did not move for 4 seconds. That seems to be correct behaviour, it waited 4 seconds for the spindle to come back up to speed before continuing.
It looks like the code for milling operations works fine, however in laser mode it does not. In laser mode it ignores the 4 second spin up time, and starts moving the laser head instantly, which is ideal, however it does not switch the laser on.
Disconnecting A1 and A2 from the microswitch and returning to laser mode, I tried to pause the job ‘!’ and resume ‘~’ it through Universal GCode Sender. This should send a ‘!’ to pause it and a ‘~’ to restart it again. When paused the head slows down to a stop and then the laser switches off (perfect), When you resume it again, the head starts to move but the laser does not go on again. Identical behaviour to the microswitch.
However if you take it out of laser mode and repeat the exercise, on pausing through UGS the head stops, but the laser remains on (i.e. the spindle remains at speed), when you resume, the head moves on again with the laser on i.e. the spindle that has not stopped continues to cut into the work. Slightly different behaviour which suggests UGS is doing something else, however a good outcome if you are using a spindle.
I’ve posted in 3 forums asking if anyone has this working and not had anyone reporting that it works for them using a laser.
The conclusion I’m regrettably drawing from this is that Gnea\GBRL has a defect in this area. I’d be delighted for anyone to suggest my conclusion is wrong and point me in the right direction. This is a worthwhile safety feature to have.
In desperation, I’ve looked at the code but don’t really have the understanding to make a sensible judgement.
I think it happens here in the protocol C file.
// Delayed Tasks: Restart spindle and coolant, delay to power-up, then resume cycle.
if (gc_state.modal.spindle != SPINDLE_DISABLE) {
// Block if safety door re-opened during prior restore actions.
if (bit_isfalse(sys.suspend,SUSPEND_RESTART_RETRACT)) { if (bit_istrue(settings.flags,BITFLAG_LASER_MODE)) {
// When in laser mode, ignore spindle spin-up delay. Set to turn on laser when cycle starts. bit_true(sys.step_control, STEP_CONTROL_UPDATE_SPINDLE_PWM);
} else {
spindle_set_state((restore_condition & (PL_COND_FLAG_SPINDLE_CW | PL_COND_FLAG_SPINDLE_CCW)), restore_spindle_speed);
delay_sec(SAFETY_DOOR_SPINDLE_DELAY, DELAY_MODE_SYS_SUSPEND);
}
}
}
Have you filed an issue on the GitHub for grbl/gnea? It sounds like you’ve got a detailed enough description that someone appropriately conversant with the code should be able to find the root of the problem. I’ve never submitted, so don’t know the specific steps there.
I think it is very telling that things “work as expected” under $32=0, but that the laser doesn’t come back under $32=1. I would think that would steer toward the code that manages $32=1 behavior.
I raised it as an issue, two weeks ago without a response. In fact the entire forum seems to have long term reported issues with no response and Chamnit has not posted anything in the last year. 1.1h came out nearly 4 years. Think I read somewhere that Chamnit was concentrating on porting the code to run using the ARM processor,
I will continue to monitor, hope that someone pops up with an answer and may take a deep dive into the code in a bid to understand it.
FYI, Grbl has been ported to a Teensy and other ARM boards by various users but they are not up-to-date with the main repo nor will they give you much more performance since the Arduino Uno’s Avr does fine (I’m the lead developer of Grbl). You’ll only get extra flash and ram to install your own peripherals, and a higher max step frequency. That’s about it.
FWIW, I’m working on a next-gen Grbl on a 32-bit ARM that will take advantage of the extra power. Its a total overhaul of the system and will include a lot more functionality. I’m still going to make sure to pack in as much as I can into Grbl on the Arduino Uno though so that everyone can CNC with a good powerful compact firmware.
I guess not much is happening now with the UNO repo.