Marlin firmware errors compiling

post your config files and very importantly which version of marlin you are trying to compile and I can try to compile it for you

getting them for github

This does not tell us anything. Please provide a link to where you downloaded your version of Marlin.

If you made any changes in the configuration.h or configuration_Adv.h, please put them in a ZIP file and attach them to a post using the upload button:

UploadIcon

Please put your errors in a text file and attach them to a post.

With this information, someone may see the problem, or if not, Covur2606 has volunteered to compile your specific version to see if he can spot the problem.

zip.zip (70.5 KB) file must be renamed zip.7z to work. website won’t let me send .7z file, so I had to rename it zip, sorry.so rename zip.zip to zip.7z

zip.zip (70.5 KB) rename zip.zip zip.7z, site won’t let me upload .7z files, so I renamed it zip.zip from zip.7z

There were a few problems in your config. The PlatformIO.ini was referring to a mega2560 as the board, but the SKR Mini E3 V2 is a STM32F103RC_btt, that’s what was causing most of your errors.

The errors relating to Mesh levelling and z offset not being valid are correct. with the BLTouch, you dont need to enable any of the mesh levelling config, instead you enable the bltouch specific definitions.

you need to go through the configuration.h in the attachment and adjust the x and y offsets for your probe (line 985), I can’t guess those, you need to measure them, fill them in and then compile
if you don’t do this, you will have problems with it probing in the wrong place, possibly even missing the bed and crashing your nozzle into the bed

compiled.zip (84.3 KB)
I’ve not included the bin file as in its current format it could cause damage to your printer.

1 Like

There are two threads on this now. Let’s try to keep this contained:

i TRIED IT ITDIDN’TWORK THIS TIME EITHER. iDON’T KNOW WHAT’S WRONG

what errors are you getting when compiling the configuration I sent you? I can’t help if the only thing I know is that it didn’t work. That compiled fine on my environment in both VS Code and in Atom with the latest version of PlatformIO

Hey, I know this can be frustrating, but there are several people trying to help you and there are a dozens reasons why they don’t have to.

If you think it is frustrating sitting at the keyboard getting these errors, imagine being these people who are trying to help and only have a fraction of the information.

A little kindness and a little patience will go a long way here.

Rest assured, it is not magic. There is a solution and there are a lot of people who can find it. Be confident that this will work out if we get the right piece of information.

are you getting an error like this:

“Error: Build environment ‘LPC1769’ is incompatible with BOARD_BTT_SKR_MINI_E3_V2_0. Use one of these: STM32F103RC_btt, STM32F103RC_btt_512K, STM32F103RC_btt_USB, STM32F103RC_btt_512K_USB”

though yours probably says ‘mega2560’ rather than ‘LPC1769’?

even once changing to the correct build environment and downloading all required resources i get compile errors too.

specifically the config files are out of date for marlin 2.0.x 3/25/21 release.

The config files that he sent compiled without error on Marlin 2.0.7.2 (latest release on the github) once I had selected the right build environment and changed mesh levelling over to bltouch

i’m using the bugfix version, maybe that’s the difference? the Config file you sent is version 20007 the one i use is 20008 so its only one version out of date for me.

@deanembrey what version of marlin are you trying to compile?

I was wondering if you could send me the bin file and Ill check it out. My bet is an old magnetic one. and I don’t think it will hurt anything. If i can get it running I can figure out why I’m running into errors. got to know if it works. By the way i have dual z motors. the one’s the go up and down they go slow. until I get them out of parallel and hook the other one in the second z plug port.

The duel z could be the cause of some of your layer issues. Have you tried running without the second z?

A second leadscrew without proper alignment and greasing can cause the tramming to be different at different z heights. I bought my e3 pro used with duel z and removed it because it caused problems.

Also unless you have a really heavy hotend (like a large direct drive extruder or duel hotends) a second z axis doesn’t help on a machine the size of the ender3

If you do decide to keep it and have it wired in parallel (as you described) make sure to double your z motor current.

IT did the same with it I measured from the bed to bar on both sides, and squared everything all around. I have a slope in the bed. I can’t understand, i pull a marlin build off line on github and everyone swears it works good, same system as mine. I try to build in vscode and it goes to errors. I uninstall vscode, and try it again same thing

1 Like

Are you using somthing like marlin builder? If your pulling a whole marlin repository and it is not compiling with out you making any changes to it. That makes me belive that you are in the wrong environment or have missing resources.

I did that everything worked. So that rules out my computer causing it .

Just to be clear, when I say resources I’m not talking about what your computer can do. But rather if you have all the proper files for the board your trying to compile for. My skr1.4 turbo requires resources for the LPC1796 chip set that it uses. These where not on my computer originaly and so I needed to download them.

I think @jeffeb3 includes all of those resources for the specified board inside of marlin on the v1 git repository so that they don’t need to be downloaded separately. This would not be the case for your e3 mini.

No, I don’t. Platformio has it’s own package management system. There is a teaching tech version of Marlin that doesn’t compile anymore because it doesn’t work with the latest tmc library. It is really frustrating when that happens.

We take the vanilla marlin code, configure it for a specific board/machine, delete some files we know we won’t need (in HAL, if you care). We compile the bin or hex and zip it up.

I have only seen one error and it seemed like a configuration issue.

1 Like