Marlin: 1.1.2 Regression: 7kb additional size due to PROBING_HEATERS_OFF requires ADVANCED_PAUSE_FEATURE

[HenningJW]

Hello, since 1.1.2 I need ADVANCED_PAUSE_FEATURE for the PROBING_HEATERS_OFF, which consumes about 7kb extra. Imo this is a pretty big regression from 1.1.1 and there is no way to fit this onto my 128kb Melzi board.

edit1: There is another regression I am investigating, the size grew about 22kb even without adv_pause. I can't edit the topic, from 30kb to 7kb.

edit2: bisecting since "UBL Menu System 1.1" / 66db6c3 I went from being able to fit my config into 128kb (127504/98%) to a linker error region text overflowed by 6144 bytes. Will investigate where the size grew significantly.

edit3: 48f76521 added another ~3kb (2731) after some rambling (=> +500)

edit 4: ac959b1 adds another 1.5kb (1654), again after some rambling (+ 430), the rest is misconfiguration on my side (10.5kb) and some rambling after (1.5kb)

[fiveangle]

Aside, NO_WORKSPACE_OFFSETS usually recovers a few k if you don't need it

[thinkyhead]

consumes about 7kb extra

I assume you mean 7K more Program Memory…?

Please post your Configuration.h and Configuration_adv.h (zipped works) so we can try building with your settings and use that as a starting point to resolve the issue.

[thinkyhead]

edit3: 48f7652 added another ~3kb (2731) after some rambling (=> +500)

Optimization is disabled for UBL's G29 by that commit — It intentionally uses more program memory for extra safety. I think you can safely remove the _O0 flag from unified_bed_leveling::G29 now, if you want to use less program memory, and it should work just fine.

[thinkyhead]

edit 4: ac959b1 adds another 1.5kb

That links to a change in a few Spanish strings, which would have no effect on size. Perhaps the actual commit that brought the change was earlier than this?

[thinkyhead]

edit2: bisecting since "UBL Menu System 1.1" / 66db6c3

We can double check that this new feature doesn't add too many new strings.

If you don't need G26 then be sure to disable UBL_G26_MESH_VALIDATION – which is now enabled with UBL by default.

If you're just looking to do basic mesh-based leveling and don't need a lot of tuning options, the core AUTO_BED_LEVELING_BILINEAR option is likely to use a lot less program memory, while still being a good mesh-based system. UBL is built for power and variety, not with modest 128K boards in mind.

[HenningJW]

Not sure how I failed with edit4, but I bisected again and it was 0cbe448 that added 1606 bytes.

I hope a patch is fine, I also modified a line in the pins definition, to free up an io pin for a probe. It should be "git apply"-able.

marlin112tomyprinter.txt

[Roxy-3D]

We probably should add controls to turn off all the LCD UBL Menus. Most likely we can save 5KB (or more) doing that. And we should also add other controls to turn of big hunks of the code.

It is on my "To Do" list....

[tcm0116]

We could remove the requirement for ADVANCED_PAUSE_FEATURE for PROBING_HEATERS_OFF by either removing the ENABLED(ADVANCED_PAUSE_FEATURE) condition or adding ENABLED(PROBING_HEATERS_OFF) as an or'd for the heater idle functions in ThermalManager and the lcd_impl files.

[Lord-Quake]

Guys, I just signed up to Guthub and need to learn the ways so please bear with me.
I think the issue I'm having fits this thread.

When I used v1.1.1 my compiled size was

The FW would work with my setup.

However with v1.1.2 my compiled size using the same settings as v.1.1.1 has grown considerably

I can upload the FW but my Graphic display (ANET_FULL_GRAPHICS_LCD) will show a blank screen.

If I deactivate "ADVANCED_PAUSE_FEATURE" in v1.1.2 the FW will run with my setup but I no longer have M600 to my disposal.

I'm guessing this is a FW file size issue.

[benlye]

@Lord-Quake you might want to grab the latest Anet board definition from @oderwat's repo:
https://github.com/SkyNet3D/anet-board

It updates the maximum upload size for the stock Anet board to allow for the standard bootloader, and gives the option to use Optiboot which allows larger firmware uploads.

I suspect that you're v1.1.2 upload is stepping on the bootloader, which is why you get the blank screen. With such a large compile size you will find that unless you use Optiboot, your v1.1.2 build won't be allowed to upload because it is too large (the actual max upload size for the standard bootloader is 126976B).

If you go this root you need to change your board selection in the Arduino IDE to 'Anet V1.0 (Optiboot)'.

[Lord-Quake]

Oderwat's repo is what I'm using however i'm using the standard "Anet V1.0" files.

I will try "Anet V1.0 (Optiboot)" this evening and let you know how it goes.

My concern is that Marlin is now at a point where a Mega 2560 will no longer be compatible which in my opinion would be a disaster as this CPU is used with so many 3D printers on the market.

[benlye]

Your Anet board doesn't have a Mega 2560, it has a 1284p, which has half the flash space of the 2560. Also, I can see from the screenshot you posted you don't have the latest version of the Anet board definition because it reports the maximum size as 131072. With the latest version you will see a max of 126976 (standard board) or 130048 (Optiboot). Those changes are made to prevent corruption during the upload.

[Lord-Quake]

Opps, sorry. Of course it's a 1284p but my concerns stand.

Like I said, I will try Optiboot this evening and report.

Thanks!

[oderwat]

Right, the Anet board has a 1284p and will limit what you can do. The new board definitions are made to prevent killing the bootloader. I for mysqlf have the SD card support disabled since months, which gives me space for experiments. It gets even worse when using other displays on the A8 and on the A6. UBL and other new features require a lot of additional space. Trying them needed manual "adjustments" by deleting code to fit into the board. I think one eventually has to accept, that there is this limit and consider using another board. My Rumba waits since weeks that I take the time to switch though.

[bgort]

or adding ENABLED(PROBING_HEATERS_OFF) as an or'd for the heater idle functions in ThermalManager

👍

[fiveangle]

It would be nice if UBL didn't require LCD (hint, hint :)

[Lord-Quake]

OK, I installed Optiboot as bootloader on my Anet board. Went off without a hitch.
Then I compiled my FW settings including "ADVANCED_PAUSE_FEATURE" to the board.
That was a success and the printer is now running as it is suppose too :-)
Thanks @benlye for the tips and to @oderwat for the Anet fork!

[Roxy-3D]

It would be nice if UBL didn't require LCD (hint, hint :)

Yeah... I was trying to get closure on how we proceed in https://github.com/MarlinFirmware/Marlin/issues/6982 . Right now I'm leaning towards 3 new symbols. I'm thinking we need:

HAS_LCD_PANEL
HAS_GRAPHICS_LCD_PANEL
HAS_CHARACTER_LCD_PANEL

If HAS_LCD_PANEL is defined, one of the other two will also be defined. That would work nicely for @Tannoo 's work. Most stuff can just be switched based on HAS_LCD_PANEL. But some of the fancier rendering can be done based on the last two.

[fiveangle]

i see this is still open - still having issues ?

[HenningJW]

I would assume not, as the pr is merged. I am using UBL without a display now with PR 6971 cherrypicked into 1.1.3 (this was godsend!).

For the record in my setup the default optimisation works (Os I would guess) works for unified_bed_leveling::G29. Haven't looked at the binary though, if there are problematic things with Os.

From my perspective this can be closed, I am not sure if this serves as a memo for:

We probably should add controls to turn off all the LCD UBL Menus. Most likely we can save 5KB (or more) doing that. And we should also add other controls to turn of big hunks of the code.

As there were quite a few people in this topic I am hesitant to close it myself, since there is still some kind of size regression going on, even not directly in relation to the topic. I don't know how the workflow is in this bugtracker, if anyone thinks this is better closed, please feel free to close this topic.

[Roxy-3D]

Don't worry about us forgetting! We know UBL is BIG. We need to get the full set of features moved to the 20x4 LCD panels and then it will be time to allow the user to start turning off big pieces of it.

[fiveangle]

You got that right @Roxy-3D ! 😝

//#define AUTO_BED_LEVELING_3POINT // 6366 bytes (w/o LCD)
//#define AUTO_BED_LEVELING_LINEAR // 18386 bytes (w/o LCD)
//#define AUTO_BED_LEVELING_BILINEAR // 9804 bytes (w/o LCD)
//#define AUTO_BED_LEVELING_UBL //48592 bytes (w/o LCD)
//#define MESH_BED_LEVELING // 7220 bytes (w/o LCD)

😱

[fiveangle]

One thing I noticed when reviewing some of the G8u2 library discussions, G8u2 allows an LCD emulation mode:

Very fast, LiquidCrystal like char based API (U8x8) if graphics output is not required.

Which seems like it wouldcould be a boon, if the performance of its own text->graphics translation layer doesn't throw the baby out with the bathwater :)