So have you ever wanted to give users the ability to offset and object either plus or minus a certain distance from a constant reference point. Like maybe you have a custom curtain panel family that you want the user to be able to plug in 1' 0" to offset the panel forward one foot from the curtain wall centerline, or you want them to be able to put -6" into the same field and have the panel move backwards 6" away from the centerline. Well, here is the code and instructions:
1.) Create two reference planes, depending on what is important in your family they might represent the front face, back face or centerline of the panel/object. (For our demonstration we'll assume that we're using the front face.) Name one reference plane, "forward offset", name the other "front of panel". Make sure the forward offset ref plane is forward of the front of your constant (in this case the ref plane that is in the curtain panel template named "front"). Make sure the "front of panel" ref plane is behind your constant.
2.) Now create a dimension from your constant to the "forward offset" ref plane. Select the dimension and make it a parameter called "Offset Forward". Next create a dimension from the "forward offset" ref plane to the "front of panel" ref plane. Make this dimension a parameter and call it "Offset Back".
3.) Go into the Family Types dialog box. Create a new parameter called "Offset" set it be a length type of parameter. You can leave it at its default of 0' 0" or change it to some value, positive or negative.
4.) In the formula fields of our other two paremters enter this information:
Offset Forward - = if(Offset > 0', Offset, 0')
Offset Back - = if(Offset < 0', abs(Offset), 0')
That should be it, with the addition of the two formulas the offset will automatically go forward or back based on the positive or negative value entered into the "Offset" parameter. As long as I didn't screw up the order of the dimension strings to reference planes it will work just fine.
Sunday, January 27, 2008
Too much to do in too little time: Linked file error message
Argh... I've been busy. After my last post I had a deadline on a 30,000 sq ft building, then there was Thanksgiving, AU then a deadline on a 100,000 lab/classroom building (all in Revit of course) oh and Christmas was in there too and New Years. What is cool is the classroom building was featured on the cover of McGraw Hill's latest research report:
Interoperability in the Construction Industry
If you care about our industry and why we use tools like Revit its a good and important read, check it out. I recently attended an AGC BIMForum committee meeting (as an architect) where Norbert Young delivered a keynote address regarding this report.
All that said, Revit stuff. Regard Steve's recent post about acquiring coordinates from another file. An error that I know we've run into here, and I imagine others too is the wonderful error message about "Can't save file X, as it will invalidate local copies of file Y, owned by user Z (you)" Now, no one I had talked to had ever really been able to explain this message, though A-Desk was able to say, don't worry about it. The question is, what does it really mean? Well thanks to having the ability to see what users are working in a central file, I think I have an explanation.
First we'll lay out the conditions. You have a central file for your building (worksharing enabled), of course this means you have local copies of the central file on your computer. You also have a second revit file that is a site file which contains all of your topography and exterior elements. Within your building file you've created dimension strings that are attached to objects that exist in the site file that is linked into your building file. Your building central file is also linked into your site file (for reference). Your site file exists on the network with your central building file, and the site model is does not have worksharing enabled.
When you open your site file and work on it Revit sees you as a user working in the central file of the building. So this would be similar to if you opened up the central file directly and started working, rather then creating a local copy of the central file. Why you might ask do you show up as a user working in the central file, because of the links! Links in Revit have all sorts of associations and relationships, shared coordinates being the most obvious, but also being able to schedule objects across links, creating dimensions, align/locks, workplanes based families, etc... So, in affect you're a quasi local user when operating in linked files that have worksharing. In fact, you have to be in order for shared coordinates to work, as when you publish shared coordinates to another file you have to be able to write data to the file you're publishing to. If the file being published to is workshared.... well you get the picture.
So now, back to the error message. We've now established that user Z is working in the site model, but is also seen as a user working in the Building Central file. User Z has a local copy of the building Central file on their computer. Except user Z isn't working in the local copy, Revit sees them as working in the central file.
Time out again; lets go back to another error message that everyone is probably familiar with. "If you do not save current changes in the central file to your local file, you won't be able to save any new changes in the local file to the central file". This basically says that if you don't save all the changes from the central file to your local file, the two will be out of sync, thus invalidating your local file. This is Revit's way of protecting the integrity of the database, your local copy of the database always has to be in sync with the server copy.
Time in;
You've made a change in your site model, that for whatever reason Revit is convinced affects the building file, maybe you moved a bollard in the site file, that has a dimension string in the building file, who knows, either way, Revit being a giant database, it wants to rectify that change in the building file when you go to save your site file. So, in essence, when you hit save in your site file, you're doing a Save To Central on the Building File! (At this point you've either understood everything I've written, or you're saying waiiiit! What? an STC that isn't a real STC?). So, now here is the catch, when you hit save in the site file, and kick off the STC to the Building Central file, you don't really have a local file you're saving from, but Revit is smart, and it says wait, you do have a local file on this computer, and if I let you make changes via the site file to the central file, the central file and your local file won't match up anymore, therefore, you're local file will now be invalidated (per the other error message previously discussed). Since you don't have the local file open, there is no way for Revit to save the changes and rectify everything across all the files, therefore you get the error message.
The nice thing about this whole issue is that it really isn't that big of a deal. You're not prevented from saving the changes to the site model, and all you have to do is close it, open your local file, reload the site file, and then STC and everything should be kosher. I will say that this is all based on assumption and a little detective work (and the ability to see who Revit thinks is working in a central file). I'm can't say that I'm 100% right, and you're more then welcome to poke holes in my theory, but I think the overall logic is pretty solid, even if I might be off on some of the details.
Interoperability in the Construction Industry
If you care about our industry and why we use tools like Revit its a good and important read, check it out. I recently attended an AGC BIMForum committee meeting (as an architect) where Norbert Young delivered a keynote address regarding this report.
All that said, Revit stuff. Regard Steve's recent post about acquiring coordinates from another file. An error that I know we've run into here, and I imagine others too is the wonderful error message about "Can't save file X, as it will invalidate local copies of file Y, owned by user Z (you)" Now, no one I had talked to had ever really been able to explain this message, though A-Desk was able to say, don't worry about it. The question is, what does it really mean? Well thanks to having the ability to see what users are working in a central file, I think I have an explanation.
First we'll lay out the conditions. You have a central file for your building (worksharing enabled), of course this means you have local copies of the central file on your computer. You also have a second revit file that is a site file which contains all of your topography and exterior elements. Within your building file you've created dimension strings that are attached to objects that exist in the site file that is linked into your building file. Your building central file is also linked into your site file (for reference). Your site file exists on the network with your central building file, and the site model is does not have worksharing enabled.
When you open your site file and work on it Revit sees you as a user working in the central file of the building. So this would be similar to if you opened up the central file directly and started working, rather then creating a local copy of the central file. Why you might ask do you show up as a user working in the central file, because of the links! Links in Revit have all sorts of associations and relationships, shared coordinates being the most obvious, but also being able to schedule objects across links, creating dimensions, align/locks, workplanes based families, etc... So, in affect you're a quasi local user when operating in linked files that have worksharing. In fact, you have to be in order for shared coordinates to work, as when you publish shared coordinates to another file you have to be able to write data to the file you're publishing to. If the file being published to is workshared.... well you get the picture.
So now, back to the error message. We've now established that user Z is working in the site model, but is also seen as a user working in the Building Central file. User Z has a local copy of the building Central file on their computer. Except user Z isn't working in the local copy, Revit sees them as working in the central file.
Time out again; lets go back to another error message that everyone is probably familiar with. "If you do not save current changes in the central file to your local file, you won't be able to save any new changes in the local file to the central file". This basically says that if you don't save all the changes from the central file to your local file, the two will be out of sync, thus invalidating your local file. This is Revit's way of protecting the integrity of the database, your local copy of the database always has to be in sync with the server copy.
Time in;
You've made a change in your site model, that for whatever reason Revit is convinced affects the building file, maybe you moved a bollard in the site file, that has a dimension string in the building file, who knows, either way, Revit being a giant database, it wants to rectify that change in the building file when you go to save your site file. So, in essence, when you hit save in your site file, you're doing a Save To Central on the Building File! (At this point you've either understood everything I've written, or you're saying waiiiit! What? an STC that isn't a real STC?). So, now here is the catch, when you hit save in the site file, and kick off the STC to the Building Central file, you don't really have a local file you're saving from, but Revit is smart, and it says wait, you do have a local file on this computer, and if I let you make changes via the site file to the central file, the central file and your local file won't match up anymore, therefore, you're local file will now be invalidated (per the other error message previously discussed). Since you don't have the local file open, there is no way for Revit to save the changes and rectify everything across all the files, therefore you get the error message.
The nice thing about this whole issue is that it really isn't that big of a deal. You're not prevented from saving the changes to the site model, and all you have to do is close it, open your local file, reload the site file, and then STC and everything should be kosher. I will say that this is all based on assumption and a little detective work (and the ability to see who Revit thinks is working in a central file). I'm can't say that I'm 100% right, and you're more then welcome to poke holes in my theory, but I think the overall logic is pretty solid, even if I might be off on some of the details.
Subscribe to:
Posts (Atom)
