What's this kinematics called?
-
@JoergS5 Know it's a fairly old topic now but did you ever define how to do m669 for this kinematics? I keep coming back to this as how to do an idea I've got but don't want to go full steam into the mechanicals if the kinematics don't yet work in the firmware.
-
The standard Polar kinematics support in RRF should work with that arrangement, so no new M669 code is needed.
-
@oliverracing there is a good thead about using the polar kinematics printer in https://forum.duet3d.com/topic/13330/polar-kinematics-type-3d-printer-software-setup-help (and documentation in https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwarePolarPrinter)
If you setup a parallel scara configuration like picture in step 15 left (both actuators at the pivot point), this workmode 2 is tested and works ok with M669 K9 parallal scara kinematics. If you build the printer with one actuator at the pivot and the other actuator for a linear guide, polar kinematics is the correct one.
-
Thanks, sorry @dc42 I had somehow missed your first post saying that when coming back to my idea, I guess it is a polar but just struggling to get me head around how it's going to work the same but with the arm vs bed moving- but if it's supported the best way to find out will be to try.
@JoergS5 Thanks for that, reading that it definitely looks doable and a good project for when stuck inside for the next few months! It'll definitely be one stepper for the pivot and one for the linear guide. Just need to work out if it'll be stiff enough for decent quality printing and not wobble all over the place!
-
Sorry probably going to be asking a few questions while I get my head around this. Feel free to tell me if any are in documentation as whilst I've had a good look through I've probably missed things.
-
I see polar printers normally have a round bed. Is it possible to define the actual printable area as a square within this (will be testing this with a square bed I have in the cupboard) or is the easiest method to define the origin as the centre of the printable area and limit the printed area in the slicer (and us custom Z probing points to probe the square)
-
When moving the printer in the control panel/DWC are the X/Y movements linear or in the axis system of the printer?
-
Can you set the print head accelerations separate to the axis accelerations? I'd imagine at the end of the reach you'll need to have a lower peak acceleration or even with the best design you'll get inertial effects on the print quality?
-
-
@oliverracing said in What's this kinematics called?:
- I see polar printers normally have a round bed. Is it possible to define the actual printable area as a square within this (will be testing this with a square bed I have in the cupboard) or is the easiest method to define the origin as the centre of the printable area and limit the printed area in the slicer (and us custom Z probing points to probe the square)
Currently there is no facility to shift the origin when using polar kinematics. This is on the todo list and I may be able to bring it forwards. Meanwhile you can use your slicer or the workplace coordinate system to shift the origin.
- When moving the printer in the control panel/DWC are the X/Y movements linear or in the axis system of the printer?
Linear. You can also use G1 H2 commands to move individual motors.
- Can you set the print head accelerations separate to the axis accelerations? I'd imagine at the end of the reach you'll need to have a lower peak acceleration or even with the best design you'll get inertial effects on the print quality?
No, acceleration and speed limits are implemented in Cartesian space only.
-
@dc42 Thanks, all makes sense and I don't see any of those being a blocker!
-
So got another question that's stumping me.
Will the nozzle have to be directly on the axis (so move directly to/away from the pivot) or will the kinematics he able to handle an offset? I've done a few paper drawings of the effect of an offset and I get a skewed shape so it'll need to be calculated in the firmware if I'm right in thinking?
-
@oliverracing as far as I know it must be exactly on the axis. A change in firmware would be possible by adding M669 parameters and calculating kinematics and inverse kinematics, but it is not implemented (yet). It would be nice to have it, in case one has a displacement and want to change the config setting instead of changing the mechanical construction.
-
Ok, that should be fine although being able to do in the fireware would be great too, I'm just trying to take everything into account when doing the mechanical design so will add in adjustability to the offset.