How is this possible?
The tags are obviously listed as instances, yet the list of their parameters is a repeating list of their type parameter?
That is why the Workset parameter return Nulls, because Types do not have that parameters…
By the way, yesterday it was working… same nodes, I could see the workset names in the Parameter.ParameterByName node…
thanks
I think tags are view-based elements, and their workset is the view they are placed on. The workaround for you might be retrieving that with Element.OwnerView nodes.
Thank you habdirad,
yeah, I know, that is why I need the workset of those tags, because they tell me the view they are planed in…
Following up, I cannot collect the tags in the model…
Again, I remember this was working at some point… like in the screen shot above?
Internal error has occurred is the error message… could this be related to the number of tags in the model?
This is all such a train wreck…
thank you
Use the ꟿ Collect.ElementsInView to collect the tags on linked elements.
The OOTB All Elements of Category node works only with tags on elements of current model.
There have been issues with Tag categories and the All Elements of Category node lately. Use an alternative method.
As @habdirad mentioned, you actually want Element.OwnerView from Clockwork.
Of course tags have valid worksets, in a workset enabled project:
Instance workset is the view, type workset is the tag’s family.
The entire point of what I need to do is find tags with a specific instance Worsket, because that is where you can tell in what view the tags are located.
Visibility in view includes only tags within the view boundaries, however (as all you Revit veterans must know), it is very easy to find hundreds of tags beyond the view boundaries, after dozen of people worked on a large project for months.
This is the cleaning I trying to do, and I can do it with OOTB tools (mainly: select all instances in project, save selection and then remove from selection set the tags that I wish to keep. Then, delete tags in resulting selection set).
It worked for stair paths (we had over 18,000 instances, while we needed only a few hundreds), but wall and door tags are too many and dispersed in too many views, so I was trying to save time using dynamo.
Which does not save time at all, but it does make you feel really good when the script finally works as expected.
Now, I begun my script on a test project, and it worked great, as expected:
then tried on the actual project, and the All Elements of category would fail. Hence, I spent hours debugging and finding alternative solutions, but the issue must be numbers and dynamo, because several nodes involved with getting the instances of the tags, fail or return the tag’s type, instead (see previous screenshots…)
It’s hard to say, if it is a mater of number of tags, and what that number is, because I cannot recreate a project with thousands of tags just to test the damn thing. I don’t get paid to do this work, I am not a programmer or beta tester…
thanks
gio
Haha oops. Didn’t realize my test model wasn’t workshared yet. You are correct. However, it still stands that getting the OwnerView may be more straight forward. As I mentioned before, there is currently a bug with All Elements of Category getting Tag elements; this will likely require you to utilize python or a custom node to collect your tags.
Also, the Element.AllInstances node is working correctly. It may be a little confusing, but it gets all Instances (not FamilyInstances) of a specific Element (not FamilyType). The element you provided is a FamilyType and FamilyTypes obviously only have one instance in a project. If you had provided a single FamilyInstance it would have returned all matching FamilyInstances. The node you were looking for is FamilyInstance.ByFamilyType.
I am really struggling today… 
That being said, FamilyInstances show the tag name (type name) in Dynamo, but you can see they have different element Ids, so they are separate instances.
After further testing, the script is partially working on the large project as well, except the before mentioned fail of the “All element of category” node specifically with large numbers of Wall Tags.
Large numbers of other tags work as expected.
The interesting thing is that different nodes, from different packages, for different purposes, also fail with large number of Wall Tags.
For example, I tried to feed to the script the current model selection, using “Springs.Collector.CurrentSelection” and it works for small numbers, but it fails for large number of Wall Tags.
I think it’s some weird bug in the API, or in Dynamo…
In your large project are there instances of wall tags associated to linked elements?
Jacob,
yes, it looks like tags to linked elements do not collect properly… bummer.
I tested the “Springs.Collector.CurrentSelection” node from Springs, and it returns Null for any tags pointing at a linked model, which is weird because the tag is actually live in the current model…
So, it’s not about the number of tags, or type of tags, its (yet again) about linked models…
This is bad because I cannot just screen tags by linked models, this is too large of a project.
I’ll use CTC quick select, and screen by workset value, will take much longer though…
However, this does not explain the original problem: tags collected but treated as types:
thanks
gio
Paradoxically, Grasshopper is able to collect the tags (even from linked models) just fine…
I was able to rewrite the script in Rhino.Inside and test it successfully.
In Grasshooper I used the Owner View property instead of the Workset parameter, but it should not make a difference, since in Dynamo the “All Elements of category” node fails before retrieving the Workset parameter.
This seems to indicate it is not a Revit API problem, but a dynamo issue?
Thanks
regards
