How to allow dual Z and dual extruder on RUMBA?

[geekness]

The RUMBA has 6 stepper ports
If I uncomment //#define Z_DUAL_STEPPER_DRIVERS in Configuration_adv.h, then the firmware only allows a single extruder.

#ifdef Z_DUAL_STEPPER_DRIVERS
  #undef EXTRUDERS
  #define EXTRUDERS 1
#endif

[thinkyhead]

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: X Y Z Z E E or X Y Z E E E

I will gather some resources around this and see what we can do… seems like an important feature!

[geekness]

@thinkyhead
thanks, let me know if you need me to test.
It's late here now (Australia), so I won't be back for probably about 9 or 10 hours. I need to rest.

[alexborro]

We should have a better way to associate drivers to function, not
predefined in pins.h

Cheers

Alex.

[thinkyhead]

@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

[alexborro]

@thinkyhead an abstraction layer would be nice. It can be done inside configuration.h....

Let's say we have in pins.h:

Stepper1 pin1
Stepper2 pin2

And inside Configuration.h:

#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

[thinkyhead]

@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 Configuration_adv.h?

• The default assignments should be in the pins files.
• Changing options like number of extruders, etc., should pre-set these for typical configurations
• Re-ordering axes at the hardware level should be invisible to the software level

[thinkyhead]

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.

[thinkyhead]

#1416

[boelle]

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

[gegiarmo]

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.

[boelle]

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

[gegiarmo]

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.

[gegiarmo]

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?

[thinkyhead]

@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.

[TGMods]

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:

C:\Users\Sally\AppData\Local\Temp\build8061703545994090010.tmp\temperature.cpp: In function 'void manage_heater()':
C:\Users\Sally\AppData\Local\Temp\build8061703545994090010.tmp\temperature.cpp:665:1: error: unable to find a register to spill in class 'POINTER_REGS'
 }
 ^
C:\Users\Sally\AppData\Local\Temp\build8061703545994090010.tmp\temperature.cpp:665:1: error: this is the insn:
(insn 98 97 100 4 (set (reg/v:SF 103 [ pid_input ])
        (mem:SF (post_inc:HI (reg:HI 147 [ ivtmp.210 ])) [4 MEM[base: _113, offset: 0B]+0 S4 A8])) C:\Users\Sally\AppData\Local\Temp\build8061703545994090010.tmp\temperature.cpp:449 99 {*movsf}
     (expr_list:REG_INC (reg:HI 147 [ ivtmp.210 ])
        (nil)))
C:\Users\Sally\AppData\Local\Temp\build8061703545994090010.tmp\temperature.cpp:665: confused by earlier errors, bailing out
Error compiling.

From Marlin_RC

In file included from C:\Users\Sally\AppData\Local\Temp\build3314267325316262561.tmp\Configuration_adv.h:601:0,
                 from C:\Users\Sally\AppData\Local\Temp\build3314267325316262561.tmp\Configuration.h:861,
                 from C:\Users\Sally\AppData\Local\Temp\build3314267325316262561.tmp\Marlin.h:26,
                 from C:\Users\Sally\AppData\Local\Temp\build3314267325316262561.tmp\blinkm.cpp:5:
C:\Users\Sally\AppData\Local\Temp\build3314267325316262561.tmp\SanityCheck.h:75:8: error: #error EXTRUDERS must be 1 with Z_DUAL_STEPPER_DRIVERS.
       #error EXTRUDERS must be 1 with Z_DUAL_STEPPER_DRIVERS.
        ^
Error compiling.

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.

[KiteLab]

About the 'POINTER_REGS' problem in the release branch:
https://github.com/MarlinFirmware/Marlin/issues?utf8=%E2%9C%93&q=is%3Aissue+POINTER_REGS

In the RC try to simply comment out the SanityCheck.h:75 line and see what happens. This could be a limitation for RAMPS, and other 5 driver boards, only.

[TGMods]

@KiteLab
Thank you for that information which I have tried.
However I came up with a better solution.
I ditched the official release and went with the RC. In the Azteeg X3 Pro Pins file extruders E2 to E4 are allocated which, in total, equates to steppers for X, Y, Z, and 5 extruders.

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.

[thinkyhead]

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

[Wackerbarth]

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.

[thinkyhead]

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!)

[CONSULitAS]

@thinkyhead
Perhaps we start here?

I have thrown with first crumbs of code. 😀 Is this a beginning?

[thinkyhead]

Every bit (and byte) helps!

[github-actions]

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.