Attribute label blocks

Mike

Our company uses a block for contour labels which uses an attribute to grab the elevation of the polyline it's placed on and automatically give us the number, along with a wipeout to block out the polyline behind the label. This is working fine in our base xref, but in our sheet file, that label changes to "NaN" or some other odd strings of text like "5E45". The block worked with no issue in Civil 3D, but not so much in Brics. I can provide a couple files if necessary, but I wanted to see if anyone else had run into similar block/attribute issues. Thanks!

Mike

From our contact at Chasmtech
Mike:
NaN in a pdf means not a number.

I simplified the drawings and generated the PDFs.

Plotting from the x-labels drawing directly – all is good.

Plotting from Base drawing, everything is now NaN – so at least we are consistent.

I would ask that you issue a support request to Bricsys with the attached files. You will get higher priority than I.

Issue – NaN displayed in PDF file when using an X-Ref

X_labels.dwg contains elevation labels – X-Labels-layout pdf file shows these displaying properly.

BaseDWG.dwg has x_labels.dwg as an xref. If you check the BaseDWG-Layout.pdf. You can see that they are all now NaN.

Attached are the files referenced above. These attribute blocks worked fine in Civil 3D, but don't work no matter what I try in BricsCAD. This is now on the verge of holding up submittal of a major project unless a solution happens or I replace every one of several hundred labels with individual ones and manually edit each to reflect the elevation. Any help in resolving this matter would be awesome. Thanks!

Roy Klein Gebbinck

FYI: I do not experience this issue in V18.2.20.
If you have a V19 license you can also use V18.

Mike

@Roy Klein Gebbinck said:
FYI: I do not experience this issue in V18.2.20.
If you have a V19 license you can also use V18.

That seems to be Bricsys' work around as well. It doesn't seem to be the case in 19.1.11 either. Unfortunately this means several unbillable hours for my boss as I go through and install a secondary version on all the computers in the office...

Mike

This issue has been identified as a bug in the new version and should hopefully be fixed with the next update.

Joe Dunfee

Might they display correctly using Autodesk's viewer? You could use that just for plotting.

-Joe

Mike

Update:
This was identified as a bug in newer versions of v19, and has been fixed in v20.

Unfortunately, there was another bug underneath of that which I didn't realize was there. The idea of our contour label blocks is that they are inserted at a snap point (endpoint or midpoint generally) along a polyline, and then the attribute field within the block takes the elevation at which the block is located (UCS Z value) and changes the number of that label accordingly. At least that's the way it worked within AutoCAD/Civil3D, following these steps:

1. The block is inserted using INSERT, at an endpoint or midpoint of a polyline contour, with the scale being specified onscreen.
2. The block is copied using COPYBASE from the same endpoint or midpoint at which it was inserted.
3. The block is then pasted to another contour, using an endpoint or midpoint snap, at which point it picks up the new contour's elevation.

The last bit of step 3 is where we run into issues. The block ends up at the proper UCS Z value, but the field remains the same as the original. For instance, if I insert it on a polyline with an elevation of 450', follow the steps above and paste it onto a polyline with a 448' elevation, the block will have a Z value of 448, but the ELEV field and the number shown on the block will still read 450.

I've attached the blocks we used in Civil 3D, as well as blocks that Bricsys support have created by modifying the originals, and a stripped down drawing with just some polyline contours in it.

File key:
P_Cont_Tx.dwg - Original proposed contour label block
95665-P_Cont_Tx.dwg - Proposed contour label block, modified by Bricsys support
E_Cont_Tx.dwg - Original existing contour label block
95665-E_Cont_Tx.dwg - Existing contour label block, modified by Bricsys support
x_3_Diamond_16-006.dwg - CAD base containing polyline contours

The layers should be fairly self explanatory - E_... is existing, P_... is proposed.

The blocks modified by Bricsys support contain a point within them from which the defined attribute is supposed to grab the elevation.

I'm not sure at this point whether the issue is with the block, block attribute, or something with how BricsCAD handles attribute definitions.

Unfortunately,

Terry Dotson

We took a slightly different approach in MapWorks by creating Mtext objects and using it's built in ability to mask. The content is a field referencing it's own elevation property, so it takes on the elevation of any polyline it's placed on (with nearest osnap). Attached is a small example, the labels are created in automation by dragging a line up/down hill, one (in the middle) was moved slightly.

Roy Klein Gebbinck

The block are perhaps a bit old? They seem to predate the introduction of the BlockPlaceHolder field object. The attached block uses this object and can be copy-pasted. Note: to display the correct elevation after pasting you have to issue the _UpdateField command or the _Regen command.

BTW: there is a "pin" symbol at the origin. What is that?

Mike

@Roy Klein Gebbinck said:
The block are perhaps a bit old? They seem to predate the introduction of the BlockPlaceHolder field object. The attached block uses this object and can be copy-pasted. Note: to display the correct elevation after pasting you have to issue the _UpdateField command or the _Regen command.

BTW: there is a "pin" symbol at the origin. What is that?

Roy, you hit the nail on the head. Support finally realized that the blockplaceholder was the issue - we were trying to use a point within the block to grab the Z value, which of course was zero because it was referencing it within the block. They finally got it working this morning.

The blocks were necessarily old; they were created last year in Civil 3D, which at least at that point didn't have a blockplaceholder option.

@Terry Dotson said:
We took a slightly different approach in MapWorks by creating Mtext objects and using it's built in ability to mask. The content is a field referencing it's own elevation property, so it takes on the elevation of any polyline it's placed on (with nearest osnap). Attached is a small example, the labels are created in automation by dragging a line up/down hill, one (in the middle) was moved slightly.

Terry, not a bad approach, but we currently have Civil Site Design, which unfortunately isn't out for BricsCAD v20 yet. Regardless of the add-on, we currently don't work with surfaces at all, instead using contour polylines sent to us by our surveyors with whom we work. Generating a surface from those is less than accurate, and my boss doesn't want to move in the 3D direction just yet anyway, due to the lack of experience of some of our people.