Visit the forum instructions to learn how to post to the forum, enable email notifications, subscribe to a category to receive emails when there are new discussions (like a mailing list), bookmark discussions and to see other tips to get the most out of our forum!

It is useable, it's just still in development. Also, it's not an entire toolchain. To really meet the OSE requirement (such as it is), we need a project management system, attached to a CAD system, attached to a CAE system, attached to a CAM system, attached to a CNC control system. Also, they all should be at least moderately compatible with their commercial equivalents so they could stand on their own outside of the OSE toolchain.

Also, FreeCAD needs a better interface, or at least better documentation. I still can't figure out how to draw a profile properly...let alone anything else it's supposed to be capable of.

I think script-based 3D will be more useful to us than model-based 3D. For example, OpenSCAD is being used a lot by the 3D printing crowd on thingiverse.com because not only can they exchange STL files, they can exchange the SCAD files themselves. That means someone can write a script that generates the specific gear they need, but instead of posting just the gear file, which will be useless to most everyone else, they can post the SCAD file and people can tweak the settings to make the gear they need without having to write the script from scratch. Script-based also allows people to build in dimension agnosticism. Since the final object is defined by independent and dependent variables, rather than by discrete points, all it takes is a single variable flip to change between imperial and metric (assuming they build that into the script). Additionally, it's important for the files to be watertight so that the CAM/CNC machines don't get confused. Constructive solid geometry, like OpenSCAD uses, ensures that. Other approaches can sometimes leave the model looking good to the human eye, but full of reversed normals and overlapping points and whatnot.

Thanks Matt, that's exactly the answer I was looking for. I asked this question because I'm working on a project management system and would like to tightly integrate with the CAD system. I'm a Python programmer so the Python API in FreeCAD appealed to me (especially for things like generating icons to use in the project manager and different static views, allowing users to comment on specific parts of the model, etc). The down side of course is versioning.

What you describe sounds much more palatable to me, using script-based solves the problem of version control and generally opens an entire slew of new tools from the programming/text editing world to become available for CAD design.

@Eukreign - Yes!!! Please do this, shoot me your e-mail in a PM and I'll send you a document that has some of my thoughts on that. Also you should e-mail the main guy at FreeCAD Juergen Riegel, he's a really nice guy and could likely help you work on your integration with FreeCAD as with time it will become quite good I'm sure.

I think managing the inputs of multiple users, potentially at the same time, will require a sort of turn-based approach. Like, the file will branch when peopel work on it and then can be "compiled" into a single, synced, file.

It seems like there should be sort of "views" you can switch between. Like one would be the text interface for the script, and another would be 2D views, and another would be 3D views. Maybe another one could be a "time" view where the parts start to move.

In terms of integrating the whole process right from the beginning, I think a script-based approach is best. So, each individual part would be modeled with instructions, like draw a box, then extrude the box, then draw a cylinder and subtract it from the box. That kind of thing. The individual parts would be assembled into a machine in the same way, like start with part#1 at this location in this orientation, then attach part#2 at this spot in this orientation. When the design of the machine is finished, it could be imported into new processes. Like, one of them would take each of the individual parts and come up with fabrication steps (additive, subtractive, etc) while another process would attempt to disassemble and reassemble all the individual parts to 1) see if anything is trapped in a place that can't be accessed and 2) create assembly instructions.

It would also be important to allow people to contribute different levels of detail. Like, some people figure out how to specify types of welds and grades of steel and whatnot, but most people can't. Some people can do complicated modeling, but most people can't. So there needs to be a way for some random guy to, like, define the overall spaces. The frame is this size, the cab is this size, the engine is this size, the wheels mount to the frame at this location, etc. Then he could plug in some preexisting models, like a power cube and some hydraulic motors. Then, because he can't do detailed modeling, he can just define a "hose" with beginning and ending points (the connections on the power cube and motor). Later, someone else can come through and add detail to the "hose" part like a properly modeled set of connectors and a long curving cylinder to represent the physical hose itself. Later, someone else can come through and specify what type of hose it has to be to handle the pressure/volume.

As for the project management process, I don't think OSE has any official process. It does seem like flexible prototyping is a core competency, so agile approaches make the most sense.

Are you planning on branching FreeCAD, or are you going to just contribute to FreeCAD, or are you going to take a different approach?

It seems like FreeCAD's "scripting", such as it is, really is nothing more than telling the program what you would have done if you'd been using the mouse. Just modeling a simple object requires a huge text file because instead of saying "draw a cube of this size at these coordinates in this orientation" you have to say "turn the program on, now move the mouse to this place, now click, now make another point, now finish the profile, now extrude it into a square..." that kind of thing.

If you haven't used OpenSCAD yet give it a look. It's got a remarkably short learning curve.

I figure the scripting really needs to be a process definition, like OpenSCAD, rather than an interface definition, like FreeCAD. But I might not be defining things correctly; I don't understand the code well enough to describe what's really going on.

Both is needed, IMO. Personally, I like FreeCAD because parametric modeling is easy. I quickly learned how to create basic shapes, move them around, rotate, scale them, etc. Subtractive and additive modeling also came easy. Admittedly, extrusion was more difficult. The Python scripting in FreeCAD opens up the full capabilities of the underlying engine, which is huge - far more than can be expressed in a UI. I have created a short set of examples a tutorial on how to use FreeCAD at http://opensourceecology.org/wiki/FreeCAD.

That said, I'll have a look at OpenSCAD as well. Matt's earlier summary of the development chain is accurate. The biggest lack on FreeCAD is the inability to produce CAM or tool path files. This is why OSE is using AutoCAD and other professional design tools.

It seems to make a lot of sense to just integrate tightly with FreeCAD and take advantage of the upcoming Assembly and constraints functionality. For example the Quick Connect Wheels would be a project with one part and specified attachment points (constraints). The LifeTrac will be an Assembly project which will have the LifeTrac frame and also reference the Quick Connect Wheel part, because of constraints we'll be able to actually correctly position the parts where they are supposed to go so that if you redesign the LifeTrac the Quick Connect Wheels will still show up in the correct place.

OpenSCAD will likely never have this functionality and using OpenSCAD models with FreeCAD models will always be a pain point.

FreeCAD can generate STL so there is no reason that it couldn't be used to produce CAM. A few people on #freecad have stated they use FreeCAD for making things to be 3d printed, etc.

And you can always do scripting with FreeCAD using Python.

If someone doesn't know programming and they learn OpenSCAD script their knowledge is limited but if they learn Python they can use it to model in FreeCAD and also contribute to the tool chain :-)

OpenSCAD was just an example of the process I was suggesting. That's why I contrasted it against FreeCAD's script-based modeling which takes a couple dozen lines to create the same result that OpenSCAD produces with one.

Can a higher level set of syntax be laid over the Python that FreeCAD uses? Like, instead of having to script where the mouse goes and what it clicks on, could the user just write "draw a cube."

Also, I can't see any reason why FreeCAD shouldn't be able to import STLs. It should be on the list to implement if it isn't already. That's a different subject, tho.

Sure...IF someone learns the special programming language the program is written in they will be much more useful. That's great, as long as we have so much professional input we can afford to dismiss all non-professionals. I don't think OSE is that successful yet. In a more abstract sense, very few people can produce good work in both mechanical, electrical and computer engineering. Usually you're doing quite well if you can manage one, let alone two, and they're usually the two that are adjacent, like ME&EE or EE&CS. So, since we're going to be dependent on mechanical engineers for the machine designs, it seems strange to ask them to learn how to program in a very specific language. Python's not as bad as many languages, but it's hardly intuitive. OpenSCAD's syntax is so simple it doesn't even merit being called a language. You just tell the computer to draw a cube.

FreeCAD seems like the sensible first choice of 3D modeling application. But that's almost entirely because it's open source and has developers. It's still pretty rough even when it isn't actively interfering with your ability to learn how to use it. The interface sucks, is what I'm saying. That's par for the course in open source software. It doesn't bother the developers because they already know exactly how to get it to do what they programmed it to do. As long as the developers are the only ones who are ever going to use it that's not a problem.

OpenSCAD is an example of a 3D modeling program that dramatically reduced the barriers to entry. Power user options are great, but you shouldn't have to be a power user just to draw a cube. The simplest functions in the program need to be accessible and intuitive so that anyone can pick it up and start doing SOMETHING with it right away.

It's not just a matter of non-engineers trying to contribute to the designs. If you're asking the engineers themselves to learn an entirely different modeling program only the most committed are going to put in the effort. A bunch of people with good ideas are going to simply balk at the learning curve required to contribute.

My opinion is that we'll get more bang-for-our-buck by focusing on making FreeCAD easier to use than anything else. A project management layer will be wasted because only a couple guys are going to get far enough with the program to work on a project that can be managed. There's no need to manage a project that only a couple people can work on. If people have to go outside FreeCAD to a modeling program they are familiar with, then they won't be able to participate in the project management built into FreeCAD.

Basically, a stand alone PM program would be useful to people right now. Improvements to FreeCAD's interface would be useful to people right now. A PM layer in FreeCAD wouldn't be useful right now to anyone that I'm aware of.

A simplified FreeCAD API can be created with Python to emulate OpenSCAD language. I don't think this is an issue.

FreeCAD can import STLs but then what? STL is such a limited format. You're basically importing dumb solids with no meta data, it doesn't even support giving colors to faces much less constraints for anchor points or anything else. For example if you did a part in OpenSCAD and then tried to incorporate it into a larger FreeCAD Assembly there is not enough information in the STL file to do that.

DXF files are supported natively by FreeCAD (via opencascade) so no reason you couldn't use familiar tools to do part of the work, you just wouldn't get the nice integration with the PM system. I don't know how Assemblies would work though as far as editing parts in AutoCAD and then incorporating them back into FreeCAD Document and keeping the Assembly constraints for how all parts fit together...

We definitely can and should starting using existing project management tools. Scrumy is dead simple to use, don't even need to register for an account: http://scrumy.com

By starting to use Agile/SCRUM process now we'll all start to see what's missing or what we need in our own implementation of the collaborative engineering suite.

Regarding the ease of use of FreeCAD, I found it to be quite simple to do basic things that can be combined to make some fairly sophisticated drawings. For example,

I've used it to do cut away views, too. The problem that I see with FreeCAD is that beyond simple things, the interface is difficult. Extrusion and lathing, for example, is unintuitive at best, though it is possible. General modeling is fairly simple, but what you can do with it seems limited. Support for object materials (color, texture, patterns, etc) and better rendering would be very nice. I'd use it more if it did.

I should also note that, while I am a professional programmer, I've never had to resort to using Python to create anything in FreeCAD.

I've been playing around with FreeCAD and atfer a couple of tutorials, I think it's a good option. Of course, if we are going to compare it to solidworks, inventor or catia it's still a little back in developing...

What if we contact the developers to have some technical support? They could also have our feedback..