Triperon Motion
-
@fcwilt said in Triperon Motion:
What is the raison d'etre for such machines?
There are very few machine designs -- for printers or otherwise -- that are linked in parallel, in 3 or more axes, and also linear kinematic mechanisms. Of those, the multipteron family are the simplest.
The general benefit of parallel machines is high dynamic stiffness without needing to move one actuator with another (serial linkage), which can compound the error of one axis with the other due to the coupling. The side effect is you can build a 3D printer with a fixed bed and all fixed motors.
-
@Apsu said in Triperon Motion:
The general benefit of parallel machines is high dynamic stiffness without needing to move one actuator with another (serial linkage), which can compound the error of one axis with the other due to the coupling. The side effect is you can build a 3D printer with a fixed bed and all fixed motors.
Thanks.
Is it hard to get the "slop" out of the joints?
I understand your comment about serial linkage but it would seem, from an "outsiders" point of view, you've traded one engineering challenge for another.
Frederick
-
@fcwilt Joint slop is quite easy to take out with one of these types of arrangements, as preloading radial bearings is exactly the method used for doing so in machinery. There are many articles and data sheets discussing taking slop out of radial bearings by preloading, as well as different preload approaches (and when you might want to use angular contact or tapered rollers, etc) out there in the wild. Like https://www.nationalprecision.com/info-library/technical-data/bearing-preload/ or https://www.skf.com/binaries/pub12/Images/0901d1968065f1f4-Bearing-preload_tcm_12-299896.pdf for example.
Back to back and face to face are both very common setups for wheels and shafts, from bicycles to engines to skateboards. Getting the joints stiff is pretty easy. Designing the housings and connections and arms to handle the large lever and twisting forces is the real challenge.
-
-
If you need another excuse to build a monorail Tripteron, imagine you have four of them surrounding the printbed.
-
@Apsu said in Triperon Motion:
You are indeed correct that it is not delta movement. It is completely linear, and described by a linear matrix/system of linear equations. All Tripterons are...
If that is the case, then standard RRF supports Tripterons, and there is no longer any need for custom kinematics. Use the M669 command to specify Cartesian and use the XYZ parameters to modify the matrix.
-
Hello,
I'm just trying out the delteron from Apsu, does anyone have a working config.g for duet wifi board? ...could you please show this here?
My hardware is printed, smart effector is here, so I can start building this into my Kossel XL.Best Regards
Peter -
@speedpete you'll need to build your own firmware from my fork https://github.com/oliof/RepRapFirmware/tree/colinear-tripteron
-
@speedpete also you need to brace for disappointment, there is a lot of inherent backlash in the Delteron
-
@oliof
that looks more complicated that I can handle ...What is with "If that is the case, then standard RRF supports Tripterons, and there is no longer any need for custom kinematics. Use the M669 command to specify Cartesian and use the XYZ parameters to modify the matrix." from DC42?
DoesnΒ΄t that work? IΒ΄ve found no one showing such a config.gBest Regards
Peter -
@speedpete there are two different kinds of Tripterons:
-
Orthogonal Tripterons in a box frame -- These use Cartesian kinematics and can be run without any changes to firmware. You could use the RepRapFirmware configurator to create a config.g for these.
-
Colinear Tripterons in a delta frame like @Apsu s delteron -- these use their own kinematics as implemented in my fork and need firmware changes. I'll need to check whether it can be done as @dc42 says, but back in the day I couldn't make it work (but that's probably my lack of understanding and not a limitation of the firmware).
-
-
@dc42 these are the inverse kinematics for colinear tripteron
/* Inverse Kinematics * * 3x3 reduction coefficient matrix * 1x3 coordinate matrix * [a_x -a_y 1] [x] * [b_x -b_y 1] * [y] * [g_x -g_y 1] [z] */
How'd that be expressed in M669?
But besides that I needed arm angle and the height at which the machine homed plus some correction factor (which thinking about it today might be dropped in favor of adjusting steps/mm...) for proper movement, as well as delta style homing at the top (because the motors move the arms colinearly and not in a Cartesian fashion). I may pull out my prototype and do some testing; I assume I can drop a lot of my code if M669 matrix definition works.
-
@oliof
That would be very interesting ...nice of you Truly I really depend on you in this case ...so please give it a tryBest Regards
Peter -
@oliof said in Triperon Motion:
Inverse Kinematics * * 3x3 reduction coefficient matrix * 1x3 coordinate matrix * [a_x -a_y 1] [x] * [b_x -b_y 1] * [y] * [g_x -g_y 1] [z] */
How'd that be expressed in M669?
If a_x, a_y etc. are constants, then this:
M669 K0 Xa_x:b_x:c_x Y-a_y:-b_y:-g_y Z1:1:1
with appropriate substitutions for a_x etc.
-
@dc42
so a / b / g is a substitute for the lenght of the arms? ..and I have to find "a matching value" ?Best Regards
Peter -
@speedpete I have a feeling that a_x etc. are not constants but are trigonometric functions. @oliof, can you point me to your reference for the inverse kinematics?
-
@dc42 they are constants, see https://github.com/oliof/RepRapFirmware/blob/colinear-tripteron/src/Movement/Kinematics/ColinearTripteronKinematics.cpp
(sorry I haven't looked at this code in a long time, I am a bit confused).
-
I've now refreshed my memory and with some helpful explanations from @Apsu yes those are all constants.
-
-
@speedpete Grab the formula from my code to compute the constants and then set up the kinematics as @dc42 described. I didn't get around to trying this weekend; I may be able to do this tonight.