Archive for September, 2011

Why You SHOULD be Running Dynamic Simulations

Written by Nick Luyster on . Posted in Simulation, SolidWorks

Let’s discuss the difference between the linear solver and the dynamic solver with a case study. Take the example of an engineer slamming his head on his desk after getting poor simulation results from his linear solver.

In scenario #1, the engineer lightly places his head on his desk then proceeds to slowly press down with his body weight. The force value, F, represents the maximum amount of force he can transmit through his neck.

In scenario #2, the engineers head starts a distance of 2 feet from his desk. The engineer proceeds to accelerate his head towards his desk with the aforementioned force value, F. After he comes into contact with the desk, his neck continues to transmit the force until his head comes to a complete rest against the surface.

Now, in both scenarios, the engineer’s neck transmits the same amount of force, F. However, the second scenario will produce higher levels of cranial stress at specific instances in time. The higher stress is related to momentum. The engineer recognizes this and proceeds with scenario #2 until the desired level of masochistic indulgence is achieved.

If we were to simulate these events, design scenario #1 could be adequately achieved with either the static solver or the dynamic solver and the results would be the same. However, if we were to run scenario #2 with a static solver, we would get the same result as we would with scenario #1. Obviously, the static solver has limitations.

The linear solver only sees the last moment in time; when things are at rest. Thus, we have two data points, the beginning and the end.

On the other hand, the dynamic solver is aware of the time in-between the beginning and the end. As a result, we are left with a much more complete picture.

For a moment, let’s sidestep the slamming head on desk approach, as this practice is no longer necessary. Let’s use the example of a cantilever beam with a weight of one hundred pounds suspended from the end.

For the linear study, let’s consider the case of loading the end very slowly. The results of this simulation are shown below.
The maximum displacement is 58 mm.

For the dynamic study, let’s consider that the weight will take .05 seconds to reach its maximum value of 100 pounds and will then level out. The maximum displacement results of this simulation are shown below.
The maximum displacement is 93 mm. This is an enormous jump from 58mm. Obviously, we’d want to study the dynamic simulation results over the static.

Tech Tip: Network Slowdown

Written by Nick Beattie on . Posted in SolidWorks, Technical Tips

Does SolidWorks sometime feel like it’s working at a turtle’s pace? The problem might stem from being connected to a network!

Working on a network is great, and in today’s age it’s basically required. Unplugging from the network could solve a lot of issues, but usually isn’t feasible. The problem is that so much stuff is looking to the network it can sometimes slow down SolidWorks. There can be a ton of reasons for this, some can be fixed! Here’ are a few tips to make your performance a better while working with SolidWorks.

  • Don’t work over the network!!! One of the biggest slowdowns you can cause in SolidWorks is by trying to work with files that are located on the network. If the files aren’t on your local computer, every time you open them, temp version of them are made in the directory they’re opened in. Every change you make has to get written to those. Every time you save the main files get written to. All of that going over the network is going to slow down SolidWorks. Copy files locally to avoid those issues.
  • Backup/Auto-Recover: You should not have these locations be on the network. If these locations aren’t local, SW will again be constantly working and writing over the network and slow down. The backup option to put the backups in the same place as the original file can double the issue if you’re working on files over the network as well.
  • SolidWorks Search: The SW Search is useful, but if you don’t use it, turn it off. If you do use it, make sure to set the indexing to “only when the computer is idle.”
  • News Feed: Turn off the option in the general area of the options to “Show latest news feeds…” It may be minor, but it’s one more thing to slow down SW.
  • Stop Streaming: Turn off things like streaming audio, unneeded web pages, and any other non-essential programs. The less trying to fight for resources the better.
  • Stop the CPU War: Everything you’re running on a computer is constantly fighting for you CPU. When you’re on the network, even more things are fighting for it. If possible, dedicate a CPU core to SolidWorks. Windows defaults everything to the first core, once that’s full, it’ll start using other cores. Most of SW can only use one core, so the more it’s trying to fight with the slower it will run. If you can dedicate a core, it will reduce the chances of a slow down.
None of this is a fix all, but the more of it you can do more likely you’ll keep SolidWorks rocketing along!

Fully Define Sketch

Written by Tony Cavegn on . Posted in SolidWorks

We have been preaching to you forever about the importance of fully defining your SolidWorks sketches. Now that you have (hopefully) accepted the reasoning behind the recommendation, today’s tech tip will help you reduce the time it will take you to accomplish this task.

Introducing, the FULLY DEFINE SKETCH command. Well it was actually introduced several years ago but it may be new to you.

The Fully Define Sketch tool calculates which dimensions and relations are required to fully define under defined sketches or selected sketch entities. You can access Fully Define Sketch at any point and with any combination of dimensions and relations already added.

To fully define a sketch:
1. Edit a sketch.
2. Click Fully Define Sketch (Dimensions/Relations toolbar) or Tools, Dimensions, Fully Define Sketch.
3. Set the options for relations and dimensions in the Fully Define Sketch PropertyManager.
4. Click the green check mark.

That’s it. To simplify it even further, you can program a hotkey to invoke the command. Now that you know how simple it is to define your sketches, there is really no reason not to. Try it. You might like it. I know your sketches will be happy.

Click for Hi Res Image

Click for Hi Res Image

Don’t Ignore That Little Green Flag

Written by Jennifer Bahnsen on . Posted in Enterprise PDM, Technical Tips

There is a setting on the workflow states in EPDM that is easy to overlook but can drive you nuts while troubleshooting. That setting is “Ignore permissions in previous states.” In 2011, it is the green flag icon on the State Box. (Previously the icon was a hand.)

Why this setting can be troublesome.
If this flag is not set there will be circumstances where permissions set at a particular state are not followed.  This particularly happens when a permission was granted at an earlier state but removed at a later state.  Let’s go through an example. I’m going to use a simple workflow and explain what happens with “Read file contents” for two groups.

 

Scenario 1:
The “Ignore permissions in previous states” flag is NOT selected for any state.

Permission: Can “Read file contents”

 

 

With this setup someone in Sales should be able to see any file that is in the Released state but not in any other state.

 

 

 

A document was added to the vault and is currently in the Initiated State.

This is what an Engineering user sees:               This is what a Sales user sees:

 

 

 

 

So far everything is as expected.

Change State was initiated on the document and it was sent to the Released State.

This is what an Engineering user sees:                 This is what a Sales user sees:

 

 

 

 

 

At this point, this is what we planned with our workflow.

Now, though, let’s Change State on the document again and send it to the Under Editing State.

This is what an Engineering user sees:                 This is what a Sales user sees:

 

 

 

 

 

Wait a minute! The Sales user is NOT supposed to see files in Under Editing. So what’s going on?

It has to do with that little green flag. Because we did not set the “Ignore permissions in previous states”, the Sales user can see the file when it is Under Editing because they were able to see it in the previous Released state.

 

Scenario 2:

Let’s try this again with a new file but this time we’ll set the “Ignore permissions” flag in all states.

This is what an Engineering user sees:                 This is what a Sales user sees:

 

 

 

 

 

Change state to Released.
This is what an Engineering user sees:                  This is what a Sales user sees:

 

 

 

 

 

OK, so far, so good.

Change state to Under Editing.
This is what an Engineering user sees:                  This is what a Sales user sees:

 

 

 

 

 

This time, this is exactly what we wanted to happen.

By turning on the “Ignore permissions in previous states” flag, the permissions set for each state were followed exactly as we set them.  So don’t ignore that little green flag!