Need help with "CadTextData.FromLayers"

[dami.lorente]

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.

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

[dami.lorente]

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.

[jacob.small]

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.

[Thomas_Mahon]

@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 @jacob.small 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.

[Thomas_Mahon]

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!

[dami.lorente]

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.

[dami.lorente]

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!

[stillgotme]

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

[Alban_de_Chasteigner]

HI Thomas,

@Thomas_Mahon

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

Thank you for the advice but there is already a transaction visible in the script that you display :

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

@Thomas_Mahon

Update: the problem isn’t BimorphNodes:

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.

@Thomas_Mahon

package would need updating

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

Merry Christmas !

[Thomas_Mahon]

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 ! 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.

[Thomas_Mahon]

This issue is fixed in BimorphNodes v4.0.0. The problem is caused by the DXF export which the node performs to enable the parsing of the text (its not possible via the Revit API). DXF doesn’t support periods in the layer names and converts them to underscores automatically when exporting from Revit. In the update, any CAD file which contains layers with periods will not be supported and you’ll need to open your CAD file, remove these characters from your layer names, then reload it into Revit to use the node. More details about v4 will be posted on the forum - its scheduled for release this month; thanks for reporting the issue!

[Omar.Elwan]

Hello, Thomas,
I still get the error as clarified in the picture below. I use the BimorphNodes 4.1.1
Can you help me out with it?
Thanks

[Thomas_Mahon]

Hi @Omar.Elwan indeed - just do as it says on the tin: remove any unsupported characters from your DWG layer names then try again! You cant use periods for example as they’re not supported hence why you are seeing this exception.

[Omar.Elwan]

Ahh actually, there are too many layers in the CAD file.
It will take a long time to do such task.
I was wondering why not using try-except in the node script? this may skip layers with unsupported characters. I suppose you have a reason for that, don’t you?

[Thomas_Mahon]

Yeah as it would sweep the problem under the carpet and I’d have even more users complaining that the node doesn’t work, plus the layerNames input filter fails if I allow it! You might be able to copy your DWG and use a LISP routine to remove the unsupported characters? This limitation comes from the export to DXF the node has to use to be able to extract text from the CAD file so I cant do anything about it; there are no workarounds.

[jacob.small]

@Omar.Elwan

Ahh actually, there are too many layers in the CAD file.

Beyond a LISP solution @Thomas_Mahon indicated, you could use Dynamo for Civil 3D.

[Omar.Elwan]

Thanks, misters @Thomas_Mahon @jacob.small .
I learn from you a lot.