Motor stutter or jitter when cutting arcs near top of sheet--

Troubleshooting MakerMade
21

David, et al
Thank you for the very helpful information. Lots to think about…
I’ve been thinking a lot about the configuration and calibration, particularly saving calibration settings to nonvolatile EPROM. For some reason it appears that successive attempts are supposed to improve the accuracy–this may stem from the Holey calibration?? I’m not sure. I think that this is a problem. It should be set once correctly and be saved–and not changed until there is a modification to the device or there is significant wear on the components. Otherwise it is a moving target. If successive approximation is required, there is something wrong with the design–it has too much play. Please correct me if am wrong in this assumption. If you have ever done timing on a car engine–similar to calibration on the Maslow. You do it once. If it is set correctly and you don’t need to change it unless there is wear or a some modification. This is a simplification of a very complex process, but you get the idea. I stand by my statement that the sled should always go to 0,0,0 every time when you hit the home button.

Back to the problem of the stuttering. I am going to try both slowing down the movement, and reducing the back pressure from the spring that is attached to the chains (I’m using a 16" spring with the original cog gears). Now that I have increased the top beam to 12’, I think that additional width has increased the spring tension which may be adding addition force (load) to the motors making them work harder.
Also my sled has a linear slide with a ballscrew which is rather heavy (26#'s). I had factored this into the calibration, but it may be a bit too heavy. I have added an HDPE ring under the sled to reduce friction.

I’ve been toying with the idea of adding drag chains to add additional ‘pull’ into the lower corners.
Please see the attached photo of a working model using plastic chains and gears. I’m not sure this will work but I’ve found, as you’ve said, that there is very little force in the lower corners. My intention is to be able use the full 4’x8’, possibly even 4’x10’ to create my arc templates.

image
image1248×831 145 KB

The lower chains in the ‘model’ will be spring loaded. I’ve found that I would need a rather long pair of chains. As you’ve said most force will be required in the lower corners. I need to figure out how to only add enough spring force to complement to motor chains and not over power the upper corners. There are other concerns with this approach such as replacing the work-piece, but this is not significant
Looking forward to your thoughts.
I’m hoping the stuttering is easily solvable. I will work on it tomorrow.
The endless calibration is a continual annoyance.

1 Like
22

Hey David,
Would adding thermal paste to the heat sinks held dissipate the heat?

23

David,
I did cut the speed in half and it greatly reduced the jittering.
I now have only 5 ‘jits’ pretty evenly spaced.
Regarding the power, I’m using 12 volts, 5 amps.
Is it possible to up the amperage without damaging the board?

24

Yes, the board and motors will only draw what they need, if they try to draw
more than the power supply can provide, the voltage will drop under load.

David Lang

25

I’ve been thinking a lot about the configuration and calibration, particularly
saving calibration settings to nonvolatile EPROM. For some reason it appears
that successive attempts are supposed to improve the accuracy–this may stem
from the Holey calibration?? I’m not sure. I think that this is a problem.
It should be set once correctly and be saved–and not changed until there is a
modification to the device or there is significant wear on the components.
Otherwise it is a moving target. If successive approximation is required,
there is something wrong with the design–it has too much play. Please
correct me if am wrong in this assumption. If you have ever done timing on a
car engine–similar to calibration on the Maslow. You do it once. If it is
set correctly and you don’t need to change it unless there is wear or a some
modification. This is a simplification of a very complex process, but you get
the idea. I stand by my statement that the sled should always go to 0,0,0
every time when you hit the home button.

the problem is that we do not have a good mathamatical model of the maslow, and
we do not have a calibration routine that can figure out how to correct things.
Search for the thread ‘sources of error’ that I started to list all the possible
causes of error.

In a perfect world, you are correct, we could calibrate once and be done, but in
practice, nobody has measuring tools that are accurate enough to measure
properly.

tape measures are graded as class 1, 2, and 3. over a 3m distance, a class 1
tape is supposed to be ± 0.4mm, a class 2 ± 0.9mm and a class 3 is anything
worse. see

when you are trying to calibrate a system with dozens of unknowns, using only a
handful of measurements, and those measurements produce errors as large or
larger than the accuracy you are trying to get out of the machine (which is
<0.4mm) it’s a problem.

the holey triangular calibration is a significant improvment over our prior
methods.

Back to the problem of the stuttering. I am going to try both slowing down
the movement, and reducing the back pressure from the spring that is attached
to the chains (I’m using a 16" spring with the original cog gears). Now that I
have increased the top beam to 12’, I think that additional width has
increased the spring tension which may be adding addition force (load) to the
motors making them work harder.

if you can make the top beam higher, that will decrease the tension along the
top

you don’t want more than 4-5 pounds on the slack side of the gears, or in the
bottom corners there is more tension on the slack side than the sled side, and
the motor turns compared to the sprocket to take up the backlash (introducing
error)

weights on the slack side are better than springs, springs produce the most
force when they are extended , which is when the sled is in the bottom corner
and needs the least force. Weights are at least constant force.

Also my sled has a linear slide with a ballscrew which is rather heavy
(26#'s). I had factored this into the calibration, but it may be a bit too
heavy. I have added an HDPE ring under the sled to reduce friction.

yes, that is a bit heavy, and can make the motors run out of power earlier

are you aware of the spreadsheet that lets you calculate the forces on your
machine? see what the results are with your setup. If the top beam is the same
height above the workplace as sock, just longer, that gives you more grief along
the top, a heavier sled gives you more grief along the top.

I’ve been toying with the idea of adding drag chains to add additional ‘pull’ into the lower corners.

there’s been a lot of people talking about doing that, but figuring out how to
control it so that it pulls towards the corners with a prdictable force is a
non-trival task (see my comment above about not having a mathamatical model that
fully depicts all the variables in the current machine)

Please see the attached photo of a working model using plastic chains and gears. I’m not sure this will work but I’ve found, as you’ve said, that there is very little force in the lower corners. My intention is to be able use the full 4’x8’, possibly even 4’x10’ to create my arc templates.

image
image1248×831 145 KB

The lower chains in the ‘model’ will be spring loaded. I’ve found that I would need a rather long pair of chains. As you’ve said most force will be required in the lower corners. I need to figure out how to only add enough spring force to complement to motor chains and not over power the upper corners. There are other concerns with this approach such as replacing the work-piece, but this is not significant
Looking forward to your thoughts.

not seeing the diagram, but the basic problem with anything spring based trying
to pull it towards the corner is that it provides more force the further you are
from the corner, which means that the opponsite corner spring will provide more
force pulling towards it than the near spring will provide, exactly the opposite
of what you need.

David Lang

I’m hoping the stuttering is easily solvable. I will work on it
tomorrow. > The endless calibration is a continual annoyance.

26

it’s better than nothing. If you have time, watch the ‘tech ingrediants’ videos
on testing thermal compounds.

David Lang

27

forgot to include the link to the spreadsheet

28

David,
Thank you for the wealth of information. It is really helpful in understanding the issues that trouble Maslow users. I’m hoping that in the near future we can somehow solve them, or at the very least make them much more manageable. I think I mentioned that I am somewhat obsessed with accuracy. Someone once told me that quality is infinite. So is I imagine accuracy, which is a form of quality. I think that 1/32" accuracy is an achievable goal (although I prefer hairline).
Perhaps the ‘sloppiness’ of the Maslow system may be inherent in the hanging chain/triangulation design, but to my thinking this is not insurmountable. A good place to start would be locking down the configuration settings. If we cant do that we will all forever be stuck in an endless loop of continual errors. We need a benchmark. A fixed place to start improving the system.
A mathematical model, similar to your spreadsheet, that contains all significant variables would be a great place to start. Also, as you mentioned using springs to control the chains injects a whole set of issues. Counterweights are much more quantifiable.
One of the problems, I believe, is that each user has a slightly different frame. The nominal size of the work surface, 8’x4’ should not be a great concern. The height of the motors is more-so. Ranking the variables in importance my be helpful.
Also the precision calibration should be automatic. There is no reason to have to move to each location, manually, to make a mark. It should run continuously from start to end. Using a Sharpie on tape allows for repeatability, cutting holes each time does not.
Perhaps refining the frame element would be a good place to start–I’m not really sure. Also, perhaps, this is an issue that concerns only a handful of us…

29

Perhaps the ‘sloppiness’ of the Maslow system may be inherent in the hanging
chain/triangulation design, but to my thinking this is not insurmountable. A
good place to start would be locking down the configuration settings. If we
cant do that we will all forever be stuck in an endless loop of continual
errors. We need a benchmark. A fixed place to start improving the system.

continual calibration shoudl not be needed, the settings should be saved.
however, if things aren’t parused when the system looses power, it doesn’t know
where it is and so you need to reset the chains next time you power on.

A mathematical model, similar to your spreadsheet, that contains all
significant variables would be a great place to start. Also, as you mentioned
using springs to control the chains injects a whole set of issues.
Counterweights are much more quantifiable.

springs/counterweights should not make a difference unless they are too strong
(invoking backlash)

One of the problems, I believe, is that each user has a slightly different
frame. The nominal size of the work surface, 8’x4’ should not be a great
concern. The height of the motors is more-so. Ranking the variables in
importance my be helpful.

motot-motor distance, height above workplace, and weight of the sled aer the top
3

Also the precision calibration should be automatic. There is no reason to
have to move to each location, manually, to make a mark. It should run
continuously from start to end. Using a Sharpie on tape allows for
repeatability, cutting holes each time does not.

since the weight of the sled matters, how do you replace the bit with a sharpie
without affecting the weight?

I hear that one of the software varients has a calibration that doesn’t drill
holes, but I’m not sure ho it works.

Perhaps refining the frame element would be a good place to start–I’m not
really sure. Also, perhaps, this is an issue that concerns only a handful of
us…

keep asking questions and making suggestion, a lot o the maslow has been
designed/refined by people like you (and me) who started out as users looking to
improve things.

David Lang

30

David
Do you have any idea who does the programming for Makerverse or EastBay systems? Are they open to suggestions? Is this open source? If so, are we able to look at the programming? I assume Python or C. Where can the source code be found? Github?
One other thought regarding calibration. Cabinet makers and contractors often use diagonal measurements to check for ‘squareness’. It seem this approach might be worth considering in simplifying the calibration process. The sled/router bit could just check 4 corners and compare the two diagonals. The center points could be added as a cross check, if necessary. Really for the Maslow system ‘squareness’ ought to be a major consideration. It would tell us a lot about our configuration/calibration accuracy.
One final additional thought. Have you ever considered modeling the system in Autodesk Inventor? Inventor allows for dimensional modeling with forces and weights. I’m pretty sure if it allows for movement as well.
Thanks

31

the code is opensource on github

I won’t pay autodesk for their software as they refuse to consider it a sale.

part of the problem is that there are just so many unknowns involved, for
example, on the chains, what is the gap between the pin on the chain and the
hole it’s rotating in. If it varies by 1/1000 of an inch then the chain length
can vary by 1/2 inch once you feed out 500 links (the 10’ of chain to reach the
opposite corner), the weight of the chain (and therefor the amount it sags under
any specific tension) will vary from manufacturer to manufacturer.

The holey calibration routine is designed to be based on the diagonal
measurements. the errors tend to be symmetrical around the center of the
machine, but (depending on the chains and the motor mounting) may not be eactly
the same on each side, so you can’t just go from one edge of the workpiece to
the other edge (and how square is the workpiece? and how precise are it’s
dimenstions) I understand that one of the newer kits includes a different
calibration routine that doesn’t drill holes, it may use the edges of the
workpiece. I have not looked into that in much detail.

here is the thread on sources of error

part of the fun in designing a calibration routine is that the errors almost
never manifest themselves as linear errors, they tend to be curves (up/down or
left/right) and different error sources can result in similar looking error
curves, so figuring out which of the many things is in error to fix is an
unsolved problem. The current holey calibration only tweaks a few of the
settings to try and correct the error. It tends to do a pretty good job, even on
the first pass, but depending on your measurement accuracy (see the tape measure
discussion), it may improve things to re-run it a couple times.

David Lang

32

by the way, please don’t take my comments to be telling you that you shouldn’t
do this, I’ll help as I can. I’m trying to point you at existing work/thinking
on the problem and just set expectations that it’s a harder problem than it
would seem at first glance.

David Lang
k

33

I’ve been reading the thread with interest, and as usual, learnt a lot!
I’m too new at this to offer any real insight into the kinematics, but I have noticed when I translate a design through SVG, Inkscape to GCode, if I specify too high a ‘resolution’ in creating the path (or just forget to check the defaults), Inkscape will produce a path with a ridiculous number of nodes along a given curve. And then the Maslow will exhibit that ‘chattering’ behaviour. But not on every curve! Go figure!
It appeared in the cut as little ‘swirls’, rather than just a smooth line (very similar in appearance to the attached photos).
I just assumed I had exceeded the processing power of the Due at certain points in execution of the GCode.
Anyway, dropping the resolution greatly reduced the number of nodes, and seriously improved the performance of cuts, without altering the practical quality of the outcome.
For what its worth…

34

ahh, good point, I had forgotten about that.

What is happening is that if the gcode specifies an arc (G2/G3 command) and the
start and end of the arc are the same, that is telling the machine to draw a
circle.

There is a problem with the arduino in that it can’t handle too many digits of
precision, so if the arc is very short, the positions get truncated and become
the same, atchich point the machine cuts a circle instead of a very short arc.

There is a gcode optimizer thread here pointing at some code that simplifies the
gcode and looks for very short segments and eliminates them.

If your CAM is producing too many very short segments, the machine gets really
slow (there is a limit to how many lines per second of gcode it can process, as
well as the limit to how fast it moves). In extreme cases, ‘stopping’ (or almost
stopping) too long in one place as it’s working through teeny-tiny line segments
can generate too much heat from friction and burn the wood or start a fire in
the chips/sawdust.

in your CAD, it’s best not to have shapes with smaller dimenstions than your bit
(you can’t cut anything saller afte all), and (if you have a CAM program that
doesn’t generate G2/G3 arcs/circles) having rounded inside corners means that
they get converted into lots of tiny movements, which at best slos the machine
way down.

David Lang

35

@dlang - good explanation!
GCode Optimiser thread? Couldn’t find it.
Is there a link?

36

try this (dug up from my email)

1 Like
37

O00o00h I’m famous - and still listening - mind you - working on ‘other stufffff’

38

CTRL + L in inkscape will reduce the number of nodes in your drawing and sometimes to its detriment, but you might try that to cut down on the chatter.

1 Like
39

Greg,
This describes exactly what was happening at the top of my arc. Little ‘swirls’. Funny thing though, all of my template that I’m trying to cit is comprised of the same arcs–the only straight line is at the lower right corner. It template design was originally produced in Autocad, then ported to Fusion, then into G-code via Fusion. The swirls are definitely something to think about. I’m not sure how I go about dropping the resolution. I will need to investigate further.
Thanks for the great insight

1 Like
40

No Worries, @ceka
The thing I REALLY like about this forum is the selfless contributions made by the Community to help out anyone having problems.
I’m off to try out @md8n and @Orob suggestions!
Of course, now you need to ‘pay it forward’ and help some else in the future.
Greg