search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.17k stars 19.21k forks source link

[FR] Marlin Resource Optimization Guide #7696

Closed Deneteus closed 6 years ago

Deneteus commented 6 years ago

Forward: This is my first time compiling Marlin. Experienced with QA/Hardware support for Windows/Linux

Issue: When I was attempting to compile Marlin for my Creality CR10 with Unified Bed Leveling (UBL) enabled I quickly found that it eats up a lot of space. 

**Error:**  Arduino: 1.8.4 (Windows Store 1.8.8.0) (Windows 10), Board: "Sanguino, ATmega1284 or ATmega1284P (16 MHz)"

Archiving built core (caching) in: C:\Users\denet\AppData\Local\Temp\arduino_cache_508657\core\core_Sanguino_avr_sanguino_cpu_atmega1284p_beb9a19b8f39f7198bf44747ccbb9fb5.a
c:/program files/windowsapps/arduinollc.arduinoide_1.8.8.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld.exe: C:\Users\denet\AppData\Local\Temp\arduino_build_304217/Marlin.ino.elf section `.text' will not fit in region `text'

c:/program files/windowsapps/arduinollc.arduinoide_1.8.8.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld.exe: **region `text' overflowed by 74774 bytes**

collect2.exe: error: ld returned 1 exit status

exit status 1

What I tried: I already found a copy of working Marlin 1.1.4 config for the CR-10 from 2 different individuals that are selling ABL sensors and realized that neither source included any notes about the changes they had made so there was no way to know the reasons behind their changes as they were not documented. (I used Notepad++ to Compare their config files to the example config and noted the differences.) For someone working with open source products I thought 'That's not cool man.' How is a noob supposed to learn how to modify this stuff?

I then scoured the internet for more information about this issue and eventually found several posts pointing to the fact that the code required to enable the feature on my Creality CR10 would require me to sacrifice features that were already enabled in the stock firmware without Auto Bed Leveling (ABL) such as SD Card support, LCD Display Support, Sound, etc.

I found that there is an issue with the Rerapdiscount Full Graphic Smart LCD using 55kB as well as the fact that previously some changes could be made to QR_SOLVE.H to reduce the amount of memory as well. The stock CR-10 has 128k so that is a problem.

As I read through previous bug reports I found that that there are a few people that know this info but I saw none of this info within the documentation itself where anyone could figure it out themselves. When there are 20 Instructables about an issue but it's not documented in official documentation then I believe there are a few problems that need to be solved.

  1. Why isn't there any info about how much memory is required to run different types of LCD hardware?
  2. Why is there no list of 'Most Wanted' optimizations being posted so that new people can help find better ways to fix some of these issues?
  3. Where are the docs that say 'if you do this' then you are going to bork your install?
  4. What can we do to reduce the size of these graphics libraries that include functions that we may never use? For example. 'Removing Big Text' to save some kb.

Feature Request: Please provide more information on managing available memory when enabling/disabling Features within Marlin within the FAQs. It would be helpful to include the average size of any compiled drivers for LCDs or anything else that's going to use space when the firmware is compiled. This way people can plan their builds around available resources.

Supporting Documentation:

Graphic LCD support makes Marlin too big for 128k boards. https://github.com/MarlinFirmware/Marlin/issues/1645

V1.1.4 with Anet and Bed Leveling Sensor -> "Sketch too big;" https://github.com/MarlinFirmware/Marlin/issues/7240

Marlin with Anet A8 https://github.com/MarlinFirmware/Marlin/issues/7190

Not compiling with UBL defined #6602 https://github.com/MarlinFirmware/Marlin/issues/6602

fiveangle commented 6 years ago

Looks like you found lots of info on this (as per your links above). I answered you in your other thread too.

The reason there isn't specific answers on how much each take, is because they are not constant but instead depend on all the other enabled features. For example, enabling LCD but not UBL or SD does not increase PROGMEM usage as much as when UBL and SD are enabled (because without them, the LCD logic to run those features isn't needed). With dozens of compile-time features in Marlin, and every feature adding another increment to the exponent of how many possible outcomes there are, the answer becomes very complex, very quickly.

Scott and I discussed the possibility of scripting a travisci compile for every possible perturbation (perhaps on a daily basis, since it would be quite resource-consuming) and auto-populating the results in yet another as-yet-to-be-built "Marlin Configurator" that would cite PROGMEM/SRAM usage ranges for the possible outcome, but the reality is that doing this would amount to almost as much effort as most of the actual dev work being done on Marlin itslef as of late.

I like your idea though and absolutely agree that it would be a great thing to have for the small number of users that it is critical for. If you have insight as to how to go about doing so, please jump in, but providing the info is much more difficult than it seems on the surface, with a relatively small number of users it benefits.

The configure->compile->review resulting size of sketch method that everyone has been using for years, while somewhat tedious, seems to work well enough that the drive to ochestrate a more elegant solution hasn't spured anyone to want to invest the time to do so.

All this said, I do think a simple document expaining the configure->compile->review resulting size of sketch method would be useful for new users struggling with where to start. Since you're headed down this path, perhaps you would be interested in writing such a doc ? It would make a nice addition to the Marlin wiki and, as you're finding, would help a lot of new users out.

-=dave

Deneteus commented 6 years ago

@Deneteus - The fact is the 128k boards are a minority makes bending over backwards for them a double-edge sword. Those with them typically stick with the mfr provided FW for just this reason (Printrbot, Anet, etc). Your concerns are valid but not easy to address since every user's needs are slightly different... if people in the path of a hurricane are evacuating, one can fit only so much in a car: each person will choose different things that are critical for them.I myself went so far as to compile for EVERY option available in Config.h so I could see which features consumed the most PROGMEM, and then made my own judgement (I chose to abandon SD all together as I use Octoprint almost exclusively). I had originally disabled LCD, but with knowledge of which less-essential features consumed the most resources, I was able to add up a bunch of non-critical-to-me items to omit in order to regain LCD functionality. This is the nature of running comprehensively full-featured software on severely resource-constrained 8-bit micro controllers.I myself am truly amazed at the level of functionality that the Marlin developers have been able to squeeze into these devices with such modest computing power. Consider these MCUs were intended to run thermostats, coin-op vending machines, and Christmas tree light flashers, and here we are running entire 3D printers on them: it's a testament to human ingenuity.But as we near the end of the usefulness for these 8-bit MCUs for this purpose, it will become harder and harder for those on the fringe, not easier. I hope that my annotated Config.h files linked above can help, but taken at a high level, no other open source project I can think of has catered to the lowest common denominator as Marlin has. In fact, it was specifically the advent of Linear Advance that improved my 3 year old Printrbot so greatly that I was compelled to donate a token kickback to the effort.Hats off the all the devs,-=dave

--

@fiveangle Sorry. I didn't see your response in my email this morning. I actually wrote that last night. This surely needed to be its own Feature Request.

I figured that was the case with the PROGMEM usage by the random hints about what could be disabled. I played around with it for a couple days myself so when you say 'a relatively small number of users'. I am looking at everyone with 128k or less which I would figure is a lot of users. In the past year Creality shipped something close to 50k units and Wanhao has probably shipped even more due to Monoprice and Aldi putting more units in peoples hands. So even though everyones looking at 32bit usage, these machines will still be around for a while.

When you say that no other project caters to the lowest common denominator of users, you forgot about Dear Old Linux. I was the one in the shadows writing the configs for dial-up support on Rockwell hardware/software modems, getting the Sound Blaster to work, and getting one of the first Alcatel PCI DSL modems to work when everyone else was running Windows.

Last month I had an issue with my Wanhao i3 Duplicator Plus where I was trying to print with ABS and the printer was shutting down the hot end and bed at the same time with no error messages being displayed on the panel and no errors being logged in Cura (because there are no error logs in Cura apparently when a print fails.) I had already upgraded to their V3.0 firmware and it corrupted my LCD images so I contacted support and they sent me another firmware that had not been released that also was not working.

I literally spent a few weeks trying to figure out what was wrong. I dug through 2 years worth of Google Group support posts. I contacted Wanhao support and wasn't getting anywhere when I decided to try i3 PlusPlus based on Marlin 1.1.1 and it did the same thing and but when it did I received an error message about the Temp Runaway and realized that the suppressed the error message by not including on in their GUI.

image

So that meant the entire time I was having an issue it was because Wanhao set the temps in Marlin where they couldn't be near 255C. So the first thing I did was contact them to get the source so that I could modify it myself and instead they sent me a firmware compiled for 280C.

If I had the source from the very beginning then I would have figured this out in like 10 seconds.

I think the 'configure->compile->review resulting size of sketch method' in this case is like building a car and then realizing that because the engine is too big that the headlights won't fit.

I actually just setup Octoprint for both of my printers a few weeks ago but sometimes you need the card for other people to bring you prints and you don't want to have to rely on a laptop/network to get your prints out. It would be cool if you could use the USB port to do that.

I would be interested in writing such a document but I don't think I have enough info to reliably cover each of the features. I'm essentially just getting started. I would think the example configs that you already built with the memory usage would be something you could add to the example configs folder on a regular basis.

Roxy-3D commented 6 years ago

@Deneteus It really shouldn't be that much work to make UBL fully configurable so the user can pick and choose which portions of it they want. G26 already can be turned off. And UBL can now be used without an LCD Panel in the system. We can go further and make it so the interactive mesh editor and automatic probing are able to be turned off. Or maybe one can be turned on to get the initial mesh and then turned off to make room for the interactive mesh editor later.

None of doing that is 'Rocket Science'. I did have it running on a 128KB PrintRboard 3 or 4 months ago. It should be fairly straight forward to get UBL to work on a 128KB AVR board with a 20x4 LCD Panel. If you want to see how far you can shrink the UBL foot print I'll help coach you to do that.

Deneteus commented 6 years ago

@Roxy-3D

Roxy-3D commented 6 years ago

@Deneteus

It should only take serveral #define's to be added to control features to make it possible to put UBL into a 128KB part. My initial suggestion would be to add support for:

I bet if we get those #define's in place with the corresponding #ifdef's to control code generation, we will be where we need to be. And if we aren't... We should be close enough that we can find the remaining memory to free up so it fits. My suggestion is we do the work on the new (when it gets dropped in place) bugfix-2.0.0 just because that is coming in 5 kb smaller on a fully optioned firmware build. And... that will be the current development branch too.

The #define UBL_NO_WHAT_CMD would be the easiest to implement. Probably the UBL_NO_LCD_SUPPORT would give back the most memory. (Probably... the encoder wheel still works for G29 P4 R's. So technically... it isn't "NO" LCD support. But what I'm suggesting is to cut out all the UBL LCD Menu support functions to do things through the LCD screen.)

Deneteus commented 6 years ago

That sounds like a plan. I can always add an LCD to my Octoprint box so I can tell whats going on without walking to my PC.

fiveangle commented 6 years ago

I put one of the Amazon Fire's that I got on black friday for 40 bucks over my printer for just this purpose. Works great.

Deneteus commented 6 years ago

I was just going to use one of those touchscreen LCD's. Maybe an E.PAPER 3 color.

Deneteus commented 6 years ago

Could you take a look at my configs and tell me if I missed anything?

Marlin 9.26.17 Bugfix Configs .zip

Deneteus commented 6 years ago

Enabled Safe Z Homing and found the Z was flipped from the Example file when homing.

thinkyhead commented 6 years ago

The best starting-point for CR-10 configs is to use this version of Marlin and the CR-10 example configs that come with it. Most recent patch is today, so it might be slightly newer than your current:

https://github.com/MarlinFirmware/Marlin/archive/bugfix-1.1.x.zip

It has the following extra features enabled:

As Roxy points out, the full version of UBL is too large to fit onto the 128K Melzi board. In fact, I can get no automated form of bed leveling to fit within the allotted space using Marlin 1.1 — though I didn't try turning off any features that I wouldn't want to sacrifice. It might be possible to squeeze Mesh Bed Leveling (which is manual) onto the board by turning off just about everything. ABL (Bilinear) isn't as feature-rich as UBL, but it has a smaller footprint.

The "EZABL" version of Marlin is —I'm guessing— not as up to date as bugfix-1.1.x, so it is also able to fit some form of bed leveling (and probably not a lot more). Older versions of Marlin are generally less efficient and not as refined, so it's best to use the most recent version that you can.

Deneteus commented 6 years ago

@thinkyhead - I am already using last nights bugfix version and it fits because I disabled the LCD and a few other features. I also had to set the inset because UBL doesn't use the bed dimensions to constrain where the probe can go till you do. I've been reading all of the posts related to UBL for over 2 weeks. If I can get those changes Roxy talked about to whittle it down even more then I'll be able to enable my LCD again.

Sketch uses 118114 bytes (90%) of program storage space. Maximum is 130048 bytes. Global variables use 3397 bytes (20%) of dynamic memory, leaving 12987 bytes for local variables. Maximum is 16384 bytes.

Roxy-3D commented 6 years ago

Also... There was a separate request to make UBL work without a Z-Probe. That would release all the program memory used to do the various probing functions. I have helped people fake out the printer and bring up UBL without any Z-Probe. It works, and is pretty straight forward especially if the bed is some what level. You just do a G29 P0 to zero the entire mesh and jump straight into G26 and start editing the mesh.

The problem is... To do that, you really need the G26 code. Hopefully, we will be able to turn off enough stuff that G26 can still be turned on for people without Z-Probes on a 128KB processor. I'm thinking when you get your code merged, I'm going to circle back and do the work to make UBL work without a Z-Probe. At worst case, G26 can be re-written to be much smaller and just do long lines centered on the mesh points. That would reduce the code requirements and print time required dramatically.

fiveangle commented 6 years ago

Just a cursory look at your configs and there's countless places to regain PROGMEM.

Your current config:

Sketch uses 107642 bytes (84%) of program storage space. Maximum is 126976 bytes.
Global variables use 3453 bytes of dynamic memory.

With some simple changes:

Sketch uses 95880 bytes (76%) of program storage space. Maximum is 126976 bytes.
Global variables use 3377 bytes of dynamic memory.

Of course still nothing close to enable even a text-based LCD. The only option for bed leveling + LCD on 128k boards is bilinear. Trust me, I've explored every option :)

If @Roxy-3D can untie UBL from automatic probing to get some progmem back, then you might be able to bring UBL up w/o and LCD with G26 validation enabled, then once that's done, disable G26 / re-enable LCD, and go to town.

Until then, I highly suggest enabling Linear Advance. It will improve your print quality better than any other thing, especially with CR-10 if you plan to use any of it's massive size, otherwise you are stuck with 60-100hr for big prints on it. Also, acceleration of 500mm/s is quite slow, especially without Linear Advance, so you really should bump that to 700-1000 for print speeds or you'll get bad bulges on corners, esp. with the long bowden on the CR-10.

fiveangle commented 6 years ago

...complete aside - it astounds me that panels take soooooooo much space to implement. I wonder how @apballard 's Nextion implemenation compares, since the display handles most of the heavy lifting ?

https://youtu.be/4NnOwrkCkYk https://github.com/apballard/Marlin

When I'm not late for work (like now ;) I may compile it to see...

Deneteus commented 6 years ago

Holy cow @fiveangle. I was just thinking about doing the same thing with an external LCD last night. I could have it to send data to my Samung using an app. You could use any small Smart-TV with Android to manage multiple printers info that way just by adding touch via the displays USB port.

Also, I didn't whittle the profile down all the way. I just disabled a couple things so I could use UBL to get some prints done.

@Roxy-3D Working without a Z-probe. What sorcery is this?

Roxy-3D commented 6 years ago

Working without a Z-probe. What sorcery is this?

Well... Instead of using a Z-Probe in the system, it would home using normal endstops. And instead of using a Z-Probe to do the initial probing of the bed, you just set the entire mesh to 0.00mm using G29 P0. Obviously, those values are going to be wrong. But you just jump straight into a G26 / G29 P4 R cycle and edit the mesh to the correct values.

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.