Looking for quick feedback--Questions on XRef usage within ACAD products

[kathy.oconnell]

Hi all,

We would love to get an idea of how many of you use xrefs in your drawings and to what extent.

What percentage of your drawings have xrefs in them?

And on average, how many xrefs per drawing?

Thank you for your help and feedback!!

Kathy O'Connell
Sr. ACAD Product Manager

[scott.wilcox]

On average, half of our production drawings have XRefs. Counting images as xrefs (which we now do), pretty much all of our production drawings have xrefs. Some offices XRef their title blocks.

Probably looking at 1 to 5 XRefs per drawing, it varies.

[kimlance]

I agree with Scott 1 - 5 Xrefs and yes we also Xref our titleblock in. The only time we don't is it is for a small job. Then it's just get it out the door

[Richard.Kent]

Hi all,

We would love to get an idea of how many of you use xrefs in your drawings and to what extent.

What percentage of your drawings have xrefs in them?

And on average, how many xrefs per drawing?

Thank you for your help and feedback!!

Kathy O'Connell
Sr. ACAD Product Manager


Every drawing starts out life with three xrefs building the title block, logo, and project status. A block is inserted in that holds the attributes for the title block.
In model space there will be three to 5 xrefs from master drawings, walls, equipment, column grid, furniture, cleanroom walls.
100% of drawings will have 3 xrefs, 85% will have 5 or more.

[michael.12445]

Our firm specializes in multi-family housing and we use xrefs heavily. For example, each apartment unit in a building plan is typically an xref, since there will be a separate, larger-scale plan for just that unit. Moreover, clients often want kitchens and bathrooms to be standard from unit to unit, so sometimes these are nested inside the unit plan xrefs. Since all of our projects are multi-story, we also typically xref the next lower level into any given plan, in order to check that everything is aligned. And once a plan is drawn, it gets xref'd into the model space of a plot sheet.

We usually set up our projects such that there is one plot sheet per dwg file. Each of these also has the title block as an xref in paper space.

We also have hundreds of standard details that get xref'd into detail sheets (each sheet has space for 20 details), as well as all the custom details that get drawn for each particular project.

So, on average, it's not unusual for any given drawing to have 20-30 or more xrefs, and it's also not unusual for some of them to be nested.

Now if you're inquiring because the developers are considering improvements to the xref mechanism, let me offer some suggestions:

1. AutoCAD still cannot cope well with drawings containing xrefs that get moved from one disk location to another. Reference Manager is, at best, only a semi-automatic, partial solution that is simply unworkable where nested xrefs were used. Moreover, it requires that drawings on which it operates be saved as the newest dwg file version, which is sometimes unacceptable as well. If, during the process of opening a drawing, when AutoCAD failed to find an xref on the saved path, it could be given a simple substitution, like 'For every instance of "X:\Projects\ProjectName", use "Y:\ArchivedProjects\ProjectName," that would be a big help. And yes, I know about relative versus explicit paths, but that does nothing for the thousands of legacy drawings we have created with (default) explicit paths. (However, a means of automatically and seamlessly changing paths from explicit to relative, including nested xrefs, would help.) A more exotic solution would be to port AutoCAD to Linux and take advantage of that OS's "symbolic link" feature, instead of being hobbled by Windows' lame reliance on drive letters.

2. Editing xrefs in-place is buggy, and can give bizarre results, especially with dimensions (which is another rant, for another time). I always use xopen instead - which pretty much makes in-place editing irrelevant.

3. It's possible to use xclip to make an xref invisible, by defining an xclip boundary that excludes any visible xref geometry. This results in a "mystery object" - the xref is still attached and can interfere with attempts to detach it, ("multiple instances detected"), slow down the drawing, etc., but the only way it can be selected is by non-graphic means, i.e., (ssget "X" '( ( 0 . "insert" ) ( 2 . "xrefname" ) )). There should be a tool like the light bulb at the bottom of the Revit screen that temporarily displays items hidden from a particular view.

4. Particular problems arise when a host drawing has both an instance of an xref that is nested inside another xref, as well as an instance of that xref attached directly to the host drawing. AutoCAD should allow the directly-attached instance to be detached, unloaded, etc., without getting confused by the indirectly-attached instance.

I've seen posts preaching against a lot of what I've described here as poor practice (i.e., nesting xrefs, explicit paths), but I cannot reasonably expect our staff - which in busy times often has many interns and new graduates - to begin to be able to tiptoe around all the subtle gotchas. These things happen more often, more easily, and more innocently than we'd like to think. AutoCAD can and should be made much more fault-tolerant when it comes to xrefs, so I hope my comments will have some effect.

[RobertB]

We are an electrical engineering firm, so we live and breathe with XRefs.

100% of our sheet drawings have XRefs, at the very least the titleblock, logo, and PE Stamp. Most sheet drawings XRef a working drawing which where the real XRef structure is located.

Working drawings will XRef the base drawing(s) and possibly 3D models. Where we have 3D models, those drawings will overlay the base 3D model(s) and 2D plans. We would be close to 100% of working drawings having XRefs.

Our working drawings can have 5-15 XRefs. Some projects have even more XRefs.

We have developed an in-house system for specifying the types of XRefs attached to drawings and how those XRefs are to display. This system has greatly reduced the amount of time spent dealing with updates to the client's/consultant's drawings and made plotting results more reliable. Sheet drawings automatically import the layer settings from the working drawings.

[irneb]

I'd say 90% of your TB's are XRefs (also only the "small" jobs don't). Then the model varies quite a lot, between 0 to 20 XRefs - some nested (most not).

[ccowgill]

I would say 90 - 95% have xrefs, and on average 3 - 4 xrefs per drawing. If you include images as xrefs, I would say pretty close to 100% have xrefs.

[Mamma Jamma]

We use xrefs for all of our layout drawings. We can have anywhere from 1 to many, depending on the job/client requirements, but usually less than 10.
We don't reference in our titleblock.
We don't use xrefs for anything that is strictly diagramatic (P&IDs, wiring diagrams, etc), nor do we use them for sketches in which we're trying to figure out how stuff's going to fit -what size we need to make the building for the lines we're laying out.
We've been using nested xrefs for years, but are now moving to overlays and relative paths as we get new jobs.

[cadtag]

Every job here (civil mostly) uses Xrefs -- typically from 1 to 4 xref files are used to create each sheet in the project.

The two biggest issues I find are that images are attached to xref, and are not overlay-ed - so they keep getting dragged in even when not wanted. An even bigger issue is when objects in the xref have properties assigned by object instead of bylayer. While it's possible to go in and fix the xref so I can control plotting in my drawings, I really don't want to -- those files typically come from elsewhere, and I do NOT want to edit the survey drawings at all. Matter of liability and responsibility.

A better solution for me would be to include a "Force bylayer" switch for xref instances so that the current drawing properties will override the overrides in the xref. Preferably selectable by property, so linetypes, ltscales, color by-object overrides can be over-ridden separately.

[rkmcswain]

Hi all,

What percentage of your drawings have xrefs in them?

And on average, how many xrefs per drawing?



Hi Kathy. 100% of our production drawings include xrefs, anywhere from 2 to 6 on average.

[rkmcswain]

1. AutoCAD still cannot cope well with drawings containing xrefs that get moved from one disk location to another. Reference Manager is, at best, only a semi-automatic, partial solution that is simply unworkable where nested xrefs were used. Moreover, it requires that drawings on which it operates be saved as the newest dwg file version, which is sometimes unacceptable as well. If, during the process of opening a drawing, when AutoCAD failed to find an xref on the saved path, it could be given a simple substitution, like 'For every instance of "X:\Projects\ProjectName", use "Y:\ArchivedProjects\ProjectName," that would be a big help. And yes, I know about relative versus explicit paths, but that does nothing for the thousands of legacy drawings we have created with (default) explicit paths. (However, a means of automatically and seamlessly changing paths from explicit to relative, including nested xrefs, would help.) A more exotic solution would be to port AutoCAD to Linux and take advantage of that OS's "symbolic link" feature, instead of being hobbled by Windows' lame reliance on drive letters.

AutoCAD can only look where it's being told to look. If you attach an xref with a full path, then don't expect AutoCAD to find the reference when it's moved. As for legacy drawings, the relative path option has been part of AutoCAD for at least 10 years - so that isn't really an excuse. Setting the path right on an xref is no different that choosing the correct textstyle or dimstyle before drawing - it's just part of the job.



2. Editing xrefs in-place is buggy, and can give bizarre results, especially with dimensions (which is another rant, for another time). I always use xopen instead - which pretty much makes in-place editing irrelevant.

Totally agree with this. I have seen enough drawings crash or the xref "vanish" when using REFEDIT, that we no longer use this at all. It's just as easy (or maybe easier) to use the XOPEN command and work directly on the reference file.



3. It's possible to use xclip to make an xref invisible, by defining an xclip boundary that excludes any visible xref geometry. This results in a "mystery object" - the xref is still attached and can interfere with attempts to detach it, ("multiple instances detected"), slow down the drawing, etc., but the only way it can be selected is by non-graphic means, i.e., (ssget "X" '( ( 0 . "insert" ) ( 2 . "xrefname" ) )).
Never run in this before. Sounds like a training/management issue, not a technical one.



I've seen posts preaching against a lot of what I've described here as poor practice (i.e., nesting xrefs, explicit paths), but I cannot reasonably expect our staff - which in busy times often has many interns and new graduates - to begin to be able to tiptoe around all the subtle gotchas. These things happen more often, more easily, and more innocently than we'd like to think. AutoCAD can and should be made much more fault-tolerant when it comes to xrefs, so I hope my comments will have some effect.

Everybody is busy. We don't "reasonably expect" it either, we demand it. All of these things are no different than knowing what drawing to open, knowing what layer to choose, knowing what printer to choose, etc. Especially in these times, AutoCAD operators should be striving to do it right, or risk being replaced. There are plenty of qualified CAD operators out there that would gladly take the position and do it right.

[irneb]

3. It's possible to use xclip to make an xref invisible, by defining an xclip boundary that excludes any visible xref geometry. This results in a "mystery object" - the xref is still attached and can interfere with attempts to detach it, ("multiple instances detected"), slow down the drawing, etc., but the only way it can be selected is by non-graphic means, i.e., (ssget "X" '( ( 0 . "insert" ) ( 2 . "xrefname" ) )). There should be a tool like the light bulb at the bottom of the Revit screen that temporarily displays items hidden from a particular view.True, but it's also possible to do this with a normal block. For that matter, it's possible to explode dims :roll:. It's simply an ID-10-T error ... or as I like to call it Faulty-Chair-Keyboard connection :mrgreen:. Although you could turn XClips off: type XCLIP, select everything by typing ALL, and type OFF to turn the clipping off. After which you can turn it back on with the same procedure.

Xrefs are definitely not perfect, there's much room for improvement. But so to nearly everything in all programs (not just ACad). It's not a reason for not using them.

XRefs are analogous to any other program's feature of Paste as Link or Insert as Embedded. XRefs are here to stay. It's one of (if not the) most time saving feature of ACad (maybe on par with layers). Those not using xrefs (because "they have too many problems") have way too many problems when they need to do the same change 100's of times. The only place where xrefs are not needed is where the geometry only happens once in the entire project. My rule of thumb (I think I've stated it in some thread here as well):

If you find you're using the copy command, array, copy-n-paste, saveas, etc. Ask yourself: "Shouldn't I make a block of this?"
If the answer is "Yes", then ask: "Shouldn't it be an XRef?"Remember an XRef is nothing more (in essence) than a block which automatically redefines itself from another DWG. You'd have made the DWG by WBlock(ing) the block out, then insert browse & yes to redefine in every drawing it was used.

The differences between blocks & xrefs are:

A block can have changeable attributes or dynamic parameters, xrefs can't.
An xref has its own layers, blocks don't.
A block is only specific to one DWG, it may be different in another (even if its name's the same). An xref is the same throughout all DWG's where it's used (even if the reference object has been renamed).
Sending a DWG to external parties need no extras with blocks, but with xrefs you either need to bind them ... or preferably use eTransmit to include them in a ZIP.
There's no such thing as a path to a block. An xref needs to know where it comes from.That said ... I can't believe how many consultants (MEP, Arch, Struct, ID, etc!) I've worked with who don't (or rather won't) use xrefs ... internationally :shock:. We've got endless problems sending our drawings to these "dinosaurs", not so with the guys who're at least in the same decade as last :lol:.

A project I'm working on just now, we have a worldwide engineering consultant firm. They're on 2011 already but still don't have any concept of xrefs. Why did they ever upgrade if they're still using the same features as found in R10?

[rkmcswain]

Xrefs are definitely not perfect, there's much room for improvement.

When you drag+drop a drawing from Explorer to create an xref, I wish it would automatically place the xref at 0,0,0.

[RobertB]

When you drag+drop a drawing from Explorer to create an xref, I wish it would automatically place the xref at 0,0,0.UCS or WCS?
:veryevil:

[rkmcswain]

UCS or WCS?
:veryevil:

We only attach xrefs while in WCS

[irneb]

But it would make sense for UCS though. If the user's in a UCS, then they usually think of 0,0,0 to be that of the UCS (not the WCS). Otherwise they'd have set WCS current wouldn't they? I.e. it should use whatever's current, not overriding the settings the user has specified.

[rkmcswain]

But it would make sense for UCS though. If the user's in a UCS, then they usually think of 0,0,0 to be that of the UCS (not the WCS). Otherwise they'd have set WCS current wouldn't they? I.e. it should use whatever's current, not overriding the settings the user has specified.

There is no reason (for us) to attach an xref while in a UCS. If you mean that it should switch to WCS, attach the xref at 0,0,0 and then switch back - then yes, that would work.

[Opie]

There is no reason (for us) to attach an xref while in a UCS. If you mean that it should switch to WCS, attach the xref at 0,0,0 and then switch back - then yes, that would work.
How about a prompt for the location (similar to how an insert works now) to place the XREF in the current UCS?

[jaberwok]

How about a prompt for the location (similar to how an insert works now) to place the XREF in the current UCS?

How about a prompt for co-ordinate system - current or world - then place at 0,0,0 ?

[Opie]

How about a prompt for co-ordinate system - current or world - then place at 0,0,0 ?
When you currently attach an XREF to the drawing (not through Design Center), you are not prompted for a different UCS. So, why the extra prompt?

[jaberwok]

When you currently attach an XREF to the drawing (not through Design Center), you are not prompted for a different UCS. So, why the extra prompt?

Just following the train of thought -

UCS or WCS?


We only attach xrefs while in WCS


But it would make sense for UCS though. If the user's in a UCS, then they usually think of 0,0,0 to be that of the UCS (not the WCS). Otherwise they'd have set WCS current wouldn't they? I.e. it should use whatever's current, not overriding the settings the user has specified.

[Ed Jobe]

I don't like that if you use edit-in-place, it leaves duplicate layers, styles with the prefix "0$0$". Exspecially, in ACA styles.

[irneb]

I don't like that if you use edit-in-place, it leaves duplicate layers, styles with the prefix "0$0$". Exspecially, in ACA styles.Actually, I don't like Edit-in-Place ... period ... it's got a lot more bugs than just those "fake" layers & styles. E.g. notice how draw-order gets screwed up if you use EiP?

As for placing XRefs in WCS/UCS, it depends on how you work with your XRefs. E.g. in Arch if you have a site with multiple buildings, you may want to place each building at a specified location & rotation. Easiest & most accurate method would be to use UCS. If all your XRefs are always drawn in WCS (a common WCS between each DWG), then you'd probably want to place them in WCS as well.

We just find that in our scenario, a building has its own WCS, but gets placed in different (ever changing) locations & rotations on the site. So if we'd drawn each in a common WCS, a change of location would require modification to each level of that building, including any viewports showing that building. Just way too much work. Thus we generally use the intersection of Grid A & 01 as the 0,0,0 of each building's model drawing (in its WCS). Then a location change / rotation only requires a move / rotate on the site-plan (nothing else needs to be modified).

[Julesagain]

We (fire alarm/life safety engineering firm) always xref our title block, notes, and wire legend and device address legend (each is a separate file). If required, the NICET certification block for each applications person is xref'ed in. We also start with our customers' drawings, and often the floorplans or other elements are xref'ed in (with varying degrees of expertise and headaches and nested upon nested upon backwards referenced, leading to these kinds of problems:
"4. Particular problems arise when a host drawing has both an instance of an xref that is nested inside another xref, as well as an instance of that xref attached directly to the host drawing. AutoCAD should allow the directly-attached instance to be detached, unloaded, etc., without getting confused by the indirectly-attached instance."
Amen.
Jules

[irneb]

"4. Particular problems arise when a host drawing has both an instance of an xref that is nested inside another xref, as well as an instance of that xref attached directly to the host drawing. AutoCAD should allow the directly-attached instance to be detached, unloaded, etc., without getting confused by the indirectly-attached instance."Stop me if I'm wrong ... but isn't this a bit different from "Detatching"? It's the same as saying, you can't purge the block even though you've deleted all selectable instances of it. --> There may still be instances of it inside other blocks, i.e. nested.

As far as I can tell, you should be able to erase the instance(s) of the xref which is placed directly in the DWG (not nested through other xrefs). Same as you would be able to erase the block reference(s) not nested within other blocks. Again, once you start thinking of XRefs as blocks you realize how similar they actually are.

If you want to have 2 "versions" of the same XRef, you could rename it. E.g. say you've got a file A.DWG which has B.DWG attached. In B.DWG you've got C.DWG attached (not overlaid). Now you'd like to attach C.DWG into A as well, but you want to set it's layer colours separately from the version loaded through B.

Solution: Open a temporary file (no need to save it). Attach C.DWG to it. Open the XRef Manager and rename it there to something like C1. Ctrl+C the placed xref. Close the temp file. Go back to A.DWG and Ctrl+V. Now you've got 2 distinct versions of the same XRef. You can unload them separately & their layers can be changed separately.

...

Isn't that a lot similar to what you would do to make a new block definition from another (before the BEdit command)? See XRefs = Blocks ... almost!

[dgorsman]

We use XREFs *everywhere*, from engineers stamps (without signatures) to 3D models. There are a few issues I'd like to see cleaned up:

Annotation scales from XREFs should follow the same convention as other XREF-dependant named items like text styles, as XREF-NAME|ANNO-SCALE-NAME

3D solids in XREFs that are rotated in the host drawing do not show the silhouettes/profile lines properly. This means that if a vertical vessel (for example) must be re-oriented 90 degrees the equipment model DWG must be opened and modified rather than just changing the XREF orientation. Incidentally this is the same behavior for blocks as well.

There needs to be better control on object enablers and their automatic importation of data when XREFs are loaded. Users need to be able to control this, not rely on in-house automation to scrub the drawings after the fact.

I wouldn't mind seeing an XREF proxy system, whereby instead of loading the full contents of the XREF a boundary box or similar simple object is presented instead. Partial loading isn't always an option, especially when you have a dozen or more XREFs with a hundred layers each and only the all-or-nothing unload XREFs option and 1200 layers to check on/off.

[RobertB]

Solution: Open a temporary file (no need to save it). Attach C.DWG to it. Open the XRef Manager and rename it there to something like C1. Ctrl+C the placed xref. Close the temp file. Go back to A.DWG and Ctrl+V. Now you've got 2 distinct versions of the same XRef. You can unload them separately & their layers can be changed separately.No need to use a temporary drawing. Just rename the 1st instance in the host drawing's Reference Manager palette and then attach the XRef again. Two names, same source file, no temporary copy-and-paste. :beer:

[michael.12445]

There's a user in this thread (http://forums.augi.com/showthread.php?t=33064) who's getting tripped up on the "multiple references detected - unable to detach" problem discussed here. Now several folks have responded to help out, but the problem - and how to solve it - are so complicated and convoluted that even the most experienced power users are having a hard time explaining it.

I think this may be one cause of the frustration some have expressed with firms that, in 2010, still refuse to use xrefs. AutoCAD has had xrefs, I think, since Release 11 or 12 - almost 20 years - yes, enough time for users to have learned how to cope with them and to apply best practices to their use, but also - xrefs are still handled essentially the same way in AutoCAD as when originally introduced. (Yeah, there's now in-place editing, xopen, and xclipping, but the attachment structure is still the same.) Especially when nesting them, things can easily get more complicated than many users are willing to tolerate. I think it bears examining whether this is just inherent in any possible scheme of linking external files, or whether AutoCAD can be made to handle these situations in a more intelligent, user-friendly way.

[darthyoga]

I love the idea of Xrefs and have been trying to get them used here for awhile. The issues I have (admittedly, ignorance is probably high on the list) are as follows:
1. We have up to 20 clients with up to 20 jobs on the go at a time so it impossible for us to work off a central network with any efficiencey. We haven been able to use our read/write software to include Xrefs when sending drawings to our personal drives for editing. As such we dont all work from a central location, and generaly have to reattach Xrefs alot.
2. When the workloads get heavier we send work to up to 4 different offices. While etransmit is effective, it doesnt consider drawing that are sent out with sketch numbers and returned with project numbers. ( rename the drawing, the the Xref path is no longer valid)
3.A nasty trend of putting the revision number in the drawing file name has sprung up, so with each revision the Xref path is broken and needs to be reattached. ( I am fighting this tooth and nail.)
4. I hate to say this but Microstation has Autocads number when it comes to Xrefs. They are efficient, stay with the drawing, and you can copy geometry and modify layer qualities easily. ( I really hate to admit this because the rest of Mstation is useless)

I would love to have a more useable Xref. They have a very valuable place in my day to day work but they dont suit how we function in our company. ( I am going to keep trying though)

[dgorsman]

3.A nasty trend of putting the revision number in the drawing file name has sprung up, so with each revision the Xref path is broken and needs to be reattached. ( I am fighting this tooth and nail.)

Good for you. That fight is well worth the effort, and its much easier to have one current document rather than a lot of "maybe current" ones. Its not a bad means for archived versions, though.

[irneb]

Its not a bad means for archived versions, though.Yes, but then they should stay archived versions. They should never be changed after they were issued, otherwise it defeats their purpose don't it?

We tend to keep the eTransmit ZIP files as an archive for each of the issues. That way we have a freeze of all the xrefs as they were at the date of issue, thus making it a breeze to open a drawing exactly as it was at ### date in its history. You could rename the ZIP file to include the revision code, or you could place the zip file in date folders, or some combination which works for you.