ToM MK7 ZAxis Binding Bearing Issues - Software Solution

[Jetty]

A common problem with the ToM MK7 seems to be binding in the Z Axis.
This shows up as an incorrect starting height, i.e. sometimes the
filament is squashed into the platform and sometimes it isn't even
touching the platform, and this seems to be caused by a variety of
issues, bent rods, not enough oiling, bearings binding. It also shows
up when it's really bad as missed Z steps in the print.

A general solution has been to oil the heck out of the Z axis rods,
however this is only a temporary solution, it comes back often mid
print.

A longer term solution is to replace with SW06UU or LMB06UU linear
bearings. (my bearings are on order)

I've noticed particularly at the start of the print that I get
vibration whilst the Z axis is moving fast, as one rod binds due to
friction and the other doesn't, which causes a rocking motion in the
platform, causes more binding and missed steps.

The software solution I've found which solves the issue is to slow
down the Z Axis. Apart from homing at the start and end of the print
being dog slow with this solution, you don't need fast movement in Z
during the print, and slow the axis gives gravity and friction time to
sort themselves out.

Since doing this, all prints start consistently and no more missed
steps.

These instructions are for ReplicatorG 29-r2 ToM MK7 with HBP on a
Mac, alter as needed:

1. Edit /Applications/replicatorg/machines/thingomatic.xml, find the
section with the name "Thingomatic w/ HBP and Stepstruder MK7".
In the axis id="z" line, change maxfeedrate from 1000 to 100 and
homingfeedrate from 500 to 100.
Restart ReplicatorG and check "Machine Information" in ReplicatorG to
ensure your changes have been picked up.

2. Because the homing commands have a 20 second timeout, and your
homing will now take >20 seconds, you risk hitting the HBP because the
homing command has been timed out if your nozzle isn't near the top.
To solve this, you use 4 homing commands instead of 1 (timeout out is
now 4 x20)

Edit /Applications/replicatorg/skein_engines/skeinforge-35/
skeinforge_application/prefs/SF35-Thingomatic-HBP-Mk7/alterations/
start.gcode
Find the line G162 Z F1000, and repeat it 3 times, so you have a total
of 4 next to each other.

Edit /Applications/replicatorg/skein_engines/skeinforge-35/
skeinforge_application/prefs/SF35-Thingomatic-HBP-Mk7/alterations/
end.gcode
and do the same with the G162 Z F1000 line.

3. Finally if you've stored any .s3g on SD cards, or you've built
any .gcode files that you're re-using, you'll need to reprocess these.

[Greg Thorstad]

Not to sidetrack this thread but is there actually a 20 second limit on
homing?

If so that would explain the issue some people are having with the Y not
homing all the way sometimes. I did a quick test and it does take right
around 20 seconds to home the Y. So if it is too far forward then it may
time out.

Greg Thorstad, B. Comm.
Thorstad Computer/Thor3d.ca/Canadian Makerbot Distributor
Box 268
Outlook, SK
S0L 2N0
306 867-9596

> --
> You received this message because you are subscribed to the Google Groups
> "MakerBot Operators" group.
> To post to this group, send email to make...@googlegroups.com.
> To unsubscribe from this group, send email to
> makerbot+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/makerbot?hl=en.
>
>

[Jetty]

Hi Greg.

Yes there is. I believe that the decompiled .s3g will show a timeout
parameter . I forgot to mention that and you're correct that the Y is
a problem on the ToM MK7 (the one you sent me). I've had that problem
where if the Y is as far forward as it goes (which it is when the
print finishes), then if left in that position, the next print won't
hit the Y stop, and the print isn't centered and the next time it
finishes the print, it slams against the front.

Duplicating the line: G161 X Y F2500 just once in start.gcode fixes
that one.

I would also guess that upping the homing speed for the Y axis
slightly in the thingomatic.xml would be another way of solving it, it
just has to reach home before the timeout occurs.

The timeout is there so that it doesn't endlessly search for a home if
an endstop isn't working.

[Greg Thorstad]

The Z binding problem seems to have just showed up with the MK7. We have
never really seen the problem here with the MK6. I was surprised when I put
together my first new machine with an MK7 and could not get the Z height to
dial in quite right. You are right I had to oil the heck out of the
bushings especially the bottom ones. I am guessing that the issue is the
weight difference. The MK7 is so light that it does not pull down very hard
on the Z platform. Has any experimented with putting a weight on the Z
axis.

Greg Thorstad, B. Comm.
Thorstad Computer/Thor3d.ca/Canadian Makerbot Distributor
Box 268
Outlook, SK
S0L 2N0
306 867-9596

----- Original Message -----
From: "Jetty" <clell...@gmail.com>
To: "MakerBot Operators" <make...@googlegroups.com>
Sent: Saturday, December 17, 2011 2:23 PM
Subject: [MakerBot] ToM MK7 ZAxis Binding Bearing Issues - Software Solution

[Greg Thorstad]

Thanks for the info, Jetty. I did decompile a s3g and found

Tool 0: Set target temperature to 225
Tool 0: Set build platform target temperature to 110
Home maximum on 4, feedrate 600, timeout 20 s

I was talking to one of the guys at Makerbot support about this a while ago
and have emailed him back with some info so they can get some sort of fix
maybe in the next release of replicatorG.

Either you knew lots about 3D printing before you bought your TOM or you
have learned a lot in a short period of time.

Greg Thorstad, B. Comm.
Thorstad Computer/Thor3d.ca/Canadian Makerbot Distributor
Box 268
Outlook, SK
S0L 2N0
306 867-9596

----- Original Message -----
From: "Jetty" <clell...@gmail.com>
To: "MakerBot Operators" <make...@googlegroups.com>
Sent: Saturday, December 17, 2011 9:34 PM
Subject: [MakerBot] Re: ToM MK7 ZAxis Binding Bearing Issues - Software
Solution

[Jetty]

> Either you knew lots about  3D printing before you bought your TOM or you
> have learned a lot in a short period of time.

I knew zero about 3D printing, apart from I wanted one :-) I'm just
determined.

So I've tracked down the timeout in the replicatorG source code to src/
replicatorg/machine/model/MachineModel.java

There's the following line in there:

double defaultTimeout = 20.0;

and surprisingly I also found when digging in the source, that you can
specify a "timeout" parameter in the axis xml of thingomatic.xml too.

The problem is we really need a timeout for safety reasons as a broken
or disconnected endstop could pull apart the machine if not noticed.
Also the timeout will vary per model of machine. So although changing
defaultTimeout to 30 seems like a reasonable thing to do initially a
better solution would be just to target the Y axis in the .xml for the
machines that are effected and then there's no need for multiple
homing commands.

If you let me know which machines in addition to the ToM with
Stepstruder MK7 are effected, I'll update the thingomatic.xml on
github and ask Makerbot to pull it into the next build.

[Small Pretty Things]

I for one, would appreciate this, as a TOM MK7 user with this exact Y-
axis problem. (Thanks for figuring that out Greg!)

30 seconds is probably overkill. The Y axis on my machine only need a
second or two more to hit the endstop. It usually times out and
reverses about 4-5mm before hitting the end stop.

Lyn

[Greg Thorstad]

Lyn- Actually you are the one that got me started on tracking it down. I
had noticed it on our TOMs but not dealt with it. Since you posted your
problem I got sidetracked with other things but Jettys post helped me figure
it out. I new there was a timeout somewhere but had not got to the bottom
of it yet.

This User group works pretty well most of the time to figure things out.

Greg Thorstad, B. Comm.
Thorstad Computer/Thor3d.ca/Canadian Makerbot Distributor
Box 268
Outlook, SK
S0L 2N0
306 867-9596

----- Original Message -----
From: "Small Pretty Things" <smallpre...@gmail.com>
To: "MakerBot Operators" <make...@googlegroups.com>
Sent: Sunday, December 18, 2011 11:17 AM
Subject: [MakerBot] Re: ToM MK7 ZAxis Binding Bearing Issues - Software
Solution

[Greg Thorstad]

I think it is all TOMs that have this issue.

Greg Thorstad, B. Comm.
Thorstad Computer/Thor3d.ca/Canadian Makerbot Distributor
Box 268
Outlook, SK
S0L 2N0
306 867-9596

----- Original Message -----
From: "Jetty" <clell...@gmail.com>
To: "MakerBot Operators" <make...@googlegroups.com>
Sent: Sunday, December 18, 2011 10:30 AM
Subject: [MakerBot] Re: ToM MK7 ZAxis Binding Bearing Issues - Software
Solution

[Jetty]

ok, I'll fork the ReplicatorG code, issue a pull request and change
the timeout for all ToM's. This should mean it will be in the next
release, and for the meantime, the fix will be just to download the
xml file and replace it on your local copy.

I'll provide a link here when down.

Regarding "side tracking", this will be a fix for just the Y axis
issue (and is kind of unrelated to my original post about the Z axis
binding).

[Luis E. Rodriguez]

This is weird, I've never had this problem but I've sped up the homing
routine to max speed with zero negative effect. At one point I thought
folks were homing once fast and then backing off and then homing again
slowly. All handled in the start.gcode for me personally.

Luis E. Rodriguez

[Far McKon]

Lyn/Jetty:
A per-axis fix in the .xml file and a pull request would be AWESOME! I
look forward to that.

Also, Z-Hold changed in firmware 2.8 to 3.0. If you upgraded both at
the same time, maybe some of the effect might be firmware changes?

yarr & hack on,
- Far McKon

Desktop Lead and Nerd Herder
MakerBot Industries

[Mark Cohen]

This would be why a gen4 cupcake needs 2 z homes and one with a low
rider and z rider needs 3.

Sent from my iPhone

[Jetty]

> routine to max speed with zero negative effect. At one point I thought
> folks were homing once fast and then backing off and then homing again
> slowly. All handled in the start.gcode for me personally.

I think the reason for this is for accuracy reasons due to inertia.

The first faster home is to reach the limit in a short amount of time,
then it retraces a small amount and does it again but slowly, to get a
more
accurate read.

However the issue then becomes, can it hit the limit before the homing
command times out (a safety feature). So if the timeout happens
before it reaches, the 2nd slow retrace may or may not hit it
depending on how far away it was when it timed out.

On the Y axis, the homing is just a little bit to slow, or has a
little bit too far to go, so for example, the home from the extreme
takes 22 seconds, and the homing command times out at 20. If you
don't home from the extreme then you won't encounter the problem.
It's just that when the print finishes, your print is ejected and it's
at the extreme Y, so the problem shows up. Previously I got around it
by just pushing the platform in before the next print.

So there are a few ways to work around it:

1. Increase the timeout
2. Speed up the initial home so it completes before timeout
3. Push the platform in before print
4. At the start of the print, send a gcode command to move the
platform in a bit

I favor 1. and changing thingomatic.xml for 2 reasons. Really it's a
geometry problem, the Y Axis is larger than the code thinks it is and
that's a machine specific problem. The second reason is that changing
the timeout does the least damage, i.e. we're not making any
assumptions about mechanics / design of the machine.

[Jetty]

I've sent the Y axis timeout fix to makerbot and asked them to pull it
into the next release of ReplicatorG.

In the meantime, if you're on the latest ReplicatoG (0029-r2), then
this is a "safe" fix that you can update on your own very easily.

Find the file machines/thingomatic.xml which you can find in your
Replicatorg application folder, and replace with the one here:

https://github.com/jetty840/ReplicatorG/blob/1209623d8f46cfb5e1a35c798288747ffd7f0a8c/machines/thingomatic.xml

Then restart your ReplicatorG.

---
For those github guys who need it, here's the pull request:
https://github.com/makerbot/ReplicatorG/pull/249

[Federico Heinz]

On 18/12/2011, Greg Thorstad wrote:
> I am guessing that the issue is the
> weight difference. The MK7 is so light that it does not pull down
> very hard on the Z platform. Has any experimented with putting a
> weight on the Z axis.

I just did. I placed a 400g weight on the Z platform, just behind the
motor, and the binding issue (which was plaging me too) disappeared.

Fede

[Greg Thorstad]

If anyone wants to go the alternate route with the Y axis not homing
problem and speed up the Y homing, it appears you have to speed up the
X as well because they are homing at the same time. I tested only
changing the Y on the XML file and it had no effect until I changed
the X Homing Speed as well.

[jet]

On 12/17/11 19:38, Greg Thorstad wrote:
> Not to sidetrack this thread but is there actually a 20 second limit on
> homing?

Yes, I submitted a patch that allows for a workaround.

--
J. Eric Townsend, IDSA
design <http://www.allartburns.org>
hacking <http://www.flatline.net>
fabrication <watch this space>

[Dan Newman]

On 5 Jan 2012 , at 2:21 PM, jet wrote:

> On 12/17/11 19:38, Greg Thorstad wrote:
>> Not to sidetrack this thread but is there actually a 20 second limit on
>> homing?
>
> Yes, I submitted a patch that allows for a workaround.

And until you have the workaround, you can either

1. Manually disable the motors and by hand slide the carriage back and
to the side in the general direction of the limit switches, or

2. Using the machine control panel's "Homing" menu item, home each
of the axes while waiting for a warm up.

As regards 1, I've never myself needed to worry about a time out
on the Z-axis. And, you don't need to push the carriages all the
way to the stops -- just get them nearby and you won't experience
a time out.

Dan

P.S. Presumably the timeouts are there so that the bot doesn't damage
itself, trying to move something for 3 minutes, getting nowhere owing
to a blockage, and damaging something in the process.

[Mark Cohen]

It's easier just to add multiple homes to the start.gcode

Sent from my iPhone

[Dan Newman]

On 5 Jan 2012 , at 3:52 PM, Mark Cohen wrote:

> It's easier just to add multiple homes to the start.gcode

But not as fun if you'd a litle more hands-on in the process ;)

Dan

[charlestx]

I just tried the "adding weight to the z platform" method. It worked
great for me. No more binding issue. The tough part is finding
something with enough mass and yet small enough. I used about 300g.
Thanks for the suggestion!

On Dec 19 2011, 5:53 am, Federico Heinz <fhe...@gmail.com> wrote:
> On 18/12/2011, Greg Thorstad wrote:
>
> > I am guessing that the issue is the
> > weight difference.  The MK7 is so light that it does not pull down
> > very hard on the Z platform.    Has any experimented with putting a
> > weight on the Z axis.
>

> I just did. I placed a400gweight on the Z platform, just behind the

[alex e]

Adding weight to the Z does work for MK7, yes.

> >http://groups.google.com/group/makerbot?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Jamesarm97]

Did you add it to the very front where the extruder sits, or behind
the extruder near the Z rods?

[Greg Thorstad]

I am not sure where Alex put it but my vote would be for as close as
possible to the z rods so it is pushing straight down rather than creating
torque on the bushings.

Greg Thorstad, B. Comm.
Thorstad Computer/Thor3d.ca/Canadian Makerbot Distributor
Box 268
Outlook, SK
S0L 2N0
306 867-9596

----- Original Message -----
From: "Jamesarm97" <armstro...@gmail.com>
To: "MakerBot Operators" <make...@googlegroups.com>
Sent: Thursday, February 02, 2012 9:07 AM
Subject: *****SPAM***** [MakerBot] Re: ToM MK7 ZAxis Binding Bearing
Issues - Software Solution