Re: a new glitch

[Fred Proctor <proctor-at-cme.nist.gov>]

EMC folks,

Jon Elson wrote:

> I have been using the 17-Feb-1999 version of EMC through xemc for a
> few days.  It has been working well, but tonight I had a very strange
> experience.  I was running a program that had been run before, but I
> edited a few lines out of it to skip over drilling a hole that had a drill
> bit
> broken off in it (my fault).  Those cut lines are between N15 and N40.
> The program appears to be correct.  It drilled 2 holes correctly, then
> on the third, at line N120, it is supposed to retract in Z to make the tool
> clear the top of the work by .1" (Z=0 is set at the top surface of the
> work - strange practice, but that's how I often do it) before positioning
> in XY to the next hole.  Instead, it started the XY move while the Z
> axis was still about in the middle of the move.  This broke the drill bit
> off (this time, NOT my fault).
>
> Now, I used to have stuff like this happen when the Z axis got stuck,
> as with a chip in the ball nut.  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.

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.

Try either of these and see if motion improves.

--Fred