CAD FAQ
Question:
How OFFSET command works on a true ELLIPSE entity? It seemsthat it
will give different result for the same ellipse under different circumstances.
Answer:
Yes, it is true that OFFSET may produce different results upon the same
ellipse entity under different circumstances.
The true parallel path of an ellipse is not a true ellipse. It is a path that can only be
approximated by spline, which is not directly supported by TwinCAD of current release. So,
if the OFFSET operation is to create a geometrically parallel entity, then it will
certainly fail or reject the operation when you pick up an ellipse.
However, an ellipse can be a projected circle under PUCS mode. The OFFSET operation
to such an ellipse can thus be defined to create an offset to the projected circle. That
is, it is the original circle being offset and then projected to produce the required
ellipse. This feature is useful in creating parallel projected drawing.
So, under PUCS mode, if the selected ellipse satisfies the requirement of a projected
circle, the OFFSET command will give the result as mentioned above. Otherwise, it will be
rejected, assuming that the operator is trying to create an offset projected circle while
not setting up the correct PUCS axis for it.
If the operation is not under PUCS mode, then the OFFSET command will give you an ellipse
result by directly modifying the length of the original major and minor axes. Of course,
this is not the true parallel path to the original, but would be close.
If you do need to create a true parallel path of an ellipse, you can explode the ellipse
into polyline first and then create an offset to the polyline. You can control the
precision of the ellipse approximation by setting the system variable @splineseg to an
appropriate value, before exploding the ellipse.
Question:
When the system variable @MIRRTEXT is OFF, the texts resulted from the
MIRROR operation may sometimes be different from the one produced by AutoCAD. Is that a
bug or a rule difference? What should I do, if I need the same result as what I will
get from AutoCAD?
Answer:
This is a rule difference, not a bug. The resulted text may differ only in
its orientation within its bounding box. You may use FLIP command (a TCL/TCA program
shipped with the package) to flip over its orientation to the other alternative.
When the system variable @MIRRTEXT is off, the MIRROR command operation over a Text entity
will be treated differently. The Text will not be mirrored to produce the geometry result
of its text strokes, but instead to produce a Text that remains the same readablilty
within the same bounding box which is virtually mirrored in geometry.
The problem is in the text orientation within the mirrored bounding box. There are
apparently two possible results. TwinCAD always takes the one that has the base line which
is the geometry mirror of the original one. This gives a clear and consistent definition
in mirror transformation. On the other hand, AutoCAD determines text orientation by
maintaining its original "reading direction", which does not have a very clear
definition from AutoCAD's documentation. The idea of maintaining the original
"reading direction" of a text after mirroring is probably from the way we create
dimensioning text annotations.
You may try to mirror a text serveral times in AutoCAD with respect to lines at different
angles, and observe the change of text angles that result. You would find the change is
not continuous at certain angles (depending on the original text angle). A major drawback
of this mirroring scheme is in mirroring a paragraph of texts. The text line
ordering in the paragraph may be altered after mirroring. You can easily see this by
mirroring a horizontal dimension with a text annotation containing upper and lower
tolerance expression with respect to a horizontal line. This is probably one of the
reasons that AutoCAD would replace the dimension texts with a single MTEXT after R13.
Question:
What is the operation rule of QCHANGE over a line in changing its length?
Answer:
When you issue QCHANGE and pick up a line, you are going to change the length of the line
(about the same function of LENGTHEN from ACAD). There are several ways to complete the
change:
- By specifying a fix length value.
After picking the line, you may directly enter the desired length of it. QCHANGE will
modify the nearest end point to the pick point to meet the length requirement. If
the length value is given negative, the resulted end point will be in the opposite
direction of the original line.
- By specifying a relative length increment value.
After picking the line, you may enter a relative value in the form of @val to specify an
increment or decrement of the line length. If the value is positive, the line will be
extended from the end point nearest to the pick point; otherwise, it will be shortened by
the given value.
- By designating a point.
After picking the line, you may designate a point or enter a point coordinates. If the
projection point on the line is beyond the line limit, then the line will be stretched
from the nearest end point to the projection point. If the projection point falls on the
line, then the line segment containing the original line-pick point will be retained, and
the other line segment will be trimmed from the projection point to the opposite end
point.
- By extending to a boundary object.
After picking the line, you may issue PER snap directive to snap at a boundary object. The
line will be extended ortrimmed to the geometry intersection point with that object.
The rule is the same as that in rule 3, except the projection point is replaced
with the intersection point.
The rules stated above also apply to the ARC entity.
Note that in the first and second rules, it is the nearest end point of the line to the
pick point that will be modified, not the other end point.
Question:
I try to DIVIDE an Ellipse, only get an erroneous result. Does
DIVIDE command support Ellipse as the target for division insertion? If not, what should I
do to resolve this problem?
Answer:
According to TwinCAD document, the DIVIDE/MEASURE commands support only
Line, Arc, Circle and Polyline as the measuring targets, and the Ellipse is nowhere
mentioned. This implies that the Ellipse entity is not officialy supported within the two
commands. On the other hand, the system did not decline yor request outright for dividing
an Ellipse, but simply treated it as an Arc. That is why you would get erroneous result.
The updated version of TwinCAD after V3.1.049 and its DOS counterpart after V3R4C1 have
already included the capability to divide/measure along an ellipse, an elliptic arc or a
polyline containing elliptic arcs.
If you do not have the update yet, you may explode the ellipse into polyline first, then
proceed to the DIVIDE/MEASURE command.
Question:
Can PASTECLIP command paste in a paragraph of text from MS-WORD? If it can not, how do I
paste in Text information into TwinCAD?
Answer:
By design, the PASTECLIP command can not paste in Text information from the clipboard. It
is intended to paste in drawing (either created by TwinCAD or by AutoCAD) only. Thanks to
that, its operation can therefore be simple and direct without any confusion. As for
clipboard data with formats other than the drawing formats registered by TwinCAD or
AutoCAD, you will have to use other commands to do the paste-in conversion. Currently,
there is one command called PASTEXT, which is used to paste in Text information from the
clipboard. You can use PASTEXT to paste in a paragraph of text which was cut from a Word
processor such as MS-WORD. The PASTEXT command is an external command developed in TCL
language. If you don't have this program, you can download it from our web site
(http://www.twincad.com or http://www.tcam.com.tw). You may copy this PASTEXT.TCL or
PASTEXT.TCA (for lite mode) program into COMMANDS sub-directory to have this command
support.
Question:
Why some command aliases can be repeated with the space-bar and some can not?
Answer:
Actually, none of the command aliases can be repeated by pressing the space-bar. The
reason is that activating a command alias, just like activating a screen menu, will make
the associated script be fed into the system and executed. So, they cannot be repeated by
pressing the space-bar.
Of course, if the "script" associated with a command alias is just the name of a
command, then you may repeat that command by pressing the space-bar. In fact, it is the
last executed command that you are repeating, not the associated command alias script.
Question:
I wanted to measure the distance between two parallel lines. So, I issued the DIST command
and, intuitively, used two successive PER snap directives to snap on the lines. To my
surprise, it failed. What should I do to measure that distance ?
Answer:
If you are certain that those two lines are parallel, you may replace one of the PER snap
directive with the NEAR directive to snap on the line, so that a specific LINE solution
can be found for the DISTance measurement.
Basically, the DIST command will call out the internal 2-point LINE command to determine a
line of which the length is of interest. Since in the LINE command, you can not use
PER/PER on two lines (parallel or not) on the same spatial plane to define a line, the
DIST command would certainly fail in the same cases.
P.S.: The update version V3.0/R3 has included the support to treat this condition as a
special case. You may use PER/PER to measure distance between parallel lines now.
Question:
The PURGE command can not purge all the un-used blocks in one shot, why? How can I make
sure that all the un-used blocks are purged?
Answer:
This is because these un-used blocks are really in use before the purge operation. When
you issue PURGE command, the PURGE command will start scanning the whole drawing database
and mark all the un-referenced blocks for deletion. A block will be purged off when it is
no longer in reference.
However, if there are two blocks, say A and B, and block A contains a reference to B while
A is not referenced anywhere in the drawing, the PURGE command will delete A and keep B
(since it is in reference). The block B will become un-referenced only when A is deleted
from the drawing database with the purge operation.
You may issue the PURGE command again and again, until no more blocks are reported for
deletion. Then, all the un-referenced blocks will be removed.
Question:
I use STRETCH command in ACAD to stretch the Ordinate Dimensions generated by TwinCAD
(after DWGOUT), but it produces strange results. It has no problem at all if I
stretch the ordinate dimensions generated by ACAD. Does this imply that the ordinate
dimensions generated by TwinCAD is not fully compatible with ACAD?
Answer:
You must be using R11 or R12 that supports ordinate dimensions, since the R10 does not
support the ordinate dimensioning. So, the R10 DWG file produced by TwinCAD's DWGOUT
command can not have ordinate dimensions in the drawing. TwinCAD must disguise them as
some other dimensioning objects in the drawing.
In fact, as R10 does not support the Leader and Center mark as official dimension entities
(it merely draws them out), and the Ordinate dimensions are only supported after R11,
TwinCAD will disguise them as Angular Dimension entities in the DWG file. This would cause
no problem at all if you load the DWG file in ACAD, since it is the dimension blocks that
determine the picture of the dimension entities and the dimension entities in ACAD are
merely records of the creation of the dimension blocks.
However, if you issue STRETCH command to operate on such entities, the ACAD will actually
take them as Angular dimensions and try to re-produce the dimension pictures according to
the rules of the angular dimension! This is the reason why you would have a strange
result.
If necessary, you may stretch the ordinate dimensions in TwinCAD along the dimension line
by using the CHANGE/ALL command, or using the STRETCH command to any orientation after
V3.0/R3a. Or, DWGOUT the drawing file in R12 format by setting the system variable
@DWGVERSION to 1 after V3.0/R3b.
Question:
When I was selecting objects using window crossing, after indicating the first corner
point, I issued a transparent command 'ZW to change the view window. After the view window
was changed, I continued to indicate the second point for the object crossing window.
Unexpectedly, the object outside the view window but actually inside the crossing window
was not selected! Why? Is there any problem?
Answer:
No, there is no problem at all. This is normal. All object selections or object pick-ups
by means of the user screen interface are limited to those objects appeared in the drawing
window only, no matter how the pick points are given.
In fact, the searching of objects crossed by a picking target box are not directly from
the drawing database (if so, the search time would be terribly long), but from a display
list that contains only those clipped drawing vectors seen from the screen, so that the
search time is greatly cut down. This limitation is thus a natural result of the
implementation.
Question:
How to define a command alias that can be invoked transparently?
Answer:
All you have to do is to add a single quote (') before the alias name in the command alias
definition. This quote will tell the system to allow the command alias to be invoked
transparently. Yet, this does not mean that the command script associated with a
transparent command alias will be successfully executed in the transparent mode. The
script activation of a command alias works the same way as the menu script which is
activated from the screen menu. The only difference is the way to activate them, that is,
one by the command word and the other by the graphic user interface.
Question:
The BPOLY/Auto is intended to search out the maximal coverage of
area automatically from the selected boundary objects. What is that all about?
Answer:
The BPOLY/Auto command provides a very useful feature in finding the maximal areas bounded
by the selected boundary objects. The boundary objects are used to form networks, and the
BPOLY/Auto will find out all the maximal area coverage of each independent network. Those
independently created areas will become the base surfaces, holes or islands of the final
regional area, according to their topological relationship determined by the even-odd
rules. With this feature, the operator no longer needs to select the loops of area from
the networks one by one, but simply enter the sub-command option "Auto" to
determine a maximal regional area. The "independent networks" are defined as
networks that do not connect with one another. If there exits any connection between them,
then a single yet more complex network will be formed. For example, two concentric circles
are independent networks, and BPOLY/Auto will locate two independent maximal areas from
them. One is the outer circle and the other the inner one, forming a ring as the final
regional area. However, if we draw a line across the two circles and divide each of them
into halves, then they will form a single yet more complex network because of the
connection. As a result, BPOLY/Auto will locate only one maximal area out of this network,
i.e., the outer circle, which is the total combined area of those independent loops from
the network. From the latter case, we can clearly see that there are 4 loops in the
network. You may have C(4,1)+C(4,2)+C(4,3)+C(4,4)=15 kinds of choice to select those loops
to form a regional area. The ring from the former case is only one of the possible
combination. Obviously, from a complex network, the BPOLY/Auto will not guess how you want
to combine those loops and make the pick. What it can do, however, is to choose the unique
and undoubtedly one, i.e., the maximum one. If that is not what you need, then you will
need to make your own pick manually. Based on this combinatory principle, if you have
selected some loops from an independent complex network in advance, then it is assumed
that the combinatory regional area of that network has been determined and should not be
altered by the BPOLY/Auto processing. This states another important rule: that BPOLY/Auto
will neglect the networks that contain previously selected loops.
Question:
How to snap on the center point of a center mark entity? Why can't I snap the point by
using INTersection directive?
Answer:
You should use CENTER directive to snap on the center point of the center mark entity,
instead of the INTersection directive. This is because the center point of a center mark
entity is a geometric data of the entity, not an intersection point of two crossing lines.
However, the new release of TwinCAD update version has included the support for snapping
on this center point using INTersection directive.
Question:
What's the difference between TwinCAD's SLD and ACAD's SLD files? Are they compatible?
Answer:
Basically, the SLD format adopted by TwinCAD is nearly compatible with ACAD's SLD format,
except for the following:
- There is no limit on the number of vertices for a solid-fill area in the TwinCAD's SLD
file, while ACAD can not handle such solid-fill area with more than 10 vertices. Most of
the desk-top publishing software do not have this limit.
- TwinCAD's SLD file format allows complicated solid-fill area with holes and islands by
means of starting vertex checking among the vertices list, while ACAD does not support
this extension. Some of the desk-top publishing softwares do support this extension
implicitly.
- TwinCAD uses physical color (VGA palette number) for pen number, while ACAD uses
drawing's logical pen number.
- TwinCAD uses logical drawing space with 1:1 aspect ratio for the vector image despite of
the graphic device in use, while ACAD uses physical drawing space with a physical aspect
ratio taken from the graphic device at the time the SLD is prepared.
In fact, TwinCAD can load and view the SLD files generated by ACAD without problems.
And, if the slide files generated by TwinCAD do not contain complicated solid-fill areas,
it can also be viewed by ACAD. Of course, the display color may look different.
Question:
How to create a user variable? Is the operator allowed to modify such user variables
freely?
Answer:
All new user variables must be created by explicit calls to the TCL uservar() function,
either from a TCL application or from an expression entered directly to the command line.
Once a user variable is created, it can be accessed from within a TCL expression as if it
were a predefined system variable, as long as the access matches with its declared data
type. The system also provides a USERVAR command to help the operator in viewing and
modifying the existing user variables. It works in the same way as the SYSVAR command
does.
The modification of the content of user variables by the operator, however, will depend on
the data attribute assigned to the individual variable at its creation by uservar()
function call. If it was set to READONLY, then it can not be modified in the normal way,
including the USERVAR command operation. To modify a READONLY user variable, the uservar()
function must be called explicitly for the job.
For details on uservar() function, please refer to the document "TwinCAD Command
Language(TCL) Reference Manual V3.1"
Question:
I've already set @POFSTCANG to zero, why sometimes there are still unwanted arcs added to
the offset polyline?
Answer:
This is because the offset distance is too large for the polyline to have a proper offset
path without introducing additional arc segments. It happens when two adjacent segments
can not have a proper intersection after being offset with the given distance, and thus an
additional arc must be added in between to make the path continuously joined. It always
happens when at least one of the segments is a circular arc, making a sharp and concave
corner angle, and the offset path is made outside of the corner. Offsetting the arc will
shrink it toward its center, and make it smaller, which is farther apart from the other
offset segment. As the offset distance increases, they lost their intersection eventually.
To prove it, just explode the polyline and offset each segment to see if they can be
joined together by extending them to the intersection point.
Question:
I tried to add a few toolbar definitions of my own in the MNU file. But TwinCAD failed to
create them when the menu file is loaded at startup. Why? What should I do to solve this
problem?
Answer:
That is because you had added too many toolbar definitions to the MNU file, and there was
not enough heap space for TwinCAD to accommodate them. You have to remove or comment out
some of the unwanted toolbar definitions from the menu file, not just to turn them off
from TwinCAD. Reducing button counts in a toolbar definition is also helpful in relieving
the problem. Currently, TwinCAD allocates memory from the heap space for toolbar creation,
and the heap space reserved for that purpose is limited in TwinCAD. The required size of
the memory space for a specific toolbar definition depends on the number of buttons it
contains. The size of the button or the size of the bitmap file used for the button face
is irrelevant. P.S.: For version after 3.1.048 (inclusive), each toolbar will take up a
fixed 100 bytes of heap memory space. The number of buttons contained in a toolbar is now
irrelevant to the heap memory usage. This would allow more toolbar definitions in the menu
file.
Go to top
|
|