Increase the number of macros avalible

[ithinkido]

Please describe the feature you would like implemented

There is currently a hard coded limit of 4 user definable macros. With work on developing support for I/O expanders , it would be good to increase this amount.

Why do you think this would improve FluidNC?

There are use cases where having more than 4 user definable button macros would be useful. For example -

1. If you have an ATC and would like to manually load a tool. Using a physical button for this task would be an ideal way to do this.
2. The possibility of directly wiring in a jog pendent for manual moves would be a good fit as the button macros are only available when the machine state is idle
3. GRBL ESP32 is often used non CNC standard projects. Many of these would benefit from an increase in usable tactile, offline controls.

What do you need the feature for?

To retro fit to a Roland pen plotter and keep functionality such as pen select

Do you know of other users who need this feature?

There is a growing community of people using GRBL with pen plotters. The current macro allocation can be quickly used up when this is used for any functions related to pen / tool change.

[cotepat]

The macros are currently pretty limited (no variables, calculation etc...). Only pure G-Code... I also dream about more features available from hardware buttons. For instance : Probe Z, Probe XYZ, Probe with Z tool length offset etc... Unfortunately it's not possible right now. I might give a go at it... Do you know why your pull request was closed ? I also had a branch with pretty much the same code as yours, but I realized afterwards that there was already a closed PR with the same features...

[MitchBradley]

Number of macros: How many is enough? Pick a number and the next person will want more, so endless problem. The current architecture of numbered macros does not extend well. WebUI has a better facility in which macros are stored in files.

Variables and calculation: That is a can of worms involving adding an expression parser. What is the extent of the language and where does it stop? It is easier to add something like that to UI code that is written in a more dynamic language like JavaScript.

[cotepat]

Yeah, I really get that "variables and calculations" in macros would be a very big endeavour and is beyond the scope of FluidNC... But I still think that some higher level functions could be developed and activated via control pins. There is a finite number of very useful functions that we use all the time, and I really hate to go back to a UI for these things. If you look at macros people are developing (with variables and calculations) in CNCjs (https://github.com/cncjs/CNCjs-Macros), the vast majority are related to probing and tool change (probing at a specific location and applying offsets to Z for the new bit). Being able to override feedrate and spindle RPM with +/- buttons could also prove to be useful.

The ultimate goal for me would be to only rely on the UI to prepare and launch a job, and then use physical buttons for the remaining (eventual) operations : adjust feeds and speeds during the job, pause/resume, goto tool change position, probe a new bit, apply offsets and continue with next operation. That's it... I use to work with a small GRBL controller developed by makerfr that integrates all of these things (https://github.com/mstrens/grbl_controller_esp32), but it is still based on a touch screen with several level of menus).

As for the number of macros. I get that people will always want more... But 4 is not a lot. Here is an example of macros I would use all the time : Homing, Goto WCS X0 Z0. Goto WCS Z0, Set probing location, Goto probing location, Unlock ($X). That is 6 right there...

Sorry for the lengthy post!

[MitchBradley]

One way to finesse the problem of the number of macros is to store them in files. In principle buttons could be assigned to access a file-resident macro instead of one stored in the config. That begs the question of how many buttons are available to assign to such macros. Right now it is pretty rare to have enough GPIOs left for a lot of button macros. That might change soon based on Stefan's input expander work in progress, but for now it is usually impractical to have a lot of button macros.

It is already possible to use WebUI to increase the number of macros. That does not solve the variables problem though.

I am well aware of how CNCjs works, since I am one of a very small number of CNCjs developers, and the only one who is doing any amount of support on the Facebook CNCjs User's Group. The CNCjs macro language is fairly extensive. letting you use a fairly large subset of JavaScript expression syntax. The code to implement that is fairly involved. It might be true that most uses are less comprehensive - but once you start turning something into a programming language, you run into the problem that there will always be somebody who wants just one more little feature. If you start with a simple subset with easy syntax, then at some point you run into a syntactic brick wall, so you really should thing about the general problem and adopt a full syntax at the outset. Which means a high-stakes design problem.

WebUI already has feedrate and spindle overrides

[Pastitas]

This also ties in to some functions like moving on the outline of the cut that either need to be specifically implemented or done in macros with some amount of programming capability. I get that everyone has different needs but with programmable macros you kinda allow the users to fill in the gaps themselves, without having to reinvent the wheel.

For example one way that this is done in another proyect is Klipper, which allows for any number of macros to be set up in the config, and then they just become new "Gcode" that you can call from the terminal or any other tool that sends gcode to the machine. This to me seems like a very good approach since I does not limit the ability of the users to do complex stuff while using a jinja2 parsing which is somewhat of a standard with the yaml format of the current config file https://www.klipper3d.org/Command_Templates.html

maybe borrowing some stuff from the Klipper proyect (which already deals with gcode) might yield a bigger ROI in time and effort required

[bdring]

We have these issues in our tracking system.

At this time, most of our time is spent on new user support, so we are primarily working on issues and features to help them. We have limited time and a lot of advanced feature requests.