Accurate calibration of Rep 2 X/Y steps-per-mm

[Wingcommander]

So I while back Jetguy posted an alternative steps per mm calculation which I have been using in GPX

[x]

steps_per_mm=88.88888888888889

[y]

steps_per_mm=88.88888888888889

However I decided to manually calibrate my printer using the attached script with a set of digital callipers I use for tramming my mill, which are attached to a magnetic clamp. With it I am getting within +/- 0.01mm using the following settings in GPX.

[x]

steps_per_mm=88.95

[y]

steps_per_mm=88.95

As always YMMV.

[Wingcommander]

Just to clarify, this is measuring/calibrating the carriage movement, not the extruded output.

[Steve Johnstone]

Thanks Wingcommaner, I will calabrate the printer after I have installed Carl's X ends.

Out of curiosity how far was your printer out?

Hope you and your family have a fantastic New Year.

Steve

[Wingcommander]

Out of curiosity how far was your printer out?

The original makerbot steps_per_mm setting of 88.573186 was out by about 0.42mm over a 100mm distance.

I know its not much, but I am printing bike part samples that we plan to forge in Aluminium, so I needed them to be as dimensionally accurate as possible - clearly I can't compensate for die swell in ABS if my printer's X/Y movement is out by the width of an extrusion across the length of a part. Y axis backlash is still about 0.3mm, so longer term I am thinking of mounting a Kysan stepper on the left front pillar and driving the gantry directly from the Y axis front axle to see if I can eliminate this to some extent. 

Basically if you are not printing engineering samples, none of this really matters - however I am so it does.

[Dan Newman]

On 30/12/2013, 11:10 PM, Wingcommander wrote:
> Just to clarify, this is measuring/calibrating the carriage movement, not
> the extruded output.

And, BTW, I had pretty similar numbers -- 88.94 steps/mm -- for my Rep 2 which was
made/shipped roughly around the same time as yours. I used a large dial indicator
built for measuring backlash on CNC equipment.

It's been really tempting to change the numbers the machine def's for RepG to
the 88.888888 [more correct theoretical values]. I've just been unsure of how much confusion
that might cause....

Dan

[billyd]

I use the caveman method:

Print the part. Measure it. Scale the model in each axis to compensate for measured errors. Reslice and print again. Perfection.

[Wingcommander]

And, BTW, I had pretty similar numbers -- 88.94 steps/mm

That is reassuring. A dial indicator would probably have been better, my digital calipers went haywire at first - probably EMI from the stepper motor coils in the extruder. Once I repositioned it, everything worked fine, but not after me first swapping batteries and scratching my head a bit.

[Enginwiz]

Simplify3D 2.0.1 installs GPX version 1.3 without a GPX.ini.

I tried to put together a GPX.ini for my Replicator 2 with the heated build plate

that includes your new calibration values for the X- and Y-axis steps per mm.

Then I printed the 110 mm calibration piece http://www.thingiverse.com/thing:28109

The measured outer dimensions of the printed part are 109,6 mm along the X and Y axis at the new 88.95 steps per mm.

I increased the steps for both axes to 83.3 steps per mm in the GPX.ini and the dimensions of the next print stayed the same.

Does the enclosed GPX.ini (with your 88.95 values) have all the necessary settings for the Rep2HBP or did I miss something?

[Wingcommander]

This is all you need.

;
;  gpx.ini
;
; gcode to x3g conversion configuration file

[printer]

; specify the machine definition using a pre-defined built-in type identifier
; NOTE: settings are order dependent, so always start with this settng
;    r1  = Replicator 1 single
;    r1d = Replicator 1 dual
;    r2  = Replicator 2 (default)
;    r2h = Replicator 2 with HBP
;    r2x = Replicator 2X

machine_type=r2h

; specify the gcode flavor
;
; reprap = M109 Set Extruder Temperature and Wait
; makerbot = M109 Set Build Platform Temperature (Same as M140)

gcode_flavor=makerbot

build_progress=1

; SD Card path - if inserted the x3g file will be written there
;sd_card_path=/Volumes/THINGS

[x]
steps_per_mm=88.95

[y]
steps_per_mm=88.95

[Enginwiz]

Thank you for posting the correct syntax for the GPX.ini. 

I copied your posted settings into the GPX.ini sitting in the directory of Simplify3D 2.0.1 and printed another 110 mm calibration part.

With the recommended 88.95 steps per mm the 110 mm calibration print again measured 109.6 mm on the X- and Y-axis.

I increased the steps per mm to 89.20 and 89.50 on two additional prints and the maximum X- and Y-axis length stayed at 109.6 mm.

Somehow the X and Y values in the GPX.ini don't seem to change the dimension of the prints.

Does the enclosed GPX.ini scale up the prints on your printer?

[Dan Newman]

On 02/01/2014, 1:31 PM, Enginwiz wrote:
> Thank you for posting the correct syntax for the GPX.ini.
> I copied your posted settings into the GPX.ini sitting in the directory of
> Simplify3D 2.0.1 and printed another 110 mm calibration part.
>
> With the recommended 88.95 steps per mm the 110 mm calibration print again
> measured 109.6 mm on the X- and Y-axis.
>
> I increased the steps per mm to 89.20 and 89.50 on two additional prints
> and the maximum X- and Y-axis length stayed at 109.6 mm.
> Somehow the X and Y values in the GPX.ini don't seem to change the
> dimension of the prints.

BTW, to save you printing, you can just dump the s3g/x3g and compare how
many steps are in each motion command. Wingcommander maintains a script
to perform this feat,

https://github.com/whpthomas/GPX/blob/master/scripts/s3g-decompiler.py

it's progenitor comes from the RepG source repository (same subdirectory
name, same file name).

Dan

[Wingcommander]

Just remember that if Simplify3DCreator has a different machine selected (i.e. -m on the command line) it will clobber any gpx.ini settings. The loading order is gpx.ini, then command line options, custom ini using -c option. The new version of GPX prevents this from happening if the command line machine is the same as the one in gpx.ini, but I am not sure what version S3DCreator is using. You may need to replace the older one with the latest version if its clobbering these settings.

[Ming Kawaguchi]

instead of mounting it to the left front pillar, i have relatively concrete plans to mount into the front plate (which of course will not be the piece of foam used by MBI but something very rigid instead). in particular, if you look at the clearance from the long y-pulley rod to the pillar, there isn't enough room to do much by use a drive belt just as in the rear right pillar mounting. you could use a gear-set instead, but they you're just trading one problem for another.

my side plates are already relatively thick 304 sandwiches, and my plan has been to to the same with the front and rear, but haven't gotten around to it. however, if one were to mount a stepper into a very large, solid and thick front plate assembly such that the drive shaft went straight through, perpendicular to the plate, one could get excellent stability at the stepper mount as well as a direct drive of the front pulley. 

also, my dial gauge has been significantly more useful than any either the mic or calipers in debugging issues with the bot. worth picking up, i think.

[Enginwiz]

Simplify3D 2.0.1 automatically  installs GPX 1.3 in its directory.

GPX 1.3 is the highest Windows version I could find on Thingiverse.

GPX 1.4 and 1.5 are only avaliable for OSX.

For a windows user GPX 1.3 on the command line is currently the way to

do accurate mm to step conversion for third party slicers. It would be great if

the next versions of GPX.exe would contain the more accurate step-to-mm resolution

of 88.95 for the X- and Y-axis. This would make automatic postprocessing 

a lot easier.

On Github there is currently a beta of GPX 2.0

Will there be a windows version of GPX 2.0?

[Wingcommander]

In the Process (FFF) settings under the Scripts->Starting G-Code tab, uncheck "create x3g file..." and enter the following in the post processing scripts text box.

/Applications/GPX/gpx [output_filepath]

Obviously you need to change the gpx program path to suite your machine.

Anyway, this will cause the settings in gpx.ini to get used.

[Enginwiz]

Hello Wingcommander,

converting with GPX on the commandline at 88.95 steps per mm for X and Y did the job. 

After 15 month my Replicator 2 finally produced its first dimensionally accurate print.

Every dimension of the printed part varied less than +/- 0,1 mm from the CAD-file.

Thank you for the new postprocessing procedure for Simplify3D. I will try it out.

[Wingcommander]

converting with GPX on the commandline at 88.95 steps per mm for X and Y did the job. 

 That is cool =)

[Jetguy]

The problem I have with that is what does that mean when the value that works for scaling doesn't match theoretical?

 

In other words, a long time ago I showed where MakerBot used a different formula to determine the steps per mm, it's found right in the machine .xml for Rep-G.

They use what we assume is info from the pulley manufacturer about the effective or "pitch diameter" of the pulley, and then the standard microstepping times the motors default 200 steps/rev.

 

Long ago, I said to use belt pitch times pulley tooth count and the standard microstepping times the 200 steps/rev. This is based on the fact even the slightest error in diameter in the way MakerBot calculates results in a larger error in the steps per mm.

 

Right here from the Rep-2 config is STOCK value

<axis id="x" length="285" maxfeedrate="18000" homingfeedrate="2500" stepspermm="88.573186" endstops="max"/> <!-- Pulley dia: 10.82mm / 1/16 step = 1/(10.82 * pi / 3200)

My method is 18T GT2 pulley @ 2mm pitch is 18*2= 36mm/rev and we know at 1/16th stepping the motor is 16*200=3200 steps/rev so 3200/36mm=88.88888888888889 steps/mm

To recap:

88.573186 is STOCK

88.88888888888889 is what I would say is proper "theoretical"

88.95 is now the "suggested value"

My concern was and alway will be that scaling is NOT a number to be playing around with.  There is one correct value and that's it. The end result is the belt attached to the motor should move the correct distance. Since there isn't any kind of extra multiplier mechanical ratio in the bot, any deviation is then assumed, and with good reason, to be backlash. If scaling is incorrect, it's like a 24 hour clock that is broken, it's right only once a day. I build machines with even longer axis and such a "scaling" error becomes extremely evident the larger you go. I think it is bad practice to do "fuzzy" math compensating for backlash using scaling, and assuming that because the max build size is smaller the total error percentage is within reason.

If belt pitch is wrong, then given enough movement, the teeth simply do line up with the pulley teeth and it either jumps the belt or has a lot of friction. Effectively it must be 2mm pitch. This is why I dislike the "pitch diameter" method of calcs because they are so prone to error. The pitch diamter is not any measurement you can make of the pulley. It's not the teeth diameter and it's not the root diameter. That means it's total guesswork.

Again, the reason I bring this up over and over is we need to get to the bottom of the logic of what is happening. Obviously, you cannot make a fraction of a step. The bot either moves a step or it doesn't. This means that rounding calcs to the next even step happen.

Basically, there are 3 logical conclusions here:

If the suggested value is correct scaling, then the belts and pulleys are not manufactured to 2mm pitch and the firmware and software are correctly rounding = pulleys and belts are the root cause

If the pulleys are correct and the belt pitch is correct, then the answer is the firmware and software have flawed rounding= Flawed firmware/software

If the mechanics are that sloppy that they are introducing backlash, overlaying a scaling change is not the correct way of compensation=flawed mechanics and improper way of adjustment..

 

Again, the numbers are telling. MakerBot's numbers are just bad info and a bad way to calculate the value. It's pretty obvious that's the case when you compare it to the pitch and teethcount calc. The fact the manually adjusted anumber is higher than both stock and the theroetical values indicates LOST motion. We have to tell it to move further to to achieve the actual distance. That's clearly backlash in my book.

Being that BOTH Makerware and Replicator-G (Skienforge) have backlash adjustments in the profile, I find it odd that you are NOT using that to correct.

In fact, don't you find it odd, that Makerbot went to a lot of effort to put such a comprehensive backlash adjustment method in Makerware? Wouldn't that be somewhat telling they acknowldege there is significant backlash in the mechanics of the machine? While Rep-G was Universal to run many bots, Makerware is purpose built and intended to run on MakerBot machines.

http://www.makerbot.com/support/makerware/documentation/slicer/

Backlash Compensation

"doBacklashCompensation". True/false.

Backlash occurs when there is some amount of slack on one of more of your bot's axes. When the extruder changes directions, some small portion of the first movement in the new direction will be taken up by that slack, and the resulting move will be slightly shorter than intended. Backlash can affect dimensional accuracy. When "doBacklashCompensation" is set to "true," the settings below will attempt to compensate for backlash. When "doBacklashCompensation" is set to "false," none of the backlash settings below will be used. This feature is experimental and use may result in some slight distortion in printed objects.

"backlashFeedback". Decimal, [0,1].

The MakerBot Slicer compensates for feedback gradually in order to reduce distortion. It will compensate for a certain amount of feedback over the distance set in "splitMinimumDistance." The amount of feedback compensated for in each segment of the length set by "splitMinimumDistance" is a percentage inverse to the number set here. For example, if the default "backlashFeedback" setting is 0.9 and the default "splitMinimumDistance" is 0.4 mm, the slicer will compensate for 10% of the remaining feedback error over the first 0.4 mm after the change in direction. Then it will compensate for 10% of the remaining error over the next 0.4 mm. This will continue until the size of the error meets or falls below the distance set in "backlashEpsilon." If "backlashFeedback" is set to 0, the entire error will be compensated for immediately.

"backlashEpsilon". Millimeters.

When you use the "backlashFeedback" setting, the slicer compensates for increasingly small amounts of error over distance. The remaining error gets smaller and smaller, but is never fully compensated for. The "backlashEpsilon" setting fixes this problem by ending the backlash compensation when the remaining error becomes so small as to be insignificant. When the remaining error is smaller than the distance in millimeters set here, the slicer will stop compensating for backlash.

"backlashX" / "backlashY". Millimeters.

The "backlashX" and "backlashY" settings tell the slicer how much backlash the slicer should be compensating for. To determine if backlash is present, print a 20 mm calibration box (available under File > Examples in MakerWare) and measure the length and width of the printed box. If either the length (Y) or width (X) of your box is less than 20 mm, subtract that value from 20. Divide that number by two and enter the result into the appropriate backlash setting.

 

Again, the basic idea that I amd trying to present is that YES, I agree, there is a slight error in the way MBI calculated steps per mm in the config. Why this default value hasn't been changed in like 2 years blows my mind but hey, who said anything at MBI makes sense.

That said, I believe the "correct" method is to use the "theoretical" value I have presented, and properly use Backlash compensation as your fine tuning.

[Jetguy]

Also, I really didn't want to seem like I'm arguing your numbers, just trying in my head to wrap around where this could go wrong.

 

For example, I know both you and Dan obviously have the experience and the tools to measure this correctly.

We all agree the stock value is not ideal.

 

What I think could happen is that it's a flawed method of testing to arrive at the numbers. I could totally be reading into it that you based it on measurement at 100mm or the other obvious point would be say nearly max X axis 200mm.

And just for discussion, a lot of folks start a complaint here on dimensional accuracy on a 20mm test cube. If you are off at 20mm, then you are off by a mile at 200mm.

 

I think we all can also agree fundamentally, there is going to be some measurable backlash in these desktop printers. I know you guys no how to minimize it, but there are design elements that you just cannot remove.

 

It's not that big of a deal and the 88.95value may help a lot of folks out .

 

At the same time, I'm just a stickler for method and if you get the method right, then no matter what size bot you make, it's going to be accurate. I'd rather see this place and hobby as being educational and really trying to nail things down to what is the right way regardless of bot size. The hope is the scientific minds of folks using these printers are future engineers around the world and building bigger and better things.

 

Again, I know I'm a pain but I want to better understand why we arrive at 88.95 rather than 88.888889.

 

The basic idea in that in all of these calibrations, even when I do it, we tend to to a small distance, then a large distance move and verification. For example, move 10mm and verify it moved 10mm, then if that seems about right, move 100mm and verify, then 200mm, then 300mm (oh wait, you can't go that far). Backlash is a funny thing, so I think what happend is you scaled for 200mm to be dead on with no backlash compensation. When we now command smaller distances, backlash value is a constant value, scaling error by name becomes smaller.

 

So maybe your method works great and the reason is that you calibrated it at the absolute max distance the bot can move anyway and then by the nature of the beast, smaller distance might be off in a technical sense, the but error value is so small because the distance is so small it's not relevant.

 

On the flispide, the point I've been trying to make to folks are the ones who start makign massive adjustments to get a 20mm test cube right. Simply put, you cannot tell anything of reason at that distance. If you make your adjustment here, then you will have big problems on larger prints.

 

Again, sorry for the long post and airing my thoughts, but I hope at least the discussion is educational to everyone.

[Enginwiz]

This strategy for automatic postprocessing in Simplify3D using the settings in a GPX.ini works.

However - the path to GPX in a Windows environment requires backslashs instead of the slashs on OSX.

I did a common GPX setup for Kisslicer and Simplify3D sitting in C:\GPX

In Simplify3D running on a windows computer the new postprocessing settings look like this:

[Jetguy]

Thanks for those tips on syntax of GPX inside of Creator software.

I needed that to implement the custom config for the big Ulti-Replicator.

I was doing it manually previously for testing.

[Enginwiz]

The 110 mm calibration part consists of 5 mm bars and 10 x 10 mm holes.

To my surprise on the printed part the bars are now exactly 5 mm wide,
all holes are exactly 10 by 10 mm and the overall length is exactly 110 mm
in both directions. I don't know why the 88,95 work while the theoretically
correct 88.88 steps per mm produce too small parts. Maybe someday we
will find it out.

Kudos to Wingcommander for finding this sweet spot.

[Joseph Chiu]

When bending metal, there's a concept of a neutral axis - and I would expect the belt to have a similar "neutral line" that is at some fraction of the belt's thickness.  Googling around, I see that it's called the "pitch line" http://www.sdp-si.com/D265/PDF/D265T003.pdf, http://www.hoverhawk.com/polychain.pdf for these belts.

GT2 2 mm pitch, 18 teeth on SDP/SI shows pitch diameter of 0.451 in = 11.4554 mm in their inch catalog, and 11.5 mm in their metric catalog.  

Using the metric 5mm bore part's 11.5 mm pitch diameter, I get pitch circumference of 36.128315516282622242320398907714 mm, 0.18064157758141311121160199453857 mm/step (200 steps), and 5.5358241075441855919611743781744 steps/mm.  With 16x microsteps, I end up with 88.573 as my calculated value for the steps/mm.

Josef Prusa's calculator (http://calculator.josefprusa.cz/) yields 88.89

When I use the 11.4554 pitch diameter from the inch catalog, I get 88.9180.

Could belt tension be a factor in the pitch diameter?  

The thing is, we're talking about a ~0.04 mm difference in pitch diameter between the catalog numbers at SDP/SI.  For a 11.5 mm nominal diameter, that's ~ 0.4% error.

I know that some slicers (well, SkeinForge,anyways) will scale a part up by 1% by default (scale plugin; x/y plane scale ratio = 1.01) and others will "inset" the perimeter by a fraction of the extrusion width (KISSlicer.  Slic3r as well, iirc).  It seems like that, plus shrink, provide greater contribution of errors in printed parts?

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

[Dan Newman]

On 03/01/2014, 11:54 AM, Jetguy wrote:
> Also, I really didn't want to seem like I'm arguing your numbers, just
> trying in my head to wrap around where this could go wrong.
>
> For example, I know both you and Dan obviously have the experience and the
> tools to measure this correctly.
> We all agree the stock value is not ideal.
>
> What I think could happen is that it's a flawed method of testing to arrive
> at the numbers. I could totally be reading into it that you based it on
> measurement at 100mm or the other obvious point would be say nearly max X
> axis 200mm.
> And just for discussion, a lot of folks start a complaint here on
> dimensional accuracy on a 20mm test cube. If you are off at 20mm, then you
> are off by a mile at 200mm.
>
> I think we all can also agree fundamentally, there is going to be some
> measurable backlash in these desktop printers. I know you guys no how to
> minimize it, but there are design elements that you just cannot remove.
>
> It's not that big of a deal and the 88.95value may help a lot of folks out .

Difference between my 88.94 vs theoretical 88.89 is 0.06% (note *percent*).
I don't know the manufacturing accuracy of GT2 timing belts, but that may be
within it. (And I don't see MBI paying for high precision belts, if such
a thing exists.) Note further that Wingcommander and I both have very early
Rep 2s so it's conceivable that the belts are not only from the same supplier
but perhaps even the same batch.

Dan

[Ming Kawaguchi]

as far as i know, MBI only sources belts from gates. they are pretty high quality, but in this case it's more of a durability thing than a tolerance due to the limited control one has of the elastomer one uses for the teeth. there's a reason that the auto industry (very possibly the chintziest industry in the economic world) almost universally switched from belts to chains for timing about 10 years ago.

[Dan Newman]

On 03/01/2014, 3:41 PM, Ming Kawaguchi wrote:
> as far as i know, MBI only sources belts from gates.

My ToM and Rep 1 have only SDP/SI belts. My Rep 2 has some SDP/SI
belts, but I've not checked all of them. The Fairloc(tm) hubs on my Rep 2
were from SDP/SI as well. However, I've also seen Rep 1's and Rep 2's
with belts from Gates. So, it may well be a case of whomever they got
the best deal from that month.

Dan

[Ming Kawaguchi]

designatronics belts are nothing to sneeze at either. i just wish they'd sourced more of the linear motion stuff from them as well. it would have saved me quite a bit of money replacing all that with the sterling sourced equivalents.

and yes, the fairloc hubs are something to sneeze at.

[Wingcommander]

Again, I know I'm a pain but I want to better understand why we arrive at 88.95 rather than 88.888889.

This was done by measuring the physical distance the X carriage moved over 100mm. In the script, is moved twice 10mm - the zero point - then to 110mm. This was intended to reduce backlash - the first movement provides some pre-load, and the second the measurement. Each time I back-calculated the difference and re-tested until I got an accurate, repeatable result. Obviously there is some potential for sympathetic rounding errors here, so it could be that my result is out by a small amount, however the fact that Dan got 88.94 using a dial indicator - which I assume measured a much smaller movement - measuring larger distances is more likely to capture these errors.

The main point here is that in a lathe/mill we use a linear encoder to track the physical movement of the carriage is relation to the tool. Any theoretical movement has no bearing on accuracy - we want to measure what is actually happening physically. I just did the same thing with my 3D printer.

I do agree with Dan, that it is quite possible that if any of the parts have been substituted since my printer was manufactured then these numbers may not work. However, readers could check them by running the x3g attached to the OP and measure the X carriage movement with a set of digital callipers themselves. It may not be as accurate as using a set attached to a magnetic base, but it will give you some indication. Only way to really find out how much variation there is between printers.

I would caution against measuring printed parts, because other variables come into play - however if you printer's extrusion is properly calibrated, you should get similar results to Enginwiz.

[Dan Newman]

On 03/01/2014, 4:24 PM, Wingcommander wrote:
>
>>
>> Again, I know I'm a pain but I want to better understand why we arrive at
>> 88.95 rather than 88.888889.
>>
>
> This was done by measuring the physical distance the X carriage moved over
> 100mm. In the script, is moved twice 10mm - the zero point - then to 110mm.
> This was intended to reduce backlash - the first movement provides some
> pre-load, and the second the measurement. Each time I back-calculated the
> difference and re-tested until I got an accurate, repeatable result.
> Obviously there is some potential for sympathetic rounding errors here, so
> it could be that my result is out by a small amount, however the fact that
> Dan got 88.94 using a dial indicator - which I assume measured a much
> smaller movement - measuring larger distances is more likely to capture
> these errors.

Dial indicator specially designed for General Dynamics for use with
a 9 axis mill they had in Pomona, California twenty years back. Not mine
but I borrowed it from the chap who bought it when the facility was mothballed.
Quite accurate, but only a little over 2 inches of travel.

Dan

[Dan Newman]

> Quite accurate, but only a little over 2 inches of travel.

Which is the unique feature of the gadget: that much travel plus
the accuracy. I don't recall the error other than it was better
than +/- 0.05" and thus better than 0.002 mm. Or at least 20+
years ago.

Dan

[Wingcommander]

Quite accurate, but only a little over 2 inches of travel.

I wasn't questioning the accuracy of your indicator, just that measuring a longer distance will reduce the effect of rounding error.

Obviously a better way to do this calibration, it is to move the carriage an exact number of steps, so there is no rounding - then it would be completely accurate =)

[Dan Newman]

On 03/01/2014, 9:05 PM, Wingcommander wrote:
>
>>
>> Quite accurate, but only a little over 2 inches of travel.
>
>
> I wasn't questioning the accuracy of your indicator, just that measuring a
> longer distance will reduce the effect of rounding error.

Didn't think that you were. I was just mentioning that it was an odd
DI with that much travel.

> Obviously a better way to do this calibration, it is to move the carriage
> an exact number of steps, so there is no rounding - then it would be
> completely accurate =)

Actually my approach was to move it a known number of steps and then measure
the amount moved. Move a small amount to load and eat any lash; read the
DI; then move a known number of steps in the same direction; read the DI;
distance travelled is difference of two DI reads. Then repeat the process nine
more times and average the ten results.

I used 3200 steps and was expecting very close to 36.00 mm of motion. Indeed, I chose
3200 steps since 3200 steps / 36.00 mm was the magic value: one full stepper
rotation and 18 pulley teeth * 2.00 mm / belt tooth or 36.00 mm of belt travel.
However, to my disappointment it averaged out a bit less: 35.98 mm over the trials.
What I don't know how to account for in the whole process is stepper motor positioning
error. After all, the cumulative positioning error may easily have been several microsteps.
What if the pulley turned 1 or 2 microsteps shy of a full 360 degrees? Then it might have
been or 88.91 or 88.88 steps/mm instead.

Dan

[Ming Kawaguchi]

i feel like this is a prudent time to point out that these steppers are mounted in ABS slots with 2-3MM outer thread widths at best and no published torque spec, in addition to gearing and belt variance. 

[Enginwiz]

My Replicator 2 has a serial number in the range of 150.

It came equipped with this Gates GT2 belt on the X-axis.

[Enginwiz]

However - on the Y-axis carriage there are two SDP belts.

The short belt to the Y-axis motor is also a SDP.

The printed calibration part had the same overall length in X- and Y-direction.

So the two brands of belts seem to match each other quite well.

I printed the calibration part with PLA at 215°C on a heated build plate at 60 degrees Celsius.

To get proper adhesion to the build plate I used two layers of Garnier Fructis #5 on the glass plate.

The radial cooling fan started to run after the first layer and kept running until the end.

However - at the end of the print the 4 mm high printed part was still quite warm because of the heated glass plate underneath it.

Immediately after the end of the print (and still on the hot glass plate) its length measured 110,2 mm in both directions.

During cooling after the end of the print the calibration part started to shrink and released itself from the build plate.

After separating from the build plate and cooling down to room temperature its length measured 110,0 mm in both directions.

[Wingcommander]

Actually my approach was to move it a known number of steps and then measure
the amount moved.

As usual - you are way ahead of me Dan =)

At least I can take some consolation that by using a different methodology and getting a very similar answer, we are at least triangulating these results - which should increase overall confidence that the results are correct.

My lathe and mill have glass linear encoders and DRO that measure down to +/- 0.005 - but my dial indicator only moves about 20mm and wiggler about 1mm.

[Dan Newman]

On 04/01/2014, 12:35 AM, Enginwiz wrote:
> My Replicator 2 has a serial number in the range of 150.
>
> It came equipped with this Gates GT2 belt on the X-axis.

My #18 and has a X drive belt whose part number begins "SDP A ...".
(Sorry, too lazy to snap a picture but if folks want the part number,
I will.) And all my SDP/SI belts begin that way, "SDP A ..." so I'm
assuming it's from Stock Drive Products (SDP/SI).

Dan

[Big-E]

I recently had to go through the process of calibrating steps per mm on my Prusa i3 and Printrbot simple XL, On my i3, the Z axis was a little off, whereas on my Simple, Every axis (except for the extruder steps per mm) were WAY off!

Of course, I used the old "print a calibration cube, measure and calculate" method.

My big question is this: Is there a way to flash the values into firmware on a Replicator/2/2X, rather than through software? it certainly would make things easier. The equivalent of M500 and M501 commands would be handy on a Replicator (although, my Rep2 has been pretty much dead accurate, so I haven't needed to calibrate it)

[Dan Newman]

On 04/01/2014, 10:56 AM, Big-E wrote:
> I recently had to go through the process of calibrating steps per mm on my
> Prusa i3 and Printrbot simple XL, On my i3, the Z axis was a little off,
> whereas on my Simple, Every axis (except for the extruder steps per mm)
> were WAY off!
>
> Of course, I used the old "print a calibration cube, measure and calculate"
> method.
>
> My big question is this: Is there a way to flash the values into firmware
> on a Replicator/2/2X, rather than through software? it certainly would make
> things easier. The equivalent of M500 and M501 commands would be handy on a
> Replicator (although, my Rep2 has been pretty much dead accurate, so I
> haven't needed to calibrate it)

But it's a catch-22: you do have to use software. Makerbots do not consume
gcode. They consume s3g. So you have to modify your gcode -> s3g translator
to then recognize those new mcodes as well as modifying the firmware to accept
the new s3g commands. So, instead of just modifying the firmware to recognize
new commands, you also have to hit the other points in the software chain.

Now, in the old Jetty Firmware we did have special mcodes to set all the
acceleration parameters. And we had to modify RepG to handle them and we
had to create new s3g commands. But once we put the UI support into RepG
so that people could just use Machine > Onboard Parameters, no one seemed
to care about the mcodes anymore. So, we removed them and saved code space
in the process. (Mind you, you can still set all these parameters for
Gen 4 electronics from the Gen 4 LCD interface so on ToMs at least there
were not one but two UIs available.)

So, at present there are no mcodes you can use for a Replicator to set
these. And it's unlikely that we would add them since I see no chance
of MakerWare ever supporting them. And there may not even be the code
space in the firmware for this.

Dan

[Wingcommander]

My big question is this: Is there a way to flash the values into firmware on a Replicator/2/2X, rather than through software?

The basic problem is that the x3g file format sends XYZ & AB (E) values to the printer in steps, not mm like gcode does.  The x3g conversion also pre-calculates the DDA value for the longest axis while accumulating the rounding error. This reduces the burden on Sailfish - so it can print faster - while maintaining accuracy.

The best way to think of x3g is as a printer control script. The x3g format is very low level.  Each file is essentially generated for a specific printer - Replicator 1, 2, 2X, TOM and cupcake. They all have slightly different axis lengths, movements and/or step lengths.

[Big-E]

Thanks for putting it all into perspective guys. As I've said, My machine has been pretty accurate out of the box. The only thing I may tweak is extrusions if anything, as sometimes holes are a little tight (Maybe .1 or .2 mm too small; Less noticeable when I print with only one or two shells). I usually correct through compensating for it when I design a part, by making the holes a hair larger, or I simply ream out my holes with a drill bit after printing (sometimes, it's better to have more material in there than not enough for a tighter fit)

The whole shebang makes a lot more sense to me now; I was just curious if there was a way to compensate in firmware, that way, you wouldn't have to make changes across all the software one can use, just flash some settings and go; not that it would be difficult to change software settings, but still, it'd be nice.

Thanks again :)

[Ming Kawaguchi]

yep, all the part numbers for standard 1 sided belts are A ... https://sdp-si.com/eStore/Catalog/Group/342

i've ordered multiple sets of replacement belts for my 2x and all of them have been gates gt2, so it's possible they've settled on a single supplier at this point. but, who knows --- sterling/designatronics is local to MBI and has low MOQs. they're generally quite a good supplier for prototyping and for short lead times on a wide catalog, and it seems pretty clear that they supply the timing pulleys. 

[Enginwiz]

I printed some ABS parts with the new calibration factor of 88.95 steps per mm 

and the printed parts still came out a bit too small.

ABS is more prone to heat shrink than PLA. Heat shrink happens in two

steps. In the first step the molten material shrinks while getting solid at the temperature

of the build plate. At the end of the print the build plate and the part cool

down in a second step to room temperature and the different thermal expansion

rates of glass and plastic lead to the separation of the printed part from the build plate.

To quantify the effects of the two heat shrink steps during printing and cooling after the print I

printed the calibration part with black ABS at 230°C on a glass build plate at 100°C.

Slicing of the part happened in Simplify3D at 0,15 mm layer height and 20% infill.

Immediately after the end of the print the still hot ABS part measured exactly 110 mm

in both directions.

After cooling to room temperature and separating itself from the

build plate the ABS part measured only 109,6 mm in both directions.

The loss in size due to heat shrink of the part seems to be 

dominated by the temperature difference between the build plate

(or for higher parts the temperature of the build chamber)

and room temperature. In this example a temperature difference

of 80°C led to a loss in part size of around 0,4%. 

To compensate for this post printing heat shrink an ABS part would 

theoretcally have to be enlarged by a factor of 1.004 in the slicing program 

to get get a printed part with the correct dimensions.

I will print an upscaled ABS part and see wether this produces a 

printed part with the correct dimensions of the original STL file.

[Wingcommander]

Enginwiz, I have had a similar experience with ABS shrinking after it cools. That was actually what precipitated me calibrating my X/Y axes. I figured I should start by getting my printer physically accurate,  then attempt to compensate for ABS shrinkage. Let me know how you go.

[Steve Johnstone]

Great observations guys.

[Joseph Chiu]

One thing that I've noticed in many of my ABS prints in a heated chamber is that the first layers seem to have a far greater amount of shrink than the layers above.  

If I were to print a square box, the side profile will be slightly rounded at the bottom edges, forming more of a U shape.  

My suspicion is that at the higher layers, as each layer is laid down at their nominal location, they are placed over plastic that has already shrunk most of the way to its final position; and that each successively layer gets only a small shrink-induced error term to their position.

But the ABS in contact with the bed has much more shrinking left to be done when the print is finished -- so that when the part is fully cooled, the first layers are pulled together much more.

Anyone else see this?

On Mon, Jan 6, 2014 at 10:50 AM, Steve Johnstone <stevene...@gmail.com> wrote:

Great observations guys.

[Enginwiz]

I scaled the STL in Simplify3D with a factor of 1.004 and sliced the gcode.

GPX conversion was done with 88.95 steps per mm in GPX.ini.

The scaled up calibration part was printed in ABS at 230°C nozzle temperature

on a glass print bed heated to 100°C.

After cooling to room temperature the printed part measured 110,05 and 110,07 mm

along the X- and Y-axis instead of the correct 110 mm in the STL file.

So in general upscaling before slicing works, but the factor of 1.004

is slightly too high. The perfect scaling factor for this calibration part

and a build plate temperature of 100°C might be 1.0035. 

I will rescale the STL for the calibration part in Simplify3D with a factor of 1.0035 

and print another copy with the same black ABS filament.

[Enginwiz]

I scaled the STL for the calibration part in Simplify3D with a factor of 1.0035 

and printed another copy with the same black ABS filament on the 100°C hot build plate.

After cooling to room temperature the lenght of the printed part measured 109.99 mm in X

and 110.0 mm in Y direction. All 10 mm square holes were between 9.95 and 10.05 mm.

The 5 mm bars were between 4.91 and 4.99 mm wide.  Nominal height of the part should be 4 mm and 

measured between 3.96 and 4.00 mm.

This strategy of scaling ABS parts with a factor of 1.0035 in the slicer and

using 88.95 steps per mm in GPX for the X- and Y-axis looks promising 

for printing dimensionally accurate ABS parts. 

Wingcommander: Let me know if this also works for your big running bike parts.

[Wingcommander]

Wingcommander: Let me know if this also works for your big running bike parts.

Will do, thinks for the feedback. 

[AeroJay99]

I'm a little late to the party, but how do I change this setting in Makerware?  Do I have to export a file to gcode, manually add lines to the gcode file in a specific place, and then use makerware's "print from file" option to turn the gcode into an x3g file?  I haven't used sli3er at all.  

Thanks, and this has been a very interesting discussion to read through.  

On Monday, December 30, 2013 8:27:34 AM UTC-5, Wingcommander wrote:

So I while back Jetguy posted an alternative steps per mm calculation which I have been using in GPX

[x]

steps_per_mm=88.88888888888889

[y]

steps_per_mm=88.88888888888889

However I decided to manually calibrate my printer using the attached script with a set of digital callipers I use for tramming my mill, which are attached to a magnetic clamp. With it I am getting within +/- 0.01mm using the following settings in GPX.

[x]

steps_per_mm=88.95

[y]

steps_per_mm=88.95

As always YMMV.