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

[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" notifications@github.com 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