Stability

Stability of SW has been a perenial issue for several years now. When CTDT
became a common occurance in SW circles there were many theories as to why
it would crash. People with seemingly similar setups would have very
different experiences. Over the last 6 months I have noticed something that
I think has been overlooked. We have developed a list of things to check in
hardware and the operating system. What hasn't been added to the mix is the
effect of bad data on SW stability.

Here is the history that I am using to base my hypothesis on. During the
last six months I have worked on a couple very large assemblies that at the
outset were pretty distressed. They had numerous mate errors and numerous
CTDTs. As the mate errors came under control so did the CTDT situation get
better. Recently I have been working on some mold data. I get data from the
same source. Some data is healed by an outside source before work and some
data is only checked in SW using the tools available. The data is IGES from
CATIA. When working on the healed data I have few CTDT, just what I would
consider (UGH)normal. When working on the unhealed data I have been having
numerous CTDT (8-10 per day). Same hardware, SP, etc. The only thing that
has changed is the data.

If this hypothesis turns out to be true then a number of people here have
been unecessarily told that their hardware was at fault when in fact it was
non-robust handling of data in SW itself.

I wonder if anyone else has had a similar experience?

Paul

 

As we all know, there are so many hardware, software and settings
variables that coming up with a universal set of rules for attaining
stability is virtually impossible.

A recent experience may be an interesting one to add to the set of
variables however, since it could offer an easy "cure" for many
SolidWorks performance issues.

One of my co-workers was struggling to open a fairly large assembly in
order to update the associated drawing and found it impossible to do
so without errors and failure to complete.

He assumed that it was because of a memory (RAM) limitation on his
system and repeatedly spent time asking an associate to perform the
operations for him with copies of the files on a "higher powered"
system.

Since my system has the same 500Mb of ram as the one that was failing
to resolve the assembly drawing, I became curious about what else
might be the root cause.

To make a long story short, it turns out that by simply resetting the
Windows pagefile to have the initial AND maximum sizes the SAME value,
the problem was aleviated.

I have always been an advocate of NOT allowing the Windows O/S the
freedom (or burden?) of dynamically adjusting the pagefile size. This
stance has again been confirmed by my co-worker's situation and is
based upon:

1. A dynamic adjustment of the pagefile size wastes Windows system
resources.

2. Allowing the pagefile size to change simply invites fragmentation
of the hard drive which leads to performance slow-downs and possible
compromised data transfers.

So I think everyone should take the simple steps to set the pagefile
to be at least twice the value of the actual RAM and, of course, to
make the initial and maximum sizes the same!

Also, disk defragmentation should be performed regularly, even if the
built-in Windows utility is used and reports that the level of
fragmentation is not great enough to warrant it. (I thinks Windows'
own threshold for allowable fragmentation is too high.)

It certainly can't hurt...

Per O. Hoel
___________________________________________________________________

 

Per:

I agree with Dale except that I'd add that once you understand the 3 Gb
limitation of windows, you'll look at RAM and VM in a new light. If you
have 2 Gb RAM, don't set your page file to 4 Gb, windows can't handle all
of that memory. Unless you're doing big assemblies, chances are you won't
use the 2 Gb of RAM, so a page file would barely get used, still, I'd
probably set it to 1 Gb. If you're paging out, you need more RAM.

There are a few resources for troubleshooting crashes. There is a bit of a
troubleshooting guide in the SW knowledge base which started as one of my
posts here to the ng a couple of years ago. It's still fairly relevant.
Search the KB for "crash".

There is also a new troubleshooting wizard of sorts on the SW support site
that will walk you through a few scenarios. I'm not sure how helpful it
is, but it looks interesting.

Richard Doyle and I have both written user group presentations about this
topic. I'm sure Richard would share his, and mine is available on my
website (http://www.frontiernet.net/~mlombard follow rules of thumb link).
I'm not saying this stuff is comprehensive, but it's a source of
information.


Other comments about Paul's original post.

If you are crashing on the imported data, have you tried to Parasolid round
trip the crappy Catia data? How about import diagnosis?

On the assemblies that crash a lot with mate errors, are there incontext,
assembly features, comp patterns or things like that dependent on the
failed mates? What happens if you work with the failed mates suppressed?

matt

 

Matt,

Actually if I have the data healed and repaired before importing I
eliminate that problem. Export and reimport as parasolid seems to be a
half measure. I will do a VDA round trip if I want to be sure the data
is clean, as VDA has the highest standard for data integrity that I am
aware of.

My whole point is that bad data from whatever source (self inflicted
of inhereted from a customer) will cause instability. For parts with
complex geometry the dreaded General Fault from the check tool is a
sure sign that trouble of one sort or the other will crop up later. In
my opinion data should not be allowed to crash a program.

In the case of assemblies my experience was that cleaning them up
(removing incontext, fixing mates, etc.) caused a reduction in
crashes. There were deeper problems with these assemblies than could
be fixed with suppressing mates.

Bad data is yet another item to be added to the multitude of things
that can cause unexpected terminations.

 

We just worked through something a bit strange and this might help someone
else. SW2004, SP2.1.

The scenario is this - in simple form, and maybe not repeatable other than
that assy. A component had a few good mates, and a few broken ones that
were based on a suppressed part. If we selected a mate and shift-selected
at least two other broken ones, then RMB, it would CTD. If we ctrl-selected
the same set by selecting a good one first, it would work fine. If we
selected a bad one first, CTD. Etc. Lots of iterations.

The overall picture is that the mixture included broken mates, good mates,
shift-selecting, ctrl-selecting, selection order, at least three selected
including at least one good or at least one broken - you get the picture.

Bottom line is that updating to SP3.0 stopped the CTD & the selection worked
fine. Hope this helps someone.

WT

 

My data checking procedure is as follows:

1. Run diagnosis; Fix as many gaps and bad faces as possible.
2. Run Tools/Check (General Faults mean stop work and get the file
fixed)
3. Run CTRL Q with verification with rebuild on.
4. Write to VDA format (and any others with a strong standard. If SW
won't write to these then you know there is a problem(s) that probably
is deeper than what SW can fix.
5. You can check edges by using select tangent edges. If edges that
should be tangent don't select take a close look around the vertex
where the select stops. If you zoom way, way in and see multiple
vertices where there should be one or edges way off of surfaces you
can rest unassured that you have bad data that will cause subtle
problems later on.
6. You can select faces in areas where you suspect bad edges/vertices
and export just those faces to IGES or parasolid. If they don't look
much like the faces looked in the model you have bad data.
7. Sometimes you can use face delete with fill to remove and patch bad
faces. If they won't patch then you know that you have bad data.
8. Use your free eval seat of Rhino to investigate the nuts and bolts
of your surface model.

OR

You can send the data out to be healed.

 

Wayne, I guess I never understood or asked what "RMB" is before.

I probably do relatively light duty SolidWorks parts and assemblies
compared to machinery desginers in my plastic parts work, but I just
do not get CTDs with SolidWorks 2003SP5 on my Dell M60. Can't
remember one in 4 months.

I must admit I am a bit compulsive and have learned to organize my
plastic part builds in the History Tree in a way that seems logical
and lets me go back and easily modify things for design iterations,
and radii and fillets and such. I don't know if that helps me avoid
CTDs, but maybe so.

I also typically do not do surface work at all, and rely on prismatic
shapes for 100% of my type of work.

I just finished a foldup snap-together plastic part design with 4
parts connected by 4 hinges with all multiple configurations, and
never had a crash in the week long project.

Bo

 

RMB - right mouse button.

Most of our projects are large machines for lifting/moving cars, car parts,
car building people, boats, combines, personal watercraft, etc all over the
place, and so a lot of the models will have some sort of imported car parts,
etc. Might be an engine/transmission assy, complete body, frame, etc, but
they are converted STP files of several hundred meg. I think this is one of
our issues,but unfortunately, a necessary part of our business. Some of the
assy files go into the thousands of parts.

WT

 

Can't you convert assemblies into a "dumb solid" for use in assemblies
whereby you get rid of so many parts.

Bo

 

It used to be that four times the RAM was recommended. That was when 256MB
was a lot of memory. Now days with people running 1GB and some 2GB this
doesn't make sense. Even with the 3GB switch the system can't deal with
more than 4GB of virtual memory* unless you are running on a Server version
of Windows. I think the limit for pagefile plus physical ram is 4GB. With
the 3GB switch 1GB is reserved for the OS/Kernal to use and the rest is for
the program(s) to use. When I get a chance I will probe the 3GB limit and
see just how much SW can really use past 1.5GB.

*Virtual memory = Physical RAM + Pagefile

 

Actually, the assemblies I was referring to there are the lifts I design,
not the imported models.

On the other hand, a couple years ago I wrote an article about joining parts
of an assy together to do just that. It's a procedure that's easy to forget
if you don't do it often, so I started to document the steps and it turned
into a full article. Copies are available upon request.

WT

 

Wayne,
Send it to me please, I would like to make it availbale for user groups if
you don't mind.

Richard

 

[snip]

My recommendation is to use STEP, IGES or ACIS (SAT). These are the
most used translators in SolidWorks.

Don't use VDAFS as it is not as widely used and VDAFS is not a strong
standard.

Obviously, don't use Parasolid (X_T or X_B) since no translation takes
place in these formats.

-Insideinfo.

 

You're gonna take some heat for that, I think. I often use Parasolid to
heal or troubleshoot data. I'll import a messed up Iges, and round trip it
with Parasolid, and it will often improve it.

Paul was using VDA as a round trip tool, so he wasn't giving it to anyone
else.

The best translation with SW is Parasolid. Period. Take STEP if you have
to and IGES under protest.

matt




(InsideInfo) wrote in

 

Doesn't SolidWorks 2004 have a new feature allowing easier creation of
a single solid out of an assembly of parts? Thought I remembered
hearing something about that as a way of speeding up large assemblies.

Bo

 

Yes, you can take an assy and save it as a part file. What you get is a
part file made up of lots of surface bodies - each of the original assy
items becomes an individual surface body. If you do the parasolid route out
of a join, you end up with one solid body. Saving an assy as a part is
quicker. So, I think the proper method maybe depends on what you are
comfortable with (surfaces or solids) and what you intend to do with it.

Here are some statistics for a gearmotor I tried. The file sizes will tend
to vary depending on what is done in the model before it's saved. I also
ran Unfrag on the files & they were reduced in size for the time being.

1. 854 KB Received .SAT file

2. 252 KB Assy file created from the .SAT

3. 1,390 KB Part files to go with the assy file

4. 1,568 KB Joined part file - still dependent on individual part files

5. 865 KB Parasolid output file

6. 1,240 KB Part file saved from imported parasolid - complete



7. 1,808 KB Part file saved from assy file

8. 713 KB Parasolid saved from item 7

9. 1,096 KB Part file saved from imported parasolid





Notes:

Item 2 SW assy file many parts trailing along behind

Item 4 SW part file 1 solid body - still dependent on part
files

Item 6 SW part file 1 solid body - complete in itself

Item 7 SW part file 17 imported surface bodies

Item 9 SW part file 17 imported surface bodies



WT

 

VDAF is not used here for file transfer. It is used to check the file. I
don't even do a round trip as Matt suggested. From what I understand VDA
holds the data to a higher standard than any other format with STEP being
second in this regard. If SW won't write a VDA file, which happens quite a
lot, than I don't try to do anything more with the file, I send it out for
healing.

I wish I could share pictures of some of the stuff that I have come across
in the last little while. Edges that form loops completely off the surface
they are supposed to be with, vertices with mismatch up to .0009 inches
that SW happily lets in the door.

SW sometimes will show what is really happening if you use diagnostics to
locate areas with bad geometry and then export just the surfaces around
that area to a temp file. You might be surprised at what you see when the
surfaces that don't look so bad when with the rest of the model, are made
independent of it.

One of the blokes I have been working with has shared that while CATIA
tolerances on surfaces can be set reasonably tight the tolerance on edges
or vertices is something astronomical like .1mm. This is the kind of thing
that you can find in SW by selecting edges using the tangency option or by
trying to make a Composite curve.

When SW has to work with these kinds of problems it would not be surprising
if they cause ambiguity in the data which could make the software unstable.

 

VDAFS data has only beziers in it - you cannot store analytic geometry
(cylinders, ellipses, etc.). Even NURBS need to converted to beziers.
This is why VDAFS files are so large compared to STEP or SAT.

VDAFS is very limiting in topology as well. There is no BREP
connectivity (lumps / regions, shells, faces, etc.). Which is why you
cannot import VDAFS files using the "BREP import" option like you can
with STEP or SAT (ACIS) files.

In a nutshell, SolidWorks has to undergo a lot of data conversion
while creating VDAFS files. While this may serve your purpose for
"stress testing" geometric data, failure to create a VDAFS file does
not necessarily mean your model is "bad".

Hope this helps,
-InsideInfo.

 

SolidWorks is most likely masking the errors when you import a
Parasolid file. (Since PS is a kernel file format, it probably just
assumes the data is good). A Parasolid file is just a file dump of the
geometric representation of the model. Roundtripping via PS should
make no difference...

Try doing a body check before and after the roundtrip to see if the
body errors actually reduced.

-Insideinfo.

 

(InsideInfo) wrote in

Whether it should or not, it does. SW does some automatic healing of
imported data. It could be that it is just activating these routines when
it sees the imported data.

matt