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

Reply to
kellnerp
Loading thread data ...

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.

  1. 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...

Reply to
Per O. Hoel

snipped-for-privacy@draeger.com (Per O. Hoel) wrote in news: snipped-for-privacy@posting.google.com:

I agree with everything else. On this point I would recommend using twice the RAM only until experience shows how much you might actually need. But this is only a difference of opinion.

Reply to
Dale Dunn

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

formatting link
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

Reply to
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.

...snip

Reply to
P

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

Reply to
Wayne Tiffany

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.

Reply to
P

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

Reply to
Bo Clawson

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

shift-selected

Reply to
Wayne Tiffany

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

Bo

Reply to
Bo Clawson

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

Dale Dunn wrote:

Reply to
kellnerp

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

Reply to
Wayne Tiffany

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

Richard

Reply to
Richard Doyle

[snip]

[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.

Reply to
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

snipped-for-privacy@mailinator.com (InsideInfo) wrote in news: snipped-for-privacy@posting.google.com:

Reply to
matt

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

Reply to
Bo Clawson

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

  1. 252 KB Assy file created from the .SAT

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

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

  2. 865 KB Parasolid output file

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

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

  1. 713 KB Parasolid saved from item 7

  2. 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

Reply to
Wayne Tiffany

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 k>> My data checking procedure is as follows:

Reply to
kellnerp

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.

Reply to
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.

Reply to
InsideInfo

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.