Topic: Using Xref's in automation

[MickD]

Hi All,

Has/Dose anyone use a lot of xref's as part of their automation process?

Are there any performance issues etc I would need to consider if I was to go this way.

In inventor basically every part is an xref, this can be hard to deal with at first but once you get the hang of it it becomes quite handy when you need to update a part that is used multiple times throughout the model. With a bit of automated house keeping I think this could work quite well.

tia,
Mick.

[Kerry]

I only use xrefs for setout geometry and assemblies of some size.

Haven't considered using xrefs for individual component parts ... that would be a lot of xrefs !!

[Glenn R]

... if I was to go this way.

Which way is that? Are you talking about inside inventor, autocad or what? Mick, if you're just generally asking whether using many xrefs raises perfomance issues, I think you already know the answer to that...it depends on how many, file size etc.

However, having said that, I've been in companies where civil drgs in particular, were primarily made up of xrefs (upwards of 20-30) if that helps. Personally, I like using a lot of xrefs.

[jmaeding]

we use over 30 on some projects, with no issues - so long as you do not "attach" them, but make them as "overlays".
If you daisy chain them by using attachments, you will one day find some xref that has some issue, and its hard to troubleshoot things.
I believe it has a few bugs with handling duplicate block names in nested files, and linetypes too.
I sometimes set all linetypes to names in active drawing, instead of like "xref1|hidden"...
Doing that lets certain xrefs resolve, and I can then deal with things.
Architects use attachments all the time, and which files would you guess have the most issues?
We immediately bind them to compress to one file, and keep the originals though in case things get updated.
Also, there is no API access for changing an attachment to overlay.  Many people want that feature.

[MickD]

Gents,
thanks for your replies.
Glenn, yes this is for acad.

Using Inventor as an example, every part (ie. single part/solid object) resides in its own file, these parts can then be used in an assembly or may be used in other assemblies like an 'off the shelf' item if you like.

You would normally build your assembly from 1 or more parts and these assemblies could then be used in another larger assembly to build larger objects.

How we do it here is we have a file structure of -

Job Folder-
    major assemblies
    minor assemblies
    parts

So for structural steel we would have our main model in the major assemblies file, the individual parts in parts and beam members in minor assemblies. As you could imagine there can be quite a lot of parts and assemblies but I guess the parts folder would be the driver here as all assemblies derive from those.
You may have many instances of a part in an assembly and many minor assemblies in a major one.

Hope that makes some sense.

The best part is in acad you can edit an xref in place using the major model geometry as a reference which is not possible in Inventor without using adaptivity etc.

Obviously there would need to be a few tools to be written to manage this in a seamless manner but it would be quite logical and aid greatly in things like BOM's and part numbering etc.

[Bryco]

I can't see an xref being better than a block, since you must already have a nice pull down menu.
It would be interesting to find out if an xref works better for you.

[MickD]

hmmm, didn't think about blocks, I guess it's basically the same process and benefits as an xref but contained in the one file.
Have to ponder this further, cheers.

[Bryco]

Every tube, channel, pipe,I-beam etc section in my pull down is a block, works well for me.
 If you made all these xrefs, you would definately want to make them uneditable.

[MickD]

That's the thing though, I want to edit them.

Say I have a cleat that I wish to use many times throughout the model, I can create it as it's own block/xref and distribute it around as required. If I need a very similar cleat I would need to save an instance as a new type, edit it and then copy around as required.
If I create a beam part I may need to cut or drill it as the model develops but it will initially be a plain block which I would probably create after creating the part in code.

If for some reason a part file needs mod's that will affect all instances I simply edit the block/xref definition in place and the change propogates through the model, this is very handy!

I haven't really done that much work with blocks or xref's other than day to day typical uses but with either I would need to drill down to the part in question to make the mod's.

[jmaeding]

In Civil, we split things into files for organization, stability, and ability for different items to be worked on at the same time.
Given the quirks I have seen with blocks (and xrefs), its better to separate things by file, then xref together.
If issues happen, at least its not one big blob you have to rip apart to isolate the issue.
You should think about relative paths or full paths a bit.  I like relative paths for users who get what they mean.
Ones that do not will copy some file to another folder and wonder why the xrefs do not show right.

At a minimum, you should make or get a routine that attaches xrefs with the defaults you want.  I control the layer, alias (name that shows in xref dialog), insert point, scale, rot, and attach vs overlay prop.

Also keep in mind that with separate files, you need a way to clean up old xrefs.  You have to be able to ask "where is this file xreffed?".
That is a tough one, but doc management progs and programs like Everest http://www.altimasoftware.com/ can help.
Its a pain if users do not keep things squeeky and named nicely.

[MP]

In addition to what's already been said ...

I use xrefs extensively, models created by hand as well as created/updated/revised etc. strictly thru code. I use ODBX a lot.

RE: xref "attach" and the notion that it's somehow evil ... I use attach with cause: for example I'll create a wrapper drawing for each type of production drawing, it's sole purpose to attach all the models typically referenced by said production drawings in a run (each xref on it's own layer, this is important for layer mgmt down the road), so that I only have to directly reference one drawing AND in the event that some change requires the addition of more models after hundreds of production drawings have been cut it's a no brainer: update the wrapper drawing and *poof*, all production drawings updated. In all other cases "overlay" is strictly enforced.

[Draftek]

I use them quite a bit as in:

I use blocks for 'part' replacement features in individual detail drawings
and
xref's for sub-assemblies of individual detail drawings for a detail replacment feature.

[dgorsman]

I could see a potential problem with layer counts (and possibly other XREF dependant objects such as text styles, annotation scales) - 50 different parts, with only 10 layers apiece, thats 500 layers right there.  If copies of parts require their own unique name it gets even worse.  For manually selecting layers, styles, or other settings it could be difficult for the user to pinpoint what they need, while automation will have to chew through more and more entries when iterating the entire collection.

[MickD]

As far as management goes, it would be pretty much handled behind the scenes with code, as long as they don't play with the folder structure the user will not be any the wiser.
Pretty much all xref'd items will be 3d solids so line types et al won't be a real issue.

Layers - only one layer per xref as there will only be one part per file.

Copies - parts would be a 'save as' and layer name and prop's can be changed on the fly if req'd.

A lot of the problems caused by xref's will not be that apparent to the user as it will be handled by the application, in fact the user doesn't even need to know they are xref's but obviously will need to know that folder and file maintenance is handled by the app or else there would be problems.

Blocks on the other hand can be handled all within the main file but obviously this file may suffer in performance from size eventually whereas I'm not sure whether xref's will have the same performance efffect??

[Glenn R]

Over recent years, I've become a devoted fan of PROJECTNAME. I've implemented for several companies a system which uses XML files on a server that contain all project information eg. name, description, REFERENCE PATHS, etc.

Enumerate projects and do what you need as well as adding each project's NAME and it's REFERENCE PATHS to AutoCAD's list of PROJECTNAME variables. Then you attach any xrefs WITHOUT paths from you're standard xref folder for each project (ie the project.xml I mentioned previously).

The enumeratioin and setup is done at startup in either VBA or C#. The file is read in and the projectname re-snotted so you always have a fresh list in acad. This means, that if you have a standard folder structure under each project and a standard naming convention for references, then if you move/copy a drg from one project to another, all you have to do is change that drg's PROJECTNAME variable and it will pick up the references in the new project that are named the same.

I've also written a batch program that opens each drg using ReadDwgFile and depending on GUI options, will optionally change PROJECTNAME and remove hard paths for xrefs and images...so you can bulk migrate fix.