Mechanical designs

We had a bit of a debate a while ago prompted by Simon's pointing out that svn wasn't ideally set up to deal with large binaries like STL files.

Apologies to whoever thought of the idea that I'm about (absentmindedly) to echo back as my own:

I'm thinking of removing STLs from the distribution altogether: the svn structure that we have set up (host, electronics, mechanics, and firmware) seems nice and easy to follow and to keep tidy. I propose to remove the few STL files already in the mechanics section, to read all the Darwin ones that have been so kindly tidied up by Eric and Bart into AoI and save them as AoI files, all under mechanics in a sensible tree. AoI can export any of them as STL, and they'll all be editable. True, the ones from SolidEdge won't contain their construction geometry, but people can start retro-engineering that back in, especially if we need to change something.

So we just have AoI files as the complete record of the mechanical design.

What do people think?

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Personally, I've got no troubles with this. The STL's do tend to get a mite big. What you are purposing is going to mean, though, is that anybody wanting to print out, say, a set of Darwin parts is going to have to install and learn the basics of AoI. Are you sure you want to put that hurdle up there? That hurdle hasn't previously up there and there are already quite a number of hurdles to people wanting to get into making a RepRap already as we have seen to date.

I was speaking with on guy who posts on the forums a few days ago and discovered that he uses AutoCAD inventor which apparently can't even use STL's, much less .aoi files. He is battling trying to figure out how he is going to be able to leverage his AutoCad Inventor experience, which I gather is rather extensive, on RepRap.

Would it not be reasonable to zip up all the STL's for, say, Darwin and put them in a non-SVN folder on the RepRap website where people needing them in that format only can get them. If this is too difficult for the RepRap website because of how it is being configured I will be glad to make space on the Tommelise website for this sort of thing and people can get them off of some page on the website by simply linking over to the Tommelise website. You can even go directly to the download file so that you don't have to plough through my website to get what you need.

If we are going over to .aoi, however, I do have one request. We might want to have one location which just has the booleans for the Darwin pieces and another or even a zipped file containing the booleans and all the rods and blocks and the like that it took to generate those booleans. I notice that Adrian or Ed or whoever set up the Mk II parts kit that way. It is very handy to have the .aoi set up that way of you want to actually edit, as opposed to print out, a particular part for local conditions.

Edited 2 time(s). Last edit at 06/02/2007 01:07PM by Forrest Higgs.

i agree that we should take out the STL files from subversion. forrest brings up a good point, but one that is rather redundant considering that we are already offering the raw STL files as a 'release' up on sourceforge.

i think this is the way we should do it in the future:

1. keep designs as AoI in subversion.
2. release a .zip of STL files on sourceforge for normal users
3. when someone checks in a new .aoi file into svn, they need to either update the release file themselves, or ping me to do it.

using AoI shouldnt be a prerequisite for running a RepRap machine. i think this offers a 'best of both worlds' solution. you can consider the AoI files to be the 'source' of an object, and the STL file to be the binary compilation of that object. should we also ever switch the output filetype, it would be very easy to update the releases.

Sounds fine to me, though I'd think someone (ideally someone other than the committer of the new or revised .aoi file) should actually load it into AoI, export it as a .stl, and then RP the revised part from that (at worst, virtually RP it using null cartesian, in the absence of working test hardware), and make *some* degree of effort to check that it really can be used to build a Darwin, before the new .aoi gets "released" on SF for use by non-developers? Just as a minimal check that what is released for non-developer use is actually likely to be buildable.

Or are all our 3D mechanical parts designers infallible, and so 100% sure they never make mistakes?? :-)

This comes back to the overall release engineering and release process discussion, I suppose.

Please note: I'm *not* advocating formal QA, signatures on forms in quadruplicate, and hundreds of man hours of QA work to release a small change to one part. I'll continue to push strongly for the idea that there should be *some* appropriate (minimal, for right now) level of QA before releasing things, and that developers should all be clear about what that level is. I hope that is not unreasonable.

Jonathan

Each part should be documented with photographs of the finished products, an AoI file so that the part can be looked at in a 3D viewer, an STL that can be used in any of a variety of printers and an AoI file of the complete set of the volumetric primitives, in place and hidden, as Adrian and Ed have done plus the final boolean that is to be printed.

OK - so put AoI files up as I proposed, and have the STLs on Sourceforge updated as at present seems to be the consensus. For the Darwin design remember that we don't (yet) have the construction geometry, as the STLs were exported by SolidEdge. We only have the final shape. That's editable in AoI, but some edits will require a bit of reverse engineering...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Forrest wrote:
> I was speaking with on guy who posts on the forums a few days ago and discovered that he uses AutoCAD inventor, which apparently can't even use STL's, much less .aoi files. He is battling trying to figure out how he is going to be able to leverage his AutoCad Inventor experience, which I gather is rather extensive, on RepRap.
>

I have created quite a few test parts for RepRap, almost exclusively in
Autodesk Inventor. It isn't very hard to do...

However as you say, Inventor crazily doesn't have STL export
capability. What I do is export it and load it into 3D Studio and then
re-save from 3D Studio to STL. It can clean up the models a bit in the
process. Works quite nicely.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Jonathan wrote:
> Please note: I'm *not* advocating formal QA, signatures on forms in quadruplicate, and hundreds of man hours of QA work to release a small change to one part. I'll continue to push strongly for the idea that there should be *some* appropriate (minimal, for right now) level of QA before releasing things, and that developers should all be clear about what that level is. I hope that is not unreasonable.
>

Yeah, I'm kinda of the feeling that before any *major* release is done,
somebody or a group of people working physically close to each other
should build everything from scratch. In theory that's not supposed to
be too hard to do. For the externally sourced parts like rods and
springs, etc, having some spares onhand just for doing a build test
should simplify matters.

At least for the moment, with quite a lot of manual steps, it would be
too much to expect to do a full build every time for minor tweaks.

Before committing code changes to the trunk of subversion, in the future
I would really like to see a unit test suite in place. Trunk commits
should only happen if the unit tests succeed first. In the shorter
term, we could start with a fairly minimal and incomplete test suite and
start to develop it further over time.

In the longer term when the system is more completely able to replicate,
the unit tests could include an optional "fabricate a RepRap" test which
builds everything. Groovy

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

> I'm kinda of the feeling that before any *major* release is done,
> somebody or a group of people working physically close to each other
> should build everything from scratch.

That's probably what some people would call an alpha-test release?

I'd be a bit reluctant to have to spend US$400 or so in parts on a regular basis to verify that the system passes an overall functionality test -- it seems a bit of a burden on whoever is doing that testing!!

Unit tests are a good idea, but creating them for other people's code after the fact is probably a very boring slog for any programmer. It's likely to be difficult to find anyone willing to do that work as a volunteer -- but if you can prove me wrong, that would be great :-)

Maybe we could specify that any *new* classes or methods should have associated unit tests before being checked in?? Or is that going to make people unwilling to try new things and check their new code in, because they don't want to create the tests??!

Jonathan

Jonathan wrote:
> Maybe we could specify that any *new* classes or methods should have associated unit tests before being checked in?? Or is that going to make people unwilling to try new things and check their new code in, because they don't want to create the tests??!
>

Maybe we should put some process/framework in place, but don't force
people to create unit tests unless they feel so inclined. It would be
better than nothing, and people that aren't familiar with the practice
may pick up some habits from people that are creating the tests. The
advantages are pretty significant...

I actually made a small start on doing it a while ago in some branch,
but didn't get very far and now it's probably hopelessly diverged and it
may be easier to start again. I can't even remember which unit testing
framework it was now, but it plugged in to Eclipse (or ant) quite nicely.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Simon McAuliffe wrote:

> Maybe we should put some process/framework in place, but don't force
> people to create unit tests unless they feel so inclined. It would be
> better than nothing, and people that aren't familiar with the practice
> may pick up some habits from people that are creating the tests. The
> advantages are pretty significant...
>
> I actually made a small start on doing it a while ago in some branch,
> but didn't get very far and now it's probably hopelessly diverged and it
> may be easier to start again. I can't even remember which unit testing
> framework it was now, but it plugged in to Eclipse (or ant) quite nicely.

I think we're in a very different environment now than we will be after
release.

Now informal testing seems OK, and if things go a bit wonky then we can
always revert in SVN and ask the person who make the cock-up to correct it.

After release, we've obviously got to do some thorough testing of each
published upgrade, and - of course - we ought to plan for that now.

Another thought is that this is an area where having someone not too
familiar with the project, but with a high level of expertise, might be
an actual advantage.

I think that we should treat hardware and software the same (or as
similar as possible) from the perspective of design, file organization,
versions and the rest.

But clearly hardware tests that involve making some test parts (that are
mostly air) for measuring would be a whole lot easier than a requirement
for someone to build a significant chunk of a machine at each release.

--

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]