Lots of good posts to mull over. I especially appreciate the comments from people who have already made the decision with either a good or not-so-good result.
The posts on a cheap cnc/laser engraver confirm what I suspected - not all that helpful for the direction I want to go.
While I knew I would need CAM software, I haven't looked at that area as closely as I should have. I would prefer software that works well with OnShape (my 3D CAD preference). Kiri:Moto can integrate with OnShape, and since it is cloud based it works on my Linux box. Kiri:Moto seems to be actively supported and improving, but I get the feeling that it has some significant limitations at this time - but I don't know enough about CAM in general to say for sure if that is the case. OnShape has announced that they have acquired CloudMilling CAM and that it will be implemented in 2023; however, I suspect that this will end up being available to paid users only, so it's not something I am counting on. I can export STL files from OnShape, so I assume that Linux CNC is an option similar to the way I export/import into PrusaSlicer.
So - in 25 words or less - tell me everything I should look for in a CAM package!
25 words or less? I'll try:
Works with your OS and motion controller. Handles STL and DXF at a minimum. Simple tool tables. Can do 2D 2.5D and 3D toolpaths.
24 words, but at least a start.
Here's a bit more, as always
Your controller software will not take in any drawing format, it only understands G Code, and in a flavor of G Code it speaks. Your CAM package ingests the drawing and generates the G Code. CAM for machining is the functional equivalent of the slicer in 3D printing. The motion control software, be it Mach, UCCNC, gRbl, linuxcnc, whatever is the equivalent to the embedded firmware in a 3D printer, or perhaps being more involved, it quite similar to klipper running on a pi along with the firmware in the printer control board.
Lacking specific support for your motion controller (rare), most CAM packages with have a post processor that generates .TAP format gcode, usually it's about as generic as things get. The base FANUC post processor is usually really vanilla too. Sometimes you can select a generic post processor that specifies arcs and curves, if so use it, otherwise curves are cut as series of short straight lines from point to point, resulting in slow machining, lots of stops and starts, and faceted curves. Odds are you won't have to worry about this, but it's nice to know there is some low level commonality. Unless you have an original EMCO CNC machine... Don't sweat this much though, just about everyone speaks Mach 3/4, LinuxCNC, and gRbl along with all the spiffy machines. The differences usually show up in things like advanced optional parameters for thread milling, dynamic work offsets, that sort of stuff. The basic G Code world is pretty well standard, at least as much as any technical stuff is "standard".
Meshcam, VCarve, and Cambam all import STL files. It's worth noting though that the process can be a lot more streamlined if you can save your CAD files in a vector format such as DXF rather than in an approximated tessellation form such as STL. Naturally if you are going to do true 3D machining, a 3D model is the way to go, but for many of the things done on a CNC mill, it's pockets and profiles for the most part. I just tried the current version of CamBam with wine, no luck. It looks like they use the .NET4 framework and some other stuff, no messages, just a loading cursor then nothing happens. As a side note, Meshcam expects 3D input, when pulling in a DXF you have to fake up a component thickness via an extrude operation before you can generate gcode. Flip side is that using a 3D format for your CAM input can save you having to enter all the pocket and hole depths, they are within the CAD file already.
Mach and linuxcnc both have demo modes where you can "run" your G Code in a simulation mode without even having a machine defined. This would let you sort out your process and get some experience with different software option before you have a machine up and running. There are free g code simulators of various quality all over the place, a quick search on gcode simulators will get you started.
Quickie suggested plan of attack:
1) Draw something simple in the CAD of your choice, which I believe is OnShape. Save as an STL and optionally as a DXF if supported. Make the object really simple, like a strike plate for a dead bolt. Two rectangles, four or eight fillets, two screw holes. Boring and trivial. There's enough weirdness coming up, don't add to it for the first time out.
2) Import the drawing into whatever CAM package(s) seem of interest, and learn to generate tool paths. You'll need to specify tools, and depending on the package all sorts of machine and cutter data (RPM, ramping rates, step over, all that stuff). Doesn't matter what CAM package, or if it's cloud or local, just play with the stuff and see what works for you. If your CAM package will do a simulation run have a look and see how things are playing out, otherwise onwards to simulators or controllers doing backplots.
You already speak slicer, KiriMoto is set up like what you already know from a quick look, so give it a shot. I did plop a small STL into KiriMoto and generated some gcode for linuxcnc and gRbl, although it appears to do line segments rather than arcs, so the file is silly big. Maybe a config setting, I just had a quick look. I did notice that KiriMoto does not take dxf files, sort of a big miss for a CAM package. Perhaps their engine is so tied to a slicer code base that 2.5D just isn't in the cards. Feels sort of weird to me, a subtractive CAM package that doesn't require workpiece dimensions, origins, other "normal" stuff before spitting out GCode, but maybe it's OK, just different. It does support roughing and contour passes, which is great, but in simulation it doesn't seem to honor the tool length settings, so the tool just dives under the surface and pops back up elsewhere. Not something any of my mills can pull off.
3) Plop the output of your CAM package into a gcode simulator. Try a few, some are pretty good, some suck, some are really good but look lousy, simulation is all over the place. Optionally, pull the gcode into motion control software running in a demo mode and simulate there. Camotics seems to be a pretty good open source simulator, with .deb and .rpm packages available. It does have some dependencies that if unmet may require manual installation, but the camotics page documents these. Some simulators are embedded within gcode editors too, so you might find interesting things using the search term "CNC backplot".
Always use the time option in searching for help. In the case of linuxcnc there are millions of posts and pages dating back probably 20 years. Most of it is only of historical interest if that, much of the old tech advice is completely outdated and in many cases now wrong.
Most stuff won't work or make sense at first, at least it didn't for me. Plod along one step at a time and it will all fall into place after an Aha moment or two.