Re: a new glitch




Fred Proctor wrote:

> EMC folks,
>
> Jon Elson wrote:
>
>  But, now I have a maxerror limit set
> > to .050" on the Z axis.  I checked, and the maximum cumulative
> > error on Z was .014", which would not have caused the broken
> > drill, as it still would have cleared by .086".  Fred mentioned some
> > changes to the synchronization of messages, so I wonder if there
> > might be a subtle condition under which the messages get out of
> > order, or are emitted from the trajectory planner before they should
> > be?
>
> Jon, can you tell me if this happened after you reduced the acceleration value
> (DEFAULT_ACCELERATION in the [TRAJ] section of the ini file)? Note that moves
> are blended together, with one move beginning when the previous begins
> decelerating to a stop. If you decrease the acceleration, the blending becomes
> more pronounced. Matt noticed this when doing drilling cycles, in which the
> retract Z move did not finish before the next X move began, and it gouged the
> hole.

Yes, this is with both DEFAULT_ACCELERATION and MAXIMUM_ACCELERATION
set to 2 I/Sec^2.  But, I doubt that this has anything to do with it (outside of
a bug in the code) because it appears to have started the X and Y axes
almost at the same instant that it began the retract.  I got the broken drill
out of the hole, and measured the hole.  It had been drilled to the full depth
specified in the program, and the broken drill appeared to be within .020"
at most, of the full hole depth.  So, it appeared that the drill had not been
withdrawn from the hole at all before the X and Y axes began to move.
I observed the Z axis retracting, so it WAS moving, in other words, the
retract Z command was not lost or skipped over.  I can expect the behavior
that the X and Y might start to move before the Z has completely settled,
that's why I allow a .1" clear space below the drill point, before commanding
movement in the XY plane.  Otherwise, I will note that the same program
ran faultlessly both before AND after the crash!  After completing those
particular parts, I have run several drilling programs with very similar drilling
strokes, and have had no repeats of this behavior.

So, let me reiterate that this was a one-time occurrence, and not just a
little bit of blending.  These holes were .675" deep (I think), and the XY
motion commenced when the tool was at least .65" from the end point of
the Z retract motion.  So, in other words, it was at the very BEGINNING
of the one-axis move, not near the end.

I also will mention that The last key I hit was the R key to start the program,
and I hadn't hit any keys like pause or feed override up to that point.

> Matt's fix for this was to put G4 P0.0 zero-time dwells after some moves, to
> force a stop. You can use G61/G64 for exact-stop or cutting (blended move)
> modes, respectively. I don't recall if G61 affects rapid moves; I'll have to
> check.

I have not used any G0 rapid moves, because I don't know what limits
machine speed under those circumstances.  I usually don't run my machine
over 45 IPM, even for rapid, due to the acceleration.  Now that I have
turned the acceleration down, I might start using it, but I just by habit
keep things slow.  I avoid some accidents that way.

> Try either of these and see if motion improves.

In general, the motion is just DANDY, and my programs leave enough
clearance in places where it might cause a problem, so that the blending
would not cause any trouble.

One other little thing I noticed, was that in Xemc, if you hop too fast
from one axis jog key to another, it loses the 'key-up' message, such
that hitting jog left, then quickly jumping to jog right (or even jog +Y,
say) causes it to keep moving as if jog left was still depressed.
It seems that it takes almost a second for this to clear, leaving a large
period where you can get off one key and onto another, and getting
the wrong jog action.  (I'm still happy to use xemc, because of all the
other pluses it provides!)

Thanks, Fred, for all the hard work!

Jon




Date Index | Thread Index | Back to archive index | Back to Mailing List Page

Problems or questions? Contact