What is the significance of the "LOCK" toggle in the family edit dialogue? When would you lock a parameter or not? also, what's the benefit of utilising shared parameters? Is it just a scheduling thing or to keep consistent parameter naming conventions across an organisation?
Shared parameters enable cross project data structures, which enhance scheduling, tagging and computational accesdibility for tools like dynamo. I use them extensively in all my work. The lock toggle tells revit whether it should try to maintain this dimension as other parameters change in the family, e.g. if a handle is stretched, does the parameter maintain its value and get dragged along (lock) or does it flex to allow the plane to move independently. Noting this is only in the family editor itself. revitforum.org/showthread.php/3720-Locking-Parameters-in-the-Family-Types-Dialogue-Box
Is there any way to limit users to only three or four materials? say this table came in red, white, or wood. And what if this table had four styles, each could come in any three of the colors. Is there a way to do that without having to create 12 types?
Unfortunately not. A swift rap on the knuckles and some training i guess! If your material parameters aren't shared you can add a tooltip that lists the valid materials they should use maybe? Otherwise beyond that using a key schedule with delimited finish scheme options and a dynamo script to push the equivalent material to the object based on what is selected is the only other way i can think of, but its very convoluted.
A few years back with the creation of the UK Level 2 protocols, now an international standard ISO-19650, they were promoting the use of the Uniclass 2015 classification system. Even though Revit has imbedded Omniclass it may be something to think about to push back into the families somehow.
Hi Gavin, I have a question about Nested switching family, I’m not sure if it is possible to do, I have searched throughtout the internet I haven’t found any similiar situation as I’m looking for How can I set up a family type to switch its type by itself in case it measure get changed in the project? For example if there is one steel beam connecting two columns. Let’s regard that the distance between two columns is 3000 mm and for this far distances I have to use BEAM A. So I realised that the dsitance between the columns have to be 5000 mm instead. But for that far distance I need to use BEAM B that is pretty much the same as BEAM A, but with different features as self weight and data ID. Both of BEAMS are a family nested with different types. So How could I create a parameter to limited the length of and switch to the beam which suits the length required in the project? I’ve tried to use the syntax according to each beam lenght, but the software doesn’t allowed me to create a syntax with the Length parameter which is a standard parameter in the structural framing template family. I've accomplished something similar but still not the suitable as I want to. I've created the beams in the generic template and it's shared parameters, loaded into a structural framing template and created a family type parameter to each and used a syntax for the length. But I couldn't get the shared parameters created in the generic beams. Is there a better way of doing that? Cheers.
Hrm tricky, I'll have a look into what can be done this morning... I believe it may be possible to embed a shared parameter into a formula related to length. If not, Dynamo is likely the best option. Will get back to you!
Hi there, I'm tried looking for the Tutorial you mention early in this video about "shared parameters" in your channel and I'm not able to find it. May be you change the name of it? Would it be possible to share the link to the video or re-post it?
Typically this warning is caused by trying to add a parameter or locked dimension where it isn't needed, or isn't possible to be flexible (e.g. the leftover space between two reference planes constrained by other parameters to different reference planes). If you need a fairly brute force solution, this should work: forums.autodesk.com/t5/revit-structure-forum/overconstrained-geometry-problem/td-p/4666459
Hey Gavin, Sorry to bother you (again and again...)! This time I actually have a couple of questions: 1) Type Image location - where should we store this files? if they get deleted from the server they disappear from the family? what is a good file size for the image? I think this would be quite useful in a plumbing fixture schedule for example. 2) Type name with sizes - How in your experience is this working? Because in mine people usually don´t bother to change the name to match the actual dimensions and it just becomes really messy :/ 3) Type parameters locked vs. Instance Reporting - I've encountered some problems when setting some fixed dimensions (ex. frame thickness of a specific door/window). I've used a shared parameter and then made it instance reporting because we might want to see it but we will not change it. But then this fields are not available to use in formulas... Is that why you use type parameters and lock them instead? 4) Cost - I find this to be too generic, as the price can be by unit or per sqm. I've created a shared parameter (ex: Cost/m2 and Cost/unit) and then used the built-in Cost to actually calculate the "final price", although there is also the question if we should add with or without VAT... Thank you for letting us pick your brain! :)
No problems! 1. I would store these in a subfolder within the category folder, or at the same level as the family storage. Ideally name image with some sort of system about the product it represents (so don't name it the same as the family), as you may have more than 1 version of what a family represents. 2. When the family type is heavily determined by its size then definitely should be included. For example doors, joinery, windows, concrete structure. 3. Reporting parameters are intended to be used for reference elements underlying the family, for example the wall faces in a door family template. Usually for 'vision' parameters like the area of an object, or a resultant dimension I would build this out for formulae if I need it in a formula. 4. Yes I have a second cost and costrate parameter as well for use when relevant. One issue with cost is it is always a type parameter, but sometimes needs to be instance (e.g. for a structural beam).
![Ice On My Teeth - ATEEZ エイティーズ 에이티즈 [Music Bank] | KBS WORLD TV 241115](http://i.ytimg.com/vi/c-n92OgbbwA/mqdefault.jpg)
Another usefull tutorial with a lot of practical info's, Thank you Aussie
No worries, thanks for watching Tomasz 😀. Video on shared parameters out tomororow - hope you enjoy it!
What is the significance of the "LOCK" toggle in the family edit dialogue? When would you lock a parameter or not? also, what's the benefit of utilising shared parameters? Is it just a scheduling thing or to keep consistent parameter naming conventions across an organisation?
Shared parameters enable cross project data structures, which enhance scheduling, tagging and computational accesdibility for tools like dynamo. I use them extensively in all my work.
The lock toggle tells revit whether it should try to maintain this dimension as other parameters change in the family, e.g. if a handle is stretched, does the parameter maintain its value and get dragged along (lock) or does it flex to allow the plane to move independently. Noting this is only in the family editor itself.
revitforum.org/showthread.php/3720-Locking-Parameters-in-the-Family-Types-Dialogue-Box
Is there any way to limit users to only three or four materials? say this table came in red, white, or wood. And what if this table had four styles, each could come in any three of the colors. Is there a way to do that without having to create 12 types?
Unfortunately not. A swift rap on the knuckles and some training i guess!
If your material parameters aren't shared you can add a tooltip that lists the valid materials they should use maybe?
Otherwise beyond that using a key schedule with delimited finish scheme options and a dynamo script to push the equivalent material to the object based on what is selected is the only other way i can think of, but its very convoluted.
A few years back with the creation of the UK Level 2 protocols, now an international standard ISO-19650, they were promoting the use of the Uniclass 2015 classification system. Even though Revit has imbedded Omniclass it may be something to think about to push back into the families somehow.
Yes these days I have switched over to Uniclass 2015 using assembly coding.
Hi Gavin,
I have a question about Nested switching family, I’m not sure if it is possible to do, I have searched throughtout the internet I haven’t found any similiar situation as I’m looking for
How can I set up a family type to switch its type by itself in case it measure get changed in the project?
For example if there is one steel beam connecting two columns. Let’s regard that the distance between two columns is 3000 mm and for this far distances I have to use BEAM A. So I realised that the dsitance between the columns have to be 5000 mm instead. But for that far distance I need to use BEAM B that is pretty much the same as BEAM A, but with different features as self weight and data ID. Both of BEAMS are a family nested with different types. So How could I create a parameter to limited the length of and switch to the beam which suits the length required in the project?
I’ve tried to use the syntax according to each beam lenght, but the software doesn’t allowed me to create a syntax with the Length parameter which is a standard parameter in the structural framing template family.
I've accomplished something similar but still not the suitable as I want to. I've created the beams in the generic template and it's shared parameters, loaded into a structural framing template and created a family type parameter to each and used a syntax for the length. But I couldn't get the shared parameters created in the generic beams.
Is there a better way of doing that?
Cheers.
Hrm tricky, I'll have a look into what can be done this morning... I believe it may be possible to embed a shared parameter into a formula related to length.
If not, Dynamo is likely the best option.
Will get back to you!
Solution sent via Linkedin, let me know how it goes!
Hi there,
I'm tried looking for the Tutorial you mention early in this video about "shared parameters" in your channel and I'm not able to find it. May be you change the name of it?
Would it be possible to share the link to the video or re-post it?
I have a class on shared parameters here; ruclips.net/video/ORUJqpIGkIU/видео.html
@@AussieBIMGuru Thanks, I asked about the video just in case it had different content that's all. I was planning to watch that one too! Thanks again!
How would you work around the 'model is overconstrained' warning?
Typically this warning is caused by trying to add a parameter or locked dimension where it isn't needed, or isn't possible to be flexible (e.g. the leftover space between two reference planes constrained by other parameters to different reference planes).
If you need a fairly brute force solution, this should work:
forums.autodesk.com/t5/revit-structure-forum/overconstrained-geometry-problem/td-p/4666459
@@AussieBIMGuru Wow that makes sense. Thanks for cleaning that up!
@@andrewolivo3876 you're welcome! Been in the same situation many times ;)
Hey Gavin,
Sorry to bother you (again and again...)!
This time I actually have a couple of questions:
1) Type Image location - where should we store this files? if they get deleted from the server they disappear from the family? what is a good file size for the image? I think this would be quite useful in a plumbing fixture schedule for example.
2) Type name with sizes - How in your experience is this working? Because in mine people usually don´t bother to change the name to match the actual dimensions and it just becomes really messy :/
3) Type parameters locked vs. Instance Reporting - I've encountered some problems when setting some fixed dimensions (ex. frame thickness of a specific door/window). I've used a shared parameter and then made it instance reporting because we might want to see it but we will not change it. But then this fields are not available to use in formulas... Is that why you use type parameters and lock them instead?
4) Cost - I find this to be too generic, as the price can be by unit or per sqm. I've created a shared parameter (ex: Cost/m2 and Cost/unit) and then used the built-in Cost to actually calculate the "final price", although there is also the question if we should add with or without VAT...
Thank you for letting us pick your brain! :)
No problems!
1. I would store these in a subfolder within the category folder, or at the same level as the family storage. Ideally name image with some sort of system about the product it represents (so don't name it the same as the family), as you may have more than 1 version of what a family represents.
2. When the family type is heavily determined by its size then definitely should be included. For example doors, joinery, windows, concrete structure.
3. Reporting parameters are intended to be used for reference elements underlying the family, for example the wall faces in a door family template. Usually for 'vision' parameters like the area of an object, or a resultant dimension I would build this out for formulae if I need it in a formula.
4. Yes I have a second cost and costrate parameter as well for use when relevant. One issue with cost is it is always a type parameter, but sometimes needs to be instance (e.g. for a structural beam).