Re: Various bugs in March 15 EMC release

[Clint Bach <clintbach-at-earthlink.net>]

Fred,

I don't remember exactly which version didn't have the losing steps
problem but I think it was Feb. 25.  I had a fatal hard drive crash with
the hard drive running 2.0.36. It is permanently dead with all its
data...  Anyway, my stepper drivers don't change direction if the
direction and clock signal arrive at the same time. This happens only in
one direction. I thought a slight delay was added between the direction
step and the first clock pulse when the direction was changed to give
the direction pulse time to settle down.

I'm using Slo-Syn chopper drivers and steppermod and 2.2.13. Freqmod
gets following error messages and stops at any jog speed over .6. I
believe the freqmod problem can be fixed with the ini file but I haven't
been successful yet.
Fred Proctor wrote:
> 
> EMC folks,
> 
> Clint Bach wrote:
> 
> >
> This is a real live bug which was eradicated in the 2.0.36 version but
> is still in the 2.2.13 version. The EMC adds an extra step in the
> direction it was going before reversing direction.
> <
> 
> Is this for freqmod.o or steppermod.o? Which EMC release were you
> running on 2.0.36 that worked? This bug doesn't ring a bell with me, so
> maybe it was fixed as a side effect of something else and then got
> bugged again.
> 
> And Tim Goldstein wrote:
> 
> >
> I just tried actually homing with the Mar 15 build on RedHat 5.2 and I
> am having a problem. once I contact the home switch the axis is
> continuing to travel about .1 " then it reverses direction and backs up
> a few thousands then it starts back in the original direction of the
> homing at a rate of a few steps per second and keeps going for 5 or so
> seconds.
> 
> This is unlike homing has been working. Previously the direction would
> reverse as soon as the homing switch was contacted and then it would
> come at the switch again very slowly and stop the instant the contact
> closed. No extra movement past the switch closing at all.
> <
> 
> The way homing works is that motion proceeds at the [AXIS_#] HOMING_VEL
> speed in the direction specified by [AXIS_#] HOMING_POLARITY until the
> home switch trips. The polarity of the home switch is set by [AXIS_#]
> HOME_SWITCH_POLARITY. Then, the axis position at the trip point is saved
> and motion is aborted. Once the move stops, a move back to the saved
> trip point plus any offset in [AXIS_#] HOME_OFFSET is done, and the axis
> position is set to the value specified by [AXIS_#] HOME.
> 
> With HOME_OFFSET and HOME set to 0, the homing sequence would look like
> this:
> 
> 1. slow jog toward home switch.
> 2. switch trips.
> 3. jog decelerates and move terminates shortly after home switch.
> 4. jog back to switch trip position.
> 5. position set to 0, and digits turn green.
> 
> With HOME_OFFSET set to -0.1 (sign depends on value of HOMING_POLARITY),
> and HOME set to 3.0, the homing sequence would look like this:
> 
> 1. slow jog toward home switch.
> 2. switch trips.
> 3. jog decelerates and move terminates shortly after home switch.
> 4. jog back to point 0.1 units past switch trip position (to get off
> switch if you need to)
> 5. position set to 3.0, and digits turn green (lets you specify 3.0 as
> home for this axis).
> 
> This works on my servo system, but I haven't tried it on a stepper
> system with switches. It sounds like it's not working, but it's hard for
> me to tell.
> 
> Can stepper users try setting HOME_OFFSET to some non-zero value and see
> if the behavior agrees with the writeup above? for both freqmod and
> steppermod? Note that the motion control code for freqmod is
> emc/src/emcmot/emcmot.c, and the code for steppermod is
> emc/src/emcmot/emcstepmot.c, for the 15-Mar-2000 release. In prior
> releases, the code for freqmod is emc/src/emcmot/emcfreqmot.c, and the
> code for steppermod is emc/src/emcmot/emcmot.c. We did this to promote
> the frequency stepping code to emcmot.c, hoping to give up on the
> binning algorithm in steppermod eventually.
> 
> --Fred