CoreXY with rotating bed
-
@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)
