InsanityAutomation / Marlin

Optimized firmware for RepRap 3D printers based on the Arduino platform.
http://www.marlinfw.org/
GNU General Public License v3.0
452 stars 220 forks source link

Creality_DWINTest - Economy Mode Does Not Stay Disabled #23

Closed mwolter805 closed 5 years ago

mwolter805 commented 5 years ago

Description

Hello, thank you for your hard work on this project! I am using your firmware version 1.1.9 B5 on a CR-10s Pro. When disabling economy mode (visible from the print adjust menu while printing) it does not stay disabled after a power cycle. This creates a huge issue as I need to physically go to my printer (I use Octoprint) which is inside an enclosure and disable economy for each print. If I forget to do this, the print falls off. This was not an issue with the stock firmware..

Steps to Reproduce

  1. Start a print
  2. Go to the adjust menu
  3. Turn off economy
  4. Wait for print to finish
  5. Power cycle the printer
  6. Start another print
  7. Go to the adjust menu
  8. Economy is enabled again.

Expected behavior:

Economy to remain disabled

Actual behavior:

Economy is enabled after a power cycle

InsanityAutomation commented 5 years ago

I havnt found the register address for Eco mode yet. Ill do a bit more digging once I finish porting this to ExtUI in Marlin 2.0.

juliandroid commented 5 years ago

@InsanityAutomation Is that what you are looking for?

LCD_RTS.h (currently Creality_DWIN.h):

#define FONT_EEPROM 90
...
#define FanKeyIcon          0x101E

LCD_RTS.cpp (currently Creality_DWIN.cpp):

PrintMode =eeprom_read_byte((unsigned char*)FONT_EEPROM+6);
if(PrintMode)RTS_SndData(3, FanKeyIcon+1);  // saving mode
else RTS_SndData(2, FanKeyIcon+1);  // normal
...
eeprom_write_byte((unsigned char*)FONT_EEPROM+6, PrintMode);
juliandroid commented 5 years ago

@InsanityAutomation Am I missing something or it seems trivial? I'm asking because in the source it seems you have removed pretty much all of the eeprom_read/write calls?

InsanityAutomation commented 5 years ago

Eeprom stuff could overlap other data depending on features enabled. Marlin 2.0 EXTui has an encapsulation later for safe handling so it'll be reimplemented there.

juliandroid commented 5 years ago

Alright, so those address are dynamically selected depending of the features? I'm wondering what would happen if you have the settings stored in the eeprom but later add/remove feature with a new firmware update? I guess the EXTui keeps somewhat static locations for each feature and does not reallocate them and you have to assign space for those things?

Elinvention commented 5 years ago

The fan on/off setting also returns to on at each print, which is quite annoying.

InsanityAutomation commented 5 years ago

While the mode storage to eeprom wont be feasible until 2.0, ive gotten eco mode working as intended and defaulting to off for B7 so im closing this out as anything further will be part of the rewrite effort.