Hi all,
As many of you know the OpenFlexure Microscope uses OpenSCAD as our CAD package. Due to the complexity of the microscope main stage, and the many iterations we have preferred code-based CAD as a way to continually collaborate on the design.
OpenSCAD however is not a general purpose language. It suffers from a lack of language tools for unit testing, linting (I did write a SCAD linter), package managment. The language is also pretty quirky, making it very hard to do advanced calculations or add new features. The final problem with OpenSCAD is that it produces a lot of broken meshes while being very slow.
I have often toyed with writing a Python-based CAD packaged but realised in general that this just adds to the noise of there being lots of code-CAD packages:
So despite this. Last month I started to write a code-CAD package called EngScript.
Why did you do this!?
The short answer is because CadQuery is an awesome long-term project to bring full boundary representation CAD to python. But with that complexity it is not going to have all the features OpenFlexure needs in the short term. Also because a new mesh based CAD kernel called manifold is really powerful and has python bindings.
See also long answer copied from the GitLab README
This is a fair question. The open source code-CAD space is very crowded, and there is arguably very little to gain from creating another similar tool. This tool is experimental and is based on extensive experience building complex hardware in OpenSCAD.
We created the OpenFlexure Microscope in OpenSCAD (repo). OpenSCAD allowed us to build a very compact, complex, precision translation stage for 3D printing a microscope body. We also have written a lot of custom assembly scripts allowing us to automatically generate the images for our assembly instructions in OpenSCAD:
While OpenSCAD has taken us a long way we still have issues with:
- A lack of language specific tools such linters (we wrote our own SCAD linter), unit test frameworks, package managers, etc.
- Difficulty handling data for a large complex project
- Speed issues
- Faulty meshs
As OpenSCAD moves to the manifold kernel the mesh quality and speed will improve. But a project the size and complexity of OpenFlexure really feels that it needs advanced language features and tools that OpenSCAD. For this it makes sense to look for an alternative in an established general purpose language.
Other options include:
- CadQuery - CadQuery is a really ambitious project, bringing full B-rep modelling (and STEP file compatibility) to the open source code CAD world. Moving away from meshes would open up opportunities outside 3D printing. For OpenFlexure the microscope is designed entirely around 3D printing, and relies heavily on operations not supported in the underlying OCC kernel. Porting to CadQuery would be a huge task, and would require a lot of work on CADQuery to reproduce our renders (This work is ongoing in CadQuery and is very exciting).
- Python OpenSCAD - Another cool project which brings Python to OpenSCAD. However, as the python runs within OpenSCAD this ties the project still to many of the pitfalls of the OpenSCAD internals. I also worry that this approach makes it hard to run python virtual environments so that different projects can have different libraries installed, and so that packages can be handled with a package manager.
- Web-based CAD such as ManifoldCAD - The web provides easy options for getting started, nothing to install, just start coding. However, I think that as a project becomes more complex and has multiple files and even external packages this simplicity goes away. Either you need a fully hosted solution with storage, multiple files, and package management; or you need to run things locally, hosting dev servers, installing packages with npm. I don’t see an easy way for this to scale.
- One of the many other PythonCADs - There are lots of other programs similar to EngScript which are Python based, using the same or different underlying kernel. While many look really cool, none I found seem to be very mature and stable. (Not that EngScript is mature or stable either).
The purpose of EngScript is to take all the lessons we learned in creating the OpenFlexure in OpenSCAD, the lessons we learned making auto-updating rendered assembly manuals, and the lessons collaborating on the code with a growing community. EngScript doesn’t offer to solve these problems yet, but it is a space for us to experiment with features that are needed for complex projects. A key focus of this will be object oriented code so that object properties can be queried during the design process. This should help mitigate some data handling issues, but should also make it easier to capture design intent.
EngScript may be a successful new code CAD program adopted by the OpenFlexure project. It may just be a place to try new things and to learn from that experience.
Can I try it?
You can! It is very new but it has fairly complete documentation.
It is designed to be somewhat OpenSCAD-like in functionality. However, geometry is held as objects. These objects are modified in-place with transformations
from engscript import engscript as es
mycube = cube([10,10,10])
mycube.translate_x(25)
This will make a cube and translate it.
Note that the translate_x functionality doesn’t return a new object, it modifies the existing one. This was done for two reasons:
- So that the order of operations is the same as the order of code (in OpenSCAD it is backwards as you have to write:
translate([0,0,25]){cube([10,10,10]);} - By not returning a copy you cannot put multiple transformations on the same line. This should encourage, clean flat readable code.
Anyway, the library is super new and v0.0.1 has just been released, so I assume there will be a lot of bugs. So don’t use this for anything important. If you use it and do find bugs please open an issue.
