I have 5 xrefs, of 5 aquaculture systems in a row. these 5 systems are repeated 3 times.
x x x
x x x
x x x
x x x
x x x
So I xref'd them into a floor plan, then if I copy or attempted to xref more in away from 0,0,0 I get the error message
"An xref has been moved to an unsupported location"
What are the ramifications of this? The 3 overall systems are not interconnected.
In previous versions it caused connection problems with piping but I though 2012 had solved that. I have not tried it because I always make sure xrefs are inserted at 0,0,0.
I, personally, would have used either 15 xrefs all inserted at 0,0,0 or done the copy in the original file so that you have 5 xrefs with 3 systems in each. That way you will not have any issues with pipe connections and you also will not end up with the annoying error message.
Other than that I am not sure what further implications there are.
Yeah what I may end up doing is finishing the original 5 xrefs, then just copy them to new files giving me the 15 then I can insert them all at 0,0
Xrefs need to be inserted at 0,0,0 in order to maintain intelligent piping connection across the Xrefs. That's the reason for the warning message.
If you're using a floor plan or plot plan, use a common take off point and align that to 0,0,0. Then all of your Xrefs should match up as they are inserted.
Thank you,
The mechnism that all xrefs must be insert at 0,0,0 is so inconvenient. In the case that there is many same equipments on the same area, it loses the advantage of using multistage xrefs.
For example, if you have 50 same pumps in the pump station, you can only do it by: model the pump, assign nozzles, copy 50 times ,then posittion the 50 copies at the proper location relative to the 0,0,0. Then xrefing it to other master dwgs will have no connection problem. You cannot accomplish it like: model a pump, assign nozzles, xref it to master drawing, copy the xref 50 times, position the 50 copies at the proper location. If xref this file to upstage drawing, P3D will not recognise the nozzle.
The fomer: If changes are make to the pump, copies cannot changes. You must recopy/rearray it.
The latter: Changes can flow to the master drawing. But nozzles lost.
WE NEED XREF MOVE FREELY !!!
I completely understand this, but you have to remember, when you run an Iso, what does the end connection say? If you have 50 lines and then 50 pumps, and they all say the same Pump connection at the end, what do you do?
And how do you count the 50 pumps if they are all named the same? Its one instance of a pump, but how do you represent it in a database? Give it unique PnPID's? Then you might as well make different pumps.
It has to be remembered there is a database backend and it needs to be satisfied in how it makes the data work with the software.
As for keeping it at 0,0, thats logical. You nominate a datum point on a site, and with each equipment model and piping, structural models, you move them in their own respective models, rather than moving the XREF to suit.
No, we really need to be able to move the xrefs.
Typically, people want to have one drawing file per piece of equipment as it's easier to model and organize. Then they will usually create an overall general arrangment of the equipment that references each of the equipment drawings. The easiest way to locate the equipment in the general arrangement would be to move the xref, otherwise, we have to open each equipment model, attach the correct references and then move the equipment. I aggree that piping and steel should all be at 0,0, but equipment is a different situation and the program needs to handle locating information in a moved xref.
Typically the equipment (and piping and structural) models are broken down into areas, relative to the datum point of the project/plant. From that 0,0 you place the equipment in its place, and then route the piping to that piece of equipment/nozzle/connection point. You make an area of equipment models, then move them individually inside that model to the correct location. You can do one model per equipment obviously, but I don't see any benefit to that, its just more work.
You wouldn't do the same with structural piping rack models, doing them at 0,0 them moving the XREF (and rotating maybe) to the correct point. Its all relative to the Plant datum, wherever that may be (the corner of a building, a fence post, the corner of a pipe rack etc)
A lot of this comes down to the size of the site, how many people working on it, how many area's inside the plant etc etc, but moving the XREF isn't the answer. Keep the models to a 0,0 of the site/project, and then move the elements inside each model, not the XREF's. I have never seen a project that has equipment models moved via the XREF, all equipment is moved inside its model to the correct location. When you do a report on equipment and where the datum point is, they show where the location is to 0,0 and not where the XREF is located, otherwise you would have all equipment placed at 0,0 which is useless for reporting.
Dave,
Yes, we need to remove this restriction. It's on our enhancement list for the future.
There was some relaxation of this restriction in 2012, I think, but it still holds for xrefs that have connected piping.
I now have version 2013 and this is still NOT fixed. I have read the autodesk comments that all the equipment should be in one drawing and not each piece in its own drawing. The bad part of this is there can be only ONE guy working on the equipment drawing because it gets locked when open. Having separate drawings for equipment and then xrefed together means many people can be working on the equipment at the same time. We normaly start with simple equipment models, do a general layout and then add detail to equipment ie nozzles at a later time. We don't have a gigantic plant broken down into areas so many can work on it at once. We have a small plant, one area and need many works accessing parts of it at the same time.
You can use multiple xrefs, but you must have the equipment located within it's own drawing (no moving the equipment xrefs).
We are using Plant 3D 2015 and the ole "unsupported location" for xrefs is still in effect.
I totally agree with the others who have said this is unacceptable.
Yes for plant layout we take a datum into consideration. However, for example I create a custom spool that we use several times on a skid. I don't want to have to go through the rigamarro of having to create some sort of dummy file just to place this spool 4 times in space, then xref into my skid model.
Plus we use the same skids on all our jobs and the sites are layed out differently, so the datum will vary and equipment locations will vary in relation to each other, etc. This definitely should have been fixed already.
My main problem with this issue is the following:
For example in my current project I ahve a big press hall (150mx150m footprint), 2 heater rooms and several press locations in this hall with 5 different presses.
The heater rooms, the presses and the hall all have reference points for its own for easier planing.
So in the several drawings i want to keep the reference points, so I dont have super high x,y coordinates.
And its better to communicate with the suppliers and customers.
Every drawing has its own piping, to a defined transfer point.
But my Process piping needs to connect everything in the main drawing (the hall).
As we know if you make ortho drawings wich are far away from the 0,0,0 cordinate this causes problems!
(missing geometry)
So i dont want to move the diferent Buildings or presses in their drawings to the correct possition.
Thats why I think we need this feature!
Hi,
Picking up on this thread from previous comments, seems some debate over 0,0,0 location use relative to X ref models and Elements.
My question is relative to Advance Steel, typically we would teach that users model about the WCS 0,0,0 point, because AS has issues numbering parts if to far away. But with P3D, the indication here seems to be that you are not able to do this, say the elements in the Steel sub model are required at a remote location away from the 0,0,0 point in the P3D. typically i would expect to insert this with an offset from the origin in P3D to achieve this position.
But as with the comment over equipment, it seems that it the elements of the steel model need to be modelled at those remote co-ordinates, to achieve the relative required location when inserting into an overall master model.
So whats the best practice here: to model the steel model at the remote location, to assure require location in master overall site layout. or is there now an option to allow for the offset from the origin and not receive this warning message? or can i just ignore this message, being that i only insert the Xref AS file to show the completed steelworks, as fully detailed under the Advance steel programme back into the overall P3D project.
Any advice guys.
Cheers
John Bennett
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
hi, I am involved in implementing P3D 2021 to replace other 3D piping design packages.
We use a local project 0,0,0 basepoint and rotation, but also need to be able to xref these into a master container file and the insert point and rotation needs to be set to place these models in real world coordinates (treatment plants, dams etc). This master container file is also used by other disciplines (xrefs as attachment not overlay). As we are not connecting P3D to P3D in these container files so hopefully the error warning will not have any impact. It seems to work ok for NWCOUT when creating intelligent exports for inclusion in Navisworks Federated models.
However I do support the need to be able to connect to xrefs if they are not inserted at 0,0,0. There are always projects that have special requirements and the software needs to accommodate this.
I am currently using 2021 Plant3D on a trail to see if my firm can use it for our projects. This impediment of "xref moved to an unsupported location" is still there. This impediment is still in Plant3D. It needs to be removed.
So it's 2024 and this issue still persists. Cannot the database apply an offset to anything that needs it? Easier for it than us I would think.