DeskProto releases free CAM software for Linux.

Are you aware that Blender has a CAM version ?

Yes, I know.
I followed blender cam from the first day, but I don't get expected results. May be it's to complicated for me? Don't know.
Til now, I get the best CAM results with CamBam.
Its more work for the user as estlcam or Deskproto, but you can workout any kind of operation from stupid stl-files.

Let's look at next sample, a more technically sample:
.

This is an adapter to mount a jaw chuck on a rotary table.
Blender export is always a mesh, so can't use DP vector operations. But 3D-operations are not the right way to mill this part. Well, best would be to turn it on a lathe, but milling could be fine anyway (and in fact, I milled my adapters on a 3-axis mill).

The part consists of 3 levels/stages. So to do it right with DP, you have to create a part for each level and create a geometry operation "contour only" - but that fails:
.

It looks at holes that are below the part boundary and sees artefacts in stl surface ...

... and the drawback of multiple parts - you can't combine operations. Not in simulation, and I guess, gcode output does not know anything about other operations.

So let's have a look at cambam:
No matter what file u use for import, cambam works with polylines. stl / meshes don't have polylines. But cambam is that charming, that it allows you to cut the model in Z-direction, which will create a bunch of polylines (on the fly).
Just select the one you like and create an operation for that line
.

continue evaluation of first model ...

I hope, that simulation for 4-axis works in next release. Actual shown toolpaths don't allow to check, whether cam does a good job.
.

Compare the picture above with the second picture from last post. On that picture, you can identify the fault of cam at first sight.

I used a big cutter (10mm) for roughing and a big ballnose cutter for finishing (8mm).
But that leaves the details hidden.
So I looked for a way to reduce milling area for a small detail cutter.
The only way I found was "custom rectangular". Isolating toolpaths of that operation looks like
.

Not what I expected.
So I very hope, that simulation will be available in next release.

Better choice for details processing would be, if parts of the surface could be selected (like in edit-mode of blender with circle selection "C". Size of selection circle can be changed by using scroll-wheel of the mouse ):
.


Imagine that you have a bigger surface with a small relief. Then you don't want to waste time on the big surface that don't contain details. Instead you like to limit processing area for small tools, that need finegrained toolpaths that take long runtime.

I think, that being able to select parts of the model surface would be the most efficient way for detail processing.

Hi Reinhard,

My question about the source indeed was not very clear.
What I meant was if you want me to mention your name as source of the image.
It could be "Reinhard", "Reinhard from ..." (I do not know in which country you live), "a DeskProto user from ...", perhaps with a link to your website or your own page on Facebook or Instagram.

Machining has been done very accurately, as it looks very smooth.
Do you know which type of wood was used ?

Lex.

The above post was a reply to your post of 25 Sep 2020 14:12.

Now my reaction to the CamBam comparison (your post of 25 Sep 2020 15:57):
I do not understand why you want to use more than one part: it would be a lot easier to use a number of operations in one part. You then can use the Operation area of each operation to limit the Zmin and Zmax for that operation. And you can create a simulation.

That CamBam can generate curves from an STL file indeed is a nice feature, on that DeskProto does not offer. Still when using the Waterline strategy it should be possible to get similar results.

I do not understand what happens at the holes below the part boundary that you mention.

Lex.

And here my reply to your post of 26 Sep 2020 13:01.

DeskProto V7.1 will include a simulation for rotation axis machining !
I cannot yet give an estimated release date, sorry (such promises in practice are impossible to keep).

Selecting a certain area to be machined indeed is a great tool. In DeskProto that is done by setting min and max limits (or for XYZ machining by seting a freeform boundary). Selecting on STL level (by "painting" triangles) would indeed be a nice addition, however not easy for us to implement I am afraid. We will away store the idea.

... mention your name as source of the image.

you could write: Reinhard from linuxcnc-forum
I live in germany and the friend, that milled the figure is german.
.

Do you know which type of wood was used ?

Sure. The wood type was my choice.
The figure is maple and the stand is walnut.
.

I do not understand why you want to use more than one part

You can't understand that, as I don't want it.
I did it that way, as I did not find a way to limit machining with using "custom rectangular".
May be I have to extend testing (but it's so time consuming ... ).
.

That CamBam can generate curves from an STL file indeed is a nice feature, on that DeskProto does not offer. Still when using the Waterline strategy it should be possible to get similar results.

Its not only nice (to have).
It saves a lot of time. I tried to achieve similar result with DP, but toolpath calculations needs hours! That's inacceptable.
Calculation of 3D-toolpath for the model from previous post took less time.
... CamBam needs few minutes for the same challenge.
When I look at my work, most of things I mill are technical things. So using a CAM should save my time and not waste it. Therefore CamBam is the one to beat.
Creating 3D-figures is fun (for me), but it makes less than 10% of my doing.

I don't have a screenshot for the next description, DP took to much time to recalculate, so I aborted calculation. I created several geometry operations to get a similar output than from CamBam.
On first operation I used waterlines with fill plane option. And I used custom rectangle with max z limited to a value below lowest stage (to get a circle right out of the rectangle).
Next operation was custom rectangle limited min Z to lower stage surface and max Z to a value below next stage. Again waterline with fill plane option.
That generated toolpath was not as expected. Each open pocket was milled as if it was a closed pocket.
Manually coded would lower the endmill to Z of that plane outside of existing material and than workout paths from outside to inside (possibly parallel to pocket contour). That strategy is faster and leads less stress to the endmill - as the chips can fly away and don't fill the closed pocket.
That open pockets are perfect candidates for trochoidal milling
.

DeskProto V7.1 will include a simulation for rotation axis machining !

Great! Thanks.
And I don't want you to promise any release date. Promising release date is unprofessional. I like the debian way: its ready, when it is ready
.

Selecting on STL level (by "painting" triangles) would indeed be a nice addition, however not easy for us to implement I am afraid. We will away store the idea.

Well, I don't know, how you paint the stl-import. The mesh consists of nodes, so you'll need to store some kind of node.
If you don't try to select triangles, but select nodes - than the triangles come into play without extra calculations. Work with what you have

cheers Reinhard

Hi Reinhard,

I will post the image of your maple wood part later today, on the DeskProto Instagram page and the DeskProto Facebook page. Thanks for sharing !

Creating 3D-figures is fun (for me), but it makes less than 10% of my doing.

DeskProto originally was created purely for (wildly curved) 3D geometries. We were late in realizing that indeed most parts to be machined are much simpler, and can be machined from a 2D drawing, at various Z-levels (2.5D machining). The current DeskProto V7 is the first version to really support this type of machining, so this still is fresh technology for us.

The part that you showed is a good example: a few 2D curves are sufficient CAD data. Vector machining in this case can be done with much lower calculation times and more efficient toolpaths. Most CAD program can export such curves as DXF file, unfortunately Blender cannot do this. CamBam as said has found a good solution by offering an option to extract curves from STL data.
Something to put on our internal wish list for future versions.

So many issues that can be added to this list, like the trochoidal milling that you mentioned. And the selection of facets and/or of nodes using a paint-like functionality.
We have to balance this with the need to keep the program simple: DeskProto should be about "CNC machining for non-machinists". And the more options, the less easy to use....

Anyway: thanks for your constructive criticism.

Lex.

Hi Lex,
.

We were late in realizing that indeed most parts to be machined are much simpler, and can be machined from a 2D drawing, at various Z-levels (2.5D machining). The current DeskProto V7 is the first version to really support this type of machining, so this still is fresh technology for us.

Being late does not mean, that you can't become better

CamBam has passed a long release cycle and this release is the first, that creates polylines on the fly. Older release created line-segments, which you had to convert into polylines. Then all segments of a curve had to be selected and combined into one polyline.
That was quite a lot of work - but compared with i.e. estlcam - you could workout any complicated figure.
Automatic solutions are a holy wish, but you can't foresee every complicated situation.
So in my opinion, cambams concept is not bad.

What I think is definitely better, is that cambam does not bind possible operations on the imported source. Instead operations are identified by their type like 3D-surface or 2D-paths. That reduces work for programmers and amount of possible user errors.

To workout stl like vector data from dxf, cambam supports smoothing of curves, which then converts mesh data into vector data. You could try to do the same. Differentiate between 3D-surface and 2D paths - the latter will save a lot of processing time.
Another possibility would be "boring" or pockets for 5-axis machines.
I read, that currently only holes with same diameter than current tool are recognized as holes.
There are lot of ways to create round holes and many holes need a traveling tool.
So recognizing holes with diameter, length and orientation will be a valuable feature.
.

DeskProto should be about "CNC machining for non-machinists". And the more options, the less easy to use....

Hm, I don't think, thats a good goal.
Estlcam already works that way - and it is pretty easy to break estlcam without way out.

There's a saying: if you make your app that easy, that fools can use it, then only fools will use it.

Many years ago, when I tried blender the first time - I thought: no, that app is not for me. Too complicated. Later some friends told me about the possibilities of blender and I thought I have to try again.
This time I decided: if I can not use blender, the way I like, I have to learn how to use blender and change my workflow. I started with tutorials, lessons, and lots of doing.
At the same time I started to learn freecad the same way.
After some weeks I got the conclusion, that freecad is crap and blender is a perfect substitute for my cad.
From that day, I used blender nearly every day and of cause became better and better.
Now - many years later, I stil believe, that my conclusion from old days is valid.

Therefore I believe, the best way to get used by serious users is by persuade with functionality. If functionality is reliable, users will learn how to use DP.

cheers Reinhard

Being late does not mean, that you can't become better

We are doing our best

What I think is definitely better, is that cambam does not bind possible operations on the imported source.

DeskProto does not impose that restriction either: in a project you can create any operation type that you need, and import any CAD data type that you need (in the normal user interface, not in the wizards). What differs is that Cambam adds some CAD functionality: it can generate vector curves from STL data.

Many years ago, when I tried blender the first time - I thought: no, that app is not for me. Too complicated.

You perfectly illustrate my point
The argument that Estlcam already offers this does not convince me, as numerous CAM programs are on the market that already offer complicated CAM.
Adding functionality is fine, and we do so all the time, however we try to keep the user interface simple. Which is not always easy...

Regards, Lex.