So im trying to configure marlin 2.0.9.3 stable build for my skr 1.4 turbo (LPC1769)
Ive often had issues compiling marlin initally and i think it usually ends up being a library thing. Im mot 100% sure but on my previous board and build that was the case.
Has anyone had more luck compiling the bugfix over the stable build?
The only time I’ve compiled bugfix instead of the main release was for my skr 2 before the build environment had been updated in the release branch.
Otherwise I try to just use the release version since it should in theory be more stable.
I have a habit before compiling in vscode of hitting the trash icon and clearing the previous builds before compiling the new one. I have read that can help give more consistent success with the build.
I haven’t had any issues compiling the last two release versions of Marlin or the previous bugfix.
I’ve found that bugfix is a lot more functional for my controller (Robin Nano V3) than the “stable build”.
What you might want to try is get the manufacturer’s Marlin build and move the platformio & configuration files over to the stable/bugfix builds. This will be a non-trivial amount of work (it took me about six hours), but when I did it I knew which files needed to be validated along with the configuration values with a good build.
I think this is a case of YMMV - I think you need to look at the available sources and figure out what works best for you.
Good luck!
myke
6 hours seems like a really long time. Are you manually going through line by line looking for differences between the sample configuration and your files?
Any time I have updated to a new release I have moved my configuration settings over to the new files and it takes about 30 minutes, maybe an hour. I use a file comparison plugin that highlights in red all of the lines that are different in the two files so you can quickly scroll through to the affected areas and copy values between the two.
I did a kDiff on two the folders and recorded the differences. Next, I did a kDiff on the platformio and configuration files and reviewed the line by line differences and updated the bugfix version.
Next was a build (which had some errors) and I reviewed the failing sources and swapped in the MKS versions of the files where it seemed appropriate. In other cases I could see where the errors were. I went through three build cycles.
The end result, when I burned the firmware into the controller was great - the MKS version was marginal and I then had something that is working fine.
The six hours was up front work that has paid off, I haven’t had any other problems with the firmware build.
Sorry I don’t have a simpler solution for you.
I guess the big difference is that I have never compared any of the files other than the two configuration files. Platformio.ini just needs the build environment line changed, then I compare the configuration ones with whatever settings were working from my last build and tweak as needed if I’m changing out hardware.
I have never looked at the differences in the rest of the Marlin files and folders because I have never had a reason to. The only other file I even open usually is the pins one to confirm numbers for certain settings.
I don’t know if my method is over simplified but it has been working for me and is how I’ve seen other people build their firmware.
I only use bugfix on most of my builds. for me it is quite easy to clean up in ardrino in config.h
Sorry, I always included platformio in the discussion because I forgot copying it over once and that caused me an hour of pulling my hair out.
Going through what I did minimized the chances for problems later on and I did catch a few problems with MKS’s build files being downlevel.
Looking back over the conversation, maybe I’m not completely answering your question and projecting the issues I discovered with the manufacturer’s Github provided files.
Thanks everyone for the input. Ill post at a later time what my current issue with marlin is though ill give the bugfix a shot and see if that corrects my issue.