Drive dual y-axis CNC using beta and extruder drivers

992 views
Skip to first unread message

Thomas Kole

unread,
Apr 2, 2014, 10:12:47 AM4/2/14
to smoothiewa...@googlegroups.com
Has anyone figured out how to drive a dual y-axis CNC using the beta and extruder drivers using a firmware modification? I'm trying to avoid soldering a jumper between the step/dir pins.

Jetguy

unread,
Apr 2, 2014, 11:30:51 AM4/2/14
to smoothiewa...@googlegroups.com
Unless you ALSO cut traces or disabled the pins as outputs I am concerned hard bridging the step and direction pins would damage 1 or both outputs of the processor.
 
You really should handle this in code and I think it's not that hard to simply change the pin assignments. Just assign both pins to the desired output?
I'm hoping that points you in the right direction.

Thomas Kole

unread,
Apr 2, 2014, 11:42:41 AM4/2/14
to smoothiewa...@googlegroups.com
That's what I was thinking but I went on to IRC yesterday and was told there was no way to do this in the firmware and that I should try jumping the pins. I thought that sounded fishy so I posted here for a suggestion. I've been looking through the firmware files and think that the solution may be as simple as just modifying the stepper.cpp file. I was going to basically place a call to the delta motor where there is a call to the beta motor with the same parameters. Thoughts? I guess that I should also disable the extruder module in the config file but am worried that if I do that it won't pass along the delta pin or current assignments.

Jetguy

unread,
Apr 2, 2014, 11:43:19 AM4/2/14
to smoothiewa...@googlegroups.com
For more hints look in the config file.
 
Specifically here:
 
 
FYI, beta is Y axis
beta_step_pin 2.1 # Pin for beta stepper step signal
beta_dir_pin 0.11 # Pin for beta stepper direction
beta_en_pin 0.10 # Pin for beta enable
 
 
Now, I don't yet see what the 5th axis is defined as. Logically, I think what happens is that on the 5th axis you would omit or define the pins to unasigned free pins on the board or null?
What you do need to set is the current for that axis
so it would be the name of whatever they call the 5th axis and this line but replacing "beta" with that axis name.
beta_current                                 1.5              # Y stepper motor current
 
So basically, you would end up with beta axis having 2 pins assigned for step direction and enable.
And then the 5th axis (whatever it's called would have it's pins changed to new number or unused or null.)
But still define current for that axis.

Jetguy

unread,
Apr 2, 2014, 11:44:55 AM4/2/14
to smoothiewa...@googlegroups.com
Sorry, cross posting timing wise.
 
If you don't need the 4th axis, sure, that might work as well.
This should be possible but for sure, I wouldn't attempt to bridge the pins.

Thomas Kole

unread,
Apr 2, 2014, 12:57:37 PM4/2/14
to smoothiewa...@googlegroups.com

Mark Cooper

unread,
Apr 2, 2014, 1:34:52 PM4/2/14
to smoothiewa...@googlegroups.com
Bridging the logic dir-step pins is definitely the best way to go if you want to synchronize two stepper drivers. You will not damage anything by doing this. Simply do not assign the pins of the "extra" driver in config and all will be well (even if you fail to do this no hardware will be damaged ... the steppers simply may not move as expected). I would not recommend cutting traces on the pcb.


On Wed, Apr 2, 2014 at 9:57 AM, Thomas Kole <tpk...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jordan Jansen

unread,
Apr 2, 2014, 1:35:21 PM4/2/14
to smoothiewa...@googlegroups.com

I just soldered on male headers and use female/female Dupont jumpers for the step/dir pins on my shapeoko 2. Everything works fine.

On Apr 2, 2014 7:12 AM, "Thomas Kole" <tpk...@gmail.com> wrote:
>
> Has anyone figured out how to drive a dual y-axis CNC using the beta and extruder drivers using a firmware modification? I'm trying to avoid soldering a jumper between the step/dir pins.
>

Mark Cooper

unread,
Apr 2, 2014, 1:37:41 PM4/2/14
to smoothiewa...@googlegroups.com
Actually on second thought ... if you do not disable the extra driver in config you could damage the mcu pins, so do make sure to do that.

Thomas Kole

unread,
Apr 2, 2014, 1:58:54 PM4/2/14
to smoothiewa...@googlegroups.com
My Azteeg x5 is not here yet (Friday, hopefully) so I'm just getting prepared. My concern is that I'm going to have a difficult time getting to the step/dir pins since the board is so compact and the drivers are surface mounted. I would think that this should be an easy software fix just as it is in RAMPS. If my superficial understanding of the software is correct, the key is in the stepper.cpp file. I won't get a chance to check until it gets here. If anyone familiar with the software architecture sees a reason that this won't work I'd like to hear it.

Mark Cooper

unread,
Apr 2, 2014, 2:06:08 PM4/2/14
to smoothiewa...@googlegroups.com
Did Roy not break out the logic pins to headers? Ok, well that would create an issue then. I'm used to supporting Smoothieboard which breaks such things out to useable headers. ;) I guess we'll have to figure something out then...


On Wed, Apr 2, 2014 at 10:58 AM, Thomas Kole <tpk...@gmail.com> wrote:
My Azteeg x5 is not here yet (Friday, hopefully) so I'm just getting prepared. My concern is that I'm going to have a difficult time getting to the step/dir pins since the board is so compact and the drivers are surface mounted. I would think that this should be an easy software fix just as it is in RAMPS. If my superficial understanding of the software is correct, the key is in the stepper.cpp file. I won't get a chance to check until it gets here. If anyone familiar with the software architecture sees a reason that this won't work I'd like to hear it.

--

Thomas Kole

unread,
Apr 2, 2014, 3:44:15 PM4/2/14
to smoothiewa...@googlegroups.com
I don't have it in front of me, but from the pictures I don't see any logic headers. Maybe someone with the board in hand can comment.

Jim Morris

unread,
Apr 2, 2014, 6:11:54 PM4/2/14
to smoothiewa...@googlegroups.com
the Azteeg X5 does not have the driver pins broken out so you can't do it that way, unless you want to solder jumper wires directly to the chip pins.

You could use the two Z headers for Y they are hooked in parallel. You just swap the pin definitions in the config for Z and Y.

There is no way to do it in S/W just yet. What Jetguy suggested won't work.

Triffid Hunter

unread,
Apr 2, 2014, 6:15:18 PM4/2/14
to smoothiewa...@googlegroups.com
There's some stuff in the pipeline that would support this, but it's
not quite here yet.

We're in the process of reorganising the entire pipeline between
gcodes and stepper motors- there's a surprising amount of code along
that path!

In the future, you'll be able to define two actuators that both
consume the same arm solution output which means you can run two
drivers for one axis - but also move the motors independently if you
find some mad reason to do so!

In the meantime, you'll have to jumper the logic signals somehow. As
Mark says, simply ensure that at least one set of pins are set as
input and it'll be fine. Pins not referenced in your config will be
left as inputs.

Jetguy

unread,
Apr 2, 2014, 10:08:40 PM4/2/14
to smoothiewa...@googlegroups.com
Well, just as a measure of safety, I would tell folks to use 1k resistors to bridge the 2 stepper driver inputs.
That way, if a person totally messed up the config and both where in output mode, it just wouldn't work and no damage would be caused. The drivers have reasonably high input impedance and therefore should still be able to be driven easily by the 1K resistors forming the crossover but also have the protection to not destroy the processor if the config was incorrect.

According to the data sheet for the LPC1768, max current on an output pin is 45mA or 50mA depending on high VS low signal.
At 3.3V output, assuming one was in high state, the other in low state (grounded) 1K is sufficient to limit the current to safe levels to not blow things up, but more than enough "drive" to maintain signal integrity to both stepper drivers.

Thomas Kole

unread,
Apr 4, 2014, 11:06:11 AM4/4/14
to smoothiewa...@googlegroups.com
Thanks. I don't think I'll have enough current trying to use the parallel z headers. How long before we see the update to the software for dual y axes? I gotta admit that I'm sort of shocked that this wasn't one of the initial priorities out of the gate. Don't most cnc machines use dual stepper driven axes for gantry motion?

Jetguy

unread,
Apr 4, 2014, 11:19:51 AM4/4/14
to smoothiewa...@googlegroups.com
Even if they did use dual motors, the "correct" assumption would be to use 2 external drivers since you know you are using bigger motors.
 
I get it that you guys love onboard drivers and so on and if the software lets you gang to together, sure. The other alternative is to use a dual shaft motor and couplers and shaft to HARD LOCK the left and right sides together in alignment. To assume both stepper motors are in sync and the gantry is aligned exactly 90 to travel is my gripe with using 2 motors.
I'd rather have a dead solid and sqaure machine that is always sqaure, even when the power is off or even if I had enough force to cause a motor to skip a step, at least I wouldn't rack the gantry.
 
SO basically, IMO, you're doing it wrong before we ever got to the electronics.

Thomas Kole

unread,
Apr 4, 2014, 11:34:08 AM4/4/14
to smoothiewa...@googlegroups.com
That's a fair point, though I have never encountered any of those problems. Maybe I haven't had enough time under my belt to experience it. Nevertheless, I think there are many people that use two steppers. My motors are in the 2.5A range which is why I bought the Azteeg x5 with it's 8825 drivers. I use these same drivers with an old RAMPS board and have never missed a step. Since I am the only person that has access to this machine, I know that no one is accidentally turning one of the y motors independent of the other. I also verify my alignment before every machine op and have never had to make an adjustment so I don't see why I should change my drive mechanism. I also don't see the point in buying higher power external drivers when these are perfectly sufficient. Even if I did use external drivers, there is no easy way for me to hook them up to this board so that still leaves me in the same boat.

Mark Cooper

unread,
Apr 4, 2014, 11:34:35 AM4/4/14
to smoothiewa...@googlegroups.com
Thomas,

  So, to give you the slightly longer story there... Half the reas is that we have a plan for enabling that sort of thing in future that is going to be a lot more work to implement than a simple hack that just doubles an axis. But it will also allow for a lot more options. Because of these plans to implement a more elegant solution the core team has been less than driven to implement the software hack. :) The other half of the reason is that the X5 is a very new board. All other existing Smoothieboards break out the logic pins for the steppers to 0.1" headers. So, until very recently the hack simply had not been necessary.

Mark


--

Thomas Kole

unread,
Apr 4, 2014, 11:37:49 AM4/4/14
to smoothiewa...@googlegroups.com
Gotcha, I understand.

Jim Morris

unread,
Apr 4, 2014, 3:23:21 PM4/4/14
to smoothiewa...@googlegroups.com
I agree with jetguy, using two motors to drive a single axis is a mechanical hack that is really the wrong way to do it, although 3D printers do it because it is easy.

Personally I hate that hack... on my large Corexy I refused to use two steppers and leadscrews for my Z Axis. Instead I use a single actuator and use a moving knot to move both ends properly. The other ways I have seen is to use two leadscrews and one motor and use a chain drive to keep the two leadscrews turning together.

X5 does support the regular use of two motors for Z, most 3D printers use lower current steppers and drive them in parallel off a single driver, and X5 supports that by providing double Z headers already wired in parallel.

2.5amp motors are unusual in the 3D printer world. In the CNC world chain drives are common to keep both sides of a gantry moving in parallel.

just my opinion :)

Thomas Kole

unread,
Apr 4, 2014, 3:41:19 PM4/4/14
to smoothiewa...@googlegroups.com
It is loud and clear that you and Jetguy are of the opinion that dual motor axis setups are inferior, however, this is simply conjecture. Dual motor setups are extremely common, and the problems that you are talking about are mostly speculative. Just ask all of the people that run Mach3 in slave mode. My point is not to debate with you about which is better because I could come up with a number of mechanical based reasons for a chain or belt drive to fail as well. The purpose of this discussion is to find a solution for people that drive an axis with 2 motors powered by separate drivers. This is something that many people are going to want to do with this board, period. My intention is to find a software solution to this and not to design a chain drive for a machine that has been running flawlessly for almost a year now.

Jim Morris

unread,
Apr 4, 2014, 4:31:13 PM4/4/14
to smoothiewa...@googlegroups.com
well it is an open source project, source code is there have at it.... best of luck ;)

Thomas Kole

unread,
Apr 4, 2014, 5:06:11 PM4/4/14
to smoothiewa...@googlegroups.com
Thanks, that's exactly what I intend to do. I'm just waiting on the board and wanted to make sure that I wasn't reinventing the wheel. I will post the code modifications when I sort it out.

Triffid Hunter

unread,
Apr 5, 2014, 6:49:50 PM4/5/14
to smoothiewa...@googlegroups.com
This is getting a bit off-topic, but I think the two motor Z is
preferable to the alternatives, which place a radial load on the Z
threads and thus require significantly more complex mechanics to
eliminate the problems this introduces.

I started off with a belt on my Z, and the two motor solution is
significantly simpler.

If your mechanics have enough friction for one Z motor to skip steps,
then simply shifting that load from two motors to one won't help much-
you'll still lose steps and have ruined prints. You only avoid racking
in this error condition.

When the motors are hooked in parallel, they move together when spun
manually even when your electronics are powered down. This
demonstrates how tightly coupled they become through the amazing
functions of electromagnetism :)

In fact, if you connect two steppers with different steps/rev but
similar electrical numbers, you have made an electrical gearbox! Add a
relay into the mix and you have an electrical gearbox+clutch... Does
this not count as adequate coupling between the two sides?


Personally I tend to prefer hooking my Z motors in series. When
connected in series, they each get full current, but torque drops off
faster with rotational speed due to effectively doubled winding
resistance and inductance.

Thomas Kole

unread,
Apr 8, 2014, 12:26:00 AM4/8/14
to smoothiewa...@googlegroups.com
For anyone interested, I got my board in the mail today and after modifying a couple of the source files I have successfully come up with a firmware based solution for operating two y-axis steppers using independent drivers. I will add comments to the files to mark where I edited them and will post tomorrow. I'm tired. 

Jordan Jansen

unread,
Apr 8, 2014, 10:38:24 AM4/8/14
to smoothiewa...@googlegroups.com

I have my y-axis motors jumpered on my smoothieboard 5xc but I would definitely be interested in seeing a firmware version. This won't be my last smoothieboard and a firmware option seems like it would be easier.

On Apr 7, 2014 9:26 PM, "Thomas Kole" <tpk...@gmail.com> wrote:
For anyone interested, I got my board in the mail today and after modifying a couple of the source files I have successfully come up with a firmware based solution for operating two y-axis steppers using independent drivers. I will add comments to the files to mark where I edited them and will post tomorrow. I'm tired. 

--

Thomas Kole

unread,
Apr 8, 2014, 12:16:51 PM4/8/14
to smoothiewa...@googlegroups.com
If you have easy access to the driver logic pins, that is definitely easier than the firmware fix. I had to modify at least 5 files to get this to work. I'll post them when I get a chance to clean them up and comment everything (hopefully tonight). I also want to try and run a full gcode file containing a series of moves instead of me just manipulating the motors via the manual control interface of the host software.

Jordan Jansen

unread,
Apr 8, 2014, 1:13:05 PM4/8/14
to smoothiewa...@googlegroups.com

I only meant that going the firmware route would be easier now that you're doing the work for me :). Would i need to modify it to work with my Shapeoko 2? I suck at softwaring.

I would love to have that gcode file too. I'm looking forward to your updates. Thank you!

On Apr 8, 2014 9:16 AM, "Thomas Kole" <tpk...@gmail.com> wrote:
If you have easy access to the driver logic pins, that is definitely easier than the firmware fix. I had to modify at least 5 files to get this to work. I'll post them when I get a chance to clean them up and comment everything (hopefully tonight). I also want to try and run a full gcode file containing a series of moves instead of me just manipulating the motors via the manual control interface of the host software.

--

Thomas Kole

unread,
Apr 8, 2014, 3:11:00 PM4/8/14
to smoothiewa...@googlegroups.com
You would just plug your 2nd y motor into the extruder header and then modify your config file to disable the extruder module.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-support+unsub...@googlegroups.com.

Thomas Kole

unread,
Apr 8, 2014, 11:27:41 PM4/8/14
to smoothiewa...@googlegroups.com
During a test this evening I found out that planned moves and homing are controlled by completely different mechanisms. So there ended up being a whole other file that I needed to hack. I got it fixed and can now home and execute planned moves with the dual y-axis setup. I should be able to run a proper machine op test tomorrow night and then post the firmware for anyone who wants to test it.

Triffid Hunter

unread,
Apr 9, 2014, 12:12:57 AM4/9/14
to smoothiewa...@googlegroups.com
On 9 April 2014 13:27, Thomas Kole <tpk...@gmail.com> wrote:
> So there ended up being a
> whole other file that I needed to hack.

I have a feature/Homing-and-Actuator branch that seeks to solve that,
would love some help testing it and filling in the rest

Thomas Kole

unread,
Apr 9, 2014, 7:17:06 AM4/9/14
to smoothiewa...@googlegroups.com
I'd be happy to help in any way I can, but I'm not really a programmer.

Thomas Kole

unread,
Apr 10, 2014, 12:26:03 PM4/10/14
to smoothiewa...@googlegroups.com
My tests have been going well thus far. The only thing I've noticed is that once a motor is initiated to move by the host software, all motors are enabled and stay enabled indefinitely. I haven't been able to find a setting to turn off the motors when the machine is sitting idle for a set amount of time. I'm not sure if this is something that I created with my hack or if it is a general smoothieware phenomenon. I have to load a stock firmware and see if it still happens. Is there a setting for this buried somewhere in the code?

Mark Cooper

unread,
Apr 10, 2014, 1:06:56 PM4/10/14
to smoothiewa...@googlegroups.com
that's stock behavior


On Thu, Apr 10, 2014 at 9:26 AM, Thomas Kole <tpk...@gmail.com> wrote:
My tests have been going well thus far. The only thing I've noticed is that once a motor is initiated to move by the host software, all motors are enabled and stay enabled indefinitely. I haven't been able to find a setting to turn off the motors when the machine is sitting idle for a set amount of time. I'm not sure if this is something that I created with my hack or if it is a general smoothieware phenomenon. I have to load a stock firmware and see if it still happens. Is there a setting for this buried somewhere in the code?

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

Brian Dickman

unread,
Apr 10, 2014, 1:17:54 PM4/10/14
to smoothiewa...@googlegroups.com
If you really want the motors off after a run, just put an M84 at the end of the gcode.

Triffid Hunter

unread,
Apr 10, 2014, 9:38:56 PM4/10/14
to smoothiewa...@googlegroups.com
On 11 April 2014 02:26, Thomas Kole <tpk...@gmail.com> wrote:
> The only thing I've noticed is that
> once a motor is initiated to move by the host software, all motors are
> enabled and stay enabled indefinitely. I haven't been able to find a setting
> to turn off the motors when the machine is sitting idle for a set amount of
> time.

Please create a feature request at
http://github.com/Smoothieware/smoothieware/issues :)

It's far less likely to slip through the cracks, and provides a
wonderful forum to discuss specifics around it

David Bassetti

unread,
Jul 4, 2014, 4:20:15 AM7/4/14
to smoothiewa...@googlegroups.com
Hi guys, I have the same need for my Azteeg 5 to run 2 NEMA 23's, is there an easy firmware solution yet to run Y ais from Y and Extruder stepper drivers?
I looked on the issues list but I couldn't find anything..
I love smoothie for my 3d printer..  its soo fast in HBot setup.. but this cNC is a bit different :(


On Wednesday, April 2, 2014 4:12:47 PM UTC+2, Thomas Kole wrote:
Has anyone figured out how to drive a dual y-axis CNC using the beta and extruder drivers using a firmware modification? I'm trying to avoid soldering a jumper between the step/dir pins.

Arthur Wolf

unread,
Jul 21, 2014, 5:12:55 PM7/21/14
to smoothiewa...@googlegroups.com
Cheers.


--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Courage et bonne humeur.
Reply all
Reply to author
Forward
0 new messages