Hi all - not sure if this has been answered, I am no electrical engineer but I’m looking for advice from anyone who’s successfully added a door interlock to a Shapeoko (5 / 5 Pro / HDM etc.).
We’re building an enclosure around the machine for a small-batch production cell, the cell will need to be opened constantly between fast moving operations so we want the CNC to be safely inhibited when the door is opened (spindle stops + motion stops, and it requires a manual reset before resuming).
Mostly looking to just see if this is possible at this point and how challenging it is.
EDIT: From what I can see so far there is a ‘power pendant’ that allows for stopping and pausing of the machine. I don’t see why an interlock can’t be added on the ‘pause’ line of the power pendant. Any comments on this?
We’re in the UK if that affects wiring norms/RCD behaviour, but happy to follow any proven approach.
From previous posts over the years(and that the Nomad is equipped with an interlocked door from my understanding), I do believe this can be accomplished fairly easily - but I do not have the latest motion controller PCB to reference.
There are also plenty of other threads on the forum if you do a search. With the recent release of the remote pendant, the way the controller handles Feedhold may be different from what people found 5+ years ago.
Looks like the 5.1 Pro has dual Y axis homing. You need to confirm with C3D what the Feedhold actually does, since on most machines with Dual Y axis homing, feedhold does not stop the spindle.
The feed hold requires a resume button to be click med in the screen and does not stop the spindle.
The only thing that coms to mind would be a relay that shuts off if your spindle is commanded on and your door switch is open. You could use this to kill power the the machine. But would have to restart machine if tripped.
Keep in mind these aren’t industrial machines with 1k ipm rapids. They don’t move that fast.
Thanks for your responses. It sounds like on the 5.1 Pro, Feedhold / Pause stops motion but may not stop the spindle, so using the pendant pause line alone wouldn’t be enough for a proper enclosure interlock.
Has anyone with a Shapeoko 5 / 5 Pro / 5.1 Pro actually set up a door interlock that stops both:
machine motion
spindle run
If so, was the solution:
Feedhold / Pause for motion, plus
a separate relay / VFD inhibit / contactor for the spindle?
Particularly interested in anyone using the 220 V spindle / VFD. I’d like to know what was actually wired, and how restart behaved after the interlock tripped.
We’ve got a workplace requirement to have the machine in an enclosure with safety interlock, so we are just starting to work on this too. I think pause on opening the enclosure won’t be sufficient, because it wouldn’t prevent you from starting a job with the enclosure open. Interrupting the signal to VFD isn’t ideal because then it may be possible to run a job without the spindle going.
But maybe someone will suggest the right way to handle this?
Seems like the local codes/insurance regulations would have a provision for simply requiring people to be trained. It’s odd the things that you have to protect people from. What stops them from stepping off a curb in front of a bus?
Upon thinking this thru further, I would be inclined to agree that there is no easy way to accomplish this with C3D’s controller & software.
Any kind of interlock rig would require having a by-pass switch to use while setting up stock & prepping the machine for a job & then engaging the interlock before the program is started. Essentially making the interlock pointless.
Any practical door interlock system would need a dedicated input on the controller board that the motion controller only responds to when a program is running to pause the program & stop the spindle. This would have to act as an overwatch function - which would likely complicate & frustrate when troubleshooting issues occurs.
Essentially my line of thinking results in the conclusion that the time/effort/complexity of implementing a door interlock is just a fun exercise in over-engineering vs proper operator training & attention.
But I’d still love to hear about anyone who has managed to implement something!
i dont know if such a thing exists and you may well go down a rabbit hole there - but you could implement a gcode repeater (using a rpi or something) that sits in between the carbide software and the machine. and this could have the appropriate pins that would receive the door opened/closed signal and perform actions depending on the state.
program running, door open is detected. it would stop forwarding on the gcode to the machine, and send the gcode to power down the VFD, and it would also send to the carbide software an similar signal that the pendant uses to pause the program. this repeater would also need to buffer any gcode that was received but not yet sent to the machine.
then when the door is closed, the repeater can send the VFD power up gcode, send the pendant unpause signal, and resume forwarding on the gcode, starting with whatever is in the buffer.
the repeater can also buffer and not forward on any gcode if the job is started with the door open, but updating carbide software of this state is maybe more tricky… it could just immediately send a pause once the job starts i guess?
there might be countless edge cases to deal with here, but as they say in the software world, you can build anything given enough time and resources.
Certainly sounds like one way an overwatch safety system could be implemented. The biggest issue I see with it is the increased chance of communicaiton failure between Carbide Motion & the motion controller - it’s not one-way. And even small timeouts could cause Carbide Motion or the motion controller to reset their state. Have had plenty of times when static or software issues caused me grief in the middle of a job.
Essentially it would be performing a man-in-the-middle communication hack to control both sides when the door is opened. But what about when you open the door to get stock setup & jog around to get zero’s set & change bits? How would it deal with that? It would have to be looking for a job start/end/bit changes/probing/etc to know when to activate the safety interlock - same as if you had an interlock bypass switch. And again, the door interlock could not be active all the time - it’s like asking to perform an action with a hand or power tool that you aren’t allowed to touch. So then you bring in AI so you can talk to it, but the AI starts dreaming about what it thinks you said when you haven’t said anything & randomly chops your finger off while you’re changing bits…So the whole safety system becomes a liability & cancels itself out.
Conclusion: Desktop/hobby/small business grade CNC’s are essentially too open-ended & operator dependent to make integrated safety interlocks make sense.
yep, all valid points! and all ultimately solvable given enough engineering resources, but then at that point you probably could’ve just bought a fully kitted out Haas.
Other machines support this functionality, so I don’t thinks it’s so hard. Following the thread here
I think it should be doable to rebuild GRBL with the right settings so that the pause button functions as a door safety switch. Then wire a door sensor in parallel with the pause button.
As to why any of this needed when there are curbs and busses nearby… our workplace provides neither the curb nor the bus so they have no liability if you use them wrong. I’m willing to jump through a few hoops if it allows my workplace to provide a big CNC for people to use. We’ll still require training, but have you met people? They don’t follow rules, so it’s better if safety can be automatically enforced.
I am unclear why using GRBL’s ENABLE_SAFETY_DOOR_INPUT_PIN, and wiring the pin to your door switch, would not work for your need?
I understand this is what the Nomad did. It both interrupts a job (spindle included) if running, and prevents GRBL from accepting move/spindle on commands until the safety alarm is cleared. I am NOT saying this is how GRBL is currently configured on SO5 machines, I have not checked in a long long time.
I have not used CM in a long time either, so I could not tell whether in such a configuration, the resume button would work. But worst case scenario, switch to one of the other gcode senders out there, they implement standard GRBL alarm management/clearing/resume buttons.
It could be that it may be enabled to work with that. The big question I think is if the memory limitations on the controller for the Grbl build allow for that function to be part of it on the SO5.
