Top level Global Variables:
Equations Part/Sub assembly in SW 2016:
How looks like the same link in SW 2014 SP5
Screen Shot – 2015 What’s New in SolidWorks – Equations in Assemblies:
SolidWorks 2017 - a good news:
Links in equations between Global Variables: Assembly <-> Parts/Subasseblies and/or between Parts/Subassemblies in Assembly are working now.
SW Development Team: Thanks! (Better late then never)...
have you ever thought of using an external parameter file in order to link global variables to different components in the hierarchy? You would not have to rely on equations across several assembly levels.
Are there any blocking issues that make it impossible to use the external file? I am just curious since we introduced this functionality specifically to inherit values across different assembly hierarchy levels.
Indeed it was my "plan B" if links between GV were newer fixed.
But now... What is the reason to add an extra .txt file instead of direct links?
the idea behind the external parameter file is that you have one location that holds the most important parameters that are required across different hierarchy levels. The downstream calculations would be handled in the component.
If you make a change to the parameter file you will automatically update the parameters in several components with the same rebuild. Basically you can do the same thing with global parameters at the top level and equations at lower levels. But from my experience it can become messy with too many equations across several assembly hierarchy levels. So I guess the benefit is that you have an easier to comprehend structure where one file goes into several others. Another benefit could be that someone without any SOLIDWORKS knowledge could define the basic design layout and the designer would do the detail work. This targets towards design automation where the initiator of a product is not necessarily a designer.
SOLIDWORKS Product Definition Team
Thank you, Frank.
Currently I'm investigating the behaviour of Global Variables.
So, I came to this thread.
The extra txt-file you mention, is interesting for some occasions, but generally I think there are also many disadvantages:
- the extra txt-file has to be managed differently, if you want to change parameters.
- there is no extra advantage when you organize your Global Variables very well.
(When all GV's are defined in Equations of the Main-Assembly, they can be pushed to all parts in the Main-Assembly and the Sub-Assemblies)
- if you want to combine Global Variables with Configurations, this seems not possible in the extra txt-file.
The extra txt-file can be useful when there are no Configurations or Design Tables neccesary, and as you have mentioned, for a system which can automatically update/change the txt.file.
Or just use Driveworks?
yes, Driveworks will give you even more options and capabilities. On the downside you will have to get familiar with Driveworks and it is not so easy to share your design (with the built in intelligence) with someone else.
Frank Ruepp Keeping the IP out of the models and in a rule-based application is the preferred way to safe guard your companies IP and competitive advantages.
I'm not one for sharing my companies design IP with customers. They don't need to know how fast I can produce their designs. They are not paying for the IP they are paying for a designed product. If my deliverables have to be native CAD models they can have a Parasolid imported into SW. If they require a drawing they can have the PDF version. If the customer specifically "requires" fully parametric models and native CAD drawing files they should be paying a serious premium.
yes, l agree that there are a lot of good reasons why you don't want to share your IP with customers but there are also other scenarios where it can make sense. Speaking of customers it could be i.e. a different department (that could be a customer for you as well) in your organization that might benefit from something you have already invested quite some time and thoughts.
In general I think it boils down to the individual requirements that you have and depending on these you might want to choose a rule-based application in some cases and a completely SOLIDWORKS based solution in other cases.
A while ago I was running into a requirement where a customer wanted to set up a parametric (injection molding) tool that he could use to generate the initial tool, manually add features (like cavities, cooling canals,...) and at some point had the requirement to update the initially generated geometry (because i.e. he would figure out that he would require a bigger tool due to design changes) without losing the already created detail features. I have to admit that this is already some years ago but at that point in time it was not possible to cover this scenario with a rule-based external solution and to be honest I do not know every detail of the current design automation tools so it likely is possible today. But it is an example when it can make sense to use a SOLIDWORKS internal solution.
Retrieving data ...