Kinematics for 5-axis CoreXY printer

tcpl

Hi @dc42
I am in the process of building a 5-axis printer, with Core-XY linear kinematics with additional AB rotary axes mounted on the gantry. Could you reserve a kinematics type number for this purpose?
Thanks,
Blaise

dc42

@tcpl I can reserve a kinematics number, but do you actually need new kinematics? Unless you want the positioning of the CoreXY motors to take account of the position of the rotary axes, or vie versa, you don't need one because you can already add additional axes to a CoreXY configuration.

tcpl

@dc42 I need to take that into account, as I want GCODE to dictate the position of nozzle and it's rotation, not axes individually. This makes linear axes affected by target rotation, and I don't see how I could make that work with what is available now

dc42

@tcpl thanks. In firmware 3.7 we'll be shifting to a new mechanism for defining kinematics, so what we'll need is a unique short name of the kinematics to select it in the GCode command. Would you like to propose one? Syntax will probably be:

M669 K"your_kinematics_name"

where as usual case of letters is not significant, and underscores and hyphens are ignored when matching.

tcpl

@dc42 The best name I (or my team at my students' association) could come up with (and I have been working on this project for some time) is ABCoreXY. If someone has better name I would be more than willing to use it, but if not it is (semi)appropriate

o_lampe

@dc42 Over the years we've seen many experimental printer kinematics (eg. tripteron) or even worse: mixed kinematics like this.
IMHO there should be an option to define a new kinematic in RRF3.7 which includes naming it.

Maybe you can split the kinematic definiton into small sections?

One for the gantry (delta, cartesian, H-bot, coreXY, Markforge, etc)
one for the tool (static, AB rotary, etc.)
one for the bed (static, Stewart, AB rotary, etc)

With that, the user can hopefully cobble together a kinematic model that fit's any flavour.

T3P3Tony

@tcpl have you seen the work by @JoergS5 on this?

@dc42 for multiaxis rotary/linear systems like this it may be worth using a naming convention that fits with the stacked linear & rotary build up, e.g. as Joerg uses in his doicumentation:
https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuring_RepRapFirmware_for_a_Robot_printer
e.g.
CoreXYACbed : CoreXY ganry, AC both connected to the bed, A nearest to workpiece

More here:
https://docs.duet3d.com/User_manual/Machine_configuration/robot_5_axis_CNC

JoergS5

@tcpl are you sure it is AB type? This would mean the rotary axes are parallel to the X and Y axes. I've not seen this type until now, so I only implemented and tested AC and BC. Do you have a picture or drawing to verify the rotary axes types?

I will continue mid may to develop and can add AB if you need it.

tcpl

@JoergS5 Hi, yeah I think it is AC. Gantry (and rotary axes) looks something like this (not final design):

I was not aware of your work on this, is it possible to do this configuration without modification, or would I need to change something for it to work?
And from what I see my configuration would be described Z_corexy(XY)AC or Z_corexy(XY)CA or something else?

JoergS5

@tcpl this is an interesting design. I will develop the firmware to support it.

The behaviour of the rotary axes depend on whether they are connected to the starting point (e.g. connected to the bed) or the endpoint (hot end or drill). Connected to one or the other changes the direction of the rotation. I will probably change the definitions and configuration to a general description. I will have to think about how to define it with the M669 parameters easiest.