HELP UBL !

[ghost]

@thinkyhead @Roxy-3D

Hi , UBL strange behavior outside of bedsize , up infinitly and more strange things, i have a purge bucket outside of the bed ' impossible to probe this void zone '

How to solve ? 1-) Enable/disable UBL by gcode when go out of boundaries " when go on pause zone ' but i don't know if it can resume perfectly the height when back to print 2-) Move to the limit and go on pause zone , to avoid interpolation of bedzone and nobedzone 3-) Add manually the bucket zone in probing points 4-) Is it fixed now , Need support , or any options for out of probed zone ?

Thanks

[Roxy-3D]

There have been a number of reports of the Z-Axis going to infinity on UBL. And also a few reports of the Z-Axis diving into the bed. I don't know when the regression got into the code. I'm going to be making some additions to the UBL code so I'm going to be watching for this. (AND FIX IT!!!!)

But the problem has to do with the nozzle going off the mesh. You can do idea 1 and that will work. UBL will 'resume perfectly the height' when it is re-activated. You probably don't want to hear the reason this is... But you can activate and de-activate as much as you want and you will not confuse the printer about the 'correct height'.

[ghost]

For information

• No bug when no moves in the bed and no big activity in the bed before go outside
• No bug when go on the limit , and after go outside
• The moves that go outside , stop a bed boundaries , up , and down
• No bug , when enable , disable

It's the interpolation calculation, when no probed points are available ' outside ' the maths are wrong for zheight It's just here , the maths with no probed points Add a rule , all over bedsize have the same value of the closest point

[Roxy-3D]

Agreed about the interpolation math. The functions are coming up with a bad value if a NAN (invalid mesh point) is used in the calculations. They should be coming up with 0.0 in that case.

[ghost]

I trust you

[ghost]

But , if you have a bed with a corner at 1mm and you apply 0.0 The size of nozzle will shock the bed It's why , you need to use the closest point to minimize the drama lol Or create a define like this 'UBL Outside z Height ' to have a fixed secure value for all outside movements with disabled interpolation

[ghost]

UBL system force the user to activate an 'outside of bed ' secure height It's time to make it

[ghost]

Good job ! lol

[Roxy-3D]

Yes... I understand why you are saying that. But that is why it is very important that you setup and calibrate your printer. If you tell the firmware the bed is a certain size.... Perhaps it would be good if the nozzle actually stayed in that area. The problem with interpolating off of the nearest point (besides it taking a lot of calculations) is even that does not guarintee the nozzle won't be driven into the bed.

I'm more inclined to add an option something like:

#define UBL_Z_RAISE_WHEN_OFF MESH 5.00

If you really need to go off the mesh and UBL is active... That number would be used as the correction instead of 0.000. Would that be OK for your printer?

[ghost]

Don't need new options Just add a comment on UBL description

"To go outside of BEDSIZE enable/disable UBL"

And ALL IS FIXED lol And you have time to have reflexion about this and make some new maths

[ghost]

After reflexion and for the happyness of everybody ...

define UBL_Z_EXTERN_OFFSET 2 // mm

Is a very good idea 2mm is enough by default because feedrate of z never high and make time to raiseup

[Lutz1967]

Hi! First I would like to thank you for the great work. I learn to use Marlin now since some month and its great to apply and create. Recently Ive tried to make UBL work on RAMPS. Firstly I had used MESH_INSET=15 to utilize the inductive probe correctly, but then I got the Z-to-the-max issue and also Z into the bed. Then I read that the root cause is going outside the mesh and I`ve redone everything with MESH_INSET=0 and corrected the mesh by hand. Then I made a test print and at one point (clearly within the defined mesh) the extruder pushed out all the filament ... I have no idea how extruder and UBL interacts but that is what happened. Any idea?

[Roxy-3D]

I am currently working to resolve the Z-to-Infinity issue when the nozzle goes off the mesh.

Then I made a test print and at one point (clearly within the defined mesh) the extruder pushed out all the filament ... I have no idea how extruder and UBL interacts but that is what happened. Any idea?

My guess is you have the filament sensor defined and there was some electrical noise on that signal. If you are not really using the filament changer stuff, you might want to turn that off.

[ghost]

Me too , every day , the use of marlin is a pleasure , babystep + ubl + fw retract + advance is my happyness

[Lutz1967]

Thanks for the quick response. Look forward to use UBL when Z issue is fixed.

Filament runout stuff is not active. But I use the pin that is assigned to the sensor for something else (fan). I don’t think that should have any impact but I have corrected that.

[Athemis]

@Roxy-3D probably slightly off-topic, but perhaps it may help to pinpoint the Z-to-Infinity issue: I observed that issue on my delta printer not only if the nozzle goes off the mesh during UBL levelling, but also during regular prints. Those instances all had in common that the model was very close in size to the bed boundaries set in Marlin, though the model never really exceeded those (at least the slicer did not complain). But you can trigger that reproducably by trying to print gcode that has been sliced using bed boundaries slightly larger than those set in Marlin. My guess would be that some kind of rounding error is involved here?

[AnHardt]

Could xy-skew code be involved? (when leaving the probed area but being inside)

[Roxy-3D]

probably slightly off-topic, but perhaps it may help to pinpoint the Z-to-Infinity issue: I observed that issue on my delta printer not only if the nozzle goes off the mesh during UBL levelling, but also during regular prints.

I was working on that all day today. It is not a rounding issue. It is a problem with invalid mesh points being used in the Z-Height correction calculations. And the problem with going off the mesh is there is not another set of mesh points to do the bi-linear interpolation.

[ghost]

YEAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

Roxy seems very close to push something soon Don't forget to Force UBL to apply HEIGHT OF MESH OFF when off mesh Don't forget to add the ' definition of ' HEIGHT OF MESH OFF ' , very very very very IMPORTANT Don't forget to verify if babystep works when disable And the new release will be top And tell me what units are impacted , the new bugfix have ' pause code ' totally destroyed ,and i don't want to use this new bugfix , so i will just update the units you have modified

### Ps: For information , i have made a printing , dual color single nozzle , and each tool change need to go on purge bucket outside the bed , i have used G29 enable disable to go and back IT's perfect , there is just the beep to delete

[Roxy-3D]

Right now I'm trying to fully understand the representation and usage of NAN in the Arduino library. The reason is that is how the bad height is getting the stepper motors doing the wrong thing. But something I don't understand is I have a configuration right now where doing a G26 causes the problem. That is very strange (and others have reported this exact issue also) because G26 never sends the nozzle off the mesh.

It will be a few days because I'm trying to fix this as cleanly as possible and not brute force the fix. With that said... I've got what I need now to get this resolved and I'm on it.

I'll probably do the Z_LIFT_WHEN_OFF_MESH as a separate Pull Request just because I have to change 37 Configuration.h files to do that one.

[Roxy-3D]

@studiodyne I think the "Off the Mesh" issue is resolved so it doesn't make crazy up or down movements. I need to check out the latest G26 changes for circle drawing... And then I'll look at the other request to have a specified Z Height correction when off the mesh.

[Roxy-3D]

@studiodyne The requested changes are merged into bugfix_2.0.0. I'm making a bugfix_1.1.x version now....

https://github.com/MarlinFirmware/Marlin/pull/9661

Please let me know if works how you want it to work. I'm wondering if the Z raise when the nozzle goes off the mesh should be 'faded' ? At some height (maybe the fade height), it would seem the raise should not happen. Right now, it raises unconditionally when the nozzle goes off the mesh.

[ghost]

YOU RULES ! I will test soon Now , i'm working on the WANHAO LCD DLP , i just received it , at the software suit is so poor , two days and no print started all is too young , and softwares are all prototypes , no smart function , for example , i want to print a tea cup , but to make economy of resin , i want to change the infill , with honey comb for example , and there is no software that transform a stl with a hollowing/infill function ' and , the second question is ' how to get out the resin inside lolllllllllllll and more Promise i test this soon

[filipgoc]

Just wanna say. Awesome troubleshooting @Roxy-3D!

Also happy to hear there's a regression or something in the mesh validating pattern G26. I presume now that's why babystepping does not work while G26ing.

And I here I was thinking it was a design choice (which I didn't understand). Haha.

[Roxy-3D]

My guess is if you enter Z-BabyStepping prior to doing the G26, it should work. But really... You want G26 to show you what the printer really sees. The G26 pattern is not valuable if the user is moving the nozzle up and down.

[filipgoc]

@Roxy-3D I understand your reasoning, which I believe is based on starting with the printer being able to print in the center before even launching UBL. However, my use case is very different from yours.

Long story short, I have a predictable and consistent tilt to the build platform. Thus, it is way easier for me, if not necessary, to have some leveling in place and activated to be able print anything - and thus to be able to babystep the proper z probe offset. Only after that I would move into validating the mesh.

(If you're wondering why I don't have the Z offset from the nozzle set in config as precisely as possible, it's because I have quick swap extruders with various hotends. It's way easier to lower or raise z probe into the right neighborhood when I swap out for a vastly different one, and then tweak the offset digitally in a few seconds.)

Does any of this make sense?

I was poised to simply tweak the z offset as the validation pattern initiates (decidedly losing about a centimeter of validation) and then observe the rest of the pattern. Yet as I'm writing this, I suppose it would be indeed cleaner to add the z tweaking as an additional step prior to mesh validation...

I still wonder if it's necessary to prevent user from using babystepping, if it actually is by design. If a user doesn't want to babystep, she or he doesn't have to. (User has to exhibit resolve, and act to babystep.)

[Roxy-3D]

I still wonder if it's necessary to prevent user from using babystepping, if it actually is by design. If a user doesn't want to babystep, she or he doesn't have to. (User has to exhibit resolve, and act to babystep.)

Baby Stepping is done by constantly calling idle() and having the LCD code constantly checking the encoder wheel's position. G26 doesn't do anything to make that happen. But it could. It probably is as easy as calling lcd_status_screen() when long waits are happening. (And testing the system for correct operation.) If you want to wake up G26 to baby stepping... I'll help you get that to happen.

[filipgoc]

If you want to wake up G26 to baby stepping...

Thanks. I want to keep you all focused on these other bugs for now :-) No distractions.

I'll give it a bit more thought. Writing about this made me think that maybe what I want is adding a step to (my own) UBL flow.

[ghost]

How i use UBL 110°c bed , i make a cold mesh :smile , i save , i set fade heigh to 1mm , and it's all To verify if UBL works , i have a tape on the z axis ,if the tape move like a flag , all is good To verify ubl by lcd , i have made a custom user script ' G1 xy move ' because , the LCD move does not act the ubl I don't use the g26 pattern it's too long , time is precious One click on the babystep ' option autosave ' , and ITS ALL And every day , i think about roxy that have created this AWESOME MAGIC FEATURE !!!!!!!!!!!!

[ghost]

@Roxy-3D , please can you take one minute to read my post on your last pr conversation , i have made a little suggestion about ' Secure Z HEIGHT OFF MESh' , that works only when z axis is inferior to it , but when the z height have reached the secure value , you can disable this It's not good , not need , not usefull , increase the printing time ,and cost computation ticks ,to have a z raise during all the print

Example

if (end[Z_AXIS]<=UBL_Z_RAISE_WHEN_OFF_MESH) z_raise = UBL_Z_RAISE_WHEN_OFF_MESH;
else  z_raise =0;

or

z_raise = (end[Z_AXIS]<=UBL_Z_RAISE_WHEN_OFF_MESH) ? UBL_Z_RAISE_WHEN_OFF_MESH : 0 ;

It's a feature to avoid scratching the bed , but this feature can be disabled when nozzle is far it's a very light little fix 😸

[ghost]

UBL_Z_RAISE_WHEN_OFF_MESH 2.5 Not implemented in 2.0 just the definition exist in config.h

[Roxy-3D]

There was a problem with the use of #if ENABLED(). That had to be changed to #ifdef's because ENABLED() doesn't work with floating point numbers. I'll try to bring up the bugfix_2.0.0 branch today and get it checked out (and working).

If you pulled the code before this commit: https://github.com/MarlinFirmware/Marlin/commit/304e0f8945f8a25b9c08b5047dc8530a10f66975

Please grab a fresh copy and try it again...

[ghost]

Don't work anymore on 1.1.x now

[Roxy-3D]

Arrrrrgggghhhhhh!!!!

[ghost]

Not implemented too ?

[ghost]

I don't see the merged line ' calculations ' in the last bugfix 1.1.x

[ghost]

Travis not ok loll

[Roxy-3D]

@Studiodyne I like the idea that above the UBL_Z_RAISE_WHEN_OFF MESH nothing happens. And below that height, it simply raises to that height. I think we can accommodate that. But that will take a little bit more work because right now a lot of the work is being done in the Z-Height correction routines and they don't know the current height.

[ghost]

Take your time All the release versions are very bad now I keep my old release Today , i have made a new up , and i have lost ' big edit font ' , ubl still in progress , pause system is shit Marlin not on the highlights for the moments. current z height is not like x and y , it's more calm and stable , and you can use the last known value in the routine with a secure margin , ultra precision not needed here , you just have to be up to the z value but never under

[ghost]

My wish for UBL off mesh Z secure height 'you know all ' off mesh z secure active only under current z lcd babystepping active is UBL disabled ' seems to be solved ' And a new wish ..... FADE HEIGHT in LCD , because fade height change when the object to print change , and there is no possiblity to adjust it by lcd , and if we print by sdcard , to set a fade height need usb connection and will reboot the board Fade height have been forgotten , but it's a VERY IMPORTANT DATA I use one millimeter fade height , because i d'ont understand why10mm if you print a plate of 3mm I understand that we want same thickness everywhere , but it's the only object that need a high fade height , all other object want to smooth the plan the more quick as possible

[Roxy-3D]

but it's the only object that need a high fade height , all other object want to smooth the plan the more quick as possible

No... This isn't true. The problem is the amount of extrusion isn't changed on a per layer basis. The difference in the bed needs to be averaged into a large number of layers.

And a new wish ..... FADE HEIGHT in LCD , because fade height change when the object to print change , and there is no possiblity to adjust it by lcd , and if we print by sdcard , to set a fade height need usb connection and will reboot the board

I believe it is there if you have Bed Leveling turned on in the LCD.

    #if ENABLED(ENABLE_LEVELING_FADE_HEIGHT)
      static float new_z_fade_height;
      void _lcd_set_z_fade_height() { set_z_fade_height(new_z_fade_height); }
    #endif

[AnHardt]

Even fade height could be dynamic. If it needs 10 mm (50 layers) to even out a 1mm failure, that is 1/50 mm/layer. If the largest failure (max difference of the probed points) on the bed is only 0.1mm it only needs 1mm (5 layers) fade height, to have the same (1/50 mm/layer) MAX_HEIGHT_CORRECTION.

[Roxy-3D]

Even fade height could be dynamic.

Good point. Fortunately... This would be a relatively easy one to do within the SEGMENTED_MOVES logic because the firmware would know how much Z-Height correction was being applied in that area.

If it needs 10 mm (50 layers) to even out a 1mm failure, that is 1/50 mm/layer.

If we were to do this... It might make sense to specify how much height is needed to fade out .1mm of error. Some parts of the bed would not have any correction before other parts of the bed reached their fade height.

[ghost]

@Roxy-3D The LCD FADE HEIGHT not implemented in the UBL menu I've seen the ultralcd.cpp No implementation , on the UBL zone The menu is created , but never used Make a fix , add it on the list lol ' easy ' I can make it , but i prefer when it's you , because MERGED immediatly , if it's me , i will be thinkyheadized before , and it will take a few days lolllllllllll

Updated wishes 1-) Lcd Fade height for UBL 2-) Nan/offmesh UBL bug 3-) Secure z height ( + disable when current z raise to the same value ) 'Not important you have the time'

Thks in advance for the time you give here ! For us and for the firm

[ghost]

Updated wishes 1-) Lcd Fade height for UBL 2-) Secure z height ( + disable when current z raise to the same value ) 999/NAN -) Fix big edit font lollllllllllllllll PLEASE my favorite functionnality !!! Thks in advance for the time you give here ! For us and for the firm

[filipgoc]

For better or worse, this seems to be now temporarily a somewhat general UBL thread.

I am unclear about the use cases for bed and hotend temperatures when probing the mesh.

• Is the ONLY reason to heat up the bed and the hotend before probing that most probes measure differently when heated up, and the proximity to the hot bed (and extruder? really?) is enough to mess them up?
  • I suppose this is coupled with the bed actually varying in properties at different temperatures.
• If that's the case, then what we really want to do is match is the temperature when generating the mesh and the temperature when homing as a part of our start gcode.
• If I
  • home all axes first
  • and then heat up the bed
  • and then print, ...
  • then I should actually be generating a cold bed mesh even if I'm printing at 235/70 °C?

Is this right?

[Roxy-3D]

Is the Bed Leveling main menu available when UBL is active? If so, that is where it will be.

/**
 * Use the LCD controller for bed leveling
 * Requires MESH_BED_LEVELING or PROBE_MANUALLY
 */
//#define LCD_BED_LEVELING

#if ENABLED(LCD_BED_LEVELING)

I think the code is there. I think we just need to get it to compile in when UBL is active.

[Roxy-3D]

Is the ONLY reason to heat up the bed and the hotend before probing that most probes measure differently when heated up, and the proximity to the hot bed (and extruder? really?) is enough to mess them up?

Yes... You will get different mesh values when probing cold or hot. Personally... I think one hot mesh is enough. Because I use Z-BabyStepping when a print starts to manually adjust the first layer anyway. But if you are not going to do that, you may want a mesh that is built at PLA temperatures and a mesh at ABS temperatures. (And just save them to different mesh slots.)

I also don't really see a reason to generate a cold mesh. But it is in the menu system...

[filipgoc]

I also don't really see a reason to generate a cold mesh. But it is in the menu system...

Hm. What do you think of this line of reasoning? :

what we really want to do is match is the temperature when generating the mesh and the temperature when homing as a part of our start gcode.

If I home the z axis while the bed is cold and then heat up before the print, shouldn't I actually be generating a cold bed mesh even if I'm printing at 235/70 °C?

[ghost]

@filipgoc On a 400x400 buildplate or a 600x600 builplate , it's strongly requiered to probe with heated bed , because the mesh isreally different , between 0.1/0.8mm , the hot bed mesh is not a joke , it's serious i have a 400mm bed , and if you have 0.4mm somewhere , your first layer is down and the nozzle scratch the bed , and i you have ' BUILDTAK' adhesive , you can put it in the trash !

@Roxy-3D No available menu except the UBL big large strong infinite menu , so you can make a fix to have it

[filipgoc]

@Studiodyne

I think I got it.

It's not as much about the probe changing the probing (as that should mostly just shift the mesh up and down), but about the bed actually changing shape due to heating up? Is that what you're saying?

(Otherwise, like roxy, just shifting the mesh up and down as needed...)