Customized LCD-menu

I thought I might share my modified LCD-menu with you guys.
I was going crazy when trying to access the menu objects I needed through the LCD on the modified version of the RC7 that’s on Vicious site, so I came up with a couple of improvements that customized the menu for me. This is what I tried to accomplish:

• Get rid of all junk I don’t use (I’m only using the machine as a router)
• Reorder the menu to put the mostly used commands on top
• Access the z-probe offset from the LCD-menu
  o The height of the piece of metal I let the tool go down against to probe for z (connected to GND and z-min)
• Make a temporary Z-offset-menu item
 o Useful if e.g. an engraving ends up too shallow – just make a temporary z-offset of -0.5 mm and run the same file again (it doesn’t lose x and y)
  o So that you don’t have to alter the z-probe offset
• “Go to home” command in menu
• Set current position to home (without offset) menu item
• Make the 2nd option on a submenu pre-selected
  o If I e.g. enter the submenu “Move Axis” from the “Prep-menu”– most likely my next action won’t be to go back to the prep-menu, but to press the first real option (2nd option) 

I’m happy to say I successfully implemented all of these alterations, with modifications in the file “ultralcd.cpp”

This is the menu I decided to go with:

• Startscreen - jumps directly to preparation:
  o Back
  o Move Axis
    • 0.1mm
    • 1mm
    • 10mm
  o Probe for Z0 (“Home Z” using bit as probe)
  o SD Card
    • Options depend on sd-card status
  o Go To Home 	
    • ALL
    • X
    • Y
    • Z
  o Disable steppers
  o Temp Z offset
  o Z homing offset 
  o Make this home
  o Store to EEPROM
  o LOAD from EEPROM
  o Control
    • acceleration, jerk, speeds..... (set these in gcode)

And if we’re in a print (still has g-commands in the buffer) this is the menu:

• Startscreen - jumps directly to preparation:
  o Speed (%)
  o SD-Card
    • Pause/Resume Print
    • Stop Print

I also modded the gcode post processor for fusion 360 (V9) to disable the G92 –“set current position to home” at the beginning of the g-code (I don’t want to lose track of the x, y and z and the offset of my z-probe bottom material). Just comment out the line 200 like this:
//writeBlock(gFormat.format(92) + SP + “X0” + SP + “Y0” + SP + “Z0”);

I would strongly recommend you to comment out the line above even if you’re not altering the LCD menu, since it removes the possibility of engraving the same pattern twise if your engrave bit didn’t go deep enough the first time, the second time with a temporary z-offset (go deeper). Hold on tight to your current X and Y coordinates…

A few tips if you want to make your own version
• You only need to alter the file named ultralcd.cpp (I used Notepad++)
• All my modifications are marked with “Kalle” -search for them in included file!
• I haven’t deleted anything – just commented it out so if you want to re add the 3D-printer settings, just move them to where you want them and remove the comments (“//”)
• If you want to use the “Make the 2nd option on a submenu pre-selected” you have to use my own version of the submenu called “submenu2” like this: MENU_ITEM(submenu2, …….) (23.4 KB)

I made some improvements:

  • “confirm probing” page when “Probe for Z0” is clicked since it’s very close to Move axis, and you don’t want to accidentally probe for z when your probe wires aren’t connected…

  • changed ENCODER_STEPS_PER_MENU_ITEM from 5 to 4 (one step on my pot equals 4 encoder steps) might differ from yours?

  • Improved the Move axis sub menu - if i want to move e.g. 1mm and enter the 1mm submenu, my pot will want to move my steppers 1*4mm at a time, so I changed it to increment with 1/4 and update lcd every 4 times!
    Did the same with Temp Z offset and Z homing offset! Now one full step with the pot is very accurate 1mm or 0.1mm if i want to… (23.7 KB)


Thanks for sharing Karl! I’ll take some ideas for my custom lcd menues.

There are two configurations for the lcd encoder, and they are sort of connected. You want to change the one that’s encoder pulses per step to 4, and then encoder steps per menu item to 1, that will fix the stepping by 0.4mm and the menu steps. I had the details buried deep in my MP3DP build, and I doubt many people saw that, sorry.

jeffeb3: I do have defined the encoder pulses per step to 4, and then encoder steps per menu item to 1, even then the “move axis” menu does not take that into consideration in the original version…

Take a look at my modified version of the functon “_lcd_move_xyz” below - the original version is updating the LCD and current_position at every encoderPosition - which is 4 times per pot-step! My code waits till encoderPosition % 4 == 0 which is once every full pot-step!

static void _lcd_move_xyz(const char* name, AxisEnum axis, float min, float max) {
    if (LCD_CLICKED) { lcd_goto_previous_menu(true); return; }
    if (encoderPosition) {
      if(encoderPosition % ENCODER_STEPS_PER_MENU_ITEM==0){ //Kalle make one whole Pot-step equal one movescale!
        current_position[axis] += float((int32_t)encoderPosition) * move_menu_scale/ENCODER_STEPS_PER_MENU_ITEM; //Kalle: ENCODER_STEPS_PER_MENU_ITEM=4
        if (min_software_endstops) NOLESS(current_position[axis], min);
        if (max_software_endstops) NOMORE(current_position[axis], max);
        encoderPosition = 0;
      lcdDrawUpdate = LCDVIEW_REDRAW_NOW;
    if (lcdDrawUpdate) lcd_implementation_drawedit(name, ftostr41sign(current_position[axis]));

Decided to change the submenu of “Probe for Z0” so that it has two options:
-“Zero only Z” -probe for z and leave x and y as is
-“Zero All” -probe for z and zero x and y
I kept the added safety question from version v2 so that i make sure to not forget to add the probe wires :wink:

//Kalle (23.8 KB)

I wonder if we are using different versions of the Marlin firmware. I am actually not exactly sure what version I’m using, but I think it’s RC8, which you are probably not using, due to the z movement bugs there…

The encoderPosition should have already removed the ENCODER_PULSES_PER_STEP in the encoder reading code (also in ultralcd.cpp):

encoderPosition += (encoderDiff * encoderMultiplier) / ENCODER_PULSES_PER_STEP;

Yes I am using RC7 (the one linked by Vicious)
Stress-tested my new LCD-menu last night, and it works like a charm:

Remote control

I found out that the Post processor V9 for F360 disables the steppers after file is done - this is bad if you want to keep you X and Y while changing tool (if you like me have separate gcode-files) so I edited line 538 in post processor and commented out the M84-command:
//writeBlock(mFormat.format(84) + “; Turn steppers off”); - to keep the current flowing!

This is how I used the menu:
1. Define the Z-probe bottom thikness:
a. Z homing offset = 1.24 mm
b. Store to EEPROM Saves the Z homing offset to eeprom so that it never have to be entered again!

2. Find X0, Y0, Z0
a. Manually set machine where you want X0,Y0 (with “move axis” or by hand)
b. “Probe for Z0”/“Zero All” (with my Z probes clipped to the bit and the probe bottom piece underneath!)

3. Facing: In F360 I had defined the Origin (x0y0z0) to the model top, and told the facing bit to face off to Z0. Since the surface of my stock piece was a bit uneven, there were parts that was lower than Z0 => need to use my Z0 offset!
a. “Temp Z offset” = -0.5 mm (note that the Z value on Status screen now changed from e.g. 5mm to 5.5mm => Z0 is now 5.5 mm down!
b. Run the Facing -gcode and if needed, decrease the offset even more and run again till smooth surface!
Bit: 6mm 4 flutes
Speed: 10 mm/s

4. Contour: I used the same bit again (need to get a longer 1/8 bit… for this) so no need for Z-probing this time.
a. Just run the next gcode (no need to go to x0y0z0 first, just hit run!)
Speed: 10 mm/s.
Max ramp stepdown: 1.5 mm

5. Adaptive clearing: this time I had to change bit so my Z will be off! Before I changed bit, I made sure that the stepper motors were active – to not accidently fuck up my coordinates!
a. I hadn’t altered the post processor yet, so my stepper where disabled =>
“Move axis”/”X”/”1mm”/+1mm and same for Y to trigger the motors!
b. Moved Z to height where I could change the bit (manually or in menu) and changed the bit
c. “Probe for Z0”/“Zero only Z” - To probe for the new Z0. Be very careful not to Zero All!!! This time the probing will find the actual Z0, and does not need any temporary offset (even though it’s not cleared in the menu in current version, but that doesn’t affect anything, take a look at status screen and see that it says Z5 after probing and not Z(5-temp offset)!)
d. Run the code!
Done in 2 passes (1.5 mm at a time)
3 mm bit (~1/8").
Speed: 7.5 mm/s.

4. Engraving: with 45 degree 1/8" engraving bit - used the same method when changing tool as last time!
Speed: 10 mm/s

I will flip the piece and repeat step 2 (facing) till my remote is free from the stock (except for the tabs to hold it there)

You might want to make a github fork to make it easier to keep all your changes through the updates to marlin. I used to change the menus but all the work it took during updates made me give up. Now I’m a minimalist, until I get a better handle on github.

I havn’t used Github that much, maybe i’ll look into that if there’s time…
Anyway I found out that removing the M84 Command from the gcode still didn’t manage to keep the steppers activated…
Turns out there’s a setting in file Configuration_adv.h that inserts a M84 code when file is done. So you have to edit that one as well… Change line 417 #define SD_FINISHED_STEPPERRELEASE true
to false - and your steppers should stay active after print/routing is done!

Excellent! I was just thinking last night while running some tests that I really wish the LCD menus were geared more towards CNC and the actions I need/use regularly. I’ll give this a shot!

My limit switches finally arrived so I need to install those and a Z probe. That’s next on the list since I seem to have a good dust shoe solution working now.

I have done some improvements on the menu, you’ll find the latest version of the code on my github:

  • I didn’t fork the entire marlin sice i decided to stick with the version RC7…

    Karl I have a question. If I start keeping all my versions of the firmware on github what is the preferred way to do something like standard firmware, 8mm rod, extruder, no extruder, all of those with and without the LCD.

    Should I make a new fork of the main marlin branch or fork mine over and over again, or is that where branch comes in?

    All the github tutorials kind of only explain github for use in a combined development environment. Mainly how to push, but I will never have a push I just want to easily maintain several versions of the firmware.

    I have been syncing a version of marlin and I think I have a decent handle on how to resolve conflicts, but it seems pretty convoluted. I am sure I must be doing it the hard way.

    You wouldn’t fork for each change, you could use a branch.

    A commit is just a patch, or diff with a comment, and a parent. A branch is just the name of a commit. So if you kept a main branch, which was sort of the vanilla Marlin (just with the files moved around the way you liked). You could tag that with things like RC7, RC8, RCBugfix_Jan_01_2017, etc. Then you could have a branch like MP3DP, or MPCNC_no_extruder, MPCNC, etc.

    When you wanted to move all the software from RC7 to RC8, or whatever, you could do something like this:

    git checkout MPCNC # switch the branch you are working on to MPCNC
    git rebase RC8   # change the parent to the tag RC8 (This is really hard to do in reverse, it's really only used to move forward)
    ... # fix all the conflicts, merge problems, etc.
    git push origin :MPCNC # deletes the remote branch named MPCNC
    git push # pushes the new definition of MPCNC

    That’s the first way I can think of to do it. I think you can link to a .zip file that has code from a single branch.

    BTW, there is a lot of scary, giant pits with alligators in git (rebase has a few of them), so if you get stuck, let me know, I use git all the time (and I really like it, so I have read way too much about it).

    If you haven’t used git, make sure you have some tools to see WTF is going on. I use “git status” “qgit --all” (might only be linux, IDK) and “git diff” the most.

    I’m sorry, but you are asking the wrong guy… I’m a total novice in github and was really unsure if it was a good or bad idea not to fork the whole version of marlin or not, but decided to only upload only the files I modded to make it easier for people to see what I’ve modified.
    I guess it could be a problem if you make changes to the original files that won’t work with my version!

    I’ve seen those tutorials as well, and have the same feeling about them… I don’t want to push this into the real program, just make my own version and maybe keep track of different versions…

    And there you have the answer! Thanks for the explanation Jeffeb3!

    Too easy for me to screw that up, for now I will just keep doing it my way and just add a few versions.

    I would suggest using it just to keep track of whatever you are doing on your local machine. I do this all the time:

    git init # starts tracking
    git commit -a -m "initial commit" # commits everything as is.
    ... change some stuff ...
    git commit -a -m "something I changed" # saves every file in this git repo

    You can then push to github if you want, but that’s more for using the website’s tools, or sharing with others, or maybe as a backup.

    It’s nice for things like this autolevel stuff I was just doing, because I can just start changing things, and if I ever wonder “what did I just change?” I can just do “git diff” and it shows me what is different from the last time I committed. Whenever I get something “working” I do the commit again. If I ever want to see what I’ve changed since I started, there are simple commands for that too.

    It sounds like you have a lot of configurations, though, which is going to be complicated, and error-prone anyway you do it. Which is just a fact of life, I guess. If you want to try some of that stuff, send me a PM, and I’ll get you started.

    How I do it now is download a new version or marlin, open up the old and new and transfer all my changes. Then each iteration is easy, save as, change steps or whatever, save as keep going. It doesn;t take too long, but I figured If I could keep at least one branch on github it would be alright.

    The one I have been maintaing is kinda harder to deal with, and i am not confident about the changes that happen when I sync

    I did just get kdiff, that might make it easier for me. Who knows. The firmware thing used to be once a year, now it’s a little more often. I just wanted to be able to push changes easier, like your LCD edits. They are in my local copy but I did not upload it yet.

    I made a few updates on the LCD menu on github that might be interesting:

    • I’ve added a function so that I have to confirm that I pressed the right filename before the “printing” (routing) starts… It would suck to slip on the flaky knob and accidentally start the wrong file and fuck up my X and Y (I guess this wont be a problem if you include all the tool changes and paths to the same gcode…)

    • Extended the Move- function so that I have the option to set the coordinates for x,y and z first, then execut the G1-command (much smoother then having the machine move while turning the knob since it’s a bit flaky)

    • Reset the Speed [%] (feedrate) to 100% after file is finished (haven’t actually tested this yet, but should work) and added the speed menu to the menu even when file is not currently printing (Reset the variable “feedrate_percentage” to 100% in the file cardreader.cpp in fkn: printingHasFinished())

  • Speed reset to 100% after file is done is now tested and works!
    Modified the Z-proing to force all the steppers to engage to not accidentally change X or Y.
    I’m starting to feel like I’m done with all the modifications I need for now!