Polar pattern bugs

[kkremitzki]

The following issues in the tracker all seem to be duplicates of the same issue that is present in 0.16, but fixed in 0.17. All sample files in the issues can be PartDesign->Migrate'd, and afterwards the steps to reproduce no longer produce the issue. Can these be closed as fixed in 0.17?

#2028
#2637
#2246
#2072
#2248

[DeepSOIC]

I think yes!

[NormandC]

I'm sorry guys, I know it's fun to close issues, but it seems I need to play the part of the buzzkill again.

On what basis can you say that for example issue #2248 is resolved?

No file were attached to this issue. Reading this description:

When a polar pattern results in overlap of repetitions, a) if the source feature is a pad, the binary union should be applied between all repetitions and the base solid (if there is one);

In less than 5 minutes I built a model showing this exact issue in current master.

So I would say this bug is definitely not fixed.

Not only that, but a new bug crept up: I completed the PolarPattern and the feature was created in the tree with no apparent error! But it doesn't work... (there's an error in the Transformed feature messages box while the command is active, but no exclamation point on the PolarPattern icon in the Model tree when the operation is completed)

To see what I mean:

1. Open attached file
2. Activate the Body
3. Edit PolarPattern

FC017_Failed_PolarPattern_no_error_message_01.png (56.67 KiB) Viewed 3921 times

I haven't looked into the other issues yet...

OS: Ubuntu 16.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10611 (Git)
Build type: Unknown
Branch: master
Hash: 44a9ecd25f27ec3efe52c9de9c95ef2b3e19dd17
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0

[NormandC]

At least 2248 is fixed where subtractive polar patterns are concerned.

[kkremitzki]

Thanks for looking at that Normand. The other 4 all had attached files, and the behavior in the bug was no longer occurring. I do see the bug you're describing though with additive polar patterns.

[jnxd]

Slightly off-topic, but can anyone explain me why there has to be a major difference between when the angle is 359 deg and when it is 360 deg?

[NormandC]

I'm sorry, what are you referring to?

[chrisb]

Perhaps it is the following, which isn't systematic but comes in handy:

• For degrees < 360 the last object is positioned at the given angle.
  Example: degrees = 240, n=3 leads to one objects at 0°, 120° and 240°
• For degrees=360 this would lead to two identical objects at the same place (0°=360°). Thus the last object is placed at 360°-1/n*360°
  Example: degrees = 360, n=3 leads to the same as before: objects at 0°, 120° and 240°

[Jee-Bee]

I break a bit in into this...
The linear pattern have also a bit strange behaviour. When i want create a pattern i know the number of objects and distance between objects.
So every time i use the pattern i am confused by its working method.
So i would say both patterns have strange working behaviour...

[DeepSOIC]

The linear pattern have also a bit strange behaviour. When i want create a pattern i know the number of objects and distance between objects. So every time i use the pattern i am confused by its working method.

+1 for linear pattern. Every time I was using it, I had to try a few times before I got the numbers right.
EDIT: but I have to admit, I hardly ever used partdesign patterns at all. In most cases, Draft arrays are superior and more convenient. And if they are not good enough, I have Lattice.