Open5x

JoergS5

Dear Freddie @Freddiester , your 5 axis printer based on 3 linear and 2 rotational axes looks promising for non planar printing.

Reference for other users: https://github.com/FreddieHong19/Open5x and
https://arxiv.org/pdf/2202.11426.pdf)

I am developing robot kinematics and it should be possible to use your setup with this kinematics also, as it is an open chain from object starting with V to the hotend:
V rotational, U rotational, Y prismatic, Z prismatic, X prismatic.
It differs from industrial robots, because object and endpoints are both rotating/moving, and the joint between Y and Z axis is your fixed reference. This is the only addition I have to make to existing kinematics code and would allow other constructions as well.

It would have the following advantages

the axes need not to be parallel (Y and U), the linear axes can be off-perpendicular and can be finetuned to compensate inaccuracies
I use Moore-Penrose calculations to find the way out of the singularity, which you have on top of your object
the axis speeds (angular speeds especially) are limited to config speed limits
a sixth axis could be added, perpendicular to the U and V axis, placed at the base of the white big part, so all rotations would be possible.

Are you interested in trying this alternative kinematics solution?

T3P3Tony

@JoergS5

I was actually discussing your work with robot arms kinematics with Freddie last week. Either using your kinematics implementation, or by implementing the 5 axis Kinematics that Freddie uses already in grasshopper, I would like to see the 5axis kinematics supported in RRF.

The aim would be able to send XYZAB (or XYZBC actually I think from this design) and have the effector/print bed orient itself correctly. That was gcode generated for a 5 axis machine would work with this Kinematics.

My understanding from what you have described is it would be possible to setup you existing kinematics to allow this. What would that look like as gcode configuration?

JoergS5

@t3p3tony I'm currently in the process to make an update to the RobotViewer DWC plugin. The next version will show axis home, min, max angles and some other improvements. For Open5x, this is a first test, which shows the possibility to model cartesian as robot kinematics also, as we discussed:

Left are the G-Code parameter setting for the axes, right is the current view with PPPRR configuration. Left down is the object (but in Open5x this is rotating itself), the white one is the tool.

The axes coordinates look like this:

from left down to right up: Z-X-Y-U-V-Tool, blue are the rotatable/movable axes.

T3P3Tony

@joergs5 said in Open5x:

from left down to right up: Z-X-Y-U-V-Tool, blue are the rotatable/movable axes.

I wont claim to completely understand this image but the plugin image makes sense.

Please let me know when the updated plugin is published.

JoergS5

@t3p3tony said in Open5x:

Either using your kinematics implementation, or by implementing the 5 axis Kinematics that Freddie uses already in grasshopper, I would like to see the 5axis kinematics supported in RRF

It is not necessary to decide which one to take, you can use both kinematics and decide, which one offers more advantages. I'll enhance the robot kinematics to include Open5x, but a version which uses cartesian plus two rotational axes is also a solution, which may need less processing power (but if you want to add a third rotational axis, the robot kinematics will offer a solution). The same holds for polar kinematics and serial scara, which can also be configured with robot kinematics. There are sometimes solutions like solving a singularity situation, needing less processing power or crosstalk, which may be an argument to prefer one solution.

JoergS5

@t3p3tony said in Open5x:

understand this image but the plugin image makes sense.
Please let me know when the updated plugin is published.

I'll tell you. I want to add documentation for the plugin when I have a stable version.

JoergS5

@t3p3tony just to inform you, I have RobotViewer updated
https://docs.duet3d.com/en/User_manual/Machine_configuration/RobotViewer_DWC_plugin
https://forum.duet3d.com/topic/28492/robotviewer-dwc-plugin
The template for Open5x is included as an open chain configuration, but the main logic is in the CAD program and the slicer, avoiding object collision, the hotend being vertical on the object, and the object holding to print without support while printing. The firmware can watch and limit the maximum angle speeds, in case they are violated.

T3P3Tony

@joergs5 thanks that great. hopefully @Freddiester can test it as i don't have an Open5X printer (yet!)

JoergS5

FullControl, a program to directly produce G-Code, will be migrated from excel to python based in a few months. This information tells that it will support 5 axis printing:

https://www.reddit.com/r/FullControl/comments/v7ks4a/python_version_update/

Maybe interesting for Open5x.

FullControl homepage is https://fullcontrolgcode.com/

T3P3Tony

@joergs5 yes indeed. full control is a different method to generate paths (not based on a CAD files), which is awesome in applications that suit that method.

Freddiester

@joergs5

Hi Joergs,
Sorry for picking this forum so late. I am picking up 5-axis work again soon.
The RobotViewer sounds really useful plugin for DWC & Open5x, especially to avoid the collision!
I will get my hands on it soon and share the progress!

JoergS5

@freddiester Dear Freddie, there is a limit of the current RobotViewer, because it doesn't fit completely with Open5x. The current template is from base to hotend in one chain. The result of position and orientation calculation will be correct, but not objects' orientation and hotend orientation not yet.

Your hotend is always vertical (or near vertical) and the printed object rotates by 2 axes. The typical robot has one base and one rotating hotend, the object fixed. In the first post I made a suggestion to fix the coordinate system between Z and Y. *) I'll build it into the RobotViewer into the next release.

*) this will allow to build two arm robots as well, with the fixed position in the middle.

I agree that collision detection is very important, which will need additional definitions of the nozzle size and form e.g. Touching a tilted already printed wall would destroy the print otherwise.

I will build an Open5x and test kinematics and RobotViewer for it. I currently build strain wave gears 3D printed, this may be interesting for U, V also.

JoergS5

There is a thesis of Grutle https://www.duo.uio.no/handle/10852/47652 from 2015 which is similar to Open5x and interestingly used Duet hardware. It offers additional information about ABC to IJK conversion and printing results.