Best way to debug + deploy

Hello folks,

I would say this is a different query as I am not asking for help/support in Dynamo. I am just asking for advice to the experts on the best way of debugging + deploying a long and heavy Dynamo script based on their experience.

You´ll probably know that when you deploy a Dynamo script in a company for everyone, it is very easy that people might come up with errors when running the scrips because of the data formatting within an Excel file, how they set the inputs, and so on…

My question is, how would you debug + deploy a huge Dynamo script where an issue can appear in many different parts of the script when running through Dynamo player? so anyone can be aware of the mistake he made.

  • TaskDialog?
  • CTypes?
  • Try/Except with Python and setting output text messages?

@JMCiller

so what i do:

  • first concept Collect → Filter ->get or generate Values → Set (f.e.)

  • test it step by step (stop script at key points)

  • Test on a demo file or detached file

  • when you are advanced build as less nodes as possible use python: FilteredElementCollector, LookupParameter methodes, Condtions,…

  • i would rather use pyRevit as a toolbar insteat of the DynamoPlayer so it is more userfriendly

  • discribe your graph as much as possible, that someone can understand it one year later…

usertoolbars

freeze
grafik

custum nodes in dynamo or lather in pyrevit
grafik

i am courious what other people do … :wink:

KR

Andreas

This is a good post as well :grinning::

2 Likes

Ten thoughts off the top of my head:

  1. Build your stuff using reliable code with error handling.
  2. Test in every environment you’re deploying (Revit version, Revit add-ins, Package library)
  3. Simplify environments to all data on the local disc instead of networks (Dynamo graphs are code, and running code off a network is a bad idea).
  4. Deploy separately for each environment - no Revit 2023 and 2022 shouldn’t have the same package directory.
  5. Users who just want to push play should leverage Dynamo Player exclusively; organize the library and provide properties and help documentation for them that works in this context.
  6. Clear input names with notes for detailed instructions.
  7. Provide a watch node consisting of any unexpected results at key points, and an indication of where that is.
  8. Provide a watch node for major results.
  9. Don’t build graphs which do everything at once; let the users run things in sequence instead.
  10. Build your graphs off your office standard, and inform users “if you deviate it won’t work, so get onboard with the rest of the team.”
2 Likes

Hi,

for the debug, it is possible to recover the errors of the nodes.

Once the error messages have been retrieved, you can send these errors to a server or a channel like Slack or other

some Example

1 Like

Wow! This is another point of view so interesting. I have never seen it before.

Thank you for sharing!

1 Like

Keep in mind your code will be more stable the more standardized it is. It’s better to have stricter requirements that work than to be flexible and have to deal with error reports. Standards and explicit requirements will also make documentation and training much easier. If you can define all your requirements in the documentation then you shouldn’t have to deal with troubleshooting those errors. (They’re still going to happen, but that becomes a user error rather than a tool error.) Be as proactive as possible so that you have fewer instances of troubleshooting to begin with.

1 Like