Maybe I should make it explicitly clear that I'm much more of a HARDware guy than an electronics or software guy, so I tend to think of things in terms of metal and motors. I can see how maybe guys who primarily think in terms of wires or boolean could misinterpret my poorly-formed illustrations.<div>
<br></div><div>The confounding thing about physical projects is that they cannot be simulated in any relevant sense of the word. Sure, if you're an expert, and you have a lot of capital invested in tools, you can generate accurate simulations for most features of a hardware project before you build it. I actually talked to the technical lead in charge of DARPA's VehicleForge project, which is specifically directly millions of dollars into the pie-in-the-sky dream of a software tool that can simulate a cyber-electro-mechanical system so accurately that it doesn't need to be prototyped...and he isn't confident that it's even possible. </div>
<div><br></div><div>So, that being my background thought process, no the LifeTrac CAD isn't available or up to date, but no that doesn't matter. When something gets so far out of the computer that it requires welding you are beyond the ability of "source files" to be anything other than helpful. The records of a machine always have to be updated with all of the little things that you ACTUALLY did when you built it. If you were to give someone the original files, the ones that haven't been updated based on reality, they would not be getting a description of what the thing actually is.</div>
<div><br></div><div>That's a huge part of why HARDware projects are lagging behind. It's not enough just to design the thing. After all of the work is done you have to go back and edit your design records to reflect what you actually ended up building. That can easily turn into an extremely unfriendly cost/benefit ratio when you need to record one change but it affects a dozen different records.</div>
<div><br></div><div>Anywho, the LifeTrac was an example of a barely-open project. So, if you have problems with it, that's probably because I picked an example with a lot of illustrative problems on purpose.</div><div>
<br></div><div>Should hardware documentation be parameterized whenever possible? Absolutely. Was OSE (at the time) rushing to try to publish a batch of instructions by Christmas? Absolutely. Was the LifeTrac documentation out of date even before it was published? Again, absolutely. Do we need some better options that most of the community can standardize on? I think the answer is absolutely. <br>
<br><div class="gmail_quote">On Tue, Mar 26, 2013 at 11:00 PM, Bryan Bishop <span dir="ltr"><<a href="mailto:kanzure@gmail.com" target="_blank">kanzure@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Mar 26, 2013 at 11:56 PM, Matt Maier <<a href="mailto:blueback09@gmail.com">blueback09@gmail.com</a>> wrote:<br>
> Releasing the source is only half the battle.<br>
<br>
</div>But... you just said you don't even have that (source files). "It<br>
wasn't even completely planned out." Do the CAD files even correspond<br>
to the actual machine? Maybe it would be better to use the prusa<br>
reprap models as an example instead, or the parameterized reprap<br>
source files. You guys have a lot of technical debt. To be fair, so<br>
does RepRap-- Sebastien has been using a very similar "put everything<br>
on the wiki" strategy, although RepRap has a huge community of other<br>
contributors, including those parameterized source files to define the<br>
3d printable parts.<br>
<br>
- Bryan<br>
<a href="http://heybryan.org/" target="_blank">http://heybryan.org/</a><br>
<a href="tel:1%20512%20203%200507" value="+15122030507">1 512 203 0507</a><br>
</blockquote></div><br></div>