Re: Runaway z axis with steppers

[Ray Henry <rehenry-at-up.net>]

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.