Automatic tramming/leveling on a Replicator 2X

[Scottbee]

This is a project that I've been working on for about two months, and have had operational for about a month.

I now have enough prints across my #1 machine (hundreds) to consider it to be reliable, and have replicated it onto my #2 machine... so in some ways I consider it to be repeatable.  It works and is not just a one-off uber-tweaked hand-crafted gizmo that would never perform outside of some controlled confines.

Some background:  I got my first R2X in December of last year.  It is/was part of a larger plan to build a "printer farm" at one of my companies, producing ABS components for our custom-configurable products on a 2-shift basis (the second shift the machines would run unmanned and lights-out).  The components that we are currently using are hogged out of billet, and our product lifecycle and volumes are such that injection molding is not economically viable.  The cost savings by going to printing (assuming strength, durability, and aesthetic criteria are met) are impressive and the payback period and ROI are excellent.... if we can do this with a sub-$3K prosumer machine and low-cost consumables (i.e.: no-Mojo).

After evaluating the R2X for a couple of months I came to the conclusion that the machine could absolutely produce parts that met our requirements.  But it would not be realistic to assume that a machine like the R2X could be put into a production environment with traditional ham-fisted manufacturing personnel and produce quality repeatable components over the long haul.  There were/are technical tweaks and operational skill level requirements that didn't align with the resource pool at my disposal.  I tried to bracket these "production weaknesses" and see if I could engineer some modifications that would make the machines more production-robust without blowing the economic justification.

The three main areas that I felt needed attention were/are:  Build plate leveling/tramming, build surface adhesion and preparation, and compensation for filament diameter variations (within standard filament production tolerance bands).

Over the last few months I have designed and implemented what I think are viable "solutions" to the first two issues, and am on the cusp of resolving the third.  Here I'll discuss how I went about handling the "automatic tramming/leveling" challenge.

Most of us here are probably quite good when it comes to tramming/leveling our build surface, and with stiffened Z-arms and some care when using or removing our build surface, we can probably go for days if not weeks without re-tramming (and do it on-the-fly while the first layer is printing).  But in my production environment I knew that we were going to be using multiple removable build plates (which may not be dimensionally identical) and human resources that can be a little heavy-handed at times.  I felt that hands-free automatic adaption to the new build plates is required, along with the ability to re-calibrate the surface (machine wear and deformation) was a better solution than alternatives like removable rafts.  When I went looking for the prior-art for such systems that could be adapted to my 2X's the bulk of the technology that I found revolved around a switch or sensor that would be affixed to the carriage that could be used to determine the existing orientation of the build surface with respect to the XY plane of the gantry, and then use software/firmware to "tilt" the printing of the model (Euler angle transforms and the like) to adapt to the errant build surface.  Alternately, the switch or sensor could be used to "assist" an operator with performing the traditional tramming/leveling routine (MBI Gen5).  The latter didn't really satisfy my "automatic" requirement, and I was unable to find a fully fleshed-out implementation of the adaption system that was ready for prime-time and could be used with a semi-standard set of tools and workflow.  So I pondered it a while and came up with my own solution.

In lieu of determining the errant orientation of the build surface and contorting or modifying the model so that it would "print true", I decided to use the existing XY hardware (gantry, carriage, nozzle(s)) to contort and modify the build surface so that it would be parallel to the printing XY plane and gapped properly to the nozzle.

To do this I came up with a system that allows the HBP on my 2X to essentially levitate, sitting on three low-K springs that do little more than offset the weight of the HBP assembly.  Replacing the three leveling jack-screws are three "gimbaling pins", and there are three corresponding pin clamps built into the span/spreader plate.  These pin clamps can lock the gimbal pins at an infinitely variable Z elevation.  The clamping is performed by a lever arrangement that is actuated by a cam profile on a worm gear that is driven by a simple DC motor.  The DC motor is controlled by X3G code (gcode) that leverages the unused "Fan_Cool" (Extra_FET) on the RevH MightyBoard.

This is what the mechanics on the underside of the span plate look like (Rev1):

In practice, the 2X will move the carriage to each of the tramming/leveling locations, perform a Z move to contact the nozzle to the build surface and then "depress" it to a fixed elevation, and lock that elevation in place.  After the operation is complete the surface of the build platform is now parallel to the plane of the XY motion, and the nozzle gap has been properly set.  

A video of the system in operation (Rev2):

The tramming/leveling routine can be run as a stand-alone X3G that we just put on my SD card, but in my production environment I prefer to have it as part of the start.gcode for every print.  The printer comes to operating temperature (so there isn't any hard ABS on the nozzle tip(s).. and so that the unit has thermally stabilized), performs the tram, and then immediately starts printing.  It adds ~10 seconds to every print.

As a caveat and reminder, this system will not compensate for warped or otherwise deformed build surfaces.  It will take three points on the build surface, call that a plane, and set that plane parallel to the XY motion plane.  If there are mountains and valleys in-between those three points the system has no way of knowing.

As I mentioned at the beginning of this diatribe, I have two machines with this system currently installed, and there will hopefully be a third in the next week or so.  To-date the results have been quite, quite promising... and the first layer repeatability has been as good if not better than what I can achieve with a methodical traditional manual approach.

Enjoy!

[bigjosh]

Very elegant solution!

...can't wait to see how you approached the filament width issue.

[Jimc]

Good to see it coming along scott! Great work.

[Scottbee]

This is the link to the genuine iPhone video of the auto-tram running:

Auto-tram Video

I didn't realize that trying to insert it in the post only gave a "thumbnail video view".

[Scottbee]

Thanks Jim!

I'm pleased that it has worked fairly well "right out of the gate".  I was braced-for and was expecting to have to do a lot more tweaking of the design in order to get it to work as planned... but so far, so good.

The first version was on a R2X with the inexpensive "aluminum wrap" Z stage arm stiffeners.  That worked well.  Then I upgraded to the BottleWorks all-aluminum arms and it continued to work with nary a change.  I went over to a Rev2 design which changed the direction of cam rotation and the leveling order (which works better on a dual-extruder setup... and just makes more sense).  Still rock-solid.  Then I build a second setup and put it on a completely different machine.  I figured this would be where I got shot in the foot and would discover that I was a "one trick pony".....  but it worked as-planned there also.  Now we're putting another rig on a machine with a 3rd party (BottleWorks) HBP.... with fingers crossed.

I'd still love to see how one of these works on an M2 like yours....  but obviously that's going to require a whole new layout and some 1st-person familiarity with your machine.

[Ryan Carlyle]

Scott let me look at the design a little early, and I think it's a better concept than the usual carriage-mounted switch sensors.

The really great thing about this design is that it physically moves the bed to a trammed position using the Z motor and nozzles. That eliminates a lot of the issues with repeatability that height-sensing switches have. (Switches don't always switch at the same distance/travel.) The only position-sensing switch here is the Z axis limit switch, and tram gap positioning is relative off of that... So there's no error introduced from switch travel variation.

As long as your nozzles are even and build plate is flat, this is pretty bullet-proof.

[Pomme]

Wow, It is very impressive!

Do you have any plans to release your design? kitbom.com, thingiverse.com or anything similar? I'm very curious about the "gimbaling pins" and the three corresponding pin clamps that you used.

I wonder also if your support bended with the pressure required to push the surface in position and if you compensate for it in the gcode?

Thanks for sharing this idea. You are a talented engineer.

[Brandon Andrzejewski]

Very well done!  Any offers from Stratasys or 3D Systems yet? ;)

[Scottbee]

Thanks!

I don't haven't formulated any long-term plans for the design.  Right now I am concentrating on building and testing them for my printer farm.  I have also release a unit "out into the wild" for external testing and perhaps some refinement of the software implementation.

Of course, virtually any system will deflect when you apply a load to it, and the R2X is no exception.  When you use the nozzle to press down on the build surface the gantry will deflect "up" and you'll also get some elastic deflection of the Z-stage springboard.  This can be reduced through the proper selection of the "levitation springs", but you'll never eliminate the "error".  The good news is that the deflections have been very repeatable on my machines, and therefore you can easily characterize them out via the gcode.  Although I was concerned about this in the beginning, it has mostly proven to be a non-issue.

The "gimbaling pins" is only important if you want to talk theory.  In practice the M3 studs and stainless HBP baseplate allow for enough angular deflection to eliminate the need for some true "gimbal" mechanism.  The pin clamps (printed in ABS) have a fairly small contact patch on the pins (which are just SST tubes installed over the M3 studs) and they allow a bit of angular deflection also.  I was worried about a shimmy-bind... but haven't really seen that either.

[Scottbee]

Uh... no.  They haven't been blowing up my phone....   ;)

But you must admit, eliminating tramming and all of those first-layer issues would certainly make life easier on novice users and reduce the volume of technical support phone calls.

The experience user just looks at the nozzle as it is laying down the first layer... reaches underneath, and gives a knob an 1/8 turn.....

[mkapras]

Wow! That's a sweet solution! When you have the printer farm auto-leveling itself - I want to see THAT video! Rise of the Machines! ;-)

[Brandon Andrzejewski]

This is true, experienced users do not have troubles with leveling (assuming they aren't running a warped HBP).  I do think that automated build surface leveling is the next logical step in bringing the technology from the tinkerer market into a system your grandma could run.  Any idea what the professional FDM systems use for leveling?

I do have one real question on your system.  What are you using to detect the collision with the nozzles?  I would assume you are ignoring the Z limit switch completely and using the stepper resistance to feel out the collision?  I ask because the Z limit switch only tells you were the Z stage is, not the build plate itself.

[Jetguy]

You totally missed the operation.

It still uses the normal Z stage switch. The motorized can locking system UNLOCKS the 3 point leveling springs and posts the bed sits on as the bed rises to hit the Z min limit switch. The start.gcode has been modified to position the extruder carriage over top of the 3 point leveling posts. The cam system then locks that new calibrated postiion mechanically from the nozzle resting against the build surface. Basically, the system adjust the bed to mechanically touch the nozzle. Then via homing offset or gcode, one can "recalibrate" 0 Z level to be the proper distance above the now "mechanically zeroed" bed.

 

Again, the trick here is the cam lock system instead of leveling screws. They are smooth posts and the bed still sets on springs. The locking cam system allows the posts to be unlocked and locked position wise in a sequence.

[Jetguy]

Stupid typo, I meant CAM locking not can.

On Tuesday, April 15, 2014 2:49:39 PM UTC-4, Brandon Andrzejewski wrote:

[Jetguy]

The ONLY downside to the current system is that it uses the "extra" fan output (AKA the cooling fan on the Replicator 2) or the unused port on the both the original Replicator and 2X models.

This means you probably have to pay attention in the slicer and not turn on the fan control which now controls the cam locking motor system. Further, at this time, I'm not sure you can have both, the cam locking and the fan control?

 

I know Scott has been working very hard on this and it is a very impressive system to work around the many limitations of firmware and hardware so that anyone can use this without special firmware or major changes.

My hat is off to Scott for a very innovative and well thought out system.

[Scottbee]

I was told that the MoJo uses dissolvable/disposable rafts (made from their expensive consumables).

Frankly I don't about the other systems.

[Normand]

Nice job!

Do you think it would be possible to trigger a release mechanism when the support hit the bottom of the printer in Z? That would spare the need for a DC motor.

You sparked something there. Thanks

[Jetguy]

Well, for example the CubeX Duo and entire series uses a massive metal frame, huge and nicely machined linear bearing holders and stainless Z axis arms.

They simply built the frame right the first time, as well as the z stage that it stays square and true and doesn't require frequent leveling and adjustments.

 

Why you guys and must of the industry puts up with Plastic Z arms and other shoddy parts in a $2K + machine blows my mind.

 

But that's the problem, rare is the perfect bot. One company seems to get one aspect right, and then everything else is bad from software to other hardware.

This is why I more or less gave up and started building custom bots or modifying other bots to correct the problems and get the best of all worlds.

[Scottbee]

Thanks!  Means a lot coming from you.  (I've seen your work!)

You're absolutely right...  I stole the only available DO point that I could find/control on my RevH board... and that was "Extra_FET" (FAN_Cool).  You have to make sure that your slicer is not diddling M126/M127... and if you are running a PLA-style cooling fan you're out of luck.  Yes, a switch can be added.... but that takes some of the shine off of "automatic".

If I had a single extruder system with a cooling fan (Rep2) I could actually get a bit more exotic.  I'd swap out the DC motor for a small cylindrical stepper and drive the cam with T1 extrusion commands.  That doesn't really buy me much of anything besides "wow" factor (and an increase in build cost).

Of course, once you uncork custom electronics and/or firmware you get all kinds of additional options.

[Brandon Andrzejewski]

On Tuesday, April 15, 2014 2:22:39 PM UTC-5, Jetguy wrote:

You totally missed the operation.

Wow, yes, I really did.  I got the neutral spring arrangement but somehow disconnected that from the actual leveling process.  Thanks for the [repeat] explanation. My bad, that's what I get for browsing this forum at work. =/

[Ryan Carlyle]

Jetguy, it would be fairly straightforward to make a manual mode select switch, so the fan control FET runs the cooling fan in print mode versus the cam drive in leveling mode. Maybe it's not elegant, but it would work well enough. Compared to messing with thumbscrews and feeler gauges, flipping a switch and running a level-script off the SD card is EASY MODE. 

To my mind, the benefit of this for experienced users is that you can swap build plates and extruders and not worry about minor height/thickness differences.

On Tuesday, April 15, 2014 2:28:06 PM UTC-5, Jetguy wrote:

[Randy_y]

Replacing the three leveling jack-screws are three "gimbaling pins", and there are three corresponding pin clamps built into the span/spreader plate.  These pin clamps can lock the gimbal pins at an infinitely variable Z elevation.

First, Scott, this sounds awesome.  I'm not sure if I understand how the gimbaling pins lock at infinite levels.  I see that they have long arms (elegant torque solution from the dc motor) and see how the motor sequencing cam works but how do they lock the plate when engaged?  Also, when you disengage, how do the locks open?  I don't see any return springs.  Can you take a close-up photo of the gimbal pin/ clamp?

Are you concerned about the lack of feedback on the motor?  It seems like a servo would be good here (although it would require firmware changes).

Anyway, keep up the good work!!!!

 

[Scottbee]

Randy,

I bugged-out of the office early today to ensure that my good Uncle Sam and I stay on speaking terms.  I will have access to my library of images and 3D CAD models when I get back to the office tomorrow.

The mechanism is probably a lot less complex than you think.  The three colored ABS "lever arms" are actually the clamps.  They ride on a cam profile on the underside of the worm gear (that creates lateral movement)...  and they have pivots and "living hinges" close to the centerlines of the three leveling pins (somewhat hidden by the MBI thumbnuts).  So there is a lot of mechanical advantage.  The actual clamping is done with two half-moon jaws printed right into the arms.  They're one-piece units.

The "gimbaling pins" are just stainless tubes that are slid over the factory M3 leveling studs, and the tubes are locked in place by the MBI thumbnuts.  The thumbnuts are no longer used for any kind of adjustment.  The half-moon jaws on the ABS arms ride on the OD of the stainless tubes, and when the cam moves the lever the jaws squeeze the tube, creating the "locking" friction.  It's not a "hard lock", and if a nozzle crashes into the build surface the plate will move before the nozzle becomes damaged.  

One of the advantages of using the stainless tubes as "liners" around the M3 studs is that there is an annular gap between the stud and the ID of the tube.  This can be used to compensate for center-to-center variations between the M3 studs and the corresponding clamp locations in the span plate.  You allow the thing to find its own "happy place", then lock the tubes into place with the MBI thumbnuts.

I would love for the DC motor and cam to have feedback to the controller (or have the cam motor be a stepper), but the architecture of the existing MightyBoard just doesn't support that (on dual extruder machines).  So, instead, there is a microswitch under the worm gear/cam that you can't see.  After the cam has rotated about 320 degrees the microswitch will kick in and drive the cam to the 0/360 position.  It's a "poor man's auto-homing", and it helps to ensure that the cam starts from the same position every time that you initiate the tramming routine.  It doesn't artificially create accuracy, but it does help to eliminate cumulative errors.

[Justin Blake]

That really is a beautiful, elegant solution. Well done. I hope you release the designs at some point, I would love to add one of these to my machine.

[Bas van Deursen]

Brilliant!!! I love it! I would be really interested to test it on my machine.

-Bas

[Fri Rider]

Very nice!!!
Would you share the files for the components?
Thanks

On Monday, April 14, 2014 9:38:38 PM UTC-4, Scottbee wrote:

[Scottbee]

Fri,

I'm not trying to be a jerk here (I don't have to try, it comes naturally)... but I don't consider my implementation to be ready for public consumption yet.  I'm just a bump beyond Alpha testing and am just moving into Beta.

There are hardware refinements that I am currently working on, and the software side is being pondered and refined as well.

I'll discuss the implementation all day, but I don't want to release any source yet.  I prefer to slow-roll this a bit.

[Bryan Casey]

Did you happen to take pictures of the cam mechanism (the flip side - what we can't see in the first picture)?  I think that's really why people are asking for models: so they can see the mechanics of how you've made a single motor control three cams.

[Ryan Carlyle]

It's impressively simple when you see it. But it's Scott's IP so I won't comment 'til he shows the group.

I puzzled out the gist before seeing it, and you probably can too if you think hard enough  :-) 

[Scottbee]

It's easy to over-think and over-Engineer stuff.  I know that I certainly started going down a much more complicated path than was actually necessary when I embarked on this project.  The nudging of a couple of peers saying stuff like "not necessary", "over-thought", "fluff".. helped.

The clamp arms are pretty simple, but not the easiest things in the world to print.. even on a well setup machine.  There came a point when I decided that I was just beating my head against the wall and that I should bite the bullet and do a couple of secondary operations with traditional methods.

The gear-cam is simpler than one might think... but it's also a bit of a bear to print.  You only need to release one clamp at a time to do the tramming, so there is only one "inverse lobe" location... with a lot of dwell.

Once you get your head wrapped around the way it works, you'll probably just say "duh".

[Robert Quattlebaum]

I'm almost afraid to ask, but... Do you intend to patent this mechanism? And if you do decide to patent it (and the patent is granted), would you consider giving a license to people who build their own for personal use to do so royalty free?

I know that if I built one and it worked well I would happily "buy you a beer" and then some (It's a great design!). I'd be quite disappointed if I wasn't allowed to build one of these marvelous devices myself one day.

Again, this is a great idea, and thanks for sharing how it works with everyone!

[Scottbee]

On Thursday, April 17, 2014 12:53:23 PM UTC-5, Robert Quattlebaum wrote:

I'm almost afraid to ask, but... Do you intend to patent this mechanism? And if you do decide to patent it (and the patent is granted), would you consider giving a license to people who build their own for personal use to do so royalty free?

I know that if I built one and it worked well I would happily "buy you a beer" and then some (It's a great design!). I'd be quite disappointed if I wasn't allowed to build one of these marvelous devices myself one day.

Again, this is a great idea, and thanks for sharing how it works with everyone!

Robert,

Don't be afraid to ask.....  but I should probably be afraid to answer!

I'm an inventor by trade and profession.  It's how I make my living, it's how I feed my family.  And therefore my normal workflow involves invention disclosures, provisional patent applications, and patents. This invention and embodiment was no exception.

I didn't go after IP protection to preclude the individual enthusiast from utilizing the technology to enhance their own systems.  If a person wants to expend time and energy to get this type of system to work on their machine I certainly won't get in their way... and will (on a limited basis due to my own time constraints) make attempts to be helpful (but it's a little early in the program for that).  The IP protection is basically to stop some enterprise from coming in and making the invention their own, generating revenue and profit without some form of appropriate acknowledgement and attribution to the inventor.  We inventors usually have a substantial investment in our designs... both time and money.... and just like anybody else we like to see a return on that investment.

That's not always a popular position and methodology in the "open source" world.......

[Robert Quattlebaum]

On Apr 17, 2014, at 1:48 PM, Scottbee <scott.e...@gmail.com> wrote:

> Don't be afraid to ask..... but I should probably be afraid to answer!
> I'm an inventor by trade and profession. It's how I make my living, it's how I feed my family. And therefore my normal workflow involves invention disclosures, provisional patent applications, and patents. This invention and embodiment was no exception.

I'm not necessarily anti-patent, at least for hardware, which this clearly is. Not sure about everyone else.

I have no problem with you patenting what appears to me to be a novel and inventive hardware mechanism.

> I didn't go after IP protection to preclude the individual enthusiast from utilizing the technology to enhance their own systems. If a person wants to expend time and energy to get this type of system to work on their machine I certainly won't get in their way... and will (on a limited basis due to my own time constraints) make attempts to be helpful (but it's a little early in the program for that).

I am relieved and quite happy that this is how you feel. If you are granted the patent, would you consider explicitly granting a limited-scope personal-use royalty-free license for enthusiasts who would like to build their own?

> The IP protection is basically to stop some enterprise from coming in and making the invention their own, generating revenue and profit without some form of appropriate acknowledgement and attribution to the inventor. We inventors usually have a substantial investment in our designs... both time and money.... and just like anybody else we like to see a return on that investment.
>
> That's not always a popular position and methodology in the "open source" world.......

Well, there is a huge amount of animosity toward the patent system due to some governments allowing patents on software mechanisms. This is clearly a hardware mechanism, so I have no philosophical issue with it. (Although 3D printers do at times seem to blur the line between software and hardware)

Again, great job, and I look forward to hearing more about it once you have finished polishing it!

-- Robert

[Bernard Kerckenaere]

On Wednesday, April 16, 2014 9:59:05 PM UTC+2, Scottbee wrote:

Fri,

I'm not trying to be a jerk here (I don't have to try, it comes naturally)... but I don't consider my implementation to be ready for public consumption yet.  I'm just a bump beyond Alpha testing and am just moving into Beta.

There are hardware refinements that I am currently working on, and the software side is being pondered and refined as well.

I'll discuss the implementation all day, but I don't want to release any source yet.  I prefer to slow-roll this a bit.

Any updates on your current status?

I'm about to put together my interpretation of an i3, and would love to put a system like this in it (I really don't like the more common probe method of compensating for an unlevel bed through software.) I was thinking of lasercutting the components out of acrylic, instead of printing them, it doesn't look like this would be a problem, apart from needing to bond together two layers to form the main gear?

Can you tell me what the height of the space is between the mounting plate and top plate with this mechanism sandwiched between them? Then I can at least take this into account while I'm designing where to put the Z axis endstop.

Nice work!

[Scottbee]

My current status is that I have one of them out in "gen pop" and the (proud?) owner has been putting it through its paces.  He hasn't found any bugs or real/substantial problems yet.... which either means it is an amazing invention or my Alpha tester is a slacker....  ;)

The mechanism doesn't consume any space between the span plate and the build platform or HBP.  It is slung "under" the span (spreader) plate... essentially below the Z gantry.  It is low profile enough that it doesn't reduce the available Z stroke on the Replicator class of hardware.

You would have to use a different design approach for the pin clamps if you wanted to do them via laser-cutting, and you wouldn't be able to get the correct helical hob-profile on the main gear... but that's not to say that it's not "do-able".  The theoretical sexiness of my main gear is gross overkill for the RPM and loads that this runs at, and there are many ways to skin the cat when it comes to making a simple pin clamp.

[Aisflou .]

Hello here!! :D

Any news on this subject?

Im very excited with this bed leveling tecnique!!