Need help with "CadTextData.FromLayers"

Hello, recently i started working with the node CADTextData.FromLayers from the Bimorph Package, (using Revit 2018, Dynamo 2.0.3 and Bimorph 3.0.3) and since the beginning i am having problems with that node. First problem i had was that when i tried to use it , combined with Genius Loci`s Imported DWG node, for some reason the node did not work well, returning an empty list value, both for the two output node values.
imagen

But after 2 days of “research” and trying to feed the nodes from different ways, i discovered that if you feed the node with a 2 cycled import instance, the “first try” of the node fails, but the second one works properly.

So then i thought that i fount a node patch that “solves” the problem… but no.

Yesterday i started working in a workflow to allow me to pick some DWG data (lines and text) from a
foundation and plumbing drawing and the node started failing again. I tried everithing: Copying the elements in a new drawing, rename the layer, trying both Text and MText, creating a new layer and change the text elements to that layer, ciclying the import instance 10-15 times… and nothing.

And the strangest part is, when i try the node in previous workflows (the firsts ones that i mentioned before) the node works perfectly with the “2 cycle patch”, but with this workflow does not do anything.

I adjunt the .dwg and the .dyn (also needed Genius Loci for this workflow)
Cimentacion.dwg (50.9 KB) Foundation and wasting water.dyn (68.1 KB)

I know that the node has beed created by @Thomas_Mahon, so i hope that my explanation of the problem helps him to improve the package and the node.

Thanks for your reading/time
Damian

Also, i know that there are alternative solutions (like AutoCAD`s ExtractData), but at first i would like to see if i am able to create a workflow that only requires the DWG import and nothing else.

I think you need two transactions to leverage this sequence of nodes. One to import the dev and one to get the data, otherwise the Revit API doesn’t have the capacity to pull data from the import.

Add a transaction end and a transaction start node (in that order) in place of the List.Cycle node and see how that works.

3 Likes

@dami.lorente can you try the following so we can determine precisely what the problem is.

Firstly, the issue is not BimorphNodes - you’ve already established this based on your description of the problem - rather there is some problem occurring between automating the linking of DWGs and passing this into the BimorphNode, and that is where you need to focus your attention.

Just some friendly advice: With problems like this where you are seeing a combination of events and inconsistent behaviour, you shouldn’t just jump to conclusions, lay blame and expect help in return, especially when you haven’t even bothered to isolate the problem.

What you should try is something along the lines of this:

  1. Link the DWG in manually then use CADTextData.FromLayers. Does it work as expected?

  2. Use the GeniusLoci node to import the DWG. Find another node which isn’t Bimorph nodes, literally any other node which can interact with that DWG import instance, replicate the same steps you take where you find inconsistencies with the BimorphNode and see if it returns a result which is expected.

One possible issue which @JacobSmall has already touched on is the need to control the transactions (a context required by the Revit API to make any changes to the database, i.e. your Revit file) being submitted to Revit. The reason why this is significant is because some element types when created via the API are not visible in the database until after the document has been regenerated, which can either be done by the developer (and would be my recommendation if this does turn out to be the issue - in which case the GeniusLoci package would need updating), use the transaction nodes, or save your file after importing the DWG,
OR
run your graph twice so long as there are other nodes which interact with Revit and commit transactions because this will force the update to the Revit database, meaning any other process which needs to operate on say…an DWG ImportInstance…can access it successfully. Sound familiar?

I hope the behaviour you’ve observed make more sense now.

1 Like

Update: the problem isn’t BimorphNodes:

Update: the linking of DWG occurs outside of a transaction (hint, hint):

@dami.lorente I’ll let you work out the rest. Merry Christmas!

Hi Jacob. After reading all, I tried the transaction nodes thing and it does not work.


Even, I tried fo place those nodes before the Cycle and neither works.

Hi Thomas. After reading all, I tried to do the import manually, then run the workflow, and it did work.
I also run the GeniusLoci Import DWG and place a Element.Geometry and also worked.
And at a last try, I tried to use *Passthrough" from Clockwork, to force the workflow to do something after the Import DWG and before do the CADtext (I tried to create a line) and this third one try did not work.

I need to say that, before writing the fist post I tried to verify what was the problem by myself and to understand what was happening. If I insinuated that I was blaming the package at first, I am sorry. But I writed it in that way because other node of the package, CADCurves.FromCadLayers, which I use in most of my workflows, works perfecly with the GeniusLoci import. Coming from the same package, one working and one not shocked me.


I did a research, visiting the Bimorph offcial page, and I saw that the CADText is more recent than the CADCurve. that is why I assume that, maybe the problem was because the node was more recent.

Maybe the problem begins from the relation of the Genius import and the Bimorphs CADtext, but I still do not really know where to go with this, I really need help.

Thanks for your time,
Also Merry Christmas too!

i think @Thomas_Mahon already gave you the answer to your question. Because CADTextData.FromLayers node references netDxf assembly, it requires the imported DWG to be “temporary exported to dxf” in order to read the text data from CAD. Hence it is required of revit for the transaction to be completed in order for export to begin. If not the database will remain as empty. And hence “nothing will be exported”, which resulted in your empty output. He also already pin point that the linking of dwg is outside of transaction in the custom node.
An workaround i can think of without changing the custom node, is to add transaction start before the import dwg node and add transaction end after the import dwg node. CADTextData node shouldnt require any transaction node as it is already pre-built in the node. Try that and see if it works

HI Thomas,

Thank you for the advice but there is already a transaction visible in the script that you display :
link DWG
Too bad you didn’t see it, that would have allowed you to determine where the error really came from.

I made a short screencast with the OOTB Revit’s Import CAD tool to explain the problem.
CADTextData.FromLayers Screencast

It is simply your CADTextData.FromLayers node which does not accept certain characters.
The characters “.” are replaced by “_”.

So @dami.lorente, replace the layer Name “.D San” ​​by “_D San” ​​or use the default value (null) of the CADTextData.FromLayers to solve your issue.
You don’t need the List.Cycle node and can get the desired result on the first try with this fix.

I’m sure in the next bimorphNodes update this little annoyance will be gone.

Merry Christmas !

2 Likes

Funny how I completely overlooked that, I glanced over your code and was looking at the mainline function beneath where you have you transaction…2019 was a long year :sweat_smile:! There was nothing wrong with your code btw, I was highlighting drawbacks of certain processes in the Revit API that require no transaction which can cause unexpected results with other process that do; albeit its exporting not importing which caught me off guard!

Thanks for investigating the issue; it appears to be caused by the DXF export which the CADTextData.FromLayers node must perform as this allow the text data to be extracted (its not possible via the Revit API). I haven’t had time to investigate yet, but its likely to be caused by either a regex process the node uses to clean escape characters which appear in the DXF after export, or there is simply a limitation in the DXF format which doesn’t allow periods at the start of layer names and this is what is causing the problem.

I’ll update this thread once I get time to investigate and find the cause. In the meantime, @dami.lorente please use @Alban_de_Chasteigner workaround or map the layer names from the CADTextData node to the CAD.LayerNames (which are correct) as I’m not sure when I’ll find the time to publish an update as January is always a busy month.

2 Likes