Left / Right Bed Leveling

[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.

[edward]

Ok sorry. I didn't mean to sidetrack the topic. I made my comment based on what I interpreted 626's comment to mean "I looked through the file." I guess we all have tools that work for us.

Yes, I'm on Marlin. When I referenced Repetier, I was recalling 0.83; it *was* in that version.. I've never more than quickly looked at some specific segments of the 0.90 development branch. Maybe it's been moved to EEPROM, in which case this whole business would be easier because you wouldn't have to recompile and reflash after each change.

Maybe later tonight I'll be able to study the new Repetier branch. Until then, if someone wants to look, I'd start by understanding the function that contains the primary location for use of the tower positions in the calculateDelta() or that similarly named.

[edward]

I've now spent a few minutes looking into the 0.90 development code, specifcally in motion.cpp, focusing on the transformCartesianStepsToDeltaSteps() routine.

It seems that Roland did indeed eliminate the preprocessor defines for the tower positions, instead assuming that they are always separated by 120 degrees and performing all of the necessary trigonometric calculations with only the sine and cosine of 60 degrees, as can be done.

So, for those on the newest Repetier, this is going to be a bit more difficult; however, given the amount of "stuff" that has been moved into the EEPROM for this release, I think that it would be great it these six parameters could be put in there, too (there's plenty of space - I think 1k). Instead of starting the work on it now, I will email him to begin a discussion. He has seemed to be quite open to changes and improvements in the past, so I'm sure that this is something we can work out. Since I'm not intending to change away from Marlin, I'll need some testers if and/or once some code changes begin.

It might actually be a feature that could set Repetier apart from Marlin in a significant manner, IMO.

[inventabuild]

Edward,

Unfortunately this did not work for me. I went through the process of stepping through different SIN and COS values in the DELTA_TOWER_STEPS equations, but nothing had an effect on the thin spots on the left and right side of my print. Maybe I'm doing something wrong?

I have the DELTA_TOWER code in Repetier Version 0.90C and I substituted decimal equivalents for the SIN and COS values in the equations shown below as I was incrementing by +/-0.1 degrees up to +/- 1 degree:

and the DELTA_TOWER values appear to be used in motion.cpp:

Please let me know if you have any suggestions. Thanks.

Mitch

[tearabite]

I am having a similar issue. The positive directions for both X and for Y are too close to the bed, but the negative directions are just fine. I tried the solution that edward posted regarding moving the three towers without success. If anyone has insight into this problem, I will gladly print you a pony and ship it to you when my printer works.

[edward]

Please let me know if you have any suggestions. Thanks. Mitch

I'll spend some more time looking at your case probably tomorrow, more specifically the Repetier code. But to be sure, you were re-calibrating the end-stops with each adjustment of the tower positions, right? Along with that, possibly adjusting the DELTA_RADIUS as needed? Every parameter adjustment requires a full re-calibration from the beginning to ensure the full effect of the adjustment.

I had a sneaking feeling that this would turn out to be a "works for me" situation

Edit: Also, be careful with your version numbers. Your mention of 0.90C is likely the version of your Repetier Host (on your PC). You are most likely using v0.83 of Repetier-Firmware on your RAMBo or whatever.

[edward]

It seems that the v0.83 Repetier-Firmware code should apply the tower position changes just fine.

I'm not really sure of what else to say without knowing the answers to the couple of questions in my previous post: were you re-calibrating the end-stops after each parameter adjustment?

Also, can you post exactly the modified #define statements that you used (at least one for example)?

[626Pilot]

I had a sneaking feeling that this would turn out to be a "works for me" situation

For anyone who was following this thread - it's not just Edward this works for! I fixed my printer by rotating the Y tower one degree CCW. I think this is the solution I've been looking for for months.

Edit: I'm trying to get this implemented on Repetier, but the newest version has been changed so that there's an assumption that the towers are all 60 degrees apart. I've filed an issue. If you're using Repetier and your printer acts weird near the edge of the build platform, that would be the place to chime in.