Use separate drivers for X/Y without end stops

This is my first post here, I am not sure if this has been covered or not. I have printed and assembled an MPCNC and I am impressed at how well the parts came together. I want to thank Ryan for making this amazing design available and everybody who has contributed here for all the information they provided.

I am about to set up an arduino/RAMPS controller for the machine and am intrigued by the possibility of automatic squaring using dual end stops and separate stepper drivers for the X and Y axis. This is something I would like to try after I get some experience with the CNC. Is it possible to use the dual end stop firmware without end stops now in order to avoid having to rewire the steppers later? Are there any downsides aside from using up all stepper drivers on the RAMPS? I do not plan to use the machine as a printer.

Related to stepper wiring, I am also wondering about what wire gauge to use. A search on google turns up recommendations between 18 and 24 AWG. The steppers I am using have a rated current of 2A. I am wondering if I could use network cable for wiring them. I have found wire gauge charts that suggest 24 AWG is ok and others that indicate it’s not. Any advice would be appreciated.


High five!


Yes, turn off the endstops in config, and there are a few changes in config adv. Really though the wiring is super easy you might just want to stick with the proven path to learn on.

24awg is more than enough.



1 Like

Thank you, Ryan!

I tried out the dual end stop Marlin 2 firmware and I can now move all steppers from the LCD and the X and Y steppers are turning in the correct direction. I did not install the belts, so only the Z axis is actually moving. There are a few issues, though. The X and Y axes only move in one direction and the stepper drivers are getting hot.

I think the software thinks there is a normally closed min end stop on X/Y and therefore does not let me move in the negative direction. I only spent a few minutes with Marlin and when I tried to comment out USE_XMIN_PLUG, the sanity check threw an error. I really wanted to see the steppers turning, so I left the USE_MIN defines active for X and Y and installed the firmware. Does anybody know the correct way to disable the end stops in Configuration.h while still using two independent drivers per axis?

I do not know why the stepper drivers are getting hot. I have the reference voltage set to just under 0.7V on all the drivers.

If you are using the Dual endstop firmware they want you to home first. To move both way disable the endstops in the firmware.


0.7V for what drivers? each driver is very different, for the DRV8825 0.7V is very warm but also normal.

What define is used to disable the end stops? The only thing I found was the USE_{AXIS}MIN_PLUG settings, which I cannot comment out because of the sanity check.

The drivers are DRV8825, the steppers are rated at 2A. What value do you recommend for the voltage?

The only things to change are in Configuration.h and config adv.h

Use 0.7V

If you don’t want to use the dual endstops I highly suggest you use the regular firmware and series wiring.

Might be best to wire in series until I’m ready to try the dual end stops. FWIW, I did manage to get both directions working for X and Y with the dual end stop firmware by changing the ENDSTOP_INVERTING defines to true.

Inverting is for NO or NC. My firmware is set up for NC on the Dual and NO on the regular.

Yes, no problem using network cables.

I recommend you to use shielded cable (to avoid electromagnetic interferences in case you’ll be using a router) and to use one pair of wire of the network cable for each wire of the motor (8 wires in the network cable --> 4 wires to the motor). I’m not sure if this is absolutely necessary, but it will reduce the resistance, so less stress on the wiring and on the driver for a given motor performance.

That’s how I did it on the first version of my MPCNC, worked nicely.

That makes sense. To get the dual firmware working without end stops, it has to be set to NO as well, otherwise it always thinks it is at the min end stop and does not let you move in the negative direction.

I have not done any permanent wiring yet, just plugged the stepper cables into the board sitting in the middle of the table and ran your crown gcode. Even though I had checked all axes directions beforehand, I must have gotten confused on the Z axis and it pushed the pen down real hard and then proceeded to draw the crown in the air. The flexible pen holder survived and after flipping the Z axis cable, the crown gcode worked flawlessly. I am pretty excited about it and ended up showing everybody around who did not run away fast enough a new print of the crown.

I think I may have tightened the belts on the X axis a bit too much. It is somewhat hard to push by hand (with steppers off) and was resonating at the fast travel moves. Of course, the machine is a bit larger than the recommended size, not sure if that might have something to do with it.

Thanks for confirming that this will work. I plan on using a router eventually and have a lot of network cable. I wanted to make extension cables with proper connectors and while I found the pins and crimping tool in one of my drawers, I could not find any of the housings. I ordered a bunch of them and will wire it up later this week.


Pretty sure that never ends for all of use, I still do it all the time.

Slow is the name of the game here. Slow by hand and fast travel moves are also slow. There is no need to shave off a few seconds of travel time.

I wired the machine today. All the network cable I had was solid core, so I used 22ga hook up wire instead. It’s not shielded wire, but so far so good. I decided to leave the machine configured for dual end stops even though I have not wired them yet. All I need now is a 40mm fan for the RAMPS case.

I gave the machine a good workout today. The crown got a bit boring so I wrote a program to dither photographs using lines at various angles. My plan was to save the line segments as an SVG file and then generate gcode with Estlcam, but the time it took for the software to generate the paths was unbearable. Maybe it has something to do with running it under wine on linux. Instead of waiting for Estlcam, I programmed gcode output directly into my dithering software and even added a crude path merging and optimization scheme to reduce the time spent lifting the pen and moving around without drawing. The attached picture took 56 minutes to draw. I used six gray values and an ultra fine tip sharpie after initial attempts with ball point pens failed. They would not draw consistently. The sharpie, on the other hand, tends to bleed a little and is a bit thicker than I would like, so I had to reduce the gray value resolution. I have some ideas how to improve the result and calibrate the dithered gray values to obtain more contrast, but I am pretty happy with how it turned out.

In my software, I calculated time spent on drawing moves, travel without drawing and moving the pen up and down. The total of all three categories was a bit under ten percent less than the actual time, as I did not take acceleration into account. Interestingly, my calculations show that just over half the time is spent moving up and down, about five percent moving without drawing and the rest on actual drawing. And that is with a clearance plane of only 1.25mm. I used speeds of 35mm/s in-plane and 10mm/s out-of-plane. I think if one wanted to make a large drawing with this or similar techniques a fast pen lifter would help. Maybe something with a solenoid.

I am really excited about how consistent the machine is. The line spacing appears to be spot on. My path optimization scheme always tries to find the closest path endpoint, so a lot of times it would fill in a line in between two neighbors that were drawn much earlier. I cannot tell any difference, so there is no error accumulation at all. It is truly an amazing design!

[attachment file=51871]


That is one hell of a test!

A few other people might want to get there hands on that software, the results are fantastic. I added it to the gallery, thanks.

The software is not very user friendly at the moment, it is just a quick hack for proof of concept. If I find enough time to make it into something usable where you don’t have to recompile every time you want to change a setting, I will start a new thread and release the code.

Cool, no pressure I know how those things go. Just putting the idea out there in case you do get back into the pile of code.

Yeah, not enough hours in a day, but I hope to do some more with this. I made another drawing with ballpoint pen. Unfortunately, the pen did not draw very consistently and the line width varied a bit so there are some obvious stripes. But the contrast and detail is much better than in the sharpie pen version.