Monday, 29 December 2014

Content to think about

This post I have started to write some time ago. I have let it simmer in my head for a while to give it a correct angle. I am glad I did because new insights gave me better understandings and have given me a lot to think about. 

The story started with an email I got from the website . They had posted some new content and I had a look at it. My first reactions were of annoyance and I left a rating and comment that were less than eloquent. They contacted me and I explained why I was unhappy. They explained to me that they shared my views but that the customers were asking for this. Oh oh 

So customers are asking for this below. Why are you asking for this? Because of LOD 400+ ???  Please do ignore the brand name because that's not what this post is about.

This sort of content could become extremely expensive if you use it in a project. (please still ignore the brand name because it's not them that makes is expensive)  If you add this to your project you are probably also adding other content like this to your project. Why does it become expensive? Content with manufacture like detailling will most likely slow down Revit projects extremely. Therefore you are waiting and waiting for Revit to respond to your commands. You will lose valuable time and money. 

I see so much content like this from many manufactures in Revit projects. When I look at the 3D it's a very nice model. I love highly detailed 3D models, but not in my Revit projects. Just because I don't want it in my Revit model, does not mean I do not want it in my BIM model. (they are not the same as I see it)

My objections to this family for Revit projects are the following:
  • To much detail
  • Remnants of DWG geometry
  • A whole lot of family types and no type catalogue file provided
  • Capitals in parameter names not compliant to DRS but to EMCS
  • Shared parameters with the same name as native Revit parameters. (TYPE and CATEGORY)
  • Geometry not assigned to subcategories
  • Unnecessary use of voids
  • Lacking any zones for clearing, connection, maintenance and placement 
  • No bounding box
  • No use of coarse medium and fine or any other Visibility setting
  • No symbolic representation
  • Family name not compliant to DRS but to EMCS
  • No assembly code(although this might be on purpose to serve more countries) So you would have to add it yourself
  • Family parameters not compliant to DRS but to EMCS
  • Object styles
I have seen other families from and they sure now how to make good content. I think we ask them the wrong things. I talked to them and they are trying to comply to industry standards. Some of these standards are still shaping as we go. They are improving the content every day. It's a lot of work and not easy because of increasing demands. 

I'll try and write my next post about how to use lean revit content and create super rich BIM content in one flow. It will most likely involve Revit Navisworks and database connections.

Friday, 12 December 2014

Manufacture content

This week I received this model from a company to add to the revit model. I recieved it as a stepfiles. Right away alarmbells went of in my head. Stepfiles are generally created out of Inventor or similar programs. That often means way to detailed for Revit and no metadata. (Big disclaimer: the model itself looks fine to me. It's just I have to think about Revit performance!) 

Just for fun I made a revit family out of it just to see how bad it would be.  I am not going to explain how I got it into Revit because that could lead to bad practises. If you want to degrade the performance of you projects you have to figure that one out your self. Below you see the stepfile opened in Navisworks. It's nice, isn't it?

In Revit: (not a good idea)
First not every panel came across. Also the family turned out to be 4.5 mb and it has no connectors or any usefull metadata. This got me thinking. How do I get a good performing revit model and a BIM model where I can also see the more detailed model. 

Of course If this is the content you get from your manufacturer you have to create a family yourself. In that family you could add a link to the the manufacture content. But where to let you point that link? The website of the manufacturer? That is probably not a future proof idea. You also what to avoid having to edit your families when changes happen. 

If you get the Revit files to Navisworks you can create a database link and add properties there. You can refere to all kind of extra information from the database without 'polluting' your Revit model.

Friday, 21 November 2014

Revit Ramdrive

Revit 2015 offers a nice performance increase over Revit 2014. But ofcourse we always want more more and even more. I am working on a project where I can't switch to Revit 2015 just yet. So I started to wonder what else can I do to get more performance out of 2014.

The project I am working on has a lot of links. While working I noticed my C: drive filling up. So I was wondering did Revit start to cache a lot? I checked the memory and I still had quite some free memory left. Revit saves it's cache files in the following location %temp%. 

Let's take a look at what Revit 2014 writes to this location: 
Revit has just started up and no thing has been loaded yet. Notice that Revit creates some placeholder temporary files. These are small so this should not hurt performance 
Let's load a workshared project with a lot of links. I do not open all the worksets just those I need.
Notice the new and big temporary files it creates? The information in these files had to come from the network to the HD. Bottleneck #1

To have a better understanding of what Revit is doing with the cache files and the memory I keep an eye on this temp directory and the taskmanager's processes tab. Apparently there is a magic free some memory button in Revit that looks like this.
Because this is what I see happening a lot. Notice how Revit is now using 2889 mb of RAM
Press the worksets button:
Notice how Revit is now using 59 mb of RAM
Press the OK or cancel button:
Notice how Revit is now using 979 mb of RAM
So far this works every time for me. I wish I knew what Revit just ditched and if other parts of Revit will react slower because it needs to reread this data from the cache files.

So far we know now that Revit cache's it's links. This is read/write intensive for the hard drive but only at start up. So far I have the impression that it creates them only to read. I don't see any changes in the modification date after I loaded those worksets. Which makes sense because you can't edit the links.
I also noticed that Revit prefers it's cache files to be a certain size. 2048, 4096, 8196 16.384, 32.786, 65.536, 131.072, 262.144. 

So back to the initial question how do we get more performance out of Revit. I remembered a trick that has been around for years. What about creating a ramdrive? (ramdrive) What if I would put the temporary files upon a ram drive. I used a free ramdrive version from for testing purposes. I also changed one Windows variable? The user variable that sets the location of the temp files. I set that pointing to the new ramdrive.

After a bit of testing I did notice some performance increase but not what I was hoping for. This got me thinking. Before I used the ramdrive those files were placed on an SSD. So basically the change I made was loading those files from the SSD to the CPU and now from RAMdrive to CPU. But if I observe how Revit seems to work with these cache files then it seems to do the following. Create cache files when loading project. It also seems to create cache files for files linked revit files that are on a closed workset. This data often tends to come from the network so the bottle neck is still the network.

Should I continue exploring a RAMdrive solution? Probably not, because of the following. I know that SSD can transfer a lot of data to memory fast. I did a simple test. I transfered 3,5 gb of large files (about 300mb each) from the ssd to the RAMdrive. This transfer spiked to 700 mb/s to later go down to a steady 400 mb/s I also tested with a couple of thousand small files 50kb. This transfered at an average of 70 mb/s. When I test the ramdrive with Revit I only gain a little bit of performance. This leads me to conclude that there is yet another bottleneck and that is the processor. 

I made the following conclusions
If you don't have an SSD in your system but you do have enough memory you might consider a ramdrive solution.
An ssd drive is becoming very important when working on large revit files. Network speed is very important.
File link setup and worksets structure in those files are crucial for getting a good performance. 

I think that the order of addressing performance bottlenecks are:
  1. Network speed
  2. Harddrive
  3. CPU
  4. Memory
  5. Revit knowledge
Good Revit knowledge will let you avoid running into the other bottle necks for a while but at some point projects just become big.

Wednesday, 19 November 2014

Project North don't do it!

Project North

English version of: project-north-niet-meer-doen

Several times I have written about coordinates in Revit. Recently I have seen a number of projects where errors with coordinates creep in. Often I see architects who get a drawing from the municipality drawn to coordinates and then they pick an interesting point in the drawing as an exchange point. This work quiet well in Autocad. I don't advise it for working in Revit.

First of all when you pick a point in you drawing you will get a point with lot's of decimals and therefore you will get differences in rounding when usinging different software packages. I suggest you create a point and you move it to rounded the coordinates. I have this little Autocad block that I use for it.

I also have to admit that in the past I have explained people how to acquire coordinates from a dwg. I have stopped teaching this and using this methode because it creates inaccuracies. I also have stopped with using Project North. I have experienced quiet a few annoyances when trying to set it up. I have also experienced some major problems in projects with multiple disciplines. There was one project were the BIMguide said that the rotation was 60.389° while the project was really setup wit these numbers: 60,38872747670°
Read this little excel example as follows:

Row 3 is angle α and row 5 is β
In row 2 and 3 you see the length set for x and in row 3 you see the lenght for y

So when α = 60 then x = 1000mm and y = 1732,05mm
If α wasn't 60 but instead rounded down from = 60.4 and x = 1000mm then y becomes 1760,32 mm. This is means that because of this rounding the differences becomes (f) 28,27mm. (btw verschil = difference)

In Row 12 you see the difference between if the angle is 60,389 and 60,3887. If X is a meter you can't tell the difference. But when X becomes 1000 meter than the difference is almost 2mm. This will make clashdetection a hell! How to avoid it?

Do not use project north for drawing orthogonally! Use scopeboxes! Also be aware Project north will only let you do one rotation per file. Scope box  will let you do as many as you can deal with.

Tuesday, 4 November 2014

Using schedules for checking

A simple trick today.

Schedules in Revit are great. You may also use them to check to see if you comply to specific project demands. For example I am working on a project where one of the demands is to add assembly codes to every family type. 

A simple schedule will help you find the ones you may have forgotten. The schedule will also let you fill them in very quickly.

  1. Create a multicategory schedule
  2. add the following fields:
    1. Family and type
    2. Assembly Code
    3. Assembly description (optional)
  3. do NOT include elements from linked files (You can't add information via a schedule in a linked file you have to do that in the file itself, obviously)
  4. sort by: family and type
  5. uncheck itemize every instance
  6. Optional:
    1. filter by: Assembly code equals blank
  7. OK

  1. click in the empty cells on the little grey button 
  2. select the right one!

Wednesday, 29 October 2014

RTV Xporter by RTV Tools

Sometimes some tools really makes you happy! I am evaluating the RTV Xporter Pro by RTV Tools. 

This tools saves me tons of work and a lot of waiting for cpu cycles to finish. I haven't even tested al the niceties of this tool pack, but I am already very pleased.

What makes me so happy about it is it functionality to create nwc files from views in Revit. I have a way to big model. I have separated this model into worksets and I have several views showing only a particular workset. The only thing I have to do now is select the views I want, set the export options once, press the magic button and work on something differently while it's pushing out nwc files for me.
Check it out yourself.

Wednesday, 22 October 2014

Revit 2014 vs Revit 2015

(Dutch this time)

Recentelijk kreeg ik de vraag of we niet beter naar Revit 2015 kunnen overstappen omdat deze zoveel sneller zou moeten zijn. Autodesk had me al uitgelegd wat ze hadden verbeterd en waarom het sneller is geworden dus ik was al overtuigd. Om het intern ook uit te leggen heb ik een snelheidstest gedaan.

Ik gebruik graag de Revit benchmark test van
rfo benchmark
Op dezelfde machine heb ik dezelfde test voor 2014 en 2015 uitgevoerd. Hieronder staan de scores. (blauw is 2015 en roos is 2014)
Deze grafiek laat vooral modeleer gerichte taken zien.

Deze grafiek laat vooral view opbouwende gerichte taken zien. 

Bovenstaande grafieken maar dan in % en

(groen is in het voordeel van 2015)

NU is dit geen extreem uitgebreide test maar het geeft een redelijke indruk. Zoals Autodesk zelf aan aangeeft hebben ze vooral gesleuteld aan de opbouw van views. Alle andere vernieuwingen laat ik even buiten beschouwing. Op basis van grafische prestatie verbeteringen is er zeker een goed argument om over te stappen naar 2015. Als je conservatief naar de cijfers kijkt en bedenkt wat je dagelijks voor taken in Revit uitvoert dan denk ik dat je kan stellen dat je tussen de 5 en 10% sneller kan werken in Revit 2015. 

Het lastige voor project teams met meerdere partijen is natuurlijk om gecoördineerd over te stappen.

Saturday, 11 October 2014

Revit Family size

Recently I had to evaluate some Revit models. After some checks I ran into some large families. Drilling a bit further down I found some heavy detail items. Basically some autocad files had been exploded in them. This made me wonder what is the impact of a line or arc on the filesize and thus the memory usage in Revit.

An empty Empty detail item.rfa = 204 KB (208,896 bytes)

Adding lines: 1             
= 204 KB (208,896 bytes)
Adding lines: 10  
= 204 KB (208,896 bytes)
Adding lines: 100  
=220 KB (225,280 bytes)
Adding lines: 1000  
=368 KB (376,832 bytes)

An empty Empty detail item.rfa = 204 KB (208,896 bytes)
Adding arcs  100
224 KB (229,376 bytes)
Adding arcs  1000
404 KB (413,696 bytes)

 this roughly means the following:
1 line = +/- 168 bytes
1 arc = +/- 205 bytes

don't forget to multiply filesize times 20 for memory usage

Tuesday, 30 September 2014

Export Revit to nwc

Last week I was discussing NWC export settings when I was asked why I set the convert element parameters to all.Truth is that I actually haven't looked into it and I just set it to all because I wanted it all.
So I had a check the other day. Apparently if you set the above export setting Convert Element Parameters to element you don't get Revit type properties. Or at least not where I wanted them. Recently I had spend some time to create searchsets looking for specific assembly codes. These searchsets are looking for: (ignore the dutch words)

selectionset name="28.20_hoofddraagconstructies - wanden en vloeren, algemeen (verzamelniveau)" guid="002812da-1211-2802-3108-151219752812"
            findspec mode="all" disjoint="1"
                condition test="equals" flags="10"
                    name internal="LcRevitData">Revit Type
                    name internal="lcldrevit_parameter_-1002500">Assembly Code
                    data type="wstring">28.20

(pretty much all the < and > are removed from the above searchset otherwise it would not show here)

If I don't convert element parameters all these searchsets don't work!

So basically I need to convert all element parameters and properties. It looks like element parameters are Revit's type properties and element properties are Revit's instance properties.
My preferred setting are:

Friday, 8 August 2014

location marker

In my previous blog I wrote about trying to get project to link in properly when shared coordinates have been set and they do not match.

Revit has a very nice tool to report coordinates of a point. But you first need to have something there. I was looking for some sort of autocad like functionality of putting something you can snap to at exactly the right coordinates. Most likey it will be easy to do if you make use of the api and some c##. I am not so good with code so I thought let see if I can create a family who can do what I need.

I created this family called location marker. This family is meant to be placed at the project base point. If the values you need to put in are not to big then you could also place it at the survey point. 
The trick to this family was to be able to insert positive or negative values.
Dima Chiriacov blog about formula's helped me out. In order to position the snap point I have to be able to insert negative values. But Revit length parameters won't let you use negative values. But with Dima's formula's I can use negative values.

First a parameter looks if x > 0 mm then the next parameter  if(x_is_positive, 2, 0) gives me a value of 2 or 0
The same for the y value except instead of 2 and 0 it gives me 1 and 0
Next I add the results of the of the two above and they control which snap point becomes visible.
The next four images show screenshots of different xy values and it's corresponding marker. (take a look at the right in the property window)

With this family I can put a mark anywhere in my project. This can help me out when shared projects coordinates have not been setup properly and models have not been modelled relative to the revit origin.

You should be able to download the family from here:
Location marker

Thursday, 7 August 2014

Linking projects with different shared coordinates

Differing coordinate systems.For myself I had set out to see what triggers this screen.

It's been my experience that as soon as two files have different rotation values in the project basepoint you will get the warning of different Coordinate sytems. Not True! As soon as you change any value in the project base point it goes wrong. But why does it sometimes go right?

Start a new file change the project basepoint and save the file under a name, let's call it Project A. 
Next you change the project-base-point again save that file under a another name, Project B. 
If you link Project B into project A by shared coordinates it will place project B exactly where it should land.

In fact I have been using a copy of the same file and changing any value of the project basepoint, or survey point, unclipping it, moving it and so on and I do not get this screen when I link by shared coordinates. And more surprisingly it ends up where it should.

I have tested this both in Revit 2014 and 2015. No difference I'll try to show this now in screenshots
Project A: just a floor no change to either survey or Project base point
Project A saved as Project B, but I changed the project base point N/S E/W values.

Project A saved as Project C, but I changed the project base point N/S E/W values and rotation.
Next I link Project B into Project A by shared coordinates and it lands exactly where it should. Next I link Project C into Project A by shared coordinates and it lands exactly where it should.
Now I will create a new project and setup the project base point exactly like project B but I will model a floor that should end up below Project B. 
When you link Project D into Project B by shared coordinates you will get this. 
The irony is that in the preview it does it right but once you click on the button it moves to the wrong position.
(publishing the shared coordinates from B to D fixes this problem. If you then Save Project D as Project E and you try to link Project E into project B by shared coordinates it will end up where it should, ofcourse)

Before I never had this problem because I always setup the project base point manually and I link the revit files origin to origin.

My conclusion is that something else controls the ability to use shared coordinates and that the values of the project base point or the survey point do not matter.

You would almost suggest you create one simple file at the start of the project and share this file to all companies who are going to work on the project. From a revit point of view that might work but from an organization point of view it's quiet unlikely that that is going to work. What will work is if you all model relative to the revit origin and you link your files origin to origin! Once the files are in you can use the publish and acquire coordinates function.

Friday, 18 July 2014

Project North niet meer doen

(a Dutch post this time)

Ik heb al meerdere keren geschreven over coördinaten in Revit maar graag zou ik hier toch nog maar eens een post aan willen wijden aangezien ik de laatste tijd toch veel projecten tegen kom waar het fout gaat.

Vaak krijgen architecten een Autocad tekening die op RD coördinaten staat. Regelmatig ziek ik dat er vervolgens een kruising van stramien lijnen of een of ander punt, in de tekening, wordt gekozen als referentie punt waarmee wordt uitgewisseld. Doe dat niet! Waarom niet? Je krijgt zo altijd een punt met veel decimalen. (cijfers achter de comma) Ik raad je aan om een punt te maken dat op precies hele coördinaten ligt! Dit heeft als voordeel dat je geen afrondingsverschillen hebt. Voor de xyz coördinaten vallen die afrondingsverschillen misschien nog wel mee maar niet als je met verdraaiingen gaat werken.

Het nulpunt van het RD systeem ligt niet in Parijs. Maar ten oosten van La Celle-Saint-Cyr.

Ik zie vaak dat mensen een blokje maken voor in Autocad die de coördinaten uitleest. Pas geleden zag ik een blok die dat in attributen stopte. Jammer alleen was wel dat de attribuut waarden niet overeen kwamen met de plaats waar het blokje stond. Als je field in je attributen in Autocad gebruikt dan kan je bij het plaatsen / verschuiven de waarden automatisch laten updaten.

In het verleden heb ik meerdere mensen uitgelegd hoe je coördinaten van een dwg in Revit kunt krijgen met het commando acquire. Al enkele jaren doe ik dat zelf niet meer en leg ik dat ook niet meer uit maar doe ik dit handmatig! Dit ben ik destijds gaan doen vanwege afrondingsverschillen.

Al vanaf het begin dat ik met Revit werk heb ik een redelijke hekel gehad aan het true north project north in Revit. Dit kwam vooral omdat het of net niet zo reageerde zoals ik wilde of omdat gelinkte dwgs aan de wandel gingen. Er is nog een nadeel aan true north project north. Je kan maar één verdraaiing instellen. Stel dat je een project heb waar meedere delen verdraaid staan en je zou die toch graag orthogonaal kunnen modelleren dan gaat dat niet met True North Project North. Dit gaat wel met meerdere scope boxen.

Ook een fout die ik tegen kwam was dat men coördinaten en rotatie uit een autocad tekening heeft overgenomen om vervolgens in het project met het afgeronde getal verder te werken.
De waarde was: 60,38872747670° en werd verder gewerkt met 60.389
Hieronder een een excel tabel met het effect van deze afronding:

Lees als volgt:
Als de hoek = 60° en de aanliggende is 1 meter (1000mm) dan is de overstaande 1732,05 mm (afgerond)
Als de hoek = 60,4° en de aanliggende is 1 meter (1000mm) dan is de overstaande 1760,32 mm (afgerond)
Het verschil tussen de lengte van de overstaande met een hoek 60° of met 60,4° = 28,27 mm
Als je helemaal onderaan rechts kijkt dan zie je dat:
Als de hoek = 60,3887° en de aanliggende is 1000 meter of de hoek = 60.38872747670° en de aanliggende is 1000 meter. Dan zit er tussen die twee nog steeds bijna 2mm verschil. 

Oftewel zelfs tussen 3 en 4 cijfers achter de komma gaat het al snel erg fout. Waarom zeur ik hierover? Als we een clashcontrole gaan doen die op mm kijkt dan krijg ik dus heel veel clashes. Als iedereen met dezelfde fout zou werken dan is er niets aan de hand. Maar daar gaat het nog wel eens mis. 

Als je afspreekt om geen true north project north verdraaiing toe te passen maar daarentegen met scopeboxes te werken heb je heel dit probleem niet!

mijn advies is dus, geen dwg linken in je project om coördinaten te acquiren en zeker geen true north project north toepassen. (oh en teken ook geen lijn van het Autocad 0.0 naar je situatie!!!) Wat dan wel?
  1. Maak een punt in autocad op afgeronde coördinaten .
  2. Schrijf deze coördinaten weg in een textbestand
  3. Vul deze coördinaten in bij het projectbasepoint
  4. Link de dwg met manual origin
  5. verplaats de dwg zodat het eerder vastgelegde punt op het project basepoint komt te liggen
  6. Link een (eventueel) volgend revit bestand origin to origin
  7. Publish de coördinaten van de host naar de link
  8. exporteer een 3D view naar nwc (navisworks)
  9. Append de dwg en het nwc bestand, deze moeten nu op elkaar liggen

voor een uitleg over scopeboxes (engels) kijk hier:scope box

Tuesday, 15 July 2014

sloping levels

I was busy the other day with coping some levels between projects when I ran into this view. For a second I had the impression that my levels were sloping. As far as I am concerned that's not possible in Revit 2014.

Looking a bit further I realized it was an optical illusion. I liked it and so I thought I'll share it with you.
And also a small tip: If you want to quickly fix this. Assign the levels to a scope box!

Wednesday, 9 July 2014

Scope box and levels

I recently worked on a file where the modeller had gone a little bit to happy with creating levels. All the levels were constrainted to eachother at the end. At a scale of 1:100 this made all the text unreadable. Of course I could set the scale very small to make them readable but that wasn't practical for other reasons. 

If you have to un-constrain  all these levels you might be in for quite a few clicks and annoyances. I thought let's see if I assign some of the levels to a scopebox and drag the scope box. It works and if you unassign them they stay at there new position. That saves me clicking on a whole lot of padlocks.

I was already a fan of scope boxes when I found out they could solve true north project north but now I even like them more!

Thursday, 3 July 2014

Navisworks reads pdf files

Autodesk has released a subscription app that will let you append pdf files to your project.

See download here: pdf files in Navisworks

When you have the app installed I notice a few things:
When you click the append button you will see this. 
This seems nice but if your first addition to a naviswork project is a pdf file it won't let you add 3D files. 

If you first add a 3D file, for example a nwc from Revit, navisworks won't let you add a pdf file. It says it has not 3D information. 

So how do you get them in both:
Got the project browser! There is an import button that will let you either import 2D or 3D. Once you have at least one 3D nwc file in, the append button starts to work again for 3D files. Any other pdf's have to be brought in through the Project browser. You can find the project browser here: Lower right corner

When the pdf file is in take a look at the units and transform. The units are set to Inches........... Leave it even if you have a metric sheetformat. Navisworks will import the file using the sheetsize. So you have to add the scale yourself. So change the scale and you can measure. It doesn't snap on anything on the pdf so far for me. So you have to eyeball it. Don't forget to add the scale value in both boxes. 
It's a step forward but wouldn't it be nice if you could mix pdf files and 3D files in the view canvas? Good old Autocad can read pdf files and snap to it. (if it's a vector based pdf) So the knowledge is in the factory how to do it. Get these people to talk to eachother! 

I just tried to append some 3D pdf's from various sources. They load but you only get a frontpage and no 3D model. 

Tuesday, 1 July 2014

Fixing Revit warnings

Most of you have probably experienced this many times. You have to make a big change in the model and you get an big list of errors. Some of you might choose to ignore those completely, DON'T. 

Export the errors to html and and try to fix them one at the time! There are two nice tools that will help you a lot. One native from Revit and the second is a free extension. There are many more tools that can help you out. This is just one of them.

  1. install the Auto section box extension (it's free) link: Auto section box
  2. open the saved html
  3. open a 3D view
  4. copy paste the id numbers into the select by id dialogue us ; between id's
  5. don't click on show but on OK
  6. click on manage tab --> auto section box set the buffer size (it takes the geometric extens of your selection and increases it with what you insert here
  7. OK
  8. There are your troubling elements
If you add the tools to the quick acces toolbar you save yourself some time and clicks.

Tools used:
Select by ID is located here
Paste the ID numbers
After installing, the Auto section box should be here: Add-Ins tab--> Coins
Set the buffer size
By the way this tool is also very nice for creating 3D detail views

Friday, 27 June 2014

Revit linked files and worksets

Recently I had a model that kept turning of a linked file. I was bit curious what caused this behaviour as I was under the impression that I didn't do it. Today I wanted to test something shortly with worksharing visibility in a linked file and I suddenly found out what was the cause of my earlier problem.

I made this very simple model with three worksets. I made these worksets names on purpose. (First of all I would like to point out that I never create worksets as if they are Autocad layers but for this simple test it is okay.

So what was the setup and what did I forget to do...
I have a file with a link. I selected the link in canvas and changed the workset to the one I called link_Wv
Then I turned of this workset Wall (bad name) and suddenly my link was gone... I select the link in the project browser and suddenly it became all to clear to me. I had changed the workset assignment of this instance of the link ( in the instance property window). I should have changed the workset assignment in the type properties of the link. 

So the proper setup for linked files in workset should be:
A workset for controlling the entire link and in case of multiple instances of that link you might want to create a workset for every instance of the link.

So if your linked file behaves erratic when turning of worksets, select the link in canvas and check the instance properties of the link and the type properties of the link.

An example with pics:
the link on a workset:
every instance on it's own workset

Be aware the goal of this setup is to keep the load smaller for your computer and not to controle visibility.

Google+ Badge