Backlash

[Mark]

I spent some time playing around with the "Lash" setting in ReplicatorG last night, to try to eliminate some print issues I was seeing.  I go things pretty well dialed in with a Lash setting of X=0.0 and Y=0.23.  Not sure where the Y axis lash is coming from (Replicator2), but it was good to get it mostly cleared out.  But, it is odd to me that dealing with backlash is in the CAM tool instead of in the machine parameters.  What this means is that if I get an S3G from someone else, the file won't print well on my machine, because it doesn't have my backlash settings.  Similarly, if I send a S3G to someone else, it won't print well for the same reason.  So, this is a setting that should be on the machine, not in the CAM tool.

 

Is there some reason it hasn't been added into the firmware?

 

The test model I used is attached.

 

Thanks,

 

Mark

[Jetguy]

Actually, I can easily tell you where the lash in Y axis comes from.
On a Replicator 1, the jackshaft where the Y motor then drives the
longer belt to actually move the Y axis is one long shaft that moves
both sides in a Replicator 1 series. Note, the black pillow blocks are
not stock, that's a mod to further increase stability
http://www.flickr.com/photos/90025904@N04/8543340036/
matching left side rear
http://www.flickr.com/photos/90025904@N04/8543339874/
And while I don't have pictures, the front is nealy identical, a long
shaft goes all the way across and the 2 matching pillow blocks are
installed the same way.

However, this is where a Replicator 1 and a Replicator 2/2X are VERY
different.
http://groups.google.com/group/makerbot/browse_thread/thread/3448de22afe6f9ae

The basic difference is that the back shaft, the one being driven by
the motor is now ONLY driving the right side of the Y gantry. It then
transfers the torque to the front pulley, then across the front shaft,
then drives that Y belt on the left side.

So a Replicator 1, the backlash is the short belt, plus the long
belt.
The Replicator 2 and 2X are totally screwed in that you have the short
belt, plus, the right Y belt, then the belt to front shaft, then the
front shaft to left belt. Every motion literally add up that bakclash
and further, is tweeking the entire Y axis from square.In one
direction, it might be square or near square, at that start, movement
in one direction from that point twists the y out of square then
opposite motion twists it back. In short, the system is VERY flawed
IMO. Replicator 1 can be made to be as accurate in Y as it is in X
with the mods I've shown, the only way I see a Replicator 2 or 2X
being even close to right is using a long shaft across the back to
mimic the Rep-1.

>  TestRing.STL
> 121KViewDownload

[makerman]

there are special test objects for backlash.

http://www.thingiverse.com/thing:10524

http://www.thingiverse.com/thing:18227

[Martin Bogomolni]

I -highly- recommend the "ultimate lash calibration" -- 18227

> --
> You received this message because you are subscribed to the Google Groups
> "Jetty Firmware" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jetty-firmwar...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jake]

+1 to the original poster's suggestion for firmware based backlash compensation. I don't know much about the motion planner, it my guess is that this is an 'easier said than done' kind of thing.

[Dan Newman]

On 10 May 2013 , at 7:54 AM, Mark wrote:

> I spent some time playing around with the "Lash" setting in ReplicatorG
> last night, to try to eliminate some print issues I was seeing. I go
> things pretty well dialed in with a Lash setting of X=0.0 and Y=0.23. Not
> sure where the Y axis lash is coming from (Replicator2), but it was good to
> get it mostly cleared out. But, it is odd to me that dealing with backlash
> is in the CAM tool instead of in the machine parameters. What this means
> is that if I get an S3G from someone else,

Personally, I never expect someone else's s3g to print well. Generally,
people tune/calibrate their bot by tweaking the steps/mm for different
axes. And further, every extruder is slightly different and so they
also calibrate flow for each of their extruders. As such, printing someone
else's s3g is always going to be suboptimal (and sometimes downright
lousy).

> the file won't print well on my
> machine, because it doesn't have my backlash settings. Similarly, if I
> send a S3G to someone else, it won't print well for the same reason. So,
> this is a setting that should be on the machine, not in the CAM tool.
>
> Is there some reason it hasn't been added into the firmware?

The general consensus in DIY 3D printing has been that it doesn't
belong in the bot's firmware. Moreover, the bot doesn't understand anything
about the overall geometry -- it just plods along printing one line segment
after the next. As such, it's arguably more likely to make a mess of things if
you have it try to do backlash compensation.

Dan

[Jake]

The general consensus in DIY 3D printing has been that it doesn't 
belong in the bot's firmware.  Moreover, the bot doesn't understand anything 
about the overall geometry -- it just plods along printing one line segment 
after the next.  As such, it's arguably more likely to make a mess of things if 
you have it try to do backlash compensation. 

Interesting, thats actually kind of the exact opposite of other CNC systems, where the backlash is handled by a lower-level setting, in the configuration of the machine.  (EMC, Mach 3, and TurboCNC to name a few, all do this in the machine config as far as I know)

The backlash setting is doesn't really care about the geometry, and the backlash can be spread across several components (belts, leadscrews, gears, etc.) in one axis.   The compensation just knows that when there is a direction change, there are a certain number steps that have to be taken up before continuing processing the line segment.

Interestingly this type of compensation would probably work better on a belt driven makerbot than on, say, a CNC mill.  A mill's leadscrews are often worn int he middle (XY table center) than near the ends of travel, meaning the backlash at the center of the travel could be very different than at the end of travel.  I'm not sure this problem exists on a belt driven system.  Commercial CNC's rely on ball screws with very little backlash so this variable backlash problem doesn't really apply.

I apologize if you know all this already, not meant to suggest that this is new to anyone.  Just strikes me as odd that the 3DP community would go in the opposite direction of the DIY CNC community.

[Jake]

Let me ask a think out loud for a sec and shoot me down if I'm not thinking about this properly.

Lets assume a machine with backlash.  We perform an accelerated move.  The movement starts off slow, to get the mass of the printhead moving.  Since we have backlash, however, the head doesn't move at all until all the slop is taken up.  Then once the slop is taken up, the head jerks forward at a speed higher than the intended initial velocity of the acceleration curve.

Wouldn't this be bad?  Seems to me you want an unaccelerated move as fast as possible just before a direction change to take up the backlash.  If tuned properly, there would be no problem with jerking since you're taking up slop and not actually moving any mass.  Of course, improperly tuned would be bad, every direction change would have a jerk if too many steps are taken and the head is moved by an unaccelerated slam.

The lash module just adds to the dimension, but doesn't take into account the acceleration/deceleration problem.  Based on the 0.23mm backlash mentioned, thats something like ~20 steps.  Maybe at that scale it isn't so important, or maybe it would give us the next great advancement in smooth printing since acceleration?

[Dan Newman]

> I apologize if you know all this already, not meant to suggest that this is
> new to anyone. Just strikes me as odd that the 3DP community would go in
> the opposite direction of the DIY CNC community.

It's my understanding that things went that way for two reasons.

First, there's a much shorter release cycle when changing a slicing
engine than changing bot firmware. And it's a larger group of the
DIY 3D printing crowd who are comfortable tweaking slicing code
running on a desktop than tweaking firmware for within a bot. Combine
that with the group as a whole always being hungry for new features
and improvements. Presto: lots of stuff finds it way into the slicers
and other pre-processors. Much less finds its way into the firmware
itself.

Additionally, and I could very well be wrong here, it's my understanding that,
ignoring the Z axis, most DIY 3D printers have very minimal backlash and what's
there can usually be tuned out sufficiently by mechanical adjustments. That
may further explain why there's not much attention given to the issue on the
software end of DIY 3D printing: because usually it can either be fixed in
the mechanics or the mechanical design is sufficiently poor that the DIY crowd
simply fixes the underlying design itself. That's been my impression at
least. I could well be wrong.

Dan

[Dan Newman]

On 16 May 2013 , at 3:17 PM, Jake wrote:

> Let me ask a think out loud for a sec and shoot me down if I'm not thinking
> about this properly.
>
> Lets assume a machine with backlash. We perform an accelerated move. The
> movement starts off slow, to get the mass of the printhead moving. Since
> we have backlash, however, the head doesn't move at all until all the slop
> is taken up. Then once the slop is taken up, the head jerks forward at a
> speed higher than the intended initial velocity of the acceleration curve.
>
> Wouldn't this be bad?

It assumes there is significant slop. In my experience, there isn't
with the drives systems commonly used -- drives systems chosen for
very minimal backlash. The only exception tends to be the Z axis -- a lead
screw. But that is satisfactorily dealt with by only driving it in
one direction. Further keep in mind that on desktop 3D printers, the
masses being moved around are much less than on a metal-cutting
CNC machine worthy of the name.

Now, if you have a desktop 3D printing bot for which there is a signficant
backlash problem and you cannot mechanically fix it, then yes you may have
an issue not handled by current firmwares such as Marlin and Sailfish.
However, that does beg the question of why use a bot with such a defect?
I suppose it could be inherent in the design specification: i.e., it's
a bot big and massive enough to 3D print an auto body.

Dan

[Jake]

Got it. Makes sense.  Also, this is an Atmega 1280 under the covers, gotta have realistic expectations. :)

[Dan Newman]

On 16 May 2013 , at 3:39 PM, Jake wrote:

> Got it. Makes sense. Also, this is an Atmega 1280 under the covers, gotta
> have realistic expectations. :)

Yeah, don't get me started on the ATmega 1280. Really nice AVR. Now can we please
use something more modern? 'tis why I have an M2 and hope to start running it under
LinuxCNC. (Am waiting on being told which Mesa cards to procure.)

Dan

[Jake]

the only way I see a Replicator 2 or 2X  being even close to right is using a long shaft across the back to mimic the Rep-1

Looking at the 2X, don't think this is a viable upgrade.  The shaft I think would interfere with the top Z-axis mount, unfortunately.

[Mark Kenworthy]

Actually, in commercial CNC machines with ball screws, it still applies.  They do wear over time, and the wear is variable because like the manual machines, most of the work is done in the middle of the travel, so that’s what wears fastest.  So, they typically have adjustments for last at multiple locations along each axis.

 

Like the 3D printer, all the CNC machines are doing is processing discrete moves defined in g-code, so operationally, there isn’t really any difference.

 

If all one cares about is generating code for one machine, then having lash defined in the CAM tool is an acceptable solution.  Otherwise, it doesn’t make much sense, since what it represents is an approximation of the lag in movement on one of the axis.

 

On my R2 (Replicator 2), I have set up 0.0 lash for X, and 0.23mm in Y.  I don’t really understand where the Y axis slop is coming from.  I agree it doesn’t really make sense from something like the torque on the front Y axis driveshaft or belt stretching.  I don’t think the forces in play there would be enough to have that large of an effect.  But, there is certainly something causing the lash, so I guess one of these days I’ll try to determine where it is coming from.

 

I’ll also say that I’m not sure that the X axis lash setting moves things in the right direction, but I need to look at that more.

 

Mark

--
You received this message because you are subscribed to a topic in the Google Groups "Jetty Firmware" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jetty-firmware/Zb4G7Aa9-BI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jetty-firmwar...@googlegroups.com.

[Dan Newman]

I've not seen a 2X in person, but if it's like the Rep 2 then backlash
compensation for motion along the Y axis is likely not a fixed value.
That is, I would expect the backlash like behavior to be more significant
when the extruder carriage (mass) is to the far left than when it's on
the far right. This owing to the stepper motor driving things from
the right end of the system. Little details like this tend to compound
the issue of trying to handle it in an already max'd out uprocessor.
(Folks printing fine detail on Rep 1s and 2s at fast speeds know what I'm
referring to.)

And, there's always the question of whether any artifacts
caused by backlash is significantly more than positioning error.

Dan

[Jeff_Birt]

When talking about backlash it is important to understand what it is and what it is not and only then can you begin to know how one might go about trying to compensate for it. The easiest way to visualize backlash to picture two gears meshing. A tooth of the driving gear will press on a tooth of the driven gear, if the direction of the driving gear is reduced it will have to rotate some number of degrees before it makes contact with the driven gear (on the opposite side of the tooth). This in a nutshell is backlash. Backlash is not flex in a gantry, or slop in a bushing, etc.

 

When trying to do something to compensate for backlash you have two choices, open loop or closed loop. Closed loop compensation involves having some for or linear scale (position sensor) on each axis so you can read the true position of the axis. This linear scale would b used in conjunction with the encoder on the servo motor and you will often hear it being referred to as 'dual loop' compensation. Closed loop compensation has to be performed by the motion controller.

 

The other choice is open loop compensation. This involves measuring the backlash in each axis very accurately and applying the needed number of 'extra' steps when an axis changes direction. The rub here is that you have to know 'when' to apply the compensation. To start out with you have to have a means to home each axis, once you hit the home sensor and (back off of it) you know that as long as you keep moving away from the home sensor backlash is not a concern. When that axis changes direction you need to apply backlash compensation. Since you are going to be adding in a few extra steps with each axis reversal you have to be able to accurately measure the backlash as if you add in too many or too few extra steps you'll not be helping things at all. To measure backlash you need something like a good quality test indicator that has at least 0.0005" graduations. You then jog an axis one direction to 'preload' (cause the needle to move a certain distance)  the indicator say 0.010", then reverse the motor and step the other direction at say 0.001" increments until you see the needle move. If you jog back 0.005" and the indicator shows only 0.001" of movement then you know you have 0.004" of backlash.

 

Since you now know, accurately, what the backlash of each axis is you can try to compensate for it. So the question is where should the compensation be applied. It can be applied by the motion controller as it is privy to knowing when any axis will change position. It can also be applied at the planner level providing that the planner controls all movements of the machine, both any GCode initialed movement as well as any movement initialed by 'canned' routines or the users. It CANNOT be applied at the GCode level. Why not you ask? Well, because the GCode has no idea, whatsoever, of what other motions might take place. For example if the machine is homed when it is started up, and then you load some filament, and your machine moves around some during the filament loading process now you have no idea where you are at w.r.t. backlash. So you say, well I'll put a home command in my GCode first thing! Ok, what happens when the user is able to pause the printing to change filament or something else? Now you are back to having no idea where you are at w.r.t. backlash.

 

There are other caveats related to open loop backlash compensation. If the axis is subjected to any outside forces it can be 'pushed' out of position taking up the backlash at some unknown point. On something like a 3D printer that is less of a concern than it is on something like a milling machine. The big picture is that open loop backlash compensation is tricky, it cannot make up for a' loosey goosey' machine and it sure can't be done via GCode.

[Dan Newman]

Thanks for the explanation. To clarify my own comments, when I wrote
"backlash like", I was referring to other drive system issues which also
contribute to positioning errors beyond the classic tooth clearance issues.
Namely, the Rep 1 and Rep 2 have features of multi-belt systems and as such
there are belt vibration issues. One belt stops sooner -- the belt on
the right side -- but the other belt continues to move until the counterforce of
belt tension overcomes that motion, stops it, and then there's
a motion in the opposite direction. Net result is a positioning error
which I suspect has a higher amplitude on the left side than the right side.

Now, my question in all of this has always been whether or not anyone has really
determined that there is significant backlash in their system that actively
trying to compensate will actually help print quality. On a Rep 1 and a Rep 2
there are significant issues with differential vibration between the build platform
and extruder carriage. And, of course, there's positioning error in the stepper
motors themselves. So, would compensating for the backlash make an appreciable
difference? On a Rep 1, the vibration is really a serious issue. It's a bit
less on the Rep 2, but still and issue there.

Dan

> --

> You received this message because you are subscribed to the Google Groups "Jetty Firmware" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to jetty-firmwar...@googlegroups.com.

[Dan Newman]

In order to see what the code space usage would be, I added backlash compensation.
And, the very dreaded "confused by earlier errors, bailing out" was utterred by the
compiler,

Steppers.cc: In function 'void steppers::calcSteps(const Point&, uint8_t)':
Steppers.cc:702:1: error: unable to find a register to spill in class 'POINTER_REGS'
Steppers.cc:702:1: error: this is the insn:
(insn 145 143 147 9 (set (reg:SI 128 [ D.6059 ])
(mem:SI (post_inc:HI (reg:HI 6 r6 [orig:150 ivtmp.135 ] [150])) [3 MEM[base: D.6726_106, offset: 0B]+0 S4 A8]))
Steppers.cc:682 12 {*movsi}
(expr_list:REG_INC (reg:HI 6 r6 [orig:150 ivtmp.135 ] [150])
(nil)))
Steppers.cc:702: confused by earlier errors, bailing out

Oh joy. It's usually no big deal, but we'll see. The compiler has run out of
registers and code needs to be pushed around within the function which caused
the trauma.

Dan

[Jetguy]

3 things SOLVED the problem on my Rep 1.
Aluminum Z arms
These pillow blocks http://www.flickr.com/photos/90025904@N04/8543340036/
http://www.thingiverse.com/thing:40584
And removing the stupid spring tensioners and tightening the belts by
moving them up in the slots 1 or 2 teeth.

The basic idea to was remove anything had flex. The driving rods are
supported by the bearings way out at the ends. Thus, it takes nothing
to flex that tiny 5mm rod. Supporting with a bearing pilow block right
next to where the belt pull is solved that issue.
Removing the spring tensioner is just one more place ringing,
overshoot and other nonsense was being added to the system. Because
the shafts and pulleys were now stable and could take more tension,
you could actually adjust properly.
The aluminum Z arms are what should have been there all along. The
plastic is just crap.

The problem is, the 2 and 2X have totally different mechanics and
certainly 0.23mm more in Y is telling.

[Jake]

 It CANNOT be applied at the GCode level. Why not you ask? Well, because the GCode has no idea, whatsoever, of what other motions might take place.

That's a good point, but probably less important on one of these machines.  CNC controllers do track the last known direction of an axis from the time you engage stepper or servo lock, and apply the backlash compensation to all moves, not just g-code.  You get your compensation from during jog move direction changes too.

Really its sailfish's extra features that make this a problem for blacklash compensation-- the ability to jog during pause.  Unless this jog also applied and tracked the compensation it would lose the backlash state. Though for prints where you didn't have filament changes or didn't pause and jog you could do it at the g-code level.

In a world were we had unlimited space on the atmega 1280's, a new g-command could be considered as a feature request.  Something like "unaccelerated raw step move" that allowed you to make a move on an axis without accumulating in the position registers.  "Move X+5 steps but don't change the current understood position tracked by XYZ registers".  This could be used to insert the backlash movements in the gcode pretty easily without having to calculate weird changes to XY positions like the LASH module does.

LASH module compensation isn't quite right as far as I can tell.  It just adds/subtracts a backlash value to all coordinates after a direction change.  While I'm sure it improves things, this doesn't really work.  When X lash is 0 and Y lash is 0.23, and you do a diagonal move after a direction change, the X-axis is immediately tracking the correct position, while the Y axis lags 0.23mm, and the path isn't right.  You'll end up in the correct final location, but it won't be a straight line.  Hence the need to take up the lash quickly and all at once on a direction change.

I haven't measured my 2X's Y-axis backlash yet.  It was really bad until I tightened the belt.  Now its not as bad, but there's still backlash there, lurking, haunting me.  I'll measure it someday.

[Jeff_Birt]

Being able to 'accurately' measure the backlash is the key, I have seen some folks try to do this by measuring how out of round a cycle is on a CNC mill, that just not work. There are too many other factors at play. You have to measure each axis individually with something like a test indicator. The previous post mentioned backlash on the order of 0.023mm (0.001"), personally this is not something I would loose much sleep over. Given the general level of accuracy from the printing process itself that small amount of backlash isn't going to make any noticeable difference. Twisting, flexing, and generally sloppiness in the whole system would be much more concern (but these things are not backlash.)

[Mark Kenworthy]

0.23mm is .009”, so that’s significant, leading to undesirable gaps, etc. in my prints.  I was printing some parts that had walls just 4 layers thick (e.g., 1.6mm wide), so having an air gap between the layers was bad, significantly affecting the strength of the printed part.

 

Putting in the backlash most definitely solved that issue.

 

I don’t want to start a big argument over backlash, but as the owner and operator of a CNC machining business, dealing with backlash in machines is not a theoretical exercise for me.  None of our machines are closed loop (e.g., with scales on the axis), and closed loop systems are not very common, even in professional CNC machines.  Most of them are open loop, but all are servo driven (e.g., there are encoders on the servo drives to confirm that the commanded motion to the motor has occurred, instead of just hoping the motion occurred, which is the case with stepper motors).  But, even though you know the motor has rotated the commanded amount does not mean that you got the motion you wanted, as there is always some lash and flex in the system.  So, we have backlash compensation for that, and over time, as the machines wear, the compensation is adjusted.

 

Jogging axis with an indicator is not a sufficient methodology for determining backlash, as there are dynamics involved that jogging can’t fully capture.  We use a short program (independently for each axis) that moves away and then returns to the start point at a normal feed rate, and we use an indicator to see how far off the movement was.  Then we cut test patterns to make sure we are achieving accurate cuts, since that is the ultimate confirmation that the backlash is correctly compensated.

 

The test ring I posted is an excellent indicator of backlash in a 3D printer.  If there is any lash, it shows up as gaps between the layers being laid down in opposite directions.  I wish it was as easy and obvious on a CNC machine to see the effect of lash!

 

I don’t see any problem with applying the backlash in the g-code, other than it makes the code specific to a machine that has that amount of lash.  For that reason alone, I think it is better to have the backlash compensation in the firmware, so s3g files can be shared between machines that might have differing amounts of lash.

 

Mark

--
You received this message because you are subscribed to a topic in the Google Groups "Jetty Firmware" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jetty-firmware/Zb4G7Aa9-BI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jetty-firmwar...@googlegroups.com.

[Jetguy]

"I don't see any problem with applying the backlash in the g-code,
other than
> it makes the code specific to a machine that has that amount of lash"

Or, just fix the stupid mechanics causing the problem. The logic
behind this blows my mind. Throw excessive amounts of time and effort
at software, in the hopes that it somehow masks a mechanical problem.

Or, just sell the stupid machine and make something that works:
Correct direct drive Y axis
http://www.flickr.com/photos/90025904@N04/8683802370/
http://www.flickr.com/photos/90025904@N04/8683801734/
http://www.flickr.com/photos/90025904@N04/8682686747/
Consists of a high torque NEMA17 rated 5.5kg/cm
5 to 8mm CNC coupling
8 mm shaft
608 skate bearings for load.






On May 17, 10:41 am, "Mark Kenworthy" <m...@kenworthymachine.com>
wrote:

> To unsubscribe from this topic, visithttps://groups.google.com/d/topic/jetty-firmware/Zb4G7Aa9-BI/unsubscr...
> en.

[Jeff_Birt]

@Mark, yes .23mm is about .009", I misplaced a zero when doing a quick mental conversion. With that amount of backlash a mechanical solution, i.e. fixing the problem would be much better than trying to compensate for it.

 

With regards to trying to do backlash comp in the GCode. As I mentioned before it just can't be done. A machine may make many other preparatory moved before getting the GCode and any user interaction in jogging the machine will also prevent the GCode from being able to know where the backlash is, the planner or motion control stage is the only place it can be done.

 

The method I describe and what you describe for checking backlash is essentially the same, preloading the indicator and then noting the difference in commanded vs. actual position after an axis reversal. Backlash has to be checked on an individual axis bases though and can only be done accurately by indicating it. When you are actually making a part (with any type of machine) there are too many other variables in play and sorting the backlash out of that is impossible. Remember backlash compensation can only take care of backlash, not any dynamic interactions cause by a loose machine and moving multiple axis at once.

I have worked with everything from huge router tables, to robotic welding/cutting to laboratory/research equipment over the years. For the past five years or so I have been operating a small business that deals with small scale CNC equipment and custom motion control type consulting work (my full time job is as a research engineer at a university). This is not to brag but just to point out that this is a subject with which I am very familiar and deal with on a daily basis.

[Mark Kenworthy]

Sure, if you start from an arbitrary situation, then the g-code approach couldn’t reliably solve the problem.  However, as soon as an axis reversal has occurred in the code, then things are okay.  I always start prints with a skirt, and I don’t interrupt the print, so for the way I print, it can (and does) work.  Even if I interrupted a print, jogged around, and then restarted the print, as soon as there was an axis reversal in the code, comp would be correct again.  I would argue that having the comp correct most of the time (except for possibly a few moves after restarting an interrupted print) is better than not having comp.

 

Not that I’m arguing that having it in the gcode is the right approach.  It isn’t and really the backlash comp should be in the machine parameters and handled by the firmware on the machine.  Which is where this thread started, asking why it wasn’t in the firmware.

 

One irksome issue with having the comp in the g-code is that previewing the code (e.g., with Skeinlayer) is pretty ugly with the comp moving the head position around, so it is difficult to visually confirm that the code is correct.

 

Mark

 

From: jetty-f...@googlegroups.com [mailto:jetty-f...@googlegroups.com] On Behalf Of Jeff_Birt

Sent: Friday, May 17, 2013 9:31 AM
To: jetty-f...@googlegroups.com

[Dan Newman]

While I have been looking at adding backlash support, I'm not too sure if folks
realize just how miserable it will make printing in regions of small detail or
short, back and forth infill strokes.

To do the backlash support an additional, short move (a few steps) needs to be
queued. In general these compensation steps cannot be added to an existing move since
they will, in general, change the angle of the move. Sure, just by a tiny amount on
relatively large moves but on very short moves it's more significant.

So, in a region of small, back and forth detail (e.g., infill), we're potentially
doubling the number of line segments to plan. Already the acceleration planner
is taxed in such areas and now its work has as much as doubled. This will
introduce zits/pimples in those areas. (Recall, taxed, 8bit, 16MHz AVR.)

Net, net, there are printing cases where this may work well and printing
cases where it will just be trading off one problem for another.

Dan

[Jake]

Another case for doing it in GCode?  Use backlash compensation while doing perimeters and loops, and switch it off for doing infill and small features?

Okay, getting complicated now.

[Dan Newman]

> On my R2 (Replicator 2), I have set up 0.0 lash for X, and 0.23mm in Y.

According the the Gates design guides, properly using their 2mm Power Grip GT2
timing belt system for "light duty" motion transfer and a belt tension of 1.8 lbs,
the positioning error (which includes backlash) should be in the 0.003 mm ball park.
That's well in the range of the stepper motor's positioning error when microstepping.
About 88.5 microsteps/mm on a Rep 2 or 0.011 mm per microstep and thus less than ⅓ of
a microstep.

Now, the X axis system on the Rep 1 and 2 is pretty simple. The Y axis is not
so and involves three belts and a long axle (two in the Rep 1). I myself do not
know how to compute the theoretical positioning error in that system. But your
measured 0.23mm is nearly two orders of magnitude larger than "basic" 0.003 mm
(77 times larger).

Note that the PG GT2 system is designed to have very low backlash.

Dan

[Bottleworks]

I agree with Jetguy. Fix the underlying issue. These issues can be resolved to where there is virtually no backlash. Backlash compensation in CNC Mills is the "cheap way" to fix the problem. It's also the most realistic way considering the costs. But when it comes to makerbots, realistic thing is to fix the real problem. The costs are cheap. The cost to fix them in the firmware are high (Limited remaining free space) and it's still just covering up an underlying issue.

Do I need to release an upgrade for the replicator 2/2X's that fixes the Y axis backlash?

[Dan Newman]

>
> Do I need to release an upgrade for the replicator 2/2X's that fixes the Y axis backlash?

Sure and a nice, rigid chassis for Rep 1 owners, and an entire improved extruder assembly,
and, and, and.

Next thing you know, you'll be comparing notes with Rick Pollack and selling entire bots.
(Rick started out as a Cupcake owner who then started making and selling improvements and
now owns and operates Makergear.)

Dan

[Bottleworks]

Well now you're killing me. There's only so much time in the day!

[Bottleworks]

I'll send you one next week.

[Robert Trescott]

Backlash is an interesting problem. It can determine the difference between a circle and an oval shape. It really is a problem for small parts because the head/part never really catches up with the 'true' position.

For this reason, I try to build all my machines (CNC & 3DP) without the need for backlash compensation. Fortunately, timing belts and cog pulleys are inherently backlash resistant. For lead screws, I only use Kerk patented zero backlash nuts, so I really don't see a lot of backlash issues.

However, I got to say, it is a 'machine dependent' (axis dependent actually) issue and should be transparent to GCODE and slicers. It's supposed to be handled in the servo controller code and should be configurable per axis. I know its a blurry line between what we call servo controller and motion planner, but doing the right thing is not always doing the easiest thing!

If done correctly, printers with zero backlash will see no change whatsoever in part quality, while machines with backlash will see incredibly accurate parts (to what they were used to) with some minor variations in surface finish areas where backlash was winding/unwinding.

It is interesting to point out that the extruders suffer from a type of 'backlash' error and that we have all kinds of corrections employed to try and mitigate those problems.

Without the code space to provide backlash compensation, all of this is a moot discussion, unless it's offered on a platform with enough extra capacity to make use of it. But in the end, making sub-backlash print moves back and forth really adds some excitement into the servo positioning, but what's life without some excitement?!

Cheers,
-Robert  

[Dan Newman]

>
> Without the code space to provide backlash compensation, all of this is a moot discussion, unless it's offered on a platform with enough extra capacity to make use of it. But in the end, making sub-backlash print moves back and forth really adds some excitement into the servo positioning, but what's life without some excitement?!

While code space is an issue on the ATmega 1280s, the 16 MHz is also an issue.
Were I to do the code correctly, it would be deep down in the actual code which
exectutes a single step instruction. That's exactly where the endstop check
code is, btw. Problem is, that code runs at interrupt level and needs to be
as fast as possible. Also, every instruction added there makes the overall
stepper interrupt take longer to run. The longer it takes to run, the fewer
steps per second you can execute (without having to double step, etc.).
But putting that code in that deep becomes yet another set of conditionals
and jump statements: does this axis care about backlash compensation, have
we changed direction, etc. And, because of that first test -- does the
axis care about backlash compensation -- every bot is impacted by the
code change. Hence the consideration of a compromise of potentionally
landing it higher up the code stack but then needing to throw in extra tiny
moves into the accel planner's queue. It's not clear what the right answer
is (aside from first trying to tune as much out mechanically as possible).
And while using an ATmega 2560 helps with the code space issue, having
a faster uprocessor would help all around.

Dan

[TobyCWood]

And... Please make em shiny.