Marlin: Making user life easier with config files

[ruggb]

Per request, I am using this to present my ideas for making Marlin a little more user friendly.

I have 3 targets to accomplish this:

1. Make the config file contain everything that is user configurable for basic operation. Optional items like special steppers, bed leveling, LCD and SD items, will be in separate files and included as the user requires.
2. Make the configurable items stand out by using /...../ format for text only lines. Any line starting with // is a user configurable item in the config files. Obviously, some ppl are doing that already, but it is inconsistent.
3. Organizing all configurable items for an item in one section. That requires defining the sections. Currently, there is an extruder, hotend, hotbed, temperature, motion, stepper, LCD, conditionals, etc, etc. sections. So where do you put the temp variables for the hotend? Right now, I think you can find some in 3 places, and maybe 2 or 3 different files.

So far, most everyone agrees it will help operation, configurability, troubleshooting, and documentation.
There are also a number of "can't do that" issues being voiced. Most I think are procedural and can be changed easily with a buy in to the plan. One I need to resolve before I start - syncing forks. I have no clue how this works, if it will be a problem, and how it is resolvable. Will someone educate me? thx

I have never done this, but I am going to try to create a fork and build my model. Maybe that is an indication that I have totally lost my mind. But.........

Please..chime in

[ruggb]

I created these optional function files. Note: it was done on a previous build, before someone else created the auto bed level file that exists now. I haven't compared them but I am sure they are the same. Also, I think the filament sensor didn't quite work. It needs a little work. There may be others that I break out. I think the names are self explanatory. (only names, no file) Includes for these functions are in the config file.
auto_bed_level.h
filament_sensor.h
L6470_driver.h
lcd&sd_card.h
mesh_bed_level.h
nozzle_park_clean.h
rc_servo.h
TMC2130_driver.h
TMC26x_driver.h
z_probe.h

[ruggb]

This is the initial config file created from build 493e738.
Note: the #include statement near the top and the format of the comments vs the commented out code.
I think that is complete in this file but if you see one that isn't - ignore it. Any text at the end of a code line uses //
Compare this to any current version to see if it is easier to pick out code from text.

Configuration.h.txt

This may contain some rearranged code, but it is not complete.

[Bob-the-Kuhn]

Either you've done one heck of a lot of work previously or you're a really fast typist or Ultraedit is something I need to check out.

Apparently you have a thing for clean directories. You wouldn't like my work environment. :-)

Changing the style of the comments is definitely a really good thing.

I have mixed feelings on moving options off to their own files. It's nice to have them all in one file. It's a pain to have them all in one file. I'd have to use the proposed system before I can make up my mind.

---

Hopefully a Doxygen formatting guru will chime in here but ...

My understanding is that the desired format is:

• Initiate a comment with a /** by itself on one line
• Close it with a */ by itself on one line
• Have a * on every line in between including blank lines
• Line up all the * with the first one in the opening

The down side is those nice one line comments change from

/* I like this format */

to

/**
 * Not as nice
 */

[ruggb]

@Bob-the-Kuhn Yeah, Ultraedit is great especially for programmers. It can be configured to do a lot of the formatting work for you.
However the answer is not related to Ultraedit or my typing skills, which really don't exist.

I did a lot of work on both config files and verified my changes worked on my build. There is no rocket science there, just consistency, and no code changes so it should work for anyone - UNLESS the BOOTSCREEN_TIMEOUT thing is an indication of something the compiler can't handle or an issue with it.
But I am sure there is a logical answer for that.

By OPTIONS I am not talking about simple if statements - I am talking about the support for non-standard stepper motors, different forms of bed leveling. The LCD one could be called a stretch, but because it takes up a lot of room, and is not something that all machines have, looking at it in a separate file makes the config file a lot easier to navigate for basic stuff.

RE formatting -- Not quite - unless I missed a few ALL the comments are formatted like your from version

/* single line comment */

/* multi line comment - obviously only needed if one has a lot to say in instructing with a

• comment */

/* multi line

• comment with define after it */
  //#define something //uncomment this line for something

It would be nice if the editor was smart enough to color those commented out code lines.

there is no /** line - if there is a need for that line I am unaware of it.

[Bob-the-Kuhn]

I've been told that the long term plans are to use Doxygen to help generate documentation. The /** comes from that.

[ruggb]

but you don't like that -

I think I am starting to learn more about C than I wanted to. If a CPP file is for definitions and H file is for declarations why does nozzle.cpp include Marlin.h, nozzle.h & point_t.h - AND nozzle.h file includes point_t.h and marlin.h also. My plan to break up config file was met with some opposition based on "convention". Now I understand why, I think, but the above compromises that in a very redundant way. My purpose for the includes is to add to the declarations of a config file so that the configs are manageable and linked. The former seems haphazard, is it?
If marlin.h is not used in nozzle.h and point_t is used in nozzle.h, then why put marlin.h in nozzle.h and point_t in nozzle.cpp? Does this redundancy help?

[oysteinkrog]

I don't really understand how this is easier for users, why should a user have to mess around with header files?
The current config file system where a user enables the features needed seems easier to me.

[ruggb]

@oysteinkrog the last time i looked configuration.h and configuration_adv.h and language_en.h and version.h and ultralcd.h and pins.h and ......................h were all header files. Are you saying Marlin should be totally autonomous and the user should not have to change anything. That would surely eliminate a lot of issues, mostly about being user friendly.

Enabling an #include xyz.h and going to THAT file to specifically change parameters associated with THAT OPTIONAL function is a lot less mental gymnastics then dealing with all that code in one file required for BASIC operation.

I am not most users, but I am betting, like me, most users do not have bed leveling, let alone 3 types of bed leveling. They also don't use 3 types of special stepper motors. The most commonly used separate H file would be an LCD file. That represents over 1/3 of the lines in the config file that many users would not have to see or deal with.

So what would be your plan to make Marlin more user friendly???

[oysteinkrog]

So what you really don't like in the end here is that all configuration options are in one/two files, instead of spreading them across many files in a modular fashion?
I think it makes more sense to use a configuration tool/frontend to generate the config files, such tools have existed in the past but I'm not sure about the current state of things.

[BillStruve]

I like the idea of having each kind of configuration in its own file
instead of massing them all in one large configuration.h file. That one has
gotten too large and disorganized. It does​ make the include list in the
.CPP files longer, however.

On Mar 15, 2017 10:51 AM, "Øystein Krog" [e-mail] wrote:

So what you really don't like in the end here is that all configuration
options are in one/two files, instead of spreading them across many files
in a modular fashion?
I think it makes more sense to use a configuration tool/frontend to
generate the config files, such tools have existed in the past but I'm not
sure about the current state of things.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/6024#issuecomment-286765745,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWTxnETNwhTkNBJPaiQh1mUSOeYK0lexks5rl_rfgaJpZM4McpjV
.

[ruggb]

@oysteinkrog What I would like to see is one config file that contained all the basic user configurable items to make a basic printer work. Then set includes for OPTIONAL functions and refer the user to the appropriate file to enable/disable/modify #defines as they need. ALSO, that config file need related functions grouped together. We don't currently have that.

Repetier uses a config tool. When I tried it, it left a lot to be desired. I would say that in order to go that route you need to have a very organized and complete config file first. Think about how a structured format like that would fit right into a config tool.

@BillStruve No Bill. the includes in any of the other files do not change. If they have to, there is another problem to be fixed. What you are doing in moving the section (like LCD & SD CARD) out of the config file into it's own file. If you have an LCD, you enable the #include in the config file and go to the LCD file to select your options. If you don't have an LCD you don't have to wade thru all that stuff for your printer. The same with bed leveling, special steppers, etc.

Anything you want the user to be aware of and enable/disable/modify is in the config file organized in related sections.

EDIT: I got your thought process just now. You are thinking according to convention that includes are only in CPP files.

1st, Marlin does not currently comply with that convention and there are issue to be fixed relative to it.

2nd, you might like to read my last response in #5913

[BillStruve]

OK, got it - the configuration.h file is where the other, device specific,
.H files are included. Good!

On Mar 15, 2017 11:47 AM, "ruggb" [e-mail] wrote:

@oysteinkrog https://github.com/oysteinkrog What I would like to see is
one config file that contained all the basic user configurable items to
make a basic printer work. Then set includes for OPTIONAL functions and
refer the user to the appropriate file to enable/disable/modify #defines as
they need. ALSO, that config file need related functions grouped together.
We don't currently have that.

Repetier uses a config tool. When I tried it, it left a lot to be desired.
I would say that in order to go that route you need to have a very
organized and complete config file first. Think about how a structured
format like that would fit right into a config tool.

@BillStruve https://github.com/BillStruve No Bill. the includes in any
of the other files do not change. If they have to, there is another problem
to be fixed. What you are doing in moving the section (like LCD & SD CARD)
out of the config file into it's own file. If you have an LCD, you enable
the #include in the config file and go to the LCD file to select your
options. If you don't have an LCD you don't have to wade thru all that
stuff for your printer. The same with bed leveling, special steppers, etc.

Anything you want the user to be aware of and enable/disable/modify is in
the config file organized in related sections.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/6024#issuecomment-286784420,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWTxnFhjstStZ429UxIZ4Xn78r7tXZolks5rmAf3gaJpZM4McpjV
.

[Roxy-3D]

The bulk of the reason the configuration options are in one file was to help the user. When a new revision of the software comes out, it was thought that it would be easier for the user if they could just copy their old Configuration.h file to the same directory where the new software was. And then they could compile and start printing.

In practice, it isn't that easy right now because a lot of names for options are being cleaned up. But that was the intent and when the names of various options stabilize, it maybe we get back to that point. There is a lot of merit to putting the options for any given sub-system in that sub-system's .h file. But the down side for a user is that means they will need to edit 10 or 15 different files.

As a software person working on the code base, I think I would prefer the options being the respective sub-system .h files. But as a hobbiest just trying to get a new printer going, or updating the firmware on an old printer, I think I prefer the way it is.

[BillStruve]

Roxy-3D, I'm both and see your points. Your 10 to 15 is an overestimated count in my opinion. LCD (which I don't have), temperature control (don't have any), bed leveling (love that!), and since everyone has a kind of printer (printer type) with motors (motor control), those could be left in the confirmation.h file. Currently, the two config files seem to have an arbitrary split of settable parameters. Need logical names for the files that contain user settable parameters. Adding '_adv' does nothing for me.

[BillStruve]

Not 'confirmation' - I have a hate/love relationship with automatic word complete/correct!

[ruggb]

@Roxy-3D Yes, Think about it. One config file with includes for options. One config file to load b4 other files need the info. A new commit comes, copy the config file. If you have an LCD copy that one, etc. How many will I have to copy - 2. Since I have taken the config files and option files I use and stored them in a separate folder for safekeeping it is about a 3 click D&D process. If I had 10 (and I don't think there will ever be that many) it is still a 3 click process. Now, a readme.txt file in the distribution would be good to tell me if any of these files have changed. Since they are small and specific it becomes a LOT easier to inspect the changes than wade thru one with everything in it. That is a lot of eyestrain.

[ghost]

Eventually, someone wil also breakup the ultralcd.cpp file into sub-menu files. Lol

[thinkyhead]

This is a good discussion for Version 1.2.

I tend to agree that a web-based configuration tool would be best, because it can be comprehensive, include documentation, provide starting-point configurations, and —best of all— convert old configurations into newer ones. With such a tool in place, then it's not over-burdensome to have one config file, or two, or several category-based configuration files, if desired.

Version 1.2 will begin by breaking up the existing code up into sub-folders by category, with gcode handlers also split into many separate files. https://github.com/MarlinFirmware/Marlin/tree/breakup-marlin-idea/Marlin

Since it's going to be a long-term project with the aim of cleaning up, especially, the high-level code and making Marlin more modular, breaking up the configurations and documenting them in a standard way is a reasonable first step.

[ruggb]

This is something a long forgotten developer was trying to do at least 18 months ago. I was trying to work with him on it but I thought he was going in the wrong direction. He just stopped abruptly, I'm guessing from a lack of interest from the powers that were, or maybe he passed on.
Obviously, I have strong opinions on this RE the USER files. The first one being that when a user opens the Marlin folder, it would be nice if they were not presented with 230 files. We could do that easily. All the language, pins, thermistortable, dogm files in separate folders, even in the same sub-folder, just so the user doesn't see them. We are down to 100 files now. Developers might like to see most of the rest of the files in the same sub-folder - I don't know, I'm a user, not a developer. It is just a path variable, right. I am sure you could get it down to:

CODE = folder = the rest of the files
DATA = folder = the above mentioned files
machine specific configs = the example config folder
configuration.h
Marlin.ino

that the user would see. Nice, huh?
Once you are there, you have organized it such that you can think about a config tool.
You now have ALL user configurable items in ONE file. Makes creating AND maintaining the tool somewhat simple. The user doesn't see any code files, or care to. Any code changes that create/modify a user variable changes the config file and tool. Otherwise, it is transparent to the user.

I am there already with my config file, except for a few items in the ADV file that I don't know how to move to the config file. Something in the code files needs to be changed to make it work - order of loading and refs to the ADV file.

If someone were really interested, you might find it could be done and tested easily for the release of 1.1.0.

NOTE: I am only able to test this on my machine. I do not know how you test/verify a commit. I have not uploaded my changed files to my fork yet. Since there is no code changes, I would expect it to work for any configuration, but I know ANY is a big word and I don't know if any links are broken because of the reorganization. All I know is it works on my machine and it compile as a virgin copy.

[thinkyhead]

All the language, pins, thermistortable, dogm files in separate folders, even in the same sub-folder
it could be done and tested easily for the release of 1.1.0

Now that Arduino IDE can handle it. But version 1.1.0 is the last "flat" version of Marlin. We're not adding subfolder-dependency at this late stage, even though the IDEs have progressed. It's part of the specification for this release to keep it flat and comparable to 1.0.x. Version 1.2.x is all about subfolders, etc.

[ss89]

+1 for a web app that would create/upgrade/(possibly even downgrade?) configurations including defaults as we have them now (Delta/Scara/Cartesian and possibly even more known machines?). I had this idea too in the recent days which is why i checked the issue list for something that mentions this - so someone was earlier on this topic.
Depending on what i planned (i haven't read the breakup marlin part yet), it might make sense to wait for the changes of 1.2 to be done before even starting this project.
Nice Gimmick would be: to be given a hex file that is ready to flash for your printer (or the way repetier does it: give a zip with the configuration already inside).

[ruggb]

You must go thru the configuration process with Repetier to get the config file. They aren't mind readers either. And the process is not clear and concise as you might imagine it to be.

@thinkyhead What I am proposing for RC8 is not to add sub-folders. My version is at [https://github.com/ruggb/MarlinFW]. It does 2 things;

1. Places all users config items into one config file
2. Places optional functions like LCD, SD card, Bed leveling, Filament sensor, Special steppers, etc. into their own file. Then uses #include to add that functionality. To tweak any of them you must separately open the file to do that. That makes things a LOT clearer and thinks related to temp control for instance is all in the same place instead of spread thru out a file or worse across more than one file.
   It is all on the same level. The purpose is to clean up and limit the config file to items that are basic operational items for any printer. In so doing it becomes a lot easier to read, navigate and maintain.
   A big help for this is to standardize the comment format to something that makes commented out #defines and #includes easier to see. There are thins marked with //**?? that need further or better explanation. Version 1.2 can carry the same idea into it, so the changes would not be lost going forward. In fact, it would probably be a big help.

The reason config_adv is still there is because I can't figure out how to move what is left. If I move it it breaks the compile. It has to do with code placement sequence.
PLEASE NOTE: it is not complete, but it is almost there. It is also not based on the latest RC8bf commit. It is a couple behind. It also isn't a fork, because I just uploaded the files I changed from my system.
@Tannoo has been contributing to it also because she likes the organization, I guess.
There isn't any code changes, just reorganization. It works on my printer, but I can't say selecting another option, like bed leveling, will work because of the code placement issue during compile.

Anyway, I think it deserves a look and an opinion. I am planning on trying to do this properly with a fork soon, so it would be a good time for feedback.
thx