there are two problems with skinny frames
- the forces involved get high as the angles between adjacent belts get larger
- the arms are limited in how close they can get to the posts, and when they
hit their limits, the arm and belt are no longer inline
if you have a skinny frame, what I would suggest is that you plug the numbers
into the calculator and make sure that you are only doing your calibration
within the green area.
when you are cutting, you can probably go outside the greeen area by a couple of
bands without noticing much in the way of errors, but the calibration is much
more sensitive to problems (either due to angles or to belt stretch, which is
why people express concern about high current limits during calibration)
Dylan Taft wrote:
I think I can do a PID loop that makes magnetic encoders driven pwm DC motors
look like servos for better compatibility
that would be a fantastic step forward, right now, a lot of the maslow specifics
are more hard-coded than they should be. expanding fluidNC to be able to define
a “motor” that is actually a DC + encoder would be a huge long-term win.
when looking at the kinematics, lookup the term ‘cable driven robot’ and you
find the right calculations.
unfortunantly, even chains and steel braided cable have a surprising amount of
stretch in them (and with chains, the weight of the chain becomes significant
and you start having to account for sag that you can get away with ignoring with
lighter material)
…redoing something like a motion planner is way beyond me…
that’s core fluidMC stuff, not something you should have to worry about
but one problem that a PID DC motor setup has is that the response
(acceleration) lags behind what a stepper would do (until the stepper starts
skipping steps), so you may want to see if you can hook in to the output of the
motion planner rather than the output of the stepper driver so that you not only
know the position and speed, but what acceleration is desired and feed that into
the PID loop
It feels like stretch can be modeled by keeping a running number of additional
retraction to keep belt tension. It can be measured diagonally easily at
different points along a hypotenuse…
please try it. I think the biggest problem is that there are so many causes of
unpredictable friction that we don’t really know the forces involved.
From there, ignored..wouldn’t the belts move like normal triangles if kept tightish? Move slow and just do trilateration.
the calculations are actually pretty simple right now, an abc triangle + anchor
and arm lengths (with a multiplier available for people to try and fudge things
for belt stretch, but that’s not doing anything by default)
I might just abandon frame edits and try a port…vastly easier to do things
like restore known belt lengths on powering up
This is a big todo item that keeps getting pushed back as we try to figure out
these calibration issues.
there is code in place to try and save the Z position when the machine pauses
for a few seconds, we need to tie into that to save the belt positions as well
(and then restore them at startup)
This would also be a huge thing to do.
when you don’t have to sync machine state to a web interface…and if
“calibration” is simple math…it can be done on device with custom gcode.
currently this is pushed to the browser as the browser calculations in
javascript are much faster than the calculations on the esp32
it has the side effect that the measurements are available for us to grab and
experiment with other approaches
I think how I want to use the device ultimately is vastly different from how
it is used…
please say more
David Lang