Resolving {software | hardware} endstop situation

[Traumflug]

These have been on low importance for now, but show non-intuitive behaviour from time to time. From a talk to a Teacup user:

I tried to print an object and it was an absolute mess. From the second layer on the hot end was dragging through the previously laid down plastic. I just got worse and worse with every layer.

and later on:

I had the minimum Z value set to 2, so after it homed, it was at a position that was below the minimum. The logic probably didn't know what to do and thought it best to just not raise up. I set to 0 and all is well.

This is how the current code works: homing position is set to 0 (hardcoded) and all incoming G-code is clamped to be within Z_MIN, Z_MAX, ... Accordingly the first few layers (with Z0.1..Z2.0) would all be changed to Z2.0, no movement resulting.

Similar confusion here, as part of a pull request https://github.com/konoppo/Teacup_Firmware/commit/dcd3faf319939809ad001998fa08189ce60e35fa :

My printer have enstops few milimeters behind printing area. I found useul to put endstop position in configuration. The second thing in configuration is position to go after homing - for example if you want to have "home" in the center position.

[Traumflug]

How about this plan?

• Use X_MIN, X_MAX, Y_MIN, Y_MAX, Z_MIN, Z_MAX for clamping G-code (software endstops) only.
• Introduce #define USER_HELP and send out a warning if G-code had to be clamped.
• Additionally introduce X_ENDSTOP_POSITION, Y_ENDSTOP_POSITION, Z_ENDSTOP_POSTITION and set the zero point according to these after homing. This way endstop position and build room are independent of each other.
• Move each axis to be within the defined build room after homing. This way the Z axis had moved up by 2 mm after homing in the first case.
• Ignore a second endstop on an axis for homing. Homing to both is pointless (unless we'd introduce automatic build room measuring using them). Most printers have only one endstop anyways.
• Remove G161 and G162, they're pointless, then, too.

Anything missing? Anything else which can be removed?

[jbernardis]

Sounds reasonable to me. I like the second bullet where the user would get a warning.

[Traumflug]

First steps are on the endstops branch.

The million dollar question is now, how to introduce such additional #defines with Configtool? Or just a bunch of improved help messages, for that matter? Once users saved their own configuration, they won't notice such changes with the current Configtool strategy. Putting #error lines into the code can give hints and prohibit from compiling faulty binaries. But asking them to start over with a fresh distributed board or printer file isn't exactly comfortable. Neither would be to ask them to fix their configuration manually.

Is there some way imaginable to process some kind of printer description file updates? Perhaps to load one of the distributed board/printer files for comparison? Or by some distributed upgrade description file?

[jbernardis]

I think we have to have some kind of utility that scans through the directory and updates the files. The problem is that if a user is multiple commits behind the logic for catching up could be a nightmare. I think this is what was in my mind when I proposed an xml-based configuration.

But we've decided to stay with C header files, so what about this idea. We have a utility to update config files - it knows about everything that needs to be in the files and can build a valid file, potentially, from nothing. That way it doesn't need to know what commit you're coming from - just where you're going to. No real user interface - default values only.

Any time the configtool is run, it checks to see if this utility is newer that any of the config files. If it is, it runs it. That way the user doesn't have to explicitly run it - although there will (should) be no harm if they do.

This is a non-trivial task, but if you agree, I can start seeing what might be involved.

[Traumflug]

Checking for file age might fail easily if a user updates the date manually somehow. For example, by copying the whole thing elsewhere. Or by unpacking another version elsewhere, then copying the local config files over.

If I understand the mechanism correctly, Configtool loads these files into a dict or list. How about loading not only the specified board file, but also a distributed one. Then compare these two dicts and add stuff which is in the distributed one, but not in the specified one.

Removing keys is a bit more tricky, because so far we allow additional #defines. We could step back from that, though, because the number of keys useful, but not in a printer or board file is very limited. Adding the remaining ones without exposing them in the GUI would certainly be possible.

The good thing is, all descriptions contain all the keys. Even if this was a not the case, we could add a "generic" printer and board.

[jbernardis]

Config tool already adds keys that it knows about but doesn't find in the file. It does so with a generic description though. We could add a file that contains description text about all fields.

Note that right now, adding fields like this only accommodates text fields and boolean fields. Although it will add a define for a choice, it will not add entries for options. We could come up with a scheme where a list of options could be in the above file as well.

[Traumflug]

We could add a file that contains description text about all fields.

This, or consult one of the distributed templates, which has all these descriptions.

Note that right now, adding fields like this only accommodates text fields and boolean fields.

I think this isn't a problem. Configtool its self does get updated, so you get all the GUI. Problematic are only user-created board and printer descriptions. If you load an older desription with a newer Configtool, either Configtool complains or, worse, Teacup no longer compiles, because some #defines are missing.

[jbernardis]

I've cobbled together a routine that extracts description info from the board and printer files. Tonight when I get home, I can merge this with the add-new-fields logic already in boardpanel and printerpanel. I think this will give us a workable solution.

When a new define is added to the firmware, configtool and the distributed config files are changed with the new information. The user will have to load up their own config files. It's possible that the files will indicate an error right away if the new fields do not pass validation, but when they save the files, the new define will be added along with the descriptive text extracted from the distribution. This means that if the default value assigned to the field(s) by configtool meet the user's needs, all they need to do is load and then save the file.

[Traumflug]

It's possible that the files will indicate an error right away if the new fields do not pass validation

No problem, we have entire control over which new fields get introduced and can also change validation along with them if there's a clash.

[jbernardis]

I have uploaded branch adddefines. It's a pretty simple fix, but to me, it underscores the idea that the structure/format of the config files should really be evaluated.

As a software designer, it bothers me that our data is not normalized. The descriptive information - help text, possible values, data type, etc - should be in 1 file. It's a master file that is distributed (maybe 2 files - 1 for boards and 1 for printers, but the same concept applies). The files specific to a board or printer need only contain values. Many of them would still be protected, and then the user can have their own such files. If we add (or even delete) a field, the corresponding change can be made to the master descriptive file. Configtool would then have a much easier time maintaining (adding and/or deleting) from the value files.

[Traumflug]

As a software designer, it bothers me that our data is not normalized.

I fully agree from the Configtool perspective. If there were only this tool for editing/building I'd also pledge for a separate file with help texts. However, so far we also support building from the Makefile and using a plain text editor for configuration. Then it's much better to have help and values in one file.

To get closer to the idea of normalisation I'd be entirely fine with declaring one of the board/printer descriptions as master. Then you don't have to bother about descriptions in other files. You could even ignore them and load help always from the master file.

If you think the formatting of help texts, values and choice lists needs more standardisation I'm all for it, as long as it's human and gcc readable.

[jbernardis]

No I understand we still want to support those that do not use configtool. Just expressing my frustration