Revit kan natuurlijk niet denken… Maar Revit bepaald in veel gevallen wel wat het “logische” gevolg van je keuze is. En speelt daar op zijn eigenwijze eigen wijze op in. Daarom is het goed te beseffen hoe Revit reageert en daar bewust op in te spelen.
 |
| Logica |
Om zichtbaar te maken wat het bereik is van een brandslanghaspel wilde ik in de Family een cirkel opnemen met een straal die afhankelijk is van de lengte van de brandslang. Volgens de Nederlandse regelgeving is daar een eenvoudige formule voor:
Het bereik van de brandslang is de lengte van de brandslang plus de worp van het bluswater, gedeeld door een veiligheidsfactor (in verband met de stugheid van de slang, inrichting etc.). Dit zou je als volgt in een formule kunnen gieten. B=(L+5)/1.5
In mijn Family maakte ik dus B en L als Type Parameters aan. L Is voor zijn Type Name de maatgevende Parameter. En B is de resultante van L. En B bepaald de straal van de cirkel in de Family. Ik verwachte dat B niet in te vullen zou zijn, aangezien deze via een formule wordt berekend. Maar niets is minder waar. B is wel in te vullen. En nog erger L veranderd als ik B aanpas! Blijkbaar legt Revit een (omgekeerde)relatie die ik niet nadrukkelijk zo heb bedoeld.
Voor Revit geldt de
ingevulde B=(L+5)/1.5 net zo goed als de NIET ingevulde L=(B/1.5)-5.
Tja… Is deze omgekeerde relatie altijd waar en logisch? Wil ik dit ook? En zo nee, wat moet ik dan doen?
Is deze omgekeerde relatie altijd waar en logisch? …
Nee. Niet in alle gevallen.
B kan in alle gevallen het resultaat zijn van L. Terwijl L niet in alle gevallen het gevolg is van B. Bijvoorbeeld omdat niet alle waarden voor L juist zijn. Ook dat is wiskunde.
In dit geval zijn er inderdaad beperkingen aan L. De lengte van een brandslanghaspel is namelijk beperkt tot gangbare maten. Dat zijn 20, 25 en 30m1. Bovendien mag een brandslanghaspel wettelijk gezien niet langer zijn dan 30m1.
Daarnaast kan het best zijn dat L nog meer relaties heeft die bepalender zijn voor L dan alleen B. maar dat is hier niet het geval.
Wil ik dit ook? ...
Nee. Eigenlijk
niet. Want de omgekeerde relatie klopt hier niet. En het is in de
projectomgeving ook niet zichtbaar dat er een omgekeerde relatie aanwezig is.
Het kan dus tot ongewilde fouten leiden. Bovendien is het bepalen van het
bereik maar een tijdelijke actie met het doel om te kijken of de hele plattegrond
te bereiken is. Niet alleen om te kijken of we de lengte van de
brandslanghaspels kunnen minimaliseren of zo. Het blijft een ruwe controle die
gewoon moet voldoen.
Dus wat moet ik
hiermee doen? …
Het blijkt dat er
enkele oplossingen zijn om de B parameter te blokkeren als direct resultaat van
L. Zie ook de afbeelding. In de eerste plaats kan je in de formule een 2e
parameter opnemen zodat de directe enkelvoudige relatie tussen L en B wordt
onderbroken. Daarnaast kan je een totaal onbenullige “IF” statement gebruiken.
Wellicht zijn er nog meer.
Ten slotte.
Een collega suggereerde dat deze omgekeerde relatie ook speelde bij de Type Yes/No Parameters. Dit blijkt niet zo te zijn als je de afbeelding bekijkt. En wat mij betreft is dit terecht.
Wel hopen we beide dat er in de toekomst een keuzemogelijkheid komt voor het invullen van parameters. In dit geval (en veel andere) zou het de kwaliteit (eenduidig, eenvoudig en juist) ten goede komen.
Geen opmerkingen:
Een reactie posten