Left / Right Bed Leveling

[inventabuild]

I printed the Rostock Onyx Bed leveling Aid (http://www.thingiverse.com/thing:50505):

The left (west) and right (east) sides printed thinner than the north and south of the print which is why it broke in those two places when I pulled it off the print bed.

I already fine tuned the height of the towers and the delta radius, so how do I adjust my RMAX so it will print thicker on the left and right side of the bed?

[DavidF]

Im a newbe so take this with a grain of salt... try rotating the glass, I cant think of any way to get much better other then this....

[inventabuild]

Thanks for the suggestion. Unfortunately the problem persists. Still hoping there is some code or other adjustment that compensates for thinner layers on the left (west) and right (east) of the print vs thicker layers on north and south of the print.

[Nylocke]

It seems to be either a firmware interpretation error ( firmware thinks its flat when it isn't) or possibly hardware issues, check to make sure all the belts aren't loose would be my suggestion, also make sure all of the towers are equally tall, etc.....

[inventabuild]

Thanks for the suggestions. The towers are all the same height and dead on perpendicular to the glass build plate. Belts are all sufficiently tight. Hoping there is a firmware adjustment I can do to fix this.

[MDMD]

I get similar results when printing the onyx calibration circles. I will be following this thread closely. Be sure to update it if you find a solution.

My printer is amazing as long as I say withing the inner half of the platform. I want to do some big prints so I'm anxious to find the solution.

[626Pilot]

If the Z tower is north, Y is southwest, and X is southeast, try adjusting the endstop screws to make the X and Y towers "shorter." (In other words, unscrew the screws just a tiny amount.) However, this will cause some lift in the center, particularly between those towers. It's a tradeoff.

What are you using to hold down the glass plate? If you're using binder clips, you might want to think about printing some plastic clips instead.

[lordbinky]

When I print the leveling aid, this happens because I have one pair of arms on the same tower that were slightly longer than the other two. It keeps me from getting very fine printer_radius calibration too.


Nevermind this, it was a single tower that figured out how to lean on it's own
(along the same lines as what 626pilot suggested)
*CRAZY GUESS BASED OFF OF FUZZY MEMORY INCOMING*
If I remember right (and I likely don't right now) based off my last time I played with the bed leveling print, raising the X and Y screw and lowering the Z screw and adjusting your print height in software/firmware to keep from crashing the bed, will eventually get you to a point that the those low spots will move to be across from the Z tower. At which point you'd come to the same conclusion as me that a pair of your arms are slightly larger than the other two. So you could take a shortcut and just measure those arms to verify that logic, and if it's true, than my thinking was somewhat based in reality and you may have the cause of the issue identified (maybe).

[inventabuild]

Doesn't matter how many adjustments I make to the towers x, y and / or z I end up with some spots flatter than others. Started feeling like a dog chasing its tail and decided I'm good enough to lay down the first layer and will really be looking forward to genebs et al auto level. Sounds like it will be better than Johann's due to the additional delta radius functionality.

[mhigginsmoy]

Hey! I finally found someone with the same issue as me! Any news on the final solution?
I'm new to printers, yet somehow I got thrust into a delta.
[img]https://farm6.staticflickr.com/5522/9890802345_332a7f84c8_b.jpg[/img]
IMG_5933 by Miguel Higgins/Moy, on Flickr

[626Pilot]

This is one of those problems that's best solved by automated bed leveling (using a Z-probe.) There are some other threads about this. The idea is that the effector has a probe on it that can be deployed and measure the height of the bed at many points in order to build up a map of what its surface is actually like. Tiny variations in arm length, small errors in the way the top and bottom plates (that the towers pass through) are cut, the propensity of the towers to "walk" when the T-slot nuts are tightened down, different quantity of soapy water used to help lay down different strips of Kapton tape, etc. will make it impossible to get the Rostock aligned "perfectly." It can be taken fairly close to perfect, but there's no way to factor out those problems without a Z-probe.

[mhigginsmoy]

Thanks a ton for the suggestion. I definitely want to try and do the Z-probe. Mind if you point me to the posts? I'm fairly new to the forums, still haven't found my way around yet. How would I implement the Z-probe into Repetier-Host, or into the Rostock's firmware?

[Eaglezsoar]

Thanks a ton for the suggestion. I definitely want to try and do the Z-probe. Mind if you point me to the posts? I'm fairly new to the forums, still haven't found my way around yet. How would I implement the Z-probe into Repetier-Host, or into the Rostock's firmware?

I believe that the Z probe and autoleveling is still in the experimental stage at this time and is not quite ready for installation on everyone's machine but the good news is that it is getting closer everyday for a release where everyone can use it.

[mhigginsmoy]

So what would you suggest as an alternative fix for this problem then?

[cope413]

Haven't tried it yet, but I will be checking it out soon...

http://www.matterhackers.com/news/autom ... tercontrol

[mhigginsmoy]

Let me know how it goes! Right now, I'm just looking for something, perhaps in the firmware that can solve this problem for me. Just some magic setting would be nice...

[edward]

@inventabuild: Based on your first-post photo, and your description, you probably will best solve this by manually iterating through the process of moving the firmware positions of your X and Y towers around the center point of the machine (that is, based on your print results it appears they aren't exactly 120 degrees apart as the firmware expects). You must have patience, because this is a very manual and lengthy process.

Warning: Textbook to follow

I just-last-night fixed this type of issue on my machine using the described process, as a Z-probe wasn't helping. It (z-probe) is not the cure-all it is claimed to be. Certain methods (I think the current development branch of Repetier - 0.90alpha - and at least one other still-in-development Marlin branch) being worked on will perform an automated 4-point calibration and determine your printer radius which should be enough for most. Another z-probe implementation (Johann's Marlin deltabot branch) assumes you have a good calibration and then probes many points of the build surface, correcting for any flatness errors that it measures throughout the print; it doesn't adjust the DELTA_RADIUS. *Neither* method will help if your tower positions are incorrect in the firmware.

"What the hell is he talking about?," you say? It's hidden in Repetier firmware (not in Configuration.h but in Reptier.h) so most MAX owners won't have seen it, but it's plainly obvious in the Marlin Configuration.h. All three towers are #defined similar to this (this is the X-tower):

Code: Select all

#SIN_60 (actual decimal value for sin(60deg) here)
#COS_60 (you get the point)
#DELTA_TOWER1_X -SIN_60*DELTA_RADIUS
#DELTA_TOWER1_Y -COS_60*DELTA_RADIUS

...and so on for all three towers. These TOWER_{1,2,3}_{X,Y} values are precomputed before compilation of the firmware to save time when performing the Delta conversion later, as that calculation involves a lot of squares and square-roots and is very taxing on the CPU (this is why some of us are looking forward to 32-bit ARM based controllers for Deltas, allowing much faster computation of the Delta positions with higher resolution == smoother motions; it really is amazing so much is squeezed out of these 8-bit micros...).

So you can see that it is possible to "move" the towers. On my machine I had measured and verified distances so many times that I thought that there was no way my towers weren't all 120 degrees apart. But, after getting a perfect 4-point calibration, I had good height opposite the Z-tower, a bit high opposite the X-tower, and that same amount low opposite the Y-tower. From what I've learned elsewhere on the Delta-related interwebz, this meant that my Z-tower needed to move CCW (along the radius toward the low spot).

INTERMISSION....

Ok. I started small and changed the Z-tower position (in Marlin it's DELTA_TOWER3_{X,Y}) by 0.2 degrees CCW. They then looked something like this (the sin/cos values aren't correct for 0.2 degrees, just an example):

Code: Select all

#define DELTA_TOWER3_X -0.00750484533293*DELTA_RADIUS // back middle tower
#define DELTA_TOWER3_Y 0.999971838252*DELTA_RADIUS

instead of this:

Code: Select all

#define DELTA_TOWER3_X 0 // back middle tower
#define DELTA_TOWER3_Y DELTA_RADIUS

What do you know!? After re-adjusting the end-stops, the point opposite the Z-tower stayed mostly the same, the high point opposite X came down some and the point opposite Y came up an equal amount. You can think of the effects like this: by moving the location of the Z-tower closer to the low point, when the processor needs to compute the Z carriage position, given that the arm length hasn't changed, it will need to be higher up the tower in order to reach the same Cartesian Z-height. The opposite logic works for the high point on the other side.

I then increased the CCW shift until after several iterations I settled on 0.43 degrees CCW, where the two points were now consistent with the 4-point calibration. Unfortunately now the point opposite the Z-tower was low, so what now?

I needed to move the Z-tower in a radial direction away from the center. Radial movement most directly influences the point opposite the tower. If it's low, the tower needs to increase its radial distance. If it's high, decrease.

A few more calibration iterations and I've settled on this for my Z-tower position, and things are, dare I say, PERFECT!

Code: Select all

#define DELTA_TOWER3_X -0.00750484533293*(DELTA_RADIUS+0.15) // back middle tower (0.43 deg CCW)
#define DELTA_TOWER3_Y 0.999971838252*(DELTA_RADIUS+0.15)

I have small imperfections in the flat movement, but this is something that I'm quite sure the Marlin version of auto-leveling will solve. I always use a 0.1 mm feeler gauge for calibration, and now I can move to anywhere at Z0.1 and get contact with the gauge. Some spots are a bit more pressure, some less. But really damn good. I still haven't completely reconciled this with regards to the actual physical dimensions of my machine, that is to say I'm not quite sure yet if the firmware now matches the machine, because my physical measurements (with very large dial calipers) don't necessarily agree.

Note: This tower position is unique to my machine. DO NOT blindly copy it into your source files.

Most of my understanding of this process came from this thread, specifically the linked post: http://forums.reprap.org/read.php?178,2 ... msg-238009 (well, the post specific link doesn't seem to work; it's about half way down the thread by the user 'hercek') The 'edwardh' user in that thread is me. I'm currently trying to get the hercek's offline calibration code running out of curiosity. I guess I want to know if the math will confirm my tower positions, and because I like using computer tools to solve my problems (if only there was a DE solver for women...).

Back to inventabuild's photo
Based on what I see, you probably could try to "move" your X and Y towers in equal angular distances toward the low spots. That is, in the orientation of your photo, tower X should move CW and tower Y should move CCW. I would guess less than half of a degree each. Since your problem spots aren't directly across from a tower I would try this first, incrementally. Start with 0.1 degrees each and see what happens. This is why I use feeler gauges, because I can keep referencing the same point and by finding the correct gauge, determine the exact effect of the parameter change.

This method is probably also not a cure-all, because, well, it's just not easy (intuitive might be better). Only at the beginning of last week I was ready to throw my printer off the roof, or shoot it, burn it, or other horrible things. Then yesterday (Sunday) I had some kind of epiphany regarding the Delta configuration, where these adjustments just made sense. Trust me, a Z-probe won't magically fix things if your geometry is bad. I tried that and proved myself wrong. I don't necessarily recommend that everyone just start moving their firmware tower positions, but if you really feel that *everything* else is in check, you might give it a try. I mean EVERYTHING. Check that your arm pairs are truly parallel. Ensure that the towers are perpendicular. Be very particular when calibrating the end stops and adjusting the DELTA_RADIUS, etc., etc., etc.

It's also quite likely that if you attempt this it will make things worse because, again, the delta configuration is not as intuitive as a Cartesian machine. If it were, I suppose we wouldn't be having this discussion.

Because this issue was so similar to what I experienced, I wanted to vocalize that there are more methods for "tuning" these machines beyond the end stops and the DELTA_RADIUS.

Lastly, I'm traveling through late Thursday night (10/3), so my responses might be somewhat slow. That's why I elaborated quite a bit, hoping to be clear enough as to not require too many immediate follow-up posts. Ask away, though. I'll do my best to answer

Edit: Fixed some tupos.

[626Pilot]

Brilliance

Excellent. This is exactly the kind of information we need. I have noticed that my towers are not precisely the same distance from one another, even though they're snugged up to both plates as tight as physically possible. I have a working depth probe prototype mounted up but I'm running into the same issue as Gene, where it lifts on one half and dips on the other.

[626Pilot]

By the way, I didn't find DELTA_TOWER anywhere in the source except in Eeprom.cpp/.h. Is this Marlin you were talking about?

[inventabuild]

By the way, I didn't find DELTA_TOWER anywhere in the source except in Eeprom.cpp/.h. Is this Marlin you were talking about?

He's talking about the Repetier tab in the firmware:

[inventabuild]

@inventabuild: Based on your first-post photo, and your description, you probably will best solve this by manually iterating through the process of moving the firmware positions of your X and Y towers around the center point of the machine (that is, based on your print results it appears they aren't exactly 120 degrees apart as the firmware expects). You must have patience, because this is a very manual and lengthy process.

(rest of quote truncated for brevity)

Edward,

This is great stuff. I look forward to playing around with it to see if I can improve my prints.

Mitch

[edward]

We will all be awaiting your results

Also, sorry about the bad quoting of the Repetier firmware. I probably could have just as easily looked it up, but I only had a copy of my Marlin firmware source on my laptop and for no excuse I was going from memory.

Take it slow and document each change and the accompanied results. You'll quickly start to realize what each change affects, and what
changes need to be made to correct your tower placement, if necessary.

By the way, I didn't find DELTA_TOWER anywhere in the source except in Eeprom.cpp/.h. Is this Marlin you were talking about?

As an aside, grab a copy of the_silver_surfer for super-fast and inclusive text searches (*nix only, I think): https://github.com/ggreer/the_silver_searcher You can so easily search for terms within the files of a project directory it makes troubleshooting/modification/general inquiries soooo easy if you know a "keyword." In this case: '$ag "DELTA_" ./' would have returned every instance, with line number, of the search term "DELTA_." Since I didn't provide good directions, you could have nailed down the location in seconds

[626Pilot]

As an aside, grab a copy of the_silver_surfer for super-fast and inclusive text searches (*nix only, I think):

It isn't there.

Code: Select all

~/sketchbook/Repetier-Firmware> grep -r DELTA_TOWER1 *
api-doc/html/_reptier_8h_source.html:<a name="l00953"></a>00953 <span class="preprocessor">#define DELTA_TOWER1_X_STEPS -SIN_60*DELTA_RADIUS_STEPS</span>
api-doc/html/_reptier_8h_source.html:<a name="l00954"></a>00954 <span class="preprocessor"></span><span class="preprocessor">#define DELTA_TOWER1_Y_STEPS -COS_60*DELTA_RADIUS_STEPS</span>

This is the development branch, pulled a few nights ago. If you're on 0.80 then maybe those variables have been renamed in 0.90.

[dsnettleton]

I use sublime text as my dev environment (both for work and for hobbies), and its search functions are great. It can find everything in a project or specified directories, use regex, etc. The demo version is unlimited and fully featured though, if I remember correctly, a little naggy.

[Eaglezsoar]

I use notepad++ and like it a lot.
Seems to work well for searching.