CAM simulation for the Path Workbench

[chrisb]

Very impressive!

[shaise]

Thanks.

The good thing about this approach (as opposed to voxels) is that the final result can be compared directly with the original part, letting you know exactly if you have chosen a correct path sequence.
The only big issue with it is that OCC is very glitchy when it comes to boolean operation, so I had to "cheat" quite a lot to make it work without crashing or messing up the result.
Hopefully the new OCC has improvements in this field.

For those who wants to take a look in the code: https://github.com/shaise/FreeCAD_Macros
Please do not bug report yet, its really a draft version.

shai

[Kunda1]

Hi All,

I have managed to integrate some animation and control for the simulation:

https://youtu.be/iCe1zBoTb1I

shai

Awesome!

[shaise]

Testing with different tool shapes:
90 deg chamfer mill

20 deg engraver

tool1.jpg (36.23 KiB) Viewed 2112 times

20 deg engraver

90 deg chamfer mill

tool2.jpg (36.34 KiB) Viewed 2112 times

Sliptonic,

Can you post the "Path torturer" model you used in your videos?

shai

[shaise]

and a small video with 3 tool types Flat, chamfer and ball

https://youtu.be/cpPcNL0oSMg

[sliptonic]

Sliptonic,

Can you post the "Path torturer" model you used in your videos?

shai

That's looking awesome!
Here you go : https://github.com/sliptonic/PathTorture

Now that you mention the torture files, I really need to add that lipo battery case mlampert was working on.

[shaise]

Hi Sliptonic,

I will try working now on the torture part. I want to make a complicated path with several tools and path types to make sure the macro handles all.
By the way, due to OCC weak support for Booleans, in many cases the operation results with bad topology. I made some Hacks (such as changing tool radiuses by fraction of mm) to overcome some issues, but it does not work for all. So for each step, I check the validity of the result, and if the result is bad, I skip the step.
Hopefully, OCC7.2 will be better.

shai

[sliptonic]

Hi Sliptonic,

I will try working now on the torture part. I want to make a complicated path with several tools and path types to make sure the macro handles all.
By the way, due to OCC weak support for Booleans, in many cases the operation results with bad topology. I made some Hacks (such as changing tool radiuses by fraction of mm) to overcome some issues, but it does not work for all. So for each step, I check the validity of the result, and if the result is bad, I skip the step.
Hopefully, OCC7.2 will be better.

shai

A couple thoughts: In the video, your tool representation shows the ball end or v-end. I never got around to implementing this in the Tool Controller. Are you using the TC or rolling your own? If it's the second, please improve the TC and use that.

Looking down the road a bit, rather than the floating window, we should have a simulation toolbar. There should be a button to just show the final product and skip the animation sequence.

Likewise, make sure you keep in mind that FC might be running headless in a script. It may be desirable to get the final simulation shape so it can be output as a brep, webgl, or something else.

FYI: http://sliptonic.com/first-steps-toward ... n-in-path/

[shaise]

Hi Sliptonic,

1. As I would be happy if this tool will eventually be integrated into the path workbench, indeed the tool head is taken from the tool controller. And all the angles, radiuses and other parameters are taken from the tool controller. I still need to find out the meaning of each parameter so I can design other tools accordingly.

2. Instead of simulation bar, I would like to leave only one workbench button, that when pressed on will open a parameters dialog in the task window. The reason is that I want to give a lot of flexibility to the user: Select what job to perform, and which operations within. Perhaps select a different object as a stock.

3. Showing animation or not does not affect the calculation time. What you see in the video is max speed. Disabling the animation will save 1 or 2 percent not more. (unfortunately)

4. When the simulation ends, the result is left on the model tree so you can export it or do whatever. (right now the tool is left as well, but this is only temporary)



if you want to test the macro: https://github.com/shaise/FreeCAD_Macros

[sliptonic]

Hi Sliptonic,

1. As I would be happy if this tool will eventually be integrated into the path workbench, indeed the tool head is taken from the tool controller. And all the angles, radiuses and other parameters are taken from the tool controller. I still need to find out the meaning of each parameter so I can design other tools accordingly.

Right. But I'd like to see the TC's shape representation improved rather than re-implemented in your simulation code. Your CreateToolProfile() is vastly superior to what TC does now. It could move into the TC and then simulation (or anything else that needs it) could ask the TC for it's shape. Does that make sense?

2. Instead of simulation bar, I would like to leave only one workbench button, that when pressed on will open a parameters dialog in the task window. The reason is that I want to give a lot of flexibility to the user: Select what job to perform, and which operations within. Perhaps select a different object as a stock.

cool. Makes sense to me.

3. Showing animation or not does not affect the calculation time. What you see in the video is max speed. Disabling the animation will save 1 or 2 percent not more. (unfortunately)

Maybe now but who knows in the future? Short-cuts or alternate implementations might make it faster to go directly to the result. Also, we might think about the other extreme. It looks like the booleans are calculated for each Path command. What if I wanted to calculate MORE intermediate steps? This might really slow down the calculation but if I want to generate a smooth animation for a video and don't mind waiting... Well, you get the idea.

4. When the simulation ends, the result is left on the model tree so you can export it or do whatever. (right now the tool is left as well, but this is only temporary)

Fine for now. In the long run, I don't think we want to clutter up the tree with the simulation shapes but we can figure that out.