blimey Posted June 19, 2009 Share Posted June 19, 2009 Hi i've been fighting with RDLVP for a while now (see my past post on chained reference : http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Main=25754&Number=125369#Post125369)... I feel there's a "hidden" origin in the file somewhere that make them move when in chained references is that possible??? the problem typically occurs when the origin of some file as been "reset" with the "set origin..." tool ??? >> Is this possible??? Here is what happens : 1. I've got 4 floors of the same building with their origin all set at the cross section of axe1 and axeA... 2. I reference them in a new file as RDLVP, they all come nicely one on the top of the others, nicely superposed. I save the file under i.e. the name "REFERENCES.vwx" The purpose is to create a reference file that contains all the floors and that I will attach (as a RDLVP) in all my sections in order to be able to draw them 3. whenever I create in a new section file a RDLVP with the external reference 'REFERENCES.vwx" all my floors are splitted as if they where having different origins... => I JUST DONT UNDERSTAND what happens !!! => it is as if the floors file remember "past" origins that they retain as a real origin => The floors plan are not splitted randomly, their positions seem to be in relation with some "initial" origin which setting I don't know how to see and how to change => in order to double check this, i've referenced the floors as referenced layers (the old way) : the result is that they all come nicely superposed. YET if I select "Ignore source user origin" they do the splitting... exactly in the same position as above... I REALLY DON'T UNDERSTAND THIS AND IT'S REALLY BEEN DRIVING ME NUTS FOR MONTHES!!! Does anyone PLEASE have a clue on what's happening??????? Quote Link to comment
mike m oz Posted June 19, 2009 Share Posted June 19, 2009 Rule No. 1: Never move the origin in any file. Rule No. 2: Never move the origin in any file. Rule No. 3: Never move the origin in any file. Moving the origin screws ups everything so never never do it. Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 Yes but once it has been done??? (and on many many files)???? how can I fix it right? what's the use of "set origin" if we can't use it? woww... i'm in a big mess... i think.... (many many files...) Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 Well as an after thought : How come this mess happen at all? Am I the only one that find this origin problem REALLY anoying? How do you guys feel about it? I mean this could be called a BIG BUG or not? It's quite amazing that something as important as the origin of a file could'n't have a more fluid working process... !!! What do you think ? Would you agree or do I have to question my methodoly??? Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 it is not as if the origin has migrated by accident. The problem happens whan the origin is set accurately with the set origin tools. The fact is that if you have a file that has his "new" user orgini set with the "set origin" tools, it DOES NOT behave like the copy of the file where the full drawing has been moved to match the same origin... >>> i'm not sure this is clear so put it this way : 1. we have file A and file B that are identical 2. In file A : we set a new origin by using the "set origin" tool at a distance x=100 and y=200 from the initial origin. 3. In file B : we select the whole drawing and move it by x=-100 and y=-200 => the result is that we still have 2 identical file (they look totaly the same except for the position of the "page") yet they behave differently. => If you reference them as RDLVP ia a first file called "reference.vwx" they superpose nicely with the same origin. => YET if you reference the file "reference.vwx" you will see that the files split considering each different origins !!!!!! BERK888 => if you reference them the old way and select "ignore source document origin" they split the same way In my view this behaviours is A BIG AND ANOYING PROBLEM. Quote Link to comment
mike m oz Posted June 19, 2009 Share Posted June 19, 2009 Renewit, I don't fuly understand the problem either. Through experience I've learned that moving the origin is not a good idea. When you are referencing it is definitely not a good idea. Quote Link to comment
blimey Posted June 22, 2009 Author Share Posted June 22, 2009 Yes, I give up. thanks anyway for feedback Quote Link to comment
Christiaan Posted June 22, 2009 Share Posted June 22, 2009 I've had a lot of problems moving origins too. I've settled on moving pages only. Quote Link to comment
Jodyb17 Posted June 22, 2009 Share Posted June 22, 2009 I've taken to turning off the "Rulers" display preference. The shortcut button to the "reset origin" tool is very close the the mode selection icon of all the other tools (top left). It's pretty easy to reset the origin and not notice by accidentally clicking on this icon. Quote Link to comment
islandmon Posted June 22, 2009 Share Posted June 22, 2009 IMHO : The VW Parent File A declares the Drawing Origin ( default = 0,0 ) for all subsequent Container insertions. If you desire a different Origin then create a Parent File B with Origin offset and it will be the overriding structure for all embedded child-Containers relative to it. Each file will display data based on the relation to the ParentOrigin. That being said VW allows for User declaration of unlimited Child-PageContainer Origins via "Set Origin ", but these supplemental Origins are always relative to the Parent File Origin. Therefore, since referenced files may be of kind Parent and/or Child, they import into the Parent File C with their Origin information relative to the existing Parent C Origin. However, this rule does not apply to DWG/DXF imports which may override the VW File Origin in order to rectify the translation ( thereby creating endless hassle for VW Users, et al. ) . Quote Link to comment
blimey Posted June 28, 2009 Author Share Posted June 28, 2009 Thank you for the explaination Islandmon. What's the point of such a logic? I see no advantages and only anoying problem resulting ? In particular, you can't trace where's the Parent Origin unless you draw it yourself manually and lock it at the very beginning and if you're not aware this should be done (why should it? ) it's a big mess ! Basically it means that VW cannot "really" change the origin. The set origin command is in fact only an artifact that only makes it look as if the origin had changed while in fact it just a kind of make up that adjust the value of the rulers. Anyway if NNA doesn't intend to change this (or cannot) they should at least have a built in zero that is "unmovable", "unerasable" etc... sorry I didn't answer earlier (work work work :-)) Quote Link to comment
Guest Frank Brault Posted June 28, 2009 Share Posted June 28, 2009 If you were to solve this problem, what would the rules be? I am very interested in your ideas on how this would work better for you. Thanks, Quote Link to comment
Stan Rostas Posted June 29, 2009 Share Posted June 29, 2009 See Mike Moore comments above Rule # 1 The origin does not move, all other rules need not apply. Quote Link to comment
mvsubstation Posted June 29, 2009 Share Posted June 29, 2009 I am having the same set origin file problem. We have five working files, all referencing a title block. Only one of the files has a sheet layer with viewports. When the date is changed in the title block, the title block moves inside the viewport (the other drawings without viewports are still okay). Only fix is to delete the title block viewport and create a new one. This is the second job I've worked on in 6 months that I have had this problem. I definitely prefer AutoCad's viewport set up which is much simpler. Quote Link to comment
islandmon Posted June 29, 2009 Share Posted June 29, 2009 Fix the 'date changing TitleBlock problem' by editing the the TitleBlock Record Symbol to eliminate the DateField text from expanding beyond the rightside title border ( which forces the VP TB to move to the left in order to maintain the declared VP center ). Either reduce the DateField font size or shift the DateField to the left by a min. 2 character spaces. Quote Link to comment
mjm Posted July 15, 2011 Share Posted July 15, 2011 being able to move the origin of the drawing is crucial to my workflow: I get drawings from client and assorted venders with origins often in places which are worse than meaningless to efficient drafting (00@center of the plasterline in theaters). Any other position is detrimental to drafting quickly and efficiently. Being able to employ the Set Origin tool to position the origin where I need it is great. Subsequently, having the origin move randomly is extremely detrimental. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.