First layer issues? Look here!  

Re: First layer issues? Look here!

Wow very very nice. That is some funky color

I am currently printing the moon city with a perfect first layer:-)

I try to avoid prints that would benefit from la. Soon the firmware shall come:-)

Re: First layer issues? Look here!

Nice job!
Thaks for sharing your firmware. 🙂

Re: First layer issues? Look here!

Several commits in MK3 since 3.1.2 the other day. Rebuilt firmware (with and without LA) with this fix applied. Interesting stuff included is a change on temperature calibration in relation to the steel sheet, an extrusion multiplier regression fix, and slight change in LA:

03-07-18-NO-LA-testing-pull-514.zip
03-07-18-WITH-LA-testing-pull-514.zip

Had a weird result for the first time with the mesh fixed 3.1.2 LA, overnight print seems to have been on the last top layer and the print just stopped - nozzle/heat/fan still running. The menus worked, was able to retract Z with it and check failures but didn't see any. Will update to the new 3.1.3 versions later today.

Just left a big nozzle mark melted into the part, but it extruded just fine after cleaning off the gunk

Re: First layer issues? Look here!

Had a weird result for the first time with the mesh fixed 3.1.2 LA, overnight print seems to have been on the last top layer and the print just stopped - nozzle/heat/fan still running. The menus worked, was able to retract Z with it and check failures but didn't see any. Will update to the new 3.1.3 versions later today.

Just left a big nozzle mark melted into the part, but it extruded just fine after cleaning off the gunk

I have had this happen twice since having my MK3, and the first time it happened I tried again and had it happen in exactly the same spot. I don't know if this is an issue in the gcode or if it's a particular set of gcode commands pushing calculations up to the point that LA is failing out on an sdcard print. Hopefully that official LA implementation is coming when they say. 🙂

Re: First layer issues? Look here!

Several commits in MK3 since 3.1.2 the other day. Rebuilt firmware (with and without LA) with this fix applied. Interesting stuff included is a change on temperature calibration in relation to the steel sheet, an extrusion multiplier regression fix, and slight change in LA:

03-07-18-NO-LA-testing-pull-514.zip
03-07-18-WITH-LA-testing-pull-514.zip

Had a weird result for the first time with the mesh fixed 3.1.2 LA, overnight print seems to have been on the last top layer and the print just stopped - nozzle/heat/fan still running. The menus worked, was able to retract Z with it and check failures but didn't see any. Will update to the new 3.1.3 versions later today.

Just left a big nozzle mark melted into the part, but it extruded just fine after cleaning off the gunk

hey mattf6, can you please upload the gcode? I would like to take a closer look.

Re: First layer issues? Look here!

Several commits in MK3 since 3.1.2 the other day. Rebuilt firmware (with and without LA) with this fix applied. Interesting stuff included is a change on temperature calibration in relation to the steel sheet, an extrusion multiplier regression fix, and slight change in LA:

03-07-18-NO-LA-testing-pull-514.zip
03-07-18-WITH-LA-testing-pull-514.zip

Had a weird result for the first time with the mesh fixed 3.1.2 LA, overnight print seems to have been on the last top layer and the print just stopped - nozzle/heat/fan still running. The menus worked, was able to retract Z with it and check failures but didn't see any. Will update to the new 3.1.3 versions later today.

Just left a big nozzle mark melted into the part, but it extruded just fine after cleaning off the gunk

hey mattf6, can you please upload the gcode? I would like to take a closer look.

About 15 minutes after I overwrote the SD card file with an updated version to restart the print I thought the same thing - should have saved it. I'm using a flash air sd card so wondered if it was missing that last could lines or something when I saved it, but can't tell now.

Re: First layer issues? Look here!

Hi, I wrote something regarding the temperature calibration in the other thread, for anyone interested in reading it.

Did some digging, in Configuration.h:

...

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

I know Brigandier is aware of this, but can I please ask everyone else never to do this ? The flag is indeed supposed to be set by our buildserver, as is written in the comments there somewhere. By changing it manually, you make your build look like an official one. In case it starts to spread over the internet (and it will happen eventually), there may soon be people on our support reporting bugs in "official" build, that were never even in our repository and are thus impossible to find. There is no way to find out the build is actually from somewhere else, nor to trace the code that was compiled. If you decide you must do it against this appeal, at least make sure it doesn't leave your computer, and whatever you do, don't push the changed source code to your forks.

We are open-source. Everyone is welcome to clone/fork our repository and do whatever they want with it. I just kindly ask you to not make your builds look like official ones. If you don't like a warning, get rid of the warning itself. The FW_REPOSITORY flag will in future too be set by the buildserver, please don't place anything containing "prusa" in it. I hope everyone understands what my worries are. Thank you.

Re: First layer issues? Look here!

I know Brigandier is aware of this, but can I please ask everyone else never to do this ? The flag is indeed supposed to be set by our buildserver, as is written in the comments there somewhere. By changing it manually, you make your build look like an official one. In case it starts to spread over the internet (and it will happen eventually), there may soon be people on our support reporting bugs in "official" build, that were never even in our repository and are thus impossible to find. There is no way to find out the build is actually from somewhere else, nor to trace the code that was compiled. If you decide you must do it against this appeal, at least make sure it doesn't leave your computer, and whatever you do, don't push the changed source code to your forks.

We are open-source. Everyone is welcome to clone/fork our repository and do whatever they want with it. I just kindly ask you to not make your builds look like official ones. If you don't like a warning, get rid of the warning itself. The FW_REPOSITORY flag will in future too be set by the buildserver, please don't place anything containing "prusa" in it. I hope everyone understands what my worries are. Thank you.

Hi Lukas,

I understand 100%, thus why I haven't released any with this change; however, we do have several people wanting to help with testing new firmware but unable to do so because this warning message is causing issues with USB communication. Is there any chance of getting the message adjusted so that this isn't the case? That's the only reason this is even being discussed. 🙂

Thanks!

Re: First layer issues? Look here!

I'm actually working on Slic3r and not FW, so I may be wrong here, but there is a function show_fw_version_warnings() in Marlin_main.cpp, that might have some significance here. Changing this function is nothing we would like others to do either, but it is still better way than changing the build designation. I hope I understood what bothers you correctly.

Re: First layer issues? Look here!

I'm actually working on Slic3r and not FW, so I may be wrong here, but there is a function show_fw_version_warnings() in Marlin_main.cpp, that might have some significance here. Changing this function is nothing we would like others to do either, but it is still better way than changing the build designation. I hope I understood what bothers you correctly.

Yep you understand, and the function checks the current value set on FW_DEV_VERSION. It's my understanding from USB users (I use sdcard personally), that USB communication won't work until the message is confirmed and off the screen. This puts us at either lying to the function to get it to let us pass, editing the function to do something differently than you guys intended, or disable the call to the function in general. This causes a lot of extra work if we want to release a .hex for testing, and we don't want to modify this and have it end up in a pull request back to prusa-firmware. I also don't want to get rid of it, I love the disclaimer that my firmware may smoke someone's machine. It would just be nice to do it in a way that doesn't impair functionality to the point some people are having troubles testing it.

Maybe something like a timeout on the message, so it continues past after say 10 seconds and allows USB communication to continue? And maybe also some item for support guys to ask about (i.e., "DEV" on the LCD home screen), so you can quickly confirm if someone is doing stupid things when they call in? 🙂

I will investigate it and see what I can come up with. Would this be a good item to throw up on the issues board on Github?

Re: First layer issues? Look here!

A timeout might be a really good idea. I saw there is a timer class coming in an upcoming version. Maybe one could set up a timer to dismiss this screen as you have proposed.

But to be honest: I do not even know if that would fix the USB connectivity problem at all:-)

Re: First layer issues? Look here!

A timeout might be a really good idea. I saw there is a timer class coming in an upcoming version. Maybe one could set up a timer to dismiss this screen as you have proposed.

But to be honest: I do not even know if that would fix the USB connectivity problem at all:-)

Bleh, I guess I will give in and set up Octoprint so I can test. 🙂

Re: First layer issues? Look here!

I have this message and no issue with Octoprint, you just have to dismiss the message before Octoprint times out. No big deal.

Re: First layer issues? Look here!

A timeout might be a really good idea. I saw there is a timer class coming in an upcoming version. Maybe one could set up a timer to dismiss this screen as you have proposed.

But to be honest: I do not even know if that would fix the USB connectivity problem at all:-)

Bleh, I guess I will give in and set up Octoprint so I can test. 🙂

I used your LA firmware over the weekend with a Raspberry Pi 3 B without issue, (except of course for the unofficial message of course) I reverted for the weekday as I tend to queue and watch prints from work and can't do that with the nag screen that comes up using the unofficial firmware. I'm not a coder but am seriously considering trying to figure out how to make your changes, remove the nag and compile the firmware myself. Care to post a brief instructional? FWIW, I see a definite improvement using Linear Advance, or at least whatever combination of tweaks there are in the firmware and for that I thank you.

Re: First layer issues? Look here!

A timeout might be a really good idea. I saw there is a timer class coming in an upcoming version. Maybe one could set up a timer to dismiss this screen as you have proposed.

But to be honest: I do not even know if that would fix the USB connectivity problem at all:-)

Bleh, I guess I will give in and set up Octoprint so I can test. 🙂

I used your LA firmware over the weekend with a Raspberry Pi 3 B without issue, (except of course for the unofficial message of course) I reverted for the weekday as I tend to queue and watch prints from work and can't do that with the nag screen that comes up using the unofficial firmware. I'm not a coder but am seriously considering trying to figure out how to make your changes, remove the nag and compile the firmware myself. Care to post a brief instructional? FWIW, I see a definite improvement using Linear Advance, or at least whatever combination of tweaks there are in the firmware and for that I thank you.

Considering the huge amount of commits that just went in yesterday, and considering that LIN_ADVANCE looks to be enabled by default again (I am guessing v1.5), I would just wait. I have a feeling we're about to get some firmware dropped on us ( https://github.com/prusa3d/Prusa-Firmware/pull/557/files ) with a completely new LIN_ADVANCE implementation ( https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/Configuration_adv.h#L314 see comment starting at line #314, the M900 command is changing ), and it's likely going to require updated Slic3r profiles to use. 🙂

Disregard, I am blind. Lots of commits, still LA v1.0.

Re: First layer issues? Look here!

That's still the original Linear Advance implementation, nothing has changed much. The M900 command you are referring to is another option to set the Linear Advance E:D ratio - that has always been there and in that form.

Re: First layer issues? Look here!

That's still the original Linear Advance implementation, nothing has changed much. The M900 command you are referring to is another option to set the Linear Advance E:D ratio - that has always been there and in that form.

You are correct. I thought they were upgrading to v1.5 with the re-enable and assumed incorrectly. Thanks for the heads up.

Re: First layer issues? Look here!

That's still the original Linear Advance implementation, nothing has changed much. The M900 command you are referring to is another option to set the Linear Advance E:D ratio - that has always been there and in that form.

You are correct. I thought they were upgrading to v1.5 with the re-enable and assumed incorrectly. Thanks for the heads up.

so are they going to carry on with LA V1 or going to use the V1.5, I know some people are getting some great results with V1.5 on other REPRAP machine using it?

I'm no expert but could the LA V1.5 Code be brought into the PRUSA branch for another "Custom" Firmware?

Re: First layer issues? Look here!

That's still the original Linear Advance implementation, nothing has changed much. The M900 command you are referring to is another option to set the Linear Advance E:D ratio - that has always been there and in that form.

You are correct. I thought they were upgrading to v1.5 with the re-enable and assumed incorrectly. Thanks for the heads up.

so are they going to carry on with LA V1 or going to use the V1.5, I know some people are getting some great results with V1.5 on other REPRAP machine using it?

I'm no expert but could the LA V1.5 Code be brought into the PRUSA branch for another "Custom" Firmware?

Yes, the author of the v1.5 code in marlin has already done so: https://github.com/prusa3d/Prusa-Firmware/pull/504

Re: First layer issues? Look here!

You are correct. I thought they were upgrading to v1.5 with the re-enable and assumed incorrectly. Thanks for the heads up.

so are they going to carry on with LA V1 or going to use the V1.5, I know some people are getting some great results with V1.5 on other REPRAP machine using it?

I'm no expert but could the LA V1.5 Code be brought into the PRUSA branch for another "Custom" Firmware?

Yes, the author of the v1.5 code in marlin has already done so: https://github.com/prusa3d/Prusa-Firmware/pull/504

Nice!! So has it been merged (if that’s the right term) in Prusa firmware?
I’m still getting to grips with git hub lol