Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Attribute label blocks

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!

Comments

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

    dwg
    dwg
    BaseDWG.dwg
    29K
    pdf
    pdf
    BaseDWG-Layout1.pdf
    49K
    dwg
    dwg
    x_labels.dwg
    128K
    pdf
    pdf
    x_labels-Layout1 (2).pdf
    38K
  • edited August 6

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

    pdf
    pdf
    BaseDWG-Layout1_V18.pdf
    43K
  • @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...

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

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

    -Joe
  • 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,

    dwg
    dwg
    95665-E_Cont_Tx.dwg
    391K
    dwg
    dwg
    95665-P_Cont_Tx.dwg
    378K
    dwg
    dwg
    E_Cont_Tx.dwg
    392K
    dwg
    dwg
    P_Cont_Tx.dwg
    412K
    dwg
    dwg
    x_3_Diamond_16-006.dwg
    682K
  • 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.

    dwg
    dwg
    example.dwg
    60K
  • 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?

    dwg
    dwg
    P_Cont_Tx_Roy.dwg
    21K
  • @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.

Sign In or Register to comment.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam