V19 quirks

[chrisb]

Is this the wrong spot?

You can reset the configuration with the button in the preferences. Another possibility is to delete your config files or to move them in case you want to restore them. Removing the folder with all its subfolders resets FreeCAD to factory settings.

[GeneFC]

Is this the wrong spot?

The FreeCAD configuration files are located in C:\Users\#####\AppData\Roaming\FreeCAD, where ##### is your Windows user id.

The image you showed above is displaying AppData\Local, not AppData\Roaming.

Gene

[SpaceCase]

Found 'em! Why 'Roaming' when this Computer never moves?

TempSnip2.PNG (25.9 KiB) Viewed 651 times

I have re-named them to backups, and, discovered how to draw rudimentary circles around the entries. By the dates they are fresh from the V19 install so prob'ly the Tree View Preference was the default state in V19. I never reset it in V18 so ... yeah.

About to take the plunge and enter FreeCAD-19 and try out Bance's practice Practice Document, and suddenly realized oops!

Thank Bance for the practice Document, Highly anticipating investigating. The one I attached was just one Body? or did that Toroid Cut make another Body? The same method of trimming the Pipe in the real Practice Bowl gave a red-ink " Cannot Compute Inventor Representation for the Shape of BowlCut001 " error but showed the Pipe cut off nice and neat,

this practice Practice Document is from before the Toroid Cut. Another Error in all the Trial. Essentially a Toroid is laid in the bottom of the Bowl, so proportioned and positioned to intersect only the Pipe, and then do a Boolean Cut. Would that make another Body, or what's a better way to trim the Pipe flush to the inside faces of the Bowl?

When I re-enter FreeCAD, I'll see if that Torrid Trial got Errored.

[Bance]

Do it with a groove, if you're smart you can re-use one of the pipe sketches.

[SpaceCase]

In tinkering with Pipe configurations, an interesting phenomenon occurred. A Pipe of concentric circle Sketch Padded out without that ingenious Pre-Pocket Pipe-path clearing the way through the sidewall, same dimensions everywhere, when Grooved at Radius 9mm (= Bowl Inside Radius) the Grooved Pipe appears not Grooved, thusly:

TempSnip1.PNG (121.05 KiB) Viewed 615 times

, but when Radius is edited to 10mm:

TempSnip2.PNG (122.29 KiB) Viewed 615 times

. However, with all the same Dimensions, the Pipes placed within the ingenious Pre-Pocket Pipe-pathway Groove off the Pipe right flush with the Faces, as envisioned, yes. Thanks. (Did not fill in the 4th quadrant of the Matrix, assuming a Pocketed Pad Pre-Pathless Pipe behaves the same as the Pad-Only Pre-Pathless Pipe, as they had both also behaved each other the same with the Pre-Pocket pathway present.)

I would very much like to understand why one Groove Grooves concurrently-faced Sketches while the other does not, depending on presence vs. absence of identically-dimensioned ingenious Pre-Pocket Pipe-path?

Also I would like very much to understand why these Pockets:

TempSnip3.PNG (79.83 KiB) Viewed 615 times

, Sketched on a Base Plane instead of a Generated Geometry, according to Stable Model Best Practices, do not also punch through the Pipe, as they go from the Plane Through All, hypothetically to infinity?

Oh, heck. The last Document, PracticePocketPipe, won't attach, but it's the same Pipe in Pre-Pocket Pathway you Attached to me earlier, with the Groove added in. Heck.

HW: Ratty Intel(R) UHD Graphics 600
OS: Windows 10 Version 2004
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git)
Build type: Release
Branch: releases/FreeCAD-0-19
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.6+
Qt version: 5.15.1
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)

[Bance]

The groove looks like a co-planar issue, there are rounding errors in the OCC kernel, it pays to overlap where-ever possible. The second try has different numbers and works.

As to why the pocket doesn't go through the pipe, it is historic, the pocket was made before the pipe.....

You made a hole then filled it in

[SpaceCase]

Oh, CoPlanar, confusing. I think I get the concept, even though the Faces are curves.

I would very much like to understand why one Groove Grooves concurrently-faced Sketches while the other does not, depending on presence vs. absence of identically-dimensioned ingenious Pre-Pocket Pipe-path?

I prob'ly used 'concurrently' wrong. Maybe should have said 'coplanarly', whatever. To re-phrase, how come one of these Pipes Grooves, but the other does not, even with all the same Sketch dimensions? Didn't want to Overlap, thought it would Groove the Bowl also, bad-bad. Also worried about Best Practices saying to use fewer features if possible, plus Curiosity, the most important of all Human drivers (except maybe Love sometimes), makes me wonder.

Thank you for the insight on the Pocket Array not poking through the Pipe. I assume, then, that they would indeed poke through the Pipe if it were placed before the Pocket Array in the Design Tree. Very good to know.

[Bance]

We are talking about the kind of numbers that make no difference in life, 1.000000001=1=0.9999999999 for a human but not to a computer. This is co-planarity, in the terms we speak of.

This type of problem shows how important it is to understand how the SW works. If you know you will have to model a feature in this fashion then you can add in a nib or make a flat, they will obviate the problem

Incidently if you switch off the reversed feature of the groove it succeeds at 9mm (why did you do that anyway?).

Or you could make the smaller radius 8.999999mm, the difference is far beyond conventional machining tolerances.

[SpaceCase]

That is a mystery, as on my end, the Document PracticePadOnlyPipe, which does not Pocket out the Sidewall before placing the Pipe, does not Groove the Pipe in either direction, where the Document PracticePadPipe, which Pockets out the Sidewall first, then Pads the Pipe off a congruent Sketch to the Pocket, does Groove the Pipe in either direction. Prob'ly just left the Reversed checkbox wherever it was when I got through seeing if it made a difference, which it didn't. Sorry for the confusing filenames; they evolved that way.

Whatever, I like this method better because there's no coplanariality, but what does that Exception about collinear points mean? I need an Error Message Beep Alert, as I don't know if the Exception occurred during the Sketch or the Groove.

Is this the most stable strategy? Or should I put the Polar Pocket Array first before the bottom Groove?

TempSnip1.PNG (93 KiB) Viewed 534 times

HW: Lenovo (TM) ideapad 330
OS: Windows 10 Version 2004
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24276 (Git)
Build type: Release
Branch: releases/FreeCAD-0-19
Hash: a88db11e0a908f6e38f92bfc5187b13ebe470438
Python version: 3.8.6+
Qt version: 5.15.1
Coin version: 4.0.1
OCC version: 7.5.0
Locale: English/United States (en_US)

[Bance]

I have noticed that you are using some convoluted method of creating tangency constraints, this is not good....

Select the end points of curve and line and use tangent constraint.
Sketcher_ConstrainTangent

This could be the cause of your error!