Failure to create Dimension

I’m writing a script that generates dimensions in elevation views. I’m using Surfaces and the OOTB node DimensionByFaces. This works for one set of surfaces: the bottom of the wall to the top of a generic model (A),

but not for a different set of surfaces: same bottom of wall reference to the top of a casework element (B). It doesn’t seem like the category should have any thing to do with it.

I inspected the normals of the (B) surfaces and they’re both in the Z direction. When i run the script, it seems like it tries to create the dimension, but fails. I get this warning

Not really sure what’s the issue here…

I had tried this initially with genius loci nodes, but i think i was running into a similar issue where the dimension wouldn’t be visible in the view, or not create at all.

i’m digging into this. still not sure why i’m getting the results i am.

these are the inputs and outputs in dynamo:

This generates this dimension. The red ones are dimensions created with the UI

i compared the ReferenceArrays of this dimension (below) and a multi-element dimension created using the UI (above).

the Wall reference in both Dimensions use the same StableRepresentation, but the references for the cabinets and the countertop are slightly different.
It looks like dynamo is able to create the dimension, and it has the references that have been input, but i don’t understand why the other lines aren’t visible?

I resolved this valid reference issue by using the named references “Top” and “Bottom” in the family. I was not successful in developing a test to determine if any selected surface would generate a valid reference for creating the new dimension.

This requires a bit of rework/update to families, but seems like it should be more consistent from the dynamo side