I finally have some time to get my latest Morgan on Klipper.
Coming from Smoothieware it has been somewhat hard to figure out how everything fits together, especially with the multi-language setup. Progress is slow. My reason for finally trying something other than Smoothieware is due to the shortage of Smoothie-compatible printer controllers and the exorbitant price that the few purveyors of the boards charge for those boards. I also have an issue where the boards pause for seconds, causing blobs in the final print. This could be to do with the load the SCARA kinematics puts on the MCU, but it affects all my machines currently.
Prototype Spec:
Printer Model: Morgan Pro 3
MCU / Printerboard: MKS S.Base (Smoothie compatible)
Host / SBC: Raspberry Pi 4
Work in progress repository:
EDIT: I tried with Delta homing and it works perfectly.
I am focussing my work on the next stage, to get the SCARA kinematics working. I am starting over using DELTA kinematics as a base to start off from after getting lost in the apparent complexity of the kinematic system, and trying to hack at non-responsive firmware is frustrating.
The plan is to slowly turn it into SCARA kinematics, fixing things as I break it - step by step.
If anyone has SCARA kinematics properly working, let me know. I found many abandoned SCARA WIP projects on Github, and I tried to learn from them, but I noticed that all got stuck on similar issues I had done so far.
I managed to fix the kinematics using my old friend, MATH…
I don’t know why the GET_POSITION stopped working. I did not touch anything except adding the kinematics code according to the guide.
I think I will rebase the kinematics on the latest klipper/master to be sure
Not done by a long shot though. Need homing and calibration.
Ok, the kinematics are now working correctly and passes the build.
I added a link to the repo in the first post.
Next step would be to figure out how to home the rails. Ideally, the kinematics should be switched to cartesian when homing since the arms can collide if the start position is on the other side of the column.
Is there a way to switch kinematics during homing?
The issue is that the arms could be in a position that will cause a collision of the arms with each other if homing is performed with kinematics active.
All I need is even linear movement on at least the two arm steppers, and that will cause the arm to rotate around the base without changing the angle until the first end stop is reached, by which time the arms are safe.
On the older morgans, there is an extra complication in that the distal link can not switch over to the other side of the proximal link because the drive arm is in the way:
I don’t understand why you can’t achieve that homing behavior, when you are defining your kinematics - you free to redefine homing sequence as you wish in “def home” which is located in your kinematic code.
Ok, I tried changing the kinematics before homing and changing it back. Something in the movement code gets extremely upset when I try this.
I want to try to disable the kinematics inside the c function, but the trouble would be sending a flag to the kinematics called from the home module. There is currently no homing flag in the struct stepper_kinematics, or anything similar I can see.
I don’t think I should touch the homing code module to make it work, but it looks more and more like something I would have to do to get my robot homing operational.
Hi Kevin, thanks for sending the link again. I will play with it this coming weekend, time permitting, I think the first time I looked at the code I was too bewildered to see what was right in front of me
So far so good in my initial tests. The movement is super smooth and responsive, and I think it will be the first time I run a Morgan under “real” trigonometric functions, not the fast math equivalents.
