Add the gShield .elf and .bin files to our releases page

[justinclift]

As per #340.

[justinclift]

Assuming this builds ok, what's the right way to get this commit into master, and thus the .bin/.elf files into the Releases section?

Should I cherry pick this commit from edge to master, or would it be better to just manually add the hand built gShield .elf/.bin files to our Releases page for now?

I'm kind of thinking the 2nd one (add hand build ones to Releases page), so we don't potentially screw up our git commit history order for master, making the next merger from edge to master potentially a pain. (?)

[justinclift]

Ahhh, maybe this doesn't need to be pushed to master to get things into the Releases page.

Looking at the Releases page info, it has "306 commits to edge since this release". So, now I'm not sure which branch triggers the uploads. 😖

[giseburt]

Looking this over, the only concern I have is there's no indication as to what settings are used in the file.

I'm also not sure how useful the "default" settings are on a machine. They're primarily intended as a starting point for new settings.

We should probably go with a more useful base config such as:

make VERBOSE=1 COLOR=0 CONFIG=ShapeokoDualY BOARD=gShield

That would make the files posted g2core-ShapeokoDualY-gShield-${TRAVIS_TAG}.elf

Regarding what triggers a build: Travis will push a release when we tag, which also provides the version number. This allows us to vet the releases, particularly for edge where not every commit is guaranteed to be buildable or usable.

[giseburt]

We should use a CONFIG such as CONFIG=ShapeokoDualY - we may use more than one if needed.

[justinclift]

Good point with the settings. For my personal newbie use case (eg "get it to work at all first"), I used the default Arduino Due + "roll your own" gShield that the Getting Started guide says to begin with.

Not knowing any better at the time 😉, and not really understanding how things hang together, the default settings worked out well enough when following our Arduino Due pinout template.

That was good enough to get motors moving and prove to myself "ok, this looks like it's worth investigating further".

Am kind of thinking other people may follow along a similar path. For them, just having a firmware they could flash and immediately use would get them to the same point quicker. 😄

The ShakeokoDualY config might be a good initial choice. From memory that's what my most recent Shapeoko3 settings file was based on. I still need to get the limit switches bit set up (working on it now) with my new perf board. So, sometime today most likely I'll get it looked at and then this PR updated. 😄

[justinclift]

Reminder note to self for later today: Add something to the wiki in the getting started guide, clarifying that using the (as given there) make line will work fine, and result in a build that uses the pinout from the above Due PDF. I remember that being a pain point in not knowing "what to do next?" when going through it myself. Should probably update the wiki to point people at the prebuild .bin/.elf instead too, so they can get up and running faster.

Also add the exact commands needed (eg via CoolTerm/Minicom) to enable the motors. That also tripped me up early on.

[giseburt]

Justin I added notes to the wiki about tagging: https://github.com/synthetos/g2/wiki/Development-Process#tag-a-release

[justinclift]

Fantastic! That looks like exactly the right info. 😄

[justinclift]

Just made the requested updates.

Thinking about it while making the edit though... I'm not real sure about this change. My goal with this PR is to give new users a fairly obvious starting point to pick up from.

Those new users will fairly easily pick up something named like (say) g2core-ArduinoDue-gShield.bin, as those are the terms much of our docs already refer to.

They're unlikely to choose something with Shapeoko2DualY in the name, unless they just happen to be using a Shapeoko 2 Dual Y. Probably not a high chance of that. 😉

How about we choose something which ends up as the above g2core-ArduinoDue-gShield.bin, and adjust things so its settings are suitable to new users? Maybe a gShield specific settings file, that's pretty much empty except for (eg) enabling the X/Y/Z axes?

[justinclift]

@cmcgrath5035 Interested in your thoughts on this too. 😄

[aldenhart]

There's the rub. I dealt with this a while ago, and there is no single answer. There are two basic machines in the wild. Both are Cartesian XYZ with one motor on each of three axes (i.e. not a dual Y motor config). Variant [1] is screw driven, with X and Y at the same pitch and Z sometimes, but not always at that pitch. Variant [2] is belt-driven usually with a screw axis for Z.

I elected to make [2] the default machine, because if the travel settings for belts are applied to screws then the screw machine will barely move, but if it's the other way around the belt-driven machine will almost certainly crash. Hence a "regular old 3 motor Shapeoko" (which, but the way, don't exist anymore, really) is what I ended up with as the safest default.

[justinclift]

Sounds like a sensible starting point, and that's all we're needing for this. 😄

[cmcgrath5035]

I agree with Alden, there is no "right" single answer.
This will get a newcomer up and running, at least moving and looking at parameter sets.
Then they start tweaking and tuning
THEN they get motivated to know how to modifiy settings and rebuild their desired defaults.

[giseburt]

Perhaps we should come up with a few unnamed “typical machine” profiles and document them clearly. Based on Alden’s comment we should at least have “screw driven dual-y CNC“ and “belt driven single-Y CNC”. We need to clearly state what we expect the travel per rotation to be, etc.

[cmcgrath5035]

G2core settings has several ShapeOko Variants. Perhaps migrate settings_cnc3040.h over from tinyG as an example screw machine. I bet we could poll the Ox folks and find a consensus starting point there, recognizing that a lot of further customization will be needed. I see more Ox traffic these days. Challenge is that there are several different screw drives that are popular, sizes that are all over the place, etc. The correct settings will almost always be local and optimized. Having a good binary to work with will make it easier for newcomers to get some hands on experience.

[justinclift]

This will get a newcomer up and running, at least moving and looking at parameter sets.
Then they start tweaking and tuning
THEN they get motivated to know how to modifiy settings and rebuild their desired defaults.

k. If I'm understanding correctly, the current settings_default.h is reasonable for a machine with three axes, using belts on X and Y, and a screw driven Z.

That sounds like useful info we can strategically add to the existing Getting Started wiki page.

There's a small piece there in the Software section of that page which talks about flashing for people not wanting to compile. This seems like the right branching point to intro something along the lines of "Grab the [foo].bin file from our Releases [link] page, and flash it to your board."

We could probably add a table under that to list the .bin files on the releases page (linking to them too), with a description of each, and some text to help people select.

The existing page there has links to flashing instructions for Win/OSX/Linux on individual pages. The Windows and OSX ones both have a first step along the lines of "1. Get a .bin file". We can probably remove those bits as they'd be covered in the expanded Getting Started with g2core page instead.

[giseburt]

And off course the real solution being the ability to load and save settings. But that’s a bigger problem at the moment.

[giseburt]

settings_default is not suitable for any machine. It is literally the safe default of each and every individual setting, and using it is basically a completely unconfigured machine. All motors should be disabled, all switches have no actions and default polarity, etc. It’s not a “default machine” setting it’s a “no machine” setting. I think we should make it a compile-time error if the defaults are compiled without overrides.

[justinclift]

settings_default is not suitable for any machine.

Hmmm. We might be using different meanings for "suitable"?

I started out with the default settings (via gShield config), and that was good enough to get started on (after working out how to turn on the motors). 😉

"Optimal"? Heck no. "Suitable to a newbie to start with"? Kind of thinking yes. 😄

[justinclift]

I've just manually uploaded gShield .bin/.elf files for the new 101.03 build on our releases page.

Thinking about this issue more, I'll adjust this PR again to drop the Shapeoko2 Dual Y settings. What we want is something suitable for newbie users, that matches up with our docs so we can guide them into becoming proficient.

At the moment our docs use the default gSheild settings, so that's what the gShield .bin should use.

When we figure out the better approach to take, then we can update both at the same time.

Sound reasonable? 😄

[cmcgrath5035]

What file defines " the default gSheild settings" ? I see https://github.com/synthetos/g2/blob/edge/g2core/settings/settings_default.h , That is a weird machine, 1.25 (screw) on X, 40mm(pulley) on Y ?

[justinclift]

Yep, that's the file. We can definitely improve things, the point of this PR is to get people something to start with while they're going through the newbie docs.

As @aldenhart pointed out in depth above, there's not really any such thing as an optimal file for everyone. So we'll need to guide people how to get their settings into shape, in newbie friendly fashion.