Marlin: 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() #1n");

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

//      #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() #Gn"); 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.

[Roxy-3D]

@kmbecker13 Please go to the end of the move_to() function in G26_Mesh_Validation_Tool.cpp. Please add those two lines after the call to mesh_buffer_line() at the very end of the function and give that a try. It will slow things down a little bit. But I'm hoping that it will complete the pattern correctly. The thing is, once the nozzle is at the correct height it shouldn't be going up to +175mm. Something strange is going on.

void move_to( float x, float y, float z, float e_delta) {
...
  mesh_buffer_line( destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feed_value, 0, 0xffff, 0xffff );
  stepper.synchronize();
  set_destination_to_current();
}

[Roxy-3D]

@adamfilip

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

All of that is possible. But for now, you can print a Map and see which Mesh Point is closest to the nozzle. You can move (as best you can) a little bit in both X & Y and when you reprint the map, you can look for the Mesh Point that is bracketed with [0.000]. You should be able to position the nozzle exactly where you want a subsequent operation to happen whether it is an Invalidate, or Fill or what ever. So for that bad point... Move the nozzle until you see brackets around it. Then Invalidate it and Fill it. Or you can just Edit it.

[jstefanop]

Does UBL still require an attached LCD display to work, or can it work with just gcode commands?

[Roxy-3D]

Does UBL still require an attached LCD display to work, or can it work with just gcode commands?

Yes, it still requires an LCD Display. It will be a while before that requirement is relaxed. I want to get the Delta's going first. After that, the LCD Display requirement can be eliminated.

[adamfilip]

im surprised anyone has a 3d printer without a lcd

[jstefanop]

Well it has an LCD, its just connected to a Pi which controls the printer via octopi...much better solution than an LCD connected directly to rambo. Only in rare cases where a firmware feature does not have a gcode command to run is it an issue.

[kmbecker13]

@jstefanop this is certainly one of those cases, unfortunately. You really need the LCD to jog the machine around and also to take advantage of things like z-babystepping.

[Roxy-3D]

For $10 (including shipping) you can get a 20x4 display on eBay. It really is worth it. If you have a 10 x 10 Mesh, the LCD Panel is very valuable because it lets you easily edit portions of it to get things perfect. But eventually, the system will work without an LCD Panel.

[kmbecker13]

@Roxy-3D Adding those two lnies didn't seem to change the G26 behavior, i still see crazy Z increases on the X+ side of my bed.

I did notice my G26 is slightly different from what you showed (the first line at the end), this what i have now at the end of the move_to function

mesh_buffer_line( destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feed_value, 0 );
stepper.synchronize();
set_destination_to_current();

[Roxy-3D]

I did notice my G26 is slightly different from what you showed (the first line at the end), this what i have now at the end of the move_to function

Yes, your version is correct. I cut and pasted the wrong thing. I was mostly trying to get the stepper.synchronize(); line and the set_destination_to_current(); line.

Sorry for the confusion.

[sarf2k4]

Hi, I am quite interested in this ubl, because my printer here the problem, marlin will increase z on x- while decrease z on x+ side, in fact the layer on x- is too high and not sticking while x+ is to thin; nozzle pressing on the bed

I might be wrong about asking this, is there a short guide on how to set up the ubl? I've done with the initial config.h settings prior to my machine, just the ubl setup

[kmbecker13]

@sarf2k4 I think the best guide is found in the Readme of the UBL branch
here on Github.

As an FYI - I am planning to make a "users guide" for implementing UBL in
the near future to help with this sort of question, as I think many people
could benefit from it. Just trying to get my G26 running well so I can show
how the whole process should work :)

On Sep 21, 2016 8:28 AM, "sarf2k4" [email protected] wrote:

Hi, I am quite interested in this ubl, because my printer here the
problem, marlin will increase z on x- while decrease z on x+ side, in fact
the layer on x- is too high and not sticking while x+ is to thin; nozzle
pressing on the bed

I might be wrong about asking this, is there a short guide on how to set
up the ubl? I've done with the initial config.h settings prior to my
machine, just the ubl setup

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/4828#issuecomment-248647977,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASdm7Ic-xd5v18WSlT_9dcRDXpq5rboHks5qsU0jgaJpZM4J_wQw
.

[sarf2k4]

okay, I think I did post at least 2 issues regarding the rc branch's abl that my issues often not really mechanical problem which I did rectify by making them perpendicular, still persist.

Anyway, I am going to try the ubl branch tonight hopefully it all goes well, but that need to heat up the bed of my preferred print temperature also right during the probing?

[Roxy-3D]

Just trying to get my G26 running well so I can show how the whole process should work :)

@kmbecker13 I'm going to add some verbose debug code to G26 so we can get a better idea of what is happening on your system.

[OrbitAVI]

Gonna try this out tonight! Thanks!

[kmbecker13]

@sarf2k4 when you do the G29 P1, you are having the printer construct a mesh that essentially measures the relative height of all mesh points compared to each other. This means that as long as your bed is at a uniform temperature when doing this (either hot or cold) you will get a good mesh.

To set the proper Z-offset/zero the mesh to the correct overall, absolute, height - you should have both the bed and nozzle at close to their printing temperatures to compensate for things like nozzle expansion and potential probe changes (i.e with an inductive probe). This would apply to the G29 Z for example, where you are adjusting the height of the entire mesh to the correct height.

[Roxy-3D]

@kmbecker13 @adamfilip

If you pull down the latest devel_ubl code, there is very detailed, verbose debugging information available. Please pull it down and see if you see the same error you previously saw. For adamfilip, that is the weird Z-Raise when it changes layer levels. For kmbecker13 it is the big raise during the G26 Mesh Validation Pattern print.

Assuming the error is still there, it would be very helpful for you to video the printer doing the wrong thing. Here is how you capture the debug information:

• Reset your printer. It probably is helpful to increase the right side communication box if you are using PronterFace. It should be very wide because the debug text creates long lines of text.
• M47 (issue an M47 to your printer. It should confirm debugging is turned on.)
• Start your print (or G26 Mesh Validation Pattern)
• Please video it doing the wrong thing
• After it does the wrong thing, let it do one or two movements. (I want to make sure I get the full debug info for the move including any clean up moves.)
• Press Reset on your controller board to stop everything where it is at.
• Upload the video.
• Cut and Paste as much text is available and post it with the Video URL here!

THANKS SO MUCH FOR THE HELP!

[adamfilip]

Your wish is my command :)
here you go

TW_Calibration_Cubes debug.txt
Serial Monitor output.txt

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

[Roxy-3D]

Thank You! That very possibly will be enough to figure out what is causing it.

I wish I had a printer like that! That printer is wonderful.

I'll start digging through the log file.

[adamfilip]

one extra question. When I print my first layer is good. I have a Z offset of -2.2 but if i run a G1 Z0
i assume the head would touch the bed.. but it doesnt.. it is like 3-4mm away
what command will bring it down to the bed so i can check the gap is correct?

[kmbecker13]

@Roxy-3D Working on this now, but i noticed that when i compile with the new changes (and my stupid graphics LCD) i only have 203 bytes left over (3%) for local variables...i'm assuming this will cause some problems?

[Roxy-3D]

@adamfilip
You should be able to do a normal GCode command. You should be able to say: G1 X50 Y50 Z50 to have each axis go to to (50,50,50). But if you just want to move the Z, you should be able to do G1 Z1.0 to go 1.0 mm above the bed.

The error must be happening in one of the code paths I didn't expect. I've added a little more debug code. I don't need the video re-done. (That video was very helpful!) But if you could load the latest firmware and do the same thing again, I should be close. (It is possible that it won't do it any more... But I expect it is going to.)

@kmbecker13 203 bytes sounds awful light for free RAM. However, the debug code really shouldn't eat up any RAM. I wonder if you always had very low RAM? It would be good to go back to your previous firmware image and verify how much free RAM you have. Did you get the 203 byte number from M100? Or more likely from the linker? If it is from M100, at least the system is up and running when it said that. But still... That is very little, and most likely G26 is going to eat up that much and more. That might explain the unexpected movements.

Depending on what you have your Mesh dimensions set at, you can pick up some space by just dropping from say 10 x 10 down to 7 x 7. You can also go into Configuration_adv.h and change the #define BLOCK_BUFFER_SIZE 16 down to 8. That is kind of light, but it will free up a bunch of memory so we know we are not getting corruption.

[kmbecker13]

@Roxy-3D I got the 203 byte number from the Arduino IDE when compiling. My old firmware gives a value of 991 bytes free for local variables when looking in the same spot.

M100 on my old firmware (UBL 2.0, without the debug code) gives this:

READ: Initializing free memory block.
READ:
READ: __brkval : 7717 or 0x1E25
READ:
READ: Stack Pointer : 8668 or 0x21DC
READ: 884 bytes of memory initialized.
READ:
READ: Done.

[Roxy-3D]

Oh! You know what? I did eat up that memory. I didn't use the PGM version of the SERIAL_ECHO commands. Let me see if I can give back some of the memory.

[adamfilip]

Ok i updated and reset. and Ran M47 Homed Z,
sent G1 Z0 and it was several mm above bed.. I bet its exactly my current offet above.. which offset is -2.2
perhaps its reading the offset backwards..
G1ZO.txt

[adamfilip]

Configuration.txt
here is my config file.. incase its useful

[adamfilip]

Currently in the confi.h i set my #define Z_PROBE_OFFSET_FROM_EXTRUDER 3
and then i set my G29 Z -2.2

should i just set my Z_PROBE_OFFSET_FROM_EXTRUDER to 0.8 and hope my Z offset can remain 0?
can i also predefine my z offset in config.h. i dont see a spot for it

[Roxy-3D]

@kmbecker13 OK, I gave back enough memory you should be OK. Go ahead and download, build, and flash it...

Thanks @adamfilip I'm looking at things now.

should i just set my Z_PROBE_OFFSET_FROM_EXTRUDER to 0.8 and hope my Z offset can remain 0?
can i also predefine my z offset in config.h. i dont see a spot for it

Yes. I think so. z_offset came about because of the original Mesh Bed Leveling system. There was never a configuration parameter for it. It is possible I'm inverting the sign (direction) of the z_offset. I'll have to check that. But I want to get rid of that crazy layer change Z movement first.

[Roxy-3D]

@adamfilip That log file is missing all of the layer changes that were in the other one. Is it possible you didn't do a M47 prior to starting the print? It looks like it finished at a height of 14.78mm high. But there were no layer changes in the file before that. (The last log file had much more information in it!)

Depending upon how much you can capture of the debug data... It maybe you have to stop it 5 seconds after the up, down, up, down completes. (maybe just as it makes that first turn after not drawing that first line correctly).

[adamfilip]

didnt do a print. just did a homing. and G1 Z0 thought thats why you wanted

i will print and send you the results..

[Roxy-3D]

didnt do a print. just did a homing. and G1 Z0 thought thats why you wanted
i will print and send you the results..

Thanks! I need to see the debug info for that funny up and down in the corner as it changes layers.
Sorry for the hassle!!!

[adamfilip]

hmm. this is getting weird..
i printed again.. but this is after i set my

define Z_PROBE_OFFSET_FROM_EXTRUDER 1

and then i set my G29 Z 0

I dont see it doing the raising anymore.
Z offset was making it do the additional raise??

0OFFSET.txt

[Roxy-3D]

I did make a couple of small changes... I may have eliminated the funny up and down problem you had in the layer change. (That issue had nothing to do with the Z_Offset issue!) But we may still have the Z_Offset issue. If you can get a print to work by adjusting the Z_Offset, that would be very helpful. It maybe shifting the Z height in the wrong direction. I don't know. But there is plenty of debug info available now. We should be able to figure it out.

[kmbecker13]

@Roxy-3D I just ran the new firmware and had 340 bytes remaining per the M100 command and my printer started doing weird stuff in the G29 P1 command. It drove the Z axis in the positive direction over 100mm before i killed it. I'm starting to think that my weird behavior during the G26 was due to a lack of RAM.

@adamfilip have you been seeing any changes with the G26 since UBL 2.0? Also, how much memory do you have free after compiling?

Just trying to see if my problems are purely due to resource constraints!

[Roxy-3D]

@Roxy-3D I just ran the new firmware and had 340 bytes remaining per the M100 command and my printer started doing weird stuff in the G29 P1 command. It drove the Z axis in the positive direction over 100mm before i killed it. I'm starting to think that my weird behavior during the G26 was due to a lack of RAM.

It maybe because of that. If you can do a very small G29 P1 (stop it after the first probe by pressing and holding the encoder wheel) It would be very interesting to do a M100 at that point and see what it says. (You will have to pre-initialize the M100 command before that!)

And then... If you can be talked into lowering the BLOCK_BUFFER_SIZE down to 8 we should not run out of memory. If that fixes things... I can save more memory in a lot of other places and get your G26 problem eliminated.

UPDATE: If you have a 20x4 display.... You could plug that in and eliminate a huge amount of RAM. That would be good if we can do it?

[kmbecker13]

I have a smaller display, but it's on my Prusa which is running at the moment - i changed the block buffer size down to 8 and now have 1500 bytes free but still see the weird z+ moves during the G26.

The G26 does seem better though in terms of extrusion and looking like it did on UBL 1.0. Is 1500 bytes close to what you have?

[Roxy-3D]

I have a smaller display, but it's on my Prusa which is running at the moment - i changed the block buffer size down to 8 and now have 1500 bytes free but still see the weird z+ moves during the G26.

1500 Bytes free is going to be enough. With only 8 block buffers, we could end up with occasional little pauses as you print. But that will let us verify what needs to be done with G26 to get it going on your printer.

The G26 does seem better though in terms of extrusion and looking like it did on UBL 1.0. Is 1500 bytes close to what you have?

It depends on what I'm doing at the moment. My system varies from 1300 bytes free to 2100 bytes free depending on what features I have enabled. I don't have a Graphics LCD so that frees up a lot of memory for me.

If you can do a G26 now, it would be good to do a M100 I before the G26 and then get the M100 free memory report at the end. We should see how close you are to over running the free memory.

[adamfilip]

@Roxy-3D I realize you are still working your way through various issues and trying to get the delta version working.. curious when you think you will merge it into a more current version of Marlin bugfix RC7 or RC8

[Roxy-3D]

@kmbecker13 I declared a new SERIAL_ECHOPAIRPGM() macro and moved all of the literal strings to Program Memory. If you build the current version of the firmware you should have about 750 additional free bytes of memory available.

You should now be all set to do a "Training Video" on setting up the UBL system and how to use it. If you would like to discuss topics or toss ideas around how to organize things, we can start a separate thread. There are obviously a lot of topics, so it might make sense to have an "Introductory --- Quick Start" version. And perhaps it makes sense to have a few in depth ones that cover the more sophisticated topics.

[Roxy-3D]

I realize you are still working your way through various issues and trying to get the delta version working.. curious when you think you will merge it into a more current version of Marlin bugfix RC7 or RC8

@adamfilip
Well... Actually... I do want to get to the Delta work. But the z_offset issue is much higher priority. We need to get that put to bed first. Then the next thing that happens is letting the X_MIN_POS and Y_MIN_POS be negative numbers. That will be much easier to debug in a Cartesian system so it makes sense to do that first. After that is working... Then I can start the Delta work.

What are you seeing with the Z-Offset issue? I think I'm ready to go after it and get that fixed now.

As for RC-7 and RC-8, I think when one of those goes 'Stable', we will move all the fixes and enhancements that have happened since July 4th over to the UBL Branch. And probably the UBL branch becomes the main Development Branch. But that last sentence remains to be seen.

[adamfilip]

with Z offset at 0 its fine, just need to get the Z_PROBE_OFFSET_FROM_EXTRUDER the correct distance to the bed

[Roxy-3D]

But do you see a pattern of behavior as you move Z_Offset away from 0.0 ?

[adamfilip]

When I set the Z offset to 10 the behaviors is back with this weird raises
here is the log

video
https://www.youtube.com/watch?v=wE4LQiyFass

+10ZOFFSET.txt

[Roxy-3D]

Wow! That is a very good clue! I'll restart the search again for it.

[kmbecker13]

Alright here's my debug from doing the G26, the results of the printing overall actually look WAY better than any others i've done for UBL 2.0, not sure if it was from the additional RAM or something else.

I still noticed some small z "hops" on the X+ side of the printer (last points to be printed, i believe) but they were very small movements (maybe few mm?) compared to before when it was 150+. I didn't get a video as i was copying and pasting my console output in S3D to notepad (i'm sure there's a better way for this?) but i noticed the weird hops happened at the following extruder destination values(ish):

105, 111, 117, 131, 141, 148 (i.e destination=( 56.830127 , 7.500000 , ------------- , 105.043762 ))

G26_Debug_9_22.txt

[Roxy-3D]

@kmbecker13 I think what you are talking about is the same thing that adam is talking about. With a little luck, when I find what causes one of them, the other will disappear too.

[thinkyhead]

I don't have a Graphics LCD so that frees up a lot of memory for me.

If memory gets tight for some users with graphical displays, disabling the boot screen can recover a bit of memory.

[Roxy-3D]

For a Graphics LCD Panel, how much free memory can be saved by turning off the Boot Screen? On a 20x4 LCD Panel, it only saves 32 bytes.

[adamfilip]

Wow! That is a very good clue! I'll restart the search again for it.

@Roxy-3D Any luck?

[Renatfg]

Roxy,
I can not figure out what is wrong.
Z offset configured correctly - after the command
G28 X
G0 Z0
I see that the nozzle is just at the table, i.e., all right.

Look at what happens in the video - nozzle jumps during printing of the circle:
(This can be seen in 12 and 40 seconds.)
https://www.youtube.com/watch?v=X4y5ym2fsdw&feature=youtu.be

Here are the settings and results G29 P1:

echo:Z-Probe Offset (mm):
echo:  M851 Z-1.90
SENDING:M100
1716 bytes of memory initialized.
SENDING:G29 M
Bed Topography Report:
(0,4)                                                       (3,4)
(0,200)                                                   (200,200)
       .           -1.23250     0.31999     1.85374

       .           -1.00750     0.51593     2.04499

       .           -0.90250   [ 0.62280]   2.11718

       .           -0.92313     0.61249     2.11905

       .           -0.97938     0.51968     2.03749
(0,0)                                                       (200,0)
(0,0)                                                          (3,0)

SENDING:G29 P2
Manually probing unreachable mesh locations.
SENDING:G29 M
Bed Topography Report:
(0,4)                                                       (3,4)
(0,200)                                                   (200,200)
 -0.17000    -1.23250     0.31999     1.85374

  0.10000    -1.00750     0.51593     2.04499

  0.21000    -0.90250     0.62280     2.11718

  0.21000    -0.92313     0.61249     2.11905

  0.15000    -0.97938     0.51968   [ 2.03749]
(0,0)                                                       (200,0)
(0,0)                                                          (3,0)

SENDING:G29 P5
# of samples: 20
Mean Mesh Height: 0.410917
Standard Deviation: 1.070752

[Roxy-3D]

@Roxy-3D Any luck?

Look at what happens in the video - nozzle jumps during printing of the circle:
(This can be seen in 12 and 40 seconds.) https://www.youtube.com/watch?v=X4y5ym2fsdw&feature=youtu.be

I've been using every free moment to hunt down this bug. But it hasn't been enough time (yet) to find it. I'm getting more and more convinced that these are all caused by the same bug. Incidentally, on the G26 Mesh Validation Pattern circles, it seems it is always at the 6 o'clock position where the wrong thing happens. Right now, that doesn't make any sense. But for sure that is true.

I have a couple of possible paths to proceed down. If I don't find the answer soon (next couple of days???) I think I may put the old mesh_buffer_line() routine back into the software stack. If that eliminates the bug, it narrows the scope of where I'm looking for the problem. And if it doesn't get rid of the bug, it at least suggests that block of code is not the root cause of the problem.

[Renatfg]

I tried to print big square and got this interesting effect:
https://www.youtube.com/watch?v=HE-8SRDs0pA

[Roxy-3D]

I tried to print big square and got this interesting effect: https://www.youtube.com/watch?v=HE-8SRDs0pA

Yup! I'm convinced that is the same bug. And I would be willing to be money that behavior is right on a Mesh Line Boundary. I'm working on it!!! :)

[Roxy-3D]

I think I found where the problem is... I should be able to have a fix out tomorrow.

[Renatfg]

A big thank to you, Roxy!

[adamfilip]

@Roxy-3D have you had a chance to look at how Prusa is making Auto Mesh Levelling work?. curious on your thoughts on their implementation

https://github.com/prusa3d/Prusa-Firmware/tree/MK2

[Roxy-3D]

OK! I found an 'off by one' error that was affecting the last segment of moves. It should print much cleaner now. Please give it a try.

I've added some 'Sanity Check' code that should never trigger if everything checks out. If you see some messages with coordinates and z_optimized in them come out on the serial console, I need to know what gets said. But hopefully that code never prints anything and I delete it soon!

The 'M' option has been converted to 'O' and 'Q' in G29 and G26 respectively. But other than that, it is ready to give it a test. I think it is going to be much better behaved now. However, because the Z Correction was off on the final segment of the nozzle move, you probably have to do a G26 Mesh Validation Pattern and then go back and do a G29 P4 R to edit any areas that are not perfect. Then... You will be ready for a real print.

@adamfilip No, I haven't looked at it. But I really should! Have you tried it? What do you like and dislike about his version?

@thinkyhead You like doing optimizations! You might want to skim this PS: message.

PS. When ever I hear somebody had an 'Off by one' error, I wince and ask "How hard can it be to get the edge conditions right?" Well... This stuff gets confusing! Here is where the problem was:

    FINAL_MOVE:
        a0ma1diva2ma1 = (x_end - mesh_index_to_X_location[cell_dest_xi]) * (float) (1.0 / MESH_X_DIST);

        z1 = z_values[cell_dest_xi][cell_dest_yi] +
            (z_values[cell_dest_xi + 1][cell_dest_yi] - z_values[cell_dest_xi][cell_dest_yi]) * a0ma1diva2ma1;

        z2 = z_values[cell_dest_xi][cell_dest_yi+1] +
            (z_values[cell_dest_xi+1][cell_dest_yi+1] - z_values[cell_dest_xi][cell_dest_yi+1]) * a0ma1diva2ma1;

        // we are done with the fractional X distance into the cell.  Now with the two Z-Heights we have calculated, we 
        // are going to apply the Y-Distance into the cell to interpolate the final Z correction.

        a0ma1diva2ma1 = (y_end - mesh_index_to_Y_location[cell_dest_yi]) * (float) (1.0 / MESH_Y_DIST);

        z0 = z1 + (z2 - z1) * a0ma1diva2ma1;

And for the record... The original Mesh Leveling routines worked well! But if you count the floating point operations (and also factor in the reductions of floating point divides) compared to the original code, this new code frees up a bunch of CPU cycles to help the Delta's. (Be sure to account for the compiler 'folding constants' if you do the count. The preprocessor is going to turn the 1.0/MESH terms into a simple float that can be used at exectution time.) In a nut shell, the new code is replacing a call to get_z_correction( x_end, y_end);

inline float calc_z0(float a0, float a1, float z1, float a2, float z2) {
      float delta_z = (z2 - z1);
      float delta_a = (a0 - a1) / (a2 - a1);
      return z1 + delta_a * delta_z;
    }

FORCE_INLINE float map_x_index_to_bed_location(int8_t i){ return ((float) MESH_MIN_X) + (((float) MESH_X_DIST) * (float) i); };
FORCE_INLINE float map_y_index_to_bed_location(int8_t i){ return ((float) MESH_MIN_Y) + (((float) MESH_Y_DIST) * (float) i); };
int8_t get_cell_index_x(float x) {
      int8_t cx = (x - (MESH_MIN_X)) * (1.0 / (MESH_X_DIST));
      return constrain(cx, 0, (MESH_NUM_X_POINTS) - 1); 
    }                       
int8_t get_cell_index_y(float y) {
      int8_t cy = cy = (y - (MESH_MIN_Y)) * (1.0 / (MESH_Y_DIST));
      return constrain(cy, 0, (MESH_NUM_Y_POINTS) - 1); 
    }           
//
//  This is the generic Z-Correction.  It works anywhere within a Mesh Cell.  It first
//  does a linear interpolation along both of the bounding X-Mesh-Lines to find the
//  Z-Height at both ends.  Then it does a linear interpolation of these heights based
//  on the Y position within the cell.
//
    float get_z_correction(float x0, float y0) {
      int8_t cx = get_cell_index_x(x0),
             cy = get_cell_index_y(y0);
      float z1 = calc_z0(x0,
                    map_x_index_to_bed_location(cx), z_values[cx][cy],
                    map_x_index_to_bed_location(cx + 1), z_values[cx + 1][cy]);
      float z2 = calc_z0(x0,
                   map_x_index_to_bed_location(cx), z_values[cx][cy + 1],
                   map_x_index_to_bed_location(cx + 1), z_values[cx + 1][cy + 1]);
      float z0 = calc_z0(y0,
                   map_y_index_to_bed_location(cy), z1,
                   map_y_index_to_bed_location(cy + 1), z2);

     if ( isnan(z0) ) {     // if part of the Mesh is undefined, it will show up as NAN
       z0 = 0.0;        // in blm.z_values[][] and propagate through the 
                // calculations. If our correction is NAN, we throw it out 
                // because part of the Mesh is undefined and we don't have the 
                // information we need to complete the height correction.
     }
     return z0;         // there used to be a  +state.z_offset on this line
  }

[kmbecker13]

I've got a Prusa Mk2 and really like the firmware as well. It was the main reason i started looking for better solutions for my other printer (i.e UBL) since it worked so well. Some things i like about it are:

• auto axis skew correction by measuring 9 pre-placed points on the bed (probably not possible without their Mk42 bed, or something similar, in Marlin)
• live z-adjust gets stored as the z-offset in the firmware, i don't believe UBL currently does this (tho it's close!). From my understanding, with UBL you still need to adjust the "Bed Z offset" under "Tune" to store the new z offset (and this isn't a 'live' change, meaning it wont affect layers that are currently printing).
• Overall, it works very well and gets the bed extremely level without any fuss.

[adamfilip]

I will be able to test it in a few days. once i get my corexy machine back together.. took it apart to add some nice upgrades (Linear Guides!)

[kmbecker13]

@Roxy-3D Just tested the new code and it seems pretty good! No z-hop seen yet. I've noticed that when i do the G26 it isn't always exiting when i hold the knob down, it takes quite a few tries for it to register the cancel command.

Also, this may be a dumb question - but the G29 Z # command is sending an absolute command for the offset, not a relative change, correct?

[Roxy-3D]

@Roxy-3D Just tested the new code and it seems pretty good! No z-hop seen yet. I've noticed that when i do the G26 it isn't always exiting when i hold the knob down, it takes quite a few tries for it to register the cancel command.

The Encoder Wheel is only checked once per Mesh Point Circle and connecting lines. You need to have the Encoder Wheel pressed when it starts to draw the next circle for it to be detected. I guess I could check more often than that, but right now, that is what it does. Are you not seeing that behavior?

Also, this may be a dumb question - but the G29 Z command is sending an absolute command for the offset, not a relative change, correct?

There are two flavors of G29 Z. One with no number in which case it probes to find the offset. And there is the version where you can say G29 Z 1.23 and specify a number to apply. Both of those versions assign a value to z_offset (that gets reported with a G29 W or when the EEPROM loads.) That number is absolute in the sense, it is what it is. But that number gets added onto any Z coordinate that gets sent to the planner. So in that sense, it is relative. I think there is still a bug in how the Z-Offset is used elsewhere in the code because of things Adamfilip said. I'm almost set to go look for that. But I've been entirely focused on that weird movement problem. Now that I think that is fixed, I can look at getting the Z-Offset to behave how people expect it to act.

[kmbecker13]

Gotcha - i should explain what i mean/am experiencing. After building a mesh, i did a G29 P2 and G29 Z to get my height correct, but during a G26 I noticed that my nozzle was about .1-.2mm too high. I cancelled the G26 and then thought id lower my nozzle by .1 to see if that helped. I entered G29 Z -.1 and tried another G26, but it was still too high. After cancelling that, i did _another_ G29 Z -.1

Does this mean my offset is now -.2 or was i setting it twice at -.1? If it's the second one, how can i check my current Z-offset before adjusting it at a new height (so i can increase by a known height)?

It would be fantastic if babystepping was enabled during the G26 to live adjust the z-offset. This is one of the key parts of the Prusa Mk2 calibration routine, after building a mesh you print a calibration gcode while live adjusting the z-height until it looks good. If you could get that functionality in G26, it would be awesome.

[Roxy-3D]

Does this mean my offset is now -.2 or was i setting it twice at -.1?

No... The G29 Z's should not be cumulative. Only the last one will be effective. But one of the things to do on my list (with regard to the Z-Offset issue) is verify that + and - is consistent everywhere. If it is not, that would explain some of the issues adamfilip is reporting.

It would be fantastic if babystepping was enabled during the G26 to live adjust the z-offset. This is one of the key parts of the Prusa Mk2 calibration routine, after building a mesh you print a calibration gcode while live adjusting the z-height until it looks good. If you could get that functionality in G26, it would be awesome.

I guess that could be done. But maybe as an option. The problem with having it live all the time is when the Mesh Validation Pattern is complete, how are you going to remember "This part was drawn before I started Baby Stepping the nozzle down". The whole purpose of the Mesh Validation Pattern is to give you a recorded history of what the Mesh Values produce so that you can edit them up or down easily.

With that said, the Z-BabyStepping is live when the print starts. And with the QUICK_ACCESS_TO_Z_BABYSTEPPING you can instantly get to it and shift the nozzle. I really don't use it. Even with my horrible piece of glass I'm using for the UBL Development, I don't have to adjust the nozzle.

[kmbecker13]

Yea for me, the z-babystepping is more of a method to get the height offset perfect. I understand how it would skew results for the G26 mesh validation, perhaps a different print pattern could be used for the live height adjustment feature (maybe one that's a little shorter). It can be tough to get the height tuned perfectly with the currently G29 Z # command. What command will return my current z offset? Want to use a command to check my current Z offset before assigning a new one.

I've also noticed that at the end of a G26 on my printer, the LCD is unresponsive and frozen for some reason - so i can't go into the Motion menu to check the offset there.

Here is what i do on my Mk2 and it works super well: https://youtu.be/q_LqgABOICQ?t=40s

I envision that a user would use this after building a mesh to get a good height offset before they step into a full blown G26 to fine tune the mesh even further. Prusa doesn't currently have the ability to tune the mesh, so you have to just hope it's perfect - you have a major advantage in that regard :)

[Roxy-3D]

Yea for me, the z-babystepping is more of a method to get the height offset perfect. I understand how it would skew results for the G26 mesh validation, perhaps a different print pattern could be used for the live height adjustment feature (maybe one that's a little shorter).

It is very important to have the various Mesh Points accurately defined. Shifting the offsets and such during a calibration print seems akin to putting your thumb on a scale when trying to weight out a measure of meat. I suggest you don't do that. The whole purpose of G26 is to see if what areas of your mesh are good, and which ones need to be adjusted.

It can be tough to get the height tuned perfectly with the currently G29 Z # command. What command will return my current z offset? Want to use a command to check my current Z offset before assigning a new one.

G29 W will tell you the current Z-Offset. Also, an M503 will tell you the current settings.

I've also noticed that at the end of a G26 on my printer, the LCD is unresponsive and frozen for some reason - so i can't go into the Motion menu to check the offset there.

I have not seen any problems with the LCD Panel being frozen. But still, what ever the Z-Offset is, you can save it. It is part of the UBL State Information. Just do a G29 S5 and it will save the current Mesh and State Information.

Here is what i do on my Mk2 and it works super well: https://youtu.be/q_LqgABOICQ?t=40s

Interesting! I'm in competition with Prusa!

I envision that a user would use this after building a mesh to get a good height offset before they step into a full blown G26 to fine tune the mesh even further. Prusa doesn't currently have the ability to tune the mesh, so you have to just hope it's perfect - you have a major advantage in that regard :)

I see it differently. The better you square your axis's and the better you get all of your mechanical movements on the printer to 'Repeat', the more hope you have for a high quality 3D-Printer. (I know we are not arguing about this. I'm just trying to communicate my thought process.)

The Auto Bed Alignment is really best used to address flaws in the mechanical setup of the printer. The 'less work' the Auto Bed Leveling System needs to do, the better your printing experience will be. With that said, it is my goal to make the UBL System accommodate even a poorly calibrated Delta. It shouldn't be used that way. But I want to make it capable of being used that way.

The G26 Mesh Validation Pattern is a low level tool that graphically shows you the relationship between your bed and the nozzle at each 'Mesh Point'. We don't want to hide or correct that. We want this information to be accurate so we can use it to Edit the Mesh to be 'correct'.

I'm starting to think we should simplify things (for the user) and eliminate the z_offset. Please join the discussion or contribute to this thread: https://github.com/MarlinFirmware/Marlin/issues/4908

[Roxy-3D]

I envision that a user would use this after building a mesh to get a good height offset before they step into a full blown G26 to fine tune the mesh even further. Prusa doesn't currently have the ability to tune the mesh, so you have to just hope it's perfect - you have a major advantage in that regard :)

Or... How about this: What if we provided an option or a GCode command that is put in your startup code for the Slic3r. Just like you put a G28 in there, you would put this command in place after the G28, G29 sequence. This new command would generate a higher precision pattern with the Z Baby Stepping already turned on. Probably something like a Spiral pattern starting at the center of the bed would make sense. The user could just dial in the exact height (using the Z-Baby-Stepping). The command would continue at a much higher speed than the Mesh Validation Pattern is drawn. It would keep working its way outward from the center until the user had confidence everything was working right, and then be terminate with a 'Press and Hold' of the Encoder Wheel.

There would not be much material put down on the bed. The user would just let the print start normally and print right on top of the Z-Baby-Step pattern.

[kmbecker13]

That sounds VERY good! As of right now, i'm actually doing G28, G29 and then doing a 1 layer test print to get my height offset dialed in. Once i have my height pretty close, then i go into a G26.

What you described would be very handy!

[thinkyhead]

@Roxy-3D Is that "P.S. comment" applicable to the code here? What changes are you suggesting? (I'm a little slow today, otherwise I'd make sense of it.)

[Roxy-3D]

Is that "P.S. comment" applicable to the code here? What changes are you suggesting?

I'm not really suggesting any changes to the current code. The problem is the generic float get_z(float x0, float y0) has to get both the X & Y cell index which each involve a floating point divide (probably optimized to be a floating point multiply). It then does three float z1 = calc_z0(a0, a1, z1, a2, z2) calculations. And each of those calc_z0()'s does four floating point add's and a floating point multiply and (Gasp!!!!) a floating point divide.

That has to happen on each and every get_z() correction which happens at every Mesh Line. What I did was get the starting X & Y cell, and the ending X & Y cell just once for the entire buffer line. Most moves are within the same cell in which case the code I quoted up above comes into play. That code is much cheaper to do computationally.

But there are optimizations for the lines that cross cell boundaries. In the case of horizontal or vertical (Y direction) moves where you stay in the same column or row, the math gets simpler because you already know which Mesh Line you are crossing and the Z correction becomes a single interpolation instead of a bi-linear interpolation. (bi-linear requires 3 interpolations. 1 for each end of the line and then 1 to get the point in between the 2 calculated points.) And even the generic move which crosses both columns and rows is simplified by using the Mesh Line indexes to break the line up into segments. In that case the number of floating point operations only gets cut in half, but it is still worth doing.

Mostly... These changes are aimed at getting back a few CPU cycles for the Delta's! They aren't really needed for the Cartesian printers. But it is certainly easier to debug the code on a Cartesian printer!

[kmbecker13]

@Roxy-3D i'm still seeing the LCD freeze after starting a G26. It happens right when both extruder and bed reach temperature and only clears if i disconnect or reset power. Think its something related to the full graphics display?

I can continue to issue commands through my desktop application, but the LCD doesn't respond.

[Roxy-3D]

i'm still seeing the LCD freeze after starting a G26. It happens right when both extruder and bed reach temperature and only clears if i disconnect or reset power. Think its something related to the full graphics display?

It may be related to the Graphics display. I do know there is code to periodically re-initialize the LCD Displays. That isn't being done because the LCD Displays are 'stable'. I'm going to be messing around in the LCD code over the next couple of days because I'm going to add detection for 'Press & Hold of the Encoder Wheel' to get it into Z-Baby-Step mode. In fact, that detection logic is going to be in the same routine where the periodic refresh of the display happens. So, I'll keep my eye out for things.

At worst case, I might have to put a Graphics Display onto my machine. I'm hoping it doesn't come to that.

[kmbecker13]

If you decide to get one, i'll split the cost with you if you have a way for me to contribute to your developing efforts 😄

[kmbecker13]

So as my LCD freezes after doing the G26, i've been disconnecting and reconnecting to regain functionality. Before i do this, i typically save my mesh and then reload it. I've noticed that when doing a G29 W before and after disconnecting, my z-offset appears to be lost during the disconnect.

Am i forgetting to do something to save this to the EEPROM? I've done an M500 as well.

[Roxy-3D]

If you decide to get one, i'll split the cost with you if you have a way for me to contribute to your developing efforts :smile:

Thank You for the kind offer. But I can afford a Graphics LCD Panel. I just don't want one!

Is the LCD Panel active during the G26 and locks up at completion of the G26? Can you help me establish a window of time where it goes sour?

I've noticed that when doing a G29 W before and after disconnecting, my z-offset appears to be lost during the disconnect.

I'll see what I can find on this.

[kmbecker13]

I still see the X and Y values changing throughout the G26 process, and i can still kill the procedure by depressing the encoder wheel, but the temperatures don't seem to fluctuate much - which is odd. At the end of the print, the screen stops reflecting the current machine state altogether, both position and temperature.

After the G26 - If i command the head to move from a terminal, it moves, but the LCD will not update. The LCD also doesn't change if i send a G29 P4 or any other command until disconnecting. The encoder wheel on the LCD also doesn't seem to have any effect, not just the display itself. What i mean is that if i send a G29 Z, spinning the wheel doesn't drive the machine at all, so it's not just a visual problem

[Roxy-3D]

And right up to the end of the G26, can you press and hold the encoder wheel to terminate the G26 ?

What I'm wondering is this: The UBL system grabs control of the LCD Panel on certain events. The G26 is one of those events. I'm wondering if it isn't being given back to the system correctly. Or maybe it is in the 20x4 LCD case, but not the Graphics case?

[kmbecker13]

And right up to the end of the G26, can you press and hold the encoder wheel to terminate the G26 ?

For the most part, yes. I'm still seeing some weird behavior where i can't terminate the G26 at certain bed positions (seems to be on the x_max side) and i'm fairly certain it's not just poor button pressing on my part. I can do some testing later to confirm i can cancel late in the G26.

[Roxy-3D]

I can do some testing later to confirm i can cancel late in the G26.

Please do! But the thing is, the G26 is really just a big loop. If you can cancel after one or two circles are drawn, that isn't any different than a cancel at the very end of circle drawing.

One more question, when you cancel in the middle of a G26 it tends to be OK? Is that correct? Is it when you finish all by itself that the LCD Locks up? Because that would be a valuable clue. In that case it would be going through different code paths.

[kmbecker13]

So i've been trying to knock out one print today and am seeing some weird behavior while printing a raft. The printer will get about an hour in and then either stops extruding randomly, drifts off the print surface and crashes or stops altogether - very weird.

In the most recent case, i noticed the following on my print control readout in S3D:

busy: paused for user
READ: echo:busy: paused for user

The LCD read M105 and after pressing the encoder, it resumed printing for another few minutes until it happened again and then just started going haywire in general (driving to random spots, slowly). I am also seeing this periodically in my print control readout:

WARNING: Firmware unresponsive. Attempting to force continue...
SENT: M105
READ: echo:busy: processing

I've never seen this before, so i'm fairly certain its in the firmware and not slicing or my printer itself.

[Roxy-3D]

Can you try the same print but do it from an SD Memory card? It would be
helpful to rule out a Serial Communication problem. But if you need to
hurry up and knock out a print, it might be best to load a more proven and
tested version of the Firmware.

[kmbecker13]

SD card print was successful! Sounds like it was a serial comms problem. Any idea what could be causing that?

[Roxy-3D]

SD card print was successful! Sounds like it was a serial comms problem. Any idea what could be causing that?

Well... it could be a lot of things. I've had trouble with lower quality USB cables causing the serial communications to lock up. And I've also had trouble with prints getting ruined when my machine running PronterFace decides it needs to run Micro$oft's Security Essentials to scan the disk for maleware. It seems the USB Serial Communications is not very robust. For sure the USB protocol is solid. It kind of feels to me like the AVR USB Serial stuff is a little bit problem prone. I don't know that that is true. But a lot of people are emphatic that you should never use the serial port for an important print. (And this isn't a Marlin issue. It is an AVR issue.)