What version/service pack of the software are you using? I think I saw something like this back in 2012. Have you checked the SolidWorks KB to see if there are any known issues?
Have you tried this on a simple block? I checked 2013 sp2.0 and followed your steps and it worked great. (attached) I'd try that and then expand to an assembly to determine if the problem is software or your model. If simple works, upload your model.
a.SLDPRT.zip 40.4 KB
I just upgraded to 2013 hoping that it would resolve the issue, but I'm still seeing the same problem.
I was able to successfully run the part that you sent and right now, it looks like the only difference is that I am trying to run a design study on an assembly as opposed to a single part.
In my case, the global parameters are defined in the assembly and then referenced in the part.
hi matthew, can you describe your workflow?
also, when you are complete, use the pack and go to package your part and assembly into one.
once i have that i can check what might be going on. in the end this may need to go to solidworks. are you on subscription/working with a reseller?
I just rebult the system from scratch and the design study runs, however, each case produces the same values at the sensor. Even in the part "a" that you sent me, it was producing the same value at the stress sensor in the table view for each scenario.
My workflow is
1) Create part (SimpleAssembly) with random dimensions.
2) Insert part into assembly
3) Define global variables in the assembly
4) Return to the part file and define dimensions in terms of the gobal variables.
5) Define the thermal sensor in the assembly
6) Set up and run Study 1 for thermal analysis
7) Create a new design study
8) Add my global variable "length" to the parameters lise and select as a variable
9) Select thermal 1 for monitor only
10) Run design study
Attached is the "Pack and Go." It appears to be behaving the same as your part "a." Does your design study produce multiple values?
Unfortunately I dont have a subscription currently...
PackAndGo.zip 395.1 KB
matthew, sent you a PM
i'm seeing 2 issues directly affecting you
1. if the parameter you create has a name other than the global variable, you'll get an error message "no parameter defined in study"
2. it seems as though global variables aren't getting updated, as such your model doesn't update and you get the same results.
a couple ideas for workarounds while I talk to the SolidWorks guys.
A. if you create the dimensions as normal dimensions first, create the parameter study and then switch them to global variables, it seems to work.
B. get fancy with converted entities and/or equations. for example draw a line that is 1 inch long and convert that at the part level, use that to drive the dimension at the part. use the assembly dimension to run the design study.
Just got confirmation from solidworks, the parameter and global variable have to have the same name. Otherwise you might end up with an error like "no design parameters are linked in study XXX"
Also, when you create the global variable, if you want the dimension to be linked to the global variable immediately, create the global variable with the syntax =name. If you just start with the name, you have to go back and link the global variable to the dimension separately. In my model thats what the problem is, the global variable changes but since it isn't linked to the dimension, the geometry doesn't update and neither do the results.
Let me know if those fix your assembly. Thanks!
I had the same problem as the original questioner and figured out a workaround. I have a study running now, so I can't verify your solution. I thought I tried naming the parameter and variable the same and got rejected. I'm in SW2012x64.
In an assembly design study with variables driving geometry in parts, I had the problem of 'no design parameters are linked in study xxx' even though the parameter table showed them as linked.
I created a work around that I'd like to share with others..
I created a sketch at the beginning of the assembly used only to drive both variables and parameters - like a sort of dummy or stick man. This sketch is not directly used to create geometry, but is used to link (or be the go-between of) parameters and variables. For example, I have a line in this sketch, with length dimension d1. I then assign the variable 'tube_wall_thickness' = 'd1@sketch'. Then, in the actual part geometry sketches / features, I use the variable 'tube_wall_thickness' to drive them. In the design study, I then created a parameter 'tube_wall_thk' whose value also= 'd1@sketch' in the stick man. A tip is to put text description (descriptive name) in the stick man dimension itself - this makes keeping track and selecting much easier. Seems to be working so far.
Hi Kevin, good workaround. That's one of the techniques we used before we had global variables.
I've been out of modeling now for a while.....but now I'm back at it!
Kevin, that workaround works great for now. I can actually take my "stick man" dimension and use it to drive regular global variables throughout the model.
Jared, sorry to hear that it may take a while for this bug to get fixed.
Scott, I tried this method and I got the studies to run. However, it still wasn't updating the geometry.
I found a fix: create the global variables AFTER creating the design study. I got the same error ("No design variables are linked...") at first. With the design study active, I right-clicked the "equations" tab in the model tree, selected "manage equations", deleted all of my global variables, saved, and then re-created all of my global variables the same as they were before, and it worked.
As other users have mentioned, the variable names in the design study must be identical to the global variable names, or it will give the same error.
I would guess the "Design Study" tool keeps its own list of global variables, and only adds global variables to this list when new global variables are added to the part. It seems like a bug to fix. SW2014 SP0 still has this problem.
if i remember correctly, it was confirmed as an SPR but i don't think i saw it on the fixed list yet. it was late in the release so it will probably take an SP or 2 to get fixed.