I am building a new printer kinematic that works like this:
I got the kinematics calculations working, and even got it homing but I still don’t understand what forcepos and movepos parameters of homing_state.home_rails are meant to be. Is forcepos a made up toolhead position prior to homing, and movepos where the homing ends up placing the toolhead?
If so I have a bit of a problem adapting this to my kinematic set up. There is no valid position such that both of the belts would traverse the full range from anywhere within the print volume, when going to the position where it homes at.
Is there any way to home in a more “raw” way, just turn on both motors until they hit the endstop or make a move longer than set maximum?
Yes. The idea is to force the kinematics to think the printer is at forcepos then the stepper motors move as if the toolhead was moving from forcepos to movepos, but should the endstop trigger during that movement then the steppers will halt. Wherever the carriage ends is then considered to be movepos.
Alas, that’s not particularly easy. This also came up with some scara kinematics. I understand that @Bondus got it working by changing home() to reassociate the stepper kinematics with a cartesian style kinematics stepper.set_stepper_kinematics() performing the homing movement using cartesian kinematics such that each stepper moves at a constant velocity, and then reassociating the stepper kinematics with the main kinematics once homing completes.
Thanks, that makes it clear! I had a lot of initial confusion because of false triggering of endstops (I tried to use sensorless homing) resulting in it backing off a weird distance dependent on the difference of forcepos and movepos.
Reassigning the kinematics is an interesting idea. Ideally I think it would be good to have “raw” move functionality because non-Cartesian designs may need it for various set up reasons, especially those with redundant constraints (like e.g. winch printers where I imagine the calibration step would involve some custom g-code turning some motors off and running others to force the print head into a known position).
I guess I could make it home a second time if it fails to home the first time? That seems like it should be easy.
The meat of the trick is in init where a cartesian kinematics is created and in home(). The code is a bit old and might not work properly anymore, but the idea works.
With my kinematics the idea is that the “>” - looking arm is only providing stiffness in the Z direction, so it can be made very lightweight (but I’m not going to do that until I’m happy with the dimensions of everything). The belts provide all the kinematic stiffness, so the belt tensioners can also be lightweight.
Another thing I can do is placing a smaller lighter arm at the tip of the large arm, with foam damped joints. That would reduce inertial forces; for example if I want to get from 1m/s to a stop over a distance of 1mm, that’s 50G acceleration; but with 1cm it’s 5G . So if most of the mass is doing it over 1cm and just a bit of the mass over 1mm, that should reduce forces on the motors.
Basically that’s the reason for the strangeness, I want it to be capable of very high accelerations.
edit: come to think about it, my set up is kinematically very similar to controlling a 5 bar SCARA on elbows, except where you have alpha I have approximately 2*sin(alpha/2) . (I also have small corrections for the pulley radius etc). I’ll post a new video soon, still making a lot of mechanical improvements.
I may very well end up using a 5-bar linkage in place of the “>” arm because that may be lighter for the same stiffness in z direction. I may also try a hinged Peaucellier-Lipkin linkage for my z constraint, that has the potential of giving very flat motion derived simply from equality of part lengths (meanwhile an arm’s movement is only as flat as the joints are parallel).
edit: by the way just in case it is helpful for anyone else also working on new kinematics, I implemented my calc_position as a numeric solver on the C kinematics (accessed via calc_position_from_coord):
That makes it easy for me to iterate the way everything links up. The basic calculation is straightforward but corrections for nonzero pulley diameter are tricky and highly dependent on how my belt tensioners attach to the arm.
