So what did I do wrong?

[Zob]

Hi,

Let me say first that I've been printing some great small items using the old calibration script. BUT anything large is a catastrophe. I'm convinced I've done something stupid in the build like fitting the hotend upside down but I can't spot it. Hopefully you guys can...

Using a feeler gauge and setting Z to .5mm in various places across the bed I was convinced that the bed was warped but using a straight edge proved it wasn't. The range was about 1.2mm way too much to be usable.

Then the Octoprint auto calibration came along last week - best it will go to is 0.15 and the feeler gauge is telling me there's no improvement.

I've reloaded the firmware (with EEPROM_clear) at least 4 times as a clean start.

Using the HE280 accelerometer, a bit of VB.net and Excel I mapped the entire bed in 10mm increments and this is what I got after a 3 iteration calibration cycle... In this graphic the X pillar is front & centre.

And here's the tech stuff for those interested...
Bog standard self-built Rostock MAX v3 with Raspberry Pi v3
Firmware: seemecnc 20161209
Bed support dimples downwards, glass taped (at the moment - made no difference to the crazyness either way)

Attached is the entire Excel file if you want to explore the data, graphic more thoroughly.

BTW - I know the hotend is the right way up really

Thanks for any suggestions anyone can give.
Zob

[wshiwsbrding]

Hi,

Then the Octoprint auto calibration came along last week

Are you referring to the one that geneb has been working on recently?

[Zob]

Yes, I also tried the manual version and the quick auto calibrate script. All with pretty much the same results.

[mhackney]

Do the orange peaks correspond to the towers or 1/2 way between the towers.

Either your calibration was faulty - what delta radius was calculated? (check it in the EEPROM) All stock V3s will have a very similar delta radius so that should be a good indication.

If that is reasonable, then you have slop in your build plate or arms/carriages. The pattern makes sense somewhat - the center would be depressed since the flex in the system will push the center down further. The outer edge would be higher. I asked about the orientation of the orange peaks as that might give some indication. I would guess they are right at the towers where the probe is "stiff arming" when it hits the bed. Between the towers would be more flexible in my scenario.

If thats the case, you should be able to visually observe this flex if it's the bed - simply push around on the center and edges and watvh for movement. You're showing about 1 mm so it should be pretty easy to spot. If not, check your belts, carriages, etc.

[Zob]

Thanks for your reply,

The peaks correspond to the gaps between the towers.

Do you mean the Horizontal rod radius? That's at 154.78mm.
With my limited but growing knowledge of delta geometry, I was starting to suspect that value.
I see from the firmware that that's at 145 by default so it's a good way off.

Delta Radii A,B & C are all 0.

There's no discernible slop in the mechanism or build plate. As I say small items print perfectly and when I say small items: I recently printed a labyrinth box 10cm high & 4cm across. It came out very well once I'd manually adjusted the z-height in the slicer.

Time for yet another scratch start & recalibrate I think...

[nebbian]

That 3 sided peak pattern shows that either your steps per mm, or your diagonal rod length is wrong in the firmware. You can remove the peaks by adjusting either one. I prefer to measure the diagonal rods as best as I can, then adjust the steps per mm till it's flat. This accounts for different belts not being exactly the right size, and is actually a good measurement of the steps per mm that is actually happening.

The bowl shape shows that the delta radius (horizontal rod radius in Repetier) is wrong.

I've been through the same thing, many times, I recognise it instantly.

I would adjust the delta radius first until the bowl shape is gone, then go through the steps per mm / rod length adjustment.

[mhackney]

Yes, horizontal rod radius. With stock stuff yours seems too high. Mine calibrates to 144.158

@nebbian - steps per mm on these stock machines is 80steps/mm. That is pretty much cast in concrete and should not require any adjustment. Both arm length variations (if they are all the same) and carriage steps/mm variations (if they are all the same) maintain planarity of the effector movement, not the type of pattern that Zob is seeing.

Zob, confirm that yours are 80 s/mm - this is basically an invariant calibration parameter for these machines. Arm length variations - if they are all consistently short or long - result in a scaling issue and not a planar movement issue.

Zob is seeing "non planarity" that is either due to bad calibration, bad mechanical geometry (i.e. build issues) or slop in the mechanism. I don't think it is bad geometry and now ob has confirmed no slop.

And Zob, PLEASE don't adjust Z height in the slicer! You need to learn to set this correctly in firmware. Relying on the slicer to tweak this is only going to bite you in the rear end later.

[nebbian]

Mhackney,

Trust me I've done enough experiments to prove that it's either steps per mm or diagonal rod length (or both).

Here are some calibrations I did the other night. Look at the pattern of the first six results. The points are arranged in a hexagonal pattern around the bed. I started with the measured diagonal rod length, and the calculated steps per mm (GT2 belt, 1/32 microstepping, 0.9 degree motors, and the number of teeth on the pulley = 200 steps/mm) , and ran through a couple of cycles of the delta calibrator until it converged.

Note that the measurements near the towers are negative, while the measurements between towers are positive. I've graphed this before, as the OP did. It results in a wavy sine shaped pattern.

Now I adjusted the steps per mm to what I had actually measured using a caliper, using the carriages to jog the effector down 10mm at a time. Note that this is not the calculated value, it is slightly higher. I've consistently measured GT2 belt to need around 0.8% higher steps per mm values than what it should be (2mm per tooth). I've measured this on two different printers. This shows that the GT2 belt that I use is around 0.8% less than 2mm per tooth.

Note that the wavy pattern is gone.

The DC42 calculator will adjust the diagonal rod length if you choose 7 factor calibration to get rid of this wavy effect.
However if this diagonal rod length is not what you actually have, then you get scaling issues. It could just as well adjust the steps per mm value to remove the wavy pattern.

I hope this helps.

[Zob]

Thanks for the pointers guys,

80 Steps/mm

I've now successfully done a full recalibration following all of the steps I believe are required but the bed profile remains utterly useless post-calibration.

Don't misunderstand me, I'm happy to tinker but somewhere there's a flaw in the entire process if, following the instructions an average Joe ends up where I am at the moment. In the hope of revealing what point I'm missing in my understanding, and hopefully lighting the way for those that follow I've documented my calibration process from the point that the hardware build was complete. If I've missed anything please let me know.

During what follows there were no odd noises, clicks or any indication whatsoever that there was any mechanical issue. As I say I can print items with a small (<60mm) footprint with no issue other than adjusting the z-height in the slicer (I promise once I have this dialed in I'll put it in firmware Mhackney, but I was in a hurry and I knew it wasn't a final setting. I'll burn all my gcode files as I go!)

Calibration Start -------------------------------------

Using Arduino 1.6.13
Upload eprom_clear
Power cycle printer (displays two bars)

Check firmware configuration.h
#define PRINTER 5
#define REPETIER_VERSION "0.92.2"
#define FIRMWARE_DATE "20161209" // in date format yyyymmdd

Upload firmware - successful

Export firmware settings in MatterControl - C:\default.eprom.txt
Noted that configuration.h #define DELTA_MAX_RADIUS 145.0
While default eprom contains 143.280 Horizontal rod radius at 0,0 [mm]

create graph default.xlsx with 20mm step
Apart from being ~30mm high with a dome ~.25mm centre to edge slope it's pretty flat.

Using OctoPrint 1.3.0
Run G29 calibration
CALIBRATION COMPLETE

Export firmware settings in MatterControl - C:\g29.eeprom_settings.ini

create graph g29.xlsx with 20mm step
Now seeing the parabola bowl shape although it is all positive with +0.003 at centre and +1.5-2mm at periphery
Diagonal rod length [mm]|291.060
Horizontal rod radius at 0,0 [mm]|148.302

Delta Autocalibration
Load EEprom (could use some feedback here other than the button greying)
Begin Delta Calibration
Calibration Result: Calibrated 7 factors using 10 points, deviation before 1.33 after, 0.21
Load EEprom
Begin Delta Calibration
Calibration Result: Calibrated 7 factors using 10 points, deviation before 0.39 after, 0.16
Load EEprom
Begin Delta Calibration
Calibration Result: Calibrated 7 factors using 10 points, deviation before 0.17 after, 0.15
Load EEprom
Begin Delta Calibration
Calibration Result: Calibrated 7 factors using 10 points, deviation before 0.14 after, 0.14

Export firmware settings in MatterControl - C:\autocal.eeprom_settings.ini
Diagonal rod length [mm]|319.110
Horizontal rod radius at 0,0 [mm]|155.010

create graph autocal.xlsx with 20mm step
Still seeing the parabola bowl shape - now also below the Z0 plane but still a concave parabolic dish
Diagonal rod length [mm]|319.110
Horizontal rod radius at 0,0 [mm]|155.010

Calibration End -------------------------------------------------------

Conclusions:
As the default, uncalibrated settings are fairly flat, albeit way to high and the calibrated settings, while odd, are consistent and describe a mathematical curve I'm inclined to believe that I have no loose or misaligned bits or they would have to be equally bad on all three towers.

As the parabola appears after the g29 calibration there must be something fundamentally wrong with my printer or the calibration script. As I'm seeing others reporting the OctoPrint Autocalibration working wonders it seems unlikely that the calibration is wrong.

Next steps
Thinking back through my build the only point where I was unsure was belt tension. The instructions on this are vague in the extreme with something along the lines of "not as tight as a bowstring" being the guidance. I'll try re-tensioning the belts first then I'll start tweaking eeprom settings though logically I don't feel I should have to as the printer is supposed to auto calibrate.

[mhackney]

It isn't clear from your description but are you running G29 and then IMMEDIATELY running the OctoPrint script? I mean literally nothing else between? The G29 sort of primes the pump for the script. If this isn't what you've been doing try it.

[mhackney]

Your diagonal rod lengths after the plugin are way too long
Diagonal rod length [mm]|319.110 the default value in EEPROM is DELTA_DIAGONAL_ROD 291.06

This is a result of this 7 factor calibration. It really needs to be changed to 6 factor.

Try this: set the diagonal rod length to 291.06 in EEPROM and then rerun your graphing and see what that looks like.

Meanwhile, I'm not setup to run or look at the plug in right now (Duet in my V3) so I don't know if it has an option for calibration factors. If so, then rerun choosing 6. If not, we need to modify the script to use that as a default.

[Zob]

In that calibration no, I did not run a G29 immediately followed by the autocalibration.

Repeating with a G29 first...


G29
Delta Autocalibration
Load EEprom
Begin Delta Calibration
Calibration Result: Calibrated 7 factors using 10 points, deviation before 0.34 after, 0.14
Load EEprom
Begin Delta Calibration
Calibration Result: Calibrated 7 factors using 10 points, deviation before 0.15 after, 0.14

Tried diagonal rod length to 291.06 & that just seemed to increase the z scale of the parabola.

There's no 6/7 factor selection - I'll see if I can hack the plugin manually...

[geneb]

Grrr. I just checked and it somehow got changed to 7 factor. I've changed it to six and pushed an update.

g.

[mhackney]

Thanks Gene.

[HComet]

Just a comment that the auto calibration plugin was 7 factor when I installed it just after it was released. My diagonal rod length is getting set to 294.370 after my last calibration run with .03 deviation. I have a V2 with the HE280 upgrade.

So should we be doing 6 or 7 factor? I guess 6 now that Gene has updated it.

Also, wasn't the default diagonal rod length 290.8? So, I thought that maybe the V3 is different. I just looked at the firmware and configuration.h has 291.06 for both V2 and V3. I guess the old value was wrong? The difference is pretty small.

[mhackney]

I highly recommend NOT using the 7 factor calibration. SeeMeCNC has already done the work to provide a good starting rod length. Run 6 factor, then print a test cube and check its dimensions. Only adjust arm length if you need to fix a minor scaling problem.

I bet if you printed a calibration cube with rod length of 294.37 you will have a scaling issue.

From the firmware:

Code: Select all

#define DELTA_DIAGONAL_ROD 291.06  // ball cup arms

A small difference in arm length will affect the X-Y scaling of your parts.

So everyone, PLEASE reset your rod length to 291.06 then recalibrate using Gene's update that does 6 factor calibration.

[Zob]

OK, so I've loaded the 0.1.2 version of the plugin (after deleting the original)
Double checked in the plugin manager
Reset my EEprom to factory defaults
Checked Diagonal rod length is
Done a G29

The display still reads 7 factors...

Calibration Result: Calibrated 7 factors using 10 points, deviation before 0.15 after, 0.15

Still doesn't go below 0.15 and still updates the diagonal rod length.

I've even checked my copy of deltaautocal.js on the raspi contains the edits in the github repository

Sorry Gene, looks like your arrow missed it's target.

[HComet]

Looks like it may be hard coded further down in the js:

Code: Select all

        self.beginDeltaCal = function () {
          numPoints = 10;  // these should be configurable at some point.
          numFactors = 7;
          self.statusDebug("");
          self.statusCalResult("");

If you change the numFactors to 6 in your local copy of the deltaautocal.js that may fix it temporarily until Gene fixes it in github.

In theory numPoints only needs to be 7 too.

[nebbian]

It's great that people are starting to get stuck into serious calibration of their printers

If your diagonal rod values are changing a lot (between what's measured, vs what it wants the value to be) when doing 7 factor calibration, then something else is wrong with your calibration or build.

If you then go back to 6 factor calibration, then you will end up with high spots (or low spots) between your towers, as the calculator can't correct for this mistake. So you'll end up with a non-flat print surface again.

One other factor that most seem to miss is to calibrate their steps per mm value. I've found a couple of ways to calibrate this:
1) Using a set of digital calipers set up so that the carriage pushes a caliper jaw, and jog down 1mm at a time for about 50 mm. When jogging, you want to watch the numbers after the decimal point. They will bounce around a bit due to the inaccuracies in measurement, but you want them to bounce around the one number, and not drift up or down. I find that this is accurate to within about 0.10mm on each jog. It gives a good indication if your steps per mm is wrong, and you can tell which direction to adjust it.
2) Use the 6 factor calibration, and adjust the steps per mm values until the error between the towers is about the same as the error next to the towers.
3) Use the 7 factor calibration, and adjust the steps per mm values until the calculated diagonal rod value agrees with your measured diagonal rod values.

All three methods give me the same values for steps per mm on my printers, which leads me to believe that it's a valid test. Methods 2 and 3 require you to be a bit careful, and I wouldn't adjust the steps per mm value to higher than 1% off what is recommended. Method 1 has the benefit of actually measuring the steps/mm value directly, although I've found the margin of error to be higher than methods 2 and 3.

Using these methods, I consistently get deviation of 0.03 or less. To get better than this requires careful tuning of the distance between the towers, very carefully measuring tower twist (I used a laser, two spirit levels, and some turnbuckles), making the bed square to the towers, and lots of time.

Getting to a deviation of 0.05 should be easy for most people, and just requires tuning of the available parameters. 0.15 deviation is huge, and indicates a problem that should be able to be found without too much difficulty.

Good luck to all who embark on this path.

[nebbian]

Conclusions:
As the default, uncalibrated settings are fairly flat, albeit way to high and the calibrated settings, while odd, are consistent and describe a mathematical curve I'm inclined to believe that I have no loose or misaligned bits or they would have to be equally bad on all three towers.

As the parabola appears after the g29 calibration there must be something fundamentally wrong with my printer or the calibration script. As I'm seeing others reporting the OctoPrint Autocalibration working wonders it seems unlikely that the calibration is wrong.

Here's the graph from your autocal.xls:

I'm surprised that you still have the bowl shape. This is usually taken care of by the horizontal radius value. It's as if the horizontal radius value is not being sent (and saved) in the printer.

I would check that it's being updated and saved in EEPROM.

[geneb]

Yeah, I changed it in the wrong spot, sorry. I need to get that silly thing cleaned up of all the unused cruft. Gimme about 20 minutes and I'll get it updated.

g.

[Zob]

Thanks Gene, above & beyond the call of duty working on Christmas day!

Unfortunately following this I'm still seeing no improvement.

Has anyone else with a stock v3 ran through the process and got good results? Just to prove I'm not going mad?

1) clear EEPROM
2) power cycle printer
3) load latest firmware 20161209
4) G29
5) octoprint Delta Autocalibrate 0.1.4 - 2 iterations

I'm still seeing 0.15 after two cycles with no further improvement but the plot has changed entirely.

XLSX plot & eeprom ini attached

[mhackney]

I suspect you have mechanical slop somewhere - lose belts, wobbly carriages, or the bed is flexing.

Yes, a umber of us are getting good results (well, I was before the conversion to Duet this weekend).

[Zob]

Thanks Mhackney,

I'll go over everything again. Any tips on how tight the belts should be? Currently at home position, if I slip a pencil behind the belt on the inside of the tower it holds it there. Anything heavier will fall.

Zob

[nebbian]

Now we're getting somewhere!

Can you try measuring how square the bed is in relation to the towers?