Being rather neat freak, I want my homing routine to perform with independent motor, not just axis. For example, I have two motors on x. I want the x homing to go until both limit switches are hit not just one of them.
Can this be done via wiring the limit switches? Or is this something that a board like tinyg needs to support?
@Dat_Chu I have played with this myself but on a ramps board in Marlin, derived from grbl. I could not find a smooth way to implement this myself. Whosit brought up recently the other way of putting them in series or parallel. This does work for ensuring both get hit prior to the home being recognized, but if you are out of square at all you risk smashing one endstop or damaging lead screw, jumping the belt, or knocking a tooth off.
I think if someone found a really nice way to implicate this the community would be forever grateful. Uses I know I have seen multiple same axis endstops requested, delta printers for multiple motor z axis, CNC dual motor drives per axis, and belt driven z axis Cartesian printers.
Mach has a feature where it uses endstops to square up parallel axis. Linux CNC probably has the same thing. It’d be nice if someone added this to GRBL.
If it can be done in Mach, I surmise it can be done in TinyG+Chilipeppr combo @jlauer @Riley_Porter_ril3y , any suggestions on where to start? I am willing to spend the time to make this happen.
I’m assuming you have 2 motors on X both moving the same gantry. One is forward polarity, one is reverse polarity and they both move when a Gcode X position is issued. It’s possible you have 2 gantries on your X which is why I wanted to make sure that’s not the case. That would be quite fancy/cool if you’re talking 2 gantries, but I assume not.
So, based on that assumption…
Easiest is to wire your X Min port with 2 Normally Open switches and set your TinyG to $st=0 for normally open switches. You must set all ports to normally open mind you. Then when one switch is hit it will partially complete the circuit. Only when the 2nd switch is hit will it fully complete the circuit. So, a normal homing command like G28.2 X0 should work if I understand your question correctly.
Here’s a whacky alternate approach that could possibly work. You could use probing. Use the X Min switch for one motor. Then use A Min switch for other motor. You would have to send a command to TinyG though that repoints the 2nd X Motor to the A axis. That way when you ask for probing on the A axis, you’ll get movement on the 2nd X motor. Then follow the steps below:
If you think about it, you can do this like a probe in the Auto-Level. TinyG has the G38 command available. This does something similar to homing and in fact uses the homing switch ports. To do this on the X axis for two switches perhaps use the X Min and the A Min port. Just know you used A on the X. Then issue G38.2 X-1000 F200 to do the X Min switch and find the position. Watch the response like the watchZ() method line 1302 in the Auto-Level javascript. You’ll see a command come back from TinyG like {“r”:{“prb”:“e”:1,“x”:20.150,“y”:6.831,“z”:-2.916,“a”:0.000,“b”:0.000,“c”:0.000}},“f”:[1,0,0,1169]}. Capture the X value and store it in a variable. Then issue G38.2 A-1000 F200 to do the A Min switch and find position. Whichever is more negative or positive (depending on which one you want) go to that position. Then issue an artificial homing command of G28.3 X0 to set your X axis to zero.
The idea of mapping the second X to A is rather interesting. I will look into this further. Thanks @jlauer
would it be possible to wire you limits switches in series, thereby insuring both have to be closed to register.
Wiring in series work but one needs to ensure the one that trips no longer move to avoid breaking that axis.
@Dat_Chu I think Johns solution will work if I understand correctly. This would only apply to TinyG’s 6 axis control. But slaving A to X and using the separate min with some type of interrupt in less true… Yeah I can see this!
@jlauer dual X gantry… Yes yes now we are getting excited, when are you building it? Haha
Make you a deal. You build the the software, I’ll build the hardware. ESAB does it, open source should have it.
Ha.
Someday I hope open source machines will have this: http://www.h-h.com.au/images/app_egs/tool-changer.jpg
@Todd_Fleming , is it the tool coupler that is the issue? Why don’t open-source have tool changers?
Yes, the tool coupler is the biggest issue. I once made the mistake of buying a quick-change coupler set for my Sherline; the repeatability is horrid.
I have not seen an automatic tool coupler in real life before. Is the problem with getting the tool head in the right place? I thought that is already do-able. Or is it having the tool head in the right rotation?
The attachment between the spindle and the tool holder is very tricky. Think of stacking a cone within a cone. It turns out that you need a lot of force to make them align properly. Without that force you end up with wobble and/or height variation each time you reattach. It normally takes a pneumatic drawbar running through the spindle center; this drives up the spindle cost. It also weighs down the Z axis.
http://hackaday.com/2014/09/19/thp-semifinalist-farmbot/ These guys got it going. Nothing heavy though.
There’s no way that could hold an endmill.
Nope, not at all, end mill is definitely on the heavy end (hah!) of things. For some other purposes though, this would work ok.
