Unsolved Mystery. Weird Z0 behavior around build perimeter.

Having a problem? Post it here and someone will be along shortly to help
User avatar
bvandiepenbos
Printmaster!
Posts: 927
Joined: Thu Apr 05, 2012 11:25 pm
Location: Goshen, IN
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bvandiepenbos » Mon Apr 28, 2014 9:03 pm

626Pilot wrote:
bvandiepenbos wrote:I think you are on the right track, however do you think the Arduio can handle even more calculations in the firmware? it is already pushed to it's limits.

It has some wiggle room, but not a huge amount. It might be possible. Personally, I think Arduino is outdated and will soon run out of momentum. Teensy 3.0 boards are over $5 cheaper, run at 72MHz, have 256K flash and 64K RAM, and can produce hardware PWM on 9 pins - and they can be programmed in the Arduino IDE. Raspberry Pis are better still, for not much more money ($30-35), can run Linux and X-windows, but only have two channels of hardware PWM output. For immediate porting, the Teensy is better. For expanded capability in the future, the Pi is better, but as it can only generate two channels of PWM a slightly more complicated external board is needed. (They all need external support, at least for the Pololu stepper drivers.)


I have a Smoothie board to try out, and if all goes well likely will be using it in all my builds. Do you think it is a good option for now and the future? sounds like you know a bit about boards, I do not want to start down a path that may be quickly outdated.
~*Brian V.

RostockMAX v2 (Stock)
MAX METAL "ShortyMAX"
MAX METAL Rostock MAX Printer Frame
NEMESIS Air Delta v1 & v2 -Aluminum delta printers
Rostock MAX "KITT" - Tri-Force Frame
GRABER i3 "Slim"

User avatar
bvandiepenbos
Printmaster!
Posts: 927
Joined: Thu Apr 05, 2012 11:25 pm
Location: Goshen, IN
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bvandiepenbos » Mon Apr 28, 2014 9:16 pm

Woolf wrote:Brian, can you post your Marlin Firmware? I will test it on my Max.


attached is the Marlin fw I use on my older MAX.
Attachments
RAMBO_LCD.zip
marlin fw for Rostock MAX
(159.34 KiB) Downloaded 33 times
~*Brian V.

RostockMAX v2 (Stock)
MAX METAL "ShortyMAX"
MAX METAL Rostock MAX Printer Frame
NEMESIS Air Delta v1 & v2 -Aluminum delta printers
Rostock MAX "KITT" - Tri-Force Frame
GRABER i3 "Slim"

snoman002
Prints-a-lot
Posts: 30
Joined: Thu May 01, 2014 11:19 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by snoman002 » Fri May 02, 2014 8:42 pm

Been lurking for a while now, but this discussion peaked my interest.

For boards, don't forget the beaglebone black, $45 1GHz and 8 pwm outputs iirc.

As for the z height, is it not possibly a geometry problem? When the print head is right close to a tower the print head height is essentially only determined by the height of that towers arm only, however when the head is at its furthest extent but between towers the height is determined by two towers and its just a triangle. If those two towers are too close the head will be low, to far and the head will be high. Essentially though the radius of the upper pivots (don't know the terminology) could be too small, or too large. Considering this is very difficult to measure accurately, and the fact between the tower position, cheapskate position and pivot position all adding errors, this could contribute to making the upper pivot radius to small, or too large, by a fair amount (hundredths maybe).

It seems to me that any error in the pivot radius would also result in errors in the X and Y direction too. Making a small cube in the center of the build platform and measuring its size error, and then a large rectangle stretching out into the problem zones and measuring its error in length, then comparing might give an indication. I'm sure a more elaborate calibration shape could be dreamed up as well.

User avatar
lordbinky
Printmaster!
Posts: 754
Joined: Sat May 18, 2013 3:53 am
Location: Tri Cities Washington

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by lordbinky » Tue May 06, 2014 1:03 pm

I posted in another place, but I'll post here too. I upgraded to a smoothieboard and 0.9° steppers, I'll report my results either this weekend or on the 18th. My work has had my weekends tied up quite well ( viewtopic.php?p=38452#p38452 ) Initial tests before I was interupted by a necessary screw-in thermistor upgrade in the middle of getting my (0,0,0) centered between towers were quite promising. I aspire to try using magnetic arms again with two sets, one roughly standard length and another set 50% longer. I want to test the odd perimeter variance against arm length. Until I am convinced otherwise, I believe there is an correlation in this. By default, my center point after standard calibration leaves one tower (off the top of my head) ~5mm further out than the other two towers. It seems reasonable to me that the slight deviation there could be the build error that is the source of geometry issues which causes the odd Z0 behavior at the perimeter. Such minor differences in builds could be the reason why some people are seeing this behavior and some are not.

Polygonhell
ULTIMATE 3D JEDDI
Posts: 2430
Joined: Mon Mar 26, 2012 1:44 pm
Location: Redmond WA

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Polygonhell » Tue May 06, 2014 4:59 pm

snoman002 wrote:
As for the z height, is it not possibly a geometry problem?



It is likely a geometry issue, though it could be an issue with Repetier's handling of the delta coordinates. While the diagram on the previous page is "accurate", in detailing the increase in Z error over the print surface you need to look at the legend in the diagram to appreciate the size of the error.

The largest Z error a perfectly built printer with correct delta calculation can have at any point it can reach on the build plate is 1/2 of 1 step. This is trivially true since you could always move all 3 axis up or down steps to reduce a larger error.

Even with the original 8x uStepping drivers that's a maximum error of 0.01 mm (the endstops aren't that accurate).

The multi mm errors people are seeing has to either be an issue with repetier firmware (which is possible, I haven't looked at the math that closely) or it's a combination of mechanical issues resulting in a larger than expected error.

User avatar
Generic Default
Printmaster!
Posts: 558
Joined: Mon Jun 03, 2013 6:56 pm
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Generic Default » Tue May 06, 2014 10:11 pm

Hey I just found this thread and realized that I might have the same problem too! I've had magnetic arms with extra long brass tubes since December 2013. My machine isn't showing quite what you guys are having problems with here, but there are similar things going on with mine. I don't have any precise measuring tools yet, but I can accurately eyeball nozzle height to within ~0.02mm.

Here are a few things that may be affecting your machine;

-Your arms aren't perfectly rigid. The minute weight of the arms combined with the effector plate/hotend might be bending your arms when they're far away from the tower. Horizontal arms will bend more. A solution is to get more rigid arms, such as thick metal tubes like mine.

-Any backlash on your joints will cause slip stick, which is more noticeable when the arms are horizontal.

-Thermal expansion can significantly increase the length of your arms. I noticed this when I was trying to grind my brass rods to within 0.05mm lengthwise. Any thermal energy will warp/distort your arms by a measurable amount.


I mostly have to deal with my platform rotating and causing uneven levelling between my dual hotends. I'll be getting some very precise CNC machines in the next week or so, so I will be able to quantify measurements (and make precise parts) once I have them.


Also, someone brought up the idea of hiring a robot expert to fix this for us. I don't think there are very many delta printer specialists in the world, and we are probably on our own here. Delta 3d printers have only been around since early 2012, and our combined R&D on these machines over the last year has really put us in our own category.
Check out the Tri hotend!

snoman002
Prints-a-lot
Posts: 30
Joined: Thu May 01, 2014 11:19 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by snoman002 » Tue May 06, 2014 10:28 pm

Polygonhell wrote:
snoman002 wrote:
As for the z height, is it not possibly a geometry problem?



It is likely a geometry issue, though it could be an issue with Repetier's handling of the delta coordinates. While the diagram on the previous page is "accurate", in detailing the increase in Z error over the print surface you need to look at the legend in the diagram to appreciate the size of the error.

The largest Z error a perfectly built printer with correct delta calculation can have at any point it can reach on the build plate is 1/2 of 1 step. This is trivially true since you could always move all 3 axis up or down steps to reduce a larger error.

Even with the original 8x uStepping drivers that's a maximum error of 0.01 mm (the endstops aren't that accurate).

The multi mm errors people are seeing has to either be an issue with repetier firmware (which is possible, I haven't looked at the math that closely) or it's a combination of mechanical issues resulting in a larger than expected error.


I did see the previously posted file describing error, and did notice the legend. But understand that's a mathematical representation of possible error on a context-less machine. I think it serves to highlight the weak errors of a delta printer and nothing more, not a measure of error for a Rostock.

I was just trying to highlight that a some simple errors in the construction or build tolerances can cause significant errors, and as the previous document goes to show, the perimeter between the towers is the weakest area and is where problems crop up.

Has anybody measured the distance between towers very accurately, both top and bottom. A slight tilt in could cause many issues. Nothing against seemecnc, but laser cut MDF isn't the most accurate material.


As for the software, its 'simple' geometry, I would be really surprised if the software want not complex enough to manage positioning the head. Heck, its a 'simple' parallel robot with one section being linear effectors and not the effector arms most delta robots use. And its certainly not as complex as a Stewart platform, inverse kinematics are a bugger (I barely understood the IDEA of the math, let alone the math itself). As for only a few engineers around, well delta robots have been around for quite a while, just not in this realm.

User avatar
lordbinky
Printmaster!
Posts: 754
Joined: Sat May 18, 2013 3:53 am
Location: Tri Cities Washington

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by lordbinky » Thu May 08, 2014 1:10 pm

snoman002 wrote:Nothing against seemecnc, but laser cut MDF isn't the most accurate material.


At least for me and my experience at work, if the price to precision ratio of our machines is any indication, what we are getting and achieving (especially with such construction materials) is mind-boggling. I can't congratulate the guys at SeeMeCNC enough for putting together such a machine at this price point. I laugh when I talk to my co-worker about what I can do to improve the machine and see the tool costs for the necessary precision to make improvements.

As for the math, I haven't looked into the arduino limitations as well as others *cough* polygonhell *cough*, but I believe to circumvent those limitations would require a significant amount of work and put us back to less flexible and unfriendly techniques (such as using tables, which may not be viable based on the the current chipset), which would all get thrown back out the window with better processessors the controller boards are moving toward. It's hard to find the motivation (or motivate someone else) for such a task with a short lifespan.

Hans_G
Noob
Posts: 2
Joined: Wed Apr 23, 2014 5:54 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Hans_G » Thu May 08, 2014 1:58 pm

first post to this forum, hi everyone.

i got a v2 up and running about 2 weeks ago and noticed my printer has this problem too. I moved the printer around a few times and had to re-cal just about every time I moved it. I'll have to check my columns for squareness and I'll have to make an indicator holder and try to use it for calibrating. Does anyone have a revised procedure for using an indicator? I understand how to translate readings from inches to screw turns for the Z stops, but if the center reading is off by 0.010", how does that translate to a change in horizontal radius? Is the paper linked to a few pages back straight forward enough that a conversion can be derived?

It really seems like the calibration process could be automated/semi-automated. What kind of spare i/o is available on the controller board? I'll have to dig into that. I have a tool setter that would work really well for touching off on. For my day job i write software for automated manufacturing equipment, so I'm pretty familiar with a lot of the basics here. Unfortunately I have no experience with delta robots (too dirty for clean room use).

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Thu May 08, 2014 4:12 pm

Hans_G wrote:first post to this forum, hi everyone.

i got a v2 up and running about 2 weeks ago and noticed my printer has this problem too. I moved the printer around a few times and had to re-cal just about every time I moved it. I'll have to check my columns for squareness and I'll have to make an indicator holder and try to use it for calibrating. Does anyone have a revised procedure for using an indicator? I understand how to translate readings from inches to screw turns for the Z stops, but if the center reading is off by 0.010", how does that translate to a change in horizontal radius? Is the paper linked to a few pages back straight forward enough that a conversion can be derived?

It really seems like the calibration process could be automated/semi-automated. What kind of spare i/o is available on the controller board? I'll have to dig into that. I have a tool setter that would work really well for touching off on. For my day job i write software for automated manufacturing equipment, so I'm pretty familiar with a lot of the basics here. Unfortunately I have no experience with delta robots (too dirty for clean room use).


Hi Hans. Welcome to the forum!

There's no need to use a dial indicator for normal leveling, using a piece of paper as a feeler gauge does just fine. Use the scripts in the manual ("official docs" and "rostock max v2" section of this forum) and you'll get everything sorted out in short order. If your points are level at the towers, but hi or low in the center, you are correct that a horizontal radius adjustment is needed. That's in the manual too.

If you're a math or programming guru, please help work on the auto calibration effort! An older version of firmware called Marlin did this, but Repetier does not yet. There's a $100 bounty from a member of this forum too!

Hans_G
Noob
Posts: 2
Joined: Wed Apr 23, 2014 5:54 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Hans_G » Thu May 08, 2014 9:27 pm

thanks. so it sounds like the dial indicator calibration doesn't buy much over the procedure in the manual? I definitely have the problem of Z = 0 being > 0 towards the OD of the bed. Is there a consensus about how to chase down the contributors to this problem (bed level, columns square, calibration good, arms equal length, or is just "all of the above")? Do some people not have this problem because they just haven't tried to print at the OD yet? Or are they just lucky?

Really I'm trying to figure out how to best spend my time to get my printer working the way I hoped it would.

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Fri May 09, 2014 8:55 am

If you're consistently high around the perimeter, that's definitely the horizontal radius outlined in the manual.

I'm using the indicator to chase a different dragon. You can definitely be more precise with it, but for normal leveling and calibration it's bringing a gun to a knife fight.

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Tue May 13, 2014 8:11 am

So I had a thought last night... I wonder what would happen if I replaced my belts. What's the chance that they're out of tolerance ever so slightly?

I've overlooked them up to this point, but if they were off by a little, it would cause a geometry error. And it's something that wasn't replaced in my V1 to V2 conversion.
I think I'll order some new ones and see what happens to my measurements... Then I can also measure the old ones.

Has anybody else tried this in response to the error that we're chasing?

bdjohns1
Printmaster!
Posts: 238
Joined: Sat Jan 25, 2014 9:50 pm
Location: Madison, WI

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by bdjohns1 » Tue May 13, 2014 8:51 am

Jimustanguitar wrote:So I had a thought last night... I wonder what would happen if I replaced my belts. What's the chance that they're out of tolerance ever so slightly?

I've overlooked them up to this point, but if they were off by a little, it would cause a geometry error. And it's something that wasn't replaced in my V1 to V2 conversion.
I think I'll order some new ones and see what happens to my measurements... Then I can also measure the old ones.

Has anybody else tried this in response to the error that we're chasing?


Never thought of that. It's possible, but I'd guess fairly unlikely to contribute much to the error. I don't have the spec sheets for the belting we're using, but this kind of stuff is generally designed to handle its load without stretching - they're usually reinforced with Kevlar cords. We're not over-tensioning the belts. I don't think the GT2 belting is supposed to have much backlash, but it's certainly possible if the teeth wear down a bit. Measuring that geometry is probably going to be tough to quantify. Easiest way to check would be to measure for vertical-only play at the Cheapskate axles (to eliminate measuring any play in the carriages themselves).

User avatar
geolupulus
Printmaster!
Posts: 67
Joined: Mon Apr 14, 2014 3:03 pm
Location: Albany NY

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by geolupulus » Fri May 23, 2014 3:27 pm

Just chiming in to mention that I have noticed the same issue with my Revision 2 Rostock. ABS parts are a real bear as I have a job that needs large ABS prints and I cannot access all 11" of the build plate. When I try, the hot end raises between axes and the first layer does not adhere to the bed. Which leads to all sorts of warping in the print. Not good considering the Rostock was listed as having large build volume and printing in ABS as a "feature". I'm confined to printing my parts in pieces and then going back and using acetone+ABS slurry to glue my pieces together to get 11" wide prints.

Been trying to tackle this problem for a week now. Besides a suggestion from SEEME support of decreasing my horizontal radius (didn't work) I haven't heard a solution from them. Bummer too because I just ordered 2 more Rostocks to help me get this large job done.

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1719
Joined: Tue May 14, 2013 12:52 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by 626Pilot » Mon Jun 02, 2014 9:16 pm

Jimustanguitar wrote:There's no need to use a dial indicator for normal leveling, using a piece of paper as a feeler gauge does just fine.

I find calibration easier with a dial gauge. You get a lot more detail that way. For a person with the Z-lift issues, it's beneficial to see the exact effects of adjusting a tower.

In other news, here's a youtube from a guy who has this problem: https://www.youtube.com/watch?v=izTpyWeqkhA

User avatar
geolupulus
Printmaster!
Posts: 67
Joined: Mon Apr 14, 2014 3:03 pm
Location: Albany NY

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by geolupulus » Mon Jun 02, 2014 10:38 pm

Wow that video is perfect. It's been another week and I still haven't heard a solution from SeeMe support.

Quite frustrating when we bought the printer based on its build area and we cannot print to the build area extents!!

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1719
Joined: Tue May 14, 2013 12:52 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by 626Pilot » Mon Jun 02, 2014 11:08 pm

I came up with a new method for doing the tower rotations. It takes a lot longer than the ad-hoc method of trying different combinations on different towers, but you get better data and (hopefully) a better calibration. It takes at least an hour to step through all of this. You will need the following:
  • Depth gauge, accurate to 1/1000th inch or better
  • Depth gauge holder (you can 3D print one, or get one from http://tricklaser.com)
  • Some G-code scripts
  • Repetier firmware
  • Loads of time and patience

In the normal "three-point" calibration routine, you adjust the endstop screws on all three towers, then do a printer radius adjustment. We will expand on this in two phases. In phase 1, we'll change the rotation of each tower individually by a small amount (1/4 degree at a time), re-do the three-point calibration, verify the printer radius, and then record the amount of dip or lift relative to zero in all four quadrants. We have to have clean data, so we only change one tower rotation at a time. At the end of this phase, we'll have lots of measurements. In phase 2, we'll bring these measurements together to try altering the rotation of two towers at the same time.

Also, after you do your initial calibration, DO NOT ADJUST THE ENDSTOP SCREWS. Use the "Tower X/Y/Z endstop offset" variables in the EEPROM instead. This will streamline your work, and you won't have to continuously adjust the tower height.

G-code scripts:

Code: Select all

; Script 1, Z tower
G1 Z50 F12000
G1 X0 Y90
G1 Z5
G1 Z0 F500

; Script 2, Y tower
G1 Z50 F12000
G1 X77.94 Y-45
G1 Z5
G1 Z0 F500

; Script 3, X tower
G1 Z50 F12000
G1 X-77.94 Y-45
G1 Z5
G1 Z0 F500

; Script 4, Bed center
G1 Z50 F12000
G1 X0 Y0
G1 Z5
G1 Z0 F500

; Script 5, Fast Home
G1 Z275 F12000
G28


EEPROM settings:

Code: Select all

Acceleration [mm/s^2]: 1000 (less is OK too)
Tower X endstop offset [steps]: 30
Tower Y endstop offset [steps]: 30
Tower Z endstop offset [steps]: 30
Alpha A(210): 210
Alpha B(330): 330
Alpha C(90): 90
Delta Radius A(0): 0
Delta Radius B(0): 0
Delta Radius C(0): 0


Delta Radius is zeroed because I've never had anything but evil results from messing with it. The prints tend to shift a little each layer, so the output looks slanted. Alpha A/B/C = your X/Y/Z tower rotations. The endstop offsets are so that we can mess with the print center without having to constantly readjust the Z height. (Constantly tightening/loosening the endstop screws means you have to adjust the tower height as well - why bother?) We set these each to 30 steps so we have some wiggle room to either increase or decrease a tower's offset relative to the other two.

There are some high travel speeds in these scripts because you'll run each one of them dozens of times and I hate having to wait an unnecessarily long time for the printer to move. I've never made my belts jump over any teeth with these speeds, and I doubt you'll have trouble with them either, unless your belts are really loose. Repeatability is very good on these printers due to their high-torque motors, so don't waste time babying your printer with excruciatingly slow moves. However, I recommend setting acceleration to 1000 or less.

For each tower, the rotation is set to factory default (X=210, Y=330, Z=90). A standard tower calibration, including printer radius, is done per the manual. (Remember, after this you must leave the endstop screws alone, changing the values in EEPROM instead.) The scripts will make this easy because all you have to do is hit Ctrl+Alt + 1/2/3/4/5.

The purpose of the three-point calibration is to tell the printer where the center of the print surface is. Those test points are perfect for that purpose, but as the problem we're trying to fix occurs between the towers rather than next to them, we can't very well use those test points to figure it out. So, we switch to a quadrant system in which we test points in all four quadrants. As Repetier has only five hotkey scripts, and we're using all five, we will use the big movement arrows on the Manual Control tab instead. (This is a little clunky at first, but you'll get the rhythm down after you've done it several times.)

The quadrant test works like this:
  • Fast home, then move head to 0,0,0 (Ctrl+Alt+5, Ctrl+Alt+4)
  • Test quadrant 1: +Z arrow to lift 10mm, +Y and +X to move the head to (50, 50), -Z arrow to drop to 0mm; record reading
  • Test quadrant 2: +Z to 10mm, -X twice to move the head to (50, -50), -Z to 0mm; record reading
  • Test quadrant 3: +Z to 10mm, -Y twice to move the head to (-50, -50), -Z to 0mm; record reading
  • Test quadrant 4: +Z to 10mm, +X twice to move the head to (-50, 50), -Z to 0mm; record reading

I raise to 10mm and then descend to 0 each time because I don't want the probe tip dragging across the surface. That can nudge it out of alignment in the mount.

Anyway, after you do a tower alignment and printer radius, do your first quadrant test. You should have some notes like these:

Code: Select all

REFERENCE
X=210, Y=330, Z=90
-----------------------
Q1: 5
Q2: -3.5
Q3: -3.5
Q4: -6


That tells you the deflection in thous. 0.1mm is a hair under 4 thou, so you can see that with a 0.1mm layer height, the print nozzle will either dip down almost all the way to the print surface (blocking the nozzle) or lift more than one full layer height (ruining first layer adhesion) depending on which quadrant you're in. I used a target deflection of <=2 thou. That way, a 0.1mm layer height (which is about 4 thou) should be able to print OK.

Now comes the long, laborious task of repeating the quadrant test with different tower rotations. For the first phase, we will ONLY change ONE tower rotation at a time. This is because we need to start from the cleanest data possible, and we simply can't do that if we're changing more than one variable at a time. Each time we change a rotation, the change is small - I like to start with a value of 1/4 degree - and you HAVE to redo the tower alignment and verify the print radius EACH TIME. This is because changing a tower rotation invalidates the printer's notion of where its center is. Thus, you should expect each quadrant test to take 5-10 minutes.

This is what I got for my X tower:

Code: Select all

REFERENCE
X=210, Y=330, Z=90
-----------------------
Q1: 5
Q2: -3.5
Q3: -3.5
Q4: -6

X=209.75    Q1: 5.5     0.5 worse
            Q2: -5      1.5 worse
            Q3: -4      0.5 worse
            Q4: -6      Same
                ------------------
                B: 0
                W: 2.5
                ------------------
                Nope!


The "better/worse" evaluation is done in absolute values, or how close the Z deflection is to zero. If the reference deflection is -5, and you rotate a tower and find that the deflection is now +3, that's an improvement of 2. You then find the best and worst changes and record them below the measurements (in this case, none were better and the worst was 2.5 thou further away from zero). When this is done, record whether there was a net gain or not at the bottom of your figures. (I like "OK" and "Nope!" for easy scanning.)

The quadrant tests are done with the rotations like this:
  • X=209.75
  • X=210.25
  • Y=329.75
  • Y=330.25
  • Z=89.75
  • Z=90.25

You probably guessed that the point of this is to measure whether it's better for each tower if you increase the rotation a little, or decrease it a little. As you have to redo the tower calibration and verify the print radius each time, it will take awhile.

At the end of the first phase, this is what my notes looked like:

Code: Select all

REFERENCE
X=210, Y=330, Z=90
-----------------------
Q1: 5
Q2: -3.5
Q3: -3.5
Q4: -6

X=209.75    Q1: 5.5     0.5 worse
            Q2: -5      1.5 worse
            Q3: -4      0.5 worse
            Q4: -6      Same
                ------------------
                B: 0
                W: 2.5
                ------------------
                Nope!

X=210.25    Q1: 5       Same
            Q2: -1      2.5 better
            Q3: -5      2.5 worse
            Q4: -7.5    1.5 worse
                ------------------
                B: 2.5
                W: 5
                ------------------
                Nope!

Reset X to 210.
Y=329.75    Q1: 7        2 worse
            Q2: -4       0.5 worse
            Q3: -4       0.5 worse
            Q4: -8       2 worse
                ------------------
                B: 0
                W: 5
                ------------------
                Nope!

Y=330.25    Q1: 3        2 better
            Q2: -4       0.5 worse
            Q3: -3       0.5 better
            Q4: -6       same
                ------------------
                B: 2
                W: 1
                ------------------
                OK

Reset Y to 330.
Z=89.75     Q1: 2        3 better
            Q2: -2       1.5 better
            Q3: -4.5     1 worse
            Q4: -7       1 worse
                ------------------
                B: 4.5
                W: 2
                ------------------
                OK

Z=90.25        Q1: 7     2 worse
            Q2: -6       2.5 worse
            Q3: -4       0.5 worse
            Q4: -7       1 worse
                ------------------
                B: 0
                W: 6
                ------------------
                Nope!


Z=89.75 produced the best results for quadrants 1 & 2.
Y=330.25 produced the best results without making Q4 worse.


If you're lucky enough that a single rotation gets your printer well-aligned by itself, you're in luck. Set that rotation to your towers, redo the tower calibration/printer radius, verify with a quadrant test, and be on your way. If not, you can try either doing more aggressive rotations (in the directions measured to pay off the best) or try combining the most successful rotations:

Code: Select all

Reseting to reference.

REFERENCE
X=210, Y=330, Z=90
-----------------------
Q1: 5
Q2: -3.5
Q3: -3.5
Q4: -6

Trying Z=89.5   Q1: 0        5 better
                Q2: 0        3.5 better
                Q3: -3       0.5 better
                Q4: -6       same        Total: 9 better

Z=89.5
Y=330.25        Q1: -.5      4.5 better
                Q2: 0.5      3 better
                Q3: -3.5     same
                Q4: -5       1 better    Total: 8.5 better

Z=89.5
Y=330.5         Q1: -3.5     1.5 better
                Q2: 1        1.5 better
                Q3: -2.5     1 better
                Q4: -4       2 better    Total: 5 better

Z=89.5
Y=330.15        Q1: -1       4 better
                Q2: 2        1.5 better
                Q3: -4       0.5 worse
                Q4: 6.5      0.5 worse   Total: 4.5 better


I picked the third combination (Z=89.5, Y=330.5) because it had the lowest maximum deflection. Q4 was still a full 4 thou (one layer height) low, but the other quadrants were all better than that.

This still leaves significant slop, particularly in the 4th quadrant. To "band-aid" the problem, I opened KISSlicer, went to Printer->Hardware, and set the "Bed Roughness [mm]" to 0.2. This causes KISSlicer to produce a taller 1st layer. Bed Rougness is not a panacea - all it does is make a thicker layer, meaning you get squished filament in some places and over-round filament in others. As a finishing touch, it does help, and may make the difference between getting a good 1st layer adhesion and not being able to print at all.

barnett
Printmaster!
Posts: 215
Joined: Tue Dec 11, 2012 5:59 am

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by barnett » Tue Jun 03, 2014 10:26 am

I haven't tried this rotation fix yet, but I was thinking about the possible combinations of adjusted tower position angles and it seemed like a lot.

I put together this little chart. It seemed like the way to organize it was by the "gap between the towers." If you adjust each tower by no more than 0.25 degrees, then I got 18 possible configurations of the gap between the towers. Does this seem reasonable?

Code: Select all

offset = 0.25                                                               
         gap               tower angle                                          
ID      yz   zx   xy         x         y        z             position           alt pos1            alt pos2      
 0       0    0    0      210.00   330.00   90.00      x   y   z           x-   y-   z-        x+   y+   z+
 1      -1    0    1      210.00   330.25   90.00      x   y+   z           x-   y   z-            
 2      -1    1    0      210.00   330.00   89.75      x   y   z-           x+   y+   z            
 3       0   -1    1      209.75   330.00   90.00      x-   y   z           x   y+   z+            
 4       0    1   -1      210.25   330.00   90.00      x+   y   z           x   y-   z-            
 5       1   -1    0      210.00   330.00   90.25      x   y   z+           x-   y-   z            
 6       1    0   -1      210.00   329.75   90.00      x   y-   z           x+   y   z+            
 7      -1    2   -1      210.25   330.00   89.75      x+   y   z-                        
 8      -2    1    1      210.00   330.25   89.75      x   y+   z-                        
 9      -1   -1    2      209.75   330.25   90.00      x-   y+   z                        
10       1    1   -2      210.25   329.75   90.00      x+   y-   z                        
11       2   -1   -1      210.00   329.75   90.25      x   y-   z+                        
12       1   -2    1      209.75   330.00   90.25      x-   y   z+                        
13      -2    0    2      209.75   330.25   89.75      x-   y+   z-                        
14      -2    2    0      210.25   330.25   89.75      x+   y+   z-                        
15       0   -2    2      209.75   330.25   90.25      x-   y+   z+                        
16       0    2   -2      210.25   329.75   89.75      x+   y-   z-                        
17       2   -2    0      209.75   329.75   90.25      x-   y-   z+                        
18       2    0   -2      210.25   329.75   90.25      x+   y-   z+                        

User avatar
JohnStack
Printmaster!
Posts: 852
Joined: Thu Jan 03, 2013 7:07 pm
Location: Carlsbad, CA
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by JohnStack » Tue Jun 03, 2014 10:29 am

I think it is something more basic. If I missed it, have you considered reflashing your EEProm with some base settings?

There is a small script in the IDE that will allow you to reset the firmware back to it's base 2560 settings. Use it. Then reload a fresh config.

It doesn't make sense that you're having this bad of a problem. I don't think it is physical.

It sounds like you've measured everything.
Technologist, Maker, Willing to question conventional logic
http://dropc.am/p/KhiI1a

User avatar
626Pilot
ULTIMATE 3D JEDDI
Posts: 1719
Joined: Tue May 14, 2013 12:52 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by 626Pilot » Tue Jun 03, 2014 10:23 pm

JohnStack wrote:It doesn't make sense that you're having this bad of a problem. I don't think it is physical.

Other than adjusting geometry-specific parameters, I'm not sure what reflashing would do. I think the issue is due to unavoidable physical misalignments (due to the degrees of freedom that have to be managed while tightening down the towers) combined with the software not knowing the precise geometry of the printer.

User avatar
Jimustanguitar
ULTIMATE 3D JEDDI
Posts: 2631
Joined: Sun Mar 31, 2013 1:35 am
Location: Notre Dame area
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by Jimustanguitar » Wed Jun 04, 2014 8:26 am

I've cleared my EEPROM and loaded other non-repetier arduino programs to try and wipe out everything on the Rambo. While I did notice a few things that changed (like G28 speed) it did not have an effect on Geometry.

I've got a second Rambo (on loan to a good friend), a Sanguino that's almost all soldered together, and intentions to buy a smoothie board, so my next step (unsure of timeline) is to try a second or different controller board to determine if there's a gremlin in mine. Either inherent in the Rambo, or possibly a glitch or evidence of a static shock...

Since I replaced all of my wooden pieces, and have had the issue with stock and TL Carbon arms, I'm still unsure if this is physical or mechanical. My other next step is to change the belts, but they're on a very slow ship from China at the moment.

User avatar
geolupulus
Printmaster!
Posts: 67
Joined: Mon Apr 14, 2014 3:03 pm
Location: Albany NY

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by geolupulus » Wed Jun 04, 2014 9:40 am

I have lost hope and just put layers of tape down on my bed where the hotend rises to artificially raise the build plate to the hotend. Seems to work, but a pain to align.

User avatar
JohnStack
Printmaster!
Posts: 852
Joined: Thu Jan 03, 2013 7:07 pm
Location: Carlsbad, CA
Contact:

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by JohnStack » Wed Jun 04, 2014 9:53 am

626Pilot, of course; however, a two minute check is worth trying the reflash.
Technologist, Maker, Willing to question conventional logic
http://dropc.am/p/KhiI1a

snoman002
Prints-a-lot
Posts: 30
Joined: Thu May 01, 2014 11:19 pm

Re: Unsolved Mystery. Weird Z0 behavior around build perimet

Post by snoman002 » Wed Jun 04, 2014 6:23 pm

The previously mentioned alignment method sounds interesting, but wow what a time consuming process.

Might I suggest that instead of using a quadrant based system to use a 6 point star instead since your adjusting 3 towers? This should allow you to see positive and negative changes in readings and adjust.

Ultimately if it is proven to be an alignment problem someone (someone smarter than myself) could program a routine that measures variance and calculates the optimal settings for calibration. Ultimately it could all be implemented in firmware. Touch center and a 6 point star, input values, firmware calculates the changes needed, run again and input values, firmware calculates the change and adjusts again (radius, rotation etc), run a third time... 4 iterations should get you DANG close to perfect. Unfortunately I only know the fuzzy edges of the math needed

Post Reply

Return to “Troubleshooting”