GUI - Accelerating encoder steps & configuration/eeprom

[AbsoluteCatalyst]

I've implemented your suggestions on the encoder accumulating steps based on time. I tried a few different formulas including V1's until I arrived at this one. Still open to any improvements on it.

It's behavior should be smooth but quite responsive if you decide to purposely "fly" to the bottom of a menu, or max out a value. The user can easily tweak it to their liking via it's config menu, if anything.

• It's config menu displays the current step rate and delta time between clicks in realtime. Should help tuning.

• Settings are: Max Step, Max Time, Min Time, and Affect Menus (Toggle).

• New EEPROM signature & handling: GUI. Set up for encoder settings and any future usage.

• menuEnd now has two parameters to manually disable the scrollbar or encoder speed for special menus.

[repetier]

Ideas look good. Only thing I miss is an option to completely disable it to reduce RAM usage for the AVR. Can you make e.g. that ENCODER_MAX_REPEAT_STEPS 0 disables the code completely. While just looking I saw already at least 33 bytes extra.

BTW: I found the delay reason for AVR - the wait time at start is computed wrong and just the high frequency prevented us from noticing. Just working on an update that also improves the fatal error handling, e.g. can stop motor immediately or move up to safe position.

I also noted that on fatal error you need a host sending M999 which is not acceptable if you have a gui. I see currently 2 options:

1. Show error in status and have an extra menu entry "Clear Fatal Error". That way you can at least browse through menus and test some things, but motion and heating will be prevented until reset.
2. Show the error wizard with message and clear fatal state on hitting "Fixed".

What do you think would be the best solution?

[AbsoluteCatalyst]

Yeah I'll definitely add that macro to compile it out. I can see how much just a few bytes can matter so much on AVR now...

But that's good news on the AVR. I've been up trying to see what I could do. I've managed to get it to compile and run my reprapdiscount graphics display including SDCard with around 1488~ bytes left. I have a few more places I think I saw where RAM usage could be reduced too.

But It doesn't appear as if this enough, or at least something is causing a boot loop after exactly 4 seconds. (My watchdog is off?) (I can control the menu within that time too.) Maybe the frequency bug you caught might be causing it. What are your prepare/stepper frequencies for the mega ?

For the error reset, I think option 1 might be a bit better, in case there was something the user needed to look at. A user might accidentally click the wizard/prompt quickly and miss it.

[repetier]

#define STEPPER_FREQUENCY 10000      // Maximum stepper frequency.
#define PREPARE_FREQUENCY 500        // Update frequency for new blocks. Must be higher then PREPARE_FREQUENCY.
#define BLOCK_FREQUENCY 250          // Number of blocks with 

is what I use. Due to the bug it is just a 3s delay until first move happens. Should not have anything to do with reset. But so far I normally need to reset again after first connect to get it running correctly. Just like it hangs, but haven't invested this. Just happy it is working at all.

[repetier]

I also are more for solution 1 since it gives more flexibility. Maybe just show the big error screen first but with no effect on closing.

[AbsoluteCatalyst]

Thanks for the frequencies. I'm having that same hang as well, a reset fixes it.

And so like mixing both options then? A warning and a menu option? That would work.