First layer issues? Look here!  

Re: First layer issues? Look here!

I don’t know tons about github, but I’m seeing lots of versions of firmware pop up on the forum each with there own tweeks and improvements. Its great everyone is putting the time in.

What confuses me is how do you know if the pull requests are adopted back i to the original prusa firmware, is it when they then become closed?

Thanks

Re: First layer issues? Look here!

I don’t know tons about github, but I’m seeing lots of versions of firmware pop up on the forum each with there own tweeks and improvements. Its great everyone is putting the time in.

What confuses me is how do you know if the pull requests are adopted back i to the original prusa firmware, is it when they then become closed?

Thanks

Closed doesn't necessarily mean that it was added to the MK3 branch. Usually a dev makes a branch to test new code, then when they are ready they put in a pull request (sometimes called a merge request). If Prusa thinks the code is good, they merge it in to the MK3 branch.

Here's an example of some new code that was merged in, note the merge commit at the bottom of the comments: https://github.com/prusa3d/Prusa-Firmware/pull/509

You can also look at the commits on the MK3 branch. Merges will show up there too. 🙂

Re: First layer issues? Look here!

Hej Brigandier!

Awesome! Thank you for spreading the word!

My Bug fix has nothing to with LA - just if anybody wonders. In general I think the first layer issues have nothing to do with LA being deactivated. No, I do not think: I KNOW from a lot of pain...

I find it funny that now several custom firmwares are making the rounds.:-)

Lets hope Prusa reviews my pull request quickly so it is introduced into the stock firmware.

Re: First layer issues? Look here!

I don’t know tons about github, but I’m seeing lots of versions of firmware pop up on the forum each with there own tweeks and improvements. Its great everyone is putting the time in.

What confuses me is how do you know if the pull requests are adopted back i to the original prusa firmware, is it when they then become closed?

Thanks

Closed doesn't necessarily mean that it was added to the MK3 branch. Usually a dev makes a branch to test new code, then when they are ready they put in a pull request (sometimes called a merge request). If Prusa thinks the code is good, they merge it in to the MK3 branch.

Here's an example of some new code that was merged in, note the merge commit at the bottom of the comments: https://github.com/prusa3d/Prusa-Firmware/pull/509

You can also look at the commits on the MK3 branch. Merges will show up there too. 🙂

Thanks 🙂 GitHub takes some working out for me still lol

Re: First layer issues? Look here!

I tried this firmware out and somehow it broke connectivity to Octoprint. When I try to connect the I3 shows the boot display and just gets stuck there. Flashed back to the official 3.1.2 firmware and it's fine again.

Re: First layer issues? Look here!

I tried this firmware out and somehow it broke connectivity to Octoprint. When I try to connect the I3 shows the boot display and just gets stuck there. Flashed back to the official 3.1.2 firmware and it's fine again.

Interesting. If you went with the no LA option, it's literally a - changed to + difference from what is on the Prusa downloads page, assuming they compiled straight from the MK3 branch.

Re: First layer issues? Look here!

I tried this firmware out and somehow it broke connectivity to Octoprint. When I try to connect the I3 shows the boot display and just gets stuck there. Flashed back to the official 3.1.2 firmware and it's fine again.

Interesting. If you went with the no LA option, it's literally a - changed to + difference from what is on the Prusa downloads page, assuming they compiled straight from the MK3 branch.

Exactly. Did did you use the firmware with LA? Or without?
I would flash the firmware again. If Brigandier put here my build (@Brigandier: Did you?) then the first thing after boot is a warning screen where you have to confirm that this is an unofficial build and you know what you are doing. While this screen is shown, serial communication is blocked (The setup() function does not even finish). So maybe you can also try to disconnect octoprint until you have confirmed that start up warning screen!

Re: First layer issues? Look here!

I tried this firmware out and somehow it broke connectivity to Octoprint. When I try to connect the I3 shows the boot display and just gets stuck there. Flashed back to the official 3.1.2 firmware and it's fine again.

Interesting. If you went with the no LA option, it's literally a - changed to + difference from what is on the Prusa downloads page, assuming they compiled straight from the MK3 branch.

Exactly. Did did you use the firmware with LA? Or without?
I would flash the firmware again. If Brigandier put here my build (@Brigandier: Did you?) then the first thing after boot is a warning screen where you have to confirm that this is an unofficial build and you know what you are doing. While this screen is shown, serial communication is blocked (The setup() function does not even finish). So maybe you can also try to disconnect octoprint until you have confirmed that start up warning screen!

The "no LA" option is the current MK3 branch with an edit to line 3762 of Marlin_main.cpp to change - to + per the pull request. I can confirm I am getting the "use at your own risk" prompt as well, so I suspect you're correct. Wasn't aware serial communication was blocked before the prompt is confirmed, good to know. 🙂

Re: First layer issues? Look here!

I'm getting first layers issues, and assumed part of it WAS the LA, since it's overstuffed corners where I get the lift, every time. That said, it's fairly consistently in the upper right corner of the bed, which I'd like to see better leveled. My top surfaces have not liked the LA issue at all. I hate to change two things at once, but...

In short, I'll give the LA version of this a whirl in a bit, get back with results.

Re: First layer issues? Look here!

I'm getting first layers issues, and assumed part of it WAS the LA, since it's overstuffed corners where I get the lift, every time. That said, it's fairly consistently in the upper right corner of the bed, which I'd like to see better leveled. My top surfaces have not liked the LA issue at all. I hate to change two things at once, but...

In short, I'll give the LA version of this a whirl in a bit, get back with results.

I agree on not changing more than one thing at once. I have only included the LA enabled version because I prefer it enabled and only print from sdcard, it has zero bearing on this issue. Just thought having the LA option might prompt others to test the code edit. 🙂

Re: First layer issues? Look here!

I tried this firmware out and somehow it broke connectivity to Octoprint. When I try to connect the I3 shows the boot display and just gets stuck there. Flashed back to the official 3.1.2 firmware and it's fine again.

Interesting. If you went with the no LA option, it's literally a - changed to + difference from what is on the Prusa downloads page, assuming they compiled straight from the MK3 branch.

That may be the only code change, but whatever compile flags result in the warning message about it not being official firmware results in it interfering with Octoprint's ability to connect.

It'd be great to get a version of this without that warning...

Re: First layer issues? Look here!

While this screen is shown, serial communication is blocked (The setup() function does not even finish). So maybe you can also try to disconnect octoprint until you have confirmed that start up warning screen!

Octoprint causes the printer to start from boot when it connects, so I'm guessing this is why Octoprint is broken. There's no way to disconnect octoprint until after that warning screen because it's the Octoprint connection in the first place that results in the printer booting again.

Re: First layer issues? Look here!

Octoprint causes the printer to start from boot when it connects, so I'm guessing this is why Octoprint is broken. There's no way to disconnect octoprint until after that warning screen because it's the Octoprint connection in the first place that results in the printer booting again.

Did some digging, in Configuration.h:

// Firmware version
#define FW_VERSION "3.1.2"
#define FW_COMMIT_NR 231
// FW_VERSION_UNKNOWN means this is an unofficial build.
// The firmware should only be checked into github with this symbol.
#define FW_DEV_VERSION FW_VERSION_UNKNOWN
#define FW_REPOSITORY "Prusa3D/MK3"
#define FW_VERSION_FULL FW_VERSION "-" STR(FW_COMMIT_NR)

// Debug version has debugging enabled (the symbol DEBUG_BUILD is set).
// The debug build may be a bit slower than the non-debug build, therefore the debug build should
// not be shipped to a customer.
#define FW_VERSION_DEBUG 6
// This is a development build. A development build is either built from an unofficial git repository,
// or from an unofficial branch, or it does not have a label set. Only the build server should set this build type.
#define FW_VERSION_DEVEL 5
// This is an alpha release. Only the build server should set this build type.
#define FW_VERSION_ALPHA 4
// This is a beta release. Only the build server should set this build type.
#define FW_VERSION_BETA 3
// This is a release candidate build. Only the build server should set this build type.
#define FW_VERSION_RC 2
// This is a final release. Only the build server should set this build type.
#define FW_VERSION_GOLD 1
// This is an unofficial build. The firmware should only be checked into github with this symbol,
// the build server shall never produce builds with this build type.
#define FW_VERSION_UNKNOWN 0

Looking like Prusa's build pipeline automatically changes this when they do RC or GOLD releases so it doesn't error out. Anyone compiling directly from source will have the error message. Of course, you can pull it and make stahlfabrik's change plus edit this bit of code here to force it. 😉

The bit you are wanting is this line:

#define FW_DEV_VERSION FW_VERSION_UNKNOWN

It gets checked later on to see if it's set to FW_VERSION GOLD or FW_VERSION_RC to determine if the message should be shown or not. You can change the above define line to the following:

#define FW_DEV_VERSION FW_VERSION_GOLD

and it should go away; however, I don't think Prusa would appreciate it if you posted it up, thus why I am giving you the instructions vs posting a hex with the changes. 🙂

Re: First layer issues? Look here!

Interesting, I had added in a preheat for the pinda at the start of each print, but using this firmware should mean I can remove it?

Re: First layer issues? Look here!

Looking like Prusa's build pipeline automatically changes this when they do RC or GOLD releases so it doesn't error out. Anyone compiling directly from source will have the error message. Of course, you can pull it and make stahlfabrik's change plus edit this bit of code here to force it. 😉

Way too much work, I'll just wait for them to merge this and get an official firmware 🙂

Re: First layer issues? Look here!

Interesting, I had added in a preheat for the pinda at the start of each print, but using this firmware should mean I can remove it?

Yes. That is the plan

Re: First layer issues? Look here!

I'm getting first layers issues, and assumed part of it WAS the LA, since it's overstuffed corners where I get the lift, every time. That said, it's fairly consistently in the upper right corner of the bed, which I'd like to see better leveled. My top surfaces have not liked the LA issue at all. I hate to change two things at once, but...

In short, I'll give the LA version of this a whirl in a bit, get back with results.

I am sorry to say but for that issue this fix might help nothing because it is not about temperature and repeatability.
From your description your problem is very consistent. Maybe you have a warped bed or need to experiment with the +-50um bed level correction settings?
Of course potential temperature fluctuations will not HELP with your problems and stock firmware either:-)

Re: First layer issues? Look here!

I'm getting first layers issues, and assumed part of it WAS the LA, since it's overstuffed corners where I get the lift, every time. That said, it's fairly consistently in the upper right corner of the bed, which I'd like to see better leveled. My top surfaces have not liked the LA issue at all. I hate to change two things at once, but...

In short, I'll give the LA version of this a whirl in a bit, get back with results.

I am sorry to say but for that issue this fix might help nothing because it is not about temperature and repeatability.
From your description your problem is very consistent. Maybe you have a warped bed or need to experiment with the +-50um bed level correction settings?
Of course potential temperature fluctuations will not HELP with your problems and stock firmware either:-)

With the z-offset fix I am definitely seeing more consistent first layer height, but I am also seeing a portion of my bed that seems to stay consistently low (the center). It's close enough most prints work, but there's a visible variation across large parts. I haven't seen this +-50um setting you mentioned, is it hiding out in the menu or is this another code change someone has floating out there? Curious to try it, I am guessing it allows the mesh level correction to correct a bit further? 🙂

Thanks

Re: First layer issues? Look here!

It is somewhere in the menu. For the front, back, left and right you could set a manual offset of very small steps in a small range. So if your middle is to high, you theoretically could raise the front, back, left and, right.

You will find the infos here:
https://help.prusa3d.com/l/en/article/TPGip0OmaP-bed-level-correction-kit-only

Oh and THANK YOU! You are the first to finally report back that my fix improves things:-) Have gotten no feedback yet what so ever. I am still 100% convinced that this is it.