Dynamo working for some revit users but not others

Hello,
I hope i haven’t missed this as an already solved issue; but i can’t figure this one out and can’t find anything online. would appreciate insight.

I have a script (3 seperate ones actually) that allows the user to select certain elements, then extracts parameter data and generates a tag. This script works for everyone on the team (16 users) with the exception of one. I have tried moving the user to a different machine, creating a new user account (domain), tried signing the user in on a different autodesk accout…nothing seems to work. This user’s dynamo seems to be functioning normally, same version and packages as the rest, but the “select elements” function just seems to be not working.

Any ideas are appreciated.

thank you!!!

Is there an error message in that node when that specific user tries to use the script?
What is the output for that user?

nope, no errors. The script runs like normal, except the user cannot select elements. the only way to terminate it is to stop the script from running, which does not produce any errors (except for yellow nodes that have not received expected input)

That is weird, have you tried removing and replacing that node from that users pc?

yes,
I created an additional user account and that worked for a day but now same issue. If I log into the same machine it works for me. I have tried logging in with my autodesk account for her as well, no change.

Maybe @jacob.small knows how to solve this

Does this forum send a message if you tag someone or should I PM him?

You will get a notification when you are tagged :slight_smile:

Are you able to share your script?

My guess would be shared packages on a network drive. It can hang up for some people (assuming they even have access).

I had thought that as well, I finally was able to log into her account and duplicate the issue so i am going to troubleshoot. I’ll try moving the packages locally and see if that helps, but there is definately no access issue, all of the setups are identical and no one else is having this issue. The issue persists on different machines as well.

Try to run Revit (Dynamo) as administrator. My colleague had similar issue.

Concurrent access based on scope and user and the joy which is your network security protocols.

This also sounds a lot like a missing Revit update could be at play too - can you provide the Dynamo log file and Revit journal from one of these locked up sessions so we can see if there are any bread crumbs there?

Hey guys;
@jacob.small, @Drbohlav, @Nick_Boyts, @MVE1112 thanks for the ideas. I can submit some logs if we need them but i spen a little more time today and found the error… it’s a strange one though I can’t figure out how to fix it.
so the selection node is from Data-Shapes, but it is using a standard category filter. When I open the script it shows “conduits” (which is what we’re trying to select) and when the user on my team opens the same script it switches itself to say “detail item tags”. I copied a version to her desktop, same issue.

wierd thing, it won’t let her do a save, but when i pull it up to fix it (same location, same script) it says “conduits” so as far as i can tell there’s nothing to fix on the script.

What would make this happen just for this user? anyone know how to fix it?
for now i have her just changing the node back to “conduits” and everything works fine; but it re-sets if she closes and opens the script.

snippet below:


(hers)

image
(everyone else)

I went into the active directory and verified that her access level matches all other users.

Also I signed her out of autodesk and signed in as myself, no change.

any ideas? Thanks!!!

Definitely sounds like an issue with the Revit version. Dropdown selections use an indexed list, not names or IDs, for remembering selections. So this user’s list of categories does not match everyone else’s.

The versioning problem should be fixed, but you can also avoid this by hard coding your selections instead of using dropdowns.

1 Like

So the index for that list is held in revit and not the dynamo version? That all makes sense; unfortunately the revit versions are all identical as well as the dynamo versions, so I don’t know how to fix that problem. In the meantime, is there a node I can input a string into to “hard code” the selection or does it actually need to be coded (i.e. python)?

This is the main reason why i go out of my way to NOT use any dropdown nodes…

You can use the Category.ByName node for this.
You can enter a string as a name.
image

3 Likes

The index is held in Dynamo, but the list of categories available sometimes changes between versions of Revit.

wierdness, thanks for the info; I hadn’t though about how the dropdowns were indexed.
@Nick_Boyts I’ll check on it, maybe she ran an update on revit without telling me; generally i do that across all the machines at once to avoid version mismatch issues. @jacob.small, @Nick_Boyts if there is no version difference, is there anywhere else this could be fixed?
@MVE1112 thank you for the node, that will save me some time searching!

Bit of a technical explanation here, hopefully it won’t be too wordy and will help keep things clear.

Drop downs which require Revit access come in two flavors: consistent between Revit build and inconsistent. The way Dynamo deals worth displaying the selected value has changed over the last two years or so. With Revit 2019 and prior all drop downs basically worked via list indexing, where the selected index is stored in the DYN.

As an example, let’s say you were working in Revit 2019 and wanted to get the category “rooms” from the drop down, and that “rooms” is the 22nd thing in the list. The way it used to work the drop down would get all the categories, sort them alphabetically by display name, and record the number (22) which was selected. Now when the same graph is opened in 2020 you will see that the drop down displays ‘Room Separation Lines’, which isn’t what it was before. The reason for the switch is the introduction of a new category for Path of Travel, which happened to bump the previous item at index 16 to item 17 after the alphabetical sorting was applied, which bumped all values after index 17 as well, putting rooms at index 23 instead of 22 where “Room Separation Lines” happens to exist.

The good news is that starting in Revit 2020 and Dynamo 2.6 the method was changed to be more like a dictionary than a list indexing, so the name will be stagnant for all graphs built in 2020 and beyond for these ‘by Revit’ dropdowns which will prevent such errors.

Offhand I think this should only occur between Revit years, but I think we may be seeing categories added on point releases now (I recall something along these lines with the infrastructure categories), so in theory keeping everyone on the current release continues to be a thing every office should do.

The by file dropdowns such as ‘levels’ and ‘views’ may still have these types of issues though, so it is always worth testing the ‘what if’ situations on office wide graphs (ie: “what if there isn’t a level called ‘level 1’ in the model?”) to ensure scalability.

@john_pierson is doing some AMAZING work (as always) in this particular area with the Monocle view extension which I hope will be released soon. In the meantime I recommend using the ‘by name’ method, and always tests graphs which will be deployed at scale on a full range of versions (write in oldest and test in newest is a good strategy to prevent using nodes and functions not exposed yet).

3 Likes

Thank you Jacob, that does all make sense; and this is the last project we have in 2019 (hopefully for good) so that makes sense as to why it works that way.
Planning to move into other projects using these tools, and those are in revit 21, is there any conversion issues to be aware of? I will test the scrips of course, but any specific changes would definately be helpful.

I do use moocle, @john_pierson does great work!

thanks for all of the help everyone!

I marked @Nick_Boyts as the solution because I think that addresses the question most directly for anyone searching on this issue but @jacob.small and @MVE1112 thank you also for your help!

2 Likes