Arc Tolerance
21 Dec 2014 23:57 #54186
by ArcEye
Arc Tolerance was created by ArcEye
This thread was inspired by the experiences of ctrl-frq in this thread
www.linuxcnc.org/index.php/english/forum...ounce?start=10#54172
trying to get the arcs generated by his CAM program accepted by Linuxcnc.
Anyone who has done any amount of work involving arcs will be familiar with the error message as per below
In this particular case the variation is pretty small, but enough to prevent usage of the code.
This started me looking at the code the interpreter uses to test if the divergence is within tolerances.
src/emc/rs274ngc/interp_internal.hh has the definition for tolerances
Immediate thought, why on earth is the tolerance for mm so much tighter than imperial?
Probable answer, programmer uses imperial and is not really interested in metric.
No wonder I have had so much difficulty in the past with some arcs ( especially on the lathe ), when it is not practical to use a simple R parameter
Next thought, why are the tolerances so tight overall?
5 thousandths of a mm = 0.000196850394 inch or 5 microns !
I can't machine to that spec, so why would I want calculations to be done to it?
Even the imperial tolerance is pretty tight at 12.7 microns.
So what if the tolerance could be varied, how much real effect would it have on quality and would it allow CAM code which currently fails to run.
Below same code run through a build with imperial tolerance set to 0.002"
Runs quite happily and given the arcs in question are used in script on a sign, is there actually any point in having the tolerances so tight that
3rd party code is not accepted?
Perhaps an .ini file setting for tolerances would be the way forward, not to mention a fix for the inch / metric conversion of 0.1!
This is just open for discussion, I have changed the development RIP I am using at present, but not an option for most users.
regards
www.linuxcnc.org/index.php/english/forum...ounce?start=10#54172
trying to get the arcs generated by his CAM program accepted by Linuxcnc.
Anyone who has done any amount of work involving arcs will be familiar with the error message as per below
In this particular case the variation is pretty small, but enough to prevent usage of the code.
This started me looking at the code the interpreter uses to test if the divergence is within tolerances.
src/emc/rs274ngc/interp_internal.hh has the definition for tolerances
#define TOLERANCE_INCH 0.0005
#define TOLERANCE_MM 0.005Immediate thought, why on earth is the tolerance for mm so much tighter than imperial?
Probable answer, programmer uses imperial and is not really interested in metric.
No wonder I have had so much difficulty in the past with some arcs ( especially on the lathe ), when it is not practical to use a simple R parameter
Next thought, why are the tolerances so tight overall?
5 thousandths of a mm = 0.000196850394 inch or 5 microns !
I can't machine to that spec, so why would I want calculations to be done to it?
Even the imperial tolerance is pretty tight at 12.7 microns.
So what if the tolerance could be varied, how much real effect would it have on quality and would it allow CAM code which currently fails to run.
Below same code run through a build with imperial tolerance set to 0.002"
Runs quite happily and given the arcs in question are used in script on a sign, is there actually any point in having the tolerances so tight that
3rd party code is not accepted?
Perhaps an .ini file setting for tolerances would be the way forward, not to mention a fix for the inch / metric conversion of 0.1!
This is just open for discussion, I have changed the development RIP I am using at present, but not an option for most users.
regards
Please Log in or Create an account to join the conversation.
22 Dec 2014 20:15 #54210
by ArcEye
Excellent, you were obviously hitting the IRC last night!
That was my project for this afternoon.
I'm sure it is, it is that sections code that is changed and the interpreter behavior that is modified.
There do need to be some basic top and bottom figures and sanity checks that the .ini file figure does no go outside them
As the hard coded #define needs changing anyway, I will look at adding further defined values.
Then the value can be a default or the ini file value, if that is within sane defined parameters.
Quick work JT and Dewey
regards
Replied by ArcEye on topic Arc Tolerance
And like magic Dewey has come up with a patch for 2.7 that adds arc tolerance to the ini file.
Excellent, you were obviously hitting the IRC last night!
That was my project for this afternoon.
I'm not sure if [RS274NGC] is the right section.
I'm sure it is, it is that sections code that is changed and the interpreter behavior that is modified.
It does seem you could do some stupid things by
making the tolerances too big -- maybe there should
be a sanity check on the values from the ini file too.
There do need to be some basic top and bottom figures and sanity checks that the .ini file figure does no go outside them
As the hard coded #define needs changing anyway, I will look at adding further defined values.
Then the value can be a default or the ini file value, if that is within sane defined parameters.
Quick work JT and Dewey
regards
Please Log in or Create an account to join the conversation.
23 Dec 2014 01:15 - 23 Dec 2014 01:25 #54230
by ArcEye
Replied by ArcEye on topic Arc Tolerance
I didn't end up with much time for testing.
The patch has an error which probably does not need explanation
It did not patch successfully on fresh pull of the master, not quite sure which version Dewey patched against, some of the line numbers do not match.
EDIT: Now read your post properly and see he has patched 2.7, not 2.8 (ie master).
All starting to get a bit complicated with a 2.7 alpha and a 2.8 master existing at the same time
I manually inserted the lines and started to hit strange problems, but ran out of time to debug it.
Will look at it again tomorrow.
regards
The patch has an error which probably does not need explanation
--- a/src/emc/rs274ngc/rs274ngc_pre.cc
+++ b/src/emc/rs274ngc/rs274ngc_pre.cc
@@ -966,6 +966,11 @@ int Interp::init()
n++;
}
+ _setup.tolerance_inch = TOLERANCE_INCH;
+ _setup.tolerance_mm = TOLERANCE_INCH;
+ inifile.Find(&_setup.tolerance_inch, "TOLERANCE_INCH", "RS274NGC");
+ inifile.Find(&_setup.tolerance_mm, "TOLERANCE_MM", "RS274NGC");
+
// close it
inifile.Close();
}
--
1.7.10.4It did not patch successfully on fresh pull of the master, not quite sure which version Dewey patched against, some of the line numbers do not match.
EDIT: Now read your post properly and see he has patched 2.7, not 2.8 (ie master).
All starting to get a bit complicated with a 2.7 alpha and a 2.8 master existing at the same time
I manually inserted the lines and started to hit strange problems, but ran out of time to debug it.
Will look at it again tomorrow.
regards
Please Log in or Create an account to join the conversation.
Time to create page: 0.114 seconds