I'm testing constraints with an extrusion along a path to create a door frame. I want to constrain the height and width and have them as variables but when I attempt to 'flex' the variables the results are inconsistent and wrong. I've created the constraints by constraining the path before extruding as I can't see a way to do it afterwards. The height constraint seems to work but the width is giving odd results. Example attachedperforatorNamedViewtest.dgn
i had a very quick look at the file and the unexpected behaviours you are seeing when changing variables' values is due to the profile not being well constrained. you should always try to draw your profiles as closed shapes and check their DOF (degrees of freedom) is 0/. This means that there is only one possible solution for any change of the parameters. This somethimes may be tricky when the profile is complex it is worth getting used to do so.
I have attached a quick edit of your file, let me know if you need more help with this!
Product Manager, MicroStation
Bentley Systems intl
mmm...I might have misunderstood then. There was something odd with the extrusion profile: I couldn't isolate or select it or check/show its constraints, so i have re-created it, constrained it and replaced it as an input element for the extrusion along (I have shifted the feature inadvertedly, please move it back where it is supposed to be )...let me know if it is any better now.
I understand Duncan. The guidline when creating any parametric geometry is to have the 2D elements well constrained. All profiles to be extruded should be single line strings or shapes whenever possible as they are much easier to constrain. The need to have profiles well constrained is becasue the solver cannot know which solution to pick when there are multiple ones avialble as they will all be mathematically correct (this is were geometrical and dimensional constraint tell the solver which solution is right).
Once the geometry and the solids are generated following the above guideline, they shouldn't break. So far 99% of the issues reported for geometry not responding to parameters changes as expected was due to underconstrained models. We are going to improve the constraint tools to make them easier to use and any specific feedback is welcome!
Thanks Marco. I think the most helpful things are documented workflows. A door would be a good architectural example with Height width, door leaf thickness etc. In Revit I have a specific workflow ie create reference planes, lock geometry to ref planes and flex. Having an equivalent in Microstation would be helpful. I know there are some videos on this but more is needed in my opinion.
Duly noted Duncan. Our learn colleagues have started some tech talks and one of the first was on starter on parametric modeling, where all this is explained but I agree we can do more and better, so maybe some sort of a walk through for a real-type of component could be a good idea. Bear in mind though that for making the same door there may be several possible approaches, all most likely technically correct but we could definitely show a few options.
I'm a big fan of the 'here is a way that works' school. There may be others but this works.
One thing that I feel we need to address is the placement tool of a parametric cell. ie if the cell has 3 4 5 variations, the cell name has to change. if we do not have this option and we run a report, the report will issue 1 cell name rather than the variations.
As a work around (via Carl myhill) you can add an item tag to the variations, but this again is not documented.
basically, we need this tool to work the same way as AECOsim does with its variations of the same item
If the cell names changes then you have a new cell.
Applying business data to the cell with a property such as Door Type, where the value is changed by an expression controlled by say, the door leaf width, to display the appropriate type identifier would be the appropriate process.
I agree... however... 1 x door cell with 3 x widths. place the cell 3 times and apply 3 x widths = 1 cell name, thus 1 cell type on a report.
Add an item type to the cell variation, then you can get 3 x cell names. But this needs to be documented, as its not common knowledge.
I agree with Marc that we shouldn't change the cell name but w eshould find a way to show the variation in the report and treat the variations as a business property. Let me check something and get back to you.
The cell name cannot change as it is the same cell. but the item ttype associated to the variations can change. All I am asking is for this to be added to the documentation.
Ok Ian, will pass this on to our documentation team.