Re: odd problem...

[Jon Elson <jmelson-at-artsci.wustl.edu>]

Matt Shaver wrote:

> > What does NaN in the X, Y and Z axes display mean?  It kinda sounds like
> > when I was teased in third grade  "NaN, NaN, NaN!!!!"
>
> It means, "Not a Number". That is not good. We used to have this problem
> several years ago with communication between the real-time and non real-time
> processes. I'm glad you have a stepper system, on a servo machine one or more
> axes take off at warp speed toward the next galaxy!

But, if you feed large amplitude velocity commands to a servo amp, it will most
likely cause an overcurrent trip in a couple milliseconds.  (Mine sure will.)

> This is an important
> problem and it would be great if you could determine what G-codes caused it.
> Just a thought, you're not using the R format for G02 and G03 are you? You
> are using I J right? The reason I ask is that this problem (screaming
> runaway) was also caused by subtle errors in programming arc moves using R
> format. Thanks for reporting this!

I will note that I've been doing all my arcs with R, since there was that
extremely
fine limit on matching start and end radii.  I guess that limit has been
relieved,
but I'm still using R, which is a lot easier to calculate manually (although
I do nearly everything having to do with arcs by having programs write
the G code).  I haven't had any trouble at all in this.  In fact, except having
the recent quirk in MDI moves, EMC has been TOTALLY reliable in
program mode (oh yeah, there's also the thing where work offsets are
reset to G54 when a program ends).

Jon