Marlin: G26 does nothing and UBL is way off

[Whytehorse]

I'm using the bugfix 1.1.x marlin on a mini kossel delta and I can get the calibration to work perfectly(slightly better than my manual calibration) but when I run the bed leveling it does it's thing and then is way off. So I tried the g26 to print a test pattern and it does nothing. I have the correct #defines enabled in configuration.h

So I turned off ubl and printed a delta calibration file and it's obvious my bed is tilted. What can I do?

[Whytehorse]

Here's the g29 mess it prints

Bed Topography Report:
(0,2) (2,2)
(-70,70) (70,70)
. 0.603 .

-0.173 [-0.110] -0.184

 .      -0.812       .

(-70,-70) (70,-70)
(0,0) (2,0)

[Whytehorse]

with more points I get:
Bed Topography Report:
(0,9) (9,9)
(-70,70) (70,70)
. . . 0.446 0.384 0.734 0.557 . . .

 .       0.431    0.480    0.612    0.488    0.539    0.702    0.641    0.542       .

 .       0.344    0.322    0.482    0.458    0.256    0.469    0.531    0.452       .

0.006 0.121 0.181 0.282 0.300 0.329 0.343 0.271 0.211 0.125

0.118 0.008 -0.083 0.031 0.084 [ 0.122] 0.102 -0.152 -0.292 -0.082

-0.046 -0.121 -0.189 -0.087 -0.020 -0.038 -0.032 -0.143 -0.119 -0.263

-0.330 -0.222 -0.248 -0.528 -0.257 -0.190 -0.187 -0.262 -0.379 -0.327

 .      -0.590   -0.488   -0.411   -0.568   -0.454   -0.330   -0.341   -0.471       .

 .      -0.633   -0.822   -0.620   -0.631   -0.669   -0.632   -0.481   -0.517       .

 .          .          .      -0.725   -0.734   -0.607   -0.551       .          .          .

(-70,-70) (70,-70)
(0,0) (9,0)

[Roxy-3D]

Any bed leveling system works best if you level the bed as much as possible. UBL is no exception. But the numbers I see in the UBL G29 T Topology map do not look crazy. It can correct for those types of numbers.

First... You should do a few G29 P3's to fill in the grid. But can you get G26 to print anything? If so, can you post a picture?

[Whytehorse]

Nothing happens with:

G29 P3
SENDING:G29 P3

[Whytehorse]

Oh nevermind, here's what it did:
Bed Topography Report:
(0,9) (9,9)
(-70,70) (70,70)
0.518 0.518 0.638 0.446 0.384 0.734 0.557 0.751 0.632 0.632

0.431 0.431 0.480 0.612 0.488 0.539 0.702 0.641 0.542 0.542

0.006 0.344 0.322 0.482 0.458 0.256 0.469 0.531 0.452 0.332

0.006 0.121 0.181 0.282 0.300 0.329 0.343 0.271 0.211 0.125

0.118 0.008 -0.083 0.031 0.084 0.122 0.102 -0.152 -0.292 [-0.082]

-0.046 -0.121 -0.189 -0.087 -0.020 -0.038 -0.032 -0.143 -0.119 -0.263

-0.330 -0.222 -0.248 -0.528 -0.257 -0.190 -0.187 -0.262 -0.379 -0.327

-0.330 -0.590 -0.488 -0.411 -0.568 -0.454 -0.330 -0.341 -0.471 -0.327

-0.444 -0.633 -0.822 -0.620 -0.631 -0.669 -0.632 -0.481 -0.517 -0.517

-0.444 -0.633 -0.822 -0.725 -0.734 -0.607 -0.551 -0.481 -0.517 -0.517
(-70,-70) (70,-70)
(0,0) (9,0)

[Whytehorse]

still g26 does nothing

[Roxy-3D]

@oldmcg May I ask you to jump into the mix? It may be some of those variables that have been moved to Program Memory are not working correctly. We had a problem with the Feed Rate array in https://github.com/MarlinFirmware/Marlin/issues/6993. And I think we still have a few other issues. I kind of doubt it is a "RAM saving by moving things to Program Memory" problem. But I don't know and it is hard to debug without having a Delta Printer to load firmware on to.

[oldmcg]

I'll run a G26 tomorrow to see what happens.
@Whytehorse, how old is your bugfix-1.1.x snapshot?

[Whytehorse]

June 2, 2017

[oldmcg]

I'm running bugfix_1.1.x snapshot from June 4 and just tried G26 and it worked for me with UBL on delta.

@Whytehorse, I made some UBL for DELTA improvements on June 3 but I don't "think" there was anything G26 specific, but it is possible. Can you try a more recent snapshot of bugfix_1.1.x? When you run G26 does it say anything on the console or on the LCD?

Also, for UBL delta, after G29 P1 to auto probe, then G29 P2 to manually probe un-probeable locations, I recommend using new G29 P3.1 to smart-fill the remaining unreachable points that is more appropriate for delta than regular G29 P3. Sorry documentation hasn't caught up yet. This will probably become the default for P3 eventually.

@Roxy-3D, for G26, can I recommend allowing B0 H0 F0 L1 so you can "dry-run" a G26 motion without any extrusion? I didn't have any filament loaded, but I had to use B25 H165 to heat empty nozzle before it would start the G26 pattern.

[oldmcg]

@Whytehorse, also make sure your configuration.h has #define UBL_G26_MESH_VALIDATION.

[Roxy-3D]

for G26, can I recommend allowing B0 H0 F0 L1 so you can "dry-run" a G26 motion without any extrusion? I didn't have any filament loaded, but I had to use B25 H165 to heat empty nozzle before it would start the G26 pattern.

I never even considered doing that. It probably would be just a little bit of code to allow G26 to do 'Dry Runs'. That is probably a good idea.

[Whytehorse]

G26 B65 H210 F1.75 L0.2 N0.3
Does nothing. I'll try an updated snapshot later today

[oldmcg]

If it does nothing and says nothing on the console or the LCD then I suspect UBL_G26_MESH_VALIDATION is not enabled. Otherwise G26 ought to display an error if value out of range or otherwise can't print.

[oldmcg]

And, I think N0.3 is now S0.3. I don't know why that was changed.

[Whytehorse]

I think my config.h is re-used from rcbugfix and it only has UBL_G26_MESH_EDITING. So I just added the validation define. Now it's working, thank you!

[Roxy-3D]

And, I think N0.3 is now S0.3. I don't know why that was changed.

'N' is used to indicate the line number of the GCode being transmitted in the GCode protocol. It works just fine as a parameter also. But it generates strong feelings from some people.

[Whytehorse]

So here's the new way, the way of the Delta Jedi:

1. Install rcbugfix-1.1.x, enable UBL, G26, etc
2. Manual calibration to within 0.1mm or thickness of a piece of paper. This involves adjusting endstops with a piece of paper as a feeler gauge, adjusting height, and performing a 7 point calculation to get the delta radius, tower offsets, endstop offsets, etc.
3. Heat the bed and extruder to operating temps.
4. Autocalibrate: G33
5. Save to EEPROM: M500
6. Level the Bed: G29 P1
7. Fix the bed: G29 P3 T
8. Print a test: G26 B65 H210 F1.75 L0.2 S0.4
9. Manually fix the bed: Move the extruder to a point that needs adjustment and hit G29 P4 T. Then move the dial up or down to correct that point. Repeat for all points that need correcting.
   It's the only method that I've found to get good results and systematically converge to a perfect first layer. I'm pretty sure the whole thing could be automated if you just assume the bed is not level and the calibration is off and go from there.

In order to get this to work on my mini kossel, I had to comment out the following lines which were making the head crash into the towers and add my old config lines:
//#define _PX(R,A) (R) * cos(RADIANS(A))
//#define _PY(R,A) (R) * sin(RADIANS(A))
//#define UBL_PROBE_PT_1_X _PX(DELTA_PROBEABLE_RADIUS, 0) // Probing points for 3-Point leveling of the mesh
//#define UBL_PROBE_PT_1_Y _PY(DELTA_PROBEABLE_RADIUS, 0)
//#define UBL_PROBE_PT_2_X _PX(DELTA_PROBEABLE_RADIUS, 120)
//#define UBL_PROBE_PT_2_Y _PY(DELTA_PROBEABLE_RADIUS, 120)
//#define UBL_PROBE_PT_3_X _PX(DELTA_PROBEABLE_RADIUS, 240)
//#define UBL_PROBE_PT_3_Y _PY(DELTA_PROBEABLE_RADIUS, 240)
#define UBL_PROBE_PT_1_X 39 // These set the probe locations for when UBL does a 3-Point leveling
#define UBL_PROBE_PT_1_Y 80 // of the mesh.
#define UBL_PROBE_PT_2_X 39
#define UBL_PROBE_PT_2_Y 20
#define UBL_PROBE_PT_3_X 80
#define UBL_PROBE_PT_3_Y 20

[oldmcg]

I'm very concerned about this because I added code to explicitly prevent it...

In order to get this to work on my mini kossel, I had to comment out the following lines which were making the head crash into the towers and add my old config lines:

The nozzle should never move outside the DELTA_PRINTABLE_RADIUS, even if these probe points are defined outside of that. How are your DELTA_PRINTABLE_RADIUS and DELTA_PROBEABLE_RADIUS defined?

Thx.

[Whytehorse]

Attached is the config file.
Configuration.h.zip
I believe you're passing hard numbers to the function(e.g. 120, 240) instead of the radius.This config file came frome example_configurations/delta/kossel_mini/configuration.h
to get 39=_PX(R,A) (R) * cos(RADIANS(A)) you'd need cos^-1(39/80)=RADIANS(A) or A=RADtoDEG(0.4875)=27.9deg.

Oh wait, I remember trig ;) x=rcos(theta)... 39=80cos(theta)... cos^-1(39/80)=theta... theta=1.06443316 rad or 60.98752764192 deg. Perhaps the degrees are out of phase?

OK, to use cos you need to pass 60 degrees which would give x=40, which is the normal point for a mini kossel with radius 80. Mine is 39 because I had to eyeball it.

[Whytehorse]

I have another question about the G29 P4 T. It gives a number on the display which is presumably taken from the mesh grid. What is this number? I'm confused which way to go to move the extruder up or down. One would think that increasing the number brings the head up and decreasing it brings the head down, but the opposite seems to be happening.

[oldmcg]

Someone recently added the _PX based UBL points to the example files -- I haven't tried them yet myself but I will do that tomorrow. Regardless, it shouldn't move outside DELTA_PRINTABLE_RADIUS.

G29 P4 is also something I don't have much familiarity with -- I just use P1, P2, and P3.1. But I will experiment with P4 tomorrow as well. I know there is one setting somewhere that changes the direction of the panel controller knob, but I don't know if that is relevant.

[Roxy-3D]

I'm confused which way to go to move the extruder up or down. One would think that increasing the number brings the head up and decreasing it brings the head down, but the opposite seems to be happening.

Internally to the UBL system... The mesh point values tell the system how much to raise the nozzle at the given location. So, Yes... Increasing a mesh point's value should raise the nozzle at that location.

If you just want to play around and see things.... you can do:

• G29 P0 to create a mesh full of 0.000's
• G29 Q1 to load a test pattern into the mesh
• G29 A to activate the system
• G29 T to look at the test pattern.

Then lower the nozzle to 1 mm above the bed, and do a big move. Something like

• G1 X10 Y100
• G1 X175

You should see the nozzle go up as it crosses the line. And then come back down. And the test pattern will have large positive numbers that make the 'line'.

[oldmcg]

I have several findings from researching these issues this morning.

@Whytehorse, I am unable to reproduce crashing towers (moving nozzle outside of printable radius). Your X/Y offset from extruder are both zero, so all probes should be nozzle centered. Your printable radius is 80 on a mini kossel with delta_radius of 95. That seems a little suspect to me that your printable radius might be defined too big for actual full circle nozzle movement. Printable radius is not just the size of the bed, but size at which you can reach full circle without binding rod joints or hitting any obstructions (bed clamps). If I'm telling you things you already know then I apologize -- I'm just trying to eliminate things that could be causing tower crash since I can't reproduce it. Try using G2 arc to move full circles at increasing radius to see if you have full motion at that radius. G1 Z50 X0 Y60 then G2 I0J-60 should move in full circle at radius 60. Then G1 X0 Y70 and G2 I0J-70, etc. If you can run full arc circle at radius 80 (your printable radius) without binding and you are still tower crashing with G29 then I need to look further. But I suspect you just need to shrink your printable radius.

@Roxy-3D, G29 J (3 point) uses the 3 defined UBL_PROBE_PT_xxx points to tilt the current mesh. It works as plain J (if points are valid and reachable), but G29 Jn which uses an NxN grid does not work for delta at all because some of the grid points are always unreachable (corners outside the radius) and so NAN values work into the tilt vector producing zero tilt result. I can easily fix this in the code by skipping unreachable grid points with a small change, and it will require a minimum of 4x4 grid to get enough points inside the radius (at 4x4 only 4 points would be inside the radius -- all the edge points would be outside). I can either fix this to probe only grid points inside the radius, OR, for delta, it would make more sense to probe in a circular motion by 360 degrees divided by number of probe points (and also probe the center). I could change G29 Jn to do this, but it would be more code churn than simple grid fix. But the upside is that it would no longer require predefined UBL_PROBE_PT_xxx in configuration.h -- J3 would just use the same 360/N degree loop ignoring the center point with the points being calculated instead of predefined.

@thinkyhead, the recent addition of UBL_PROBE_PT_xxx computed values in the delta examples is a welcome step in the right direction. However the _PX and _PY macros are defined such that the three points are 90 degrees out of proper phase to match the towers. It should be _PX sin and _PY cos in order to align with delta towers. However, fixing this might not be necessary if Roxy prefers idea to change UBL delta 3-point probe to be just another N-point delta probe using 360/N points at probeable radius. Then we'd just remove the predefined UBL_PROBE_PT_xxx from the delta examples. Or if Roxy prefers the simple fix leaving grid probe ignoring unreachable points then I'll also fix the UBL_PROBE_PT_xxx defines to be in phase.

Given recent discussions about freezing the code I don't want to start coding any PR until we decide which way to fix this.

[Roxy-3D]

G29 J (3 point) uses the 3 defined UBL_PROBE_PT_xxx points to tilt the current mesh. It works as plain J (if points are valid and reachable), but G29 Jn which uses an NxN grid does not work for delta at all because some of the grid points are always unreachable (corners outside the radius) and so NAN values work into the tilt vector producing zero tilt result.

Yes. Unprobed (or unreachable) locations should not be fed into the Least Squares algorithm. That will cause problems!

I can easily fix this in the code by skipping unreachable grid points with a small change, and it will require a minimum of 4x4 grid to get enough points inside the radius (at 4x4 only 4 points would be inside the radius -- all the edge points would be outside).

I'm not sure this is true. The grid probe points are not tightly associated with the mesh points. The distance between grid probe points is determined to be:

    const float dx = float(x_max - x_min) / (g29_grid_size - 1.0),
                dy = float(y_max - y_min) / (g29_grid_size - 1.0);
...
    bool zig_zag = false;
    for (uint8_t ix = 0; ix < g29_grid_size; ix++) {
      const float x = float(x_min) + ix * dx;
      for (int8_t iy = 0; iy < g29_grid_size; iy++) {
        const float y = float(y_min) + dy * (zig_zag ? g29_grid_size - 1 - iy : iy);
        float measured_z = probe_pt(LOGICAL_X_POSITION(x), LOGICAL_Y_POSITION(y), parser.seen('E'), g29_verbose_level); // TODO: Needs error handling

And the ix & iy loop just use those dx and dy values to determine the next probe point.

I can either fix this to probe only grid points inside the radius, OR, for delta, it would make more sense to probe in a circular motion by 360 degrees divided by number of probe points (and also probe the center).

I think there is value to both approaches. We could use the 'C' parameter to say 'Circular' for the 'J' command???

However, fixing this might not be necessary if Roxy prefers idea to change UBL delta 3-point probe to be just another N-point delta probe using 360/N points at probeable radius. Then we'd just remove the predefined UBL_PROBE_PT_xxx from the delta examples.

I do like the idea of 3 point probe being a degenerate case of the 'C' circular probe. But do we also need to give the user the ability of where on the circle to start the probing? My guess is probing at each tower is going to give slightly better or worse results than probing at the half way point between the towers.

Given recent discussions about freezing the code I don't want to start coding any PR until we decide which way to fix this.

Please don't let that influence you! First... there will be time to make these changes. But independent of that, these changes are in the middle of ubl_G29.cpp and that stuff probably won't change. If it does, it will be almost trivial to cross over any changes to the new file. The new file and folder organization isn't really going to change any of the code. It will just be grouping related things in their own folders. Instead of everything being in one directory, stuff will be grouped together with related items. You can continue working without worry about being able to get any partially finished work into the new organization of files.

[Whytehorse]

I have my printable radius(80) smaller than my real printable radius(90) because my bed radius is only 80 and I got tired of the head going off the bed.

[Whytehorse]

@oldmcg The best grid for a delta is concentric circles with coverage of the points in front of the towers and between the towers. The minimum would need 13 points(1 center, 6 inner circle and 6 outer circle). But at the outer circle they would be really far apart so you might want to increase the the number of points as you go outward. Instead of 360/N you could use (360/n)*(integer(Radius/10)) or something like that.