The Shapeoko Forum

CheapSquier wrote:Something else that I didn't realize until I started looking closely at your build. I didn't realize that Shapeoko has a motor on each Y rail :? Many of the desktop CNC systems I've been looking at use a single screw under the gantry, right down the middle of (underneath) the table. (Ex: http://www.cncrouterparts.com/benchtop- ... p-313.html) That way they only use one motor for the Y. So I was going to ask you how you kept the two Y motors from getting out of sync, but I guess Shapeoko already figured that out somewhere along the way.

Actually, if you go back to the original, lasercut Shapeoko (mentioned briefly on the About page: http://www.shapeoko.com/wiki/index.php/About ) and w/ a link from the Parts page ( http://www.shapeoko.com/wiki/index.php/ ... urce_Files ): http://sourceforge.net/projects/shapeokocncmill/ that motor placement / screw configuration was used. It went away when the machine transitioned to MakerSlide, though it was still a single motor for the SO1. Even now, not all SO2s have the dual-motor upgrade, a couple of people have done driveshafts ( http://www.shapeoko.com/wiki/index.php/Drive_Shaft ) instead. Edward has published a list of (some of) his other machine designs:

http://www.shapeoko.com/blog/archives/1064
http://www.shapeoko.com/blog/experimental

and there's a timeline of machines here: http://www.shapeoko.com/blog/archives/305

The steppers on Y are never out of sync. There are two solutions.

1.) You attach both steppers to the same driver.
2.) You drive each stepper independently, but you send the same step/dir information to each stepper.



Sent from my SAMSUNG-SGH-I717 using Tapatalk

Actually, ideally, it should be possible to move the motors independently for the purposes of homing / squaring the gantry.

The standard SO2 Arduino/gShield controller setup uses #1 as Akhlut mentioned --- more complex systems use #2 and AIUI, squaring the gantry / homing the Y-axis involves back-and-forth motions of one side or the other until things are perfectly lined up.

CheapSquier wrote:I like the setup you posted, but I'm curious about a couple of things.

First, I'm new to CNC, so I apologize in advance if I don't know something that should be obvious.

It seems like non-captive steppers are kind of hard to come come by. You mentioned "I had some NEMA 23 non-captive stepper motors made"? I understand why you went with a screw drive instead of the standard Shapeoko belt-drive, but why did you choose the non-captive motors vs captive motors with a motor shaft coupler to the screw? I guess maybe your configuration is a little simpler since the screw is fixed? A trade-off between easily available parts and getting a clean build?

I wanted to go with the non captive motors to eliminate screw whip. When you spin a long screw with a small diameter it tends to whip around at higher speeds. With this setup the screw doesn't spin and therefore cant whip.
I had hoped to implement this setup on my big machine to try and eliminate backlash caused by stretch in the belts.

CheapSquier wrote:It sounds like you got the resolution is excellent. Have you checked the repeatability? You mentioned you would like the feed rate to be faster. What would you change to improve that?

Resolution and repeatability are very good. I ran the first cut 3 or four times cutting a bit deeper each time. I was trying to figure out why the depth was changing during the job. Turned out to be a combination of loose set screws and a binding Z axis. I really didn't take the time I should have to get every thing set up properly before I started cutting.
I think that to get better speed I will need to get motors that will run on a multi-start screw. 2 or maybe even 4 starts will speed the whole thing up. The other possibility is motors with more torque.

CheapSquier wrote:Something else that I didn't realize until I started looking closely at your build. I didn't realize that Shapeoko has a motor on each Y rail Many of the desktop CNC systems I've been looking at use a single screw under the gantry, right down the middle of (underneath) the table. (Ex: http://www.cncrouterparts.com/benchtop- ... p-313.html) That way they only use one motor for the Y. So I was going to ask you how you kept the two Y motors from getting out of sync, but I guess Shapeoko already figured that out somewhere along the way. You just had to recalibrate for the different step size.

Thanks!

I use Mach3 with a 4 axis driver. Mach3 allows you to slave one axis to another so I have each motor on its own driver. I have never had a problem with the motors getting out of sync. Though I do have to manually square the gantry at the start of each job or if I have moved the gantry by hand with the motors unlocked.

akhlut wrote:The steppers on Y are never out of sync. There are two solutions.

1.) You attach both steppers to the same driver.
2.) You drive each stepper independently, but you send the same step/dir information to each stepper.

WillAdams wrote:Actually, ideally, it should be possible to move the motors independently for the purposes of homing / squaring the gantry.

The standard SO2 Arduino/gShield controller setup uses #1 as Akhlut mentioned --- more complex systems use #2 and AIUI, squaring the gantry / homing the Y-axis involves back-and-forth motions of one side or the other until things are perfectly lined up.

The buildlog.net stepper shield and the GAUPS both support #2, but the two Y drivers' inputs are wired together, so it's not possible for GRBL to drive them separately (from GRBL's point of view, #1 and #2 are identical). Squaring the gantry with either #1 or #2 does not pose any special difficulty. Square the front of the frame once. When you need to square the gantry, drag both sides of the gantry to the front of the machine so that both rest firmly against the hard limits (this is easier on the eShapeoko, where there are no belt clamps in the way, and the V-wheels are recessed a fraction of a millimeter so that the motor plates touch the end plates before the V-wheels do). Let go. Turn power on. The gantry is now square, and, unless you move it by hand, it'll stay square (even with the power off).

The interesting case is:

3.) Drive each stepper separately, from separate step/dir signals that can send different step/dir information to each stepper.

Normally, the firmware would send the same signals to both Y stepper drivers, but during the homing/squaring cycle, it would start by moving both Y axis motors until either side activated the limit switch, then it would home each side independently. I had them wired this way, using Marlin on an Arduino Mega, modified to support two separate drivers on Y (this was a year ago -- they've added that feature in the meantime), but I never had a chance to modify the homing routine to do the squaring too.

Lots of info to read over. Thanks, everybody.

Improbable Construct wrote:I had some NEMA 23 non-captive stepper motors made. They are 2.1 amp, 106 oz/in with a TR10x2 thread pattern. I wanted them in a 3/8" ACME thread but for a small quantity they we not willing to make them for me.

Bringing this thread back to life... hopefully.

IC, I would like to implement a design like this with captive steppers on a heavily upgraded SO2.

-Is there anything about this captive motor design that you would do differently?
-Specifically where did you get the motors and could they make some for me too?
-Why did you spec the motors the way you did instead of using off-the-shelf motors?
-Is there anything else, other than multi start screw that can be done to reliably get more speed on the rapids? Any idea how fast you would be able to go with a multi start? Your 4-start Z-axis https://www.youtube.com/watch?v=0qAIaU_16ew certainly looks much faster than that, but I see it has a higher lead (1/2 inch = 12.7mm) compared to the TR10x2 which I believe has single start which means pitch = lead = 2mm ?
-As for mounting the leadscrew, could you provide some more detail? It looks like some sort of plastic piece with a hole for a cotter pin?

I ended up scrapping this idea. It worked fine but there was not really any gain (actually a loss of speed) for a ton of complexity. I picked those motors because that was what they were willing to build a small quantity of that fit my requirements. The hard part was finding a motor that used screws that were easy to source in longer lengths. Shipping long screws from china is expensive. Overall the design worked but it wasn't practical.