Configurator is diverging from current configuration

[Wackerbarth]

We really need a better way to keep the configuration stuff in sync.

However, until a better scheme is implemented, we need to try to keep things consistent.

I have started a "Configurator" branch in my (Wackerbarth/Marlin) repository to start addressing the current differences. Please review it there to assist me in formulating a "clean" pull request to address the issue in this repository.

[boelle]

do you mean the configurator? http://marlinfirmware.org/configurator/

?

[Wackerbarth]

I mean Marlin/configurator/config/Configuration.h, etc.

[boelle]

Ok, But i guess it will take some time... So far we only have one active coder on the project @thinkyhead

Reason it takes time is that there is only one active coder and there are more serious bugs to take care of first

[Wackerbarth]

I'm willing to do what I can to make Marlin/configurator/config/Configuration.h and Marlin/Configuration.h the same. However, I need some help in learning which one is "correct".

For example, Marlin/configurator/config/Configuration.h has some entries like

// @section machine

that are not in Marlin/Configuration.h

and the "default" machine is an ULTIMAKER in one and a RAMPS in the other.

Which machine should be represented?

[boelle]

That issue is not important right now, there are bugs that have been waiting for 2-3 Years that we need cleared first

#1226
#1460
#1596
#1682
#1362
#1360

Those are the more important ones right now... as soon those are fixed we can move on

Sorry for sounding harsh, but the problem is not only only 1 coder, but also that everyone wants their "own" errors fixed. That is prop the reason why some errors have never been fixed..

[TechMasterJoe]

agreed. with you boelle
i will help with some code where i can. but i know nothing of Github LOL.
i like to think I'm OK at finding Bugs but if the few hours of spare time i can find help.
it's worth it
.
wacker the real answerer is both
i think in the long run the configurator needs to be able to call the sample configs
for the people that added sample configs to marlin but yes it needs a set of generic
configs ready made for each main type cartesian, delta, scara and so on this take a lot of config changes off the user, i was thinking of doing all the configs for makerfarm I3V line as i own them and a few DIY delta's

[nophead]

One could argue that bugs that have been present for years should have very
low, or even zero, priority as they can't be big problems for most people.

On 4 April 2015 at 12:59, Bo Herrmannsen notifications@github.com wrote:

That issue is not important right now, there are bugs that have been
waiting for 2-3 Years that we need cleared first

#1226 #1226
#1460 #1460
#1596 #1596
#1682 #1682
#1362 #1362
#1360 #1360

Those are the more important ones right now... as soon those are fixed we
can move on

Sorry for sounding harsh, but the problem is not only only 1 coder, but
also that everyone wants their "own" errors fixed. That is prop the reason
why some errors have never been fixed..

Reply to this email directly or view it on GitHub
#1810 (comment)
.

[boelle]

or People could have found another firmware as their patience was used up

[boelle]

and either me or @nophead could prob supply a few solid configs for mendel90

and i have some configs for mendel prusa also

[Wackerbarth]

Hey! I'm offering to try to add another "coder" to the resource pool. However, I'm not to a point where I can determine what methodology is currently "correct". Scott started something and, rather than creating my own method, I wish to help him continue the effort. If, collectively, that is undesirable, then something should be deleted. Having "inconsistent" approaches just leads to additional maintenance problems.

[boelle]

Scott gave the thumbs up to this thread...

#1734

[thinkyhead]

The configurations within the configurator are for development purposes currently. Eventually, aspects of those will be brought into the real configurations, and the ones being used for development will no longer be needed. But there are still details to be worked out about how the configurator gains information, and lately the configurations have undergone a lot of changes, some of which have ramifications for configuration utilities. In any case, if anyone wants to help with the configurator, they should work directly with me.

[Sniffle]

@TechMasterJoe I'm the same sniffle from the forum you know there are several ways of contacting me, i can help you out with github if needed. It's not hard but can be confusing when things get out of whack on it.

[boelle]

should we upgrade this one to verified or close it?

[thinkyhead]

Much less divergence now.

[thinkyhead]

Development will continue on Marlin Configurator as time allows. It's still in the experimental alpha stage, as I develop methods to parse and generate configurations, form fields, etc. It has only a raw "expert" interface so far (with almost every option exposed) but will get a simplified interface and a presets menu over time. Now hosted at:

• https://github.com/thinkyhead/MarlinConfigurator
• https://rawgit.com/thinkyhead/MarlinConfigurator/master/src/index.html

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.