Closed GoogleCodeExporter closed 8 years ago
I've noticed that if I set the view options preference to 'inch' and extrude a
face
10 units, it still extrudes 10mm.
If everything is set to mm, it seems to work o.k. but working in imperial units
is a
mess.
That said, when it's fixed, I'd like there to still be two options in the
software as
there is now. One to control the drawing units and the other to control the
output
units in the nc code. I occasionally would like to design in imperial units
but I
always want my output in metric because of how my machine is set up.
Original comment by shopinth...@gmail.com
on 25 Apr 2010 at 5:17
When the 'nc output units' is changed, it automatically changes the 'view
units' as
well. If the 'view units' are changed then the 'nc output units' remains the
same.
Do you want the system to prompt the user whenever one of these units settings
is
changed to ask if they want the other setting changed as well?
I think I've fixed the other problem. There were a few places in the code
(extrude
face, chamfer distance, blend radius, offset-shape tool, pad sketch) that were
using
the 'InputDouble' interface call to get a value. I have duplicated the
InputDouble
functionality so that we now also have an 'InputLength' function. This, in
turn,
calls the duplicated CLengthInput class. The CLengthInput class is based on the
CDoubleInput class except that the GetProperties() routine uses the
PropertyLength()
instead of PropertyDouble(). I believe this repairs the flaw whereby a value is
entered into the 'input options' window but is interpreted in mm rather than in
the
current view units.
Where a module was asking for an angle or a scale factor, it still uses the
InputDouble() call.
Original comment by David.Ni...@gmail.com
on 26 Apr 2010 at 12:35
I know I've only just asked the question but I decided to answer it myself. I
have
added code that helps keep the 'view' and 'NC' units in synch. Whenever one of
these
values is changed, it asks the operator if they wish the other to change as
well.
The operator may respond 'NO' if they wish. This way the values are kept in
synch
(normally) but may be different if required.
Is this enough for this fault?
Original comment by David.Ni...@gmail.com
on 26 Apr 2010 at 1:36
When using other CAD programs they have a 'Settings>Parameters>System' selection
window that will pop-up and allow you to set all system wide parameters. Units
is one
of them. It should be the most basic and easiest option to locate! I do not see
anything more important then the type of units one makes components out of.
Having it
easy to locate (and only ONE selection, not separated for drawing then g-code)
is
paramount to a good UI.
Now then, an issue will arise when you are importing multiple drawings. If one
is
metric and the other imperial what happens? If your 'system wide' setting is
imperial
and you import a metric part will it convert it? or just use the metric values
and
transform them into inches?
As for the notification of changing one setting and it asking, that is a good
start.
Original comment by leoafor...@gmail.com
on 26 Apr 2010 at 12:31
I know that, if a DXF file has a units definition included, the import will
convert
the scale correctly. Many DXF files that I've seen do not have a UNITS section
defined. In this case it assumes millimeters.
I think the option of modifying one units setting and having the program ask if
the
user wants to change the other is the only way we're going to make it both
convenient
and retain the ability to draw in inches and generate gcode in mm.
The only addition I can think of is to add the NC units as an 'option' beneath
the
'machining' options in addition to the 'property' of the Program object that it
is
today. This may make it more intuitive to find. It's hard to say if this is
right
or wrong. We could add it so that both options are available and that they both
change the same value internally.
Original comment by David.Ni...@gmail.com
on 26 Apr 2010 at 10:06
There was a problem with zigzag operation in inches. I have fixed this now.
I will look at extrude next.
Original comment by danhe...@gmail.com
on 27 Apr 2010 at 10:26
I thought I had fixed the 'extrude face' problem by changing the InputDouble()
to
InputLength() call. I hope you find that it's repaired already.
Original comment by David.Ni...@gmail.com
on 28 Apr 2010 at 3:34
Can we close this one off now? If there is still functionality missing then I
have
not understood it properly.
Original comment by David.Ni...@gmail.com
on 8 May 2010 at 11:10
Right now I see a lot of "if inches, then * units".
Wouldn't this be a lot less messy if One simply set units to 1 ?
Or is this another one of those weak type issues where 1 is int while 1.00001
is float and 2.54 is fine but 1 garbles everything ?
Original comment by tha_krea...@hotmail.com
on 18 Feb 2011 at 9:36
Great Program! But... I am importing a metric DXF (it was generated by
DoubleCad3D which is set to metric units and in the DXF file the entry
$DIMENSIONS 70 1 confirms that the file is metric) - i have imported these
files into other programs which have correctly interpreted the co-ordinates.
When i try to import them into HeeksCAD/CNC it multiplies the input values by
25.4 creating huge structures. This is despite the fact that i have 'mm' set as
Visual Options and G-Code options and i am using a metric DXF file. Any ideas?
Original comment by mikeb1...@gmail.com
on 9 May 2012 at 2:16
ok i fixed this. The DXF import was ignoring the $MEASUREMENT variable.
I was having the same problem with my customer's dxf files.
Original comment by danhe...@gmail.com
on 10 May 2012 at 2:03
I am having problems trying to get a DXF to import properly in heekscnc 0.27 I
have verified that $INSUNITS is 1 (inches) and $MEASUREMENT is 0 (English
units) using the website below. I am using AutoCAD to generate the DXF files,
do I need to add or change something else?
http://docs.autodesk.com/ACD/2013/ENU/index.html?url=files/GUID-A85E8E67-27CD-4C
59-BE61-4DC9FADBE74A.htm,topicNumber=d30e670187
Original comment by cheez...@gmail.com
on 4 Mar 2014 at 2:30
Original issue reported on code.google.com by
leoafor...@gmail.com
on 25 Apr 2010 at 2:30Attachments: