Second opinion on hard limit setup

Post technical questions about the Buildbotic Controller here.
Forum rules
No profanity, no gambling, no illegal activity, so sexual or pornographic material.

Posts not related to the Buildbotic CNC Controller are likely to be moved or deleted.
Post Reply
ramurph1
Posts: 6
Joined: Thu Mar 18, 2021 1:51 pm

Second opinion on hard limit setup

Post by ramurph1 » Wed Mar 24, 2021 5:54 am

I’m using the SN04-N prox switches for homing. Additionally, I have hard limit switches for over travel protection on each end of X and Y axis, and one for the upper end of the Z. My question is would it be better to just wire all of the hard limits NC contact in series to an external relay coil, so when power is interrupted it will sends a 3.3v signal to the Estop pin on the DB25?

I suppose I could skip the relay and wire them in parallel as NO contacts to the Estop input as a second option.

Or should I just tie each axises hard limits to that particular axis max travel input (i.e. motor 0 max) since I’m using the min for the homing input? I’m assuming an NO wiring method would be required for this as well.

Just looking for another opinion.

I’m making a drawing and trying to make my wiring very neat, so looking to get this all sorted without having to go back and re-arrange wires, labels, etc.

Thanks in advance!

Skyler
Posts: 22
Joined: Fri Oct 30, 2020 10:25 am

Re: Second opinion on hard limit setup

Post by Skyler » Fri Mar 26, 2021 5:10 pm

All those ways would probably work just fine. However I would use the controller inputs to make things easier. If it were me I would use the max/min travel inputs so you the software will tell you what axis had an error. Also, I haven't tested it but if a max/min travel input occurs you may only have to re-home one axis, not all three like when you E-stop the machine. If you wanted to be super safe you could wire it up to cut power if any of those switches flip, but for most machines that would be unnessesary IMO. Also I would use normally closed if at all possible to prevent an undedected overtravel instance from a broken switch, bad connection etc.

Have fun!

Post Reply