Re: Bug report - NaN

[Ray Henry <rehenry-at-up.net>]

Jon et al 

I tried taking out the j and no difference. I could get a half circle still
with the -x distance but with x it caused the NaN again.  -j made no
difference.

I just couldn't get a whole circle.

Ray


At 05:16 PM 2/3/2000 -0500, you wrote:
<snip>
>
>EMC uses absolute values for IJK distances.  If the number is
>written as a positive value, that specifies an arc of 0-180 degrees.  A
>negative
>value specifies an arc of greater than 180 degrees.  So, the I-5 means the
arc
>is
>greater than 180 degrees, but the J is also specified with a positive
value, at
>
>least when the code checks to see if it is + or -, it will take the branch
for
>it being positive.  So, this sounds contradictory - I says more than 180,
>J says less.  Actually, since the start and end points are the same, the
>program must intend for this to be a full 360 circle, centered around 0,0.
>
>> My guess is that giving an I and J for an ending position that is the same
>> as the current position causes a divide by zero.  This happened in two
>> places in Ian's nc program.  I have no explanation why flashcut would allow
>> or use code like this but Ian is checking into it.
>
>The code looks valid, at least for certain RS-274 interpreters that handle
>arcs over 180 degrees, and use a negative sign in the IJK to select that.
>You might try it wothout the J spec, which is not needed.
>
>> I presume that what we need to do is trap this problem in the interpreter.
>> (verify does not find it)  I think that we also need to add some kind of
>> orderly shutdown of the motion stuff somewhere in EMC whenever a NaN
>> occurrs.
>
>An excellent idea.  I will try this code myself.  If it causes a runaway, it
>will almost certainly cause my servo amps to trip offline.  But, I DO
>have a hardware E-stop for just this circumstance.
>
>Jon
>
>
>
>