Drafting Pratices?

That's OK.

Best regards,

Igor.

 

You are welcome, Kev.

As for the special program for 3D drafting I have to disappoint you. No, I
don't use anything very special yet for my work. Out of the box CAD with some
cosmetic customization and a few useful lisps can go a long way. Non the less I
am going to trade AutoCAD for Inventor. Currently am in a transition period.

Regards,

Igor.

 

That's OK. <<

So you've retracted your errant claim that XREFd TB are proven to be the most efficient method (time and time again)??

 

I'm sure you know this trick, but I'll repeat it for the benefit of others.
You can attach an xref and still use attributes in it. Here are the steps:

1. Insert the Titleblock file as a block.
2. With Express Tools installed, use the BLOCKTOXREF command to convert the
inserted block to an xref.
3. Edit the original block attributes left in the xref using DDATTE.
Unfortunately, EATTEDIT won't work.

Try it... it works!

--
Daniel J. Altamura, R.A.
Altamura Architectural Consulting
and SoftWorx, Autodesk Authorized Developer
--------------------------------------------------------------------

most efficient method (time and time again)??

 

No, I just don't talk to a cadaver. It is futile.

 

You make a claim that something has been "proved time and time again", so I ask for said proof. You fail to supply said proof and then say talking to me is futile. Yep, I guess you're right.

 

I'm sure you know this trick, but I'll repeat it for the benefit of others.
Try it... it works!<<

Yes I know it works, if the file is already an xref use XREF->BIND->INSERT to make it a block first.

However, I am loathe to build into a file legacy data that's based on a program "glitch" that may or may not be supported by future releases. We have enough trouble with program "features" that change from one release to the next, I don't wish to seek out more from "accidental" events.

 

Dear OLD-CADaver,
</subliminal message>
I don't understand why you feel the need to hide behind a moniker
</subliminal message>

I believe I've made mention of this before, but it IS the best, most
efficient method I've been fortunate enough to find. Particularly when
dealing with clients/owners who cannot seem to decide (for reasons
unbeknownst to me and over which I have no control), except after MULTIPLE
revisions, WHAT information they want to include in their titleblocks.
<sigh>

Perhaps this does not occur in your particular line/scope/perfect-world of
work, but it IS a salient issue for many others, including myself. That
being the case, xreffed titleblocks, with editable attributes yet, seem to
be the cat's meow for us, as several have expressed appreciation over
learning how to do this.

Best regards,
David Kozina

PS I understand that 2005 includes new functionality (sheet sets w/
manager) which may also help in these respects - but as I have no experience
with this at present I cannot comment on how well this new feature would
work for me.

most efficient method (time and time again)??

 

program "glitch" that may or may not be supported by future releases. We
have enough trouble with program "features" that change from one release to
the next, I don't wish to seek out more from "accidental" events.



OLD-CADaver,

I understand your reason, and certainly respect your decision.

It can be difficult at times to weigh beneficial aspects of doing things a
certain way against the potential gotchas.

What follows is a portion of the thread that dealt with this in March of
last year, which first enlightened me as to the whys and wherefores of doing
this, and WHY the scales tipped in favor of the benefits to be gained over
the potential gotchas...

(Please note that I had similar concerns...)



Reply From: Young, Darren J.
Date: Mar/06/03 - 14:14 (GMT)
Re:

That explains it. We're talking about two different things. When I
mentioned Attributed Xrefs, I was talking about an XREF that contains
Attribute Definitions no different than a block with attributes, only
it's Xref'd in.

Try this, INSERT a block witrh attributes. Then use the Express Tool
"Convert Block to XREF to change the blkock to an XREF. The XREF now has
fully editable attributes just like a block (attributes changes stay in
the drawing it's referenced in) but with the geometry that updates like
an XREF (changes to the xref appear in the drawing it's referenced in).

EATTEDIT, BATTMAN, ATTSYNC, none of these work in this situation because
they filter XREFs while the old DDATTE does work perfectly in this
situaiton.


--

Darren J. Young


Autodesk Developer Network
AUGI Inventor Product Chair

Minnesota CADWorks, Inc.
PO Box 1172
Monticello, Minnesota 55362-1172
(763) 295-4433
http://www.mcwi.com
ftp://ftp.mcwi.com





Reply From: Kozina, David
Date: Mar/07/03 - 15:01 (GMT)
Re:
Darren,

DUUUDE! I *knew* I had seen something like this in an xref before - but for
the life of me I could not figure out how whoever did it managed to make it
work!

Now, is this a recipe for corrupted drawings and/or AutoCAD crashes
downstream - or is this THE ONE TRUE WAY to do titleblocks in one shot?

Inquiring minds want to know!
Thanks for the info.

Best regards,
David Kozina




Reply From: Young, Darren J.
Date: Mar/10/03 - 09:42 (GMT)
Re:

David,

Obviously, when you push the limits of AutoCAD beyond what it's intended
to do, there's the possibility that a future version could leave some of
the things non fuctional or corrupt. However, in this case, I think
this risk is VERY minimal and I'll explain why.

To understand why using an Attributed XREF in this way poses a very
minimal risk of future drawing corruption, you need to nderstand how
Blocks and Attributes are handled.

When you generate a block, it's stored in the block table. This "Block
Table" serves as a template for each insertion of the block (which in
AutoCAD's database is an "Insert" entity.

When you add attributes to the mix, your block table definition of the
block also contains Attribute Definitions. These definitions serve to
prompt and display information attached to the block.

If the Attribute definitions in the block's block table definition are
constant (read-only), they act almost just like any other piece of
geometry in the block like lines, arcs, text, etc. Hoever, when the
block's table definition contains non-constantg attributes, something
special happens when you insert the block.

When you insert the block, an Insert entity is created lie before but
now it adds ATTRIBUTE "sub-entities" off of the main Insert entity.
Because the attributes are "sub-entities", it allows the block to
maintain seperate values between block insertions. If the block
definition is updated, the block changes but the sub-entities aren't
touched.

Now, when you attach an XREF (which is also an Insert entity), AutoCAD
ignores all non-constant (read-writre) attributes when it attaches the
block. Those that are constant, appear just like text only using their
values. This is a limitation in the ATTACH operation that makes it not
prompt for the attributes and ignore them.

By using the Convert Block to Xref, the tool doesn't strip out the
attribute "sub-entities" that may be attached to the block insertion. It
just adds them to the XREF's version of the Insert.

XREFs and BLOCKs when inserted are both Insert entity types and an
Insert entity type is allowed to have sub-entities according to
AutoCAD's database rules. That's why it works with XREFs. It's a
limitation in the attach process that under normal conditions would
prevent the attribute definitions from becoming attribute attached as
sub-entities.

In fact, an Insert entity does not have to have the same number of
attribute sub-entities as the block definition. The block definition
could have no attribute definitions and a block could still have
attribute sub-entities. This normally would happen if a block with
attribites is redefined without attributes even though other insertions
with attributes exist in the drawing. Likewise, a block definition could
have attribute definitions and the Insert of that block have none at
all. There's really no rule that says that the attributes need to match
between the Insertion and the definitions. Because this is common,
that's why Autodesk introduced the ATTSYNC command in 2002.

Unfortuantly, the newer block tools BATTMAN, EATTEDIT, ATTSYNC
automatically filter out XREFS when they really don't need to. That's
why to use this type of setup (attributed XREFs) you need to use the old
DDATTE command.

I've created a set of drawings using attributed XRefs and saved them
back to r11/r12 format and this setup still works so it works in every
version of AutoCAD from at least r11 to 2004. (I didn't rey earlier
versons because I don't remember when Xrefs were introduced).

With this in mind, corruption isn't something I'd worry about here
because AutoCAD not supporting attributed Xrefs is really a limitation
of the commands in AutoCAD used to manage Xrefs, it's not a restriction
that the AutoCAD database has which can be verified by looking at the
DXF reference and seeing the flags that are and are not allowed for
xrefs and attributes.

Secondly, it's been this way since at least r11 without being broke so I
don't think it'll happen any time soon. ;-)

Thirdly, it's one of Autodesk's products that allow this condition
anyway, the Express Tools "Convert Block to Xref" command although
anyone with lisp/vba/arx programming knowledge could do the same thing.

Lastly, in the unlikely (in my opinion) event that a new version of
AutoCAD could have problems with drawings created in this manner, it's
as simple as batch processing all drawings in a script file prior to
upgrading and binding all the attributed xrefs. Easily fixable.

Any questions? ;-)

PS: I recenty sent this attributed Xref tip to Lynn Allen and she
expressed interest in working it into a future article of hers. If she
does that, if enough people start doinmg this, perhaps Autodesk will
have to some day officially support it.

--

Darren J. Young


Autodesk Developer Network
AUGI Inventor Product Chair

Minnesota CADWorks, Inc.
PO Box 1172
Monticello, Minnesota 55362-1172
(763) 295-4433
http://www.mcwi.com
ftp://ftp.mcwi.com

 

What he keeps say is "TB should be set in stone at contract". In my world it
is not. Logos, PE stamps, submittal stamps, dates, phone numbers, etc all do
in fact change. This is why I also believe that xref'ed TBs are the only way
to go. What he must have is 1000's of dwgs in each job (info from a previous
thread) each drawing with a TB to update, and is unwilling to admit that
only having to change one is not somehow faster, easier, more efficient,
simpler to do.

<snip>

 

I don't understand why you feel the need to hide behind a moniker <<

No hide intended, I 've CADaver on these and other boards since the mid '80's. Just a habit I picked up when posting from my place of employment, more to protect them from any blow-back caused by my sweet genteel personality than anything else. If you must know, My name is Randall Culp, my own business is Falcon Design Services and I am currently under cntract to a large multi-faceted EPC (design/build/manage) firm in Texas. You'll see me post under that name when posting from my home or a "nuetral" location.


For you... which is a far cry from "it's been proven time and again"


Oh, I understand the whims of clients quite well, all TOO well actually. But we control that at contract. If you're in a "cost-plus" world where you're going to be paid by the hour, whether it's productive or not, then it's fine (even profitable) to expend effort on keeping a titlblock pretty. In our short term "lump-sum" world, we haven't the schedule, manhours, or the inclination to expend any time on editting a client's logo. Add to the the volitility of client's business position at any given time requires us to maintain titlblocks in legacy contracts yet update titleblocks for new work, XREFing loses it's luster. So for us, XREF'd TBs are not the most efficient method, and that is what prompted my response.

Are you using some method other than the Et BLOCKTOXREF trick? As I've posted earlier, i am loathe to build legacy data based on a program "glitch" that may or may not be supported in the future. But even if that becomes a viable core tool, XREF'd TBs will provide us little production benefit.

 

I understand your reason, and certainly respect your decision.
It can be difficult at times to weigh beneficial aspects of doing things a certain way against the potential gotchas.
What follows is a portion of the thread that dealt with this in March of last year, which first enlightened me as to the whys and wherefores of doing this, and WHY the scales tipped in favor of the benefits to be gained over the potential gotchas...
(Please note that I had similar concerns...)<<

I remember the thread (or at least one similar somewhere) and as I recall I posted the very same concerns. The primary of which would be the author of the express tool "accidently" "fixing" the program and dropping the attributes from every file with such a legacy

 

What he keeps say is "TB should be set in stone at contract".<<

If you're being paid by the hour, and the client doesn't mind paying you to play with his TBs, then go right ahead. We run "Fixed Price" lump-sum contracts with short schedules and haven't the time, manhours or inclination to spend time diddling with a client's logo.


-- If a client hasn't determined a company logo by the time he issued an RFQ I have more conrcerns about his organization than just his titleblock.

-- Submittal stamps and dates are covered in the revision history attributes. The revisions and dates on our drawings are a drawing by drawing basis, so are not the same between drawings. A single file may have 20-30 drawings, each with a different revisions number and issue date. If a piece of equipment changes on the roof, we only revise and re-issue that drawing

-- Phone numbers?? on a titleblock?? Okay...whatever.

-- PE stamps? In the XREFd TB?? So that every file, no matter it's stage of developement, contains the stamp prior to being reviewed by the responsible PE?? Can you say litigation?


Yep 1000's and 1000's of drawing. But nope, not a single TB to update. Anything that is not revision-volitile is in the block and set in stone at contract. I the recent past we had one client whose organization changed ownership and requested a titleblock shift shortly after the job kicked off. After agreeing to the Change Order and receiving his check, we batched the redefinition of the TB with Scriptpro in a few minutes. That's the only time we've had a TB mod request in the last 12 or so years.

 

RFQ I have more conrcerns about his organization than just his titleblock.

Logos contain a phone number, area codes sometimes change, get real.

In a logo, on a TB, yes, geez...

of developement, contains the stamp prior to being reviewed by the
responsible PE?? Can you say litigation?

Yes, every drawing. Nope only at the proper time is it inserted onto the TB,
once. Fast, easy done!

years.

Saw a thread the other day where someone said in 25 years he has NEVER seen
ANY job THAT DID NOT have the front door at the bottom of the sheet.
Whatever.

 

Logos contain a phone number, area codes sometimes change, get real. <<

I am real Phone number in the logo ... ?? ... these guys working out of their back bedroom?


Okay. iI did a quick check, and everywhere we do business requires the stamp and the signature on the plot itself. I asked 3-4 of the PEs here if they would like their stamp electronically on the file and all of them said no, a couple were very adamant about controlling liability. Good luck and happy lawyering.

 

Almost every Logo I have seen has had a phone number, address, etc. on it.

stamp and the signature on the plot itself. I asked 3-4 of the PEs here if
they would like their stamp electronically on the file and all of them said
no, a couple were very adamant about controlling liability. Good luck and
happy lawyering.

 

So if your PE is on the drawing at issue time, how do you deal w/:
Revisions - now a "working drawing" is already stamped?
Drawings that may be out of the office - If you have to send a dwg to a
client, do you remove the stamp? What happens if the client's drafter gets
a call from a contractor and shoots out copies w/ your stamp on it when they
may in fact be out of date?

I'm with O.C. on this - a stamp on a dwg is not a good idea in my neck of
the woods.

Matt

 

What is the difference between the drafter printing out outdated stamped
plans or making copies of outdated stamped plans.

I think more of the liabilty lies in them getting an electronic stamp to use
on different plans.

 

It ONLY gets put on at the PROPER time. If we need a plot without it, once
it is there it either A) gets removed from the TB, or B) the layer it is on
gets frozen or set to noplot. Most revisions are also stamped and signed.
And yes, if and when we send out e-files it is removed, one time only from
the TB and it is gone from all drawing. Works perfect for us.

I want to see OC give a job with 1000's of drawing to his PE to wet stamp
and sign!

 

I want to see OC give a job with 1000's of drawing to his PE to wet stamp
and sign!

stamp and the signature on the plot itself. I asked 3-4 of the PEs here if
they would like their stamp electronically on the file and all of them said
no, a couple were very adamant about controlling liability. Good luck and
happy lawyering.