Hi, I have been noticing a problem with the Element.GetParameterValueByName node.
This issue did not happen before the advent of Cpython3.
I am using a code that outputs Family Types for a given category, in this case, BuiltInCategory.OST_Casework. From there, in the past I would connect the output of this Python node into the Element.GetParameterValueByName node and I would use a string codeblock to call for “Family Name”. This worked as expected before but now I obtain no values whatsoever:
I searched in this forum and found the most useful thread was this:
However, the fix is complex if you have used the Element.GetParameterValueByName in multiple occasions, as you would expect it to be the case with such a critical node. This also happens when other critical parameters are called, as for example Type Name:
To clarify the situation, the issue that I am experiencing is that Dynamo always chooses the “no value” version when I use the Element.GetParameterValueByName node, hence causing the script to fail in multiple areas.
Please advise, and apologies in advance if this has been discussed, I have not found any threads besides the above mentioned and that one would only work if the Element.GetParameterValueByName node has been used a reduced number of times, I do not see how that solution could be applied extensively.
Certain parameters exist with duplicates from other contexts/inheritances. Getting the value from one of these parameters by name is inconsistent because there’s no way to specify which one you’re after. (This has nothing to do with the python version.)
In these cases, you need to use the API to get/set the specific builtin parameter that you’re after. That’s additionally a good idea since you’re already using python in the previous node. Just continue the functionality with the parameter.
This thread has an example for a similar situation.
This issue did not happen before, same script worked flawlessly up to mid 2023.
The user on the thread you provided was using elements as input, I am working with Family Types, here’s the script for reference:
import clr
clr.AddReference(“RevitServices”)
import RevitServices
from RevitServices.Persistence import DocumentManager
doc = DocumentManager.Instance.CurrentDBDocument
clr.AddReference(“RevitAPI”)
from Autodesk.Revit.DB import *
doc = DocumentManager.Instance.CurrentDBDocument
OUT = FilteredElementCollector(doc).OfCategory(BuiltInCategory.OST_Casework).WhereElementIsElementType().ToElements()
I tried to modify the script with what you described, but I am not succeeding, I believe that user was using levels as the 2nd input IN[1] but I would like to query the parameter “Family Name”
elements = UnwrapElement(IN[0])
Level = UnwrapElement(IN[1]) #Do some action in a Transaction
TransactionManager.Instance.EnsureInTransaction(doc)
for element in elements:
element.get_Parameter(BuiltInParameter.FAMILY_LEVEL_PARAM)
SetValue = Param.Set(Level.Id)
TransactionManager.Instance.TransactionTaskDone()
OUT = element
Any help with this would be much appreciated. I attached the DYN below in case you could take a look.
Thanks ElementGetParameterValueByName.dyn (6.5 KB)
You just got lucky. This issue has been around forever. It’s part of the reason why you should never use parameters with duplicate names. (Even though Autodesk obviously does or we wouldn’t be here.)
Both cases are about elements with duplicate builtin parameters. The specifics don’t make any difference here.
The only thing you need to use from that example is the method for getting a builtin parameter directly.
They wanted the Level of the element so they used FAMILY_LEVEL_PARAM. If you want the user readable Family Type, then you need to provide the enumerator for that specific builtin parameter.
I actually just checked and Family Name isn’t even one of the duplicate builtin parameters. You have a custom parameter with that name somewhere (which is also why only one of the Family Name parameters has a negative Id). Clean that up if you don’t need it and everything will work again. Otherwise you’ll have to use the builtin parameter method I mentioned to get the correct parameter - or filter the parameters if you really want to avoid the python solution I guess…
Understood. I appreciate your help.
I do not want to avoid any python solution, simply put I don’t know how to code.
I need to find what parameter you are referring to, I have tried with SYMBOL_FAMILY_NAME_PARAM, but again, I am not familiar with this, it’ll take me a while. I will also eliminate that redundant parameter, I will report here in a bit.
Thanks again
No worries. That’s why we’re here to help, but we can only help if you provide enough information for us to know what you’re doing. A screenshot of your code and what errors or outputs you’re getting and we could likely tell you what the issue is.
I appreciate. This may be a lengthy explanation, apologies in advance.
This is a script developed to configure cabinetry. In this particular version I arranged it so that it could work with model groups. In doing so, I had to avoid nested shared components for the cabinetry front panels, it still uses nested panels, but they are not shared.
The script uses mainly Data-Shapes nodes for User Input to set parameters like materials for different parts of casework families. Everything went smoothly until I had to provide a drop down for panel types.
Interestingly, if I loaded the panels as independent families (not shared) Dynamo would let me use them in the families. Usually this can only be done with nested shared components, but Dynamo would bypass the ones present inside of each family and plug in the outside panels instead.
This is the reason why I had to use the Element.GetParameterValueByName to retrieve all casework and then filter down to the ones that contain a specific prefix in their Family Name or Type Name, etc, and I believe the duplicates may be coming from there, since both the family and the nested component have such built in parameters, I doubt I created a custom parameter with the same name as a native one, but I will for sure double check.
I will try to provide a reduced Revit file and a reduced script here asap.
Thanks again
Pretty sure that we don’t - we use built in parameters which have unique names. What we don’t do is restrict parameter names to enforce they are always unique. This is a good thing when it comes to collaboration - otherwise it would be ‘first parameter named wins’ for all parameters which would prevent you from using families from multiple source libraries (i.e. from your firm library and my firm’s library / manufacturers’ libraries / consulting firm’s libraries / old project libraries / etc.) without requiring data loss.
Some (most? all?) instance elements have duplicate builtin Category parameters. They have the same Name (Category) but different a different BuiltInParameter enum (ELEM_CATEGORY_PARAM_MT vs ELEM_CATEGORY_PARAM).
Level also shows up twice for elements with a Schedule Level (SCHEDULE_LEVEL_PARAM vs FAMILY_LEVEL_PARAM).
Those are the two I can remember running into off the top of my head.
Hi, thanks all.
Nick, I really don’t know what is going on, so I downloaded a cabinetry from Autodesk, out of the box, and run the script again, just to see if a completely unrelated family would not show two values for the Family Name and Type Name parameters.
They still show 2 entries, one of them empty. But that’s on a copy of my Revit template.
When I create a new project and repeat the operation (with standard Autodesk casework), the duplicated values disappear, so it may be related to my template and the fact that I introduced panels in some families as nested components that were not shared. That seems to create duplicated parameters on all families, even when they are loaded as not standard content from my template.
I’ll continue to look into this tomorrow, I will try to retrieve the built in parameter as you suggested above, using the SYMBOL_FAMILY_NAME_PARAM as value string, etc.
Thanks again
That was it, you got it right. I had introduced 2 Project Parameters, Family Name and Type Name, they were shared parameters, once eliminated the script went back to working as intended.
The reason why I created those parameters is for scheduling purposes, since until recently Revit would not allow to filter by such parameters.
I apologize for the confusion and the time taken from you and Jacob, my bad, I should have not attributed the problem to Python, that said I did learn a lot from this, I appreciate your help, lesson learned. Best regards
