Basic menu support (beta)

[mcmatrix]

Hi guys,

I wanted to inform you that I'm working on a simple menu system for klipper. I already have working mockup and now I'm trying to fit it into Klippers system.

The menu structure is fully configurable via config file. Menu is working on different screens, 2x16, 4x20 and on graphics displays. It's a text based menu system. You just have to specify correct cols and rows.

It has 3 basic menu elements:

• Group menu item (folder) SELECT will enter into submenu
• Menu item with action SELECT will execute GCODE (if specified)
• Menu item with input SELECT will go into edit mode

All submenus have first item as "go back". System inserts it automatically.

You can define klipper system predefined variables in args attribute. In menu item name you can use variables list defined in args as standard print format options. For navigation only 3 buttons is needed: UP, DOWN, SELECT

When menu item (only input item) is in edit mode then system shows asterisk and UP & DOWN will change value accordingly. Currently only float value type is supported. Pressing SELECT again will exit from edit mode and will execute GCODE (value is given as print format first element).

I tried to make flexible way for adding dynamic data into name and gcode. There is attribute parameter: endstop.xmax:b["OPEN", "TRIG"] In Klipper there's collection of status info from all modules. First part endstop.xmax of attribute value is value key of that collection. Second part :b["OPEN", "TRIG"] of attribute value is additional way for mapping value to list or dict. : is delimiter b is boolean typecast for value. Other casting types are: f - float, i - int, b - bool, s - str ["OPEN", "TRIG"] is literal presentation of python list. List and Dict are allowed. Python will use safe method to turn it into real dataset.

You don't have to use mapping options all the time. In most cases it's not needed and just parameter with simple value key parameter: fan.speed will do.

When preparing name or gcode then you're able to use pyhton advanced string formatting possibilities. Value is avalilable as {0} and mapped option as {1}. If there's error condition in conversion or just wrong data type then raw name or gcode string is used instead of formatted one.

Changeable input is using value and can only be float type. But in name and gcode you can use mapped one if needed.

Menu manager config

[menu]
root: main1     # mandatory
rows: 4         # mandatory
cols: 20        # mandatory

Group menu item config

[menu main1]
type: group                 # mandatory
name: Main menu             # mandatory
enter_gcode:                # optional
leave_gcode:                # optional
items: menu1, menu2, menu3  # mandatory

Menu item with action

[menu menu1]
type: command                        # mandatory
name: Fan speed: {0:d}               # mandatory
parameter: fan.speed                 # optional

[menu menu2]
type: command          # mandatory
name: Pause octoprint  # mandatory
gcode: @//pause        # optional

[menu menu3]
type: command      # mandatory
name: Kill me      # mandatory
gcode: M112        # optional

[menu menu1]
type: command                               # mandatory
name: xmax endstop: {1:4s}                  # mandatory
parameter: endstop.xmax:b["OPEN", "TRIG"]   # optional

Menu item with input

[menu enable_fan]
type: input              # mandatory
name: Enable Fan: {0:d}  # mandatory
parameter: fan.speed     # mandatory
input_min: 0             # optional
input_max: 255           # optional
input_step: 1            # mandatory
gcode: M106 {0}          # optional

Some screenshots from mockup demo

NB! This is still a Work in Progress. Concept, code, and other stuff might change!

[mcmatrix]

FYI, the more features that are added the harder reviewing will be, and that might make merging into the master branch harder. I'm all for replacement of the status display with something more flexible, but I suspect it would be preferable to do that in separate commits from basic menu support.

It's fine, I understand your concern. I'm only changing display module as much as is needed for menu subsystem support. The magic is all happening inside menu module. The original status display and everything else remains. It's up to user who can choose what he/she wants to use.

[mcmatrix]

Hi guys, Moving slowly, enjoing my last vacation week and summer heatwave in Estonia. Let you know when the new development release will be available.

[mcmatrix]

New development release is ready for testing. I made new branch dev-release-20180720 for it! NB! Please be aware that config has changed, please look example-menu.cfg

For new testers please use following steps to get menu: Install original klipper first. Set it up correctly, make sure that everything works and then check out my dev-release for testing. This way by using git checkout you can easily switch between different branches.

This should help with my dev-release checkout.

git remote add mcmatrix https://github.com/mcmatrix/klipper

git fetch mcmatrix
git checkout mcmatrix/dev-release-20180720

make clean
make

sudo service klipper stop
make flash FLASH_DEVICE=/dev/ttyACM0
sudo service klipper start

In display section you have following options, buttons and encoder config remains same.

# timeout in seconds, leave it out if not needed
menu_timeout: 60
# to use menu you have to specify root menu entry
# for stock statusscreen and menu use `main`
# for custom statusscreen use `infoscreen`
menu_root: main
# this option allows to run menu immediately at startup.
# use it for custom statusscreen
menu_autorun: yes

I have built example menu tree and made few sample statusscreens. You can change everything and build your own menu structure and status screens.

All statusscreen cards made for 20x4. Users having 16x4 displays have to modify these cards to fit. I tried to show config options in example-menu.cfg

I need to start doing boring stuff too, documenting menu configuration options. This is still missing.

[bruce356]

Hi being a novice would it be possible for you to go into detail on how to install your menu system. I have klipper installed (did that about 8 weeks ago so not the latest version) and the original klipper menu is working (just a static screen with little info, nothing else).

I use Putty SSH to connect to Raspberry Pi3 git remote add mcmatrix https://github.com/mcmatrix/klipper fatal: Not a git repository (or any of the parent directories): .git

git fetch mcmatrix fatal: Not a git repository (or any of the parent directories): .git

Do not know where to go from here. regards - bruce

[mcmatrix]

@bruce356 You have to be inside klipper directory. cd ~/klipper/

[bruce356]

Thanks that worked, do I just have to copy the contents of your example-menu.cfg into my printer.cfg file (which by the way is the generic-rumba.cfg), I have done that but my GLCD shows no change the menu is still the original static display. I used sudo service klipper stop and sudo service klipper start regards

[mcmatrix]

@bruce356 Could you attach you klipper config to comment. Then I can see what have you done.

[bruce356]

@mcmatrix please find attached my printer.cfg file regards printer.zip

[mcmatrix]

@bruce356 To use menu you have to enable it in display section First you have to find out what pins to use for buttons and encoder.

In example-extras.cfg

# Support for a display attached to the micro-controller.
#[display]
#lcd_type:
#   The type of LCD chip in use. This may be "hd44780" (which is
#   used in "RepRapDiscount 2004 Smart Controller" type displays),
#   "st7920" (which is used in "RepRapDiscount 12864 Full Graphic
#   Smart Controller" type displays) or "uc1701" (which is used in
#   "MKS Mini 12864 type" displays). This parameter must be provided.
#rs_pin:
#e_pin:
#d4_pin:
#d5_pin:
#d6_pin:
#d7_pin:
#   The pins connected to an hd44780 type lcd. These parameters must
#   be provided when using an hd44780 display.
#cs_pin:
#sclk_pin:
#sid_pin:
#   The pins connected to an st7920 type lcd. These parameters must be
#   provided when using an st7920 display.
#cs_pin:
#a0_pin
#   The pins connected to an uc1701 type lcd. These parameters must be
#   provided when using an uc1701 display.
#menu_root:
#   Entry point for menu, root menuitem name. This parameter must be 
#   provided when using menu.
#menu_timeout:
#   Timeout for menu. Being inactive this amount of seconds will trigger 
#   menu exit or return to root menu when having autorun enabled [optional]
#menu_autorun:
#   Enable this to run menu immediately at startup. It's mostly used to replace
#   stock info screens with custom ones. It accepts boolean values, 
#   default is False. [optional]
#rows:
#   Only needed when using display with custom row count [Optional].
#cols:
#   Only needed when using display with custom column count [Optional].
#encoder_pins:
#   The pins connected to encoder. 2 pins must be provided when 
#   using encoder. This parameter must be provided when using menu.
#click_pin:
#   The pin connected to 'enter' button or encoder 'click'. This parameter
#   must be provided when using menu.
#back_pin:
#   The pin connected to 'back' button [Optional].
#up_pin:
#   The pin connected to 'up' button. This parameter must be provided 
#   when using menu without encoder.
#down_pin:
#   The pin connected to 'down' button. This parameter must be provided 
#   when using menu without encoder.
#kill_pin:
#   The pin connected to 'kill' button. This button will call 
#   emergency stop.

This is my test config for display section

[display]
lcd_type: hd44780
rs_pin: ar16
e_pin: ar17
d4_pin: ar23
d5_pin: ar25
d6_pin: ar27
d7_pin: ar29
#menu_root: infoscreen
menu_root: main
#menu_autorun: yes
#menu_timeout: 60
encoder_pins: ^!ar31, ^!ar33
click_pin: ^!ar35
kill_pin: ^!ar41

[mcmatrix]

Added initial draft description of menu element attributes to example-menu.cfg

[Zwaubel]

@mcmatrix nice work of yours!

I noticed two minor issues regarding the case light control in your example menu:

1. When switching the case light on or off, the menu cursor changes its position right after the gcode was executed. In my case it jumps from "Case Light" to "Move 1mm".

2. I can't set a specific output pin value for the case light pin. When changing the value and confirming by pushing the encoder rod, the value jumps right back to what it was before. No change in the case light pwm or anything.

config atteched: printer.zip

[mcmatrix]

Should be fine now. Please check example-config there was a mistake in caselight gcode.

I had to remove realtime menuitems enable/disable update. When executing gcode klipper goes for a couple of seconds to the printing state and it was causing menuitems hide/show and cursor jump.

Now items enable/disable status is only updated when entering to menu or submenu.

[Zwaubel]

Great! Works fine now, thank you!

[bruce356]

@mcmatrix thanks very much for your efforts to help me. I am complete novice and have been trying to get # "RepRapDiscount 128x64 Full Graphic Smart Controller" working for many hours but this pins thing is so confusing (China Rumba board). Why is "^!" placed before the pin number. I will wait for someone with more knowledge to get this type of GLCD working. regards - bruce

[Taz8du29]

@bruce356 The "^!" syntax is described in the example.cfg configuration file:

Pin names may be preceded by an '!' to indicate that a reverse polarity should be used (eg, trigger on low instead of high). Input pins may be preceded by a '^' to indicate that a hardware pull-up resistor should be enabled for the pin.

You may have to look at the datasheet for your screen in order to determine the pinout of your LCD.

If I understood well, you have this LCD screen. The reprap wiki page gives you the following schematics, and you can find the config for your LCD and board in the Marlin firmware example.

If you don't know how the pins have to be trigerred (high or low), you can just experiment with the config... as long as the wiring is fine, there is no risk for the hardware :)

[bruce356]

@Taz8du29, Thanks for the information, you inspired me to try again. This is my final result RepRapDiscount 128x64 Full Graphic Smart Controller [display] lcd_type: st7920 cs_pin: ar19 sclk_pin: ar18 sid_pin: ar42 menu_timeout: 60 menu_root: main menu_autorun: yes encoder_pins: ^ar11, ^ar12 click_pin: ^ar43 kill_pin: ^!ar46

The kill_pin just seems to lock up the system (I expected a reset as in Marlin) but its not required very often so does not matter.

@mcmatrix this is a fantastic result thank you very much. regards - bruce

[mcmatrix]

@KevinOConnor What you think? Should we wait for more testings (It's a summertime and people are away from computers) or I'll make PR with 2 commits (for display modifications and menu stuff) and lets merge it with master.

[KevinOConnor]

On Wed, Jul 25, 2018 at 12:01:31AM -0700, Janar Sööt wrote:

@KevinOConnor What you think? Should we wait for more testings (It's a summertime and people are away from computers) or I'll make PR with 2 commits (for display modifications and menu stuff) and lets merge it with master.

I'd like to see this merged. Once it's in the main branch, I suspect we will see more testers.

Also, once it's submitted as a github pull-request, it will make it easier for me to review.

Thanks, -Kevin

[bruce356]

@mcmatrix , hi just a thought, seeing how you are a good knowledgeable programmer (only if you have the spare time) had you given any thoughts to mesh bed levelling for Klipper using a probe like the BLTouch. This would make Klipper far more attractive for larger printer bed users. regards - bruce

[mcmatrix]

@bruce356 Thank you. There are more talented programmers than me :) I'm having delta with glass bed so mesh leveling is quite useless for me. If my bed is somehow transformed then my delta calibration will be off anyway. Don't worry, if the Klippers community will grow then all needed features will come sooner or later ;)

[bruce356]

@mcmatrix , hi would it be possible to add "Babystepping" to the Z axis to fine tune the first layer offset from the bed (maybe in 0.005 increments). I understand that KevinOConnor has added M206 to SET_GCODE_OFFSET for fine adjustment. When starting a print it is much easier quicker to make that final fine adjustment from the GLCD.

Another minor point, under the OctoPrint heading (using your menu) there are no sub options, not sure why. Regards - bruce

printer.zip

[mcmatrix]

Another minor point, under the OctoPrint heading (using your menu) there are no sub options, not sure why.

If you examine Octoprint menu items more closely

### menu octoprint ###
[menu octoprint]
type: list
name: OctoPrint
items: 
    octoprint_pause
    octoprint_resume
    octoprint_abort

[menu octoprint_pause]
type: command
enable: toolhead.is_printing
name: Pause printing
gcode: ECHO MSG=@pause

[menu octoprint_resume]
type: command
enable: toolhead.is_printing
name: Resume printing
gcode: ECHO MSG=@resume

[menu octoprint_abort]
type: command
enable: toolhead.is_printing
name: Abort printing
gcode: ECHO MSG=@abort

then there's an attribute enable: toolhead.is_printing it means that menu item is only enabled (visible) when this condition is true. If you want these items visible all the time then just remove enabled attribute or put it enable: true

hi would it be possible to add "Babystepping" to the Z axis to fine tune the first layer offset from the bed (maybe in 0.005 increments). I understand that KevinOConnor has added M206 to SET_GCODE_OFFSET for fine adjustment. When starting a print it is much easier quicker to make that final fine adjustment from the GLCD.

SET_GCODE_OFFSET [X=<pos>|X_ADJUST=<adjust>] [Y=<pos>|Y_ADJUST=<adjust>] [Z=<pos>|Z_ADJUST=<adjust>]: Set a positional offset to apply to future G-Code commands. This is commonly used to virtually change the Z bed offset or to set nozzle XY offsets when switching extruders. For example, if "SET_GCODE_OFFSET Z=0.2" is sent, then future G-Code moves will have 0.2mm added to their Z height. If the X_ADJUST style parameters are used, then the adjustment will be added to any existing offset (eg, "SET_GCODE_OFFSET Z=-0.2" followed by "SET_GCODE_OFFSET Z_ADJUST=0.3" would result in a total Z offset of 0.1).

I think it's possible. But I leave it for you to figure it out. Please look existing items in example-menu.cfg You should be able to put this together quite easily. Hint, it should be input type, input parameter should be number (0), in gcode you should use Z_ADJUST. So whatever amount you will execute it will be added to existing offset. You cannot read back existing offset in menu item, so each time you start this "babystepping" menu input starts from 0.

[bruce356]

@mcmatrix, I appreciate what you are trying to do but I have no clue to programming in Python or anything else. It is easy to look at what other people have done and copy plus make minor changes.

I have used your Test Menu section to attempt to add a BabyStepping section as follows:-

test menu

[menu test] type: input enable: true name: "BabySt Z:{0:05.3f}" parameter: toolhead.zpos input_min: -0.2 input_max: 0.25 input_step: 0.005 gcode: G1 Z{0:.3f}

I have no idea if this is what you had in mind but it is just about all I can do to copy your example and make minor changes.

Thanks and regards - bruce

[mcmatrix]

I would try something like these

[menu babystep_adj]
type: input
name: "BabySt adj Z:{0:05.3f}"
parameter: 0
input_min: -0.25
input_max: 0.25
input_step: 0.005
gcode: SET_GCODE_OFFSET Z_ADJUST={0:.3f}

[menu babystep_abs]
type: input
name: "BabySt abs Z:{0:05.3f}"
parameter: 0
input_min: -0.25
input_max: 0.25
input_step: 0.005
gcode: SET_GCODE_OFFSET Z={0:.3f}

babystep_abs is for setting absolute offset value and babystep_adj will adjust existing offset by amount.

At the moment there's no way of reading these offset current values in menu input so you have to use 0 as an initial value. In the terminal, you can check existing offsets when using GET_POSITION gcode and look gcode homing: section.

[bruce356]

@mcmatrix , thanks very nicely done and nothing like I imagined. I have finally uploaded all to my Dual X Carriage printer.

What I find strange is that none of the movement settings through the GLCD take effect until dial button is pressed. Is it not possible for movement to take place while rotating the dial as with other firmware.

The Babystepping does work but with a considerable time delay (I guess it depends on where it was placed in the Que) and also no effect until after button press. Regards - bruce

[mcmatrix]

What I find strange is that none of the movement settings through the GLCD take effect until dial button is pressed. Is it not possible for movement to take place while rotating the dial as with other firmware.

This is how input item is currently working. Click on edit item will enter into edit mode allowing value change and another click will exit from this mode and formatted gcode will be executed. Could be that in the future this will be modified to allow realtime change.

[bruce356]

@mcmatrix , Just going through and doing some testing of the Menu Move system, X Y & Z seem to be working as expected but "E" is making strange movements on my printer, movements seem to be very fast (that may be by design, can this be changed), nothing above 50mm of movement seems to work for me and the movement distance is not consistent, sometimes moving the set distance other times just a small amount and other times no movement at all. Is the movement on "E" set to G91 Relative Positioning or G90 Absolute Positioning (can this be changed from one to the other).

I am very pleased with this addition to Klipper, without the GLCD Menu option I would not have gone from Marlin to Klipper as I prefer to control my printer this way.

Thanks & regards - bruce PS it seems that "E" is set to G90 Absolute Positioning but does not show its actual position as for XYZ this is confusing, would it not be better to have "E" set to G91 Relative Positioning?

[Taz8du29]

@bruce356 For the 50mm distance, it's normal. If you didn't change the configuration, Klipper defaults the maximum allowed extruder move to 50mm.

Ses the example.cfg file documentation for more details

[bruce356]

@Taz8du29 , thanks I missed that option, so many things to configure. @mcmatrix , I understand now how extruder move functions (as you have set it up) but as it is, it would be nice to display its actual position from the starting point (starting point being +000.0). If moved to say +100mm (& once moved the display returns to +000.0) and it may need reversing by say 10mm that then means setting the display to +90mm (& again once moved the display returns to +000.0). My logical assumption was that if wanting to reverse by 10mm the display would need to be set at -010.0 but this causes the extruder to reverse by 110mm not the 10mm expected. That is why I feel the display should show actual position (if its possible on the extruder) otherwise one has to remember ones last position selection, other wise unpredictable movement will occur. The other option would be to set the extruder (if its possible) for that short period of use to G91 Relative Positioning. Regards -bruce

[mcmatrix]

@bruce356 Thanks for your feedback. I'll check once more how extruder movements are working.

[unnefer1]

I love the work you've done, very nice and great effort.

My only feedback, which has most likely come too late now, is a change to the naming convention you've used for the sections in printer.cfg and how the root items are initially set - all in the name of making it more user friendly and easier to navigate.

Due to the current naming convention, if a very descriptive group or list item name is not used, and/or the sections are not entered in a flowing order, it makes it all but impossible to quickly discern what section belongs to what.

On quick inspection, everything basically looks like it belongs to a single menu item called "menu" as each section lists the word "menu" first and then only the group or list item name.

Adding to the problem above, if there are any instances it would make sense to use the same group or list item name (eg. up, down, on, off, etc), you cannot actually do that with the current naming convention as you'd end up with a duplicate section name, so you need to append an index of some sort so there is no conflict (eg. up1, down1, up2, down2, on1, off1, on2, off2, etc).

Current menu structure of a pretty standard menu for a 3D printer:

# Menu manager
[menu]
root: main1
rows: 4
cols: 16

[menu main1]
type: group
name: Main menu
items: info, control, octoprint, babysteps

[menu info] 
type: list
name: Information
items: version, status

[menu version]
type: command
...

[menu status]
type: command
...

[menu control]  
type: group
name: Printer Control
items: fan, temperature, movement, 

[menu fan]
type: list
name: Fan Control
items: 
    on
    off
...

[menu on]
type: command
...

[menu off]
type: command
...

[menu temperature]
type: group
name: Temperature
items: bed, nozzle

[menu bed]
type: list
name: Adjust Bed Temperature
items: 
    down
    up
    off2
...

[menu down]
type: command
...

[menu up]
type: command
...

[menu off2]
type: command
...
[menu nozzle]
type: list
name: Adjust Nozzle Temperature
items: 
    down2
    up2
    off3
...

[menu down2]
type: command
...

[menu up2]
type: command
...

[menu off3]
type: command
...

[menu movement]
type: group
name: Move Axis
items: X, Y, Z
...

[menu X]
type: list
name: Move X Axis
items: 
    left
    right

[menu left]
type: command
...

[menu right]
type: command
...

[menu Y]
type: list
name: Move Y Axis
items: 
    back
    forward

[menu back]
type: command
...

[menu forward]
type: command
...

[menu Z]
type: list
name: Move Z Axis
items: 
    down4
    up4

[menu down4]
type: command
...

[menu up4]
type: command
...

[menu octoprint]
type: list
name: OctoPrint
items: 
    pause
    resume
    abort

[menu pause]
type: command
...

[menu resume]
type: command
...

[menu abort]
type: command
...

[menu babysteps]
type: list
name: BabySteps
items: 
    adj
    abs

[menu adj]
type: input
...

[menu abs]
type: input
...

My suggestion, as can be seen below, is to use a parent/child approach for the naming convention of the sections, which makes it far quicker and easier to identify what parent group/list section each child item section belongs to.

By naming the sections the way I have below, it gets around the problems where list items use the same name (eg. up, down, on, off, etc) as the section name includes the parent group/list name, meaning you don't have to append an index - and that makes it very easy to work through and know exactly what belongs to what.

The same menu structure as above, except this time with the cvhanges I suggest:

# Menu manager
[menu]
rows: 4
cols: 16
type: group
name: Main Menu
items: info, control, octoprint, babysteps 
#Root "parent" menu items above are listed on LCD when menu is activated

[menu info] 
type: list
name: Information
items: version, status

[menu info version]
type: command
...

[menu info status]
type: command
...

[menu control]  
type: group
name: Printer Control
items: fan, temperature, movement, 

[menu control fan]
type: list
name: Fan Control
items: 
    on
    off
...

[menu control fan on]
type: command
...

[menu control fan off]
type: command
...

[menu control temperature]
type: group
name: Temperature
items: 
    bed
    nozzle

[menu control temperature bed]
type: list
name: Adjust Bed Temperature
items: 
    down
    up
    off
...

[menu control temperature bed down]
type: command
...

[menu control temperature bed up]
type: command
...

[menu control temperature bed off]
type: command
...

[menu control temperature nozzle]
type: list
name: Adjust Nozzle Temperature
items: 
    down
    up
    off
...

[menu control temperature nozzle down]
type: command
...

[menu control temperature nozzle up]
type: command
...

[menu control temperature nozzle off]
type: command
...

[menu control movement]
type: group
name: Move Axis
items: X, Y, Z
...

[menu control movement X]
type: list
name: Move X Axis
items: 
    left
    right

[menu control movement X left]
type: command
...

[menu control movement X right]
type: command
...

[menu control movement Y]
type: list
name: Move Y Axis
items: 
    back
    forward

[menu control movement Y back]
type: command
...

[menu control movement Y forward]
type: command
...

[menu control movement Z]
type: list
name: Move Z Axis
items: 
    down
    up

[menu control movement Z down]
type: command
...

[menu control movement Z up]
type: command
...

[menu octoprint]
type: list
name: OctoPrint
items: 
    pause
    resume
    abort

[menu octoprint pause]
type: command
...

[menu octoprint resume]
type: command
...

[menu octoprint abort]
type: command
...

[menu babysteps]
type: list
name: BabySteps
items: 
    adj
    abs

[menu babysteps adj]
type: input
...

[menu babysteps abs]
type: input
...

[mcmatrix]

@unnefer1 You have an interesting concept by using namespaces or relative naming. I added a small change in menu code so that you can use a mixed namings :)

### menu main ###
[menu main]
type: list
name: Main Menu
items:
    octoprint

### menu octoprint ###
[menu octoprint]
type: list
name: OctoPrint
items:
    .pause
    .resume
    octoprint_abort
    octoprint abort2

[menu octoprint pause]
type: command
enable: toolhead.is_printing
name: Pause printing
gcode: ECHO MSG=@pause

[menu octoprint resume]
type: command
enable: toolhead.is_printing
name: Resume printing
gcode: ECHO MSG=@resume

[menu octoprint_abort]
type: command
enable: toolhead.is_printing
name: Abort printing
gcode: ECHO MSG=@abort

[menu octoprint abort2]
type: command
enable: toolhead.is_printing
name: Abort printing2
gcode: ECHO MSG=@abort

When in attribute items the item name starts with . then the system will add container namespace as a prefix to it otherwise absolute naming is used. It's still in my local repo. It'll be available when I push PR update. Stay tuned!

[unnefer1]

That is really awesome Janar, I didn't expect any change would be made this far along. Top stuff.

I'm working through a few prints at the moment, so won't have the chance to pull the code until the weekend, but once I have a moment, I'll give it a go using attirbute items and spacing in the sections names.

Cheers.

[mcmatrix]

PR https://github.com/KevinOConnor/klipper/pull/500 is updated with the latest work.

[mcmatrix]

This feature is now in the master branch.