Discussion of Polar Pattern and Linear Pattern behaviour

[FreeCAD97990]

I first noticed at least a year ago that Polar Pattern fails when you use it to Pattern a Pocket feature if one or more of the Patterned Pocket features fails to intersect with the Base Feature.

I have found this quite awkward when there are a number of cut-outs on the Base Feature. Either you have to Pocket and Pattern the areas between the cut-outs individually, or else you have to fill in the cut-outs, Polar Pattern the whole lot, and then re-created the cut-outs again. Then repeat as the design develops and the cut-outs change!

I've been looking at the way that Pocket (when used by itself without Polar Pattern) behaves, and comparing that with Polar Pattern. When using Pocket by itself on the Base Feature there are two bad things that can happen. The first is that the Pocket splits the Base Feature and creates multiple Bodies. Pocket issues a Transformation error if that happens. The second is that the Pocket fails to intersect with the Base Feature. If that happens, Pocket does not change the Base Feature and does not issue an error. I think that both of these cases are appropriately handled and work fine.

If you use Polar Pattern on a Pocket feature, then again bad things can happen. The first is that one or more of the Pattern of Pockets splits the Base Feature and creates multiple Bodies. If closely spaced, the Pattern of Pockets can also overlap one another and make up a 'chain of holes' that stretches across the Base Feature and again creates multiple Bodies. Polar Pattern issues a Transformation error if either of these happen. I think that both of these cases are appropriately handled and work fine.

The other thing that can happen is that one or more of the Pattern of Pockets fails to intersect with the Base Feature. Well, Polar Pattern is very helpful here, because it updates the view to show what the new shape will be with the Pattern of Pockets removed. And any that do not intersect with the Base Feature are highlighted in red. So the user can easily see what is happening and what the result of the operation will be. I think that Polar Pattern is better than Pocket here, because Pocket does not highlight in red.

Unfortunately, if any are in red, Polar Pattern also issues a Transformation error. I am wondering why that is. Clearly, the Pockets that have failed to intersect with the Base Feature cannot give rise to multiple Bodies. And in particular, I am wondering whether Polar Pattern fails here because the same criterion for failure that is used for 'Polar Pattern with Pad' has been inappropriately applied to 'Polar Pattern with Pocket'. (Clearly 'Polar Pattern with Pad' must fail if any Pads fail to intersect with the Base Feature because it creates multiple Bodies.)

Any ideas?

The same seems to apply to Linear Pattern...................

Congratulations if you have read this far, and sorry if this is all garbage!

[chrisb]

Perhaps it is sufficient to issue a warning if some features don't intersect, especially for intermediate hole hitting ones. Cutting the body in more than one piece is currently disallowed but there was already talk here that this restriction might be dropped.

[FreeCAD97990]

Hi chrisb,

Thanks for your reply.

I just had a look back at my first ever forum post (July 1st 2017) which was about this same issue, and I made the suggestion there that a warning would be sufficient.

The point I was trying to make when I spoke about Pocket (used without Polar Pattern) is that Pocket does not even make the user aware that the Pocket feature has not intersected the Base Part. Whereas Polar Pattern does so in red...... and as you say could issue a warning too.

I'm not a coder...not even close...but I'm assuming that there is no technical reason that the Transform must fail (like for example that Freecad would need to keep a record of which intersected and which didn't and that would mean lots of extra coding which wouldn't be worth it). If it comes down to a straight choice of saying either:

'Transformation Failed (because we think the user might be confused into thinking that all had intersected)'

OR

'Yes here is the Transformation (and we trust that the user has looked at and understood the red warnings on the screen)'

I think the second is definately the one to go for....


Lastly as a humble user....a body should mean one piece.......

[Kunda1]

OP opened issue #4048

[kisolre]

I just made an experiment. If you create a valid linear pattern you can then change its parameters in tree view and if it fails, because of some instances falling outside the solid, it displays an error symbol with hint "transformation failed" but everything works as if there is no error. Number of elements change, distance changes, consecutive features work as expected. So it looks like there is no practical problem for this to work and just display a warning.

OS: Windows 8.1
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.17271 (Git)
Build type: Release
Branch: master
Hash: 2d8f7ef2b47a335f99036bf328f51da1e6d015d9
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Bulgarian/Bulgaria (bg_BG)

[TheMarkster]

Any ideas?

The same seems to apply to Linear Pattern...................

Have you tried lattice2 workbench? I have found it to be more robust.

phpBB [video]

Normally with the linear array you can select an edge and the array will be positioned along that edge, but I had to deselect everything, then create the linear array, then position it because I did not have a single edge to work with. Another option would have been to do the array first, and then pocket the gap afterwards.

It is import to ensure the body is active first. Otherwise the array gets created outside the body. Notice I selected the datum line as the center of the polar array.

[Kunda1]

issue #4048 doesn't look like a release blocker, right?

[chrisb]

No release blocker, it has been like that in 0.18 too.

[jmaustpc]

issue #4048 doesn't look like a release blocker, right?

You are right, I have edited the ticket.

This is not a bug, it is deliberately intended designed behaviour. It is certainly not worthy of a "blocking" priority so I changed the ticket to a feature request.

It is just that a Body must be a single contiguous solid. How pattern features should behave when some or all of its elements don't intersect with the solid is a matter for discussion that may or may not result in any change to the current behaviour. Hence this is really a feature request.

Any further discussion about this should stay on the forum. However I have left this ticket open for future reference until any decision is made on the matter.

[FreeCAD97990]

Hello again, and thanks for the recent posts posts regarding the bug that I reported.

However, I feel that jmaustpc has not fully understood what I was trying to put across in the bug report and my earlier posts.
The present Polar and Linear Pattern commands may, as you say, display 'deliberately intended designed behaviour'.
The bug report explains that behaviour is wrong and can easily be corrected.

Putting it simply, using Polar Pattern or Linear Pattern with a Subtractive Feature that fails to intersect the Base Feature must always result in a single contiguous solid. It cannot be otherwise, because the Subtractive Feature does no cutting!

The bug is that the present Polar Pattern and Linear Pattern commands, when encountering a Subtractive Feature that fails to intersect the Base Feature, respond by failing the transform. Even though the transform must inevitably be a single contiguous solid.

This is a bug that has been present since at least 2017. The solution appears to be very simple.
Simply stop using 'Subtractive Feature that fails to intersect the Base Feature' as a criterion for failure.