Hole operation - CounterSunk mismatch with FastenersWB

[RatonLaveur]

Hi,

Today whilst preparing an assembly for production, I realized that the countersunk screws do not exactly match the countersunk hole produced by the hole tool.

Since the screws follow ISO nomenclature, I would surmise that it's the countersink option of the hole tool that is not correct, but I may be wrong.

2020-01-23_09h24_49.png (42.44 KiB) Viewed 2544 times

There was discussion about polishing the hole tool, https://forum.freecadweb.org/viewtopic.php?f=19&t=39954 so perhaps my remark can fit in this topic.

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16093 (Git)
Build type: Release
Branch: releases/FreeCAD-0-18
Hash: 690774c0effe4fd7b8d2b5e2fb2b8c8d145e21ce
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: French/Switzerland (fr_CH)

[chrisb]

Currently there is nothing wrong, it's all the user's duty. If I select a countersink for a hole I have to add the diameter myself.
The book I get it from is according to ISO15065 and lists a minimum and a maximum diameter for the top circle, e.g. for M6 screws the diameter is between 12.6mm and 12.9mm.
Is it these values which you want to have inserted automatically? If so, which of both, or something in between?

I second a feature request for a proposed value though.

[RatonLaveur]

Well yes and no. What initially bothers me is that the screw head has this flat cyclindrical section towards the top that the countersink does not allow for.

It is clear from the Hole tool Task pannel that provisions were made to adapt the values of counterbore/countersink...but they are all greyed out.
I assume that's because they were locked by default according to one norm.

Either way the topic stands: there's a mismatch between the Fasteners workbench and the Part Design Hole tool.

I would therefore support, as you do, a feature request to harmonize nomenclatures.

[davidc]

I'd like to resurrect this thread; specifically with regards to the choice of values for the countersink/counterbore options. I'm willing to take a stab at implementing any/all of the below; so I'm looking for guidance on which approach is preferred! I really don't want the below to seem like a complaint - rather I want to state what the case is today, to help figure out what I (or someone else if they'd rather) should implement for the future.

All hole cut options for "Metric Coarse" and "Metric Fine" do not allow the user to change the hole cut parameters. Hence - the default calculated parameters are the only option.

In my opinion (which is quite possibly wrong) the hole cut types don't make a ton of sense: Counterbore, Cheesehead and Cap Screw all produce a counterbore type feature with different default depth/radius. None can actually be changed by a user outside of the default value

Countersink and Countersink Socket Screw produce identical features with identical dimensions (both code paths are identical as far as I can tell).

The default calculated hole-cut parameters for "Metric Coarse" and "Metric Fine" hole types aren't generally suitable for any possible fastener that I can think of (and again, they aren't editable).

- The "Counterbore" hole cut is a counterbore of 2 x d diameter and 0.6 x d depth, where d is the nominal diameter of the hole. I can't find a fastener at my usual suppliers or standard that this might be intended to accomodate.
- Cheesehead is a counterbore of 1.6 x diameter and 0.6 x depth. It seems to fit some smaller cheesehead screws available from fastener suppliers, but I can't find a matching standard.
- Cap Screw produces a counterbore that will not accomodate any cap screws I'm aware of.


So, about making this better. I propose the following incremental steps:

1) Make parameters editable so we're not stuck with the default. Leave everything else the same. Do no refactoring. This should be around a 6 line patch and should be low risk.

2) Refactor UI element enable/disable logic to use common evaluation functions (rather than using different codepaths depending on which dropdown was changed). This is a bit higher risk.

3) Unify the hole cut types between Metric and UTS profiles. While they use different standards (and should have different default parameters), the types of fastener are generally similar, and hence I think the tool should offer similar hole-cut features. (I could well be wrong - I'm a software/electronics person dabbling in mechanical design).

4) This one I'd like input on. I propose altering the defaults to be "sensible" or "worst case". For metric counterbores, the "Mechanical and Metal Trades Handbook" 4th edition English printing, page 231 provides a table of counterbores for various ISO/DIN cap-screw standards according to DIN 974-1. Machinery's handbook (30th ed, pp 1662) has a similar table for ANSI equivalents. Choosing one of those tables would probably be a (more) reasonable starting point than values that won't fit any extant fastener. Another alternative could be to use a "worst-case" value for socket-cap counterbores. That would guarantee that fasteners compliant with ISO/ANSI standards will fit in the counterbore, at the expense of possibly having an oversize counterbore. Of course, a user paying attention to detail will be able to size the counterbore to the exact fastener they plan to use.

Of course, instead of implementing 4 with an internal table; it could theoretically share data with the "Fasteners" workbench - but I'm not clear on how this would work since "Fasteners" seems to be an external workbench.

Would patches for any / all of the above be accepted?

[chrisb]

Hi and welcome to the forum!

I am delighted to see a first post with the offer to join the developers crew
And it is a very good idea to discuss it here before starting.

We have seen here several discussions about the limitations of the hole feature. Except some recent minor fixes (and regressions) it hasn't seen many changes in years. So my guess is, that a pull request is highly welcome, but it is probably Werner who will decide this.

pinged by pinger macro

Instead of or in addition to making the properties editable, you may consider to offer the possibility to augment the predefined set of available holes. I can very well imagine a json or xml format file which can exist in user space and which is handled similar to the tool table of Path workbench.
Since both formats are not too difficult to understand it wouldn't for a start even need a GUI to edit them. On start the system table would be augmented or even partially overridden by the custom values.

[wmayer]

So my guess is, that a pull request is highly welcome, but it is probably Werner who will decide this.

I don't know much about all the different modes of the hole feature and if someone more knowledgeable in this area makes sensible suggestions how to improve it the PR will be accepted, of course.