Hoping @Ewan_Opie can help!
First, I want to say this used to work and I’m not sure what broke it.
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.
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.
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
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
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?
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…
[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:
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.
Yeah, so check the units adjusting portion of the node. Something’s not right.
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.
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.
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.
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)
