Worksharing en Worksets

In Revit heb je de keus om wel of niet met Worksharing te werken. Standaard is deze niet ingesteld. Maar wat zijn nou redenen om Worksharing te activeren en wat is de Best Practice?

Worksharing houd in dat er 1 Central File is, die met 1 of meerdere Local Files samenwerkt. Dit gebeurt, door een gebruiker de rechten over een onderdeel van het Project te geven. Deze gebruiker blijft vervolgens de eigenaar, totdat deze gebruiker de rechten bewust weer teruggeeft. Wijzigingen dienen gesynchroniseerd te worden met de Central File. Eenvoudigweg opslaan en afsluiten zorgt er niet voor dat de Central is aangepast. Behalve dan, dat de gebruiker nog steeds eigenaar is van enkele onderdelen in die Central File (met alle beperkingen van dien).
Onderdelen die door Worksharing worden gedeeld en beheerd zijn, behalve gemodelleerde elementen, Views, Families in een Project, Project Standards en zogenaamde User-Created Worksets. Deze Worksets worden vaak gebruikt om een Project in stukken op te delen. Elk stuk heeft dan een eigen Workset.

Waarom zou je met Worksharing gaan werken?
In principe moet je dingen doen met een reden. En dat geld ook voor Worksharing. Hopelijk kan ik in deze Post uitleggen waarom in bijna alle gevallen Worksharing is aan te raden.

Werken met meerdere mensen.
Als er met meerdere mensen tegelijk aan 1 project gewerkt moet worden, ontkom je bijna niet aan het gebruik van Worksharing. Daar is deze functionaliteit tenslotte ook naar vernoemd.
Worksets geven ook mogelijkheden om het beheer van een Project beter te regelen. Je hoeft ten slotte niet alle rechten weer terug te geven. Het wordt hier wel een beetje tricky, maar iemand die weet wat hij doet, en wijzigingen wil blokkeren (kijk uit dat het niet frustreren wordt) kan shared onderdelen op slot zetten. Zelf heb ik dit laatst in overleg gedaan. 1 Specifieke Schedule heb ik op slot gezet, omdat we deze Schedule gebruikten voor communicatie met Excel. Om het helemaal op slot te zetten meer uitleg via deze link.

Links
Een punt wat ik hier ook wil noemen, is de internationale Best Practice om gelinkte bestanden op een eigen Workset te plaatsen. Een van de redenen is dat Worksets  lokaal worden beheerd. En een Link in de Central wordt beheerd. Als 1 gebruiker een Link Unload heeft dat naderhand consequenties voor een collega. Het sluiten van de Workset van een Link op lokaal niveau heeft geen directe consequenties voor een collega. (totdat deze weer een nieuwe Local aanmaakt. Deze is op basis van de laatst gesynchroniseerde instellingen)
Verder kan je een Central die gelinkt is in een andere Central nog steeds benaderen  via een Local. Dit kan handig zijn. Als de link geen Central is, wordt dit proces veel lastiger. Verder lezen via deze link.
Wanneer een project met Worksharing als Link wordt gebruikt, kan je in die Link, alle afzonderlijke Worksets openen en sluiten. Dit heeft veel voordelen, als je met verschillende partijen moet samenwerken. Een constructeur wil al de stoeltjes van een architect niet zien. En een architect wil misschien de funderingspalen uitzetten in zijn mooi opgemaakte aanzichten.

Performance.
Ja, zegt iemand, ik werk maar in mijn eentje aan een project.
Dat kan. Maar met Worksharing ben je in staat een groot model op te knippen in behapbare stukken. Delen waar je niet aan werkt, of onderdelen die op dit moment geen toegevoegde waarde hebben, kan je in een Workset zetten en deze Workset sluiten. Op die manier blijft je model lichter en sneller. In de oude Best Practice van de RevitGG gaven ze bijvoorbeeld aan, dat je een Workset kan aanmaken voor Inrichting en Terrein. En misschien wil je de totale fundering ook niet op alle momenten zien.  Al met al heeft het uitzetten van een Workset meer effect op de performance dan het verbergen of uitzetten van een bepaalde Category.
Een ander aspect met betrekking tot performance, is de mogelijkheid, om maar een deel van een Project te openen. Wanneer je een Central File aanmaakt, heb je onder Options de mogelijkheid om m.b.t. Worksets te kiezen voor Specify… Het kan irritant zijn als het niet nodig is, maar bij het openen van een Local krijg je vanaf nu de vraag welke Worksets je deze keer wil openen en sluiten. Dit is voor grote en zware projecten wel aan te raden.
Wat we ook vaak doen is Worksets alleen zichtbaar te maken in specifieke Views. Deze schakelaar kan je weer in View Templates onderbrengen. Onze terrein Workset, is bijvoorbeeld niet in alle Views zichtbaar. Alleen daar waar we in de visibilty settings specifiek hebben aangegeven dat deze wel zichtbaar moet zijn. Soms werkt dit lekkerder dan via een Category of een Filter.

Backup
Tja. Maar ik werk alleen. En aan kleine overzichtelijke project. Er zitten zelfs nauwelijks Links in mijn Project.
Zo langzamerhand kom je dan op het niveau van Revit LT uit. Maar Worksharing heeft nog steeds voordelen. Via Worksharing heb je meer mogelijkheden om een Backup terug te halen. Van elke synchronisatie wordt de gebruiker en de tijd geregistreerd en kan worden teruggehaald. Deze synchronisaties zijn lichter dan de standaard volledige Backup. Ook kan je opmerkingen aan een synchronisatie meegeven. Dit is voor sommige Revit gebruikers een Best Practice. Al moet ik zeggen dat ik het zelf eigenlijk nooit doe. Je kan overigens een Local ook openen en de Relinquish from Central aan te vinken. Deze staat dan op zichzelf volgens de laatste opgeslagen variant. Op deze manier kan je dus ook een bepaalde stand terughalen.

De andere kant..
Als je een systeem start moet je jezelf er ook aan houden! Het is weer een extra onderdeel om te controleren. Een tip om Worksets te controleren is via een 3D view met 1 Workset aan. Ook zijn er tools zoals bijvoorbeeld van db-Stuff om e.e.a. te controleren. Besef wel dat als met Groups werkt een hele Group op dezelfde Workset staat. Reference Planes in een Model Group komen dan niet mooi onder Levels and Grids te staan.
Wereldwijd zijn er genoeg voorbeelden van mensen die helemaal los gingen op Worksets. Een Twitter bericht die me bijgebleven is: Als je meer vergaderingen moet houden over Worksets dan dat er Worksets zijn, weet je dat er te veel Worksets zijn.
Worksets zijn niet de tools bij uitstek, om de zichtbaarheid mee te beheren. Maar ze kunnen er wel een beperkte rol in spelen. Worksets zijn te grof en te bewerkelijk in het gebruik om heel nauwkeurig de zichtbaarheid in een project mee te kunnen beheren. Dus geniet maar met mate.

Een ander gebruik van Worksets is om onderdelen die in de loop van het proces van de ene adviseur overgaan naar een volgende adviseur  mee te beheren. Alle onderdelen in een Workset zijn snel te selecteren en te kopiëren of te verwijderen. Je zou er zelfs nog voor kunnen kiezen om dit soort onderdelen nog even in je project te laten zitten in een Workset die op de Plots permanent uit staat en in basis gesloten is. Al moet je jezelf wel afvragen waarom je deze onderdelen zou willen laten staan. Geen Best Practice.

Inhoudelijk ben ik niet echt op Worksharing of Worksets ingegaan, naast een paar tips.
Om verder te lezen zou je hier het document van Brian Andresen voor LA Revit User Group kunnen lezen.

Gelezen - rondlopende arceringen in Revit - Enjoy Revit

Voor iedereen die nog geen kennis heeft genomen van deze tip via andere kanalen.

HyunWoo Kim van Enjoy Revit legt op zijn blog uit hoe je een rechte arcering ook rond kan laten lopen . Dit komt bijvoorbeeld voor bij ronde metselwerk boogjes.

Zelf meteen maar eens uitgeprobeerd. En het werkt best.
Het principe van de rondlopende arcering is dat de arcering zich evenredig verdeeld over de bolling van een bol of hol vlak.

Een boog of een Segmentboog gaat prima. Ik heb zelf een Revolve gebruikt. Maar er zijn ook andere mogelijkheden. Eventueel voorzien van parametrische flexibiliteit.

een "Segmentboog"

Wat lastiger was de Hanekam. Zie voor enkele technisch achtergrond van de Hanekam hier en hier.
Een Hanekam zonder stootvoegen lukte redelijk.
Dit kan met bijvoorbeeld een Void over de Segmentboog heen.

een "Hanekam"

Maar met stootvoegen lukte het mij in eerste instantie niet. (zonder losse lijntjes toe te voegen dan)


nou ja.. bijna dan

Enjoy Revit is trouwens een leuke blog om eens rond te neuzen. Want hij doet meer bijzondere dingen met Revit. Denk aan Railings, formules, en Adaptive Families (zoals Spanish Tiles the insane version ;-) ).
Keep up the good work!

Schaalbare Revit Family voor een Logo

Al meer dan een jaar zijn de slimste Revit gebruikers op zoek naar manieren om een Revit Familie te kunnen schalen. Want nee, dat is niet vanzelfsprekend. Komt het dan vaak voor dat een Familie geschaald moet worden? Nee, niet echt.
In deze Post wil ik graag een praktijk voorbeeld meegeven. Een schaalbaar 3D logo. Een concreet voorbeeld waar mijn collega Pieter Schipper mee aan kwam zetten. En die we samen hebben opgelost.

Maar eerst een kort stukje theorie. Er zijn meerdere manieren gevonden om een Familie te schalen. Hierbij een link naar een overzicht van verschalingsmogelijkheden op andere Blogs.

• Better Revit - Bigger or Smaller

Globaal zijn de oplossingen als volgt:

•  Een Spline is schaalbaar aangezien de vorm in tact blijft als het begin of eindpunt verplaatsen.
•  Een (niet Shared) Planting Familie in een ander Planting Familie is schaalbaar via de Type Parameter Height.
•  Een Adaptive Familie kan bepaald worden door Reference Points op een Reference Line. De positie van de Reference Point kan vastgezet worden op een specifieke verhouding tot de lengte van de Reference Line. Zo kan je een framewerk maken voor een schaalbare en Adaptive Family.



Revit Scale functie onder Modify

Enkele elementen in Revit die wel schaalbaar zijn:

•  Een Sketch
•  Meerdere vormen van Inserts zoals Images, DWG, DXF’s.
•  Model en Annotation Lines
•  Walls
•  Reference Planes
•  Dimensions

Een schaalbare 3D Logo
Het schalen van 3D logo's deden we voorheen door de Sketch van de Extrusion te schalen. Maar het kan waarschijnlijk nog eenvoudiger, via de Planting in Planting methode, zoals hierboven genoemd.
De Planting in Planting methode is een beetje vreemd. Revit verschaald de nested Planting Family totdat de hoogte van deze nested Family overeenkomt met de waarde van de Type Parameter Height in het Project.

In ons geval is dit dus direct het probleem. Want wanneer we een Logo verschalen willen we niet dat deze dikker wordt. De Z-waarde moet intact blijven terwijl de X en de Y-waarde wel mee schalen. Na wat puzzelen, denk ik dat we een redelijk goede oplossing gevonden hebben. We corrigeren de hoogte van de Solid, met dezelfde factor als waar de rest van de Family mee wordt verschaald. Wat je hiervoor nodig hebt is een referentiemaat. Deze heb ik in de nested Family gezet. Het is de maat tussen het Level en een Reference Plane. Deze Reference Plane ziet Revit als de bovenkant van de Family en moet dus uitsteken boven de geometrie. Zie ook het voorbeeld.



Een voorbeeld van de instellingen van de nested Planting Family

De referentiemaat wordt vergeleken met de doorgekoppelde Height (vanuit het Project, via de Planting Familie naar de nested Familie). Hieruit een volgt een factor waarmee we de gecorrigeerde hoogte van de geometrie bepalen. Als de Familie groter wordt, wordt de hoogte van de geometrie evenredig kleiner. Zie het voorbeeld. Let wel op dat de hoogte niet te kein wordt, want daar houd Revit niet van. Beter kan je het logo zo groot tekenen dat je deze eerder kleiner wil maken dan groter.


De Parameters en formules van de Family

Lastig is dat je soms foutmeldingen krijgt bij het invoeren van de formules. De melding Inconsistent Units betekend dat de Parameters een eenheid hebben, die niet direct met elkaar te verrekenen is. Met behulp van een eenvoudig truckje, kan je dit snel oplossen. Door de Parameter met 1 te vermenigvuldigen of te delen, maak je de Parameter eenheid loos en werkt de formule weer.
Om de Familie nog vriendelijker te maken, zou je de gewenste uiteindelijke hoogtemaat voor in het project ook door kunnen koppelen.


Doorkoppelen van de hoogte Parameters

Een andere aanpassing zou kunnen zijn om de beide Reference Planes, de eigenschap Not a Reference mee te geven. En vervolgens een not Visible Model Line te locken aan de Reference Plane die de referentie hoogte bepaald. Dit voorkomt dat je in je project de Planting Familie kan selecteren op grote afstand, door de sterkte van de Reference Plane.



Not Visible Model Line toevoegen en de Reference Planes Not a Reference maken

Ook zou je het logo niet op het Level in Plan View, maar juist in een aanzicht kunnen tekenen. Op die manier beïnvloed je direct of de hoogte, of in gedraaide toestand de lengte van het logo.



Logo aanpassen in het project Height = 500

Logo aanpassen in het project Height = 1000

Logo aanpassen in het Project Height = 1000 en H_project = 50

Een andere grappige, maar minder relevante mogelijkheid, is als de Height van een Planting Family wordt doorgekoppeld naar de daadwerkelijke hoogte van de geometrie in de nested Planting Family. Op die manier schaal je alleen de z-waarde mee en niet de de x en y-waardes. 

Constraints are not satisfied

‘Constraints are not satisfied’ Kent u die uitdrukking dames en heren?

Ik hoor al gillen op de achtergrond. Het is dan ook een erg vage, en vreselijk irritante melding, bij het maken van een Revit Family. Revit bepaald op de achtergrond wat u wel en niet mag doen. En ja computers maken geen fouten. Dus het ligt echt aan ons. Zucht. Laten we dan maar proberen iets van de mechanismen van de constrains in Revit (via trail en error) te achterhalen. Kan dat ook slimmer? Vast wel…

Ik heb voor de testjes enkele Parameters aangemaakt met de volgende vernuftige benamingen:

• Type_Lock
• Type
• Instance_Lock
• Instance

Om het mezelf moeilijk te maken (en om te laten zien hoe fout Revit lijkt te zijn) heb ik ze allemaal een lengte van 500m meegegeven. De Instance_Report Parameter is te flexibel en is daarom niet relevant.

De Parameters

In het testmodel  gebruik ik losse maatvoering. En maatvoering met een Equality. Ooh wat zal ik fijn veel foutmeldingen krijgen! Om het verder zo zuiver mogelijk te houden, maatvoer ik Reference Planes die allemaal de eigenschap Not a Reference hebben.

Het doel van deze hele exercitie is om de Revit Constraints in een Family te onderzoeken. Hopelijk kunnen we daar lessen uit trekken, om foutmeldingen zo veel mogelijk te beperken.
Waar ik niet aan toekom is de impact van Formules. Maar ook de invloed van de sterkte eigenschappen van Reference Planes etc. Ik concentreer me vooralsnog op de maatvoering.


De basis: je kan prima de Label vervangen door een andere