Frustrated!

you worked an entire afternoon on a drawing without saving?

bill

Have you updated to SP2.1? This was to address speed and a few other issues.

Keith

This is a good place to vent, Bob, and a lot more. You can learn a lot here and get your questions answered by experts . . . and some non-experts (like me). Welcome BACK to the newsgroup. Perhaps you should lurk here more often. You would have already known the answer to the slow drawing performance issue.

Best regards, Mark 'Sporky' Staplet>

There is some workaround method of getting the deformation data. I believe it involves creating an eDrawing which should create an "analysis file" containing the deflections of each node in a text form. Unfortunately, my memory is not that good and I couldn't figure it out by tinkering. I'll bet a good search of the NG would bring you the answer or maybe someone here remembers.

JJ

I'm not sure this still works, but when CosmosXpress came out, it would create a text output file for each job and save it with the suffix .OUT. If you open that file with a text editor, like Notepad, you can find the maximum deflection (it's in meters, no matter what units you are working in). If that's what you are looking for, you are in luck. If the deflection you are looking for is some where else and you aren't too fussy, you might be able to get close enough by scaling from a print of the deflected shape.

Jerry Steiger Tripod Data Systems

I've donw that. Many times. I have, in the past, had 10+ work in progress models open and did't save them all day. Of course, these days I do save and save often. Anyone who thinks saving every few minutes should be the norm is nuts. Good software doesn't crash. Period.

Jim S.

I don't think it is crazy to plan for the unexpected. It would be ideal if software never crashed, if power interruptions never occurred, and if computers never hiccupped. None of these things should happen, but they do. To deny this and to not precautionary measures is nuts.

JJ

Bob:

The "unhandled error" is not just a single problem, it could be a hundred different things. If you want to fix the problem, the best thing is to try to isolate the cause. There is a crash troubleshooting document on the SW FAQ, and an on-line Troubleshooter that may or may not help you find the cause.

You might want to consider calling your VAR before you get this worked up instead of only to complain after the fact. Sometimes they can help you solve problems like these.

Possible causes:

SolidWorks software SolidWorks data (part, assy, drw files corrupt) bad install (sometimes due to antivirus software) other questionable software installed causing conflicts temp directory too full bad virtual memory settings corrupted registry (try to log on as new user) Novell network Windows network slow hardware drivers RBP syndrome (rapid or random button pushing)

Many folks have reported drawings much faster in sp2.1.

Good luck,

matt

snipped-for-privacy@wentworthlabs.com (Bob MacGregor) wrote in news: snipped-for-privacy@posting.google.com:

Thanks for the tips guys I'll look into them when I finish this project. Also got this info from John Picinich @ CADimensions thought I'd post it for other people.

************************************************************************** Cosmos Express Deflection: Does it or doesn't it?

Note: This subject was brought up during our introductory OKSWUG meeting. There were differing opinions, so here is information you may find useful. This is more or less a Newsletter Tutorial.

Using Cosmos Express (Included free inside of SolidWorks 2003), you can get a pretty picture of a deflected part, based on Force or Pressure criteria you specify. The typical depiction of deflected or stressed parts in analysis software is to exaggerate it. Cosmos Express gives you this representation, but doesn't really tell you what the true deflection is. Or do they?

After you do a Run Analysis, you can SAVE the data by clicking the Close button. After saving, there will be several files with the part name (with "COSMOSXpress Study" after it) as the filename, with varying extensions ("partfile-COSMOSXpress Study.out", "partfile-COSMOSXpress Study.mas", etc.). We need to OPEN the file with the OUT extension ("partfile-COSMOSXpress Study.out") in Notepad. In the middle of the file, in the "Load Case 1" section, you will see something like the following listed:

Minimum/Maximum Displacements

X-displ. Y-displ. Z-displ. Node: 106 106 211 Min.: -0.00038138 -0.054787 -1.0483e-005 Node: 1294 2201 1071 Max.: 0.00038140 1.2401e-006 1.0500e-005

Maximum Magnitude of Displacement Node: 106 Max.: 0.054789

For a simple one-way, or maximum, deflection analysis, you can use the "Maximum Magnitude of Displacement" and grab the Max. Value listed there. This is the Maximum Deflection, according to SolidWorks. But SolidWorks does all its measuring in METERS (does all it's Angular Degrees in RADIANS, in case you wondered). To convert this to Inches, you take the Max. Value (0.054789) times 1000 (1000mm in a Meter) divided by 25.4 (mm in an Inch). Thus the equation would be as follows:

0.054789 * 1000 / 25.4 = 2.157047 inches for this example.

If you have multiple deflections from multiple loadings, you need to subtract the Maximum and Minimum values from the direction you are interested in, either X, Y, or Z. in the example above, the X and Z directions basically zero themselves out, and don't, due to compressions and such in the material during loading, or so I am told.

Hopefully this is beneficial for some of you. If you find this information hard to follow, not so educational, or just plain wrong, let me know.

Craig Milligan snipped-for-privacy@okswug.com

*******************************************************************************

Good luck. bill

Jim,

Very few examples of this, and none of them are parametric solid modelers. All of them crash "Period". Even Pro-E on UNIX.

The only program (of any complexty) I use that doesn't crash is Mastercam. A big reason for this is that it does'nt use MS components, especially the memory "mangler". You tell it how much memory it can use and it grabs it, and isolates it.

Regards

Mark

Parametric solid modelers are a tiny, *tiny* fraction of the software market. There are far more complex programs that don't crash.

Sounds reasonable. Every Java program can be told how much memory it is allowed to have as well.

Jim S.

Jim,

Hmmmm... Can you give me an example ? Even FEA programs are less complex than modern solid modelers. They deal with huge amounts of numeric data, but this data is much simpler in structure.

Regards

Mark

Any database system.

Google.

Telephone switching software.

High traffic websites.

Imagine something like Solidworks having to support thousands of concurrent users.

Jim S.

These applications manage (huge amounts of) relatively simple data structured in a quite well known manner. User interaction is predictable and limited (buttons, texts...)

Solid Modelers and CAD use complex data structures (API has more than 100 different classes...) which evolve in an explosion of unpredictable ways. How many different solid+surface+multibody parts can you generate with 2 sketches (each containing a single circle) and, say, 3 features ? I'm pretty sure no one knows, and it would take months to test them all...

I never saw a clear requirement of MTBF for a CAD. What would be "accepatable" for you ? One crash per day ? one per week ?

I have to agree with Matt, about a Novell network. It does not work too well with Windoze Xp, that is why we scrapped Novell.

Phillippe,

My point exactly. A solid model file has several layers of variable data which are driven and controlled by complex mathematics. This is true for a single part file. Once you start adding mating relationships, in-context features, etc., the complexity can grow exponentially.

Not trying to make a case for sloppy software or anything. It's just that I've been using this stuff since the mid to late 80's (around Pro-E V7 or

8). It just seems to be the nature of the beast.

Regards

Mark

FWIW, I gotta agree. I don't want to antagonize anyone who is having a hard time. We've probably all lost data due to crashing and it is extremely frustrating. But, like many of you, I've worked with many CAD programs over the years and they all crash now and then. I don't expect that will ever change. It goes well beyond the company's development priorities and their lack of concern for existing customers.

This doesn't mean that it couldn't be better, even much better. It doesn't mean that people have no right to critique, complain, vent, and etcetera. But if you have a zero tolerance for bugs then you are going to be forever banging your head against a wall. It is better to accept that some crashing is inevitable and to save your work regularly. Off soap box.

JJ

'Simple' by whose standards? The Google developers might look at the SW file format and find it laughably simplistic.

Now, that would be the essence of good design wouldn't it? If SW doesn't have their data structured in a well known manner (even if only known to SW internally) things are much worse than I thought.

Uhm, user interaction in SW is no more complex than any other piece of software. Just what actions do you think are more complex in SW?

As do most software applications.

You consider 100 classes to be alot? The Java API consists of several thousand public classes and hundreds more internal classes. Most enterprise programming projects consist of thousands of classes in addition to the libraries they use.

If it is properly designed, you don't need to test them all. The boundary between a sketch and something generated from that sketch should be well defined. If it isn't, there is a problem.

Zero crashes. Period. Anything less is a miserable failure. A crash represent a core software design flaw. No operation or combination of operations should leave a system in such as state that it must terminate.