Re: Home switch oddities

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

On Mon, 11 Jun 2001, Joe and Jason wrote:
> >On Wed, 06 Jun 2001, Joe and Jason wrote:
> >>Hello List,
> >>    We have just installed BDI EMC. Everything went well. However we >are 
> >>still experiencing the same problem we had with other installs.
> >>    When we set the home switch polarities so that emc thinks its >setting 
> >>on the home switch when we home we don't get the green letters.>
> 
> >What color letters do you get when you first start up?
> 
> On startup of EMC we have Yellow letters.

Then your axis limit polarities are okay.

> >Does it come out of estop and show "ESTOP RESET" when you press f1 or 
> > >click
> >on estop off?
> >Does it show "ON" as the label in the estop button when you press f2 or
> >click on machine on?
> 
> Our machine has a slight creep when it is powered up, and when we bring
> EMC out of e-stop and machine on it then takes control of the machine
> and corrects the creep (holds it still).

Creep while open loop is to be expected and can be minimized by tweeking
bias or zero on the axis drive amps.  I've never tried it but there is a
bias variable in each axis definition that may allow you to set the stg
analog out to zero also.  You could check this with a fairly good digital
meter on the analog out pin and set bias to a value other than 0.000 if you
see a voltage on that pin.  Don't set the ini bias variable with motors
connected or the loop closed!

> >Does anything happen when you press home?
> 
> Depending on the home switch polarity, EMC will either immediately give
> a following error, OR it will start moving in the direction set by
> homing_polarity, and when it hits the switch it gives a following error.

Following Error!  I find that fascinating.  Do the axis location displays
move when the axis moves toward the home switch?  A following error would
seem to indicate that motion is being commanded that is not being fed back
correctly into the EMC.  

But the good news is that your home switch and the ini switch and
home direction polarities are working as planned.  If we assume that
following error computation is ignored during a home move then what is
happening makes sense.  If the ini polarity says that the axis is home then
it tries to switch that axis into homed condition which brings up following
error.  If the ini polarity says that the axis is not home then it moves
the axis until it finds the switch and then tries to switch that axis into
homed condition which also brings up following error. 

> >Do you have motors and encoders connected?
> 
> We tried it both ways. Shouldn't it work both ways? 

With any servo system, the position feedback comes from an encoder
connected to the moving axis/motor.  If you do not have proper feedback
when a motion is commanded, you will quickly get following error.  This
problem may be as simple as reversing the wiring from the encoder or
putting a (-) in front of the input scale value.  Or it could be an
incorrect value in that variable.  It should be the number of pulses from
your encoder times the multiplication factor used by the stg board.

I see that you have the stock value of 1.0000 in OUTPUT_SCALE on that Feb
ini.  The EMC will assume one pulse per inch for your system if you are
trying to use it with that value.  You might be able to correct this
problem by setting OUTPUT_SCALE to the correct number of pulses per inch
for your device.

>By toggling the home
> switch polarity we should be able to get green letters even with nothing
> hooked up. Am I correct in thinking this? It behaves this way when set
> to use the parallel port, or if the ini stg_base_address is set to
> something OTHER than the hardware stg base address (jumpers).

This is a round about answer 'cause I'm not sure that a simple yes or no
is complete enough for a following error problem.  Following error is a
difference between the actual location of an axis and where the EMC is
commanding that axis to be.

In the EMC with shipped ini values for FERROR and MIN_FERROR following
error is a ramp with FERROR sized values at max feedrate and MIN_FERROR
sized values at zero speed. 

At zero speed even steppers can trip up the following error equasion if
there are only a few steps per unit.  Steppermod feeds back one pulse for
each pulse sent.  Freqmod and smdromod use input/output scale to figure
feedback as a percent of command pulses.  

With servo systems, the controller commands a move and if it doesn't see
motion, it will increase the command until it reaches the maximum output
value.  IMHO if commanded position follows the command voltage curve here
there is almost no way you could not get following error if you do not have
feedback correctly connected and defined.

> >I went back and looked over the ini that you posted with the earlier
> >request in Feb.  You say that this is an stg2 board but you are using an
> >earlier version of the stg driver code.  If you look in
> >emc/plat/realtime/lib you will find all of the possibilities listed as
> >stg***.o.
> >
> >1 - My guess is that you need to use stg_v2_8axis_mod.o or stg2mod.o
> >in your ini but these are only guesses.
> >
> >2 - Why do you use 0x240 as the base address for the board?
> >
> >3 - There is a P = 0 in the third axis definition.  This would quickly
> >cause a following error fault if you have motors and encoders connected.
> >
> >4 - There are several differences between axes for switch and fault
> >polarity definitions that might cause problems with getting it out of 
> > >estop
> >and homed out if you don't really have switches connected that way.
> >Ray
> 
> 1. I looked for those stg***.o files you mentioned. They were in the 
> emc/plat/realtime/lib directory like you said, but when I try to use them in 
> the ini, it cant find them (it is looking in emc/plat/realtime/bin, not lib) 
> What steps do I have to do to be able to use these files.

These should run if called from the ini.  The 8 axis version,
stg_v2_8axis_mod.o didn't start up correctly for me but the 4 axis
version, stg2mod.o did. 

> 2. We used 240 because it is what the stg shipped with. We have tried lots 
> of other addresses as well. the /proc/ioports listing is very incomplete, 
> but as far as I can tell there is no conflict... any other way I can check 
> besides ioports?

You are way beyond me here.  I guess I'd check on the successful function
of your board at the 240 location by starting up tkemc with it and using
the script IO_Exercise.  Figure the location of some of the I/O pins and
set that script to view them.  Short a pin and see if the pin changes value
on the display.  The exercise part of the script won't work properly
because the EMC is controlling the board.

> 3. We only have two axes anyhow. Even taking the third axis out of the ini 
> completely doesnt fix it.
> 
> 4. Any differences in the Feb. ini for switch settings were for experimental 
> purposes. We tried lots of variations for the polarities, but even with NO 
> inputs connected one of them should have still homed. (Right?)

Okay.
 
> Am I explaining this clearly? Let me know.

Doing great.  I can understand your frustration with this.

Ray