Projects and 'unresolved links'

[Wogz]

Please excuse my fustration, but I really really really don't get it..



This is two parts..



I have many parts, built into an assembly, yet everytime I open the assy file, many paths are 'unresolved'? I click and point EVERYTIME and it never remebers (although it is alwasy pointing in the right directory..). It remebers the 'parts' but never the 'nuts and bolts'. Some of these 'nuts and bolts' are genuine library parts, some are 'factory' parts, and some are just parts saved in our 'library' directory on the server.



So, that's the first question.. What defines a part as a 'library part' as opposed to just a 'part' part?



In the hopes of resolving this, I have added just about every directory and sub-directory to my 'project', in most cases, the same path to both the 'workgroup' and 'library' headings. This seems to work for one assembly, but the next one, I have to go through the whole thing again..



So, how should a 'project' be set up to grab parts from a few loactions, and library parts form another few locations? Should library parts be defined as something? Should general parts be defined as something else?



I'm an old hand with MDT, And attaching parts to an assembly was easy: literally 'point and click' in some instances. Even when a bit of maintenance (directory restructoring) was needed.



Learning completely new strategies, and methods is really getting to me. I'm starting to feel like an idiot.

[Anonymous]

I agree it can be extremely frustrating when things start going wrong. Best bet is to
read up on some of the stuff posted. Click on the Point A icon in Inventor and then
Articles and read the Inventor File Management 101~103 stuff. There is also some stuff on
Seans site www.sdotson.com, and Drews www.mymcad.com.

One thing that goofed me up in the beginning was I was giving the library a different name
with each new project. The library's should consistently be the same name. My fix was to
set up a project that just had the library files , and then use it as a included project
in all new projects. This brings in the library files with the same name and path to each
project.

That said personally I am working towards removing library files from my work. I feel a
lot of people don't really need them, and the small amount of benefits for most are easily
eaten up with problems like these. Just my personal opinion 8^)

--
Kent
Member of the Autodesk Discussion Forum Moderator Program


"Wogz" wrote in message news:f123eb8.-1@WebX.maYIadrTaRb...
> Please excuse my fustration, but I really really really don't get it..
>
> This is two parts..
>
> I have many parts, built into an assembly, yet everytime I open the assy file, many
paths are 'unresolved'? I click and point EVERYTIME and it never remebers (although it is
alwasy pointing in the right directory..). It remebers the 'parts' but never the 'nuts and
bolts'. Some of these 'nuts and bolts' are genuine library parts, some are 'factory'
parts, and some are just parts saved in our 'library' directory on the server.
>
> So, that's the first question.. What defines a part as a 'library part' as opposed to
just a 'part' part?
>
> In the hopes of resolving this, I have added just about every directory and
sub-directory to my 'project', in most cases, the same path to both the 'workgroup' and
'library' headings. This seems to work for one assembly, but the next one, I have to go
through the whole thing again..
>
> So, how should a 'project' be set up to grab parts from a few loactions, and library
parts form another few locations? Should library parts be defined as something? Should
general parts be defined as something else?
>
> I'm an old hand with MDT, And attaching parts to an assembly was easy: literally 'point
and click' in some instances. Even when a bit of maintenance (directory restructoring) was
needed.
>
> Learning completely new strategies, and methods is really getting to me. I'm starting to
feel like an idiot.

[pquenzi]

I know your frustration. Your letter struck a nerve.
Kent, I take exception to your answer. When I started to use Inventor, I did just as you suggested, read all I could on "Projects". Every time I did, I came away feeling like a complete idiot. It is described in such a generalized manner using such convoluted terms as to be almost meaningless to a new user. I'm sure what they say is accurate and would make perfect sense once you figured out how to actually use "Projects", but to go in the other direction and use the insturctions to learn how to use "Projects" is another matter enitrely. Realizing I needed help, I called my Autodesk retailer. They told me to take their course on Inventor. I told them I felt I was doing okay with Inventor and just needed help on "Projects". They essentially said. Can't help, take the course. I did and spent an awful lot of money on the course. After the first morning I realized I knew as much if not more than the instrutor and asked for the rest of my money back. He said they hadn't gotten to the good stuff yet and they would make it well worthwhile for me to finish the course. Turns out I learned very little from them and when it came time for "Projects", they ran out of time and spent 3 minutes on the subject. With that off my chest, everything I learned about "Projects" has been by trial and error.
Wogz, if you want to email me direct, I KNOW I can describe how to use projuects in PLAIN ENGLISH better than what is done in Point A etc. I,m no expert, but what I'm doing is working.
Kent, this is an invitation to you guys too. Maybe with my attempts at explaining it in English and your corrections on procedure, we could come up with a simple one page insturction you could post on a web site to handle such questions.
Best regards,
Phil Quenzi
pquenzi@up.net

Kent,

[Anonymous]

I couldn't agree more, we do need a plain English
approach maybe with wooden blocks representing folders libraries files etc. I
know its not that complicated but I have trouble putting the words used to the
parts, and if it was that simple someone would have a good guide for us
beginners. I appreciate that the experts understand but passing on that in an
easy to understand way is the crux of it. Flow diagram ? Thirty years ago a uni
bloke taught us basics in electronics liking it to plumbing, you can laugh but
if its not connected the juice don't flow and when I started to repair machines
for Joe public, fifty percent of faults were electronic, with out diagrams I was
rarely stumped. We need someone? something radical but basic? Most I have
learned is trial and error like the rest of us. No disrespect implied
Kent.

--
Laurence,
  
Power is nothing without
Control
---
        

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

"pquenzi" <pquenzi@up.net>
wrote in message
href="news:f123eb8.1@WebX.maYIadrTaRb">news:f123eb8.1@WebX.maYIadrTaRb...

I
know your frustration. Your letter struck a nerve.
Kent, I take exception
to your answer. When I started to use Inventor, I did just as you suggested,
read all I could on "Projects". Every time I did, I came away feeling like a
complete idiot. It is described in such a generalized manner using such
convoluted terms as to be almost meaningless to a new user. I'm sure what they
say is accurate and would make perfect sense once you figured out how to
actually use "Projects", but to go in the other direction and use the
insturctions to learn how to use "Projects" is another matter enitrely.
Realizing I needed help, I called my Autodesk retailer. They told me to take
their course on Inventor. I told them I felt I was doing okay with Inventor
and just needed help on "Projects". They essentially said. Can't help, take
the course. I did and spent an awful lot of money on the course. After the
first morning I realized I knew as much if not more than the instrutor and
asked for the rest of my money back. He said they hadn't gotten to the good
stuff yet and they would make it well worthwhile for me to finish the course.
Turns out I learned very little from them and when it came time for
"Projects", they ran out of time and spent 3 minutes on the subject. With that
off my chest, everything I learned about "Projects" has been by trial and
error.
Wogz, if you want to email me direct, I KNOW I can describe how to
use projuects in PLAIN ENGLISH better than what is done in Point A etc. I,m no
expert, but what I'm doing is working.
Kent, this is an invitation to you
guys too. Maybe with my attempts at explaining it in English and your
corrections on procedure, we could come up with a simple one page insturction
you could post on a web site to handle such questions.
Best regards,

Phil Quenzi
pquenzi@up.net

Kent,

[Anonymous]

Non taken Laurence. I freely admit to still occasionally running into
things project path related that I just don't understand why they are
happening. It is getting rarer that it happens, but it still does.

--
Kent Keller
Member of the Autodesk Discussion Forum Moderator Program

http://www.MyMcad.com/KWiK/Mcad.htm

"Laurence Yeandle" wrote in message

No disrespect implied Kent.

[pquenzi]

Kent,
What's your direct email address. I'd like to have you review this write up before it goes any further.
Phil Quenzi
pquenzi@up.net

[Anonymous]

Phil

you can send it to kent@strobedata.com.

--
Kent
Member of the Autodesk Discussion Forum Moderator Program


"pquenzi" wrote in message news:f123eb8.9@WebX.maYIadrTaRb...
> Kent,
> What's your direct email address. I'd like to have you review this write up before it
goes any further.
> Phil Quenzi
> pquenzi@up.net

[Anonymous]

Phil

If you can explain projects in a one page or so document I will be happy to
add it to my site. Unfortunately to be honest I am not as knowledgeable on
Projects as I would like to be. But the trouble I see with projects is there
is so many different sizes of organizations and each with different data
structures or needs, that it becomes a little more complicated explaining
what is good for each.

For me I am leaning towards getting rid of library paths, but that wouldn't
be right for everyone, and I am not even positive it is right for me to be
honest.

Actually probably the best document on the subject I have seen is a pretty
large one that comes on the R6 CD. I hesitated to mention it because I
don't know the legalities concerning publicly posting it.
--
Kent Keller
Member of the Autodesk Discussion Forum Moderator Program

http://www.MyMcad.com/KWiK/Mcad.htm

"pquenzi" wrote in message
news:f123eb8.1@WebX.maYIadrTaRb...

> Kent, this is an invitation to you guys too. Maybe with my attempts at
explaining it in English and your corrections on procedure, we could come up
with a simple one page insturction you could post on a web site to handle
such questions.
> Best regards,
> Phil Quenzi
> pquenzi@up.net
> Kent,
>

[Anonymous]

Can't come up with a single page, but my paper on projects will be available
after Autodesk University. I'll see what I can do about posting it
earlier..... The doc on the CD is copyrighted, but should be available soon as
well. I'll check into the legalities of posting it soon.

Dennis

Kent Keller wrote:

> Phil
>
> If you can explain projects in a one page or so document I will be happy to
> add it to my site. Unfortunately to be honest I am not as knowledgeable on
> Projects as I would like to be. But the trouble I see with projects is there
> is so many different sizes of organizations and each with different data
> structures or needs, that it becomes a little more complicated explaining
> what is good for each.
>
> For me I am leaning towards getting rid of library paths, but that wouldn't
> be right for everyone, and I am not even positive it is right for me to be
> honest.
>
> Actually probably the best document on the subject I have seen is a pretty
> large one that comes on the R6 CD. I hesitated to mention it because I
> don't know the legalities concerning publicly posting it.
> --
> Kent Keller
> Member of the Autodesk Discussion Forum Moderator Program
>
> http://www.MyMcad.com/KWiK/Mcad.htm
>
> "pquenzi" wrote in message
> news:f123eb8.1@WebX.maYIadrTaRb...
>
> > Kent, this is an invitation to you guys too. Maybe with my attempts at
> explaining it in English and your corrections on procedure, we could come up
> with a simple one page insturction you could post on a web site to handle
> such questions.
> > Best regards,
> > Phil Quenzi
> > pquenzi@up.net
> > Kent,
> >

--
Dennis Jeffrey
CAD Associates - Fort Wayne
Autodesk ASC
(260-432-9695 x 221

[pquenzi]

Kent,
I have no argument with what you say, but some of the basic stuff like what exactly do you include in a project is not at all clear, or what do you put in "local" versus "workgoup" versus "workspace" etc.

I think I can explain that nicely by using a real world example and walking through it.

When the tutorials use examples they might talk about a "widget" or something. By definition you don't know what a "widget" is or what it is composed of, so how can you get a feel for how to set up a project for it?

If you use a real world example such as a building, bridge, telephone, automobile, tractor, etc. it is something that people can relate to. I design specialized mobile equipment, and would describe how I'd set up the project for a new machine and some of the mistakes I've made along the way. You, or others in your group could make improvements to what I suggest.

I know there are all sorts of working enivronments out there and wouldn't pretend to have answers for those individual needs, but I think a simple, brief explanation of the basics using a real world example would be ueful for new users.

I'll try to write something up and send it to you. It may take a day or two.

Phil

[Anonymous]

Actually, Drew has posted it to http://www.mymcad.com Tip 9802!

Dennis

Dennis Jeffrey wrote:

> Can't come up with a single page, but my paper on projects will be available
> after Autodesk University. I'll see what I can do about posting it
> earlier..... The doc on the CD is copyrighted, but should be available soon as
> well. I'll check into the legalities of posting it soon.
>
> Dennis
>
> Kent Keller wrote:
>
> > Phil
> >
> > If you can explain projects in a one page or so document I will be happy to
> > add it to my site. Unfortunately to be honest I am not as knowledgeable on
> > Projects as I would like to be. But the trouble I see with projects is there
> > is so many different sizes of organizations and each with different data
> > structures or needs, that it becomes a little more complicated explaining
> > what is good for each.
> >
> > For me I am leaning towards getting rid of library paths, but that wouldn't
> > be right for everyone, and I am not even positive it is right for me to be
> > honest.
> >
> > Actually probably the best document on the subject I have seen is a pretty
> > large one that comes on the R6 CD. I hesitated to mention it because I
> > don't know the legalities concerning publicly posting it.
> > --
> > Kent Keller
> > Member of the Autodesk Discussion Forum Moderator Program
> >
> > http://www.MyMcad.com/KWiK/Mcad.htm
> >
> > "pquenzi" wrote in message
> > news:f123eb8.1@WebX.maYIadrTaRb...
> >
> > > Kent, this is an invitation to you guys too. Maybe with my attempts at
> > explaining it in English and your corrections on procedure, we could come up
> > with a simple one page insturction you could post on a web site to handle
> > such questions.
> > > Best regards,
> > > Phil Quenzi
> > > pquenzi@up.net
> > > Kent,
> > >
>
> --
> Dennis Jeffrey
> CAD Associates - Fort Wayne
> Autodesk ASC
> (260-432-9695 x 221

[Anonymous]

IV 6.0 I recon does smooth things out better OK if
your on 6.0    If you messed with 5.3 you needed several paths to
the same directory, 6.0 needs just one for your files I think.

--
Laurence,
  
Power is nothing without
Control
---
        

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

"pquenzi" <pquenzi@up.net>
wrote in message
href="news:f123eb8.3@WebX.maYIadrTaRb">news:f123eb8.3@WebX.maYIadrTaRb...

Kent,

I have no argument with what you say, but some of the basic stuff like
what exactly do you include in a project is not at all clear, or what do you
put in "local" versus "workgoup" versus "workspace" etc.

I think I can explain that nicely by using a real world example and walking
through it.

When the tutorials use examples they might talk about a "widget" or
something. By definition you don't know what a "widget" is or what it is
composed of, so how can you get a feel for how to set up a project for it?

If you use a real world example such as a building, bridge, telephone,
automobile, tractor, etc. it is something that people can relate to. I design
specialized mobile equipment, and would describe how I'd set up the project
for a new machine and some of the mistakes I've made along the way. You, or
others in your group could make improvements to what I suggest.

I know there are all sorts of working enivronments out there and wouldn't
pretend to have answers for those individual needs, but I think a simple,
brief explanation of the basics using a real world example would be ueful for
new users.

I'll try to write something up and send it to you. It may take a day or
two.

Phil