You're taking about a circular reference which will end in a non ending loop and may crash the tool. You can set either one of them.
May be you can use a macro in which you can chose which dimension to be driver and which one to be driven and then accordingly changes will be made or set the macro to suppress/unsuppress equations.
This is an interesting idea. My first thought is you would want to stay away from a circular reference issues; meaning that you could end up with an infinite loop. I've always stayed away from a situation like this because I've wanted to be sure my edits were going one way. To test this idea I set up a sketch with a simple rectagle and set L = 2*H. This is a simple equation to write and does prove that it only works one way. A change of H drives L, but L can not be directly edited.
My advice would be to not attempt doing this with SWX equations. Maybe you could write something with excel and use a design table.
It does not work to have two people both driving the same car at the same time. Same goes for geometry, you cannot have two dimensions that are driving each other and driven by each other at the same time. You can change drivers, but you can't have two drivers at the same time for the same geometry.
Doug: your analogy is invalid. A much more accurate analogy is that you have a driver and passenger and when the driver gets tired the passenger can take over and become the driver while the driver then becomes the passenger.
Since driven dimensions are meant to be driven ultimately by some user input it AND because they must be self consistent(well, assuming we can solve the equations properly/accurately) there is no preferred driver. e.g., in your analogy either the passenger or driver are both as good a driver and we could care less at any time which one is actually driving. e.g., either one and in any time swapping sequence will get you to the destination.
e.g., does it matter if you drive the radius with the diameter or the diameter with the radius? Of course not.
The mathematical equation D = 2R where we can think of the right hand side as driving the left hand variable is identical, mathematically speaking, to the equation D - 2R = 0 and R = D/2. So the "preferred" driver is only for convience... in some sense it's just a matter of which variable we "solve" for.
How to prevent circular/infinite loops? Simple, use the last dimension that was input by the user as the "preferred" equation and for the others that reference it as driven. Again, it won't matter at all in the end.
e.g., your dimensions can have an "driven state" and a "driver state". Analogous to your passenger and driver. The driver state is the numerical value entered in by the "user" and the driven state is the equation that is used to compute some a value.
To make it "circular" all we need to do is have each dimension have these two states.
Radius: Value = 3.2, Equation = Diameter/2
Diameter: Value = 6.4, Equation = 2*Radius
The only problem, of course, is when the values get out of sync. This can't happen though if the equations are properly related. Suppose we change the value of the diameter to 9. All SW has to do is treat the Diameter as the driver for Radius(no big deal, already can do this) and update it's value to 4.5 using it's equation(again, it already does all this).
Now suppose we change the radius to 3.9... SW just has to then treat the radius as the driver and do what it already knows how to do.
It can simply internally mark which relationship is the driver and all other's must be the "passengers". Again, if there is no issues of inconsistency the values will never get out of sync and it ultimately doesn't matter what is the driver and what is the "passenger".
More complex relations such as non-linear relations or more than 2 variables result in systems of possibly non-linear equations which may or may not have solutions. This is not necessarily a deal breaker though as it still can be possible to have consistency in most cases. e.g., A = 2 pi r^2, it is always true then that r = sqrt(A/2/pi) since we obviously want to have positive radii.
Ultimately driven dimensions are just mathematical equations(possibly systems of equations) and the user inputs some values and the rest can be computed. It doesn't matter how this is done because in the end we just need the values(doesn't matter which ones the user decided to input and which ones it wants computed). Obviously for some situations the user may underdefine or overdefine the system or the system itself may not have any solution. I don't think this is a big problem though consindering the convience one would get from being able to define such relations.
Ok, Wayne that is probably the best one can do with SW. But the method you point to shows that with just a little tweek SW's can handle these "Circular" equations.
All SW has to do is do the suppression for you. That's it! How does it know which equations to "supress"? When I enter in the dimensions for one "equation" all it has to do is supress that equation and unsupress all the other related equations.
It's quite simple. When you manually edit a dimension it should then become the "driver" that and all the other related equations then become driven.
Even though what I am discussing seems to be "circular" it isn't. We always know which equation we want to be the driver and SW's knows this too. 1 equation always is the "driver" that drives all the others. SW's already does this. The only difference is that it can automatically change the driver for us when we try to set value of a driven dimension.
You will have to submit an enhancement request for that functionality to be added.
Something similar to the behaviour of "Link Values"?
Yes Alan, basically the exact same thing as link values but using some equation to represent the relation.
For example, suppose we have an annulus and we always want the outer diameter to be 4 times the inner diameter. We have to set up an equation to do that AND we can only have one of the dimensions be the driving dimension.
What I would like is to be able to drive either dimension and the other always updates properly.
i.e., there is no a priori reason why any specific dimension is preferred over any other so there should be no reason to impose that condition. Of course it makes it easier to deal with programmatically. It's even more aggregious that we can only make "links" that give equality.
It wouldn't be too difficult to add the ability to link through equations. Either the user would have to provide 2 equations that are inversions of each other or solidworks could attempt to solve them.
For the example above
OD = x
ID = 4x
OD = x/4
ID = x
These represent 2 link equations. The first is used by SW when we drive the OD dimension and the 2nd when we drive the ID dimension. If are equations are not inversions then there is a possibility of inconsisency. This would require very little work on SW's part to implement(it already has all the tools built in).
OD = x
ID = 4x
and when we drive ID solidworks internally solves for x = ID/4 and substitutes it in for x in the OD equation. (internally it does basically what we do in case 1 but attempts to do this internally)
I am not a specialist in API, but it seems that a macro is the ticket here.