Cory,
I'm trying to understand your response and interpret what you're trying to
tell me. It sounds like you're explaining the need to have an iPart project,
which I do, in order to edit iParts. But it appears you may have
misinterpreted my confusing babble - or I'm misreading your reply. I guess
what I was after was confirmation about the correct implementation of iParts
in the real-world inevitable situation of "Purchase & Alter". I'm mainly
concerned here about when a part must be altered, i.e. features added - to
just one instance. And how to author the iPart that makes alterations easier
for a designer down the road.
Another thing your response brings to mind that I'm not clear on, is the
addition of suppressible features to iPart parents that have already "been
fruitful" or already have offspring. IOW, if I do go back and add a feature
to the standard iPart parent that represents the alteration, and add a
column to suppress that feature in all but the part I am altering, would it
make all the existent children "flip out" or become unresolvable (especially
the one back in the current assembly I'm working on)? It would seem this
approach would lead to new children from the parent with additional features
that the "older children" do not possess at all. I guess it brings to mind a
question about the evolution of a standard ipart family - can standard ipart
families "evolve" in this way - gain features over time? I suppose many of
these things can be determined with a bit of experimentation.
Many Thanks,
Jack
-sorry replied directly earlier.
"Cory McConnell" wrote in message
news:6D35DAD4096BB56FF8CCB27D20ED4FFA@in.WebX.maYIadrTaRb...
> I have a project file set up with my library paths as the workgroup. If I
> need to modify an ipart I switch to this project, and modify or add to my
> iparts. About the only problem I have run into is if I add lines to the
> table at the beginning - the current part loses its place in the table.
> After I finish, I go back to the original project, and reopen the
assembly.
> Unless you changed geometry or deleted geometry in the ipart that you used
> to constrain the ipart your constraints should stay intact.
>
> --
> Cory McConnell
> BJ Pipeline Inspection
> "Jack Brentner" wrote in message
> news:A6EBBCCEE55F4877845DD986C16CEC14@in.WebX.maYIadrTaRb...
> > Hello all,
> >
> > I've now read through every post that has "iPart" in it and I think I
can
> > draw these conclusions, and have the following questions.
> >
> > 1) Standard (as opposed to custom) iParts, once placed, can NOT be
> > modified - Ex. a cross-hole drilled. Please confirm.
> > Q: Separately, can R6 assembly features be applied to a set of
> > components in an assembly if one of these is a std. ipart?
> >
> > 2) If a Standard iPart needs a modification at a later date, and exists
in
> > an assembly, the procedure is:
> > - Open the parent file of the ipart child.
> > - save copy as to the project folder.
> > - close the parent, open the new copy
> > - edit the table and make the desired child the default, close the
> > table.
> > - delete the table that makes it an ipart, save the file.
> > - return to the assembly and Replace Component, the ipart with the
new
> > "non-ipart" component.
> > - make the modification to the new "non-ipart" component.
> > Please confirm this workflow.
> > Q: Are assembly constraints lost in the process?
> >
> > Is there a better way to later modify a placed and constrained instance
of
> a
> > standard iPart?
> > If there exists the possibility of alterations - Ex. add a set screw to
a
> > gear, turn down a flange, add an oil groove, turn the id for a wiper,
> etc. -
> > should the iPart author sit back and ponder this as a driving force to
> make
> > his/her ipart a custom iPart in preference to a standard iPart?
> >
> >
> >
>
>