Prusa-firmware: How to do extruder calibration in 3.0.12

[GurliGebis]

Since 3.0.12 has been released, E-steps is no longer read or written to the EEPROM.

So, how are we supposed to calibrate the extruder, when it doesn't extrude the amount of filament it is asked to? Recompiling the firmware with our own, unique special values?

Please add some other way to do this, or maybe change the firmware, so the SM and MM versions has a different version, so they clear the values when switched around - that way the default values would be loaded.

Having to use the default, hardcoded E-steps that almost never is entirely correct for anyone, is a step in the wrong direction......

[probonopd]

Having to use the default, hardcoded E-steps that almost never is entirely correct for anyone

How can I know?

[GurliGebis]

Follow the guide here: https://mattshub.com/2017/04/19/extruder-calibration/
But if you have upgraded to 3.0.12, don't bother, since the value can no longer be saved - you might be able to hack it into your slicer software start g-code.

To Prusa Research - this really should be worked around in the multi material installation instructions, telling people to calibrate the extruder, instead of crippling it for the rest of us.

[3d-gussner]

Hi Gurli,

I guess you to change https://github.com/prusa3d/Prusa-Firmware/commit/f89ba2c46aed55d0bfd7464a7057183526d7772b#diff-a940a548ba41bc988f99d51fd02f21de but please also the last one
check https://github.com/prusa3d/Prusa-Firmware/commit/f89ba2c46aed55d0bfd7464a7057183526d7772b it should be back.

[GurliGebis]

@3d-gussner okay, now I'm confused, you are indeed right.
Seems like I have to stop looking at commits directly and instead compare tags.

I'll close this ticket, thanks.

[GurliGebis]

@3d-gussner I was right - 3.0.12 overwrited the E-steps with the default value.

Have a look here: https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/ConfigurationStore.cpp#L354

[GurliGebis]

@bubnikv @PavelSindler any input on this?

[MartinMajewski]

This is the most unpleasant decision made since a long time by the firmware development team. The single material E-Steps values (161.30 is the default value) are too large for both of my single extruder machines, resulting in over-extruded, out-of-size models. I updated the firmware, set the correct steps and today all of my models are only good for the trash bin. Thank you! *mad
Please revert this behavior for the single extruder firmware!!!

[GurliGebis]

@MartinMajewski I have found a workaround until PR decides to fix this mess (one can always hope...)
Update your start gcode in your slicer, so it starts by running this command:

M92 E###.# where ###.# is your E-steps.
That way, it will be set in memory before the print start, which is after the firmware has overwritten it with the default value.

[MartinMajewski]

Yes, this is also my solution for now. But I don't think it is a good one as the behavior of the firmware is only documented inside the changelog. So no one who doesn't flashed the firmware and played with the settings will know. And when I switch to another slicing software I have to remember to add this line.

[probonopd]

Is it even possible to add a custom GCODE to PrusaControl?

[GurliGebis]

@MartinMajewski I totally agree, but until (if at all) it gets changed back, that is the only option (apart from fixing the firmware and compiling it yourself) :)

@probonopd not likely, since it is supposed to be a simplified version of Slic3r, where the advanced parts have been hidden from the user.
If you use Slic3r (or some other slicer, I have only used Slic3r), you can change the start gcode :)

[thess]

Hey folks, I may be wrong here but I don't think the 3.0.12 released version has the problem you are talking about here. If you look at commit 0473b7e0db4f86b1224450777da01d053196b10a which is the tagged version for release, you will see that the EEPROM and M500 functionality has been perserved. Between commit f89ba2c46aed55d0bfd7464a7057183526d7772b and 0473b7e0db4f86b1224450777da01d053196b10a it was indeed very, very broken and required a complete reset after flashing due to firmware layout changes - bad.

I have not verified that .hex file downloads from the support page are actually identical to the release sources, but the github source download is correct.

Addendum: The release notes are just plain wrong in this respect since the code is OK.

[GurliGebis]

@thess I thought so too, but take a look here: https://github.com/prusa3d/Prusa-Firmware/blob/MK2/Firmware/ConfigurationStore.cpp#L354 (and the one right above it)

That line overwrites the E-steps value in memory with the default value.

[Matts-Hub]

I would also like to express my disappointment in this change to the firmware.

From the changelog:

"Using M500 (for example running PID tuning) with single material printer and then upgrading to multi material leads to faulty extruder behavior. Thus axis steps per unit for extruder were excluded from M500."

How exactly does a PID tune lead to faulty extruder behaviour after upgrading to MMU? And how would excluding axis steps per unit change this.. it's completely unrelated to PID tuning.

[Matts-Hub]

@GurliGebis Would it be possible to just take out those lines that overwrite the saved e steps value and recompile the firmware so they are persistent once again? Then we would still be able to set/edit the e steps with M500, correct? Or is it much harder than just removing those few lines

[GurliGebis]

How exactly does a PID tune lead to faulty extruder behaviour after upgrading to MMU? And how would excluding axis steps per unit change this.. it's completely unrelated to PID tuning.

@Quintox303 This is because running M500 writes all settings to the EEPROM, including the default E-steps value, which means that now the SM default value is written to EEPROM, instead of the value that would normally be there, which can be read as empty, which means it will use the default value configured in the firmware.
So when upgrading to MM, and the value in the EEPROM is not empty, it reads and uses that, which is what is causing this problem.

Regarding removing those two lines (353 and 354), yes, that would revert it back to the original behaviour - but now you have to maintain it for every future firmware version you want to use, which is going to be alot of work. For now, until Prusa Research hopefully fixes this issue, I would go for adding the M92 hack to your startup gcode script, so it gets set in memory every time a print starts.

[probonopd]

So wouldn't the proper solution be to tell people who are upgrading to MM to entirely reset the firmware and all of the stored values?

[GurliGebis]

A factory reset should erase all the stored values, so yes, that would indeed be a better solution (and it really should be recommended anyway, when doing major changes like this)

[Sebastianv650]

Using M500 (for example running PID tuning) with single material printer and then upgrading to multi material leads to faulty extruder behavior. Thus axis steps per unit for extruder were excluded from M500.

I'm also a little bit confused about this change. If I understand the problem, it happens during the MM upgrade when the user flashes the MM firmware but doesn't reset the EEPROM values.
For upgrading bigger parts of the printer or doing mayor version jump to another FW, it's a usual thing to do a:
M502 (load FW defaults)
M500 (store them to EEPROM)

If this is true, it means this change is only a work around so the user doesn't need to issue this commands. A very bad workaroung in my eyes, as this issue here is showing up. In this case, I would recommend to have a .gcode file on the SDcard, named something like "load MM defaults" which starts this two commands. Problem solved..

[GurliGebis]

@Sebastianv650 that would also be an option.
The problem really is, that it seems like Prusa Research doesn't care, which leads me to think their plan is something along the way of: "We know best, now be quiet and forget you ever was able to do extruder calibration" :(

It would take them 5 minutes to give a statement about them being aware of the problem, and say that they are working on a fix. But that is not likely to happen I think - you are all free to interpret that as you want :)

(Sorry if I sound bitter, but I have reached the point of not trying to do anything to help PR, since they don't seem to even want to respond when you contact them in here)

[Sebastianv650]

@GurliGebis I absolutely understand your frustration. As end users, we only see what's happening here on Github. And regarding Prusa Firmware, in fact that's not much. I hope it's due to havy work in the background, but we can't tell.
While I understand they do things like they think it's best in the end (the few people here might not be representative for the mayority of the users), I would also whish some more feedback.

But there should be an easy solution. In fact at least at this time there is not a high commit frequency. Therefore it should be not that time consuming to create a fork of this FW as a "Developer Prusa Firmware" or "Advanced user Prusa FW" where commits as the discussed one will be erased and PRs will be merged fast if the creator states it's printing fine and the code looks OK.
I think we should avoid a development away from this FW in any case, so PRs should always be created against this original branch and then merged into the fork.
Then, if there are useful commits here, a rebase will be all that has to be done to stay up to date.

Your opinion?

[GurliGebis]

@Sebastianv650 I would like that idea, and the thought has crossed my mind.
I do fear that Prusa Research might not like it, if a fork of the firmware starts getting advertised to users, since I'm pretty sure they would like complete control if they could have it.

If you plan on doing it, remember to include your LIN_ADVANCE code :)

[Sebastianv650]

I do fear that Prusa Research might not like it, if a fork of the firmware starts getting advertised to users.

That's for sure, we can't recommend it to "every" user and the Prusa team might end up with issues they will complain about we introduced. But I think the "normal" users will not arrive here at githup. It would be something for users like @MartinMajewski or you which complains about something isn't right. This people usualy know how to work with github and which person they have to "hit" if something isn't working.

I'm not sure if I'm the best one to do the fork as I'm only working with this FW in regards of LIN_ADVANCE up to now and my git command line knowledge is quite low. But if no one else will do it, maybe I find some time to give it a try.

[GurliGebis]

Doing it isn't the hard part, it is having to support it afterwards that I haven't got time for :)

[Sebastianv650]

Supporting it should be a thing of git rebase prusa3d/Prusa-Firmware. I will try if it works this way.

[GurliGebis]

@Sebastianv650 Not that kind of support I'm talking about.
If people run the non-official firmware, odds are most likely, that Prusa Research will just send them away and tell them to flash the original firmware if they want any help from them.
So if people have problems, they will be coming to you, which is what I meant by support ;-)

[Sebastianv650]

Yes and no. If the problem is due to a PR that is not yet merged into MK2 branch, it's good if somebody finds a problem and comes to us.
If it's a problem also existing in MK2 branch (not related to our changes), that has to be prooven by flashing the original FW. Than, they can create the issue here. Therefore I see no additional support than the normal bugs that might be introduced by fresh PRs.

[GurliGebis]

I see your point :)

[bubnikv]

It would take them 5 minutes to give a statement about them being aware
of the problem, and say that they are working on a fix. But that is not
likely to happen I think - you are all free to interpret that as you want :)

We are aware of the problem and we are working on a fix.

On Sun, Jul 16, 2017 at 3:04 PM, GurliGebis [e-mail]
wrote:

I see your point :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/144#issuecomment-315608020,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I55vWf9whP_zPntTIbYjSF5OS8glks5sOgpjgaJpZM4OU3Wq
.

[thess]

@GurliGebis - You are correct!

Arrghh - one more patch to carry in private builds.

[bubnikv]

For upgrading bigger parts of the printer or doing mayor version jump to
another FW, it's a usual thing to do a:
M502 (load FW defaults)
M500 (store them to EEPROM)

The problem is, we are producing 3D printers for a general community, so
this simple sequence of commands, or loading a G-code and starting it from
a SD card, will likely not be performed by too many users, and we would
then face many support calls. And yes, the users too often do not follow
the manual. And I can understand that. As a father of four, when doing some
hobby stuff around midnight, I also do not read manuals carefuly and I make
too many errors.

We are discussing the solution to recover the storage of E-steps into
EEPROM. We will need to store a flag "I am single-material / I am
mutli-material" setup into EEPROM for the firmware to be able to convert
the settings between the single / multi-material setup after the firmware
update.

On Sun, Jul 16, 2017 at 3:16 PM, Ted Hess [e-mail] wrote:

@GurliGebis https://github.com/gurligebis - You are correct!

Arrghh - one more patch to carry in private builds.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/144#issuecomment-315608583,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I-CP08GYuUBST_pmuG-iM2TyUMPWks5sOg0UgaJpZM4OU3Wq
.

[Sebastianv650]

@GurliGebis I had to solve a merge conflict in my LIN_ADVANCE PR, therefore I thought it would be not much more work to create another fork also. So if you want to have a look at it, this is it:
https://github.com/Sebastianv650/Prusa-Firmware/tree/MK2_Community_Mod

Let's see if it's helpful. If not, deleting it is easy ;)

[GurliGebis]

@bubnikv Thanks, that is all I was hoping for :)
Regarding the SM/MM flag in the firmware, would it be an idea to merge the two firmwares into one, something along the line of what I have done in this pull request? #124 (It should be changed to have the switch between the two modes from the reset menu, instead of the settings menu)

[GurliGebis]

@Sebastianv650 looks good to me :)

[GurliGebis]

Closing, since it will be fixed in 3.0.12-1