Notifications
Clear all

E step calibration  

  RSS
HainjeDAF
(@hainjedaf)
Eminent Member
E step calibration

My Prusa mini only spits out 97.2mm of filament per 100mm

 

So I Idusted M92 to have a better value for E-step.

 

When I reboot the printer or take off the power, this new M92 E value is lost

How do I make it stick?

 

Publié : 31/08/2020 12:34 pm
HainjeDAF
(@hainjedaf)
Eminent Member
Topic starter answered:
RE: E step calibration

I tried M500 store to NVRAM/EPROM, both with and without USB stick.

But every time the printer starts, M92 drops back to E325.00

 

Publié : 31/08/2020 12:50 pm
Neophyl
(@neophyl)
Illustrious Member
RE: E step calibration

M500 isn’t supported in the mini firmware as yet I believe. 
until they add it in a future release you will have to add the esteps to your start gcode in whatever slicer you use. 

Publié : 31/08/2020 1:04 pm
HainjeDAF
(@hainjedaf)
Eminent Member
Topic starter answered:
RE: E step calibration

Yes, which is why i reported M500 not working as a bug for 4.2.0 firmware (seems to be there in 4.2.1 as well)

It makes all calibration useless becatse e.g. first layer calibration uses the M501 values and not the user adapted ones.

Publié : 31/08/2020 7:15 pm
Neophyl
(@neophyl)
Illustrious Member
RE: E step calibration

So you are aware of the firmware limitation, you have raised a bug (good on you) but you still ask how to fix it ?  There isn't a 'fix' except to modify the start gcode, you will have to wait until the devs get round to it. 
Alternatively as the software is open source you could fix it yourself and then do a pull request and help out everyone else who is also waiting.

Also to be more specific it makes the built in calibration useless.  It doesn't make alternative methods of calibrating the first layer useless as files sliced to do so will use the values from Slicer.

Publié : 31/08/2020 7:21 pm
Neophyl
(@neophyl)
Illustrious Member
RE: E step calibration

By the way are you aware that 5 issues relating to saving to eeprom have already been closed on githib as the decision to NOT save using the M500 command was a deliberate one on the part of the design team.  

https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/364  

Publié : 31/08/2020 7:35 pm
HainjeDAF
(@hainjedaf)
Eminent Member
Topic starter answered:
RE: E step calibration

well, My guess is if sufficient people complain, something has to be done considering this problem.

AFAIR the eprom issue has risen because appearently there are issues storing the values consistently.

So instead of repairing this, they removed the function alltogether...

Like removing the radio from future cars because tuning is broken....

Publié : 31/08/2020 7:57 pm
bobstro
(@bobstro)
Illustrious Member
RE: E step calibration

I don't have a Mini, so usually avoid chiming on on machine-specific bits, but this is interest. Their response on the github page is "we turned off EEPROM support in Marlin because values were written inconsistently". I'm unclear whether they mean that as a bug, as in they can't get them written consistently, or using M500 causes issues with storage of the automatic calibration values. 

This alarms me because it's a move away from "the Marlin way" (arguable, a standard) and into something more proprietary. If Prusa starts drifting away from the ability to read and set values via gcodes (as they've already done), we get more and more isolated from being able to access the internals of the machine. If you're raising the issue on github, I'd make mention of that

My notes and disclaimers on 3D printing

and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan

Publié : 31/08/2020 9:50 pm
bobc
 bobc
(@bobc)
Reputable Member
RE: E step calibration
Posted by: @bobstro

I don't have a Mini, so usually avoid chiming on on machine-specific bits, but this is interest. Their response on the github page is "we turned off EEPROM support in Marlin because values were written inconsistently". I'm unclear whether they mean that as a bug, as in they can't get them written consistently, or using M500 causes issues with storage of the automatic calibration values. 

This alarms me because it's a move away from "the Marlin way" (arguable, a standard) and into something more proprietary. If Prusa starts drifting away from the ability to read and set values via gcodes (as they've already done), we get more and more isolated from being able to access the internals of the machine. If you're raising the issue on github, I'd make mention of that

Too late for that, I think. Prusa have implemented a new EEPROM storage and API, and when they found that is incompatible with the existing Marlin storage, they disabled the Marlin method.

Prusa have also added an RTOS around Marlin (Marlin is run as a "server" task). To be fair, Marlin have been dragging their feet on these type of improvements while they try to maintain back compatibility. Prusa are not worried about that, so can move forward, but don't seem to be worried that they are moving away from Marlin.

It seems clear Prusa want to lock down the Mini system to make it "safer", a side-effect of this is that it makes it harder for users to modify - and harder to support third party mods.

This policy comes from the top. You can read more here https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/767. Josef talks about a "hidden menu", but I don't know what he is referring to.

Publié : 01/09/2020 8:59 am
bobc
 bobc
(@bobc)
Reputable Member
RE: E step calibration
Posted by: @hainjedaf

well, My guess is if sufficient people complain, something has to be done considering this problem.

AFAIR the eprom issue has risen because appearently there are issues storing the values consistently.

So instead of repairing this, they removed the function alltogether...

Like removing the radio from future cars because tuning is broken....

That is pretty much the case - but perhaps more like they kept the radio but it only receives one channel which you can't change.

Prusa could support storing all values in EEPROM if they wanted, but I guess they decided it was just not needed and/or too much work to fix properly.

The fact that many people have raised the issue doesn't seem to be a big deal for Prusa. Feedback from Prusa is very limited, but it seems they develop what they want without listening to users very much. When you are selling printers like hot cakes, you don't need to.

Publié : 01/09/2020 9:07 am
HainjeDAF
(@hainjedaf)
Eminent Member
Topic starter answered:
RE: E step calibration
Posted by: @bobcousins

It seems clear Prusa want to lock down the Mini system to make it "safer", a side-effect of this is that it makes it harder for users to modify - and harder to support third party mods.

This policy comes from the top. You can read more here https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/767. Josef talks about a "hidden menu", but I don't know what he is referring to.

That is a straight 404.

The only hidden menu I found was a referral to the I3 MMU2 (not S) where a combo of buttons is opressed to do setting adjustment for the MMU

Publié : 01/09/2020 11:22 am
Oxygen
(@oxygen)
Reputable Member
RE: E step calibration
Posted by: @hainjedaf
Posted by: @bobcousins

[...] https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/767 Josef talks about a "hidden menu", but I don't know what he is referring to.

[...]

You only had to remove the . on the end

Mini with FW:4.4.1 + SuperPINDA + Bondtech Heatbreak + PC4-M8 couplers + 1 piece boden

Publié : 01/09/2020 3:39 pm
Partager :