Welcome! Log In Create A New Profile

Advanced

Correcting horizontal banding in gcode with python

Posted by justine.haupt 
Correcting horizontal banding in gcode with python
October 05, 2017 05:09PM
Hello,

I've been commissioning a homebrew large format printer for a couple months now, pulling my hair out with redesigns to fix various mechanical issues as I go.

The machine in question is large (24" square build surface) and I went with a 4 linear shaft + 4 leadscrew arrangement belted to 2 motors. Learning an alignment/setup process has been painful and hindsight is 20/20, but long story short I have a periodic error in the Z movement which is likely due to eccentricity of the pulleys. Using a digital drop indicator revealed a periodic deviation of -.013mm to .042mm from the nominal Z movements with a period exactly equal to the leadscrew pitch.

This causes fairly extreme horizontal banding in my test prints and needed to be corrected.

I had already redesigned the Z motion system once, and considering the error is predictable, I wrote a simple Python script to post-process any gcode I run to imprint a negating deviation, being sure not to exceed the Z step resolution (5um in my case). This also required that I clock the leadscrew pulleys to be synchronized.

Here's a print without correction:



And with:



See here for a couple more photos: [lightsmithscientific.com]

For me this is a temporary solution, but if anyone has a need I went ahead and put the code on GitHub: [github.com]

~Justine

Edited 2 time(s). Last edit at 10/05/2017 05:14PM by justine.haupt.
Re: Correcting horizontal banding in gcode with python
October 06, 2017 02:37AM
Interesting solution, but I like it. Even though it's a bandaid fix, the results look pretty good.

+1 for thinking out of the box!

But what are your plans on fixing the mechanical error? If you share pictures of your build we might be able to help come up with some constructive suggestions.
Re: Correcting horizontal banding in gcode with python
October 06, 2017 10:37PM
Thanks Jerry.

I already have the new version worked out, but this is a picture of what I have now:



The belts are loose there as I took the picture during assembly, but you get the idea. It's a printed polycarbonate double 60T GT2 pulley that the leadscrew threaded right into. I'm pretty sure the pulleys are eccentric, as I can see the belt breathing in and out a little as it rotates. The linear shafts are hiding in that shot.

This is what I have in mind for the fix:




The blue parts in the cross section will be printed (polycarbonate), whereas the pulleys (from SDP/SI) are on a 6mm stainless dowel. The pulleys already arrived so I'm just waiting on the dowels.
Re: Correcting horizontal banding in gcode with python
October 07, 2017 12:16PM
It's probably more a question how you connect the leadscrew nuts to the bed to avoid z-wobble translating from the screw to the bed.
Re: Correcting horizontal banding in gcode with python
October 08, 2017 07:47PM
Hi o lampe,

There's NO Z wobble. The banding is a periodic dilation (expansion and contraction on all sides of the print), not an offset. The problem is that there's a residual motion in the Z movements so that sometimes layers are more compressed and sometimes less, leading to variation in the effective extrusion width, causing the bands.
Re: Correcting horizontal banding in gcode with python
October 09, 2017 03:41PM
Maybe adding weight to the buildplate will help alleviate the sticky z-movements?

Either that or a nice silicone lubricant if you've already checked the parallel alignment of the rods.


Build Log - DDDE 330x330x300mm Ultimaker
Re: Correcting horizontal banding in gcode with python
December 08, 2017 06:12PM
Update, FYI:

The problem was eventually fixed by going with 4 "powered leadscrews" from Thomson Linear (stepper with leadscrews instead of conventional shafts). I went with narrower screws with 10mm diameter and 2mm thread pitch, and mounted with the motors on the top-side and the bottom of the screws free-hanging. Positioning accuracy as measured with a digital dial indicator is now +/- 3um.

Also FYI, the original image links for the Python gcode fixer before and after photos are dead.

Photo of print before processing: [justine-haupt.com]

And after: [justine-haupt.com]
Re: Correcting horizontal banding in gcode with python
December 29, 2017 03:24PM
Kudos! You did find a very refined solution!
This is a really unusual and very interesting idea how to compensate periodic inconsistent vertical move. At least for someone who don't want to change extensive mechanic system.
Though, you have to test a lot to find the optimized settings and you must run the script for every print.

It would be interesting to know what the reason really was. You think it was caused because the pulleys are eccentric. Maybe it is possible to proof this with a disc like a clock face and a pointer mounted on the lead screw. In similar way we tested the clocking of stepper motors.

If I understand correctly, you mounted 4 motors with integrated lead screw on top upside down.
How many driver you use and how wire them?

We had exactly the same issue in the German forum.
[forums.reprap.org]



I told him to measure the height of bed each 0.2mm.
This is my analysis of his 4 measurement series:



The oscillation width between the red lines are about 0.035 mm
He has 4 linear shaft and 2 lead screw arrangement to move the print bed.
The 2 motors are on bottom.

Now he changed the arrangement, in principle like yours at first, driving the lead screw belted to motor.
But odd, he says now there is no banding anymore.
Another odd thing is, he never had this problem if he printed spiral vase mode.

BTW, if you insert images by "Attach a file..." the images are directly visible and furthermore they can't get lost by broken link.

Like this: Print without correction





Michael

Edited 2 time(s). Last edit at 12/30/2017 06:02AM by wersy.


Konstruktionen: [www.thingiverse.com]
Videos: [www.youtube.com]
Mein Club: [hackerspace-ffm.de]
Drucker: Wersybot - seit 2012 smiling smiley
Re: Correcting horizontal banding in gcode with python
December 30, 2017 09:55AM
Thank you Michael,

Quote
wersy
It would be interesting to know what the reason really was. You think it was caused because the pulleys are eccentric. Maybe it is possible to proof this with a disc like a clock face and a pointer mounted on the lead screw. In similar way we tested the clocking of stepper motors.

In retrospect it had nothing to do with the pulleys. I changed to machined aluminum pulleys (from SDP/SI) and it didn't make a difference. In fact it didn't even make sense that it could be pulley ellipticity, because the banding would have had to occur twice per full revolution and it was only happening once per rev. I'm quite sure now that it was from the leadscrews not being straight enough. Unfortunately, no amount of effort in straightening the original leadscrews completely eliminated the problem, although I was able to reduce it significantly.

The ultimate fix was switching to direct drive "powered leadscrews", which I bought from Thomson Linear with custom lengths (much longer than they usually sell) for about $200 each. There are four of those wired with two in series to one drive and two in series to another. Pictures here (thank you for the photo attachment tip):





These new leadscrews are much thinner (10mm diameter versus the previous 16mm ones). That's intentional, though counter-intuitive. I concluded that it would be better to have the weight of the HBP pulling down on top-supported leadscrews so that they're always in tension and naturally pulled straight, instead of relying on the intrinsic straightness of a leadscrew that would be able to support the HBP in compression while being thick enough to not buckle. In fact, I wonder if an imperceptible amount of buckling due to the weight of the HBP (even with 16mm diameter screws) was part of the problem.

That these are also direct drive was an additional simplification so that I could rest easy being sure not to introduce additional error with unnecessary belts and pulleys. I feel they were well worth the money, as no additional parts were needed. The motors are mounted upside down to the frame with printed polycarbonate brackets, the nut is screwed to the HBP, and that's that.

Aligning four leadscrews and four linear shafts is tricky and important, but by no means a show stopper. What I wound up with is exactly the no-compromise system I was hoping for.

Considering the other person on the German forum was getting banding, I'm not surprised that the error was .035mm. Knowing what I know now, I would expect .035mm to kill the quality. But to be sure it was surprising to discover that the Z-axis has to be so accurate. With this new powered leadscrew arrangement I'm down to +/-.003 mm positioning accuracy. As for how the other person's banding was fixed, what a mystery! Maybe the leadscrews were inadvertently straightened in the process of working on them? Or maybe they were clocked so they're exactly out of phase right now? Do they get good quality on all parts of the HBP or just in the center? I never tried a vase-mode print when the problem was bad; that's also odd.

For completeness, here again are before and after photos from using the python gcode fixer (https://github.com/jhaupt/ZBandingFixer), before the mechanical fix:

Pre-mechanical fix, without python/gcode correction:


Pre-mechanical fix, with python/gcode correction:


Edited 4 time(s). Last edit at 12/30/2017 10:04AM by justine.haupt.
Re: Correcting horizontal banding in gcode with python
December 30, 2017 10:33AM
Thinking out-loud, assuming that lead screws were attached on one side, if original lead screws caused lateral movement than wouldn't issue be with Z linear guides that failed to keep the bed steady.
Re: Correcting horizontal banding in gcode with python
December 30, 2017 12:53PM
Hi newbob,

No. The problem described above was never about Z-wobble. I think the initial post wasn't clear enough in this regard, so sorry for that.

The banding was from layers expanding and contracting in a periodic way from the Z axis making movements less than and more than the layer height. It's an issue of compression of the filament as it's extruded onto the previous layer, and the distance of that layer from the nozzle being critical. It turns out that if that distance isn't repeatable on the order of microns (at least 10 I'd say), this happens.

That isn't to say that the issue isn't confused for other people because non-straight leadscrews are making the bed wobble in addition to positioning-error related banding, but it's possible to have one and not the other. Also, the dynamics for a leadscrew's positioning accuracy being reduced by lack of straightness are more complicated to be sure. I'm not sure I understand it, except that it's a real and measurable effect that went away once I had truly straight leadscrews.

Edited 2 time(s). Last edit at 12/30/2017 12:55PM by justine.haupt.
Re: Correcting horizontal banding in gcode with python
December 30, 2017 03:53PM
Thank you for making it clear for me, I should have read your post more carefully. There's one other situation I can think of that could cause this: in four screw arrangement, periodically, one screw could take over from the other (due to backlash between nut and screw bed would not lock out) making vertical movement uneven.
Re: Correcting horizontal banding in gcode with python
December 31, 2017 04:16PM
Quote
newbob
There's one other situation I can think of that could cause this: in four screw arrangement, periodically, one screw could take over from the other (due to backlash between nut and screw bed would not lock out) making vertical movement uneven.

You know, in practice I don't see that happening. All four screws are always moving in unison, and with precise leadscrews with the nuts all at the same starting height, it's all always moving together and positively loaded. Partly this is because the bed isn't perfectly rigid. The frame of my bed is made from 30x60 aluminum extrusions and bolted with custom/machined corner brackets, and from there the hot plate itself is supported on a 3-ball kinematic support. It's as strong and rigid as it would ever need to be, and yet there's enough elasticity that I'd have to lift one corner a couple millimeters or so before unloading the nuts on the adjacent two corners. That elasticity wasn't designed into it intentionally. It's just that it would take excessive material, or an exotic material, to make it rigid enough that loading/unloading nuts (at the scale of individual step movements?) would ever be a problem.
Re: Correcting horizontal banding in gcode with python
December 31, 2017 06:32PM
Why 4 screws and 4 guide rails?

2 rails should provide the necessary lateral and rotational constraint.

3 screws provides inherently stable vertical position. Using 4 screws seems to be asking for the whole assembly to wobble vertically as it moves up/down.


Son of MegaMax 3D printer: [www.instructables.com]
Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]
Re: Correcting horizontal banding in gcode with python
January 02, 2018 11:25AM
Hi the_digital_dentist,

-Why 4 screws and not 3:

In part, a messy design heritage. I knew I'd need at least 2 screws, and I couldn't find closed-loop GT2 belts big enough to get around three at a time. Three was also geometrically awkward for my frame. Understand that the machine's footprint on the floor is 1m x 1m. I settled on four screws driven by two motors, and after parts were machined that evolved into four direct-drive screws even though it no longer needed to be 2 pairs for symmetry and parts count reasons.

But that said, when I build the next one it will still use 4 screws. Here's why: While the idea of defining the motion of a plane with four constraints instead of three is philosophically grating to the mechanically minded, in reality my 72cm aluminum square bed is not rigid enough for conceivable problems from the over-constraint to play out. In fact, a couple millimeters of flexibility from end to end is enough to warrant, I feel, supporting each corner on its own. By the "always three points to define a plane" dogma, a stool should have 3 legs, but we know there are good reasons for more. Similarly, I'm confident that my four-screw bed is more stable and precise than a 3-screw version of the same bed would be. It may not be textbook-neat, but it is better. Moreover, the build surface itself is constrained with three points (and kinematically) to the part of the bed that attaches to the screws.

Also, in case it was muddled in the quagmire of the above posts, the original banding problem was completely solved, and what I have now is a very happy 4-screw bed.

-Why 2 rails instead of 4:

There's a similarly messy design heritage here, but yeah, I agree. I may go to two rails on the next build.

~Justine

Edited 4 time(s). Last edit at 01/02/2018 05:26PM by justine.haupt.
Re: Correcting horizontal banding in gcode with python
January 03, 2018 11:18AM
Quote
the_digital_dentist
2 rails should provide the necessary lateral and rotational constraint.

I agree, but to hold it levelled horizontally you also need for each a pair of bearings with an appropriate distance in between.

Quote
justine.haupt
I'm confident that my four-screw bed is more stable and precise than a 3-screw version of the same bed would be.

Considering how large your HBP is, besides not absolutely rigid, it is best to have 4 screws. This way you also don't need long bearings.

In the German forum now I found 4 other persons which had exactly the same issue.
Two of them could solve the problem by leveling the bed frame horizontally.
The third one had wobbling coupling and the stepper motors were specially mounted loose.
The fourth one probably had not leveled the HBP carefully. Furthermore he eventually removed the bearings at the end of the lead screws.
It seems that there are several things itself or in combination which causes the problem.
- Unlevelled HBP
- Bowed lead screws
- Uncentered lead screws
- Inclined lead screws
I can imagine the more lead screws you have the more problems can arise.

Quote
justine.haupt
Aligning four leadscrews and four linear shafts is tricky and important, but by no means a show stopper.

Are you quite sure that you first had all aligned with equal care as now incl. levelling of HBP?
I am sure you didn't use bearings on top for the lead screws.

A few days ago I made a surprising experience after I reassembled one of my two lead screws.
While driving the x-unit to top the linear z-rods were wobbling really frightening. Even the z-motors were wobbling as they are only mounted by 2 screws on printed base parts.
Down again I measured the distance to the bed. From right to left there was a difference of almost 1mm.
After I levelled the x-unit there was absolutely no wobbling and the lead screw run exactly as never before smiling smiley
I uploaded a video of it: [www.youtube.com]

Quote
justine.haupt
In fact, I wonder if an imperceptible amount of buckling due to the weight of the HBP (even with 16mm diameter screws) was part of the problem.

I simulated a static stress test (FEM).
For that I took a smooth rod 900mm long, diameter 13.0mm (ca. core M16) axial loaded with 30N.
To make sure the rod bow in one direction I bowed it 2 mm in middle like a bow.
The result is 0.039 radial offset and -0.0014mm axial offset on top.
Even if I am not quite sure the simulation is correct, I think there should have been no problem with your 16mm rods.

Your printer is amazing!
I have never seen such a solid printer than yours! This is a real professionally build machine, and it is so big that it possibly could print my big wing in 2 parts instead in 40 parts smiling smiley
[www.youtube.com]

Michael


Konstruktionen: [www.thingiverse.com]
Videos: [www.youtube.com]
Mein Club: [hackerspace-ffm.de]
Drucker: Wersybot - seit 2012 smiling smiley
Re: Correcting horizontal banding in gcode with python
January 03, 2018 01:34PM
It seems to me that if the bed support structure is unstable on 4 screws, even if (or especially if?) it can flex (a second form of instability), then the bed that sits on those 4 screws is equally unstable, 3 leveling screws or not. But if it works, it works.


Son of MegaMax 3D printer: [www.instructables.com]
Ultra MegaMax Dominator 3D printer: [drmrehorst.blogspot.com]
Re: Correcting horizontal banding in gcode with python
January 04, 2018 03:24AM
Quote
the_digital_dentist
It seems to me that if the bed support structure is unstable on 4 screws, even if (or especially if?) it can flex (a second form of instability), then the bed that sits on those 4 screws is equally unstable, 3 leveling screws or not. But if it works, it works.

It works because it must work.
If all 4 screws move the frame with same lift, the frame can't flex horizontally, no matter how unstable it is.


Konstruktionen: [www.thingiverse.com]
Videos: [www.youtube.com]
Mein Club: [hackerspace-ffm.de]
Drucker: Wersybot - seit 2012 smiling smiley
Re: Correcting horizontal banding in gcode with python
January 08, 2018 02:07PM
Thanks for the comments wersy,

Quote
wersy
Are you quite sure that you first had all aligned with equal care as now incl. levelling of HBP?
I am sure you didn't use bearings on top for the lead screws.

Yes, and yes, the tops of the screws were free. But those screws were visibly bent on arrival from PBC Linear. It was always a matter of trying to fix something that wasn't great to begin with.

Thanks for the FEA, it confirms intuition.

From your wobbly experience, it seems like your two screws were out of sync to begin with, caused binding and wobbling, lost some steps, and hence the 1mm difference. Do you think that's what happened?

Quote
wersy
I have never seen such a solid printer than yours! This is a real professionally build machine, and it is so big that it possibly could print my big wing in 2 parts instead in 40 parts smiling smiley
[www.youtube.com]

Wow look at that! Very cool!

I'm not sure if the compliment was directed at me (if so, thank you), but it's not completely finished yet. I'm down to finishing touches like printing gap seals for the doors, the control panel, and installing a touchscreen. When all that's done I'll put up a video.

Edited 1 time(s). Last edit at 01/08/2018 02:09PM by justine.haupt.
Sorry, only registered users may post in this forum.

Click here to login