Migrate Custom Nodes to Zero Touch nodes

orchid
#1

Yet another time has a user problems in migrating a graph using Custom Nodes which are deprecated to the comparative Zero Touch node. It seems there still exist users who cling to to my long-gone DanEDU package which was a CN based package because it is a job to migrate it using my new ZT based package (Orchid)

I have tried if there was any possibility to add old CN nodes in my migration, but that is not possible. If any should have success with this, then please describe how :slight_smile:

However, I did try to solve this issue for the user, and figured that it is doable to do a “manually” migration using a notepad editor, and it was not that difficult …

It is a good idea to make a dummy file with the corresponding nodes you want to use because you need to know where the assemblies are stored and what the names are, the easiest is to create a graph with the nodes you know you need and then open this file in a notepad so you have the strings you need to replace values with!

The below example is from a 1.3.x graph, since the old graph most likely is from the era with the old layout before the 2.0.x versions.

The below is the node “List.Clean|DanEDU”

<Dynamo.Graph.Nodes.CustomNodes.Function guid="e4e4649b-af37-41d3-bde8-29c4e9181d4a" type="Dynamo.Graph.Nodes.CustomNodes.Function" nickname="List.Clean|DanEDU" x="281.221049098559" y="999.174659610855" isVisible="true" isUpstreamVisible="true" lacing="Shortest" isSelectedInput="False" IsFrozen="false" isPinned="false">
  <PortInfo index="0" default="False" />
  <PortInfo index="1" default="True" />
  <ID value="f39ad724-9216-46d6-9cfc-0e9bb8a71360" />
  <Name value="List.Clean|DanEDU" />
  <Description value="Remove empty list, null and blank values&#xD;&#xA;- former named as RemoveNull" />
  <Inputs>
    <Input value="list" />
    <Input value="searchFor" />
  </Inputs>
  <Outputs>
    <Output value="list" />
  </Outputs>
</Dynamo.Graph.Nodes.CustomNodes.Function>

The below is the ZT node “List.Clean” in the Orchid package

<Dynamo.Graph.Nodes.ZeroTouch.DSFunction guid="f166a310-a158-4778-b709-8eb190e878c8" type="Dynamo.Graph.Nodes.ZeroTouch.DSFunction" nickname="List.Clean" x="-0.0783702393594012" y="999.174659610855" isVisible="true" isUpstreamVisible="true" lacing="Shortest" isSelectedInput="False" IsFrozen="false" isPinned="false" assembly="..\..\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function="Orchid.Generic.Core.List.Clean@var[]..[],var[]..[]">
  <PortInfo index="0" default="False" />
  <PortInfo index="1" default="True" />
</Dynamo.Graph.Nodes.ZeroTouch.DSFunction>

The most important part to keep is the guid mention in the first line after the function, ex. guid="e4e4649b-af37-41d3-bde8-29c4e9181d4a". The guid is the id used in the graph as the connector!

example where a “codeblock” with the connector guid="f7fc68c8-1239-46d9-848c-ef958450c6de" connects to the “List.Clean|DanEDU” node

<Dynamo.Graph.Connectors.ConnectorModel start="f7fc68c8-1239-46d9-848c-ef958450c6de" start_index="0" end="e4e4649b-af37-41d3-bde8-29c4e9181d4a" end_index="0" portType="0" />

Therefore be exceptional observant towards these guid’s!

Likewise do not change the x, y position for the node ex.
x="281.221049098559" y="999.174659610855"

REPLACE to “List.Clean” node
The first string to replace is Dynamo.Graph.Nodes.CustomNodes.Function with Dynamo.Graph.Nodes.ZeroTouch.DSFunction
this will replace all the CN nodes functions!!!

Next string to replace is nickname="List.Clean|DanEDU" with nickname="List.Clean"

Then add the assembly in the end of the line with isPinned="false">
extend this to isPinned="false" assembly="..\..\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function="Orchid.Generic.Core.List.Clean@var[]..[],var[]..[]">

Move on to the other nodes, replacing only the last two strings per node!

Thats it… all the other strings from the “old” node will be removed when you open the graph, then you are good to go…

Try this out by your self…
danedu nodes.dyn (9.5 KB)
danedu nodes-migrated.dyn (8.6 KB)

before


after

2 Likes

Problems with empty lists
#2

Ok, well I thought I got this right, so you just delete all the |DanEDU’s in each of the nicknames only? I thought i got it, but then it doesnt seem to work:


I should point out that the List.Clean on the right is the one that I replaced in the DYN file using your directions and a script, and the List.Clean on the left is one that I just brought in from the side bar, so if I made a mistake with one on the right in my script the one on the left shouldve still worked, bu alas neither of them do. Please advise.

0 Likes

#3

Also, please advise if your method stated above will handle nodes that are set at different levels and or lacing, and how to change them if not. And if they will behave the same in those settings as the older nodes.

0 Likes

#4

@mix you know the game, upload the graph file…

Next, no, of course, you can’t just remove " |DanEDU". If it was so easy were there no point in making this article. You MUST follow the steps I have mentioned above.

However, I cant replicate your error!?
Home.dyn (4.2 KB)

0 Likes

#5

I cant neither replicate your error using my migrated file from above
danedu nodes-migrated.dyn (9.8 KB)

0 Likes

#6

Just to ensure I did all steps, I did take my original file and “migrated” only the “List.Clean” node… still no error!?

danedu nodes-new migration.dyn (10.5 KB)


0 Likes

#7

Hi erfajo,

I did in fact follow your steps listed above, but you didnt give instructions on how to fix all the other nodes from your DanEDU package. Only the List.Clean node. So in perpetuity, I thought it was the only thing that was …possible… to replicate between the different nodes in their migration, because it was the only thing they had in common.

So for each node, I would:

then I would:

But here it was not explained what to do with EACH node. So I assumed to replicate this step between all the other nodes I would simply just remove the |DanEDU from the nickname. to replicate this step for all the other nodes, because this is all it says to do here.

then I would:

Then add the assembly in the end of the line with isPinned="false">
extend this to isPinned="false" assembly="..\..\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function="Orchid.Generic.Core.List.Clean@var[]..[],var[]..[]">

but at this point is confusing to me, because this process does NOT convert

<Dynamo.Graph.Nodes.CustomNodes.Function guid=“e4e4649b-af37-41d3-bde8-29c4e9181d4a” type=“Dynamo.Graph.Nodes.CustomNodes.Function” nickname=“List.Clean|DanEDU” x=“281.221049098559” y=“999.174659610855” isVisible=“true” isUpstreamVisible=“true” lacing=“Shortest” isSelectedInput=“False” IsFrozen=“false” isPinned=“false”> <PortInfo index=“0” default=“False” /> <PortInfo index=“1” default=“True” /> <ID value=“f39ad724-9216-46d6-9cfc-0e9bb8a71360” /> <Name value=“List.Clean|DanEDU” /> <Description value=“Remove empty list, null and blank values&#xD;&#xA;- former named as RemoveNull” /> <Inputs> <Input value=“list” /> <Input value=“searchFor” /> </Inputs> <Outputs> <Output value=“list” /> </Outputs> </Dynamo.Graph.Nodes.CustomNodes.Function>

to:

<Dynamo.Graph.Nodes.ZeroTouch.DSFunction guid=“f166a310-a158-4778-b709-8eb190e878c8” type=“Dynamo.Graph.Nodes.ZeroTouch.DSFunction” nickname=“List.Clean” x="-0.0783702393594012" y=“999.174659610855” isVisible=“true” isUpstreamVisible=“true” lacing=“Shortest” isSelectedInput=“False” IsFrozen=“false” isPinned=“false” assembly="…\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function=“Orchid.Generic.Core.List.Clean@var,var”> <PortInfo index=“0” default=“False” /> <PortInfo index=“1” default=“True” /> </Dynamo.Graph.Nodes.ZeroTouch.DSFunction>

If you follow the steps precisely, it converts, this:

<Dynamo.Graph.Nodes.CustomNodes.Function guid="bea8f3c6-b509-482c-8bf8-e0517d9ecc8d" type="Dynamo.Graph.Nodes.CustomNodes.Function" nickname="List.Clean|DanEDU" x="1258.5" y="692.5" isVisible="true" isUpstreamVisible="true" lacing="Shortest" isSelectedInput="False" IsFrozen="false" isPinned="false">
  <PortInfo index="0" default="False" />
  <PortInfo index="1" default="True" />
  <ID value="f39ad724-9216-46d6-9cfc-0e9bb8a71360" />
  <Name value="List.Clean|DanEDU" />
  <Description value="Remove empty list, null and blank values&#xD;&#xA;- former named as RemoveNull" />
  <Inputs>
    <Input value="list" />
    <Input value="searchFor" />
  </Inputs>
  <Outputs>
    <Output value="list" />
  </Outputs>
</Dynamo.Graph.Nodes.CustomNodes.Function>

to this:

<Dynamo.Graph.Nodes.ZeroTouch.DSFunction guid="bea8f3c6-b509-482c-8bf8-e0517d9ecc8d" type="Dynamo.Graph.Nodes.ZeroTouch.DSFunction" nickname="List.Clean" x="1258.5" y="692.5" isVisible="true" isUpstreamVisible="true" lacing="Shortest" isSelectedInput="False" IsFrozen="false" isPinned="false" assembly="..\..\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function="Orchid.Generic.Core.List.Clean@var[]..[],var[]..[]">
  <PortInfo index="0" default="False" />
  <PortInfo index="1" default="True" />
  <ID value="f39ad724-9216-46d6-9cfc-0e9bb8a71360" />
  <Name value="List.Clean|DanEDU" />
  <Description value="Remove empty list, null and blank values&#xD;&#xA;- former named as RemoveNull" />
  <Inputs>
    <Input value="list" />
    <Input value="searchFor" />
  </Inputs>
  <Outputs>
    <Output value="list" />
  </Outputs>
</Dynamo.Graph.Nodes.ZeroTouch.DSFunction>

Notibly, this is different than this:

<Dynamo.Graph.Nodes.ZeroTouch.DSFunction guid=“f166a310-a158-4778-b709-8eb190e878c8” type=“Dynamo.Graph.Nodes.ZeroTouch.DSFunction” nickname=“List.Clean” x="-0.0783702393594012" y=“999.174659610855” isVisible=“true” isUpstreamVisible=“true” lacing=“Shortest” isSelectedInput=“False” IsFrozen=“false” isPinned=“false” assembly="…\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function=“Orchid.Generic.Core.List.Clean@var,var”> <PortInfo index=“0” default=“False” /> <PortInfo index=“1” default=“True” /> </Dynamo.Graph.Nodes.ZeroTouch.DSFunction>

So I dont see how it is an actual conversion, but I tried it, and it didnt work.

0 Likes

#8

I have now made migration solutions for my deprecated DanEDU package. The solution includes migration for both dynamo 1.3.x and dynamo 2.0.x

The solutions lookup values in an excel file, so it only migrates nodes from the deprecated DanEDU package, and leave all other nodes unchanged/untouched.

To be able to build these solutions I needed to make two new nodes for my Orchid package. Therefore, please update to the newest version of Orchid.

Excel file with needed conversion input
Convert.xlsx (14.5 KB)

Convert_13.dyn (41.8 KB)

Convert_20.dyn (75.2 KB)

Test files

DanEDU_Nodes_13.dyn (50.5 KB)

DanEDU_Nodes_20.dyn (94.4 KB)

Migrated files
The node which is red is not migrated. (The node is deprecated in the Orchid package since there is no need for it. The content of the node is included in the node above!)

DanEDU_Nodes_13_MIGRATED.dyn (54.9 KB)

DanEDU_Nodes_20_MIGRATED.dyn (102.3 KB)

0 Likes

Orchid update feed
How to extract a given substring based on next starting and ending values
#9

Convert_13.dyn (38.5 KB)
Well I must say when I tried converting the DanEDU_Nodes_13.dyn file to Orchid using your Convert_13.dyn script, it worked like a charm! However when I tried to convert my script, I got a warning here, and the file it wrote to was empty.



Please advise on what went wrong. ThanksCurrent Selection_Make Selected Conduit Runs Homogeneous Based on Most Reoccurring Value_ADD CONNECTED EQUIPMENT_ADD FEEDER SCHEDULE_13.1 (ATN 4B).dyn (1010.9 KB)

0 Likes

#10

Thanks for this real-life example, the problem you meet was, if you don’t use all the nodes, then you need to filter out all those nodes you don’t use…
Therefore, have I updated my graph for converting Dynamo 1.3.x graphs in the post above. Dynamo 2.0.x graphs works differently meaning that graph don’t need any update.


I have migrated your file (to Dynamo 1.3.x and 2.0.x), but I can’t verify the file…
Your graph is enormously and chaotic. I would presume that even the nodes are migrated, something will be lost in translation. Especially nodes from those packages I don’t have might fail, meaning nodes could be removed. Dynamo 2.0.x is very sensitive towards missing packages!

mix_13_MIGRATED.dyn (979.8 KB)
mix_20_MIGRATED.dyn (2.0 MB)

1 Like

#11

Hi erfajo,

Thank you very much for these graphs, you really didnt have to do them for me, if you share the graph that you modified to migrate these files Id love to look at them and possibly learn something. However upon initial review I notice some weird things happening, take for instance this one section of my graph where I use 2 of your nodes three times each. Why is one of them different than the others? They dont look right. Is this a lacing issue? Are there two types of each of these nodes and its getting confused perhaps? Please advise. Original 1.3 graph:


Migrated 1.3 graph:

Once again, I apologize for my “enormous and chaotic” graph, but as you said its a real world example. Real life tends to get messy, but it works. :wink:

0 Likes

#12

The graphs I used is the (updated) graphs in the post where I revealed them…

If you could find some significantly smaller graphs, then would it be doable for me to open them and verify them… significantly smaller!

0 Likes

#13

Well I am certainly willing to go try this on other, smaller graphs, but there is no telling if I will be able to duplicate this particular error on different graphs. The bug exists somewhere in there, indicated by this graph. But ill try to find similar errors on smaller graphs, but it might take me a while to find it. I can show you where this particular section of the graph is if it is to big for you to find if you would like however. :slight_smile:

0 Likes

#14

you can try to make a copy of your graph, and erase a huge number of the other nodes, keeping only those close to where error occur, then I can try to run the migration on those… try to keep it to around 20 nodes or so.

0 Likes

#15

Ok, I will do that. I will trim down this file and send you a smaller version. In the mean time can you please explain why the conversion of the GetItemAtIndex node no longer works the same way? You can see here, that the old graph and new migrated graph, run with exactly the same information, fails at these nodes. these nodes appear to process information differently and that scares me. Is there a way to fix this? Please advise. Thanks!

0 Likes

#16

Ok, in order to keep the smallest integrity possible to this graph, I had to keep more than 20 nodes but its probably only 1/3 of its previous size now. Have a look. :slight_smile: Reduced_Current Selection_Make Selected Conduit Runs Homogeneous Based on Most Reoccurring Value_ADD CONNECTED EQUIPMENT_ADD FEEDER SCHEDULE_13.1 (ATN 4B).dyn (258.0 KB)

0 Likes

#17

I don’t want to use my time in walking around in your files… so you need to lower it to an amount where it is doable for me to work with in a text editor. Therefor, lower it to around 20 nodes or try to figure it yourselves.

0 Likes

#18

Hello my friend,
I dont understand, there are more than 20 nodes upstream of where the problem occurs. You want me to delete all the nodes including the problem area all the way back so that there are only 20 nodes, so you can look at it? That doesnt make any sense to me. What exactly do you want to look at? I reduced the file by 70%, per your request, to a minimum where it still contains the problem area. There seems to be a problem in this area with your code. It is mis-replacing one of your nodes. You just want to leave it like this? thanks,

0 Likes

#19

This problem occurs due to you haven’t changed the node from my deprecated package to the new package for quite a long time. This is something you know will give you a raising number of problems and still you have continued using something which is not supported. Time will only make it worse.

I have gone much further than anyone else would have done. I am sure anyone else would have written shift the deprecated nodes with the new node and that would have been the only answer given!

I have made this post showing how changing could be done manually and I have even topped that up with a graph which can solve the problem… however, I (as anyone else making packages) has no possibility to take all considerations into account and I don’t want to.

I make this package for free, anyone can use it as they please but on your own accountability.

This community is not a do my job or fix my problems community. We all do this voluntarily for free!

Therefore, I have to pull back from giving any further assistance on this issue. You need to change those nodes, you must figure a way. I will not support something which is deprecated (long time ago) beyond what I have done.

1 Like

#20

As @erfajo noted, this ‘share’ was done after an issue was pointed out. The tool is there, but it’s on each of us to use it (or not) as per our individual needs and skill sets. I’m closing this post now as it’s starting to go way beyond the ‘hey look at this cool tool I built to help upgrade migrations’ topic.

1 Like