Parametric arc swing of the door goes wild

paap

Made a parametric door with two swings. when stretching the clear_with parameter to the desired value the arc of the right swing most of the time goes funny.

1. I have done multiple tests with the selected area of the entities when making the parameter. All results on the right stay funny.
2. fist i had the arc swing right = swing left. made a different designtabel with the same values as the left. All results on the right stay funny .
3. the insert value of the block = 1060 mm. when making a value input to 2500-3600 mm, the arc goes funny. But making small increments of 100 mm i can go any desired value without issues.
4. when the right arc goes funny and making the value smaller, sometimes the right arc goes normal, and sometimes it stays funny.
5. I also have an asymterical door where also only the right arc swing give issues.

Meanwhile i'm going nuts,

this issue is testing my patients.

Anybody have any clues for solving this arc issue !!! Cheers

2024-05-22_01_Parametric block setup_01.jpg

2024-05-22_02_Strech_r _01.jpg

David Waight

@paap,

Can you share the CAD file so we can see how it is constructed?

paap

Sure, be my guest. I'm also giving you the asymetrical. I can't upload the csv. file. So that will be the excel file. Cheers.

30_DO_2_custom_stomp_wd_comp_glaspanel_asym_a_T.dwg

30_DO_2_custom_stomp_wd_comp_glaspanel_sym_a_T.dwg

30_DO_swing_angle_90.xlsx

paap

@David waight, Got any ideas on whats going on with arc going funny ?

I have made a single door swing, where now only the 15 degree angle arc goes funny. The 90-45-30 angle arc stay fine. Could there be something with the attached design tables and what to check for ?

Virgil

Hello.

It would help to constrain also the center points of the arcs, using the corners of the frame rectangle.
With 2 points and a radius, there are two possible solutions to create an arc.
Sometimes, the solution chosen by the algorithm might not be the desired one.

paap

Hi Virgil,

Funny you mentioning this, because i more or less came to the conclusion that the center point of the arc is moving along the inclined arc line to the end, where to start the radius value of the made input value, see attached file. But i didn't think about constraining the center point of the arc. I assume you do this with the concentric constrain, i will have to fiddle around with that to get the hang of it. Cheers

2024-05-25_03_Arc swing 15 goes wild.jpg

Virgil

Hello.

With this case, the constraining should use a coincident constraint.
For each arc, the parameters of the constraint should be:

• A corner of the frame rectangle.
• The center of the arc.

paap

Hi Virgil,

I made all my previous constraining with coincident. I made swing arcs with two lines ( horizontal + inclined ) and an arc. And others with only one line ( inclined ) and the arc. In both cases the two remaining points, one of the line and the other of the arc coincident the the top corners of the rectangle frame. Further constraining the swing with radius and angle constraints.

In your advice, when constraining the center point of the arcs with the coincident, to a corner of the rectangle frame, i could only do that with selecting the entities of the arc first, and then to one of the endpoints of the rectangle frame. Then the remaining endpoint of the inclined line to the other endpoint of the rectangle frame. Then further constraining with radius and angles. Unfortunately the arc in some cases still goes funny.

Trying with the concentric constrain i could do that very easy in the existing blocks. Is most case it work fine, but also here the arc got funny.

When using these blocks it seems that the workaround is to take small increments and undo when the arc goes funny and make new inputs.

The whole strange thing is that door swings that have a post(frame) at each side don't have the arc issue going off beat. I seems there that the parameter of these post(frames) keep the arc swing in control.

Or it is my version V22.2.03. that is just having a laugh at me.

Cheers, from the Lowlands

Virgil

glaspanel_sym_V22.dwg

Hello.

There might be cases when a constraint can be applied on either side of the existing geometry.
This happens when there are two possible geometric configurations.
When an undesired configuration is applied, the solution is to review the constraining and, possibly, to change it in a way to prevent that configuration.
Many times, several entities are involved, nu just the most obvious one.

The constraining should be applied gradually, as new entities are added to the block.
From time to time, the constraining should be tested.
This would allow to identify any potential issue before the geometry becomes too complex.

In this case, the block uses visibility states.
So, the constraining of the arc should be applied for each state.

For simplification purposes, I tested a version without visibility states, so the constraining be applied just once.

To reproduce the original behavior, I added two angular constraints.
To reproduce the 0 state I used a visibility parameter to show or hide the door symbols.

I couldn't reproduce any issue with this version yet.