On Tue, Apr 07, 2009 at 10:29:51PM -0500, Jon Elson wrote:
> I can't answer this, but I think we need a lot more info on what the
> G-code for these holes looks like.
The gcode that causes these problems can be as simple as
G0 X??? Y???
G3 I1 F100
M2
i.e., a full circle of radius 1 with the center to the right of the
current location.
what is frustrating about this bug is that some circles are fine and
other circles are busted. It depends on the X and Y coordinates in some
non-obvious way.
the problem comes down to this: Two different calculations are made to
get the start and end angles of the circle. Mathematically, the angles
should each be precisely equal, and then the code in question determines
that exactly equal endpoints means the code intends a full circle. In
the computer's arithmetic, they end up being slightly different (e.g.,
a+b+c is not always equal to a+c+b in floating point*) and makes the
angle calculation come up as 10^-17 radians instead of 0 radians. This
makes emc treat the move as a very very tiny arc instead of a full
circle.
We've had problems like this before, but this specific one is new in 2.3
It is specific to the naive cam detector, which is enabled by the G64
P0.nnn code mentioned by the original poster.
Jeff
* A specific example of this phenomenon:
$ python
>>> a = 1.0
>>> b = 1e-100
>>> c = -1
>>> a + b + c
0.0
>>> a + c + b
1e-100
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
