Open5x
-
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?
-
@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.
-
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.
-
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.
-
-
@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. -
@joergs5 thanks that great. hopefully @Freddiester can test it as i don't have an Open5X printer (yet!)
-
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/
-
@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.
-
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! -
@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.
-
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.
-
undefined T3P3Tony moved this topic from General Discussion
