CoreXY with rotating bed
-
I'm trying to understand the command M669 and how to set the correct kinematic.
I'm working on adding two rotational axes to a fixed printing bed in a coreXY printer, which is similar to a robot 5-axis cnc in table mode
https://docs.duet3d.com/en/User_manual/Machine_configuration/robot_5_axis_CNC#bc-tabletable-example
but X and Y axes are coreXY instead of Cartesian axes. I'm not sure if there is a way to implement a coreXY to any defined two axes.
Also, is there any clarification about the M669 command used in the above link? is it M669 K13 or something else? -
@ghazi
I'd use M669 K1 for CoreXY but then add your own matrix (as shown in the examples) for all axes. -
@ghazi are you doing the kinematics in your toolpath generation workflow or expecting the firmware to handle the kinematics for the two rotary axis?
@JoergS5 has a fork of RRF where he is working on adding Kinematics for this sort of machine to RRF.
If you are doing the kinematics yourself (like, e.g. @Freddiester's Open5X in Grasshopper) then you can just define a corexy printer and then add two rotary axis and send the XYZ position you want + the absolute rotations of A and B
-
I'll build CoreXY support into robot kinematics. CoreXY is a closed chain, because two steppers are connected, but not too complicated. Then rotary axes AC, BC or AB can be added to it. The man who invented CoreXY had a great idea, guiding the gantry from two sides and only needing 3 motors for 3 coordinates.
-
@o_lampe It is my first time using duet board and I will try adding my own matrix for all axes
-
@t3p3tony my slicing code is going to produce only gcode file. One solution I thought about is coordinate rotation G68 for rotational axes, but then I have to figure out how to run multiple motors at the same time. This morning, I thought all that can be resolved if I switch to relative coordinates instead of global
-
-
@ghazi said in CoreXY with rotating bed:
I cannot find it
I have removed it, because I'm currently building a new fork based on RRF 3.5. I am currently testing a lot, then I will publish. I've added CoreXY to the documentation and add it to the first release. I will not be able to completely test it, because I have no CoreXY, so it would be nice if you can do it.
https://docs.duet3d.com/User_manual/Machine_configuration/Configuring_RepRapFirmware_for_a_Robot_printer a new B parameter.
I've also added a chapter to the CNC 5 axis specific page:
https://docs.duet3d.com/en/User_manual/Machine_configuration/robot_5_axis_CNC
where I will add an example configuration. -
@joergs5 My guess is that the next update RRF 3.5 will take awhile. Is there a way to modify the matrix of the CoreXY for the table mode? I read the paper cited in the doc "Transformation of CAM Data for 5-Axis CNC Machine Spinner U5-620", and the only difference is the equation (7) T^t_0 = CoreXY instead of Cartesian matrix. However, I see the given example of a modified CoreXY kinematics in the doc does not have any change in printing bed orientation nor X, Y, or Z offset distance.
-
@ghazi I have the code ready and will post it the next days (maybe weekend). An open point is the Denavit-Hartenberg configuration, which is complicated for AC. I was not able to configure it correctly today and will proceed tomorrow. Rotating the coordination systems makes one dizzy...
Having the configuration tested is necessary because I provide templates called B"robotType=..." which makes the task easier for users. The CoreXY part works well and as expected. I will provide binaries, for which hardware do you need binaries? I will create Mini 5+ for me (7 axes together with the Mini 2 addon) first.
I will place the binaries into https://github.com/JoergS5/RRFRobotBinaries
and for compiling yourself, the code will be in the 3.5-dev branch of the RRF fork https://github.com/JoergS5/RepRapFirmware -
@ghazi said in CoreXY with rotating bed:
only difference is the equation (7) T^t_0 = CoreXY instead of Cartesian matrix.
to answer this question, this transformation must be split into two: one for the Y axis and the other for the X axis, and the actuators must be split into 1/2(A+B) and 1/2(A-B), i. e. delay calculation until both angles are calculated. The Jacobian is calculated separately for stepper A and B. But this is all in the code already.
-
This post is deleted! -
This post is deleted! -
I made much testing last weekend, and must confess that I found bugs, among them one serious one. It's a warning for me to test more. I started to unit test all methods and I am nearly finished. Sorry for the delay.
-
@joergs5 Thanks, please keep me updated
-
@Ghazi I've tested alot lot now.
The errors I had were from random angles and trying to move there. This is not possible always, as source and targets are in different work modes. When I don't try to change work modes, it works as expected.
(explanation work modes, for users who do not know it: every position and orientation on a 6 axis robot can be reached by different robot arm positions, up to about 8 possibilities. They can be only crossed by explicit robot angle changes).
I'll proceed with creating the firmware now. I currently can work at weekends, so my goal is to finish it next weekend.
When building the CoreXY 5 axis, please be aware that the A axis has a critical angle of 0 degrees where a singularity can happen, because the C axis can be parallel to the Z axis. This should be avoided, e.g. by staying in the positive or negative A angle. Mechanical construction so that A can stay in negative or positive, I mean maximizing this range, would IMHO be the best solution. If think, if the goal of the 5 axis is to print overhangs, the maximum tilting needed would be a parameter.
The singularity can be crossed by setting C axis rotation to 0 (the firmware can do this), but the result is a movement which is not correct. I'll probably add a new flag in configuration to turn on or off the possibility to run in singularity or not. If not, outputting an error message to the console and stop printing. (to allow finding this in simulation mode)
