Compiling Marlin from Source, Integrating *.config #defines

I’m on a learning journey, so forgive my ignorance…

Starting out by acknowledging that the source files for the Lulzbot fork of Marlin can be found here:

…and also acknowledging that compiled printer-specific *.hex files and *.config firmware files (multiple versions) can be found here:

http://devel.lulzbot.com/software/Marlin/

…how do I correctly incorporate all of the #define statements from a given firmware version *.config file into the source code and effectively compile an identical *.hex file? Is it simply a matter of (arduously) searching through the Configuration.h and Configuration_adv.h (…and Configuration_LulzBot.h? Are there others?) files for the appropriate matching #define lines and copying in the values from the *.config file? …or is there a better/more correct way?

My end goal (near term) is to create a custom firmware version for my Taz 6 with an expanded BUFSIZE and BLOCK_BUFFER_SIZE to try and correct some stuttering issues I have when using Octoprint. I want to make sure I’m starting from the same “factory version” that I’m currently running (1.1.9.28; yeah I know I should be on 1.1.9.34).

Thanks!

I don’t run lulzbot or marlin firmware (though I have compiled it for lulzbots in the past, and it is a bit of a pain), so can’t help with the compilation settings. But depending on what is causing your stuttering, buffer size alone may not fix it, as the 2560 can become constrained for other reasons.

I had stuttering/pausing issues on three printers with octoprint (running klipper), and fixed all three just by culling plugins. Octoprint has a rich plugin library, but they can sometimes come at the expense of print quality (even though the processor isn’t being pegged). I still run plug-ins, but just try to keep them to core functionality.

Also note that there is the Arc welder plugin which tries to address stuttering by replacing large numbers of small linear moves with a single arc move. Cool stuff!

Finally, before going through the adventure of recompiling marlin just to increase buffer size, I might try klipper. All communications with the mcu are compressed by default, as it moves Gcode processing to the pi. If you’re not running trinamic drivers, it also has a noticeable impact on printer noise (not to mention speed and quality). And config changes or hardware upgrades just require simple editing of a single config file.

+1 for Klipper, I really like it on my mini + octoprint

Thanks for the replies!

I initially thought I might be hamstringing myself with plugins as well, but even with bone “stock” OctoPi and OctoPrint, I was still experiencing stuttering/random pauses. I’ll have to give Arc Welder a look, though.

My hesitation with Klipper is that I’d still like my printer to be functional using just the SD card slot, and as I understand things, Klipper would kill that.

edit

I also have future ambitions of adding a BLTouch to my setup, so I thought figuring out how to incorporate a simple buffer size increase would be a good toe-dip into compiling my own firmware.

Gotcha. I can respect not letting go of the bumper! :wink:

The lulzbot firmware is built using a combination of printer model and toolhead info. They maintain one codebase, and just compile firmware against specific hardware profiles. I believe there is a shell script that takes printer/toolhead arguments and outputs the corresponding configuration files required by Marlin. You can see examples of the configs generated for various printer/toolhead combination in this directory.