Re: Reading and writing older versions
- From: "Mark Mossberg" <Poundsandspammers@xxxxxxxxxx>
- Date: Wed, 10 Aug 2005 05:43:38 GMT
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
"John Eric Voltin" <jevoltin@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:l3eKe.151267$X76.100866@xxxxxxxxxxxxxxxxxxxxxxx
> 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
> Mechanical Engineer
> Agile Technology
> 512-633-0394
>
> "MM" <markm@xxxxxxxxxx> wrote in message
> news:rYbKe.1135$dk5.756@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > 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
> >
> >
> >
> > "jss87" <jss87@xxxxxxxxxxxxx> wrote in message
> > news:MdbKe.2668$Ub1.1560@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >> 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
> >>
> >>
> >> "Cliff" <Clhuprich@xxxxxxx> wrote in message
> >> news:1kcif1526h45baj196h70ifr0u27pci438@xxxxxxxxxx
> >> > On 9 Aug 2005 15:37:24 -0700, "ADS" <asked@xxxxxxxxxxxxxxxxxxxx>
> >> > wrote:
> >> >
> >> >>This is a major item of discussion that people want.
> >> >
> >> > It would be downright silly to ask for.
> >> > The ONLY way such could work would be no changes to
> >> > the part database structure to support new features of to fix
> >> > old bugs. Static.
> >> > Even migrating old part database structures forwards is
> >> > a wonder at times but must be done in some way.
> >> > Never expect more than one release level on that ...
> >> > --
> >> > Cliff
> >>
> >>
> >
> >
> >
>
>
>
.
- Follow-Ups:
- Re: Reading and writing older versions
- From: John Eric Voltin
- Re: Reading and writing older versions
- References:
- Reading and writing older versions
- From: jss87
- Re: Reading and writing older versions
- From: ADS
- Re: Reading and writing older versions
- From: Cliff
- Re: Reading and writing older versions
- From: jss87
- Re: Reading and writing older versions
- From: MM
- Re: Reading and writing older versions
- From: John Eric Voltin
- Reading and writing older versions
- Prev by Date: Re: the logic behind the feature manager tree display order
- Next by Date: Re: the logic behind the feature manager tree display order
- Previous by thread: Re: Reading and writing older versions
- Next by thread: Re: Reading and writing older versions
- Index(es):
Relevant Pages
|
Loading