Geometry driven constraint

LWL

Hello,

I am trying to setup a geometry driven constraint in the following 3D construction.

The model consists of a vertical pole 1, and a vertical pole 2 which is 1500mm apart. The diagonal distance between the top of pole 1 and the bottom of pole 2 is geometry driven.

With a parameter (height) i can adjust the length of pole 1 and 2. This means the diagonal distance between 1 and 2 changes.

Now, for a third component, which is placed diagonally, i use the geometry driven length.

My problem is the following, component 3 is changing to the correct length when i adjust the pole 1 and 2 length. So, the diagonal distance is the same as the length of component 3.

But when the poles get longer or shorter, the angle changes aswell. Unfortunately, the third component doenst adjust and gives an error in the constraints.

What am i missing?

ScottS

Seems as if it should work, yet I've tried similar things and not been able to get geometry driven constraints to cooperate. In your Drawing1, when I change the poles' Height, the diagonal bar doesn't even update in length let alone angle.

Robert

Hello LWL,

I added two user parameters that calculate the correct length and angle of the strip.
I then added a length and angle constraind and linked those to the userparameters.

The strip now correctly adjusts the length and angle when you adjust the height.

Regards,
Robert.

Robert

I forgot to say why your method is having difficulties.
Everything in a CAD program happens in a certain order.
So when you adjust the height it will update all the other constraints.
But it does not do this all at once but one at a time. So for a few miliseconds in time there is a point where the tubes get extended but the striplength is not updated yet. At this point the concentric constraints are invalid and it results in an error. Bricscad stops at this point.

So in short you have overconstrained your model.
To make sure this does not happen allways make sure all items have room to move.
In my solution I did this by adding an angle constraint, instead of using two concentric constraints.
One angle can allways move two concentrics can not.

ScottS

Robert said:

I forgot to say why your method is having difficulties.
Everything in a CAD program happens in a certain order.
So when you adjust the height it will update all the other constraints.
But it does not do this all at once but one at a time. So for a few miliseconds in time there is a point where the tubes get extended but the striplength is not updated yet. At this point the concentric constraints are invalid and it results in an error. Bricscad stops at this point.

So in short you have overconstrained your model.
To make sure this does not happen allways make sure all items have room to move.
In my solution I did this by adding an angle constraint, instead of using two concentric constraints.
One angle can allways move two concentrics can not.

So how are "geometry-driven" constraints meant to be used? I always end up having to solve the geometry myself, as you did in the new parameter expressions you introduced, and get rid of geometry-driven constraints.

I appreciate your explanation about order of operations, although it seems arbitrary that an angle constraint can tolerate being momentarily invalid while a concentric constraint cannot. I should think that setting a constraint to be geometry-driven, such as the diagonal link length, would push it to the end of the solution sequence and let it flex to be whatever it needs to be to satisfy the other constraints, whether they are coincidents, concentrics, distances, angles, or whatever.

Robert

ScottS said:

I appreciate your explanation about order of operations, although it seems arbitrary that an angle constraint can tolerate being momentarily invalid while a concentric constraint cannot.

The angle constraint never becomes invalid, for a few miliseconds it just has the wrong value before it gets updated. The reason this works is because it still has rotational freedom. The 2 concentric constraints lock the rotation of the strip. So if the length of the strip is not exactly the distance that is between the 2 holes it creates a conflict between the distance constraint and the concentric constraints. None of the 3 constraints have room to move so nothing moves and Bricscad gives an error.

I make product configurators for a living (mostly in Autodesk Inventor) and the art in that work is to make sure all components allways have the freedom to move during the updating and ending up in the right place after the update. On that note the above is not just a BricsCAD problem all the CAD systems I have worked with work this way.

ScottS

Robert said:

The angle constraint never becomes invalid, for a few miliseconds it just has the wrong value before it gets updated. The reason this works is because it still has rotational freedom. The 2 concentric constraints lock the rotation of the strip. So if the length of the strip is not exactly the distance that is between the 2 holes it creates a conflict between the distance constraint and the concentric constraints. None of the 3 constraints have room to move so nothing moves and Bricscad gives an error.

I make product configurators for a living (mostly in Autodesk Inventor) and the art in that work is to make sure all components allways have the freedom to move during the updating and ending up in the right place after the update. On that note the above is not just a BricsCAD problem all the CAD systems I have worked with work this way.

I think I see now. Thank you @Robert. What I need to watch out for are combinations of certain constraints that become unsolvable. Because an angle or distance constraint controls a single degree of freedom with a variable parameter, they are more forgiving than a concentric constraint, for example, that is either true or false, and when false is too difficult to resolve.

Robert

Yes thats basicly it, a good rule of thumb is that less constraints is allways better than more.
So if the same result can be achieved with 2 constraints instead of 3 the option with 2 is better.
As the more constraints you have the more chance there is that something becomes unsolvable.
Also if possible constrain your parts to the Origin planes instead of each other.