Resume does not switch laser back on

I've recently completed a DIY laser cutter specifically for balsa, using a laser diode, GRBL v1.1h and Universal Gcode Sender.

The laser is enclosed in a box, with good cooling, extraction and air assist.

For safety, I installed a microswitch on the lid, so that if opened when a job was running, it would pause the job, switch off the laser, and then upon shutting it again, the job would resume from that point. The microswitch pulls either A1 or A2 to ground.

When opening the lid, all movements stop and the laser switches off, allowing me to check the work. When the lid is closed again, the job continues, however the laser remains off.
I've now tried it with the play and pause buttons within UGS and get the same results.

Is this a known GRBL issue or do I need to make a configuration change somewhere?

Thanks in advance

Howard

 

Ah, looks like I have fallen upon the wrong feature. Thanks Peter, will give that a go.

 

Hi Peter, or anyone else.

Have tried the door sensor but am getting a similar issue. I must be doing something wrong.

ENABLE_SAFETY_DOOR_INPUT_PIN was uncommented within the config.h file, recompiled and uploaded to the Arduino Uno R3 (not a clone). The microswitch was altered, drawing pin A1 to ground when the lid is shut (Normally Open). The wire to resume was removed from A2.

When the device powers on with door open, everything is normal.
Trying to home results in an alarm. Unexpected but OK.
Close lid and machine homes.
Start job with lid closed and everything fine.
Open lid, job stops, laser is off and status in UGS is 'DOOR'. All good.
Close lid, job does not restart
Press play button on UGS and job restarts but laser is not on.

Tried connecting A2 to normally closed on the same microswitch and now it automatically flicks between IDLE and DOOR, with the job restarting but still no laser.

The SpinDr pin goes to a transistor controlling 12 volts to the laser. Putting a multimeter to this pin, shows it is high when the job restarts, that does not appear to the problem, it seems like PWM is not going to the laser.
Looked but can't find a solution; am I missing an action on the restart? Scoured the internet but can't see anything obvious.

Is this working for anyone else?

Thanks in advance

Howard

 

Done lots of reading and can't see where I've gone wrong.

Have tried an experiment by disconnecting both A1 and A2, taking the physical lid switch out of action. With the lid switch no longer operational, I started a job with the lid open. The laser was on and everything working as normal. During the job, I clicked the pause button in Universal GCode Sender and the job stopped, the laser switching off as the head stopped.
However when I pressed the Start button on Universal GCode Sender, the job restarted but the laser did not switch on.

To me, that suggests it's not the wiring of the switch because taking it out of the scenario it still fails. I've checked and double checked the config.h file and all appears correct. The fact that when the lid switch was wired up, Universal GCode Sender reported a DOOR alarm when the lid was open suggests the config.h file setting is correct.

It's a bit of a jump, especially for someone who is new to GRBL and just feeling their way, but I'm wondering if it is a bug with 1.1h. Is there anyone out there who has used this with a laser?

Thanks in advance

Howard

 

Thanks

I'm on a PI 4, is that supported now?

 

Thanks Peter

My GRBL firmware file has: -
$32 = 1 (Laser-mode enable, boolean)

The config file has ENABLE_SAFETY_DOOR_INPUT_PIN uncommented

// 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.
#define ENABLE_SAFETY_DOOR_INPUT_PIN // Default disabled.

Below is the Gcode I was using to test this, it shows M4.

; LightBurn 1.4.00
; GRBL device profile, current position
; Bounds: X-79 Y-86 to X0 Y0
G00 G17 G40 G21 G54
G91
M4
; Cut @ 1000 mm/min, 1% power
M9
G0 X0Y0
; Layer C03
G1 Y-86S1F1100
G1 X-79
G1 Y86
G1 X79
M9
G1 S0
M5
; return to starting pos
G0 X0Y0
M2

Chamnit states on git hub How does the "Safety Door" features work? · Issue #713 · grbl/grbl

You need to enable it in config.h and it'll use the feed hold pin. It assumes normally-open switches connected to ground, but you can use normally-closed connected to ground with the INVERT_CONTROL_PIN compile option.

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.

I fell upon UGS, which does not allow you to send '!' and '~' via the commands line. However it's supposed to be possible to do this by allowing A2 to go high. That's how I've got this configured in hardware, the microswitch has three terminals, one is common which goes to ground. It has a normally open pin which is wired to A1; normally closed is wired to A2. Therefore when the lid is shut, the switch is closed so A1 is pulled low to ground, whilst at the same time A2 goes high which allows the job to start.
UGS correctly changes its status from IDLE when the switch is down and DOOR when it is up. That seems to confirm that the switch is wired correctly and config.h changes are correct.

I'm a bit short on hardware but will try to find a windows machine from somewhere and load Openbuilds control on it. I assume that will allow me to test out the '~' command to resume a job? However as UGS has a Play and Pause button, and the pause button has the same behaviour as using A2 (restarts the job without laser) I suspect it will be the same.
It would be good to have a safety switch.

Thanks for all your help.

Howard