conic core dump PR [FIXED]

[freman]

Hi,

I've been getting persistent crashes ( core dump ) when trying to use conic tool on a 3Dsurface. I was using master from a week or two back but did a new pull this morning and still get the same.

Code: Select all

Tool type: Undefined
Tool type: Engraver
FreeCAD: /svn/opencamlib/src/cutters/conecutter.cpp:46: ocl::ConeCutter::ConeCutter(double, double, double): Assertion `center_height > 0.0' failed.
Aborted (core dumped)

If restart FC and do the recovery bit, I find that the new 3D path is present but marked for recomputation. When I do that it crashes again:

Code: Select all

Reading failed from embedded file: PartShape24.bin (0 bytes, 2 bytes compressed)
Reading failed from embedded file: PartShape25.bin (0 bytes, 2 bytes compressed)                                                                                                     
Reading failed from embedded file: PartShape27.bin (0 bytes, 2 bytes compressed)                                                                                                     
Reading failed from embedded file: PartShape28.bin (0 bytes, 2 bytes compressed)                                                                                                     
Reading failed from embedded file: PartShape29.bin (0 bytes, 2 bytes compressed)                                                                                                     
Reading failed from embedded file: PartShape30.bin (0 bytes, 2 bytes compressed)                                                                                                     
Reading failed from embedded file: PartShape31.bin (0 bytes, 2 bytes compressed)                                                                                                     
FreeCAD: /svn/opencamlib/src/cutters/conecutter.cpp:46: ocl::ConeCutter::ConeCutter(double, double, double): Assertion `center_height > 0.0' failed.                                 
Aborted (core dumped)

Same thing with ball-end on 3Dsurface.

Code: Select all

Tool type: Engraver                                                                                                                                                                  
FreeCAD: /svn/opencamlib/src/cutters/ballcutter.cpp:41: ocl::BallCutter::BallCutter(double, double): Assertion `length>0.0' failed.
Aborted (core dumped)

Works with straight endmill tool type.

Use legacy tools is true.


OS: Fedora 31 (Thirty One) (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23935 (Git)
Build type: Release
Branch: master
Hash: d5b68febbb4989b290b9af36bb2cb21d61a87a2e
Python version: 3.7.9
Qt version: 5.13.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)

[sliptonic]

IIRC, we don't pass a mesh of the tool to OCL. Rather we pass the parameters required for OCL to construct its own tool in memory.

Cone cutters aren't used very frequently for surfacing. At least I've never used one for that so It's very possible that this isn't well tested either on our side or OCL. It might be that we're not passing the right values to it to construct a cone cutter.

It would surprise me if we're getting the same error on a ball cutter though. Those are obviously used all the time.

[freman]

I've just updated OP and I do get the same issue with 8mm ball-end, a TC which I successfully used with 3Dsurface last year ( though those files are broken now with master, so I can't check back ).

I'm not really using a cone shaped tool, I'm trying to work around the fact that rotating the spindle 45 deg no longer works I have a straight V trough to cut so I'm trying to pretend I have a cone shaped tool to get a path for a 12mm straight endmill tipped by 45 deg

I've added the FCStd if you want to test it.

I'll probably have to hand code this like I did last time, I just thought it was worth reporting the error since a core dump is a pretty messy outcome.
What's a bit more annoying is that I can't rotate the Z axis for drilling the pockets. I was hoping to do all this flat on the table not have to mount the work piece three different ways.

[freman]

PS. just recalled I did use a 6mm CS bit last year to finish this kind of v-groove, but that was CS TC not an engraver TC.
Worked fine.

[freman]

By way of example this is kind if path I needed. I hand coded this one, for lack of an easier solution.

It's a bit of a trick to get around the current lack of fixed spindle rotation with a straight mill, but it should be possible. Hopefully these conic tool types will get fixed. I'm sure there are other legitimate uses.

Since it also affects ball-cutters hopefully it will get fixed.

[GeneFC]

I just tried the cone-crasher file and it ran just fine on all of your 4 tool choices. The profiles were a bit weird due to the holes, but they looked reasonable. I opened your file and ran it. No changes of any kind.

It seems that the straightforward way to deal with this sort of problem is to tilt the model the same way the physical stock needs to be tilted. As I recall from previous forum topics your mill is an ordinary three-axis machine without any tilting capability.

I do that sort of thing routinely when I need to process multiple orientations. Very easy, reliable, and much less prone to problems than faking tools or using the "rotation" feature of some of the very new Path ops.

OS: Windows 7 SP 1 (6.1)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.23970 (Git)
Build type: Release
Branch: master
Hash: a30cf5b4df22cf43f58211210b70183a7d6c17aa
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

Gene

[freman]

Thanks testing the file. It seems odd you find nothing. I'll take another look. I just did a fresh master last night to maybe something will flush out.

My machine has three cartesian axes plus the means to rotate the spindle. That is a fixed manual adjustment not a motorised degree of freedom. I was hoping to use that here.

Yes, I realise I could tilt work and mill straight but my clamping is less robust like that, lots of other details not worth discussing here, but there was good reason why I would prefer to machine the 40mm slab of stock I have clamped on the table.

I know these rotation features are new and problems are expected. Half the point was to test them and provide f/b which I did elsewhere for the rotation problems. It seems less usable that it was about 6mo back. This stuff gets included so it gets tested. Part of testing is push it till it breaks.

[freman]

OK , just took another look at that file.

The offending path Surface001 is configured with a straight 8mm endmill, so it will open and display without problems.

What is causing the crash is selecting either the 12mm v-mill or the 8mm ballend tools.

Open the path dlg, change the tool , close and CRASH.

I get the same thing with last night's master:
FreeCAD 0.19, Libs: 0.19R23993 (Git)

As I noted in OP :
Use legacy tools is true.

This may be a factor.

[GeneFC]

Use legacy tools is true.

This may be a factor.

That might be true. I am using the new non-legacy tool handlers, but I did not change anything with respect to your tools when I ran the file. Still, the new tool routines may be able to handle the V tools without error.

My machine has three cartesian axes plus the means to rotate the spindle.

Sorry, I missed that.

Gene

[freman]

Thanks Gene. It's odd that we are not getting consistent results.

Could you try enabling the Use legacy tools options and testing that path with the V and ballend tools? It maybe that there is a coding difference when that is enabled.

Here's a couple of pics. Always easier remember when you have a visual rather than the wording of a forum post.

The 45 deg path was relatively simple to hand code but it still took a lot of time checking and double checking that I hadn't made a dumb mistake or typo somewhere which would ruin the work a waste this beautiful bit of stock.

Once I cut this off the stock it's going to be a lot harder to clamp and it won't be possible to machine the two 45 deg faces without reorienting the work which will introduce an alignment error. Now you see the job you can probably see why I wanted to keep it on the table.