pros and cons in SolidWorks

What are the pros and cons of using SolidWorks?
Because i am thinking of getting it, a friend recommenced it but i want
to see what other people think about this program.

-Adriel

 

what type of work do you have in mind?

 

If you're considering buying a 3d CAD package, the single biggest
consideration has nothing to do with the software itself...

There's an enormous value associated with using the same package that your
colleagues, vendors and customers are--a value high enough that it dwarfs
the benefits associated with the features of any particular package. This
is the "network effect" that has most of us using Windows and MSOffice. A
poll of your "community" is as good a way as any (and better than most) to
make a choice

Translating between packages is an ongoing nightmare--do your best to
minimize it by selecting a package that will be compatible with as much of
your community as possible.

That said, Solidworks is an excellent choice....
good luck....

 

What type of work will you be doing? What would we be comparing it to?

KM

 

Yeah, I agree with Keith. Sounds like a Pro/E sales rep to me.

As with anything you need to select the best tool for the job. So
providing a description of what kind of work you plan on doing is very
important. From their you can evaluate whether the tool fits your
needs. If you are new to CAD then I think that SolidWorks has a
shallower learning curve than other packages. Of course if you have
colleagues using a package already then you can hopefully get advice
and learn from them. I think that assessing SolidWorks as "bad" at
assemblies over 50 components is a lie. Tell us what work you are
doing and the helpful people here will help you evaluate your needs.
Also ask on other forums so that you get a diversified set of answers.

 

Michael,

I think you may be going a little overboard. You're making some big
assumptions, a poor analogy and one erroneous statement. I'm not suggesting
that your input shouldn't be considered but I don't think it carries as much
weight as you make it sound.

First, the compatibility isn't much help if you, your colleagues, vendors
and customers aren't on the same upgrade schedule. If you're running 2006
while the vendors are still on 2004 and a customer on 2003 your
compatibility isn't much better than if you were on separate CAD packages
exchanging neutral format files. You don't have to search very hard on this
newsgroup to prove this point. The analogy to Microsoft products doesn't
work because they are backwards compatible while 3D cad packages are not.

Second, you're assuming the user wants to share complete CAD models with the
entire feature tree and all the intelligence intact. I'm not familiar with
your work but most people I deal with would much prefer to send "dumb"
models to protect proprietary information. There are only a small group of
people that I actually want to share my original model with.

Third, you can't tell a sheet metal guy, a casting guy and an industrial guy
they should all ignore features and only worry about compatibility. Based
on your suggestion we'd all be buying the same thing. If 85% of your work
is in sheet metal you want the package with the best sheet metal package.

Not intending to belittle your opinion, but when an individual is making a
$5000 decision they need to put a little more thought into it than you
suggest.

David

 

What an uniformed pile of crap.

I have complete engines with 800 to 1500 parts, very highly detailed
castings, no problems, no crashes. It all depends on how you have your
system set up, and whether you really "know" how to use the software, which
you obviously don't which makes you a liar as well.

It doesn't surprise me that PTC is still hiring low life scumbags to hawk
their shit. Some things never change.

Mark

 

I agree. I have never seen anyone dependent on the same database format.
One reason, it never happens. Even if you based you decision on what 50% of
your customers/vendors used, you still have the other 50% to worry about
which negates what you were trying to achieve in the first place. Based on
how much time we spend worrying about transferring files (way less than 1%),
that would have been a very poor deciding factor for us (and probably would
have kept us on AutoCAD). If data translation is a significant portion of
your workflow, by all means factor it in to your benchmark process, but that
shouldn't be your only driving factor, and the fact that you will have to
work with foreign data, no matter what, must be a given.

Ken

 

SaladWorks sucks donkey when you have to work with non-native geometry
and modify or fix it quickly.

http://www.kubotekusa.com/news/in_the_news/CPD_Mining Intelligence.pdf

SaladWorks sucks donkey for high-end surfacing. Good luck finding a
SaladWorks tutorial to do this kind of high-end surfaced model.

http://www.hydraulicdesign.net/fvs3-sample/concept-a-sample.htm

Why does SaladWorks suck at high-end surfacing?

http://cadinsider.typepad.com/my_weblog/2006/05/dassault_and_so.html#comment-17671573

"Dassault and SolidWorks are talking... Dassault/Catia is making sure
they keep the Solidworks team in check so that they do not start to
expand their reach into Catia's strengths. For example, one has to
wonder why Solidworks, with all the bright brains behind their product,
has never made any attempt to address complex surface modeling. Instead
users must rely on add-ons or other surface modelers, such as Rhino or
Alias/Autodesk StudioTools. Don't tell me they have no clue on how to
handle curvature continuity...As for data translation, it fits into the
same strategy: keep both products as separate as possible, and nobody
has to learn french."

Jon Banquer
Phoenix, Arizona

 

KSUDAVID,
I apreciate your response to Michael, but in my experience I don't
think you were entirely fair to his points. This is not a flame to you
- however, Michael brought up some strong issues and I think they
deserve some thought. Again, I have no agenda beyond adding to the
conversation - my experience is different than yours, and the
particulars of your situation will likely lead you to a different path.
I just want to, hopefully, make sure that something isn't getting
missed..

Excellent point to consider. However, also look at the 'packages' your
vendors use - if they are all using packages with the same kernal (for
instance, SWx uses the parasolid kernel, as do some other popular
packages) you can share paraolid data without having to worry about
translation issues that happen all the time when trying to share across
a supposedly neutral format like IGES or STEP. Keeping data in the
same kernel can save tons of time (=money) when communicating from one
software to another, even if the difference in software is just a
release.

You might want to reconsider this stance, based on my experience, and
on conversations with others downstream from 'product development' that
need to deal with others data. A simple 'for-instance'... lets say
there is a filleted model that does not have the correct draft. I have
a mold-maker in my local user group who hates this situation, because
with dumb data it can be very hard to remove those fillets, add the
CORRECT draft, then re-add those fillets. If you are in the same
package, the repair is easy - just rollback, add draft, then
roll-forward (adn do whatever minor fillet repair is required, if any).
This effects the projects bottom line.
I always look at my product as being proprietary, and the geometry and
innovation of my product as being the thing I'm worried about being
knocked-off. How I model is not proprietary,because that doesn't make
a lick of difference to a consumer picking it off a shelf, or some
d***head in China making a copy. Whether that proprietary info is
transferred via SWx, parasolid, IGES, or whatever, it doesn't offer me
any more protection.
If you are worried about accountability, that is important to consider.
We do maintain an archive of the exact models we send out in case
someone makes a change then claims that the change was our original
direction, but that can happen no matter what format you deliver.
BTW - CDA/NDA goes a long way. It aint perfect, but at least there is
a paper trail. I won't even talk to someone who brings ME data without
at least bringing up the concept of a CDA/NDA just so they know I am on
the up an up, and i definatelyh can't send my clients proprty out
without the same coverage

I don't want to speak for Michael - that is his business. But, as an
impartial observer, I never saw him ever allude to anything like this,
and find it unfair. When did he say that you should sacrifice
functionality for compatiblilty? All I read was that you should
consider compatiblity with vendors when making a decision, and that is
a damn fine point (as functionality of packages is also a damn fine
point!) Compatilbility saves money, as does functionality, and both
should be weighed. For instance, some of my work can be done faster in
other packages, but the short term gain would be lost downstream as
others had to correct and deal with imported data.

These are just some things to think about - again, they contribute to
the decision, but aren't the sole factor to base the decision upon. I
jsut couldn't sit back and let this go - having just recently been
through a spate where someone was responding with things that were
diametrically opposed to what I actually said in my posts, I am a
little sensitive to seeing it happen again.

-Ed

 

oops -didn't quite weigh one line from Michaels post.
'a value high enough that it dwarfs
the benefits associated with the features of any particular package'

So, he did allude to sacrificaing functionality for compatibility (my
bad..sorry),
But it still is a point to consider. I see this frequently in prodcut
development, where an Industrial Designer develops a design in one
package then the engineer has to work with it in another, with much
mayhem and delay happening during the handoff, and then more mayhem and
delay when it goes to tooling.

If you have a clean slate (after all, you are looking to buy a new
package) it is worth considering everyone who has to touch that model
between you and manufacturing and decide what path is the most
profitable. If you can standardize on packages, you win - if you can
stadardize on kernels, you are ahead of the game. If you can't, that's
cool too - then go for whatever will make you the most productive and
profitable.

 

Jon, if you know how to run the CAD world so successfully, I suggest
you just start a 3D solids company and DO IT YOURSELF!

I can sit here and tell how any auto company is an idiot for failing to
do items 1 thru 10, and pontificate. But I am not the CEO or owner.
They are and they do as they please, and they live or DIE by their
decisions.

So far, SolidWorks has about 500,000 seats sold, including some fairly
large companies using it, like Kimberly-Clark in my arena (not meaning
they don't use other packages, as typically required). They use these
SWks seats for what SWks is good at doing.

Jon, your words hereabouts are REPETITIVE. Professionals do not do
that.

Bo

 

User error <GG>.
Ever find out about developable surfaces?

 

Last I knew you both had to be using about the same release
level.
Not downwards compatable as such things almost never are.

 

Might not you also lose drawing data? Associativity data?

 

People can argue endlessly (and they do) about the relative modelling
capabilities of one system or another.
Solidworks has its pros and cons, but in general I see it as being pretty
good in most areas, except high-end surfacing.

My real gripe with it is its lack of data management as standard
functionality, and the way that you can do all sorts of things at the OS
level to completely bugger up file associativity. It just wasn't designed
with multi-user production department standards in mind. My analogy would
be with the way Windows was designed for the home user, with no concern for
security, versus the way Unix was designed.

An example:-
If you write-protect a document, you can still edit it ,and Solidworks will
still let you save it, over-writing the original!!
This still applies even if you use PDMWorks, which we proved out in a demo
with our VAR a couple of weeks ago. What was even more embarrassing and
puzzling to the guy doing the demo, was it then allowed us to check the part
back into the vault, even though we hadn't explicitly asked for write-access
to it.
The second part of the problem I'm sure was a bug in PDMWorks, but the first
part is inherent in the way SW works.

I don't know whether it's any better with Conisio, as we only had a brief
overview of it, but I doubt it.

Another example is it doesn't allow you to open 2 files with the same name,
but which are in different folders. This is a pain, but is an acceptable
restriction. What I find unacceptable is that if you have a component
called File1 open, and then you open an assembly which references a
different component called File1 from another folder, it substitutes the
wrong part! If you then do a save without noticing this, you've just
buggered up your assembly.

Nice work Solidworks.

Regards,
John H

 

http://www.offthemarkcartoons.com/cartoons/1995-12-22.gif

 

You make some good points. See my responses below.

Couldn't agree with you more regarding kernel compatibility. This is what
Michael and I should have said and thanks to you for bringing it up.
Hopefully the original poster actually reads these responses.

Another good point. Downstream in the production process is where the
complete model with feature tree can sometimes be useful. This seems to be
most true with mold makers. I might counter that mold makers and other
manufacturers probably have to deal with models from a number of different
CAD packages and should be equipped to do so. And unless your business
requires making a lot of molds this is even less important. Of course we
have no idea what the original poster intends to do with the CAD package.

Damn! I was coming at you with guns a blazin until I saw your next post.

You make good points ED. My goal was to add a little broader point of view
to Michael's tunnel vision response and you have certainly helped with that.

Thanks,
David

 

I think what Jon is so eloquently and professionaly trying to say is that
you have to consider where you are in the development process when looking
at which CAD package is best. If you are a mold maker dealing with lots of
data from various CAD packages, you may want to consider one of the
excellent non-history based CAD packages. If you are an industrial designer
you may want to focus on a package that handles high end surfacing tasks
well.

However, if you're a company who designs and manufactures various product
lines. And each product line comes in various sizes and configurations then
a high quality parametric history based CAD package is probably an excellent
choice for you. That package could be SolidWorks, ProE, Solid Edge, or even
Invent... no wait, I take that back, Inventor is never a good option.

Yes, I am aware of Jon's history. But I think he has a point to make. It's
just so buried in his childish narrow minded responses that no one
understands what he is saying. Thank God he's not out promoting my CAD
package of choice.

 

Problem is, he just has clueless rants. After all, it's not like he's ever
actually worked using 3D CAD/CAM, CAD or CAM AFAIK. Barest of grasps
of the basics or reality, at best.
Lots of buzzwords from ads. That's about it.

But it can all get pretty funny <G>.