V2.0 of UBL now available

[Roxy-3D]

Many small fixes for annoying issues, including the z_offset problem.

Most of the changes are for the purpose of speeding up the code paths in preparation for bringing the UBL system up on Delta printers.

You can get it here: https://github.com/MarlinFirmware/Marlin/tree/devel-ubl

[kmbecker13]

Great! @Roxy-3D Quick question on the G29 P3 command...is that required for a successful mesh? I'm somewhat confused on what areas it fills in, is it the edges of the bed or areas that may not have been probed during the P2?

Haven't been using it and am curious if i should be. My current process is to do a G29 P1, then P2 to get the un-probable areas and then right into a G26 to see how it looks. G29 P4 from there as needed based on the G26.

[Roxy-3D]

I'm on the way out the door... But the quick answer is nothing is required. If you have unprobed mesh points, the system will default those to 0.0000 However, you should fill in the mesh points one way or the other. You can Manually Probe or you can fill with a constant (P2 and P3)

What you really want to do is get to the point where you can do a G26 across the entire bed, because that lets you use the built in Mesh Editor (G29 P4 R M)

With that, you can get the Mesh perfect in 1 or 2 iterations.

(Be sure to save your perfect mesh with a G29 S1 (or some suitable number) so it is available for use later!)

[kmbecker13]

Thanks @Roxy-3D - playing with this now and it seems like the global variables use over 100% of dynamic memory available (8202 bytes)? I think i might be missing something so i'll hold off on making a new issue for this..

[printerguykw]

awesome, going to try this version soon.

[Roxy-3D]

playing with this now and it seems like the global variables use over 100% of dynamic memory available (8202 bytes)?

I can't say without doing some work... But that surprises me. I did bump up the depth of the planner block buffer from 16 moves to 32 moves deep. At least with a 20x4 LCD display, there should be just under 2KB of RAM free. If you have a graphics display, you may need to move that back down to 16 deep. (It is in Configuration_adv.h)

(These Graphic displays are a nuisance! They burn up the CPU and they eat up memory. )

If you can't link and flash because you are out of memory... Please change these lines (in Configuration_adv.h) back to this:

// The number of linear motions that can be in the plan at any give time.
// THE BLOCK_BUFFER_SIZE NEEDS TO BE A POWER OF 2, i.g. 8,16,32 because shifts and ors are used to do the ring-buffering.
#if ENABLED(SDSUPPORT)
  #define BLOCK_BUFFER_SIZE 16   // SD,LCD,Buttons take more memory, block buffer needs to be smaller
#else
  #define BLOCK_BUFFER_SIZE 16 // maximize block buffer
#endif

When I get confirmation that lets you continue, I'll update the main code base to make that the default.

[kmbecker13]

Yep that worked, with a 7 x 7 mesh i still have over 1KB of free RAM and it compiled!

However i had to select 1 extruder to get it to compile instead of my normal 2 (it gave another error saying "Marlin_main.cpp:6298: error: 'fade_scaling_factor_for_Z' was not declared in this scope" when i try to use 2 extruders)

[adamfilip]

I had to set buffer back to 16 at 32 it only had 6 bytes free

[adamfilip]

@Roxy-3D im Running a G29 P1 M now, ive noticed it still pausing once in a while. for what feels like 30 seconds. think this is buffer or free memory related?

[kablam]

I'm getting this when i try to compile in latest arduino software.

Arduino:1.6.11 (Windows 10), Kort:"Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

sketch\Marlin_main.cpp: In function 'void gcode_M47()':

Marlin_main.cpp:3672: error: 'blm' was not declared in this scope

  xi = blm.get_cell_index_x(x);
       ^

sketch\Marlin_main.cpp: In function 'void process_next_command()':

Marlin_main.cpp:6461: error: 'gcode_G25' was not declared in this scope

           gcode_G25();
                     ^

exit status 1
'blm' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

[Roxy-3D]

I had to set buffer back to 16 at 32 it only had 6 bytes free

OK... The default setting is back at 16. That really should be enough. I did some timing tests to see what was going on and most of the time is spent waiting for the buffer to open up so another move can be put in the list. In other words, most of the time the system is deep inside the planner calling idle() while it waits for room.

i'm Running a G29 P1 M now, i've noticed it still pausing once in a while. for what feels like 30 seconds. think this is buffer or free memory related?

I've never seen it do that during a P1. Does it do it without the M option? I'm wondering if it is a communication problem and you are waiting for some time out condition to happen and then the serial link recovers? You can rule out free memory issues by initializing the M100 Free Memory Watcher prior to do the G29 P1 M and then ask it to give you the Memory Statistics after the G29 P1 M completes. As long as there is stack space free, it isn't a free memory related issue.

i'm getting this when i try to compile in latest arduino software. @kablam gcode_G25() is for Delta's to help physically level the bed. It was working in previous versions of my code, but I'm pretty sure it is going to need to be brought up to date because of all the changes to Marlin's lower level planner and stepper code. Can you attach your Configuration.h file and I'll duplicate the problem and remove the dependency. I can tell you it should not be getting pulled into the compilation unless you are on a Delta. And I have not even started the work to get Delta's going yet (but I'm close to doing that).

[adamfilip]

Weird result when generating mesh.. see image.. started raising Z gantry alot

But some good news.. I reran my M48 V4 P10 with my Hinged Z probe and here are my results :)

READ: Mean: -0.997358 READ: Standard Deviation: 0.000677

[adamfilip]

Video showing pauses https://youtu.be/Hm4IM9pzTV4

[Roxy-3D]

But some good news.. I reran my M48 V4 P10 with my Hinged Z probe and here are my results :) READ: Mean: -0.997358 READ: Standard Deviation: 0.000677

That -86.22 is concerning. I'm just using the standard probe_pt() routine. There isn't much math that can be doing that in the UBL code. One thing I can do is add some sanity checks to make sure the numbers are plausible.

It looks like you should shift your Z_PROBE_OFFSET_FROM_EXTRUDER by 1.0 mm But that Standard Deviation of .0007mm is very good, especially since the whole nozzle mechanism is moving and having to come back into position.

[Roxy-3D]

However i had to select 1 extruder to get it to compile instead of my normal 2 (it gave another error saying "Marlin_main.cpp:6298: error: 'fade_scaling_factor_for_Z' was not declared in this scope" when i try to use 2 extruders)

@kmbecker13 I'll see if I can resolve the multiple extruder issue this morning. It shouldn't be too big of a deal to get that turned back on and working. The bigger issue is there has been ZERO testing of multiple extruders within UBL. So keep an eye on it and make sure it is behaving correctly once I get it to compile clean.

[Roxy-3D]

@kmbecker13 If you pull down the latest code... It should compile with multiple extruders enabled.

[Roxy-3D]

Video showing pauses https://youtu.be/Hm4IM9pzTV4

@adamfilip Wow! That is a nice machine! Its bed is huge. I see why you want to use a large mesh to level it!

The interesting thing in that video at about 1:08 is it pauses after the first trigger of the probe. It pauses before it does the 2nd, slower speed measurement. That implies it is in the middle of the probe_pt() routine when it happens. I think that rules out a communication issue because there is no chit chat between Marlin and the host at that point. (At least, that is my best guess but there is a Verbose level passed into probe_pt() )

How often does this pause happen? It would be nice if it happens every time you do a G29 P1. But here is something else that I'm wondering about. Under certain conditions the probe_pt() routine will return Not-a-Number. That happens when it has problems deploying or stowing the probe. I'm wondering if that is where that crazy -86.22 number came from. I'm wondering if that number is not being interpreted correctly.

We have a couple of options. One option is to turn on the DEBUG_LEVELING_FEATURE to get more information. We can also uncomment the various Checkpoint # messages so we see how far through the probe_pt() routine it is getting. With the extra information, that should narrow the field of things for us to look at to find the problem.

I haven't dug in to understand things yet. But you have a very special probe. Besides triggering at a positive Z_PROBE_OFFSET_FROM_EXTRUDER number, you don't have any stow or deploy action. I'm wondering if we are going to find there is some thing unanticipated. Once we see how far into probe_pt() it is getting before the pause happens... Things will start to make sense.

    #endif
    feedrate = XY_PROBE_FEEDRATE;
//SERIAL_PROTOCOLPGM("Checkpoint #0\n");
    do_blocking_move_to_xy(x - (X_PROBE_OFFSET_FROM_EXTRUDER), y - (Y_PROBE_OFFSET_FROM_EXTRUDER));
//SERIAL_PROTOCOLPGM("Checkpoint #1\n");

    #if ENABLED(DEBUG_LEVELING_FEATURE)
      if (DEBUGGING(LEVELING)) SERIAL_ECHOPGM("> ");
    #endif
//SERIAL_PROTOCOLPGM("Checkpoint #2\n");
    if (DEPLOY_PROBE()) return NAN;
//SERIAL_PROTOCOLPGM("Checkpoint #3\n");

    float measured_z = run_z_probe();
//SERIAL_PROTOCOLPGM("Checkpoint #4\n");

    if (stow) {
      #if ENABLED(DEBUG_LEVELING_FEATURE)
        if (DEBUGGING(LEVELING)) SERIAL_ECHOPGM("> ");
      #endif
      if (STOW_PROBE()) return NAN;
    }
    else {
      #if ENABLED(DEBUG_LEVELING_FEATURE)
        if (DEBUGGING(LEVELING)) SERIAL_ECHOLNPGM("> do_probe_raise");
      #endif
//SERIAL_PROTOCOLPGM("Checkpoint #5\n");
      do_probe_raise(Z_RAISE_BETWEEN_PROBINGS);
    }
//SERIAL_PROTOCOLPGM("Checkpoint #6\n");

[adamfilip]

I set it up to 5x5 grid because its faster lol. I was able to do the full grid.. without any manual entry needed Woohoo! (Helps that I have 0 XY probe offset) with a 5x5 i didnt run into pauses, maybe it uses less memory and that helps I ran a M100 I before and M100 F after Before the G29 P1 M free memory was 1748 b and after it was 1384 b, and thats only a 5x5 grid

i believe the pausing is related to the weird numbers.. seems like after it pauses they start to occur

[adamfilip]

Wow! That is a nice machine! Its bed is huge.

@Roxy-3D Thanks!, and i will be increasing it to 300x600 soon too.. so i really need to get the UBL working :)

[Roxy-3D]

with a 5x5 i didnt run into pauses, maybe it uses less memory and that helps

5x5 will use less memory. But as long as there is enough free memory, it shouldn't matter how much memory is free. Each location uses 4 bytes. So a 10x10 will consume 400 bytes of memory. A 5x5 will only eat up 100 bytes.

I ran a M100 I before and M100 F after Before the G29 P1 M free memory was 1748 b and after it was 1384 b, and thats only a 5x5 grid.

So... you should still be over a 1KB of free memory with a 10x10. I don't think it is free memory that is causing problems. Instead... with a bigger mesh, you are probing more points. It maybe the bigger mesh just gives more opportunity for the problem to manifest itself.

i believe the pausing is related to the weird numbers.. seems like after it pauses they start to occur

This is very possible. Especially because there are error conditions where I have it returning NAN. But if that is the case, there is something else going on. The reason I say that is once a number becomes NAN, it should propagate through further computations. Officially, you are only supposed to have to check for NAN at the very end of calculations. (I'm not sure I check at all, but the SERIAL_OUTPUT routines should print out NAN. I'll have to verify that.) And very literally, those '.' in the map are NAN values. If the probe_pt() routine returns NAN and ultimately the number gets stored in the Mesh, it should still be NAN. It should display as '.' I'm sure it will all make sense once we figure it out. But right now, I'm not sure what is going on.

I think we may be running into an issue in the stow or deploy routines. Let's get the extra debug stuff turned on and see where the pause happens.

[adamfilip]

ok i set it back to a 10x10 and the errors problem started happening after 20 probings i enabled all checks.. and it seemed to start hanging on check 3

[Roxy-3D]

Did you notice you have a couple of outlier points on the left side? (of the 5x5 Mesh) At the top left, you have 1.2mm surrounded by almost 0.0 numbers. I wonder if that is an issue with the bed wrapping at a mounting point? And then lower down on the left side you have a -.72 number with a .404 number right next to it.

I think you would benefit from going even higher than a 10x10 Mesh.

[adamfilip]

here is the 10x10 i just did

[adamfilip]

it started with the -2.14591 in upper right

[Roxy-3D]

i enabled all checks.. and it seemed to start hanging on check 3

//SERIAL_PROTOCOLPGM("Checkpoint #2\n");
    if (DEPLOY_PROBE()) return NAN;
//SERIAL_PROTOCOLPGM("Checkpoint #3\n");
    float measured_z = run_z_probe();
//SERIAL_PROTOCOLPGM("Checkpoint #4\n");

So... It is inside of run_z_probe() when it pauses. I guess we should modify run_z_probe() to have lots of check point info so we can see where in it the problem happens. Can you put similar lines of code every couple lines in run_z_probe() ? Just add your own flavor of message:

SERIAL_PROTOCOLPGM("in run_z_probe() #1\n");

at various points?

[adamfilip]

I added a bunch of comments but now im getting a compile error "expected constructor, destructor, or type conversion before '(' token"

define SERIAL_PROTOCOLPGM(x) serialprintPGM(PSTR(x))

here is the code i added comments too

``` cpp // #if ENABLED(UNIFIED_BED_LEVELING_FEATURE) // planner.bed_level_matrix.set_to_identity(); // #endif feedrate = homing_feedrate[Z_AXIS]; // Move down until the Z probe (or endstop?) is triggered SERIAL_PROTOCOLPGM("in run_z_probe() #A Move down until the Z probeis triggered\n"); float zPosition = -(Z_MAX_LENGTH + 10); line_to_z(zPosition); stepper.synchronize(); // Tell the planner where we ended up - Get this from the stepper handler SERIAL_PROTOCOLPGM("in run_z_probe() #B Tell the planner where we ended up\n"); zPosition = stepper.get_axis_position_mm(Z_AXIS); planner.set_position_mm( current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS] ); // move up the retract distance SERIAL_PROTOCOLPGM("in run_z_probe() #C move up the retract distance\n"); zPosition += home_bump_mm(Z_AXIS); line_to_z(zPosition); stepper.synchronize(); endstops.hit_on_purpose(); // clear endstop hit flags // move back down slowly to find bed SERIAL_PROTOCOLPGM("in run_z_probe() #D move back down slowly to find bed\n"); set_homing_bump_feedrate(Z_AXIS); zPosition -= home_bump_mm(Z_AXIS) * 2; line_to_z(zPosition); stepper.synchronize(); endstops.hit_on_purpose(); // clear endstop hit flags // Get the current stepper position after bumping an endstop SERIAL_PROTOCOLPGM("in run_z_probe() #E Get the current stepper position after bumping an endstop\n"); current_position[Z_AXIS] = stepper.get_axis_position_mm(Z_AXIS); #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) DEBUG_POS("run_z_probe", current_position); #endif #endif // !DELTA SYNC_PLAN_POSITION_KINEMATIC(); feedrate = old_feedrate; return current_position[Z_AXIS]; } SERIAL_PROTOCOLPGM("in run_z_probe() #F\n"); void do_blocking_move_to_xy(float x, float y, float feed_rate) { do_blocking_move_to(x, y, current_position[Z_AXIS], feed_rate); } SERIAL_PROTOCOLPGM("in run_z_probe() #G\n"); // // - Move to the given XY // - Deploy the probe, if not already deployed // - Probe the bed, get the Z position // - Depending on the 'stow' flag // - Stow the probe, or // - Raise to the BETWEEN height // - Return the probed Z position // float probe_pt(float x, float y, bool stow, int verbose_level) { #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) { SERIAL_ECHOPAIR(">>> probe_pt(", x); SERIAL_ECHOPAIR(", ", y); SERIAL_ECHOPAIR(", ", stow ? "stow" : "no stow"); SERIAL_ECHOLNPGM(")"); DEBUG_POS("", current_position); } #endif SERIAL_PROTOCOLPGM("in run_z_probe() #H\n"); float old_feedrate = feedrate; // Ensure a minimum height before moving the probe do_probe_raise(Z_RAISE_BETWEEN_PROBINGS); SERIAL_PROTOCOLPGM("in run_z_probe() #I \n"); // Move to the XY where we shall probe #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) { SERIAL_ECHOPAIR("> do_blocking_move_to_xy(", x - (X_PROBE_OFFSET_FROM_EXTRUDER)); SERIAL_ECHOPAIR(", ", y - (Y_PROBE_OFFSET_FROM_EXTRUDER)); SERIAL_ECHOLNPGM(")"); } #endif SERIAL_PROTOCOLPGM("in run_z_probe() #J\n"); feedrate = XY_PROBE_FEEDRATE; SERIAL_PROTOCOLPGM("Checkpoint #0\n"); do_blocking_move_to_xy(x - (X_PROBE_OFFSET_FROM_EXTRUDER), y - (Y_PROBE_OFFSET_FROM_EXTRUDER)); SERIAL_PROTOCOLPGM("Checkpoint #1\n"); #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) SERIAL_ECHOPGM("> "); #endif SERIAL_PROTOCOLPGM("Checkpoint #2\n"); if (DEPLOY_PROBE()) return NAN; SERIAL_PROTOCOLPGM("Checkpoint #3\n"); float measured_z = run_z_probe(); SERIAL_PROTOCOLPGM("Checkpoint #4\n"); if (stow) { #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) SERIAL_ECHOPGM("> "); #endif if (STOW_PROBE()) return NAN; } else { #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) SERIAL_ECHOLNPGM("> do_probe_raise"); #endif SERIAL_PROTOCOLPGM("Checkpoint #5\n"); do_probe_raise(Z_RAISE_BETWEEN_PROBINGS); } SERIAL_PROTOCOLPGM("Checkpoint #6\n"); if (verbose_level > 2) { SERIAL_PROTOCOLPGM("Bed X: "); SERIAL_PROTOCOL_F(x, 3); SERIAL_PROTOCOLPGM(" Y: "); SERIAL_PROTOCOL_F(y, 3); SERIAL_PROTOCOLPGM(" Z: "); SERIAL_PROTOCOL_F(measured_z, 3); SERIAL_EOL; } #if ENABLED(DEBUG_LEVELING_FEATURE) if (DEBUGGING(LEVELING)) SERIAL_ECHOLNPGM("<<< probe_pt"); #endif feedrate = old_feedrate; return measured_z; } #endif // HAS_BED_PROBE ```

[Roxy-3D]

The macro expansion of SERIAL_PROTOCOLPGM("something_here"); is very sensitive to mistakes.

The SERIAL_PROTOCOLPGM("in run_z_probe() #G\n"); line looks like it is outside of a function. If so, that will cause a compiler error.

If you still have problems after fixing that... I'll add debug code to the run_z_probe() routine and you can just cut and paste it from here into Marlin_main.cpp. I thought it would be easier to just have you put the debug lines in. If not, we can do it the other way.

[adamfilip]

ok well i screwed up something lol.. gotta start from scratch.. download the firmware again.. best to not let me make changes to code lol

[Roxy-3D]

ok well i screwed up something lol.. gotta start from scratch.. download the firmware again.. best to not let me make changes to code lol

These are simple changes... We should be able to get them in place without too much of a problem. Just be careful, because we don't want any 'unknown' changes! We really don't have a choice. We have to debug this on your hardware because it seems that is the only place the problem shows up.

And remember... There is a fall back position. Even if we can't figure out where the probe_pt() routine is failing, we can do a G29 P0 to zero the entire mesh, and jump straight to the G26 C P O2.5 The first iteration will probably produce a horrible Mesh Validation pattern, but at that point, you can edit it and start pushing and pulling on the Mesh points. In theory, you don't even have to automatically probe the bed.

[adamfilip]

I wonder if my rumba is glitchy. I am getting issues sometimes connecting and I need to run at 115200 baud serial

[kablam]

Roxy-3D here is my confuration.h as requested

And yes im on a Delta

Configuration.h.txt

[Roxy-3D]

I wonder if my rumba is glitchy. I am getting issues sometimes connecting and I need to run at 115200 baud serial

I've got a very low opinion of Geeetech stuff. If the Rumba board is from Geeetech, I would guess that is the source of the trouble.

I know I'm pretty sour on Geeetech, but I would rather spend $20 and have something from a totally unknown vender: http://www.ebay.com/itm/New-3D-Printer-Kit-Mega-2560-RAMPS-1-4-5X-A4988-For-Arduino-/262015070192?hash=item3d0150aff0:g:zIgAAOSwHnFV18~r

[Roxy-3D]

Roxy-3D here is my confuration.h as requested And yes im on a Delta Configuration.h.txt

I spent two weeks re-writing the mesh_buffer_line() routine to save CPU cycles. The whole intent of doing that was to free up CPU cycles so that Delta's could could benefit from the UBL System. But right now, that code lives within the Cartesian system:

#if DISABLED(DELTA) && DISABLED(SCARA)
bool prepare_move_to_destination_cartesian() {
    // Do not use feedrate_multiplier for E or Z only moves
    if (current_position[X_AXIS] == destination[X_AXIS] && current_position[Y_AXIS] == destination[Y_AXIS]) {
      line_to_destination();
    }
    else {
  #if ENABLED(UNIFIED_BED_LEVELING_FEATURE)
   mesh_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS],
                          (feedrate*(1.0/60.0))*(feedrate_multiplier*(1.0/100.0) ), active_extruder);
     return false;
  #else
        line_to_destination(feedrate * feedrate_multiplier / 100.0);
  #endif
    }
    return true;
  }
#endif // !DELTA && !SCARA

And actually, the whole reason I started this effort was to help my low quality Geeetech Delta printer. So, I'm pretty serious about getting the UBL System up and running at a 15x15 Mesh Resolution on my Delta.

But it isn't ready yet. Realistically... I'm guessing we are 6 to 8 weeks away from the Delta version. First I need to bring up the G29 and G26 portions of the code and get those working with Delta. That probably won't be too bad. And then I need to send all of the Delta requests through that code up above in this post so the new mesh_buffer_line() is breaking the requests apart on Mesh Line boundaries.

The first thing that has to happen is I have to make it so the UBL System lets you have +/- numbers for the X_MIN and Y_MIN values. (Because Delta's always have (0,0,0) at the center of the bed)

Sorry... You'll have to be patient. This Delta stuff gets very complicated. It takes time to work through.

[adamfilip]

hmm.. ive noticed that my Stepper driver for the Z is very hot.. perhaps it was loosing position after a while , making the weird Map results.. I will adjust and rerun. and let you know..

[kablam]

No problem i can be patient :) keep up the good work. I just wanted to let you know about the compilation error i found

[Roxy-3D]

hmm.. ive noticed that my Stepper driver for the Z is very hot.. perhaps it was loosing position after a while , making the weird Map results.. I will adjust and rerun. and let you know..

I just re-read what your wrote. I was thinking the Z-motor was getting too hot. But you said the 'Stepper Driver' was very hot. YES! They will shut down and lose position if they get too hot. That would explain everything. That 30 second pause would be the time it takes the chip to cool down and decide it should start working again. And of course, during that whole time, Marlin has been trying to move the stepper motor to get the probe to fire. And because the motor isn't moving, the probe never fires so Marlin keeps trying to move more and more.

The good news is, maybe you don't have to replace your RUMBA board???

[adamfilip]

@Roxy-3D that was the problem, once i adjusted the voltage and added a fan.. the problem went away.. i did a 10x10 grid with no pauses or weird values.

I have one question related to the area that it will probe. What specified area will UBL probe?

  // Edge boundaries for Grid Based Mesh Leveling
  #define LEFT_PROBE_BED_POSITION 10
  #define RIGHT_PROBE_BED_POSITION 280
  #define FRONT_PROBE_BED_POSITION 10
  #define BACK_PROBE_BED_POSITION 280

or

// Travel limits after homing (units are in mm)
#define X_MIN_POS 10
#define Y_MIN_POS 10
#define Z_MIN_POS 0
#define X_MAX_POS 280
#define Y_MAX_POS 280
#define Z_MAX_POS 300

[Roxy-3D]

Can the area being probed be set to the same as the below instead of the travel limits after homing?

// Edge boundaries for Grid Based Mesh Leveling
#define LEFT_PROBE_BED_POSITION 10
#define RIGHT_PROBE_BED_POSITION 280
#define FRONT_PROBE_BED_POSITION 10
#define BACK_PROBE_BED_POSITION 280

Maybe. I would have to look at it more closely to give an informed answer. That might be possible as an option we turn on. It maybe the case we can add an option and just bound the area that gets probed to that box. Mostly, I left those values in place because they are going to be useful to do a grid based tilt of the Mesh. But I guess we don't have to limit their use to that.

I've been kind of working on the code to do the opposite. I was trying to make the edge of the mesh go to the very edge of the printable space. And in fact, I have to go past that in the case of Delta's because there will be parts of the DELTA_PRINTABLE_RADIUS that won't have a mesh line to interpolate against if I don't allow mesh points off the printable area.

With that said... Shrinking the printable area should be possible. Let me look at it and see how it can be done in a clean manner. Can you tell me why you want to shrink the printable area? Are the edges of your bed a little warped?

[adamfilip]

I need to shrink it as i have Clips in the way holding the glass down.

[kmbecker13]

@adamfilip I've done the following for mine to shrink the mesh slightly to avoid the bed edge.

#if ENABLED(UNIFIED_BED_LEVELING_FEATURE)
#define MESH_MIN_X X_MIN_POS + 5
#define MESH_MAX_X X_MAX_POS - 5
#define MESH_MIN_Y Y_MIN_POS + 5
#define MESH_MAX_Y Y_MAX_POS - 5

[Roxy-3D]

I've done the following for mine to shrink the mesh slightly to avoid the bed edge.

That is probably a good way to address this need. But I better go through the code and make sure all of the loops use the 'right' boundary.

[adamfilip]

Did the Mesh, did a G29 Z to set Offset.. adjusted it down to -1.2 when it touched the bed.. when I send a job down to the printer its about 1mm higher then it should be.

Gcode Z height is set to 0

define Z_PROBE_OFFSET_FROM_EXTRUDER 2

[Roxy-3D]

@adamfilip it would be helpful to see your current Mesh. Does shifting the z_offset give you any control over things? That should work now. What about the Z-BABYSTEPPING? Does it do anything? 1MM is too much to Baby Step, but it would be good to know if it is possible to use it because that helps us know what parts of the system work together correctly.

[kmbecker13]

@Roxy-3D was the G26 changed much? I'm seeing some really weird behavior including large z-increases during the G26, mostly on the X+ side of my bed...sometimes with the Z axis going all the way to around +175ish in the middle of the print!

It's happened twice now and i confirmed that my mesh doesnt have any crazy numbers in it that could be causing it (mesh is from -1 to +1 z height).

[adamfilip]

Z babystepping works.. even over 1mm G29 Z didnt seem to change things.

[adamfilip]

here is my current mesh and info

[Roxy-3D]

@kmbecker13

was the G26 changed much? I'm seeing some really weird behavior including large z-increases during the G26, mostly on the X+ side of my bed...sometimes with the Z axis going all the way to around +175ish in the middle of the print!

Yes. In order to speed up the drawing of the circles, it no longer sync's the position of current with destination. I did test that a lot on my printer for correct operation. But apparently, I need to take another look at that.

@adamfilip There are two flavors of G29 Z Can you try G29 Z -1.0 or G29 Z +1.0 and see if that helps? If that lets you control the nozzle distance it will be easier to hunt down the fix. (And in the mean time, you can just specify the correct number (and not +/- 1.0 )

@adamfilip Did G29 work correctly for you?

@adamfilip Also, did you notice that -1.88931 number in the second column? That can't be real with the numbers around it being closer to 0.0 ? Maybe the probe mis-fired? Or maybe you had some plastic stuck to the bed at that location (except in that case the number would be positive and not negative???) Well, you can move the nozzle to that location and edit that point into compliance!

[adamfilip]

G29 Z seemed to work this time.. not sure why it didnt seem to work previously.

[Roxy-3D]

G29 Z seemed to work this time.. not sure why it didnt seem to work previously.

Well... That -1.889 in your mesh concerns me too. It is almost like the probe mis-fired.

Did you get a chance to try G29 Z -1.0 To manually force an offset?

[kmbecker13]

I just tried a G29 Z 0.050 and it seems to have worked, but my G26 is still coming out weird. Even the portions where the z doesn't go crazy, the extrusion seems off and i don't get anything close to usable. Printing a regular file seems to work ok, but the mesh isn't great and needs to be adjusted.

I think ill try printing a large square and adjust the mesh based on that with the G29 P4 for now.

Edit: Update, i was able to tune the mesh decently by printing a large 1-layer square with 0 top & bottom layers, giving some nice diagonal lines as the infill. I tuned the mesh height with the babystepping and then adjusting the bed z on the LCD to match and save it. Right now my first real print seems to be going great without any adjustments to the z-height!!

[adamfilip]

I redid the G29 P1 M, created a new mesh.. this time only one spot was out of whack by about 1mm i used a P4 30 60 to adjust that spot.

can there be a way to invert the Map, currentyly it shows the 0,0 origin as the bottom left but with my machine its top left.. so its disorienting.

also if for each column and row, the X position and Y position could be listed. this would make it much easier to know that I need to adjust point X30 Y60, without guessing on the point spacing, and doing math in your head. I have attached the idea based on the current map.