I am trying to place different electrical face based families on the nearest wall by equipment in a linked file. In this example I am placing a safety switch family on the wall nearest to where the mechanical placed the VFD but want the same method to work if the architect places a fridge that I need an outlet. To do this, I am trying to find the nearest wall, then take the nearest surface of that wall and point to place the family using either the springs or built-in node for familyinstance.byface. I tried using RayBounce which gave me the nearest wall and intersection point but I couldn’t figure out how to get the correct nearest surface of the wall. I tried another route using a script to find the nearest wall/point and I am getting a surface and point out but both family creation nodes fail. The springs one tells me that multiple targets could match and the built-in says it is not a Revit element. Is there an easier way to place these families or any help with the two methods?
Both nodes require a Face, which is not the same as a Surface in this case. A surface is just a Dynamo geometry, while a face refers to the actual Revit face reference of an object. I think there are a couple custom packages that have nodes for getting Revit faces, but you may need to use the API here.
A better option (in my opinion) is to use unhosted families and just place and orient them as needed.
Hi @jeffr you could try get surface with bimorph for facebased, should work on link
We’ve been discussing that option internally and then I could just use place by point which is what I am doing for some of the other families (direct connect on top of equipment). Most of their families are set as face based though so when they are hosted to the wall and the wall is moved, then the family adjusts with it. As I am sure you know this causes other issues (devices becoming not hosted or worse shooting off into space) but I am trying to make the families work as is if I can. Thanks for the suggestions.
I did use that on the walls that I found with the RayBounce node (see bottom of my graph) but all that did was list all the surfaces of those walls which wasn’t helpful to find the nearest/vertical to place the family. From your graph though it looks like I might be able to use that to run a geometry intersection with a line placed at the family.
Yes true, thats what i try 
@Nick_Boyts for the face/surface clarification, I’ve been trying to match this manual method for Select Face which is confusing because it says surface. I’m using the BimorphNodes LinkElement.Faces which similarly lists Surfaces. I need to filter that down to get the correct surface of the wall and then will see if that runs with the FamilyInstance.ByFace node.
@sovitek, I got your suggested method to work. I am drawing a vector from the mechanical equipment back to the wall and then just getting the surface that it intersects with plus the closest point on that surface to the equipment. Those inputs gets the family to place as expected.
Small edit: The closest point to node wasn’t actually finding the closest point on the surface. It was just returning the point of the equipment. Apparently, that family placement node can still input the point and must essentially project it on the face that is also inputted which works fine in my case.
It’s a little confusing. In many cases they can be used interchangeably, but they’re not quite the same thing. Dynamo separates surfaces and polysurfaces, which is a similar relationship, but faces tend to be the most basic and specific planar representation of a surface (i.e. topology vs geometry in some cases).
Revit tends to deal with faces rather than surfaces. Some nodes may accept a surface and handle the conversion themselves but it’s impossible to say what the actual issue is without seeing the specifics of what you’re doing and where your issues are occurring.
You can see here in the Revit API where this method specifically requires a Revit Face.
NewFamilyInstance Method (Face, XYZ, XYZ, FamilySymbol) (revitapidocs.com)
Hopefully that helps.
Another follow up…the last version I had didn’t handle walls on an angle so I looked at a different method for equipment on any wall. The best method I came up with was to make a sphere at my equipment to the intersect with linked walls, then get the faces and from there used Geometry.ClosestTo which gave me the surface and point. Doing a FamilyInstance.ByFaceAndPoint with those inputs gave me the result I needed on any angled wall and with the correct hosting for the family:
@sovitek have you seen this error before on the Spring FamilyInstance node? I’m taking as similar method as I did above for placing outlets but this time spacing a number of outlets per wall around a room. I am using the same Bimorph package node for LinkElement.Faces and then intersecting that with the line I have for each location thinking that will give me the correct point on the face but I get the error below. I’m getting the point/surface different than my other script above but feeding in the same inputs to the FamilyInstance so not sure why it works on one but not the other.
Hi @jeffr not really 
sounds as some list level lacing, list structure maybe
I was wondering if that was it so at the very end I just am taking a single point and surface to check and at least by the preview I am getting the point on the corresponding surface. I am using cross product to check all of the line/points intersection with all the wall faces but wasn’t 100% sure on doing that and then using a Boolean mask to get the correct one. Maybe that is still not working as expected.
I looked into this further and the issue was with where I was getting my walls to feed to the LinkElement.Faces node. In this new version I was using the Clockwork node for Room.Boundaries to get the curves and since it gave me the wall element too I was just using it to pass through to get the faces. I realized on the original version I was using LinkElement.OfCategory from BimorphNodes and when I switched back and used that with just a boolean mask for the room it started working again.