-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to allow dual Z and dual extruder on RUMBA? #1410
Comments
That looks like a leftover from an age long past. We're just now adding support for a 4th extruder, so it's a good time for us to look at the way Marlin parcels out steppers generally. Plus, once in a while someone might need to rearrange their drivers and that should be an option too. So for a RUMBA, we would like to have: I will gather some resources around this and see what we can do… seems like an important feature! |
@thinkyhead |
We should have a better way to associate drivers to function, not Cheers Alex. |
@alexborro I couldn't agree more. An additional level of indirection would be helpful. I'm in the process of breaking up pins.h into separate files by MOTHERBOARD value, a slightly tedious process, but it is already helping to make the assignments clearer. #1412 https://github.com/thinkyhead/Marlin/tree/cleanup_pins |
@thinkyhead an abstraction layer would be nice. It can be done inside configuration.h.... Let's say we have in Stepper1 pin1
Stepper2 pin2 And inside #define X_Stepper Stepper1
#define Y_Stepper Stepper2
#define Z_Stepper Stepper3
#ifdef DUAL_Z_STEPPER
#define Z_Stepper2 Stepper4
#endif In all firmware I'm used to work on for different hardware we have an abstraction layer to link high level functions to devices. What do you think about this approach?? Cheers. Alex |
@alexborro I like it a lot, especially as it preserves the meaning and order of the axes in code, but allows the axes to be rearranged at the "hardware" level. Perhaps this option belongs in
|
Another thought. Since a Stepper consists of a group of pins, not just one, we will need to either use Macro Substitution to apply the final arrangement which produces the final defines, or create structured arrays containing the pin numbers, which we can rearrange. And… If it becomes possible to re-assign an axis on the fly, we could add M-codes for that sort of thing. |
will close this one as there have only been 1 showing interest and nothing have happened in 6 months. OP or the makers of Rumba are welcome to submit a PR |
Any chance of reviving this? I have an Azteeg X3 Pro board, with a total of 8 stepper driver slots, and am looking to do just this. |
hmmm.... might be able to do it, i will be adding an extra slot to my board but i dont know how to program it |
So I'm trying a few workarounds in the meantime. I commented out the error that is thrown from SanityCheck during compile if you have dual Z stepper and more than one extruder set. I'm now able to compile and heat both extruders individually. I need to add a cable to my setup for the second extruder motor before I can test it. Will update as I progress. This might be fairly simple given the right boards. Also, as a note, I'm running Marlin develop circa 5/15. |
Everything is working. All I had to do was comment out the compile error, setup everything in configuration.h appropriately, and it's working great! Perhaps the error just needs a check for motherboard? |
@gegiarmo Probably we need to check more generally to make sure there's no conflict between the steppers used. In some way make it forward-compatible. |
I am having the same problem with my Azteeg X3 Pro which I bought to use on my CoreXY printer that I'm currently building. The errors I get are: From the current release:
From Marlin_RC
My programming skills are rather rusty or I would do it myself as I don't want to be limited to 1 extruder when I have the capacity to use multiple extruders and dual Z steppers. I just need some help. |
About the 'POINTER_REGS' problem in the In the |
@KiteLab Code snippet from the Azteeg pins file: #define E4_STEP_PIN 43
#define E4_DIR_PIN 37
#define E4_ENABLE_PIN 42 Code snippet from pins.h: #ifndef Z2_STEP_PIN
#define Z2_STEP_PIN E1_STEP_PIN
#define Z2_DIR_PIN E1_DIR_PIN
#define Z2_ENABLE_PIN E1_ENABLE_PIN
#endif This defines the Z2_ definitions to the second extruder. However changing the pins.h snippet to define the Z2_ definitions to E4_, which is in effect the fifth extruder would seem to resolve the problem: #ifndef Z2_STEP_PIN
#define Z2_STEP_PIN E4_STEP_PIN
#define Z2_DIR_PIN E4_DIR_PIN
#define Z2_ENABLE_PIN E4_ENABLE_PIN
#endif Plus commenting out the SanityCheck.h:75 line seems to have done the trick, at least as far as compile check. I will have to check tomorrow whether it actually works on the Azteeg X3 Pro. |
This seems to do the trick: #define __EPIN(p,q) E##p##_##q##_PIN
#define _EPIN(p,q) __EPIN(p,q)
// The Y2 axis, if any, should be the next open extruder port
#ifndef Y2_STEP_PIN
#define Y2_STEP_PIN _EPIN(EXTRUDERS, STEP)
#define Y2_DIR_PIN _EPIN(EXTRUDERS, DIR)
#define Y2_ENABLE_PIN _EPIN(EXTRUDERS, ENABLE)
#endif
// The Z2 axis, if any, should be the next open extruder port
#ifndef Z2_STEP_PIN
#define Z2_STEP_PIN _EPIN(EXTRUDERS, STEP)
#define Z2_DIR_PIN _EPIN(EXTRUDERS, DIR)
#define Z2_ENABLE_PIN _EPIN(EXTRUDERS, ENABLE)
#endif |
We need to explore this line of thinking to provide a totally separate HAL definition. With such, we should be able to replace the "EFF", "EFB", etc. distinctions with a simple #include which specifies the functional mapping. |
Yes indeed. I'm definitely looking forward to further abstraction of the hardware action. Hard to know where to even begin. (At the beginning, I suppose!) |
@thinkyhead I have thrown with first crumbs of code. 😀 Is this a beginning? |
Every bit (and byte) helps! |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
The RUMBA has 6 stepper ports
If I uncomment
//#define Z_DUAL_STEPPER_DRIVERS
inConfiguration_adv.h
, then the firmware only allows a single extruder.The text was updated successfully, but these errors were encountered: