RE: Runaway z axis with steppers

[wb9mjn <wb9mjn-at-wb9mjn-11.ampr.org>]

   Hi Ray,

      I see the same thing on my machine as observation 1 below, but not 2. 
Estop will stop all motion and the position stays at the commanded 
position, no matter if there uncommanded motion, or not. Switching to other 
modes will not stop uncommanded motion, however. Using manual to move the 
axis, then when it begins an uncommanded movement switching to MDI or AUTO, 
does not stop the movement.

      The uncontrolled movement is random in start direction, but then 
moves at random speeds in whatever the start direction was. The 
uncontrolled movement is not correlated to the previous commanded 
direction. It will go negative, positive, or stop with no apparent 
relationship to the previously commanded direction. The unctrolled movement 
only begins at the end of a commanded movement. These observations are with 
the manual mode set to "continuous".

       This problem was not observed with the previous BDI 2.04. In that 
setup I used steppermod, instead of freqmod.

       I cannot comment on 3, as I do not have homeing switches on my 
machine.

      73, Don....


-----Original Message-----
From:	Ray Henry [SMTP:rehenry-at-up.net]
Sent:	Sunday, September 08, 2002 9:48 AM
To:	Multiple recipients of list
Subject:	Re: Runaway z axis with steppers



Interesting, Paul.

I'll try it with positive numbers in a bit.

The number 10 strikes a cord with me here because I did try 8 and it
seemed to work fine.  'Course the whole thing acts so different when you
get down to these small numbers that it is a bit hard to hear and see
what's happening.

Do you think that it is possible that there is some kind of discontinuity
in the collection of formulas and source files used here for position,
deadband, splines and such that crops up at certain frequencies of
repitition.

I seem to be able to kill it out if I set deadband big enough but
sometimes it has to be larger than one whole step in order to do that.
My intuition has always told me that a half step should be enough to
allow the math between commanded and actual to settle out.  It does not
seem that this is true.

A couple of interesting observations here are that several other
unexpected things seem to be associated with this.

1 - While the axis is oscillating and moving on it's own, the displayed
position does not update.

2 - When an axis is oscillating like this and you press estop, the
machine will stop but the axis display will run away.

3 - Pressing home after a runaway and a restart is not effective.  It
will turn the position label yellow which says that the underlying joint
is not homed but it does not initiate at home sequence nor find the home
switch closed and zero out the axis.

Ray


On Saturday 07 September 2002 04:10 pm, you wrote:
> Hi Ray
> The first thing to spring to mind is INPUT_SCALE and OUTPUT_SCALE are
> both negative numbers. Running the ini file with the current CVS
> sources on an rtai build, I too get the odd behaviour that you report.
> I have observed similar run aways when messing around with four axis
> configurations - Often with much more aggressive results.
>
> After changing the INPUT_SCALE and OUTPUT_SCALE parameters (try 5 !),
> I can get a repeatable result after every move. Increasing CYCLE_TIME
> to 0.0015 improves the situation somewhat....
> Suggestion - Increase CYCLE_TIME to 0.0015 - 0.0025 as SCALE approaches
> 10. (I wonder if this is the answer for the fourth axis ??)
>
> Regards, Paul.
>
> On Saturday 07 Sep 2002 5:26 pm, Ray Henry wrote:
> > Here is what I did to exhibit the problem.  
> >
> > Startup using timsfreq.ini.  (attached)
> > Start the machine and home out.
> > Start scripts->IO_Exercise to view parport 0x378. (default)
> > Issue a couple of quick jogs in Z
> >
> > Once the problem shows up with the IO_Exercise display and I press
> > estop, the step pin seems to latch but the displayed position runs
> > wild.

mini-metric.ini