UVW axes on a delta printer
-
Sounds great! I will do that. Thank you. In the mean time, is using the extra motor as a tool my best option for a work around? I am creating my own G-code generator, so it doesn't matter to me so much what the axis is called, but I don't want to do something that creates an impossible amount of work to drive, or simply doesn't work.
-
The motion control for your extra axis should be quite easy to implement and I can probably make the necessary changes in the next 1.19 alpha release. The more difficult issue is how homing should work, which needs careful thought.
-
Yes, homing will be a bit strange. I plan on using another end stop for this new axis, and basically treating it as its own 4th coordinate. (X, Y, Z, U) And that is fantastic news that this might be possible in the next release.
-
I am open to suggestions about what homing buttons should be provided for a delta + U and potentially V, W axis printer, what homing files should be used, and how to avoid breaking compatibility for existing users.
-
I'm still thinking about how I would like it to work, given those restrictions. My plan was to add an end stop switch to the U rotational axis. It won't rotate continuously, so when it rotates in one direction far enough it will hit the switch. Basically if it operates in the same way as a standard axis that's all I need. (Although this axis is rotational instead of linear so I end up with the problem of the "steps per mm" requiring a conversion to degrees or radians, but that's easy to do.)
-
Here's a side question related to this. If I want to add my own support for a new kinematic system, is there a way to do it? I have the inverse kinematics all worked out for the system I am trying to implement, but it is unlikely that it will be something you would like to officially support, outside of the small request I made above.
-
It's much easier to add new kinematics in firmware 1.19 thanks earlier versions. You write a new class to represent your kinematics, inheriting the Kinematics base class and implementing the various virtual functions.
I still need to design a scheme to handle the different homing strategies. Some printers home individual Cartesian axes (e.g. CoreXY), others home individual actuators (e.g. delta) and yet others do a mixture (e.g. SCARA).
-
That is awesome news. I have the kinematics worked out, but my programming knowledge is mediocre at best. I'll give it a crack and come back with some questions I'm sure.
-
I am back working on this project again and I see that additional axes are now supported. I'm attempting to go through all of the change logs since 1.18, but so far it has been hard to tell exactly what changes affect this project. Has there been any update to this? I'll continue trying.
-
Support for additional axes on delta printers is present in firmware 1.19. So in theory you can just declare new axes using M584. However, this hasn't been tested.