Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics

JoergS5

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

oliof

@joergs5 I'll be glad to help out with that, but I thought the removal is only in the cards for Duet2 boards.

JoergS5

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

JoergS5

Thinking about the discussion, another new idea:

by IF flag the seldom used kinematics could be excluded from <= Duet2 builds.

gloomyandy

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

JoergS5

@gloomyandy I see, added recently (between 3.4.0-beta7 and rc1), so the whole problem already solved... Thank you for information.

bberger

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.

oliof

@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 (-:

o_lampe

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

bberger

@o_lampe or 2.4A Moon's motors like in my case.

Miss Rebekah

im using a duet 2 for a robot arm

EducatingSavvas

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

dc42

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

JoergS5

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

Snimax

@joergs5 There is a #define SUPPORT_LINEAR_DELTA in the code so I think it's already possible . I believe the discussion is about which kinematics should be enabled by default in the provided binaries.

JoergS5

@snimax said in Duet 2 Hangprinter, 5-bar Scara, Polar, Rotary Delta kinematics:

#define SUPPORT_LINEAR_DELTA in

that's right, but I didn't mean that, but the places where a if-delta code is placed. If there is placed code to call the delta kinematics, it would break. So if there at those places are also those if support_linear_delta switches, it would be fine.

I searched an example and here it is: GCodes2 case 665 would probably break trying to change to linearDelta kinematics. (It's not the best example because why would you call 665 if you don't have a delta, but just as example)