OK ChiliPeppr users, help me decide what to do next on the configuration utility (and understand it’ll probably be Sunday before I get free time again). Ideas on the list (no particular order):
I vote for a “Standard Configurations” pulldown menu with:
Shapeoko 1
Shapeoko 2
Ox
3020
3040
6040
etc.
I love this idea, but there are so many standard configurations for the so2 alone. Dual-y axis? Acme upgrade? Size upgrade?
More to the point, where do I get the values for each? I only have the values for my system.
But in terms of bringing more new users on-board easier I think this idea is hard to beat.
You ask for people to send in their settings via a detailed form, then see which is the most ‘standard’
I’ll agree with JohnL, a “Standard Configuration” would be great, but there is a practicality issue to be aware of: ShapeOko1 started XYZ(mostly), (GRBL days), then along came tinyG with 4 drivers and there evolved XYZY[r] machines, XYY[r]Z machines and a few who just did their own thing like ZY[r]XY. because they wired it wrong and that is the way it ended up. ShapeOko2s depend on whether it is an upgraded ShapeOko1, a stock ShapeOko2 or a NEMA 23 ShapoeOko2…
Confused? So are a lot of folks.
So I’ll change my vote to mm and inch. I’ll posit the claim that more milling bits have been broken here than any other reason.
configtinyG is really great, but you need to avoid the screen-door-in-a-submarine analogy, so pick you battles carefully 
Another thing that occurred to me Carl is that your addition is a great way to make standard configurations available.
Yup, that is probably the simplest version of the Requirements Doc, but it will implement the very personalized “How my machine was built and configured when I decided to make a snapshot” backup.conf, which is perhaps the most practical at this point.
It will also provide the capability for a machine supplier to make available a specific Do-It-This-Way.conf file, that combined with a build-and-wire-it-this-way set of instructions will provide the desired ‘standard’ config. And, of course, configtinyG will work with it to make the parameters GUI friendly, customizable, and then no longer stanstard. A vicious circle…
Both the standardized and personalized worlds need inch vs mm sorted out.
You lot need to move out of the 19th century. See how easy that was? Next?
I think the best thing would be to add descriptions to each variable to help new people understand what they do.
Joshua’s idea is intriguing; it could be implemented with an active index into the tinyG wiki such as https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#1ma---map-motor-to-axis for the $_ma parameter. It appears that most all the parameters have unique URLs… This might create a significant maintenance-of-documentation chore, but seems would be a great assist to new machine builders
Hah, I was just reading JohnL’s post over on Groups https://groups.google.com/forum/#!topic/chilipeppr/iwfJuk6fkVwI had not seen yet the GCode documentation pop up in action. That is neat and might be a technique to use in configtinyG.