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

Reply to
adrielk
Loading thread data ...

what type of work do you have in mind?

Reply to
neil

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

Reply to
Michael

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

KM

snipped-for-privacy@gmail.com wrote:

Reply to
ken.maren

I would not recommend SolidWorks. It crashes a number of times throughout the day, especially when creating drawings. It is terrible at large assemblies, and the files are bloated (drawings, assemblies).

I have used SolidWorks for about 9 years, but have vowed to never use it again mainly because of performance issues. Most of the new "features" that are added with every new release are just features that have always been present in the better 3D applications.

I highly recommend PTC's Pro/E Wildfire 3. It handles large assemblies with no problems (No need for lightweight components). The price is the same or a little bit less than SolidWorks. Most of our large customers are using Pro/E or Unigraphics, none of them are using SolidWorks.

SolidWorks is good for small machine or sheet metal shops though. As long as you have simple parts or small assemblies (< 50 parts) then SW will run OK. It does have better sheet metal features than Pro/E.

Reply to
Brooke

Hmmm....., sounds like a ProE snipped-for-privacy@hotmail.com. Last time I checked out the pricing for ProE, it was much more than SW, and if you wanted all the add-on packages which would make it feature equal with SW, it was really high. Yes SW has issues, as do all other software packages (CAD and non-CAD). All packages introduce new additional benefits to sway potential customers to their side. I do know when ProE was ported over from Unix to windows, it was very buggy it's first few versions. I tend to agree with Michael, ask what you customers and vendors are using, that's were the real cost savings will add up. Beyond that, attempt to determine how you would use solid models and what type of functionality you require. Beyond that, it's just gravy, it nice to have, but you really don't need it.

Keith

Reply to
Keith Streich

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.

Reply to
Mr. Who

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

Reply to
ksudavid

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

Reply to
MM

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.

Reply to
Ken

How do you know the dream world from the real world?

And the (jeopardy) answer is,... "DEMO"!?

..

Reply to
Paul Salvador

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

Reply to
ed1701

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.

Reply to
ed1701

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

Reply to
John H

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

Reply to
ksudavid

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.

formatting link

Reply to
ksudavid

Sorry Paul but that is not correct. You forgot to put the answer in the form of a question (jeopardy). The correct answer would be "What is a DEMO?"

Reply to
j

Damn! LOL!! (Alex Trebek would be proud of you) 8^)

Reply to
Paul Salvador

Hi;

Here is a question I would like to ask. Who has actualy change from Inventor to SolidWorks, what was your reason for that and what do you think about it now? I use Inventor 9 right now.

Thank you,

Igor.

To reply please use snipped-for-privacy@iinet.net.au address

That package could be SolidWorks, ProE, Solid Edge, or even

Reply to
Igor Mironenko

This question is incomplete. As others have pointed out, it depends on what your use is for the application.

In strictly abtsract terms, the pro's include:

- It is small and lightweight; easy to store and pack.

- It's many icons can be captured via screen shots to be used decorating websites.

- Its use doesn't violate any of the major religion's tenets, that I know of.

Some of the con's are:

- It has no nutritional value; it is worthless in times of famine.

- The CD could, theoretically, be modified into some kind of lethal Ninja throwing star.

- It creates CAD models but then leaves CAD chips all over your hard drive, which then need to be cleaned off with a special CAD chip brush.

Reply to
Paul

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.