Unsolved Mystery. Weird Z0 behavior around build perimeter.

[Hans_G]

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.

[Jimustanguitar]

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.

[Jimustanguitar]

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]

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

[geolupulus]

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.

[626Pilot]

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

[geolupulus]

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!!

[626Pilot]

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]

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+								

[JohnStack]

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.

[626Pilot]

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.

[Jimustanguitar]

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.

[geolupulus]

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.

[JohnStack]

626Pilot, of course; however, a two minute check is worth trying the reflash.

[snoman002]

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

[bdjohns1]

I think the 6-point idea makes sense, based on the shape of those error plots linked/discussed upthread.

[Jimustanguitar]

Check out page 1 of this thread. A 6 point test is where this all started.

[snoman002]

Check out page 1 of this thread. A 6 point test is where this all started.

It sure did, but that's beside the point. We are recommending that the previously mentioned adjustment routine be implemented with a 6 point star instead of a quadrant point check.

[Jimustanguitar]

We are recommending that the previously mentioned adjustment routine be implemented with a 6 point star instead of a quadrant point check.

I'd be very curious if Guanu did this on the Orions if he'd catch any red handed machines and be able to help us track it down. Check out the GCode that I posted earlier in this thread. That would be a good starting point.

[kirbymills]

https://www.youtube.com/watch?v=izTpyWeqkhA

buying this machine was a mistake.

[snoman002]

See, to me that makes me think the radius of the upper circle is off.

The error is roughly consistent between towers, it is always the same direction, and happens in the same spots.

Is there two radius to define? There should be one for the effector and one for the cheepskates, unless a single point was used for the effector and a mock radius used for the upper pivots.

Kirbymills, I'm going to suggest one thing. Change the length of your arms in firmware, then tweak the radius until its level between center and in front of one of the towers. See how the error between towers changes. If it gets worse then tweak the length of the arms the other way in firmware, if its better (or went the right direction but too far) then you went the right way and just need to add or subtract from your tweak to dial it in.

[snoman002]

OK, before I loose my thought here.

The firmware likely considers the effector a single point, and the radius is the radius of the pivots on the cheapskates. It then uses geometry to determine where the cheapskates need to be to put the print head in a certain position.

Arm length and radius can be define in such a way where center and DIRECTLY IN FRONT OF A TOWER are the same, but if this is not reality then the error would show up between towers where only two sets of arms really determine z height.

If the error exactly between towers is the same at all three points but high or low compared to directly in front of a tower then its the radius/arm length that's off.

If the error between towers is all in one direction but different then the arm length/radius needs to be tweaked AND the rotation of the towers.

[626Pilot]

626Pilot, of course; however, a two minute check is worth trying the reflash.

I have an Azteeg X3 Pro that I just finished soldering together, so I will try that exact thing when I get around to installing it.

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

It's an ordeal, but it saves SO much time compared to trying different ad-hoc things. It's a few hours as opposed to days/weeks of trying different tweaks.

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

There are some touch probes (one of them is in my sig) but so far Repetier hasn't demonstrated an ability to do a proper calibration with them.

https://www.youtube.com/watch?v=izTpyWeqkhA

buying this machine was a mistake.

I see in the YT comments you are thinking about getting a V2 upgrade kit. Don't. Another guy has this same problem, and when he installed the upgrade, he still had the same problem.

[snoman002]

Not sure if a touch probe or a dial indicator is more work/cost. I was thinking that a gcode of the 6 point star (plus center) could be run with a dial indicator and the values entered, the software compares the values and adjusts the settings. Do this 2 or 3 times and the errors should be taken care of.

[Polygonhell]

Not sure if a touch probe or a dial indicator is more work/cost. I was thinking that a gcode of the 6 point star (plus center) could be run with a dial indicator and the values entered, the software compares the values and adjusts the settings. Do this 2 or 3 times and the errors should be taken care of.

There is a branch of Marlin that does this, though it uses more than 6 samples, as discussed a couple of pages back the difficulty is attributing the error to the actual cause. It could be bad tower placement or a combination of errors in arm length and radius.