Reading and writing older versions

We've got 2005 and may go to 2006 if the dust settles. Some of our vendors use 2004.
I got an email from Solidworks for DWGgateway, which will let me
(supposedly) open and edit any DWG file using any version of AutoCAD. Is there a similar way to do this in Solidworks?
Thanks,
John
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Nope. SW is not backwards compatible across major versions (it is between service packs within a major release). This is a major item of discussion that people want.
You can save back from later versions of SW to earlier ones by saving as a Parasolid. You will get a "dumb" solid when you open up in the old version, without history or parametrics.
The best you can do is save a part in Parasolid and open in a previous version of SW and use FeatureWorks to try and recognize some geometry and pull out some history. This only works on simple geometry though.
This makes playing in the same sandbox with suppliers/customers with different versions a little tricky. ~Alex
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Well,
I know it's not exactly the same thing, but my Word XP will save as other versions back to '95 or even DOS. It will occassionally warn you that some features may be lost, but it at least it tries.
It is interesting that Solidworks purports to do the same thing for Autocad files. I agree that the SW files may be more complex, but that doesn't sound impossible. Imagine what a company could do working with it's own files, not someone elses'.
John

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John,
The biggest difference here (and it's huge) is that if your missing something in a word doc, or even an Autocad 2D drawing, the system can still usually read, and use, what's there.
Solid modeling systems in general are much different. The mathematics of the model "must" resolve to form valid topology within the accuracy of the system. With SW that's at least 10e-8 meters, and this is just the topology, faces, intersections, and vertices.
Add to that the construction database with it's dimensions, geometric relations, equations, and all the rest, and you have an exremely complex data object.
If the system can't resolve it, (missing, corrupt, incomplete, or wrongly defined elements) alot of things can happen. All of them bad by the way. At best you could get a "corrupt file" warning, and it just won't open. At worse, it could freeze or crash the application. Or even crash the entire system to a blue screen.
These are just some of the requirements for a model within the software version in which it was created. Now you want to save this binary hairball to an earlier binary hairball that doesn't support some of the critical elements that comprise it's construction in the newer version.
I don't doubt that if SW were to throw enough money and development time at it, they could make something that worked in "some" cases. The problem is, they would take so much heat for the times it didn't work, that they'd just prefer not to open this can of worms in the first place. Can't say as I blame them either
Regards
Mark

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
MM,
You make some interesting and valid observations, but I would suggest that a partial solution to this problem would serve SolidWorks much better than their current approach. Since each new release of SolidWorks adds new features, constructs, etc. it would be appropriate if attempting to save any of the newer items in an old version would produce an error/warning that the new entities are not supported. In these cases, SolidWorks could gracefully notify the user of the problem and not produce the desired old version file. On the other hand, for geometry that doesn't require the newest features, entities, etc. SolidWorks could produce the desired old version easily. I would venture to guess that at least half of all parts created would fall in this later case and the ability to save them in old versions would be very beneficial to SolidWorks users. Since cases involving the newer features/entities would be somewhat frequent as well, these would serve as an impetus for all users to stay current with SolidWorks. The biggest advantage of such an approach would be the change in user perception of SolidWorks Corp. Some of the people that believe the current approach (or non-approach) to this problem is a manipulative way to force upgrades would reconsider if SolidWorks made an attempt to deal with older SolidWorks releases.
If there were no valid reasons for a company to run an older version of SolidWorks, this topic would be strictly academic. Unfortunately, there are valid reasons to run older versions. Stability is one reason often discussed on this newsgroup. I won't say anything more about this reason, except to note it is one reason. Additionally, there are costs associated with changing versions other than the basic fees paid to SolidWorks. For a large company, changing versions requires much coordination, training, upgrade labor, etc. Such companies don't necessarily choose to go through the whole process once a year. They choose to minimize the time spent on upgrades in order to improve their efficiency and minimize their overall cost, despite paying all of their maintenance fees to SolidWorks. I am familiar with several large companies (not necessarily using SolidWorks) that limit the introduction of new versions for this very reason. Often, they skip some releases because the new releases come out so frequently.
I believe that jss87 is correct when he wrote "Imagine what a company could do working with it's own files, not someone elses'". SolidWorks should be able to save their their basic geometric constructs in slightly older version files with only minimal effort. I would venture to guess that each new release of SolidWorks does not involve the complete re-definition of the file formats. For the record, I would only expect SolidWorks to support one or two years of older SolidWorks versions.
--

- John

John Eric Voltin
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John,
I agree that it should be very easy to do some prismatic parts. Many would only require transposing the instructions. In fact, all you would need are the instructions in some cases. SW 95 didn't store any hard geometry in the part file. The files were really small too. Took longer to load though.
The place you would run into problems with prismatic parts are things like feature patterns. For instance SW2004 can't do true 3D patterns along a 3D curve. 2005 & 2006 can. How do you account for this ??
"Making unsupported features dumb solids" kind of rolls off the tounge real easy. Not so easy when you really think about it. If the base features of a shape are two or three complex lofts or sweeps, shelled with a ton of bosses ribs and other internal stuff, most of it will be orphaned if the lofts are dumb. Whether they're left dangling or broken, allot of work will be necessary on the recieving end to fix it up. How many time can a model make the round trip between the newer/older-older/newer cycle before the only real features left are a couple of holes ??
I really don't think it can be implemented in a way that has any real value
Regards
Mark

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I assume your final statement of " I really don't think it can be implemented in a way that has any real value." is because of the current ability to export SolidWorks files as dumb solids via parasolid, IGES, etc. That seems to be a reasonable assessment, particularly when you consider all of the other issues that can be addressed by SolidWorks.
I'm curious, do you completely discount the theory held by some CAD users that backward compatibility is not supported because companies like SolidWorks wish to "encourage" users to always use the newest version? Personally, I have heard many people express their concerns about this issue and I have wondered about the validity of their arguments. To be honest, I don't have a strong opinion either way on the topic due to my uncertainties about the big picture.
--

- John

John Eric Voltin
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I haven't post anything in this group for a while.... But I love when this subject comes up. It's so much fun reading everyone's ignorant responses. The irony here is, I know I'm sounding ignorant myself but I can't hold back from this subject without sounding impolite or sarcastic....
Yes guys, it's true. Solidworks and other companies have created a giant money generating conspiracy. Together, they make you believe they can just quickly generate some simple code that allows you to save to a previous version. As a matter of fact, it would be so easy to do they would rather just make you pay for upgrading to the newer software. (Am I sounding sarcastic here... I hope so!)
Apparently nobody understands natural order, programming, or even logic for that matter. What makes people think Solidworks can just have 1 guy hand over the code to make backwards compatibility happen? The truth is that it would be way too complex and big of a problem from a programming/database standpoint to be able just to be readily available at the same cost the user. I have to believe this would cost a fortune in development only to meet it's demise when people won't pay $$$ for the ability to use it. THIS DOES NOT COME FOR FREE PEOPLE!
When you think about all the problems and money it would take to accomplish such a task.... doesn't it just make sense to pay for the upgrade? Apparently some people just don't understand this.
By the way.... I keep putting my DVD movie into my CD player I bought 12 years ago and it doesn't work. Why can't they just make the DVD backwards compatible???? GIVE ME A BREAK!!
Sorry for sounding rude... I meant to sound realistic. Don Van Zile
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
If someone chose to do it, it is certainly doable. Barenboym had developed something that worked on limited feature types, but it worked.
Look at what SW can do with native ProE files. If it can be done from ProE to SW it can certainly be done much more easily from SW2005 to SW2001+. Any features that don't have an equivalent in an old version are either brought forward as a dumb solid or left out, same as the ProE conversion. Something is better than noting.
The question then becomes "why". It probably wouldn't be a big money maker, because the people who are hanging out on old versions are probably doing it to avoid spending money in the first place.
I honestly don't believe it is a technical issue. It's a business issue.
Matt
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Matt,
You've correctly pointed out that there would be very real limits. Solidworks doesn't really do much with Pro files based on complex shapes. Your choices are single body, or a mess. The mess isn't worth trying to clean up. So much for dumb or incomplete features. It does work on prismatic parts "provided" the person doing the modeling (in pro) used straight forward construction methods. I've seen Pro models where the guy used variable section sweeps to construct countersinks.
Something is better than nothing is only "your" perspective. There will be legions of users who will piss and moan because of the limitations. They'll complain loudly about another half baked Solidworks feature. It's human nature, not worth the hassle.
Mark

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
"Your choices are single body, . . ."
Here's my take on this:
1) It's parasolids in there somewhere.
2) If we can take in pro files as a dumb solid, at least give us the option to take in a "frozen" parasolid from future SolidWorks versions. Predicated on compatible parasolid versions maybe (not something I can really see).
3) Given a drawing, at least let the editor open a future version in view mode, or perhaps even a variant of "detached drawings". I know the viewer is available, but that's not my point.
Full backwards compatibility would be a total CF.
Today I had a model from my vendor in 2005 and could not open it in 2004. OK that makes sense, BUT it would be nice if I could open the model as a "frozen" solid, basically having the editor read the internal parasolid data for me - basically nullifying the need for a dumb solid as the communication vehicle between solidworks versons. I think that this could even extend into an assembly being able to take in future data as frozen.
I think that being able to open a file as frozen and use the geometry as needed is not too much to ask for. Full parametric compatibility is probably a very tall order and strewn with roadblocks.
I hate to even mention this (surely opening the floodgates of idiocy) but what about having a limited direct manipulation mode when opening a future file in an older version?
Later,
SMA
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
And then you have NX which can take a totally dumb file and treat features in it as if they were parametric in origin, dragging, retrimming, etc. 90% of users use a very simple pallette of features. Those features haven't changed much over time. And from what I understand the code to make them in the older versions remains in the newer versions to enable backward compatibility.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi TOP-
That's what I was thinking. Something is wrong and maybe this is too big a leap. To have history trees and direct co-operate.
But damn what a wish list item.
I expect them (or someone) to come up with a solution to make this sort of big picture stuff happen. I hope that they have a think tank and would not be shocked if there is some sort of body in the company that thinks about this stuff all day. Sort of like an advanced development function. I know that we will likely wait a decade for a major change and perhaps SolidWorks will not be capable of being the "lusted after" CAD of the future. They may just rest on their laurels and get comfy maintaining the status quo.
In any case, the future belongs to the people who can innovate. In CAD and any other business.
Later,
SMA
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I think it was promised at SWW two years ago. If SW does it first just think what it will do to Inventor with all those giveaway seats in circulation.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Mark,
Your observations about the "something is better than nothing" approach make alot of sense. Considering the number of complaints I hear from SolidWorks users, any new functionality that is less than complete will probably lead to as much criticism as praise. Maybe SolidWorks would be better off leaving this topic unaddressed.
--

- John

John Eric Voltin
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@nospam.net says... ...

I think this reaction is kind of severe. It's true that no one likes half baked features, I'm the first to jump on that wagon too, but the translation issue has never been a 100% success. IGES has been half baked for a long, long time, but people still use it even though there are better alternatives. The ProE translator is far from perfect too, but if I have to rebuild a ProE part, I'd rather start with maybe 80% of the sketches than nothing.
I suppose if you're so down on things that don't work perfectly, you've never used FeatureWorks. FeatureWorks can strip out the features it can recognize and leave the rest as a solid imported blob with parametric features around it. I'm not suggesting that anyone should use FW to translate new SW files, but I don't see why it wouldn't be technically feasible for a program that looks at the instructions to make the features to recreate them rather than looking at the geometry itself, and use the parasolid data for features that don't exist in the older version. You'd wind up with a blob that represents the shape feature, and paremetrics for other things that existed in that version.
http:\\baren-boym.com\ExchWorks14Demo.zip
Link is still active after a couple years. The help file is in Russian, which, maybe I'm wrong about this, but isn't really helpful. Anyway, Barenboym started the project and seems to have dropped it for some reason. I know we traded a couple of emails, and the intention was to go forward with more feature types. This version I think did extrudes, revolves and simple fillets.
Technically difficult? Probably. Impossible? No. Financially feasible? Probably not.
Financially for SW it would be a big loser because obviously fewer people upgrade if they're not forced. I don't believe SW will ever provide this. A 3rd party provider like Barenboym would be the folks who would have to do it.
There's no way of knowing, but someone might have exerted some pressure to stop that project too... You can get to Framingham from Concord in about 30 minutes.
I don't think it will ever become a reality, but I think it's definitely doable.
Matt
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Despite the postings from a few individuals that "know" the truth about the technical difficulties associated with this issue (their postings are unsubstantiated, coincidentally), Matt makes a very important point.
If anyone can offer more than just claims to support the concept that its technically not feasible to support older versions, please provide your information. I am certain many people would be interested in learning about this.
Its interesting to observe the accusations of ignorance directed at users asking relevant questions and discussing those issues. Is such behavior the result of arrogance, impatience with other users, or some other cause?
--

- John

John Eric Voltin
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
John,

the
Oooooooooooooo,,,,, it's a conspiracy... gimme a break.
I haven't called anyone ignorant, all I've asked you to do is really think about it. Another example. SW has changed it's surfacing algorithms in every releas since 2001+. I have several product models that were done in 2001+ that I can't even bring "FORWARD". Why ? because the surfaces change shape, some have failed features asa result, and "ALL" of them no longer match the very expensive production injection molds.
Can you imagine trying to go backwards to a version that didn't support things like local curvature and tangency control. The resulting mess would be usless.
I have a feeling that maybe you just do prismatic mechanical stuff. Nothing wrong with that, but it doesn't give you a very good view of the larger picture.
Regards
Mark
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

What are you talking about? Conspiracy?

Coincidentally, the whole purpose of this thread was to get people thinking about it and commenting accordingly. I'm sure we all agree that's the intended purpose.
I have seen ample examples of SolidWorks files that can't be brought forward without user intervention. Sometimes loading older files results in distinct errors and in other cases there are slight differences in the geometry. Most people that I know view this as a limitation/shortcoming of SolidWorks, but we deal with it and some of these situations are unavoidable (i.e. not a reason to criticize SolidWorks).

Yes, I can imagine going backward to a version that didn't support things like local curvature and tangency control. This problem is dealt with routinely when we export files as dumb solids in any number of older IGES, parasolid, STEP, or ACIS versions. Reading through the various postings in this thread, a variety of people have imagined it and offered their thoughts about how SolidWorks might deal with such situations.

That would be a bad assumption, but that's another story...
Of course, I do work with alot of prismatic shapes (as many people do) and the ability to save them as older versions of SolidWorks files would be useful for a variety of reasons.

Thanks for your interesting postings on this topic.
--

- John

John Eric Voltin
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I just ran a test using the ExchangeWorks v.1.4 conversion utility that Baren-Boym was developing. I re-confirmed my earlier findings that even the simplest geometry doesn't convert accurately.
I modeled a simple 1.0" diameter cylinder and saved it as a 3XF format file using ExchangeWorks. I then imported the 3XF file back into SolidWorks using ExchangeWorks. A quick examination of the dimensions showed that the diameter had been changed to 0.99999995". Not a significant difference, but certainly nothing to ignore.
Autodesk attempted to address this type of issue with their "proxy object" approach. It would be kind to say it doesn't work very well.
While backwards translation would help me in some cases, I want it to be robust, and allow for round-tripping without data loss. What many users have suggested in this post would alter the file to such an extent that design intent and future editing would be negatively compromised.
John

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.