Dual steppers

I found a couple topics about using E0 and E1 as X2 and Y2.

So instead of wiring the two X steppers and two Y steppers in series or parallel, you would use 5 stepper drivers (4, plus 1 for Z-axis), each using one port on ramps. I know you don’t want to support these config, but I have a rather small MPCNC, meaning I don’t have to cut the stepper wires to extend them. I don’t think it makes sense to cut the wires/plugs just to wire it in series or parallel, when the ramps comes with 5 drivers already, so the option for going for 5 drivers is basicly already there.

I extracted User “O-Toms” patch (https://www.v1engineering.com/forum/topic/marlinramps-patch-to-use-extruder-drivers-as-additionnal-xy-drivers/) and implemented his changes in my MPCNC-marlin firmware.

[quote]
Configuration_adv.h, un-comment these two lines:
#define X_DUAL_STEPPER_DRIVERS
#define Y_DUAL_STEPPER_DRIVERS[/quote]

[quote]
pins_RAMPS.h, add these lines:
#define X2_STEP_PIN E0_STEP_PIN // (actually this is set to 26)
#define X2_DIR_PIN E0_DIR_PIN // (28)
#define X2_ENABLE_PIN E0_ENABLE_PIN // (24)

#define Y2_STEP_PIN E1_STEP_PIN
#define Y2_DIR_PIN E1_DIR_PIN
#define Y2_ENABLE_PIN E1_ENABLE_PIN[/quote]

For the Y-axis this works straight away, but the stepper connected to E0 (the second X-stepper) does only turn in one direction. If you let turn it forwards or backwards, this stepper always turns in the same direction.

If you google for “motor only turning in one direction” (or something like that), it looks like its an endstop issue. I don’t have, or use, endstops, neither I know if endstops are actually configured in the vanilla MPCNC-marlin firmware (I’m using “MPCNC813_GLCD_T8”).

Any advice for this? Is there any other flag in marlin that is configuring E0 as a “only go in one direction, no matter what comes”-motor? Or is it really something endstop related? Or are the pins (26, 28, 24) wrong? (tried some others I googled for - those just make the E0 motor stop working at all)

edit:

I also tried this setting posted by User “AntTuru” (https://www.v1engineering.com/forum/topic/marlin-using-e-drivers-to-run-2nd-x-and-y-motors/#post-30610), looks like he is re-using 4, 2, 15 und 19. When I use these pins, the motor won’t do anything.

Already done with endstops just in case. https://www.v1engineering.com/auto-squaring/

I think something is wrong with these topic. Ryan the only posting here I see is yours, when I logout the forums and view as a guest, I see my opening post, but not yours. Looks like the whole topic is somehow broken.

Even my posting-history does not show my opening post for this thread. Weird.

Btw, I don’t use endstops, and I fail to see how the article you linked to is related to my topic.

edit: if you don’t know what is going on with this topic, please just delete it. I have a backup of my opening post, maybe I should just start another one.

Ryan, since he’s not doing dual endstops, he doesn’t need your code. The code you started with supported dual x and y movement.

Bernd, I am going out on a limb and going to say the code is still trying to control E0. I suggest defining the X2 pins explicitly and setting the E0 pins to something else. Ryan had to do that to test his dual endstop code on ramps.

If you use it and uncomment the dual endstop parts in config-adv all that should be left is the E0 and X2 remapping. I think.

 

Oh yeah or the code above but you will need to point the E0 somewhere, I don’t think you can turn it off even though there is an option to.

I just found the topic “Auto Squaring, My axis is hella square…” that was embedded in Ryans article he linked to.

Looks like the WIP firmware you posted there (Marlin_with_Dual_dual_XYZ) does not support a full graphics LCD, because whenever I flash this, LCD stays just blue.

I took your lines from pins_RAMPS.h and merged it with the org. firmware you have up in this site, now E0 can turn in both directions!

So the correct lines are

[quote]
#define E0_STEP_PIN 70 //26
#define E0_DIR_PIN 70 //28
#define E0_ENABLE_PIN 70 //24
#define E0_CS_PIN 70 //42

#define E1_STEP_PIN 26 //36
#define E1_DIR_PIN 28 //34
#define E1_ENABLE_PIN 24 //30
#define E1_CS_PIN 42 //44

//mpcnc
#define E2_STEP_PIN 36
#define E2_DIR_PIN 34
#define E2_ENABLE_PIN 30
#define E2_CS_PIN 44
//mpcnc[/quote]

Just add this to the file, and uncomment the other two mentioned lines in my opening post

[quote]
Configuration_adv.h, un-comment these two lines:
#define X_DUAL_STEPPER_DRIVERS
#define Y_DUAL_STEPPER_DRIVERS[/quote]

and be done with it. Now every motor uses one stepper driver. :slight_smile:

Sweet!

I’m trying to learn some Git so I can make modifications easier to all the firmware versions I have to keep up with now.

Is that the thing you (personally) want to spent time/resources on, as the main person behind vicious product? I think somewhere on these forums you said you are no programming guy.

Don’t get me wrong, I noticed you respond to everything in these forums and that’s very honorable imho. I have seen similar projects where this “dirty”, sometimes unthankful work is handled by moderators and such.

What I try to say is I can’t believe there’s not one marlin-dev (with interest in the MPCNC) out there that could take care of needed modifications, so you can focus on other parts, or new great projects.

When you are done with the dual-endstop-version of marlin this will multiply the number of marlin-firmwares that are out for the MPCNC by what, two actually? Maybe it makes more sense to merge everything (LCD yes/no, threaded/T8, series or parallel vs. 5 drivers, dual-endstop) into one single firmware, appropriated commented like you are already doing ("//mpcnc").

As much as I like to just click a link to get the software piece I need for my machine, I think it’s feasible to force everyone to go through the firmware and set flags whatever is needed for the a machine.

I just compared MPCNC813_GLCD and MPCNC813_GLCD_EB, and theres just one (well, two) differences. -> http://imgur.com/a/1SW2o

[quote]//mpcnc: set SENSOR_0 to 999 and SENSOR_BED 0 to disable, set both to 11 to enable
#define TEMP_SENSOR_0 x
#define TEMP_SENSOR_1 0
#define TEMP_SENSOR_2 0
#define TEMP_SENSOR_3 0
#define TEMP_SENSOR_4 0
#define TEMP_SENSOR_BED x[/quote]

This would simplify adding new generic features alot because you don’t have to change a dozens firmwares.

SQL, I love the forums. I learn so much from all you people in here. I think there are a lot of moderators in here but none of us have titles (if anyone wants one let me know). For the most part other than some spam That pops up once and a while we haven;t really had any people issues here…Heffe gets a little rowdy once and a while but Bill and Barry keep him in check…or egg him on can’t figure out which one sometimes. JK. I am usually just doing this all by myself so some forum interaction is usually a very welcome distraction sometimes.

As for the Firmware. The edits are very easy and I would love to tell people to just do it themselves but we have some extremely new comers to the game both young and old. I like to get them up and running as easily as possible even if they don;t buy from me. I am pretty sure some people think I’m a punk sometimes because I will not do specific edits but can’t win them all. I used to have edits for 20T pulleys since that is the most common issue, next is the 16th stepping of the a49 drivers. That is where Heffe patience has come into play. He has helped me get a handle on Git and GitHub so I think I can now just add a branch to my github for any version and not worry about it again even through updates…maybe…still learning.