Trouble with Python script with Sastrugi Package

Hoping @Ewan_Opie can help!
First, I want to say this used to work and I’m not sure what broke it. :slight_smile:

I put together a Dynamo script that will place a note block. I’m using Sastrugi to set the sketch plane ( *_Set Sketchplane By View ) and then allow me to click to set coordinates on that sketch plane ( *_Pick Points on Workplane ).

This used to work whether I was on a sheet, model view, or drafting view. It didn’t seem to matter. But now, the final Python script (credited to @Einar_Raknes)within *_Set Sketchplane By View errors out saying it “Cannot set sketch plane in this view” when I try to run it on anything other than a model view.

You can see I have the *_Set Sketchplane By View nodes pulled out to see what’s going on for testing at the top. Below that is my regular script.

It’s able to get a SketchPlane in the SketchPlane.ByPlane node, but for whatever reason doc.ActiveView.SketchPlane = UnwrapElement(IN[0]) is not able to do what it’s supposed to do with the SketchPlane provided.

Any help is appreciated! :slight_smile:

Thanks!

Hi @TheMattatonAP
I’ll take a look now to see what might be the issue.
What version of Revit / Dynamo are you running?

I have implemented a small code tweak for you to try. Can you add this section in try setting the sketchplane in a few view variations?

Python String Input below:

import clr

clr.AddReference('RevitServices')
import RevitServices
from RevitServices.Persistence import DocumentManager

doc = DocumentManager.Instance.CurrentDBDocument

OUT = [doc.ActiveView]
1 Like

Thanks, @Ewan_Opie . I’ll have a look at what you’ve given me above.
I have tested this behavior on Revit 2021 and 2022, Dynamo 2.6 and 2.12, I believe.

1 Like

The above just ran fine in 2022/2.12
If you do get the same error, can you please post the contents of the yellow warning dialog.

1 Like

Hmmm…well, that’s not promising for me, then. It still doesn’t work. Same error:

Warning: IronPythonEvaluator.EvaluateIronPythonScript operation failed. 
Traceback (most recent call last):
  File "<string>", line 31, in <module>
Exception: Cannot set sketch plane in this view

It would seem you are trying to set a SketchPlane for a ViewType (Autodesk.Revit.DB.ViewSheet) that does not support this property.

This can be avoided by adjusting the code here to catch exceptions.

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

clr.AddReference("RevitNodes")
import Revit
clr.ImportExtensions(Revit.Elements)
clr.ImportExtensions(Revit.GeometryConversion)

clr.AddReference("RevitServices")
import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager

clr.AddReference("RevitAPI")
import Autodesk
from Autodesk.Revit.DB import *

doc = DocumentManager.Instance.CurrentDBDocument
uiapp = DocumentManager.Instance.CurrentUIApplication
app = uiapp.Application

sp =  UnwrapElement(IN[0])

TransactionManager.Instance.EnsureInTransaction(doc)

viewType = str(doc.ActiveView.GetType())
try:
	# Attempt to set the sketchplane
	doc.ActiveView.SketchPlane = sp
	output = "Success"
	
except:

	# Sheet Views do not have the property 'SketchPlane' to be set so ignoor
	output = "Failed. Check if View Supports the 'Show Work Plane' command from the Architecture Ribbon Tab"
	
TransactionManager.Instance.TransactionTaskDone()

OUT = sp,output

This does mean that no ‘SketchPlane’ is set in the view, but Sheets use slightly different coordinate systems anyway, so placing items would need customisation anyway. There are plenty of ‘Place element on Sheet’ posts around :slight_smile:

1 Like

It apparently doesn’t work on Drafting Views either, even though the Show Work Plane tool is available.

Interesting. I would have bet a million dollars this was working on sheets before. I guess not. When I was testing, I must have only run it on plans and sections and copied the instances to sheets. Bummer!

Bottom line, I wish Revit had some way to attach families to the ribbon for easy placement/access. Digging down into the Families in the Project Browser for oft-used families is a pain (when they’re not already in the view for copying).

Complete sidenote on the last Python script in the node…
Is there a reason that doc, uiapp, and app are set to the same value twice (before and after the Autodesk.Revit.DB import), and then uiapp and app are never used?

Thanks for looking into this for me!

So, next problem. Even when I use it in model views, it’s placing the instance WAY off to the upper right of where I clicked.

I swear this was working before! This is so weird!!!

Whoops, nope. I’ll change this in the code example now.

There are a few Revit add-ins that offer this kind of functionally. Some paid, some free. Have a look a this one which lets you browse loaded families. (not endorsing this, but providing as an example only) https://github.com/RomanLavrov/RevitFamilyBrowser

What coordinate system / project units are you using (Metric/Imperial)? There may be some scaling between the internal Dynamo XYZ values and the Revit coordinate system, depending on the view type…

1 Like

I’m using Imperial, but I was when this was working too. So weird how it went screwy on me.

[EDIT] See my follow-up post below…
Sorry to refresh this on you @Ewan_Opie .
I’m still having the issue where the instance is being placed a great distance to the upper right of where I click.

I’m using the latest Sastrugi package (2.02) n Revit 2022.

Here is my current script. Nothing has really changed:

Thanks for any help you can give!

I edited the Pick Points node and copied the nodes from it into my main script to see if I got any errors running it that way.

The Python node for picking the point says:
Warning: your input points lie outside of the allowable modeling range.

The Python node for adjusting units says:

Warning: operation failed…File “\<string\>”, line 13 in \<module\>
NameError: name ‘UnitType’ is not defined

Investigating further, it looks like it’s being converted to metric (multiplying by 304.8 whether my view is in imperial units or not). Or, rather, it’s just using the Metric units because the units adjustment portion isn’t working.

Dynamo Point is 35.438342373, but Revit point is 10801.607

If I bypass the units check and just send the imperial points to FamilyInstance.ByPointView, then it works fine.

Actually this corrects all the issues I was having. I can also place the instances on drafting and sheet views now. :slight_smile:

Yeah, so check the units adjusting portion of the node. Something’s not right.

Thanks!!!

1 Like

That is interesting to hear, as I originally added this check to mitigate a translation issue. Perhaps there has been an update in recent versions of Dynamo that allows for this.

I am glad that you have it working and can move forward.

I’ll go have a look :+1:

Ok, so the issue is the Revit versioning and depreciated API functions for establishing Document UnitTypes.

The below .dyn should be copied into the Sastrugi package folder overwriting the version included in the 2.0.2 release. This should be the only node affected.

__Pointcloud_Select_Points_By_Region.dyf (262.5 KB)

I will roll this change into a future release, but for now this ‘patch’ solution should be used.

1 Like

Thanks, @Ewan_Opie !

Ah, so maybe the reason this stopped working for me is because I had moved to Revit 2022, eh? Is that when the breaking API function changes took place?

Just to clarify, I’m having issues with the Pick Points on Workplane node, not anything to do with Pointcloud. Does the updated dyf file still have something to do with the Pick Points node?

Other than overwriting that file in the Sastrugi dyf folder, should I need to do anything else in Dynamo? I deleted the Pick Points node and added it in again, but I’m still getting incorrect RevitPoints returned values from the Sastrugi node. Still getting the multiplied metric values, rather than the imperial.

When I extract the contents of the node into my canvas, I still get the same UnitType error.
Top extracted version is from yesterday, bottom is from today. They seem identical.

Yes, it’s a 2022 API change.

UnitType has been replaced with ForgeTypes, which use an ID system to specify what type of unit should be returned when searching the document.

I will post a patched dyf for the PickPointsOnWorkplane node when I get to the office that includes the same Unit type fix.

EDIT = Here is the patched Node to replace the old one in the package folder. Again, this update will be rolled into the next release of the Sastrugi package when I have some time.
__Pick_Points_on_Workplane.dyf (22.0 KB)

1 Like