User Defined Configuration

[pentacular]

Please describe the feature you would like implemented

The ability to include custom fields in the yaml configuration.

Maybe in some kind of custom field.

e.g.,

axis: x: custom: anchor: x: -240

etc

Why do you think this would improve FluidNC?

Code under Custom/ sometimes needs custom configuration.

What do you need the feature for?

I've just put together wall plotter custom kinematics in grbl esp32, and thought I'd see if I could port it across.

As part of this, I need to be able to configure the anchor points, which I previously did using a #define.

It seems like this is something that ought to be configurable, but I read in the wiki that unsupported keys will be dropped, which makes it sound currently impossible.

I can compile these fields directly into the Custom/wall_plotter.cpp, but that feels a bit like a regression.

Do you know of other users who need this feature?

No, but I can guess that most of the Custom/ code will want some kind of configuration support, otherwise it probably wouldn't be in Custom/ :).

[MitchBradley]

The custom code facility for FluidNC has not yet been designed. When we design it, there will be some way to add config items.

[pentacular]

I see.

Is there a rough roadmap or timeline for that level of work?

I'd be happy to contribute, but I can't do much with FluidNC at the moment without custom kinematics.

[bdring]

We track bugs and basic features on a Trello board. We also have this wiki page with some basic TODO/roadmap items. We have most of our development discussions on Discord server

Kinematics is coming soon. Ideally many implementations like CoreXY are precompiled. We have been discussing new ways to implement it. One thought is to have transform matrix option that could be setup in the config file. That would cover many types. More complicated ones would likely need to be compiled likeGrbl_ESP32.

[pentacular]

Yes, I suspect that the fundamentally different types will need to be precompiled -- like CoreXY, polar, wall plotter, etc.

To be honest, I don't have a problem with recompiling for non-standard kinematics. :)

I'll see if I can figure out how to review the discussions on discord -- thanks.

[MitchBradley]

Since you appear to be a programmer, perhaps the best approach is not to wait for our efforts to modularize the kinematics and other customization points, but rather just add it however seems appropriate, guarded by ifdefs. That will serve as information to guide us when we do get around to refining the customization architecture.

MotionControl.cpp in FluidNC is quite similar to Grbl_Esp32 apart from the homing, which was rewritten extensively. The weak link hooks for kinematics are still present in the same form and usage.

Look at src/Custom/oled_basic.cpp for an example of adding custom code guarded by an ifdef.

To add a configuration section, look at src/Machine/MachineConfig.cpp: MachineConfig::group() and the variables like _start in src/Machine/MachineConfig.h

[pentacular]

Sounds good.

I'll open an issue specific to kinematics.

[pentacular]

It's a bit unclear to me how I'd do a build with src/Custom/oled_basic.cpp

Wouldn't the right integration point be via CustomCode.cpp ?

[MitchBradley]

To include oled_basic.cpp, uncomment the "INCLUDE_OLED_IO" and "INCLUDE_OLED_BASIC" #defines in Config.h

The custom code approach that we used in Grbl_ESP32 did not work well with platformIO, which did not detect changes to that file, thus requiring manual clean when the file was edited. The other problem with having a single CustomCode.cpp is that you can only have one such file. I think it is better to allow multiple custom files. The ifdef approach does go against the overall FluidNC approach of runtime configuration, but custom stuff is not likely be part of the standard release, at least not initially, so ifdefs seem like an okay approach within the constraints of platformio.

[pentacular]

Ok, I think we can close this out.

Thanks.