Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics
-
I personally think that removing some of the exotics is fine, upgrading from Duet 2 to Duet 3 is no trivial or cheap task, esp when dealing with more advanced printers that use more than one board. I'm afraid some people would be left behind if Duet 2 wouldn't be updated anymore...
In any case, can you please make sure that the Duet 3 platform offers all the planned upgrade paths before deprecating existing hardware (whenver that mught actually happen)? I'm mostly talking about the dual mainboard (2 Minis or a 6HC + a Mini) configurations that still have some restrictions (according to the documentation). I need to hold off my Duet 2 + Duex5 conversion to 6HC + Mini until that stuff is properly supported.
-
@dc42 I vote get rid of them. Would much rather have more modern features on my production printers than a shorter path to an odd kinematic play toy printer.
-
I, too, vote to get rid of the specialty kinematics for duet 2. I have around 6, and none need more than simple xyz or corexy.
-
In my opinion if you freeze features on the Duet 2, you're going to lose those owner's loyalty to the brand... When I can't have the next killer feature that comes out, I'm not going to invest in a Duet3, but will be looking at other cheaper boards that support RRF, or most likely, will be jumping ship to the Klipper side!!
I think removing the exotic kinematics with an option to swap them back in for a manual compile, or even having a pre-compiled firmware for both, is a good option.
@joergs5 said in Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics:
Maybe someone can even find good solutions for those problems in the future with additional hardware.
Along the same line of thought as what joergs5 mentioned, another option is to take a hybrid Klipper approach and offload some of the functions to another controller or RPi, like input shaping, DWC, heater tuning, etc. Or even a full Klipper approach. That will provide plenty of space for additional features and extend the life of the Duet 2 and 3 for a long time. Not sure how feasible that would be, but it was just a thought.
-
@dc42 I don't know about coding or the amount of work it would take but would it not be possible to have the kinematic made in a modular fashion kinda like a macro you can choose whilst setting up for the first time, imagine not many people change the kinematics once their printer is built, similar to what Exerqtor was suggesting, or are the kinematic to integrated?
-
@oliof Interesting - for whatever reason I had the Duet3 mini as "fewer channels than Duet2" in my head. Thanks for clearing this up.
-
@dc42 if you decide to remove those kinematics from core RRF, I offer to take a lead for source and documentation for 5-bar scara, 5 axis robot, 6 axis robot and later this year for stewart/hexapod kinematics.
My proposal are dedicated github repositories on Duet3D (so the repositories can be found) for those kinematics with source and binaries, so users who want to use them can easily install them. I propose to offer binaries for Duet 3 based hardware (6HC CAN, Mini Eth, Mini WiFi, 6XD) for main releases and maybe for a part of the beta versions.
-
@joergs5 I'll be glad to help out with that, but I thought the removal is only in the cards for Duet2 boards.
-
@oliof said in Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics:
@joergs5 I'll be glad to help out with that, but I thought the removal is only in the cards for Duet2 boards.
The point is that the firmware today is one code (Duet 0.6/0.8, Maestro, Duet2, Duet3 6HC, Mini) and with eclipse several target platform bin files are created. In the near future it is too big for Duet 2. Splitting into Duet 2 and Duet 3 trees is not wished, as it complicates delivery and testing. Removing the less popular kinematics is an alternative (or dynamically linking as I proposed first).
-
Thinking about the discussion, another new idea:
by IF flag the seldom used kinematics could be excluded from <= Duet2 builds.
-
@joergs5 The current source already contains code to allow various features to be optional including some of these kinematics:
https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Movement/Kinematics/HangprinterKinematics.cpp#L10/* * HangprinterKinematics.cpp * * Created on: 24 Nov 2017 * Author: David */ #include "HangprinterKinematics.h" #if SUPPORT_HANGPRINTER
By default these optional items are enabled:
https://github.com/Duet3D/RepRapFirmware/blob/3.4-dev/src/Config/Pins.h#L221// Optional kinematics support, to allow us to reduce flash memory usage .... #ifndef SUPPORT_HANGPRINTER # define SUPPORT_HANGPRINTER 1 #endif
So it is just a case of disabling (or enabling) the support in the board configuration files (or build system), so for instance the Duet3Mini4 build has some/all of them disabled:
// Disable the kinematcs we don't need to save flash memory space #define SUPPORT_LINEAR_DELTA 0 #define SUPPORT_ROTARY_DELTA 0 #define SUPPORT_POLAR 0 #define SUPPORT_SCARA 0 #define SUPPORT_FIVEBARSCARA 0 #define SUPPORT_HANGPRINTER 0
Of course as time goes on the problem may be finding a combination of settings that supports all of the features you want but that still fits in flash memory.
-
@gloomyandy I see, added recently (between 3.4.0-beta7 and rc1), so the whole problem already solved... Thank you for information.
-
I wouldn't be completely opposed to feature freezing the Duet 2 WiFi - but then I'd want a drop-in replacement (not Duet 3) upgrade path.
If I have to re-wire and reconfigure everything I'd probably just jog on and install Klipper.
Don't want to be rude, I love my Duet stuff and if you give me a straight drop-in replacement (form factor, plug types) I'd be up for that.
It's not about money for me (only have one printer right now and would love to build a "backup" secondary printer) - but I don't want to invest the time to rebuild everything.
-
@bberger The only thing you'd need to rewire going from a Duet 2 to a Duet 3 mini 5+ is the heater wiring, the rest can be re-used as is. You'd likely require to adjust a couple of pin designations, but even that is likely to be less of an issue. So while this won't necessarily satisfy your requirement of "drop-in replacement", it'll probably be less effort than moving to klipper -- which is a great alternate choice, so if this path leads you there, you probably won't be disappointed. It may not be as straightforward if you use any of the kinematics covered in this thread though, since they're either not supported at all or in experimental branches at best, as far as I can see.
After all, the intent of this thread is gauging whether dropping those kinematics from Duet2 builds to make room for future features would be acceptable. It sounds like to you, it may -- no new hardware needed, you can stick with RRF, and you'll get all the new features for the most common kinematics (-:
-
@vwegert It's not the number of drivers that are different, but the max. current AFAIK?
The Duet3 mini is more like the Maestro. Not well suited for NEMA23 on a CNC or strong Nema17 extruders. -
@o_lampe or 2.4A Moon's motors like in my case.
-
im using a duet 2 for a robot arm
-
@dc42 Was desperately hoping someone would create a kinematic for cartesian with a rotary z - for tangential knife cutters or concrete/clay printers with vector following nozzle.
-
@joergs5 said in Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics:
@gloomyandy I see, added recently (between 3.4.0-beta7 and rc1), so the whole problem already solved... Thank you for information.
Yes, for those prepared to build the firmware themselves. The change I propose is to remove support for some kinematics in the standard firmware binary that we release. I'll leave linear delta in because it's popular, also I'll leave SCARA in because it was the second nonlinear kinematics implemented and the machine I test Duet 2 Ethernet on is a SCARA.
-
@dc42 said in Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics:
I'll leave linear delta in because it's popular
My wish would be that the kinematic can be commented out without breaking code at other places in the firmware, so if I use an exotic kinematic, I can maximize available memory.