Object Will Not Generate Proper PATH

[bill]

Anybody out there have an idea why the attached files (1 fcstd and 1 brep) will not generate a correct path (below). Is it model problems, placement, mirroring, etc. Note the segment length; Is zero even allowable or valid. And notice the error message that I would have a tendency to relate to the SEGMENT Length. HHMMMMM???

HatchPath.png (161.36 KiB) Viewed 2040 times

HatchProfilePathMod.fcstd

(28.16 KiB) Downloaded 41 times

HPPM.brep

(34.53 KiB) Downloaded 32 times

Thanks

ENVIRONMENT:
OS: Ubuntu 16.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9459 (Git)
Build type: None
Branch: master
Hash: f22f5c819e510c27debea285e6a7ee20363c30d9
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17

[sliptonic]

The path generated from the object is actually correct but the rendering of the backplot is not.

I generated the gcode and pasted it into this simulator https://nraynaud.github.io/webgcode/ You can see that the arcs are correct.

This looks like a problems with the Path viewprovider. @yorik, any thoughts?

snapshot-2.png (16.67 KiB) Viewed 2030 times

[mlampert]

This is a remnant on how arcs and helixes are drawn by the view provider. The are approximated by line segments - and the segmentation is calculated by a simple formula allowing a certain error. Given the wide arc of this part the entire arc falls within that tolerance -> resulting in a single segment.

This is a great test file - I'll file an issue for it.

EDIT: http://www.freecadweb.org/tracker/view.php?id=2825

[herbk]

Hi bill,

because i have had a problem, which returns a path like yours, the past, i try'd to reproduce it with your file. But here it works fine, no matter which operation i use.

Profile on faces:

bill1.jpg (74.75 KiB) Viewed 1990 times

Profile on edges:

bill2.jpg (78.22 KiB) Viewed 1990 times

Contour from base object:

bill3.jpg (73.16 KiB) Viewed 1990 times

On the cases i have had this, there was defently also produced a partial milling path, but this is fixed since some time now.

OS: "openSUSE 13.2 (Harlequin) (x86_64)"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9440 (Git) (Packman)
Build type: Release
Branch: master
Hash: 02492358338c34373d85a4c530eb95fac8d1be53
Python version: 2.7.12
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.9.1.oce-0.18-dev

[GeneFC]

Bill,

I found that I could change the behavior repeatedly back and forth from good to bad by changing the "shape view" tesselation in Preferences between 0.1% and 0.5%.

No doubt that mlampert has exactly the correct explanation.

(I see that this has just been fixed by wmayer.)

Gene

[bill]

Thanks for all the responses.
Problem resolved by changing max. dev. tess.. to 0.1 percent.

Should this property be accessible thru Edit:Preference: Display or General ? Part Design was the only place I did not look trying to resolve this "DISPLAY" anomaly.

(I see that this has just been fixed by wmayer.)

Gene, where(link) and how was this fixed? Was it not being correlated with the BOUNDING BOX size?
I now remember seeing this happen on 2meter+ length-arcs; but not this bad (straight line segments).

Now I see that the Segment Len. is populated (see below) in the UI.

SegLenPopltd.png (32.72 KiB) Viewed 1945 times

Thanks again, bill

[mlampert]

Should this property be accessible thru Edit:Preference: Display or General ? Part Design was the only place I did not look trying to resolve this "DISPLAY" anomaly.

The current algorithm for splitting an arc into segments in the path view provider is quite simple and it happens to use that parameter (I guess it was already there and has approx. the correct semantics). Exposing this parameter in the path settings/preferences is not the right solution. If we wanted this to make parameterized we'll have to use our own value.

[GeneFC]

Bill,

I did not give proper credit. Mlampert made the fix and wmayer merged it. (I just followed the link given by mlampert earlier.)

On the topic of preferences, it appears that many preferences have much broader application than simply the category in which they are listed. I am not complaining or suggesting any changes. Just a recommendation to carefully check all the preferences, even if the category might not sound important.

Gene