Problems with EQUATIONS

[jimdogg]

I have modeled an assembly using equations to control part's lengths etc. This assembly has multiple configurations. The over all dimensions are very easy to change and everything updates when forced rebuild is keyed.

My problem happens when drawings referencing this assembly fall over. To fix this I need to open the the assembly (in some cases this is a sub assembly as well) and rebuild, rebuild, rebuild.

Is there any way I can get around this?
Something to automaticly rebuild this model when its referenced maybee?

Any help/ideas much appriciated

Jim
New Zealand

 

[SBaugh]

Sounds like you have a circular reference. That's why you have to continue to do a force rebuild. I would find the circular reference, then you wouldn't have to find away around the issue your at now. Plus it would make it more robust.

Regards,

Scott Baugh, CSWP

http://www.3dvisiontech.com

http://www.scottjbaugh.com

If you are in the SW Forum Check out the FAQ section

To make the Best of Eng-Tips Forums FAQ731-376

 

[jimdogg]

I'm not sure I have a circular reference.
I have an equation that uses the answer of another equation to calculate it's answer.
Would that also cause this problem Scott?

These equations control the model and I don't really want to remove them.

I have done some testing and it seems to be that when I open two drawings that reference this model, the drawing opened last will have fallen over.
The drawings are of different configurations.
Thats where I have to open the model and rebuild every configuration to make the drawings work. Painful stuf on our p4 1.8s.

Thanks anyway Scott.

 

[aamoroso]

What exactly do you mean by "they fall over"?

 

[meintsi]

When you have assemblies where equations in one part drive equations in a second part, it's common for SolidWorks assemblies to have to be rebuilt multiple times. (limitation?)

This first rebuild takes care of the 1st equation where the next rebuild takes the calculated result from the first rebuild and recalculates the 2nd, etc. The logic used by SW seems to linear here.

I have had some success in reducing these additional rebuilds by changing the order of the parts in the assembly tree to more closely match the order in which the equations need to be solved.

I also don't get what you mean by fallen over? Are you saying that it shows the assembly not rebuilt correctly?





Remember...
"If you don't use your head,
your going to have to use your feet."

 

[jimdogg]

Sorry.
What I mean by fallen over is that the assembly has not rebuilt and this shows up on the drawing.

Thanks guys

 

[charbroil]

I’ve seen that term “Fall Over” here a few times and always assumed it’s a more pleasant way of saying blew up, which is what a few of my first models did.

Nonetheless, Circular Reference warning bells are going off.

jimdogg, let me get this straight:

You are changing the length of ‘Component A,’ which resides in an assembly. (Are you changing the length in the context of the Assembly or at the Component stage? That’s important)

When Component A is changed, it’s supposed to tip off a change to Component B in the assembly. You’ve done this with equations, and the drawing of Component B is not up-to-date with the newest changes when you open it.

After you make the change to A, is it feasible to open the assembly and rebuild it to satisfaction before opening the drawing of Component B? If the assembly is constructed right, this should only require one rebuild.

If not, it may be a feedback issue: The assembly knows Component A was updated and rebuilds itself. But does it tell Component B (the model that the drawing is referencing) that it has to change? Without some work (help me here Scott), assemblies don’t “talk to” lower level components. They’ll shift the components around as the mating conditions require, but rebuilding a sub-component (and making sure the model is saved for all referencing documents) isn’t something I’ve made happen yet.

That’s probably because I build a very small percentage of my parts in the context of an assembly. Much of my Boolean editing (subtracting/projecting) is done in assemblies, but for the most part, the basic frameworks of my components are begun separately. So my knowledge base is a bit different.

One thing you may try (if you haven’t already) is to make the (SLDDRW) drawing reference Component B in the assembly, as opposed to referencing the SLDPRT of B. This way, when you open the drawing of B, it rebuilds the assembly.

You may have to make a configuration where B is the only thing visible, for clarity in your drawing.


"I'm gonna go get the papers, get the papers."
Goodfellas Special Edition arrives August 17. We Gotta toughen this kid up.

 

[jimdogg]

I have an assembly where there is two or more parts which have equations controling treir length via a master layout sketch.
These parts are also mated to this sketch so when you add a configuration, all you have to do is click on the sketch, change a dimension and rebuild to update.
The equations then calculate the new lengths of using reference dimensions from the master layout sketch.

There is also other equations controling Linear Pattern pitch lengths and step quantities.
These also refer to dimensions in the master layout sketch.

EG: I have one config that is 4000 x 1000mm
The next is 3000 x 750mm and so on.

When I open the drawing of one of them, it is fine.
Then if I open the drawing of the other one at the same time, the assembly dosen't rebuild and this one is no good.

I can remedy this by opening the assembly and rebuild every configuation.

That is the step I don't want to do all the time.

I will try a few of your suggestions and hope for the best.

Thanks again

Jim
New Zealand

 

[krywarick6]

I think that I have run into this problem before also. If I remember correctly, an equation in an assembly model used to control a part has an undesired affect if the part has configurations, and those configurations are then controled by part equations. Did I lose you?

The part is getting it's info from the assembly. It is then trying to resolve any part equations. This can create a computational conflict where "A" supercedes "B" and "B" supercedes "A". The computer version of the middle finger is then given.

I think it is a limitation of equations that they aren't bidirectional for that specific reason.

Regards,

Christopher Zona
Litens Automotive Partnership
Concord, Ontario, Canada