How do i get the existing drawing to change from architectural units to decimal units.
I can't get a drawing i had sent to me to change from architectural units to decimal units. I changed the units in SETTINGS. I also changed the DIM style and it has also stayed in architectural units (ft-in). So if i want to do an offset on a line it automatically assumes inches when you type in a number not feet. The units are set to ft.
0
Comments
-
You want the drawing to display decimal values, but you need to be specific.... Decimal feet? Decimal inches?
The quick-guess answer is that you may want decimal feet. Then, when you type a length of 1.5, BricsCAD assumes you mean 1.5 ft. Since the drawing "linear units" are set to be architectural, the "insertion units" must be set for inches. So, to convert it to be decimal feet, you must scale the entire drawing 12x. That will mess up your dimstyles, so you will want to redefine each existing dimstyle, to so that the fit value is also 12x what it was.
I've recently started work as a CAD instructor, so I am having to think through how to explain this to students.
Units have always been confusing within AutoCAD. And BricsCAD, as a DWG editor, has to follow their method of dealing with units. There are two unit-related setting to consider. One is "Insertion Units" and the other is "Linear Units". Your message doesn't specify which of the unit settings you are talking about.
But, yes, BricsCAD, if you set the insertion units to be inches, a number you type will be assumed to be inches. If you also set "linear units" to be architectural, but type a value like 12.5 or 12-1/2, it will assume you mean inches. The only way to type a value in architectural format, is to have the insertion units set to inches, and the linear units to be architectural. [ Sadly, BricsCAD can't convert automatically if you type a value that is not in the default "linear units" or "Insertion units" mode. You can't type 25.5mm and have BricsCAD convert it to 1" automatically. ]
ALL linear data and coordinates are stored internally as a decimal number. The "Insertion units" is a label that say what those numbers represent.
The "Linear units" setting of Architectural are actually more of a display setting, that converts those decimal numbers to show the architectural format by assuming those numbers are inches. It will do this even if the "insertion units" are set to be light-years.
So, there are plenty of ways to get into trouble with units. If I change the Insertion units to be meters, and then set the linear units to be architectural, a 12 units long line will list as being 1ft long. But, if I insert that same drawing with that line, into another drawing, that 12 unit long line will come in as 12 meters long if the recipient drawing is set to user meters. If you insert it into a drawing with a "insertion units" setting of inches, that line will automatically be converted to inches, 472.44" long.
Please let me know if the above helps, and if you might suggest a different way to teach this.
-joe
0 -
For some custom programs I do can enter 12' 3" 3/16 and it converts it to a decimal inches value. So a lot of work as a front end for line, circle arc etc.
Metric is just so much easier.
But
Circle rad 12.
Circle rad 1'
Both the same.
Set Radius or [Diameter] <>:15
Set Radius or [Diameter] <>:1'-3"
Both the same size0 -
The challenge with the U.S. converting to metric, is that people born in the U.S. really don't know it. Until the metric system came along, measurements were based on human beings. Even if imprecise, people have a general idea of how long a foot is, even in metric countries, because people have feet. People don't have meters on them.
But, regardless, computers are VERY good at doing math, and I remain puzzled why completely flexible input has never been implemented in AutoCAD or Bricsys. Adding the ability to convert at any data entry point should be standard. So, if units are set to be inches, and the user types 15mm, it should be able to detect that the user is entering English millimeters, and convert it to inches. And since the conversion factors are imprecise, it would be good to provide the phrase "Converting to Inches" on the command line after it is entered. Yes, there are ways to convert in the programs... but none of them as straight forward as just typing it in. And apparently the programming interface doesn't permit any custom programs to fix the limitation.
-Joe0 -
Couldn't you create a lisp-based custom command that does that? Call it MM, and have it accept a length in millimeters and convert that to inches and return that number. Then when you're prompted for a length, typeJoe Dunfee said:.... And apparently the programming interface doesn't permit any custom programs to fix the limitation.
'mm_and then type the number of millimeters.
As far as why the US doesn't use metric, I don't think it's because we can't learn it. There are countries with educational systems worse than ours, and they've learned the metric system. I suspect that it's because some people in our government secretly like the term "imperial."
0 -
The government in the U.S. has tried. They even stared to require all military and contractors to use metric on drawings. It is pushed very heavily in the federally controlled school systems (I know it is not supposed to be federal). But, rather, the citizens are rejecting it. There is definitely a political component to adopting metric, just as there was when the metric system was created for the purpose of rebelling against England and establishing France as a power. There is no escaping that part of any standard.
A current headache in the U.S., is the change in the length of the foot, to make it comply to a 4 digit conversion factor with the metric system. It was officially adopted in the 1960's. But, all the historical survey records were in the pre-redefined foot. And when stuff was computerized, they often didn't say which foot they were using. Yes, it is a small difference, but it does create serious property boundary problems when you are talking about long distances.
I like that AutoCAD (and BricsCAD) is unitless in how it stores data. So, at least you know that when you create something that is 1" long, it really is stored at precisely 1, and not a metric approximation of an inch which programs like Inventor does. Those kinds of approximations tend to create problems when it has to evaluate if things are parallel, etc.0 -
Regarding LISP. I've investigated this issue. And unless you also redefine the commands for line, circle, etc. you cannot apparently interrupt the user input to add the ability to recognize mm, ft, etc.
-Joe0 -
BricsCAD already does recognize common unit abbreviations in dynamic input for length in commands such as line, circle, etc. when PROPUNITS has bitcode 1 set (as per default = 47). With INSUNITS=1 [Inches] and LUNITS=2 [decimal], you can enter "25.4mm" or "10cm" or "0.5ft" to draw lines that have lengths of 1.0000 in, 3.9370 in, and 6.0000 in, respectively, as examples.0
-
Entering values with the
'unit seems to work in most cases.0 -
I am on V14 Pro. Though I do recall testing a more recent version at some point. But, I don't normally use dynamic input. So, that was where I failed.0
-
I tried using transparent command "Line 'mm" sometimes it works
(defun c:mm ()(/ (getreal) 25.4))
Line pickpoint pickdirection 'mm 600 pickdirection 'mm 850 Enter0 -
Good idea with the transparent command. You just have to enter the units first. Thanks, I will do this, since nearly all the time for my own needs, I need to convert mm to inches. So I just have the one version to do.
-Joe0
