Weirdness with my extrusion rate

I was flashing my firmware earlier to raise the 135C soft limit on my bed and thought I'd just double-check my E_STEPS_PER_MM whilst I was there.

Prints were fine (actually they were VERY good - dimenionally accurate, good infill/wall widths etc) so arguably I shouldn't have touched it but hey ho, I did and I noticed something strange - running 100mm at 60mm/min resulted in a VERY low extrusion rate. I ran it again a few times to be sure, but I ended up raising my extrusion rate in the firmware by quite a bit. I then ran the test again and I was still under-extruding. I basically repeated this process about five or six times and my E_STEPS_PER_MM is now at *100/59, which sounds very low to me. The hobbed bolt is clean, I've got good tension on the springs and the filament isn't slipping anywhere. How could I have been getting good prints before when I'm off by so much?

Did you reset the firmware E_STEPS_PER_MM modifier to 100.0/100.0 (or remove it) and re-flash your controller before recalibrating the extruder?

Also, check for unrelated changes that might have introduced errors - things like start GCode.

Regards,
Neil Darlow

---

I try to write with consideration for all nationalities. Please let me know if something is unclear.
Printing with Mendel90 from fedora 25 using Cura, FreeCAD, MeshLab, OpenSCAD, Skeinforge and Slic3r tools.

If you actually set it to 100/59 that is your problem. C++ will do an integer division and call it 1.

You need 100.0/59 i.e. at least one side of the division to be float to get a floating point result.

Edit: well it would be wrong but not by the amount you describe.

Edited 1 time(s). Last edit at 09/17/2014 03:18PM by nophead.

---

[www.hydraraptor.blogspot.com]

Sorry I rounded up when I typed that without thinking - it's extruding 58.9 or something when I ask it to extrude 100mm so one side of the division is a float.

I did at first try to calculate the compound difference with my previous setting but it was still bad so I assumed my maths was wrong and reset it to 1 before starting the whole process again.

I've tried using both the "extrude 100mm" on my Panelolu and using Pronterface to get my 100mm extrusion. Neither uses my start gcode so it shouldn't affected by it.

It's worth noting that I have been printing with my E_STEPS tweak at 103.something since I built the printer so for it to be suddenly off by such a large yet variable amount is puzzling.

It may be an opportunity to sleep on it and look at it with fresh eyes - I've been awake for two days so that can't help lol.

Have you modified the flow rate via the Panelolu and saved it to EEPROM by any chance?

---

[www.hydraraptor.blogspot.com]

I'm wondering if I've done that by accident somehow. The only thing I've purposely saved is the pre-heat PLA and ABS temperatures in the "prepare" menu. Does that also save other settings in Panelolu?

EDIT: I've just had a look under Control >> Motion and I can see a setting for Esteps/mm with a value of +0516.8 - that's it isn't it? If I paste my previous E_STEPS_PER_MM value ("((3200 * 39.0)/(11.0 * 6.75 * 3.142)) * 100 / 103.5") into Google then I get this same number. It must have saved everything I had in my #defines into the EEPROM when I thought I was just saving temperatures, so no subsequent tweaking is having any effect! Doh! Is there a way to make clear just this setting?

Edited 1 time(s). Last edit at 09/17/2014 04:53PM by QuackingPlums.

I don't think so. This is why I ship the firmware with the EEPROM turned off. It is just too confusing to have two versions of all these settings.

---

[www.hydraraptor.blogspot.com]

If I just turn it off again in the firmware then will that stop it loading my settings?

I actually don't remember turning it on - I wonder if I inherited it when I merged the T3P3 Panelolu code. It must have been lying dormant for over a year because it was only recently that I found the Preheat PLA/ABS settings in the menu and thought it would be handy to set those to my start temperatures.

If you turn off the EEPROM the code is removed to save space, so it has to use the values defined in configuration.h. That is assuming the LCD stuff will compile without it.

You can also force all the values to the firmware default with an M code.

Edited 1 time(s). Last edit at 09/18/2014 05:52AM by nophead.

---

[www.hydraraptor.blogspot.com]

Quote
nophead
You can also force all the values to the firmware default with an M code.

Is that the M502 "revert to default factory settings" code as shown here, where "factory settings" is what is set in my firmware?: [reprap.org].

If I run M502 and then start a print, will the settings 'stick' or will the act of starting a print force a reload of the EEPROM settings again?

I guess my issue now is that I have settings in my EEPROM and these will always get loaded on boot. I can't see a way to go back to having *no* settings in my EEPROM so I'll be forever stuck with having to flash my firmware and THEN store that into my EEPROM after each change.

Yes "factory settings" is what is set in the firmware.

When EEPROM is enabled in the code then I think it will always use the values stored in it in preference to the firmware once it has been initialised, so you have to remember to do M502 after every change in configuration.h. Then of course you lose any settings you had changed in the EEPROM. This is why I think it is crazy to store values in two places. It is so easy to make a mistake and not be using the settings you think you are or lose a precious finely tuned value. If I shipped firmware with it enabled I am sure I would forever be getting questions like these from confused customers.

Perhaps it is because I am a programmer, but I like a nice text file with named constants that can be under source control and have history and backup rather than numbers in EEPROMs distributed around my machines. For some reason people seem to shy away from updating the firmware but I find it quicker than looking up random g code commands.

Edited 3 time(s). Last edit at 09/20/2014 10:43AM by nophead.

---

[www.hydraraptor.blogspot.com]

The implementation of EEPROM settings storage in Marlin has not been properly thought-out.

I can see the advantage in being able to override specific settings e.g. for experimentation purposes; or a large print-farm where you might use the same firmware on all machines but customize each individually for E_STEPS_PER_MM and Z_HOME_POS.

This is partially why I want to take a look at the whole hardware/firmware/slicer/host chain and implement something radically different (think: GCode without E and F values! - think: forget GCode altogether - think: 32-bit dual-core controller).

Regards,
Neil Darlow

Edited 1 time(s). Last edit at 09/22/2014 07:13AM by neildarlow.

---

I try to write with consideration for all nationalities. Please let me know if something is unclear.
Printing with Mendel90 from fedora 25 using Cura, FreeCAD, MeshLab, OpenSCAD, Skeinforge and Slic3r tools.

Yes that is how I ran HydraRaptor. I only read the extrusion paths from the gcode with my Python host software and add my own temperatures, flow rates, speeds and accelerations in my host. The firmware only runs the Bresenham loop and bang bang temperature control, I.E. only the real time bit, so is tiny, runs fast and never changes.

---

[www.hydraraptor.blogspot.com]