SolidWorks has created a new site for enhancement requests. Login (you have to be on subscription) and submit your enhancement request or vote on others. You can also join in on discussions about the various requests. The Top 10 requests will be announced at SolidWorks World 2009. Just click here and make your voice heard.
*I apologize for the formatting, or lack thereof. Copy/paste doesn’t play well with TypePad.*
I posted a teaser about backwards compatibility in SolidWorks about 6 weeks ago (see it here). In response to that post, Ken Fields of purCAB/Seralyn, Inc. sent me a white paper he wrote about that very subject, albeit CAD generic. I found his paper to be well written and thought out. Rather than blatantly plagiarize, I got permission from Ken to publish it. I’d love to hear your thoughts on what Ken has written. I’m sure he would too. Here’s his paper, verbatim:
CAD SYSTEMS – IN PURSUIT OF PART FILE COMPATIBILITY AN END-USER PERSPECTIVE
One of the most striking policy issues that continues to be promulgated by virtually every CAD System vendor is the issue of part file compatibility from one major release of their software to the next — or more correctly the lack thereof. The rationale for this lack of compatibility as stated by these companies tends to revolve around pseudo–technical arguments about the difficulty involved in having to maintain this degree of compatibility; the delay that such compatibility would cause in the deployment of new and improved features; the lack of end-user support; etc. While most of these arguments are essentially a smoke screen to disguise a business strategy that believes that the CAD vendor needs to “encourage” its users to be under maintenance (by making any older version essentially implode on itself), in reality, this policy does much more harm to the vendor than the policy brings in. First, it fosters an “us versus them” mentality, because it is as if a gun is being held to one’s head – upgrade or perish. Second, instead of acting as a catalyst to encourage users to upgrade, it elongates the process. Users eschew upgrading until they feel completely safe. And finally, it completely ignores the enduser’s perspective in the zero/oneness of this policy. To be clear, this is not a backwards compatibility issue as all vendors support the “reading” of their prior version files and in that sense they can be called “backwards compatible”. Nor is this a forward compatibility issue where the prior version of the software tries to read files from the current version (although this would be one way to address the issue raised here).
First, let’s examine the implications of this policy on the end-user. Since part files (actually any non-generic CAD file – part, assembly, drawing, even a material file) saved under the newest major release of the software automatically and irrevocably become completely incompatible with any previous versions of the software, it is not possible to switch over to the new release piecemeal. There is no testing of the waters so to speak (yes one can effectively conduct an internal beta test, but there is no way to “test” production unless one has the resources to have duplicate production streams) nor is there any way to switch back if something becomes unworkable (short of reconstructing the previous parts in some manner – either by hand or from a previous backup). In a single user/single seat environment, this may be tolerable as there is a one individual that has complete control; but consider what happens in a larger environment of multiple users and multiple projects. In a multi-user/multi-project environment, one could convert the files on a project-by-project basis (this strategy could also be implemented by a single user). That is, Project-A continues with the current release, while Project-B is developed under the new release. Fine, good idea…unless of course a user is working on both Project-A and Project-B; or what if some files are used in both Project-A and Project-B. This is why, counter to the argument made by the CAD vendors about enduser needs and desires for new features, that many large companies wait until the final release (effectively a year after initial availability) to make the conversion or they simply don’t migrate, but skip an entire release due to the “risks” involved.
To be fair, complete cross-version compatibility would be difficult, if not impossible to guarantee especially over multiple versions dating back 10 years or more. But is that what the end-user is asking for? Is the end-user really asking to have cross-compatibility between V1999 and V2009? No, clearly not. But what would be of benefit is to be able to try the latest version without the fear that once started, there is, generally speaking, no turning back. So what could be done that would offer an improved transition for the end-user, keeping the development effort reasonable for the CAD vendor, and at the same time acknowledging the underling business policy at play here.
One solution to these conflicting issues would be to offer a Save As V(N-1) command. That is, V(2009) would support a Save As V(2008); V(2008) would have had a Save As V(2007), etc. This approach has the following advantages:
1) It would probably address 90% of the compatibility issues that arise.
a. Accidental conversion. “Oops, I didn’t mean to click on save”.
b. Allows the user to drop back to the prior version if required…i.e. it reduces risk, especially for companies with multiple users spread over multiple projects.
2) This approach would allow for a very manageable and well-defined development effort. That is, development does not have to worry about supporting every single version, just the most recent.
3) It would encourage yearly update as opposed to year skipping (because of the N-1 policy).
4) It would encourage earlier testing and conversion…because now it is not zero/one.
5) It would be a marketing coup by the first CAD vendor to recognize the virtues of this approach.
6) Finally and perhaps most importantly, it would allow for the easy isolation of bugs by being able to test the problem file under the prior release. That is, is this a problem that was introduced in this latest release or is it one that also existed under the prior release. Currently this is not at all easy to check, as there is no way to take a current-release file and turn it back to a prior-release (short of recreating it by hand).
Questions (roadblocks?) will be raised such as “it will be impossible to save a new version part as a previous version part, because there are new features and enhancements that the user might have used that are not available under the previous version” and therefore the vendor should do…nothing? First, many of the enhancements made each year affect the UI and not underlying features. Second, a significant percentage would be “accidental conversions”. Third, it does not have to be a perfect solution – just make it so the end-user community has a way to unwind things if it doesn’t work. Having to recode (and re-input) features that were based on new enhancements by hand is not unreasonable and looks like a panacea compared to the prospect of recreating the entire file by hand. The real question is which CAD vendor will recognize that it needs to spend less time on developing new “features” and more time listening to it user base.
Me again. Personally, I don’t know enough about coding to know how feasible it is to be able to ‘Save-as’ to an older version. I’ve heard the arguments about new features not being available in older version, etc. It seems to me that it could be set up such that those unavailable features would just be recognized as “dumb”. Again, I simply don’t know enough about coding to speak intelligently about it. I don’t know that I’ve heard a single end user say that backwards compatibility isn’t needed, or that they’d never use it. Where I’ve heard rumors of it being worked on, one can jump to the conclusion that it is doable, right?
Could you, would you use it? Remember, this is across the board and not just related to SolidWorks.
Yes, I know I just posted about SolidWorks World ’09 but there’s some other posts out there that I wanted to bring to your attention ’cause they’re important.
First, Richard Doyle is looking for your 1st time story. If it’s good enough, you could end up on stage with Jeff Ray. Check out Richard’s blog and leave your story in the comments. There is also a thread in the SolidWorks forums too.
Next we have Matt West. If you’re quick, you still might be able to suggest a couple of questions for him to ask Jeff Ray and Jon Hirschtick. Matt is interviewing them for a SWW podcast. Jump over to the Solidworks blog and leave your suggestions in the comments.
By my math, which can be iffy at times, there’s only 53 more days until SolidWorks World 2009 begins in Orlando. That means there’s only 51 more days until I fly down there. I was honored to receive an invitation to attend as a member of the press, and plan on making full use of my "Press" credentials. With the number of SolidWorks partners that are going to be there, I should be able to line up reviews of their products so as to entice you all into purchasing. Ok, at least, maybe, checking out their offerings.
Have you registered yet? If not, you have until January 9, 2009 to save $100 on registration. With guest speaker Sir Richard Branson on the bill, plus Jeff Ray and Jon Hirschtick, how can you go wrong? SolidWorks will even throw in breakfast and lunch every day! If that’s not enough to convince you…
Ok, ok, how about 150+ breakout sessions? Your mind will go into overload with all the info you get from them. Still not enough of a reason? How about the opportunity to meet actual SolidWorks employees and bend their ears about your issues? That has to be enough, right?
Seriously, SolidWorks World is so worth the trip for any user who wants to get to know SolidWorks better. Between the training, networking and the partner products you can see and/or try, you just can’t go wrong. Yes, I know I sound like a shill for SolidWorks, but that’s not the case. I’ve been to three of them and left knowing more than I did when I got there. Hell, my former boss was impressed enough tthat he was interviewed by SolidWorks on why he sent employees. At the very least, go to the SolidWorks World web site and check out the agenda to see what you’ll miss out on if you don’t go.
Where I just imported the latest iteration of the building, I thought I give you all a quick project update. Currently, the upper level assembly has 4550 parts in it and 10,500 bodies (I need to dig into the assembly to find out why). There’s 383 Sub-assemblies, so there are only 14 mates being resolved in the upper level assembly. Mass properties, though a bit skewed weight-wise, are:
Mass = 48,204,613.98 pounds (24,102.307 tons)
Volume = 1,331,786,532.68 cubic inches (770,709.8 cubic feet)
Lately, we’ve been running into some huge problems with PDMWorks. Last week, I was crashing to desktop quite consistantly when using PDMWorks. I’ve been working with SolidWorks tech support to figure out what’s happening. Currently, there appears to be an issue with a dll file in Windows (x64) that’s partly to blame. The current work around is to have PDM turned off whenever possible. Actually, the only addin I have turned on is SolidJott (if you don’t know about SolidJott, you really should check it out). I’m still missing my SpacePilot, but system stability is more important than anything, or so I keep telling myself.
The project is progressing along nicely, however, and the powers-that-be are happy with what we’ve produced so far.
If you’re working on large assemblies, I’d love to hear about your issues and how you solved them.
This will be a short post but, hopefully, a useful one.
Have you ever imported a non-native SolidWorks file only to see errors? If you right click on one of those errors, you’ll see an option called ‘Import Diagnostics’. Choosing that will bring up a new dialogue box that gives you a list of the errors. At this point you have the choice of fixing all faces, fixing all gaps or, by right clicking on one of the offenders, fixing them individually. Through trial and error, I’ve found that fixing all faces will fix the gaps. Naturally, though, there are instances where this doesn’t work. I’ve had times when the "fix" actually causes the offending surface to be incorrectly fixed. After you’ve fixed the errors, you’ll end up with a bunch of bodies (unless you have FeatureWorks, but that’s a different post). At this point, go to Tools->Features->Combine. With any luck, you’ll be able to combine all the bodies.
Where, often times, these erroneous imports are surfaces, you can utilize the surfacing tools in SolidWorks to repair them as well. I’m no expert on surfacing, so I don’t want to go too deep into the "how" portion. I would recommend getting familiar with the ‘Delete Face’ option, as well as the ‘Filled Surface’. Perhaps a surfacing expert (Matt, you reading?) might be able to shed a bit more light on this subject.
This is how I deal with imported data. How do you do it?
First, let’s talk about SolidJott. The brainchild of our Canadian friend, Ben Eadie (of SolidMentor.com fame), SolidJott has quickly transformed from a helpful website to a full-blown SolidWorks add-in. Think about it, you’re stuck on some problem and all you have to do is click on a tab in your task pane to post your question. Such a much easier way to go about finding answers to your problems. Essentially, a world-wide SolidWorks braintrust at your fingertips!
Next comes news from the peeps at SolidWorks Labs. They’ve released FOUR new experimental applications. Treehouse, Tagger, Presentation Studio and a Collada export add-in. You can view either view the press release, or just head on over to SolidWorks Labs and check out their offerings!
First, an apology. I’ve been absolutely slammed at work lately and just haven’t been able to put the time aside to write. I’m sorry.
On to the subject of this post, though the title may be a bit misleading. I know that there are people out there who are creating 20-, 30-, even 100,000 part assemblies. Mine isn’t that big; It’s hovering around 3900 parts +/-. However, it also encompasses 300,000 square feet. It also includes large amounts of imported data. One drawing, with only six sheets in it, is already at 30MB and isn’t close to being done. I think I’m rambling a bit now…
How does one go about managing all this data in SolidWorks? Carefully. When the project started, we sat down and looked at the overall scope. I was tasked with setting up templates, work flow and management of the overall assembly. Here’s where the meat of this post starts. When you’re going to be dealing with large assemblies, you can’t just start throwing parts in willy-nilly. You’ll end up regretting it. Take some time and think about how you can break it into more easily digestible chunks. Even these chunks can often be broken down. Create your sub-assemblies independently. (There are those who will argue that in-context relationships are no big deal. Personally, I avoid them whenever possible. I’ve been bitten in the ass one too many times.) Combine your sub-assemblies into assemblies. Combine these assemblies into another assembly. This isn’t an exact science, though. How small you break things down and how you decide to combine them depend on the overall size of the design, as well as the design itself. When all is said and done, you want as few mates in your upper-level assembly as possible. (Right now mine has 17.)
By utilizing sub-assemblies, and sub-sub-assemblies, it’ll make it easier to have multiple people working on the project together. It was because of this that we were able to assemble the building as quickly as we did, much to the delight of the customer. Sub-assemblies work well when it comes to creating configurations and drawings, too. A subject for another post perhaps?
Large assemblies can be quite manageable, so long as you spend some time thinking about it.