Blocks in LDT 2006 Inserted at the Wrong Scale
Michael Farrell reports recently on CADVault about
what he considers a bug in this latest release of 2006
software...
From a user -I'm trying to generate a solution and make
others aware of what I consider a serious flaw in the
2006 Land Desktop software.
The problem is the new core AutoCAD feature of block
scaling and how it interacts with Land Desktop. In
essence, if your drawing is set to feet and you insert
an architectural block (or metric) and the units in that
block are set properly, it will scale the block
automatically to your unit settings in your drawing.
Of course after 20 years of not having this feature (it
has been available via design center since 2000) most
companies have an extensive block library with
the "insert units" set to "who knows what" because it
didn't matter and the actual block drawn in the same
units that they typically work in because it did matter.
Now enter 2006, This functionality has been extended
to the normal block insert command, Symbol Manager
and all LDT routines that I've experimented with such
as profile datum block, alignment label blocks, etc.
They have conveniently set most of these blocks
to "Inches" whereas in previous releases standard
blocks such as the datum block, north arrow, scalebar,
etc. were set to "Unitless". This results in different
block definitions in pre-2006 drawings and different
behavior when using block commands. In the case of
my profile datum block, it is some how factoring the
vertical exaggeration scale factor into this equation
(have not tried to figure that one out yet). Older
drawing block definitions are treated differently than
new ones in that the scale factor is applied directly to
the x,y scale in the former and via a new thing,
block "unit factor" in the latter. I might add that the
unit factor, apparently can't be edited so you end up
with a unit factor of .083 and a scale factor of 240 to
make 20 scale blocks.
There are workarounds, if you set INSUNITS (drawing
setting) to "0" or Unitless and set INSUNITSDEFTARGET
and INSUNITSDEFSOURCE (system settings) to "0" or
Unitless it will work but every time you access drawing
settings through the project menu, it will reset your
INSUNITS. And if you forget to set your units prior to
running a LDT routine that uses blocks, don't forget to
purge the old block definition out before you reset your
units, and rerun the routine.
It seems like a lot of work to fix something that wasn't
broken to start with.
So far, I have been successful in getting this logged as
a defect with Autodesk support. I have put a lot of
effort into resolving this issue and have been told that
a solution will only be developed if the issue gets
sufficient complaints. Although once you understand
what's happening you can make it work, when you are
deploying LDT across several offices and multiple users
(some still struggling with LTscale, paperspace and LDT
basic project association), little things like this can
really snowball.
I have decided not to deploy 2006 based on this
defect.
From Michael -In addition to the suggested 'work
arounds' this suggests
a couple of other strategies.
One: test this unexpected feature/benefit to see how,
when, or where
it impacts your organizations work flow. If the impact is
as imagined,
call, and email your vendor, the various discussion
groups, etc.
Given that Autodesk is already aware of the problem,
as stated by Doug
this is a serious issue to the Civil community of users.
Unless the noise
gets loud enough Autodesk will NOT fix this problem.
They may yet
ignore the problem instead pitching you on the new
version; as yet to be
released to justify subscription. The plan is to kill off
Land Desktop as it is,
so I see no fix forthcoming unless the problem IS
verified to exist within
Civil 3D and it's interaction with your legacy blocks. I
see some of that
NOT being an issue in regards profile blocks and various
other Land Desktop
blocks, as they are replaced in kind with their C3D
brethren.
Should this problem prove to be as noxious as it
sounds, I can hardly imagine
the immense task the civil users are facing in an
attempt to migrate their
legacy blocks and on-going projects into 2006.
I will point out that a small addendum to your license
agreement allows you
to continue to maintain your current version (at this
time) in perpetuity as long
as you maintain your subscription. (Or until they
change the license).
I would suggest this is a good time to review your block
library. Should you
experience the above problem let us know.
Consider setting a Blank MAP session to query your
blocks into a new session
consider changing Attributes for FIELDS where possible
and WBLOCK the file
into a NEW 2006 version of your block library. This can
be batched out.
I know it sounds like a lot of work, however it may be
the only solution that
works in the long run.
I suggest that you also take this opportunity to
consider converting your Civil
blocks into Feature Classified objects, and start
delivering your data in the
Value Added state of already being Classified and
assigned appropriate GIS
extended data. This functionality also translates into
better more efficient
cost estimates for your projects.
Now, I have been working in AutoCAD 2006 and have
experienced some quirkiness when inserting legacy
blocks, but since I was not the source of the blocks, I
had been chalking it up to the fact that the blocks
were legacy. Now, I am going to be looking at this a
bit closer.
