Duplicate Sheets using BiMorph Node

Tried using the latest version of the BiMorph Nodes 1.4.3
But, I can’t pass the duplicated sheets downstream. So tried to see if the output is the same Object.Type and I see that they are not the same. As I have little to none programming knowledge, can you please check & advise if I am missing something?

BTW, for now - I have a workaround; to have another sheet List schedule which “filters” and picks up ONLY the duplicated sheets for managing some of the properties of the duplicated sheets.

Your help would be as awesome as your nodes :slight_smile:
It’s really a big Time-saver; so a big Thank You!

R. Chandrasekar.

HI @Chandrasekar_Rajaman thanks for reporting this, its a bug! Now fixed in version 1.4.4 available via the package manager. Glad your find bimorphNodes useful!

1 Like

Thanks a lot!!

Hello, I cant get it to work at all, what am i doing wrong?

Just to be sure - Can you verify & confirm the below:

  1. There is a Revit schedule by the name “Sheet List to be Duplicated”?
  2. The schedule does have Revit sheet objects?

As the graph depends on the Revit schedule and all connections are correct, I think that the issue is from the Revit side… If there’s a schedule in the project with sheets and still the graph doesn’t work, can you share both the .rvt and the graph?

R. Chandrasekar

It’s fixed! Duplicating Sheets using bimorph not working

BimorphNodes V1.5.0


Hi @Thomas_Mahon
Saw the other post & thread later.
Didn’t expect the same to be posted in more than one thread :slight_smile:

In fact, I was remembering to mention the condition that the Sheet Number has to be in the schedule but missed it when typing the reply.

BTW, if I have a dependent view placed on a sheet and I copy the sheet and view, the node would create a dependent copy of the same parent level? Or would it create a copy of the parent level & then create a dependent (which is what I want)? Any other ideas to achieve what I intend?

Thanks a lot again - Look forward to the updated version…

In Revit there’s only one level of hierarchy with dependent views, so if you duplicate a dependent view as another dependent it is a dependent of the parent view, not a dependent of the dependent. (try saying that quickly!)

Bimorph.DuplicateSheets calls the View.Duplicate() method in the API, meaning the above behaviour is observed.

Dependent view Level 0-2 duplicated as a dependent (to create Level 0-2 A):

What you require can be achieved if I understand correctly (i.e. if Level 0-2 etc is placed on a sheet, duplicate it AND its parent). So the behaviour would be: if a dependent view is found, duplicate the parent, create a new dependent of that parent and use these view on the new sheet vs the current behaviour which: 1. Duplicates the parent as a new dependent view 2. Where dependent views are found, simply duplicates them as dependent’s of the same parent. Is this the problem you have?

I can implement this, I guess the question is which of the two scenarios described above is most common, the former or the latter as this will inform which should be the default behaviour.

1 Like

There are four potential scenarios I can think of that would affect the nodes behaviour if the former behaviour (the one I think you’re after) is implemented:

User-selected view duplication method: Duplicate as Dependent

  1. Duplicates Parent views (with detailing), creates dependent’s of new parent
  2. Create new dependent views of the parent view regardless of whether its the parent view itself or a dependent (current behaviour)

User-selected view duplication method: Duplicate or Duplicate with Detailing
3. Duplicate parent, and where dependent’s are found, duplicate them as new views, i.e. they’re promoted to new top-level views (current behaviour)
4. Duplicate parent, and where dependent’s are found, duplicate them as dependent’s of the new parent

For option 1 think carefully about what it means to ‘Duplicate as Dependent’ as the behaviour technically becomes inconsistent were it to be implemented.

First, Thanks for sharing your thoughts & sparing some time to consider my suggestion.

Allow me to explain the scenario when I think it is most helpful / productive:
There’s a set of Archi Plans for many levels (with a set of dependent views)
All arranged on sheets

There’s a need to have the exact set of sheets with an exact copy of the dependent setup of views
Let’s say, for using as Fire Compartmentation Plans (achieved by only changing View Template)
To be arranged on a new group of sheets

If I duplicate as is (not as dependent), I can change the View template but the setup is lost (parent & dependent)
If I duplicate as Dependent, then it’s dependent on the Parent so can’t change the view Template
This’s when I hit a road-block…

So yes, if it can be implemented, there would be a check to evaluate if the view on the sheet is a Dependent…
If yes, then duplicate the parent first (so the suffix or affix goes to the Parent view)
and then the create a dependent of that view (Dependent xx)

From a BIM Management view point, it appears quite logical to me…

1 Like

In this scenario then:

Your expected behaviour IF Duplicate as Dependent option is nominated, would be (assuming all of the views shown are on sheets):

Looking at the above more, I reckon its better if there is simply a new view duplicate option: Duplicate and Preserve Dependent View Structures. Otherwise, the views without dependent’s get dependent’s, whereas views with dependent’s are duplicated first which is inconsistent.

The result of this method would be:

Which seems far more rational.


Hi @Thomas_Mahon
Thank you for the reply… Precisely that 's the functionality which will definitely help make the workflow more productive.

If one set of views is done (placing on sheets included), then the other set (whatever it may be, which is just assigning or updating a view template) is just one Dynamo node away…!! :clap: :clap:

But big question is - Can this be implemented?

Of course!

I’m going to make this the default behaviour for Duplicate and Duplicate with Detailing as its far more rational. Duplicate with Dependants will remain unchanged as this, for better or for worse, is consistent but gives all users the best of both worlds. Cheers for sharing your workflow to help improve the node.

Many Thanks for taking up the suggestion :slight_smile:
Do let me know when it is ready so maybe I can help you test it…!!

Recently, I came across this quote by Bill Gates
I would hire a lazy man to do a tough task
because he would find an easy way to do it

To me, this is the way to efficiency. Of course, we have to ensure that the lazy man does his work though! :slight_smile:


This is awesome, thank you a lot! Any chance you’re looking at adding support for schedules and detail items? : D

Hi @sam_keville cheers! Yes, they will be fully supported with an improved view duplication algorithm in BimorphNodes v2.0. Planned release around mid-Feb. I’ll announce it on the forum in any case. Watch this space!

@sam_keville bimorphNodes v2.0 is now available for download.

@Chandrasekar_Rajaman check out bimorphNodes v2.0 DuplicateSheets, now includes this improved behaviour.

1 Like

Hey Thomas, I’m trying to use this again with all the same inputs I had and it’s giving me an error “Operation Failed. Managed Object is not Valid.”

I have a sheet with 2 views and 3 Generic Annotations on it. Do you have any idea why it’d be saying this?

Hi @sam_keville which version of bimorphNodes are you using? If you’re not using version 2.0.3 please ugrade then check if the problem persists. I’m running tests on this node to see if it has any bugs and I cant find any, but if you can send me a sample file if you are using that version I can debug it.

Oh, that’s easy. Thank you, I was on 2.0.0 just a bit too early with the upgrade. This is really awesome!