Formulaes and DC behaviour
-
Do you have the model as an example? And please label which is the joist
Thanks,Chris
-
Hi Chris.
Here are two models, seemingly the same. Model.skp holds no formula in the parent component, while the other has a formula calculating the cost of the joists. The parent component contains 2 levels of nested components. Level 1(test) contains the floorjoist component and 4 wall components.Upper level(TrussWallFloor) contains the test and the
TrussComponent. In Model2 you find an attribute with a formula called CostJoist2 which holds a value from the test which again holds a value from the FloorJoist component.
The overall idea with the component is to scale the floor, the walls and the roof trusses in one operation and calculate the cost of each component at the same time. Obviously not so straightforward as I presumed. Try to scale the two models and see the difference in the joists. It is important that you scale the component in a cc 600 increment.(follow the grid.Dagfinn
-
Sorry if I'm particularly dense. I am trying and we'll figure it out.
So in your models, the first one worked just fine as far as I could tell.
The 2nd one has scaling issues. The floor joists and getting messed up upon scaling. And you're saying the only difference in the 2 files is that the 2nd one, that messes up, has added the cost function. So it seems that the unrelated cost function is actually messing up the scaling ability.
Is that what the problem is? I'll explore that for now unless its something different.
Chris
PS you can make it snap to increments of 60 automatically by using something like this in the lenX
LenX=round(current("LenX")/60)*60
So say someone scaled to 310. That is the "current("LenX")" value. It gets divided by 60, which is 5.1667. That gets rounded down to 5. Then multiplied by 60 to go back up to 300, which is divisble by 60. So the LenX entered in the scale command of 310 gets forced down to 300. Hope that helps,
EDIT: Of course I just tried this with no luck whatsoever in your model. It seemed to break the model. I'll try to see if I can figure out whats going wrong, but I don't promise anything. Joists and trusses are foreign territory for me
Chris
-
oh yeah, I remember playing with your model last time you uploaded it and I found out there is a problem with it saying it is it working in CM, but it appears to be workin inches actually. When it gets scaled, the value being returned is in inches. So to get my formula above to work, I had to divide by 60/2.54 to convert it to inches. Its very odd behavior and I'm not sure if its a bug or working as intended. But enter this formula in for LenX and it should now stick to 60cm increments on its own.
=round(current("LenX")/(60/2.54))*60
Of course this does nothing to help answer your original question. I'll keep working on that.
-
Thank you for all help.
You are quite right regarding the problem. Establishing a formula in the parent causes scaling problems. I will try to investigate it further, but right now I don't have a solution to this odd behavior. Thanks for the tip on the increment formula, I will try that one later. -
Hmm, ok so I tried taking your model #1 and merely adding custom attributes to get the sum value up to the main component and sure enough, it breaks the component.
This is not normal behavior. And if it is reproduceable from scratch, in a new model, this behavior should definitely be submitted as a bug.
-
I have tried several times to retrieve values from subcomponents in a formula in a parent, and every time I do this I encounter scaling/copy problems. It seems to affect the scaling/copy function directly in the sub you are linking to in the formula and nothing else. If this is a bug, it should be corrected because it is a really powerful feature that should work properly. If you refer to a parent value in a subcomponent everything works smoothly but not vice versa. Could you submit this further? Is there anyone else having some ideas?
-
OK, so I just tried to recreate your problem from scratch in a model set to CM and the component set to CM. WOW! I'm having lots of problems. Very much screwey behavior. I'll see if it is the same in an inches model.
Ok, so I couldn't get it to go wrong in an inches model. So then I went to reproduce it again in CM, and I couldn't get it to go wrong again. But I do have some ideas about what I might have done differently. So maybe tomorrow when I am more awake I can try some more on it. Good luck!
Chris
-
I keep forgetting that you Californian are 9 hours behind us. Thanks again!
-
I have rebuild my component using inches instead of CM, and the formulas no longer interrupt/distort the component as with cm. There is obviously a bug involved. It should be fixed. For the time beeing, the *2.54 will be me my way to the metric system. Thanks for that tip, Chris
-
@dagfinnie said:
I have rebuild my component using inches instead of CM, and the formulas no longer interrupt/distort the component as with cm. There is obviously a bug involved. It should be fixed. For the time beeing, the *2.54 will be me my way to the metric system. Thanks for that tip, Chris
I second a request for a fix of this. It's very awkward to be forced to work with imperial units. At least for us metric people.
-
What could be akward about imperial units? We measure inches down to the 1/64, 12 inches in a feet, 3 feet in a yard, a lot of yards in a mile. Even more feet in a mile. Then theres also a lot of square feet in an acre, and a certain amount of acres in a square mile. And sometimes someone talks about hectares and I'm not sure if those are metric or imperial.
See, its just that easy.
I honestly google imperial unit definitions regularly when I have to go larger than feet and inches, and I have used the system my whole life. It could be worse though, it could be based on some ligical system of 10's or something.....
Chris
Advertisement