Pretty sure one could even get the 3D printer firmware running on OpenBSD. A popular choice these days is Klipper (https://github.com/Klipper3d/klipper) , which would most likely compile just fine.
I don't see the point, all this software is meant to run on *nix. Also OpenSCAD sucks. I tried it, made a few things, it's objectively a worse way to do parametric modeling and lacks some really basic features like fillets.
FreeCAD has been p great OTOH, and has baked in support for OpenSCAD scripts, if you really need that.
If you are not allergic to the cloud or proprietary solutions, Onshape is a very good tool with it's own set of annoying things.
Last time I checked (~3 years ago) FreeCAD was riddled with bugs. You make the slightest change to a constraint, everything that depends on it breaks. Degrees of freedom are calculated incorrectly. Multiple times I saved and reopened a file only to see my work get completely destroyed, with all my constraints throwing errors, and a quick search confirms I’m not alone with that problem. [0]
OpenSCAD might not have all the bells and whistles you’d expect from a WYSIWYG editor, but at least it doesn’t fubar hours of your work. As usual, formats you can edit with a text editor are the most robust. It is definitely not an “objectively worse way to do parametric modeling”.
In OpenSCAD, you primarily model by creating shapes and combining them with boolean operations. You can use this same workflow in FreeCAD without using the sometimes-fragile PartDesign workbench - that's what the Part workbench is. You could, if you were so inclined, even do it in text using Python. This approach doesn't usually explode on you.
However, the PartDesign workbench is substantially more capable and more comparable to other CAD programs, and a substantial portion of the dev work on FreeCAD has been targeted at making it less fragile. You can also avoid most breakages in PartDesign by following best practices that can be found on YouTube or the FreeCAD wiki.
A continuing issue is constraint-related issues which you mentioned. I've never seen a file explode after save and load - if that happened, it's likely it was already broken before save and FreeCAD failed to inform you, which I have definitely seen. What I have seen is a similar problem where a sketch is valid, but there are one or more alternative valid configuration under the same constraints. Everything is fine and the file is usable as long until you try to adjust certain parameters driving a sketch and the sketch flips into a totally different configuration. Even after reverting to old parameters, the sketch will be now be stuck in this new configuration and everything built on it will be broke. This is usually avoidable, but it requires seriously thinking about how you're constraining your sketch to avoid this kind of fragility.
It's also important to know that you can combine workbenches. A solid created in the Part workbench can be imported into the PartDesign workbench as a base feature. A PartDesign solid can be used in Part boolean operations.
This is all to say that while FreeCAD definitely has a much steeper learning curve than OpenSCAD, it can generally do the same things as OpenSCAD without any Sketch/PartDesign-related fragility while having many additional capabilities available if you need them.
Sure, functionally OpenSCAD is just a subset of FreeCAD. The problem is, I can't really trust them if they also push out less robust or outright unreliable features alongside them.
> Even after reverting to old parameters, the sketch will be now be stuck in this new configuration
I have definitely experienced that too. Constraint-based design is very powerful, when it works. But it doesn't always work. A boolean operation always has a result (at least in theory), but a set of constraints doesn't always have exactly one solution, or any solution at all. Which would be okay if the program could reliably tell when something is well-constrained, so that changing a parameter doesn't make it jump to a different solution - one that isn't even on the face I'm trying to make a hole into - which causes the hole and the faces created by the hole to cease existing - along with the sketch I drew on one of those faces that now doesn't exist and so neither does my sketch... It all collapses so easily. How to keep track of faces that jump in and out of existence as the parameters defining them change would probably be a good PhD thesis topic.
> Sure, functionally OpenSCAD is just a subset of FreeCAD. The problem is, I can't really trust them if they also push out less robust or outright unreliable features alongside them.
I feel like I perhaps needed to further emphasize the separation between Workbenches. FreeCAD workbenches can interoperate, to a degree, and the output from one can be used in another. Moving through Workbenches is a part of advanced FreeCAD use. However, they are separate and largely self-contained tools. Different Workbenches operate in different manners not just in regards to the interface but also in regards to their underlying function.
The Sketcher Workbench is where the constraints system is, and mainly exists to support the PartDesign Workbench. The Part Workbench is a decent CSG modeling system that works mostly like OpenSCAD or any other boolean operation based modeling system. It is not reliant on the Sketcher Workbench constraints system. You could use a Sketcher Workbench created Sketch to create a Part solid, but you can also use the output of the Draft Workbench (which could even be based on an imported SVG). It also has primitives, so you can model from primitives.
FreeCAD is intended to be modular. It has a ton of Workbenches and there are more available as addons. How things work in one Workbench is not how things work in other Workbenches, and shortcomings in one should not be projected onto others. If you find OpenSCAD useful, I seriously suggest giving FreeCAD's Part workbench a try. I found that the same sort of modeling I did in OpenSCAD was often easier in FreeCAD and it has fillets to boot. I now use the PartDesign workbench more than I do the Part workbench, but I have a nice cosplay prop I drew in Inkscape and then modeled in the Part Workbench after giving up on doing the same thing in OpenSCAD.
I also feel that it is a bit unfair to say you can't trust them. The PartDesign workbench is the most popular, most complex, and most fragile workbench, but I've never seen it take a step back - every stable update has improved its function and reliability. What's more, unlike many open source projects the 'new shiny' (in this case Part Design) has not been forced on people who are using other parts of the project. It's not intended to replace the rest of FreeCAD, but specifically aimed at people looking to model complex solids in a manner comparable to commercial CAD programs, even if the workflow is very different.
edit: The only universal problem in FreeCAD is the topological naming problem, and it almost never comes up outside of PartDesign because outside of PartDesign features are rarely reliant on referencing individual components of a shape by name. CSG modeling isn't really subject to the topological naming problem.
If you want to avoid the topological naming problem(something that can be avoided with a 10-20 minute youtube video on the topic), try RealThunder's fork.
Honestly I’ve been using blender to make precision parts to be 3d printed for years now, and while it doesn’t have all of the shortcuts of something like onshape, with a digital caliper and proper scale settings you can make basically anything you want. It also has a new plug-in called cad sketcher: https://www.cadsketcher.com/ for filling in some of those gaps.
openSCAD doesn't suck, it's just an entirely different paradigm than something like FreeCAD or onshape.
as for your complaint about fillets, there are plenty of openSCAD libraries to assist in the task. using libraries within openscad is pretty routine.
if you're designing stuff like gears/propellers/bolts/nuts/threads/pins, a purely parametric solution is fantastic. That said, I would never tell someone to go try to design their paper-towel holder or dish-rack with it or prototype a robot with it.
As with much of design, picking the right tool for the job is a large portion of the battle.
I have to agree that openscad kinda sucks, in some regards.
Sorry but fillets and chamfers aren't features that should be complicated, they are basics.
And if using libraries is pretty routine, why does library management boil down to "just download some scripts and throw them into some directory". Even python does this better.
Openscad is a text/programming based cad, but it doesn't fully leverage the advantages that come with that. A proper package manager, good linting, etc. are all absent. It feels unfinished and outdated in many regards.
I want to like openscad and I have made a bunch of models with it. But all in all I can't bring myself to do so.
Thanks for the tip about FreeCAD. I actually love OpenSCAD and have developed a really nice workflow in VS Code using some extensions (format on save, live preview, GitHub Copilot, etc.), but I would still like to learn some other tools as well. It looks like FreeCAD can do some really advanced things.
I have no experience with it yet but I have build123d[1] in my list of stuff to check out, it's basically OpenSCAD but in python and it seems quite more powerful (plus, fillets/chamfers/etc are built-in). It also seems to have VSCode integration through OCP CAD Viewer.
It's patently bizarre that the author claims the complete stack is possible under openbsd and then says "for downloading, just sneakernet the file to the printer or use linux running on a pi" and points to a very small collection of horrendously user-unfriendly, extremely manual tools like openscad.
Would we tolerate an article that claimed OpenBSD had a complete "stack" for desktop publishing if one of the steps was "save the file on a USB stick and plug it into a windows computer connected to the laser printer" or "just connect a raspberry pi running linux to the printer"?
Would we tolerate an article that claimed OpenBSD had a complete "stack" for desktop publishing if the only option for "word processing" was emacs and latex?
Saying "Blender has been in ports for ages" is hand-wavey nonsense. Does Blender actually work in openbsd?
Has anyone completed a serious engineering project in OpenSCAD? I just can't imagine how that would work. I suppose the actual design work wouldn't be that much different, but I can't imagine a way to collaborate with it. You'd need a mechanical engineer, who is also a programmer, who is also willing to learn OpenSCAD. That is expensive.
With FreeCAD, even if you never used it before, a CAD person could figure it out. Its mostly learning which icons do what. (IB4, someone mentions the topological naming problem, that its completely avoidable with a 10 minute youtube video on the subject, or you can download the RealThunder fork of FreeCAD if that 10 minute youtube video is too time consuming)
I guess my point is: Yes its technically possible to do a lot of things on any OS, but it isnt practical.
> You'd need a mechanical engineer, who is also a programmer, who is also willing to learn OpenSCAD. That is expensive.
I disagree. I'd expect any engineer these days to have at least modest skills in programming.
And OpenSCAD is a rather modest programming, the script itself always finishes, so it's not even Turing complete. So having mechanical engineer to be comfortable with OpenSCAD looks like a quite reasonable thing.
With FreeCAD you have a lot of useful and convenient things, but you immediately lose the parametrization. Can't convert back to OpenSCAD if you'd like. So it's hard to move to FreeCAD from OpenSCAD if you got used to OpenSCAD capabilities.
Parameterisation is actually one of the things you can do with freecad. Most of my projects have a spreadsheet with the parameters in them.
You can run into annoying problems with the sketch constraint solver when changing those parameters though. Depends which parameters and what you've used them for.
If changing the parameters upsets the constraint solver, you can sometimes work around it by changing them in smaller increments (e.g. so that a "length" doesn't flip to the other side of a line).
Yes, and there are some other tricks you can do. The underlying problem is that "fully constrained", to the solver, means "cannot be continuously varied". It doesn't mean "there is only one solution". So what you get, for instance, is a point being constrained to a distance from a line that the solver will allow to be on either side of that line, at the correct distance, so if the line moves further than the distance when you update parameters, everything falls apart as the solver picks the other solution.
That specific one you can force by adding a construction line between the point and the constraint line, with an absolute angle constraint on the construction line. Because lines have direction (a hidden direction! Got to love critical functionality with no representation or control in the UI whatsoever!) the angle constraint forces the solver to pick only one of the two solutions because the other would make the angle 180 degrees out.
There are other problems that are much harder though, that I haven't yet figured out how to work with, mostly involving arcs. It's easy for the solver to flip which side of a circle a tangent constraint solves to, and because in that case there often isn't a fixed angle to work with the construction line trick doesn't work. When that happens on an arc, you end up terminating a line in free space, or wrapping the arc the other way round the circle, or something. I do wish arcs would only allow constraints between their endpoints.
What would solve a lot of these cases is a winding order constraint you could apply to a set of points - "make sure these 3 points in this selection order are always anticlockwise around their median" or something - to disambiguate solution pairs, but I dread to think what the UI for that would end up looking like.
FreeCAD is a parametric CAD program. You can create a "spreadsheet" in FreeCAD where you define your parameters and then reference these cells in formulas that drive your constraints.
Thanks, didn't know about that. Maybe then the parametrization in OpenSCAD is subjectively more conveniently implemented, I don't know. Why it's not too well known?
One difference is that sites like thingiverse allow the parametrization of OpenSCAD projects right on the site, so downloaders can customize their STL without needing to run OpenSCAD themselves. To the best of my knowledge, there is no such ability for FreeCAD.
For one of my projects, this seemed to be enough of a benefit that I redid my original FreeCAD design in OpenSCAD for eventual uploading.
I've tried to use FreeCAD myself and didn't see that feature. I guess more learning are encouraged here. Now I know to look for parametrization as well.
I have no reason to print 3d, but nice to see it working. With things like this and what I believe is all the "crazy" things going on in Linux, I think OpenBSD is a very good alternative to Linux.
For me, the next release will have something like valgrind added to OpenBSD base. IIRC you would use ktrace(1) to look for issues. valgrind is one of the very few reasons I keep Linux around.
DRM in the kernel, X slowly being replaced by Wayland. Wayland will probably prevent Linux from running on Old Systems. Corporations now own the Linux Foundation, many windows type processes slowly bleeding into Linux. Not to mention the RHEL/CentOS thing and now RHEL is restricting source distribution.
Dear lord, it really is not that simple. Having ported software and served as a package maintainer on both the Linux and BSD side you get anything from pathetically easy to nearly impossible (Julia on NixOS was one hell of a journey). Just yesterday we had a great article posted about some of the effort that goes into getting a big piece of software like Firefox to run properly on OpenBSD [1].
Right but there are firmwares or tools that push the GCode to the printer (OctoPrint) that exist and are widely used, and those aren't available there.
given also they port a really old version of prusa im not surprise. i bet 100% octoprint not make it, or new version, because they are scared to update deps for reasons. openbsd port people also no share patches upstream and probably "too hard" to port in current form with many patches.
