Re: EMC motion interruption?

Thanks again for the help. I changed to nonrealtime on the task
controller and adjusted the cycle times and the interrupted motion is
not apparent any more. The reason for the strange cycle times I had
was because 'out of the box' the only EMC I could get to run was SIM.
So when I started modifying the ini file for my machine, I started by
modifying the SIM ini. Those are the cycle times in the SIM ini.
Thanks to you guys, my ignorance is no longer bliss....

Tom

--- In CAD_CAM_EDM_DRO@y..., Ray <rehenry@u...> wrote:
>
> >    From: "confusered" <confusered@y...>
> <s>
> > The interrupted steps can be heard as well as seen during very
slow
> > feeds.  For example, if Z is being driven at f0.5 you can see the
> > motor stop for about one pulse every so many pulses.  At higher
feeds
> > it is hard to see but I can hear a definite "beat".  The beat rate
> > increases with feed rate, almost like every so many pulses it
stops
> > for about a pulse length of time.
>
> 1 - You might try running the task controller in nonrealtime. Most
> ordinary users do.
>
> 2 - You have set task cycle time to only figure out where it needs
to be
> every tenth of a second. Default here is a hundreth of a second.
> (Cycle time can be confusing. There are many of them. There are
also
> some interactions between them when you get into.)
>
> 3 - I can't see a reason for some of the cycle times that you have
in the
> traj and axis sections. In [TRAJ] you show 0.06 the default is
0.01. In
> [AXIS#] you set 0.03 while the default is 0.001. My SWAG is that
your
> settings here create a HUGE bin into which the trajectory controller
dumps
> a whole bunch of pulses then steppermod reads them off as quick as
it can
> and waits for the next bin to arrive.
>
> I believe that I'd go back to emc.ini as it is stock in the release
that
> you have and then change just the minimum number of variables to
give your
> machine the gross personality that you want. Setup things like
tkemc,
> parport location, minimilltask, steppermod, input scale on each axis
and
> minimillio.
>
> > Also a possible SAFETY ISSUE: If you jog the X from the keyboard
and
> > jog Y before letting up on the X key, X will keep going after all
> > keys are released.
>
> Yep! You have discovered the real problems with using ordinary
keyboard
> input for machine control. Every key press code has an associated
key
> release code but sequential presses of stuff that isn't <shift>
<control>
> <alt> followed by a common key are treated by some keyboard
interpreters
> as an error and ignored. A second press and release of the key that
> initiated the offending condition should cause the gui to issue the
abort
> command. It is more than a little distressing the first time this
happens
> while runnning a real machine.
>
> HTH
>
> RayH