This was just mentioned on the Python mailing list:
Back when I was trying to track all this sort of stuff on the Shapeoko wiki, there were more efforts in Python than one could easily count — looks like this one will stick and become a central part of OpenSCAD itself.
Note the extra
. in the file name in the error message. I think msys2 builds provide a more posix-ish environment for the whole suite of things built there, including as many
. in a file name as you want.
I see the worry about running random people’s Python code. Would it be any safer to run OpenSCAD+python in one of the isolated app formats like flatpack?
I doubt it, if it’s set up to be useful. Hard to allow general file access to read and write files (normal use) and simultaneously prevent malicious reading and writing.
But this seems like an unlikely vector compared to, oh, well, almost everything the out there!
I was able to get this to launch by copying in the needed DLLs, but while it worked for OpenSCAD code, it crashed when I tried to use Python.
Taking this to GitHub.
I started learning openScad because its like having a parametric model.
When i have to adjust a hole size in a model that has 18 holes…then freecad forgets how to update the cnc toolpath because of the topological naming problem, then I’m forced to spend so much time for what should be a simple number change.
It’s so frustrating!
But openScad can’t do cnc CAM. So i could write a python script to do sliced Z projections that i can import into my own CAM tool i wrote: i can click on the svg shapes and click “pocket” or “profile” etc.
I can finish my cam in 5 mouse clicks!
Having python on openScad will complete the work flow!
This is why I’ve been working on:
but it unfortunately requires an OpenSCAD alternative, RapCAD.
Agree that Python support, and being able to call Python from w/in OpenSCAD will go a long way to addressing this sort of thing.
I guess some people generate a solid from OpenSCAD and then use a different program for CAM. Seems like a PITA.
For what it’s worth, there are techniques for eliminating the topology problems. They’re also a PITA but less than broken models.
I’m one of the odd ones who prefers to pick my design tool and pick my slicer(tool path generator)/CAM tool. The designs are often fluid and is something often times very specific tools are used to create the model/part so they an specialize for the activity. CAM is completely different and has all the details of the machine, endmills, materials, etc. One can even argue that once the toolpaths are generated, another tool should be used to control the machine itself. This is how it’s done in machine shops or it’s how things were described to me by my brother who is a machinist.
Consumers do like it much simpler though and just working with flat things with a VCarve bit makes them happy because they can make cool signs and stuff. But then they are locked into the very simple interfaces of those setups and find it difficult to move off it. Mostly waiting for the vendor to add features. It’s a good way to get people into CNC and stuff but they miss out on all the cool stuff already available in tools designed specifically for the task(s) at hand.
If you can 10 finger type and you know just a little bit of software programming then OpenSCAD is a really fun and rewarding tool for making 3D designs. The fact that we’re talking about consumer access to CNC machines(milling, laser, 3DP, etc) is because OpenSCAD existed. RepRep machines were built using OpenSCAD and they are the reason we can be here talking about this.
MeshCAM works well with STLs exported from OpenSCAD.
Another option in this space for 3D printing is FullControlGcode:
In the machine shop where I work we used Solidworks for CAD and Mastercam for CAM but then both companies got too greedy and the recurring costs for seat licenses and the nickel and diming for every dang feature just killed us.
So, now we’re using Fusion360 for both CAD and CAM.
I’m personally interested to see how Onshape evolves. They bought a CAM company so soon they’ll offer both CAD and CAM. It’s SaaS, though, which makes me cautious. Apparently it’s built from the start for teamwork which could be good.
Teamwork on FreeCAD and OpenSCAD isn’t great, even using a versioning tool like git.
I think you might have left one junk yard for another. Autodesk has moved most of F360 into their cloud and worst, they corrupt the files at every little update so you can only share or work together if everyone is literally at the latest update. Same software rental business and they’ve already shown they are looking at features to leverage customers interest and pocket. I know this because I was able to get some training on F360 during the Pandemic and in 6 months I learned of their file incompatibilities at minor version changes. Within a year Autodesk announce they were pulling features from the free/student/educator version including CAM, Simulation and STL export.
So I left and found it easy to move to the 0.19 beta of FreeCAD which released just months later.
There were lots of others jumping off F360 and many many complaints and eventually they decided against some of the things they’d announced. But they messed up Eagle CAD so their history is well known. Just saying, seems you jumped into another frying pan which might not feel hot now but it’s a gimme that it’ll get hot at some point in the future.
For an interesting CAM tool have you seen Kiri Moto? https://grid.space
In my shop I use foss as much as possible but the support for multi-axis CAM on Haas and Okuma machines just isn’t there in FreeCAD and at work they’re not interested in hiring developers.
But yeah, I have no love for Autodesk. Or Haas and the rest of the subscription-charging machine vendors, for that matter. We have to pay for them to flip software switches so that our machines aren’t locked out of features that the hardware already supports.
I’m ramping up to build a LinixCNC mill for my shop.
Check out the Remora project for this, it opens lots of doors.
I have a Mesa card that seems like it will do the trick.
yes, if you already have the Mesa cards needed you should be good to go.
This is why I’ve been working on a tool which directly creates the solid using G-code, and which also writes out that G-code.
It allows programming using loops and variables in OpenSCAD — while it’s quite limited in some ways, it’s way more comfortable than using raw G-code.
I’d like a nice domain specific language (DSL) for generating gcode but each controller’s interpretation of gcode is quirky so I expect writing each generator will be most of the work, especially once it gets into canned cycles, probing, and variables.
In this case, I’m taking the same approach as CAM does — writing out everything as discrete commands, and all the complexity is at the front-end.
If the basic G-code which Grbl (and Carbide Motion) uses doesn’t serve, it would be pretty straight-forward to work up a post-processor-like system which would allow adapting the output to a specific G-code dialect.