AFAIK, since the rules for that part are in a different database, that part will not update. So in case you want that part to derive with assembly, you need to add rules in the same assembly project.
I think there might be a little bit of confusing DriveWorks functionality with some SOLIDWORKS techniques for using references/equations/top-down design. A few comments.
- The bar will only change height with your assembly if there is an external reference from that assembly to the bar, so that's not really a DriveWorks question, as that length would then be a "driven" dimension based on that reference and not a "driving" dimension that you capture and modify in DriveWorks.
- DriveWorks does have a statement on in-context relationships in their help files, which they make public. You can see it here: In Context or Top Down Modelling (KB13103024) (DriveWorks Documentation)
- DriveWorks does not actually change existing models: it creates new modified copies of a master model. Those copies have names that you give them by rule and are stored in a folder of your choosing (if you are using something besides Xpress). So if you have a master model (Bar.sldprt), and you create a copy (Bar A.sldprt) at a certain length, that's how long Bar A is. If you want DriveWorks to create a longer one, it won't modify Bar A to be longer (although you certainly could do so manually), it will just create a new copy (Bar B.sldprt) to your new length.
Let's use this as example:
Imagine I want to make an jet engine model driven by driveworks. This engine model use external reference(a skeleton sketch) to determine how long the wing span is, and driveworks then use this value to determine how many turbine blades to generate.
Now I give this model to Airbus, and let's just assume they use solidworks to design airplane, they put my engine onto the assembly, they "hook up" my skeleton sketch to their wing of the aircraft, hope that when they change the wing size, my engine model can be driven to reflect the change(changing the number of blades etc). However my model is driven by driveworks, and we know driveworks don't automatically update the part if it is in higher level assembly, how can I make this work?
Now I then give this model to Boeing, they put my engine onto the model and hope the same thing.
And then I give the engine to bombardier...
You can see, this is a scenario where I want to give my model to many different companies, and those companies, each company also have many parts from different companies(hydraulics, landing gears, flaps etc). And there is no way the driveworks logic can travel with these models and make the whole thing "live" right? The chief designer may just change the length of the aircraft, then ideally it should automatically update engine, landing gear, cockpit... and ideally the chief designer don't need to go to each part and manually fire up the driveworks. Are you telling me this cannot be achieved by driveworks?
Any suggestions is highly regarded.
Out of curiosity: What level of DriveWorks are you using: Xpress, Solo or Pro?
(It won't change my answer much, I'm just trying to gauge what you're trying to use)
Running through that example:
- You have an engine model, and it's being driven by DriveWorks.
- In that model, you also have some features being driven by external relationships.
- These are two very different methods of "automating" your design. In fact both methods require different sorts of techniques: you can't have a dimension that is both controlled by DriveWorks AND driven by in-context design. One method requires that dimension to be a Driving dimension, and the other requires it to be a Driven dimension (using SW terms for the dimension property here). They can't be both, you must choose one. In your case, getting the customer to change the number of blades requires them to edit features and "hookup" a reference sketch to an assembly.
- I'd say a general rule of thumb is that it is best if you can commit to one method or the other. Trying to do both techniques in the same model is absolutely possible (albeit not for the same dimension/feature... but different dimensions/features in the same model... that can be done). In fact DriveWorks' statements on using in-context relationships talks about that quite a bit. It is, however, a little bit of a dance to ensure that you have a clear line of demarcation that makes sure that what you control by DriveWorks doesn't interfere with what's being controlled by in-context modeling.
- So, in your case, what to do? Well, in your scenario, you are trying to control the same property in different ways. And you could maybe do a workaround with multiple redundant features, one controlled by external reference, and one by DriveWorks. But failing that, you're probably looking for one solution to handle it for you.
- If you want to empower your customers to come up with the solutions themselves, DriveWorks Pro does give you the option to put your forms online through DriveWorks Live, and as part of your project administration, you can elect to allow online users to download files that you make available to them (and you are in control of what you make available). That way, you could put all of the logic behind the number of props, length and landing gear options, etc. into your DriveWorks project, and all your customer sees is the end result. That would better protect your IP by not having to embed your logic into your models, for them to see when they add it to their models. A nice ancillary benefit there is that if they configure and download a new version of the model, replacing it in their assembly should be a snap: since the two versions are made from the same master model, they OUGHT to have most of the same references for mates.