[Emc-users] following error only while homing

[t***@bgp.nu]

Why would I get a following error only while homing (latest Linuxcnc 2.7.9)? I recently added home switches to my machine. My machine has encoders on the steppers on each of the 3 axes so I want to use the index pulse for home. I set up the homing sequence each axis and when I do "Home All" I get a following error on my Z axis (first one to home). I played with all the settings and can’t get it to complete unless I set ferror and min_ferror very high Also, once there is a following error I can only clear it by exiting Linuxcnc and restarting it. If I just turn it back on, it immediately faults again with the same following error. If I don’t home, after restarting Linuxcnc, I can run the Z axis (and X and Y) all day at any speed without a following error.

I have tried setting the ferror and min_ferror settings to various reasonable values but it didn’t work. Before adding the switches I had error=0.001 and min_ferror=0.0005 and never had a following error appear. I set ferror to 2 and min_ferror to 1 (I think those were the values) and it worked but then got the following error on the Y axis (the second axis homed). The values for ferror and min_ferror that “worked” seem completely unreasonable given I am not even moving anywhere near my max velocity during homing.

I have tried changing the sign on the HOME_LATCH_VEL to make it search for index in the other direction but the same thing happens. Below are my (current) machine hal and ini.

-Tom


———————————— ini ———————————
# Generated by PNCconf at Thu Apr 8 11:40:39 2010

[EMC]
MACHINE = EMCO
DEBUG = 0

[DISPLAY]
DISPLAY = axis
#EMBED_TAB_NAME = Camera
#EMBED_TAB_COMMAND = camview-emc -w {XID}
EDITOR = gedit
PYVCP = custom_pyvcp.xml
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
MAX_FEED_OVERRIDE = 2.0
MAX_SPINDLE_OVERRIDE = 1.5
MIN_SPINDLE_OVERRIDE = 0.500000
INTRO_GRAPHIC = linuxcnc.gif
INTRO_TIME = 2
PROGRAM_PREFIX = /home/tom/linuxcnc/nc_files
INCREMENTS = .1in .05in .01in .005in .001in .0005in .0001in
POSITION_OFFSET = RELATIVE
POSITION_FEEDBACK = ACTUAL
DEFAULT_LINEAR_VELOCITY = 0.250000
MAX_LINEAR_VELOCITY = 1.000000
MIN_LINEAR_VELOCITY = 0.010000
DEFAULT_ANGULAR_VELOCITY = 0.250000
MAX_ANGULAR_VELOCITY = 1.000000
MIN_ANGULAR_VELOCITY = 0.010000
GEOMETRY = xyz
#GEOMETRY = xyza

[FILTER]
PROGRAM_EXTENSION = .png,.gif,.jpg Greyscale Depth Image
PROGRAM_EXTENSION = .py Python Script
png = image-to-gcode
gif = image-to-gcode
jpg = image-to-gcode
py = python

[TASK]
TASK = milltask
CYCLE_TIME = 0.010

[RS274NGC]
PARAMETER_FILE = emc.var

[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
#BASE_PERIOD = 50000
SERVO_PERIOD = 1000000

# [HOSTMOT2]
# This is for info only - config line is in the .hal file
# DRIVER0=hm2_7i43
# BOARD0=7i43
# CONFIG0="firmware=hm2/7i43/SVST2_4_7I47B.BIT num_encoders=3 num_pwmgens=0 num_stepgens=4"

[HAL]
HALUI = halui
HALFILE = EMCO.hal
HALFILE = custom.hal
POSTGUI_HALFILE = custom_postgui.hal

[HALUI]
MDI_COMMAND = G53 G0 X0 Y0 Z0

[TRAJ]
AXES = 3
COORDINATES = X Y Z
LINEAR_UNITS = inch
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_VELOCITY = 0.5
MAX_LINEAR_VELOCITY = 2
#Joypad Test stuff below:
DEFAULT_ANGULAR_VELOCITY = 0.25
MAX_ANGULAR_VELOCITY = 1.0

#ARC_BLEND_ENABLE = 1
#ARC_BLEND_RAMP_FREQ = 1000


[EMCIO]
EMCIO = io
CYCLE_TIME = 0.100
TOOL_TABLE = tool.tbl

#********************
# Axis X
#********************
[AXIS_0]
TYPE = LINEAR
# HOME = 0.0 -- see below
FERROR = 0.005
MIN_FERROR = 0.001
MAX_VELOCITY = 2.2
MAX_ACCELERATION = 20
# these are in nanoseconds
DIRSETUP = 200
DIRHOLD = 200
STEPLEN = 2000
STEPSPACE = 1200
STEPGEN_MAXACCEL = 40
STEPGEN_MAXVEL = 2.75
#BACKLASH = 0.0005
INPUT_SCALE = -208076.8
SCALE = -50800
MIN_LIMIT = -0.001
MAX_LIMIT = 7.8
# homing
# move here after home switch found:
HOME = 4.0
# home switch is located here:
HOME_OFFSET = 7.8
# initial search velocity in/sec
HOME_SEARCH_VEL = 0.75
# 2nd pass search velocity
HOME_LATCH_VEL = 0.1
# speed to HOME
HOME_FINAL_VEL = 0.5
# yes use index
HOME_USE_INDEX = YES
HOME_IGNORE_LIMITS = NO
HOME_IS_SHARED = NO
# do this after Z and Y is homed
HOME_SEQUENCE = 2
# should unhome if estop or power off? no
VOLATILE_HOME = 0

#********************
# Axis Y
#********************
[AXIS_1]
TYPE = LINEAR
# HOME = 0.0 -- see below
FERROR = 0.005
MIN_FERROR = 0.001
MAX_VELOCITY = 2.2
MAX_ACCELERATION = 20.0
# these are in nanoseconds
DIRSETUP = 200
DIRHOLD = 200
STEPLEN = 2000
STEPSPACE = 1200
STEPGEN_MAXACCEL = 40
STEPGEN_MAXVEL = 2.75
BACKLASH = 0.0005
SCALE = 50800
MIN_LIMIT = -0.001
MAX_LIMIT = 3.8
INPUT_SCALE = 208076.8
# homing
# move here after home switch found:
HOME = 2.0
# home switch is located here:
HOME_OFFSET = 0
# initial search velocity in/sec
HOME_SEARCH_VEL = -0.4
# 2nd pass search velocity
HOME_LATCH_VEL = -0.1
# speed to HOME
HOME_FINAL_VEL = 0.5
# yes use index
HOME_USE_INDEX = YES
HOME_IGNORE_LIMITS = NO
HOME_IS_SHARED = NO
# do this after Z is homed
HOME_SEQUENCE = 1
# should unhome if estop or power off? no
VOLATILE_HOME = 0

#********************
# Axis Z
#********************
[AXIS_2]
TYPE = LINEAR
# HOME = 0.0 -- see below
FERROR = 0.005
MIN_FERROR = 0.001
MAX_VELOCITY = 2.2
MAX_ACCELERATION = 20.0
# these are in nanoseconds
DIRSETUP = 200
DIRHOLD = 200
STEPLEN = 2000
STEPSPACE = 1200
STEPGEN_MAXACCEL = 40
STEPGEN_MAXVEL = 2.75
#BACKLASH = 0.0005
SCALE = -50800
MIN_LIMIT = -7.8
MAX_LIMIT = 0.001
INPUT_SCALE = -208076.8
# homing
# move here after home switch found:
HOME = 0.0
# home switch is located here:
HOME_OFFSET = 0
# initial search velocity in/sec
HOME_SEARCH_VEL = 0.4
# 2nd pass search velocity
HOME_LATCH_VEL = -0.1
# speed to HOME
HOME_FINAL_VEL = 0.5
# yes use index
HOME_USE_INDEX = YES
HOME_IGNORE_LIMITS = NO
HOME_IS_SHARED = NO
# do this before X/Y are homed
HOME_SEQUENCE = 0
# should unhome if estop or power off? no
VOLATILE_HOME = 0

#********************
# Spindle
#********************
[SPINDLE_9]
# these are in nanoseconds
DIRSETUP = 0
DIRHOLD = 0
STEPLEN = 20000
STEPSPACE = 20000
SCALE = 8.7
———————————— end ini ———————————





———————————— hal ———————————

# Generated by PNCconf at Thu Apr 8 11:40:39 2010

loadrt trivkins
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
loadrt hostmot2
loadrt hm2_7i43 config="firmware=hm2/7i43/SVST2_4_7I47B.BIT num_encoders=3 num_pwmgens=0 num_stepgens=4"

addf hm2_7i43.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf hm2_7i43.0.write servo-thread

# external output signals
#
# --- SPINDLE-BRAKE ---
setp hm2_7i43.0.gpio.022.is_output true
setp hm2_7i43.0.gpio.022.invert_output true
net spindle-brake => hm2_7i43.0.gpio.022.out
# --- COOLANT-FLOOD ---
# setp hm2_7i43.0.gpio.025.is_output true
# setp hm2_7i43.0.gpio.025.is_opendrain true
# setp hm2_7i43.0.gpio.025.invert_output true
# net coolant-flood => hm2_7i43.0.gpio.025.out
# --- COOLANT-MIST ---
setp hm2_7i43.0.gpio.025.is_output true
setp hm2_7i43.0.gpio.025.is_opendrain true
setp hm2_7i43.0.gpio.025.invert_output true
net coolant-mist => hm2_7i43.0.gpio.025.out
# --- Work Light (Or Air Vice)Control ---
setp hm2_7i43.0.gpio.027.is_output true
setp hm2_7i43.0.gpio.027.is_opendrain true
setp hm2_7i43.0.gpio.027.invert_output true
net worklight-ctl <= hm2_7i43.0.gpio.027.out
# --- E-Stop Indication ---
setp hm2_7i43.0.gpio.029.is_output false
net epo-signal <= hm2_7i43.0.gpio.029.in_not


#*******************
# AXIS X
#*******************
# axis enable chain
newsig emcmot.00.enable bit
sets emcmot.00.enable FALSE

net emcmot.00.enable <= axis.0.amp-enable-out
net emcmot.00.enable => hm2_7i43.0.stepgen.00.enable

# position command and feedback
net emcmot.00.pos-cmd <= axis.0.motor-pos-cmd
net emcmot.00.pos-cmd => hm2_7i43.0.stepgen.00.position-cmd

# Step Gen signals/setup
setp hm2_7i43.0.stepgen.00.dirsetup [AXIS_0]DIRSETUP
setp hm2_7i43.0.stepgen.00.dirhold [AXIS_0]DIRHOLD
setp hm2_7i43.0.stepgen.00.steplen [AXIS_0]STEPLEN
setp hm2_7i43.0.stepgen.00.stepspace [AXIS_0]STEPSPACE
setp hm2_7i43.0.stepgen.00.position-scale [AXIS_0]SCALE
setp hm2_7i43.0.stepgen.00.maxaccel [AXIS_0]STEPGEN_MAXACCEL
setp hm2_7i43.0.stepgen.00.maxvel [AXIS_0]STEPGEN_MAXVEL
setp hm2_7i43.0.stepgen.00.step_type 0
setp hm2_7i43.0.stepgen.00.control-type 0

# ---Encoder feedback signals/setup---
setp hm2_7i43.0.encoder.00.counter-mode 0
setp hm2_7i43.0.encoder.00.filter 1
setp hm2_7i43.0.encoder.00.index-invert 0
setp hm2_7i43.0.encoder.00.index-mask 0
setp hm2_7i43.0.encoder.00.index-mask-invert 0
setp hm2_7i43.0.encoder.00.scale [AXIS_0]INPUT_SCALE
net xindex-enable hm2_7i43.0.encoder.00.index-enable <=> axis.0.index-enable
#Line below causes AXIS to display the ENCODER position in the DRO (and Preview)
net xpos-fb => axis.0.motor-pos-fb <= hm2_7i43.0.encoder.00.position
#net xpos-fb => axis.0.motor-pos-fb <= hm2_7i43.0.stepgen.00.position-fb

# ---setup home / limit switch signals---
net x-home-sw => axis.0.home-sw-in
net x-neg-limit => axis.0.neg-lim-sw-in
net x-pos-limit => axis.0.pos-lim-sw-in

#*******************
# AXIS Y
#*******************
# axis enable chain
newsig emcmot.01.enable bit
sets emcmot.01.enable FALSE

net emcmot.01.enable <= axis.1.amp-enable-out
net emcmot.01.enable => hm2_7i43.0.stepgen.01.enable

# position command and feedback
net emcmot.01.pos-cmd <= axis.1.motor-pos-cmd
net emcmot.01.pos-cmd => hm2_7i43.0.stepgen.01.position-cmd

# Step Gen signals/setup
setp hm2_7i43.0.stepgen.01.dirsetup [AXIS_1]DIRSETUP
setp hm2_7i43.0.stepgen.01.dirhold [AXIS_1]DIRHOLD
setp hm2_7i43.0.stepgen.01.steplen [AXIS_1]STEPLEN
setp hm2_7i43.0.stepgen.01.stepspace [AXIS_1]STEPSPACE
setp hm2_7i43.0.stepgen.01.position-scale [AXIS_1]SCALE
setp hm2_7i43.0.stepgen.01.maxaccel [AXIS_0]STEPGEN_MAXACCEL
setp hm2_7i43.0.stepgen.01.maxvel [AXIS_0]STEPGEN_MAXVEL
setp hm2_7i43.0.stepgen.01.step_type 0

# ---Encoder feedback signals/setup---
setp hm2_7i43.0.encoder.01.counter-mode 0
setp hm2_7i43.0.encoder.01.filter 1
setp hm2_7i43.0.encoder.01.index-invert 0
setp hm2_7i43.0.encoder.01.index-mask 0
setp hm2_7i43.0.encoder.01.index-mask-invert 0
setp hm2_7i43.0.encoder.01.scale [AXIS_1]INPUT_SCALE
net yindex-enable hm2_7i43.0.encoder.01.index-enable <=> axis.1.index-enable
#Line below causes AXIS to disply the ENCODER position in the DRO (and Preview)
net ypos-fb => axis.1.motor-pos-fb <= hm2_7i43.0.encoder.01.position

# ---setup home / limit switch signals---
net y-home-sw => axis.1.home-sw-in
net y-neg-limit => axis.1.neg-lim-sw-in
net y-pos-limit => axis.1.pos-lim-sw-in

#*******************
# AXIS Z
#*******************
# axis enable chain
newsig emcmot.02.enable bit
sets emcmot.02.enable FALSE

net emcmot.02.enable <= axis.2.amp-enable-out
net emcmot.02.enable => hm2_7i43.0.stepgen.02.enable

# position command and feedback
net emcmot.02.pos-cmd <= axis.2.motor-pos-cmd
net emcmot.02.pos-cmd => hm2_7i43.0.stepgen.02.position-cmd

# Step Gen signals/setup
setp hm2_7i43.0.stepgen.02.dirsetup [AXIS_2]DIRSETUP
setp hm2_7i43.0.stepgen.02.dirhold [AXIS_2]DIRHOLD
setp hm2_7i43.0.stepgen.02.steplen [AXIS_2]STEPLEN
setp hm2_7i43.0.stepgen.02.stepspace [AXIS_2]STEPSPACE
setp hm2_7i43.0.stepgen.02.position-scale [AXIS_2]SCALE
setp hm2_7i43.0.stepgen.02.maxaccel [AXIS_0]STEPGEN_MAXACCEL
setp hm2_7i43.0.stepgen.02.maxvel [AXIS_0]STEPGEN_MAXVEL
setp hm2_7i43.0.stepgen.02.step_type 0

# ---Encoder feedback signals/setup---
setp hm2_7i43.0.encoder.02.counter-mode 0
setp hm2_7i43.0.encoder.02.filter 1
setp hm2_7i43.0.encoder.02.index-invert 0
setp hm2_7i43.0.encoder.02.index-mask 0
setp hm2_7i43.0.encoder.02.index-mask-invert 0
setp hm2_7i43.0.encoder.02.scale [AXIS_2]INPUT_SCALE
net zindex-enable hm2_7i43.0.encoder.02.index-enable <=> axis.2.index-enable
#Line below causes AXIS to disply the ENCODER position in the DRO (and Preview)
net zpos-fb => axis.2.motor-pos-fb <= hm2_7i43.0.encoder.02.position

# ---setup home / limit switch signals---
net z-home-sw => axis.2.home-sw-in
net z-neg-limit => axis.2.neg-lim-sw-in
net z-pos-limit => axis.2.pos-lim-sw-in

#*******************
# SPINDLE S
#*******************

# Step Gen signals/setup
setp hm2_7i43.0.stepgen.03.dirsetup [SPINDLE_9]DIRSETUP
setp hm2_7i43.0.stepgen.03.dirhold [SPINDLE_9]DIRHOLD
setp hm2_7i43.0.stepgen.03.steplen [SPINDLE_9]STEPLEN
setp hm2_7i43.0.stepgen.03.stepspace [SPINDLE_9]STEPSPACE
setp hm2_7i43.0.stepgen.03.position-scale [SPINDLE_9]SCALE
setp hm2_7i43.0.stepgen.03.maxaccel 0
setp hm2_7i43.0.stepgen.03.maxvel 0
setp hm2_7i43.0.stepgen.03.step_type 0
setp hm2_7i43.0.stepgen.03.control-type 1

net spindle-enable => hm2_7i43.0.stepgen.03.enable
net spindle-vel-cmd => hm2_7i43.0.stepgen.03.velocity-cmd


# ---setup spindle control signals---
net spindle-vel-cmd <= motion.spindle-speed-out
net spindle-enable <= motion.spindle-on
net spindle-ccw <= motion.spindle-reverse
net spindle-brake <= motion.spindle-brake


#******************************
# connect miscellaneous signals
#******************************

# ---home signals ---
setp hm2_7i43.0.gpio.033.is_output false
net x-home-sw <= hm2_7i43.0.gpio.033.in_not
setp hm2_7i43.0.gpio.035.is_output false
net y-home-sw <= hm2_7i43.0.gpio.035.in_not
setp hm2_7i43.0.gpio.037.is_output false
net z-home-sw <= hm2_7i43.0.gpio.037.in_not

# ---coolant signals---
net coolant-mist <= iocontrol.0.coolant-mist


# ---estop signals---
net estop-out <= iocontrol.0.user-enable-out
net epo-signal => iocontrol.0.emc-enable-in

# ---manual tool change signals---
loadusr -W hal_manualtoolchange
net tool-change iocontrol.0.tool-change => hal_manualtoolchange.change
net tool-changed iocontrol.0.tool-changed <= hal_manualtoolchange.changed
net tool-number iocontrol.0.tool-prep-number => hal_manualtoolchange.number
net tool-prepare-loopback iocontrol.0.tool-prepare => iocontrol.0.tool-prepared

————————————end hal ———————————

[andy pugh]

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which will
zero the encoder at the index pulse) and feeding the encoder feedback back
into LinuxCNC.

Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for open-loop step
position control but has encoder feedback. However I can't immediately see
why this makes a difference.

I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.

[Chris Radek]

Post by andy pugh
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.

[Sebastian Kuzminsky]

Post by Chris Radek

Post by andy pugh
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.

Tom has no pids in this config, he's using position-mode steppers with
encoders.

That's the same setup I use on the shopbot at the local hackspace, and
it homes fine. I don't see anything obviously wrong with Tom's config.

[Jon Elson]

Post by Sebastian Kuzminsky

Post by Chris Radek

Post by andy pugh
Now, this is perfectly normal, and with a servo / pid
machine the system
knows to ignore the f-error immediately after an encoder
reset. What is
puzzling me here is why it isn't working in this case. I
think it is

pid's index-enables need to be added to the index-enable
nets.

Tom has no pids in this config, he's using position-mode
steppers with encoders.

Where does the following error come from, then?

Jon

[Peter C. Wallace]

Date: Wed, 21 Jun 2017 11:48:17 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing

Post by Sebastian Kuzminsky

Post by Chris Radek

Post by andy pugh
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.

Tom has no pids in this config, he's using position-mode steppers with
encoders.

Where does the following error come from, then?
Jon

A step in the FB position from the encoder and an attempt at an impossible
step in the commanded stepgen position...


All the complexities / workrounds of this position step on index could be
avoided if support for encoder counter that can only clear on index
was dropped.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Jon Elson]

Post by Peter C. Wallace
A step in the FB position from the encoder and an attempt
at an impossible step in the commanded stepgen position...
All the complexities / workrounds of this position step on
index could be avoided if support for encoder counter that
can only clear on index was dropped.

OK, so stepgen also can compute following error. Without
encoders, it is only possible if steps can't be issued fast
enough, but with encoders, then there are other ways to
create a following error.

Thanks,

Jon

[Peter C. Wallace]

Date: Wed, 21 Jun 2017 13:22:04 -0500
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing

Post by Peter C. Wallace
A step in the FB position from the encoder and an attempt at an impossible
step in the commanded stepgen position...
All the complexities / workrounds of this position step on index could be
avoided if support for encoder counter that can only clear on index was
dropped.

OK, so stepgen also can compute following error. Without encoders, it is
only possible if steps can't be issued fast enough, but with encoders, then
there are other ways to create a following error.
Thanks,
Jon

The stepgen is not computing following error it just cant be driven by a
position command with a stepwise discontinuity and move instantaneously to the
new position.

A PID run velocity mode stepgen (or normal velocity mode servo) can do this
because both its feedback (from the encoder) and the commanded position make
this position step concurrently at index detection so the PID comp just
carries on as if nothing had happened

The PID derivative terms, FF1 and maybe D are patched at index detection so
the step in command and FB doesn't cause a one servo cycle long thump

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[andy pugh]

Post by Peter C. Wallace
The stepgen is not computing following error it just cant be driven by a
position command with a stepwise discontinuity and move instantaneously to
the new position.

I think it might be more interesting than that. Stepgen commanded position
and encoder position track each other very well, and the f-error is small
throughout.

https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing

[Peter C. Wallace]

Date: Thu, 22 Jun 2017 00:06:42 +0100
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
The stepgen is not computing following error it just cant be driven by a
position command with a stepwise discontinuity and move instantaneously to
the new position.

I think it might be more interesting than that. Stepgen commanded position
and encoder position track each other very well, and the f-error is small
throughout.

https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
ÿÿ George Fitch, Atlanta Constitution Newspaper, 1916


Only because the step was small (because it was probably not the first time
homed)

Take a look at axis.0.motor-pos-fb and axis.0.motor-pos-cmd in Sebastians test
on a servo system:

Loading Image...

Notice the (probably multi-inch) jump to 0 when index is detected

A velocity mode servo system can cope with this because the PIDs command and
feedback step at the ~same time (and there are some patches to fix derivative
related problems in the PID comp when index is detected)

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Tom Easterday]

I moved the Z axis down maybe 1/2" before issuing the home command, so it only needs to move a short distance to get back to the switch.
-Tom

Only because the step was small (because it was probably not the first time homed)

[andy pugh]

Post by Peter C. Wallace
Only because the step was small (because it was probably not the first
time homed)

Well, yes, but then the question is _why_ it is triggering the f-error
again.

[Nicklas Karlsson]

On Thu, 22 Jun 2017 00:06:42 +0100

Post by andy pugh

Post by Peter C. Wallace
The stepgen is not computing following error it just cant be driven by a
position command with a stepwise discontinuity and move instantaneously to
the new position.

I think it might be more interesting than that. Stepgen commanded position
and encoder position track each other very well, and the f-error is small
throughout.
https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing

Yes there could be a following error for stepper generator. I think it is like this, it output step frequency and number of stepped steps backs so there could be a difference. I modified stepper driver for my own card and also discovered decimal point is useful then stepping with a frequency close to servo loop. Without decimal there will be quite a lot of jitter then switching between integer number of steps and decimal point place flanks withing period. It might be step speed have been chosen to avoid jitter.

[andy pugh]

Post by Chris Radek

Post by andy pugh
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.

Yes, but, there is no PID here.

[Jon Elson]

Post by Chris Radek

Post by andy pugh
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is

pid's index-enables need to be added to the index-enable nets.

Well, that certainly will do it! To explain, index-enable
is a very funny signal, unlike almost anything else in HAL.
On both the encoder and joint, these are bi-directional
pins. When homing or preparing to synch to the spindle, the
scheme is as follows:

joint sets index-enable to 1
encoder sees index-enable as 1 and enables the encoder
counter to be zeroed when the index pulse is detected
the encoder component also clears index-enable on that servo
cycle
joint detects index-enable has been cleared, and ends the
homing cycle.

So, it is obvious PID also needs to know that on a
particular servo cycle, the encoder position has made a
jump, but should not report an error or produce a large PID
output based on that. This suppresses errors, but ONLY for
one servo cycle.

Jon

[Jon Elson]

Post by andy pugh

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which will
zero the encoder at the index pulse) and feeding the encoder feedback back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the system
knows to ignore the f-error immediately after an encoder reset. What is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for open-loop step
position control but has encoder feedback. However I can't immediately see
why this makes a difference.

I think I have an idea. If the jump in position is all
accomplished in one servo cycle, then the jump is handled by
the logic you describe. If the jump is spread over a few
servo cycles or delayed by even one cycle, it will certainly
cause a following error. The key is that Tom reports
setting MIN_FERROR to 1 doesn't suppress the error. That
means the position jump is not occurring during the same
servo cycle where the index pulse is seen. Is the encoder
feeding ANYTHING else than LinuxCNC through a simple
interface? Some external motion controller or drive in the
path between encoder and LinuxCNC could introduce a delay.

Post by andy pugh
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.

Yes, since the first home operation should zero the encoder
counter at the index position, re-doing the home should
cause a minimal shift in the position.

Jon

[Todd Zuercher]

----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,

I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.

His problem sounds different since he says can't clear the alarm.

My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.

[Tom Easterday]

Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.

-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by Tom Easterday
Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.

I think you may need to scope this out with Halscope,
looking at encoder velocity, ENCODER_INDEX_ENABLE and PID,
and trigger the trace on amp_enable. There seem to be two
problems here. One is, it should not be tripping a
following error. Second, it should not get in a state that
requires restarting. Have you tried going to E-stop (F1)
and then F2?
Going all the way to E-stop really should clear all
conditions like that.

I'm thinking there may be something wrong in your HAL files
that is causing the state of the system to get stuck.

Jon

[Jon Elson]

Post by Todd Zuercher
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.

You should be able to track signals such as encoder position
and INDEX_ENABLE with Halscope and capture the events when
this happens. Homing does cause a discontinuity in the PID,
which is only masked on following error and P. The PID
output gets a bit of a bump due to the D term. Since it is
usually moving quite slowly during the final home to index
move, that shouldn't be enough to trip errors. You could
try lowing the final move and see if that helps. I
occasionally get a servo amp fault just as the index is
detected for this reason. Pretty rare, so I have ignored it.

Jon

[Todd Zuercher]

I just checked my config on my step/dir servo machine, and it is homing to index on 2 of the axis. It is not having and problems. Maybe you have a configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check it over.

----- Original Message -----
From: "Tom Easterday" <tom-***@bgp.nu>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing

Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.

-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Tom Easterday]

Todd, the ini and hal config were in the first post....

Post by Todd Zuercher
I just checked my config on my step/dir servo machine, and it is homing to index on 2 of the axis. It is not having and problems. Maybe you have a configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check it over.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing
Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.
-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Tom Easterday]

Is there a parameter I can tweak after it happens in order to clear the fault (e.g. can I clear the ferror value) ? I can then try to home again...

Post by Tom Easterday
Todd, the ini and hal config were in the first post....

Post by Todd Zuercher
I just checked my config on my step/dir servo machine, and it is homing to index on 2 of the axis. It is not having and problems. Maybe you have a configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check it over.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing
Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.
-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Jon Elson]

Post by Tom Easterday
Is there a parameter I can tweak after it happens in order to clear the fault (e.g. can I clear the ferror value) ? I can then try to home again...

PID error should be recomputed every servo cycle. If PID
error remains at a large value, then it means that the
commanded position is not being reset to the actual position
when not in machine-on state. Whenever you leave the
machine-on state (following error, F2 or F1) then the
commanded position should be reset to equal actual position,
and that should cause PID error to become zero.

Jon

[Gene Heskett]

Post by Tom Easterday
Is there a parameter I can tweak after it happens in order to clear
the fault (e.g. can I clear the ferror value) ? I can then try to
home again...

I've no clue if this would apply to your case or not, Tom. The mpja dial
encoders I use for jogging in lieu of manual cranks on this new to me
Sheldon lathe, are inputting thru a std mesa card encoder, and when the
jog timeout is finished, 5 seconds after the last "click", I found it
was needed to hold the encoder on the mesa card in reset, so the next
time I push the button, to adjust the per step movement or to use it as
a jog wheel at the last gain setting, the motion induced effectively
starts at zero = whereever the dial was at when I enabled it. If I want
to make a calibrated motion, I set the dial to zero before I push the
button to enable it, then I can just dial in the motion I need. Wait for
the 5 second timeout and touch it off at the new position.

But I don't think this is a solution to your problem.

In your case, since zeroing the encoder would move the machine, I believe
I would AND the home switch input with the index before I sent the home
switch signal to the motion modules input. And because the index is
relatively narrow, a slower search velocity might be needed.

That way, motion would be snapshoting the encoders status at the index,
not on the home switch, but on the next index pulse after the home
switch activated. It seems to me that would get rid of a following
error. Be sure you debounce the home switch just enough for
consistency. And that the home switch is far enough away from any
mechanical travel stops by a full turn of the motor, and is setup that
the potentially full turn of the screw, the extra travel needed to find
the index, will not damage the home switch. And of course advise the
list if this latter idea solves the problem.

This advice comes with no warranty of course. :)

Post by Tom Easterday

Post by Tom Easterday
Todd, the ini and hal config were in the first post....

On Jun 20, 2017, at 9:21 AM, Todd Zuercher
I just checked my config on my step/dir servo machine, and it is
homing to index on 2 of the axis. It is not having and problems.
Maybe you have a configuration problem. Could you post a copy of
your ini and hal file somewhere where we could check it over.
----- Original Message -----
To: "Enhanced Machine Controller (EMC)"
9:00:22 AM
Subject: Re: [Emc-users] following error only while homing
Andy, you are correct it is related to using index. Homing works
fine if I don't use index. The encoder reset makes sense as to why
it CAN happen (but shouldn't be). Is this just a bug? I would try
to home a second time but as Todd says, I can't clear the error.
Linuxcnc shuts off when it happens and pressing on just immediately
faults again. I have to exit and restart it.
-Tom

On Jun 20, 2017, at 8:13 AM, Todd Zuercher
----- Original Message -----

Post by Todd Zuercher
To: "Enhanced Machine Controller (EMC)"
4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX
(which will
zero the encoder at the index pulse) and feeding the encoder
feedback back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset.
What is
puzzling me here is why it isn't working in this case. I think it
is something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine
trips up and sets a following error on an axis about 25% of the
time when trying to home to index for the first time after turning
on LInuxcnc. (Almost every time since it is a 4 axis machine.)
But the alarm is easily cleared, and it always homes fine the 2nd
try. I have never been able to figure out why, and no one else
seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index
to home to. But it does home fine without ever setting following
errors.
------------------------------------------------------------------
------------ Check out the vibrant tech community on one of the
world's most engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

-------------------------------------------------------------------
----------- Check out the vibrant tech community on one of the
world's most engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
-------------------------------------------------------------------
----------- Check out the vibrant tech community on one of the
world's most engaging tech sites, Slashdot.org!
http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

--------------------------------------------------------------------
---------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Cheers, Gene Heskett

[Todd Zuercher]

What if you set up the stepgens in velocity mode with PID (I understand that it is the better way to do hardware stepping with Mesa cards anyway.) This is how I have my step/dir servos configured (using the encoder feedback for the PID loop rather than the stepgens dummy position feedback.

----- Original Message -----
From: "Tom Easterday" <tom-***@bgp.nu>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 9:49:51 AM
Subject: Re: [Emc-users] following error only while homing

Todd, the ini and hal config were in the first post....

Post by Todd Zuercher
I just checked my config on my step/dir servo machine, and it is homing to index on 2 of the axis. It is not having and problems. Maybe you have a configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check it over.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing
Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.
-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Tom Easterday]

Hmm, it seems like I failed miserably trying to do that when I first built the machine (this was my first build and Linuxcnc endeavor) back in 2010. I have a vague recollection someone suggested that as a method of using encoders with steppers. Seems like I spent a bunch of time flailing with getting the pid to work and ultimately gave up. Perhaps I could attempt it again...I assume it would be identical to setting up a typical servo system?

Post by Todd Zuercher
What if you set up the stepgens in velocity mode with PID (I understand that it is the better way to do hardware stepping with Mesa cards anyway.) This is how I have my step/dir servos configured (using the encoder feedback for the PID loop rather than the stepgens dummy position feedback.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:49:51 AM
Subject: Re: [Emc-users] following error only while homing
Todd, the ini and hal config were in the first post....

Post by Todd Zuercher
I just checked my config on my step/dir servo machine, and it is homing to index on 2 of the axis. It is not having and problems. Maybe you have a configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check it over.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing
Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.
-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Todd Zuercher]

Here is what my Hal file looks like for my step/dir machine with encoder feedback. It has the stepgens configured for velocity mode and a PID loop (using a Mesa 5i25/7i85s).



# Generated by PNCconf at Tue Jul 9 15:53:16 2013
# If you make changes to this file, they will be
# overwritten when you run PNCconf again

loadrt trivkins
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
#loadrt probe_parport
loadrt hostmot2
loadrt hm2_pci config=" num_encoders=4 num_pwmgens=0 num_3pwmgens=0 num_stepgens=4 sserial_port_0=0xxxxxxx "
setp hm2_5i25.0.watchdog.timeout_ns 10000000
#loadrt hal_parport cfg="0x0278 in"
loadrt pid names=pid.x,pid.y,pid.z
#loadrt abs names=
#loadrt lowpass names=
#loadrt classicladder_rt numPhysInputs=15 numPhysOutputs=15 numS32in=10 numS32out=10 numFloatIn=10 numFloatOut=10

#addf parport.0.read servo-thread
#addf parport.0.write servo-thread
addf hm2_5i25.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x.do-pid-calcs servo-thread
addf pid.y.do-pid-calcs servo-thread
addf pid.z.do-pid-calcs servo-thread
#addf classicladder.0.refresh servo-thread
addf hm2_5i25.0.write servo-thread
#addf hm2_5i25.0.pet_watchdog servo-thread


#*******************
# AXIS X
#*******************

setp pid.x.Pgain [AXIS_0]P
setp pid.x.Igain [AXIS_0]I
setp pid.x.Dgain [AXIS_0]D
setp pid.x.bias [AXIS_0]BIAS
setp pid.x.FF0 [AXIS_0]FF0
setp pid.x.FF1 [AXIS_0]FF1
setp pid.x.FF2 [AXIS_0]FF2
setp pid.x.deadband [AXIS_0]DEADBAND
setp pid.x.maxoutput [AXIS_0]MAX_OUTPUT

net x-index-enable <=> pid.x.index-enable
net x-enable => pid.x.enable
net x-output => pid.x.output
net x-pos-cmd => pid.x.command
net x-vel-fb => pid.x.feedback-deriv
net x-pos-fb => pid.x.feedback

# Step Gen signals/setup

setp hm2_5i25.0.stepgen.00.dirsetup [AXIS_0]DIRSETUP
setp hm2_5i25.0.stepgen.00.dirhold [AXIS_0]DIRHOLD
setp hm2_5i25.0.stepgen.00.steplen [AXIS_0]STEPLEN
setp hm2_5i25.0.stepgen.00.stepspace [AXIS_0]STEPSPACE
setp hm2_5i25.0.stepgen.00.position-scale [AXIS_0]STEP_SCALE
setp hm2_5i25.0.stepgen.00.step_type 0
setp hm2_5i25.0.stepgen.00.control-type 1
setp hm2_5i25.0.stepgen.00.maxaccel 18
setp hm2_5i25.0.stepgen.00.maxvel 12.5

# ---closedloop stepper signals---

net x-pos-cmd axis.0.motor-pos-cmd
net x-output => hm2_5i25.0.stepgen.00.velocity-cmd
net x-enable axis.0.amp-enable-out => hm2_5i25.0.stepgen.00.enable

# ---Encoder feedback signals/setup---

setp hm2_5i25.0.encoder.00.counter-mode 0
setp hm2_5i25.0.encoder.00.filter 1
setp hm2_5i25.0.encoder.00.index-invert 0
setp hm2_5i25.0.encoder.00.index-mask 0
setp hm2_5i25.0.encoder.00.index-mask-invert 0
setp hm2_5i25.0.encoder.00.scale [AXIS_0]ENCODER_SCALE

net x-pos-fb <= hm2_5i25.0.encoder.00.position
net x-vel-fb <= hm2_5i25.0.encoder.00.velocity
net x-pos-fb => axis.0.motor-pos-fb
net x-index-enable axis.0.index-enable <=> hm2_5i25.0.encoder.00.index-enable
net x-pos-rawcounts <= hm2_5i25.0.encoder.00.rawcounts

# ---setup home / limit switch signals---

#net min-home-x => axis.0.home-sw-in
#net min-home-x => axis.0.neg-lim-sw-in
#net max-x => axis.0.pos-lim-sw-in

#*******************
# AXIS Y
#*******************

setp pid.y.Pgain [AXIS_1]P
setp pid.y.Igain [AXIS_1]I
setp pid.y.Dgain [AXIS_1]D
setp pid.y.bias [AXIS_1]BIAS
setp pid.y.FF0 [AXIS_1]FF0
setp pid.y.FF1 [AXIS_1]FF1
setp pid.y.FF2 [AXIS_1]FF2
setp pid.y.deadband [AXIS_1]DEADBAND
setp pid.y.maxoutput [AXIS_1]MAX_OUTPUT

net y-index-enable <=> pid.y.index-enable
net y-enable => pid.y.enable
net y-output => pid.y.output
net y-pos-cmd => pid.y.command
net y-vel-fb => pid.y.feedback-deriv
net y-pos-fb => pid.y.feedback

# Step Gen signals/setup

setp hm2_5i25.0.stepgen.01.dirsetup [AXIS_1]DIRSETUP
setp hm2_5i25.0.stepgen.01.dirhold [AXIS_1]DIRHOLD
setp hm2_5i25.0.stepgen.01.steplen [AXIS_1]STEPLEN
setp hm2_5i25.0.stepgen.01.stepspace [AXIS_1]STEPSPACE
setp hm2_5i25.0.stepgen.01.position-scale [AXIS_1]STEP_SCALE
setp hm2_5i25.0.stepgen.01.step_type 0
setp hm2_5i25.0.stepgen.01.control-type 1
setp hm2_5i25.0.stepgen.01.maxaccel 18
setp hm2_5i25.0.stepgen.01.maxvel 12.5

# ---closedloop stepper signals---

net y-pos-cmd axis.1.motor-pos-cmd
net y-output => hm2_5i25.0.stepgen.01.velocity-cmd
net y-enable axis.1.amp-enable-out => hm2_5i25.0.stepgen.01.enable

# ---Encoder feedback signals/setup---

setp hm2_5i25.0.encoder.01.counter-mode 0
setp hm2_5i25.0.encoder.01.filter 1
setp hm2_5i25.0.encoder.01.index-invert 0
setp hm2_5i25.0.encoder.01.index-mask 0
setp hm2_5i25.0.encoder.01.index-mask-invert 0
setp hm2_5i25.0.encoder.01.scale [AXIS_1]ENCODER_SCALE

net y-pos-fb <= hm2_5i25.0.encoder.01.position
net y-vel-fb <= hm2_5i25.0.encoder.01.velocity
net y-pos-fb => axis.1.motor-pos-fb
net y-index-enable axis.1.index-enable <=> hm2_5i25.0.encoder.01.index-enable
net y-pos-rawcounts <= hm2_5i25.0.encoder.01.rawcounts

# ---setup home / limit switch signals---

#net max-home-y => axis.1.home-sw-in
#net min-y => axis.1.neg-lim-sw-in
#net max-home-y => axis.1.pos-lim-sw-in

#*******************
# AXIS Z
#*******************

setp pid.z.Pgain [AXIS_2]P
setp pid.z.Igain [AXIS_2]I
setp pid.z.Dgain [AXIS_2]D
setp pid.z.bias [AXIS_2]BIAS
setp pid.z.FF0 [AXIS_2]FF0
setp pid.z.FF1 [AXIS_2]FF1
setp pid.z.FF2 [AXIS_2]FF2
setp pid.z.deadband [AXIS_2]DEADBAND
setp pid.z.maxoutput [AXIS_2]MAX_OUTPUT

net z-index-enable <=> pid.z.index-enable
net z-enable => pid.z.enable
net z-output => pid.z.output
net z-pos-cmd => pid.z.command
net z-vel-fb => pid.z.feedback-deriv
net z-pos-fb => pid.z.feedback

# Step Gen signals/setup

setp hm2_5i25.0.stepgen.02.dirsetup [AXIS_2]DIRSETUP
setp hm2_5i25.0.stepgen.02.dirhold [AXIS_2]DIRHOLD
setp hm2_5i25.0.stepgen.02.steplen [AXIS_2]STEPLEN
setp hm2_5i25.0.stepgen.02.stepspace [AXIS_2]STEPSPACE
setp hm2_5i25.0.stepgen.02.position-scale [AXIS_2]STEP_SCALE
setp hm2_5i25.0.stepgen.02.step_type 0
setp hm2_5i25.0.stepgen.02.control-type 1
setp hm2_5i25.0.stepgen.02.maxaccel 25
setp hm2_5i25.0.stepgen.02.maxvel 8

# ---closedloop stepper signals---

net z-pos-cmd axis.2.motor-pos-cmd
net z-output => hm2_5i25.0.stepgen.02.velocity-cmd
net z-enable axis.2.amp-enable-out => hm2_5i25.0.stepgen.02.enable

# ---Encoder feedback signals/setup---

setp hm2_5i25.0.encoder.02.counter-mode 0
setp hm2_5i25.0.encoder.02.filter 1
setp hm2_5i25.0.encoder.02.index-invert 0
setp hm2_5i25.0.encoder.02.index-mask 0
setp hm2_5i25.0.encoder.02.index-mask-invert 0
setp hm2_5i25.0.encoder.02.scale [AXIS_2]ENCODER_SCALE

net z-pos-fb <= hm2_5i25.0.encoder.02.position
net z-vel-fb <= hm2_5i25.0.encoder.02.velocity
net z-pos-fb => axis.2.motor-pos-fb
net z-index-enable axis.2.index-enable <=> hm2_5i25.0.encoder.02.index-enable
net z-pos-rawcounts <= hm2_5i25.0.encoder.02.rawcounts

# ---setup home / limit switch signals---

#net max-home-z => axis.2.home-sw-in
#net min-z => axis.2.neg-lim-sw-in
#net max-home-z => axis.2.pos-lim-sw-in

#*******************
# SPINDLE S
#*******************

# ---setup spindle control signals---




# ---motion control signals---

#net in-position <= motion.in-position
#net machine-is-enabled <= motion.motion-enabled

# ---digital in / out signals---

# ---estop signals---

#net estop-out <= iocontrol.0.user-enable-out
#net estop-out => iocontrol.0.emc-enable-in


# Load Classicladder without GUI (can reload LADDER GUI in AXIS GUI

#loadusr classicladder --nogui custom.clp

[Todd Zuercher]

I don't see why my step/dir servo setup would be any different from a step motor + encoder config. (Obviously, PID settings would be different as they would be machine specific.)

One thing to remember the PID loop will likely not be able to correct for a stalled step motor. A few missed steps should be recoverable, but if a step motor stalls, the PID loop will command faster and faster velocities, trying to catch up to where it thinks it should be, making the stall worse.

----- Original Message -----
From: "Tom Easterday" <tom-***@bgp.nu>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 10:15:01 AM
Subject: Re: [Emc-users] following error only while homing

Hmm, it seems like I failed miserably trying to do that when I first built the machine (this was my first build and Linuxcnc endeavor) back in 2010. I have a vague recollection someone suggested that as a method of using encoders with steppers. Seems like I spent a bunch of time flailing with getting the pid to work and ultimately gave up. Perhaps I could attempt it again...I assume it would be identical to setting up a typical servo system?

Post by Todd Zuercher
What if you set up the stepgens in velocity mode with PID (I understand that it is the better way to do hardware stepping with Mesa cards anyway.) This is how I have my step/dir servos configured (using the encoder feedback for the PID loop rather than the stepgens dummy position feedback.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:49:51 AM
Subject: Re: [Emc-users] following error only while homing
Todd, the ini and hal config were in the first post....

Post by Todd Zuercher
I just checked my config on my step/dir servo machine, and it is homing to index on 2 of the axis. It is not having and problems. Maybe you have a configuration problem.
Could you post a copy of your ini and hal file somewhere where we could check it over.
----- Original Message -----
Sent: Tuesday, June 20, 2017 9:00:22 AM
Subject: Re: [Emc-users] following error only while homing
Andy, you are correct it is related to using index. Homing works fine if I don't use index. The encoder reset makes sense as to why it CAN happen (but shouldn't be). Is this just a bug? I would try to home a second time but as Todd says, I can't clear the error. Linuxcnc shuts off when it happens and pressing on just immediately faults again. I have to exit and restart it.
-Tom

Post by Todd Zuercher
----- Original Message -----

Sent: Tuesday, June 20, 2017 4:27:46 AM
Subject: Re: [Emc-users] following error only while homing

Post by t***@bgp.nu
Why would I get a following error only while homing

I think it is probably because you are using HOME_USE_INDEX (which
will
zero the encoder at the index pulse) and feeding the encoder feedback
back
into LinuxCNC.
Now, this is perfectly normal, and with a servo / pid machine the
system
knows to ignore the f-error immediately after an encoder reset. What
is
puzzling me here is why it isn't working in this case. I think it is
something to do with the fact that your system is set up for
open-loop step
position control but has encoder feedback. However I can't
immediately see
why this makes a difference.
I imagine that if you press the home button again it will home Z
seamlessly, and then f-error homing the next axis.
--
atp

Andy,
I wish that were true. For some reason my analog servo machine trips up and sets a following error on an axis about 25% of the time when trying to home to index for the first time after turning on LInuxcnc. (Almost every time since it is a 4 axis machine.) But the alarm is easily cleared, and it always homes fine the 2nd try. I have never been able to figure out why, and no one else seems to have been able to replicate the problem.
His problem sounds different since he says can't clear the alarm.
My other machine with step/dir servos, doesn't have encoder index to home to. But it does home fine without ever setting following errors.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Sebastian Kuzminsky]

Post by t***@bgp.nu
Why would I get a following error only while homing (latest Linuxcnc
2.7.9)? I recently added home switches to my machine. My machine
has encoders on the steppers on each of the 3 axes so I want to use
the index pulse for home. I set up the homing sequence each axis
and when I do "Home All" I get a following error on my Z axis (first
one to home). I played with all the settings and can’t get it to
complete unless I set ferror and min_ferror very high Also, once
there is a following error I can only clear it by exiting Linuxcnc
and restarting it. If I just turn it back on, it immediately faults
again with the same following error. If I don’t home, after
restarting Linuxcnc, I can run the Z axis (and X and Y) all day at
any speed without a following error.
I have tried setting the ferror and min_ferror settings to various
reasonable values but it didn’t work. Before adding the switches I
had error=0.001 and min_ferror=0.0005 and never had a following error
appear. I set ferror to 2 and min_ferror to 1 (I think those were
the values) and it worked but then got the following error on the Y
axis (the second axis homed). The values for ferror and min_ferror
that “worked” seem completely unreasonable given I am not even moving
anywhere near my max velocity during homing.
I have tried changing the sign on the HOME_LATCH_VEL to make it
search for index in the other direction but the same thing happens.
Below are my (current) machine hal and ini.

Your ini and hal file look right, except that in the hal file all
stepgens get their .maxvel and .maxaccel from [AXIS_0]. But all your
[AXIS_*]MAXVEL and MAXACCEL have the same value, so it doesn't affect
behavior in any way.

I agree with Jon Elson, the next step in debugging this should be to get
a halscope trace of Z homing and f-erroring, while looking at these pins:

hm2_7i43.0.stepgen.02.position-cmd
hm2_7i43.0.encoder.02.position
hm2_7i43.0.encoder.02.index-enable
axis.2.home-sw-in

Trigger on rising signal on axis.2.f-errored.

[Peter C. Wallace]

Post by Todd Zuercher
"Enhanced Machine Controller (EMC)"
error only while homing
Why would I get a following error only while homing (latest Linuxcnc 2.7.9)?
I recently added home switches to my machine. My machine has encoders on
the steppers on each of the 3 axes so I want to use the index pulse for
home. I set up the homing sequence each axis and when I do "Home All" I get
a following error on my Z axis (first one to home). I played with all the
settings and canÿÿt get it to complete unless I set ferror and min_ferror
very high Also, once there is a following error I can only clear it by
exiting Linuxcnc and restarting it. If I just turn it back on, it
immediately faults again with the same following error. If I donÿÿt home,
after restarting Linuxcnc, I can run the Z axis (and X and Y) all day at any
speed without a following error.
I have tried setting the ferror and min_ferror settings to various reasonable
values but it didnÿÿt work. Before adding the switches I had error=0.001 and
min_ferror=0.0005 and never had a following error appear. I set ferror to 2
and min_ferror to 1 (I think those were the values) and it worked but then got
the following error on the Y axis (the second axis homed). The values for
ferror and min_ferror that ÿÿworkedÿÿ seem completely unreasonable given I am
not even moving anywhere near my max velocity during homing.
I have tried changing the sign on the HOME_LATCH_VEL to make it search for
index in the other direction but the same thing happens. Below are my
(current) machine hal and ini.
-Tom

I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index (and
cooresponding jump in commanded position) cannot be followed by the
stepgen in position mode. It only happens once because index will not
cause a feedback position jump a second time since its already at 0

One way to make this work is do as others have siggested and run the stepgen
in velocity mode and run a standard servo velocity PID loop

This has the advantage the you are actually using the encoder feedback
for control rather than just monitoring following error

Peter Wallace

[andy pugh]

Post by Peter C. Wallace
I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index

I wonder if the answer might be to only connect the encoder once homed?

ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.

[Sebastian Kuzminsky]

Post by andy pugh

Post by Peter C. Wallace
I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index

He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home. His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.

axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using that.

Post by andy pugh
I wonder if the answer might be to only connect the encoder once homed?
ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.

That should not be needed.

Our shopbot has a similar setup, and it homes fine every time. It has a
Mesa FPGA, position-mode steppers, and encoder position feedback. It
homes to switches, but not to index.


The ini settings for all joints are of this form:

HOME = 0.000
HOME_OFFSET = -0.260
HOME_SEARCH_VEL = -2.00000
HOME_LATCH_VEL = 0.250
HOME_USE_INDEX = NO
HOME_IGNORE_LIMITS = YES
HOME_IS_SHARED = 0


The HAL wiring looks like this:

net x-encoder-pos <= hm2_5i23.0.encoder.01.position
net x-encoder-pos => axis.0.motor-pos-fb

net x-pos-cmd <= axis.0.motor-pos-cmd
net x-pos-cmd => hm2_5i23.0.stepgen.01.position-cmd


Pretty straight forward.

I still want to see the halscope trace.

It might be worth trying (just for debugging purposes) homing to the
home switch, not the index, since that's the config that works for me.
If home-to-index is broken we should fix it, and doing that test will
help tell us if that's the case.

I have a vague memory that there's a fairly long pause at some stage in
the homing state machine. I wonder if it was during index homing? And
if so, if that's maybe related to this problem? A halscope trace might
show us.

[Sebastian Kuzminsky]

Post by Sebastian Kuzminsky

Post by andy pugh

Post by Peter C. Wallace
I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index

He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home. His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.
axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using that.

Post by andy pugh
I wonder if the answer might be to only connect the encoder once homed?
ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.

That should not be needed.
Our shopbot has a similar setup, and it homes fine every time. It has a
Mesa FPGA, position-mode steppers, and encoder position feedback. It
homes to switches, but not to index.

Never mind, I misread what you guys are talking about. I think Peter
and Andy are right, the encoder's feedback jumps, even though the
position command does not.

Home to switch, not to index, and it should work fine.

[Sebastian Kuzminsky]

Post by Sebastian Kuzminsky

Post by Sebastian Kuzminsky

Post by andy pugh

Post by Peter C. Wallace
I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index

He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home. His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.
axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using that.

Post by andy pugh
I wonder if the answer might be to only connect the encoder once homed?
ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.

That should not be needed.
Our shopbot has a similar setup, and it homes fine every time. It has a
Mesa FPGA, position-mode steppers, and encoder position feedback. It
homes to switches, but not to index.

Never mind, I misread what you guys are talking about. I think Peter
and Andy are right, the encoder's feedback jumps, even though the
position command does not.
Home to switch, not to index, and it should work fine.

It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder. We already track .rawcount and compute .count from it, and
compute .position from .count.

[Sebastian Kuzminsky]

Post by Sebastian Kuzminsky

Post by Sebastian Kuzminsky

Post by Sebastian Kuzminsky

Post by andy pugh

Post by Peter C. Wallace
I suspect this cannot work the way you have this setup because of the
instantaneous jump in encoder (feedback) position at index

He has hooked up axis.*.motor-pos-cmd to the stepgens' .position-cmd,
and motor-pos-cmd does not jump on home. His stepgens will see a smooth
curve on their .position-cmd inputs even through all stages of homing.
axis.*.joint-pos-cmd includes the homing offset (and a bunch of other
offsets), so it has that discontinuity, so it's good he's not using that.

Post by andy pugh
I wonder if the answer might be to only connect the encoder once homed?
ie, use a mux2 to to connect motor-pos-fb to motor-pos-cmd until homed, and
only then switch it to the encoder.

That should not be needed.
Our shopbot has a similar setup, and it homes fine every time. It has a
Mesa FPGA, position-mode steppers, and encoder position feedback. It
homes to switches, but not to index.

Never mind, I misread what you guys are talking about. I think Peter
and Andy are right, the encoder's feedback jumps, even though the
position command does not.
Home to switch, not to index, and it should work fine.

It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder. We already track .rawcount and compute .count from it, and
compute .position from .count.

I just pushed a totally untested experimental branch named
"2.7-hm2-encoder-raw-position", try building that, keep home-to-index,
link the new .raw-position pin to axis.*.motor-pos-fb and let us know
how that works.

[andy pugh]

Post by Sebastian Kuzminsky
It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder. We already track .rawcount and compute .count from it, and
compute .position from .count.

If that is the answer then rawcounts * scale => feedback might be the
answer. With annoying type-conversions.

[andy pugh]

Post by Sebastian Kuzminsky
It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder.

Does homing use the accumulated counts in the counter after index as part
of the homing offset? It feels like it should.
If it does, then this might not work.

[t***@bgp.nu]

You guys are prolific, and I appreciate it! Thanks for all the input.

A few things in case it hasn’t been clear...

1) I don’t (currently) have a PID involved at all (position-mode steppers with encoders only).
2) If I set FERROR=2 and MIN_FERROR=1, homing DOES complete successfully.
2) Pressing estop after the following error, and then trying to turn Linuxcnc back on from there does NOT help, the error persists. Only exiting and restarting Linuxcnc clears it.

The Halscope trace of: hm2_7i43.0.stepgen.02.position-cmd, hm2_7i43.0.encoder.02.position, hm2_7i43.0.encoder.02.index-enable, axis.2.home-sw-in with trigger of axis.2.f-errored can be seen here:
Loading Image...

I’m happy to help debug a (even obscure) bug if you want, but it sounds like I’d be better off using velocity mode and PID ANYWAY, and so should probably do that instead of what I have. To wit...

I just pushed a totally untested experimental branch named "2.7-hm2-encoder-raw-position", try building that, keep home-to-index, link the new .raw-position pin to axis.*.motor-pos-fb and let us know how that works.

If you DO want me to test this, please remind me how I go about getting/building/running it. It has been a while since I have grabbed branches. This machine runs from the standard release model, so I assume I will need to incant git (all of which I tend to forget within a week of using it for some reason)…

-Tom

Post by Sebastian Kuzminsky
It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder.

Does homing use the accumulated counts in the counter after index as part
of the homing offset? It feels like it should.
If it does, then this might not work.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Sebastian Kuzminsky]

Post by t***@bgp.nu
The Halscope trace of: hm2_7i43.0.stepgen.02.position-cmd,
hm2_7i43.0.encoder.02.position, hm2_7i43.0.encoder.02.index-enable,
http://bgp.nu/~tom/pub/enc2.png

Welllll that looks fine. And my reading of the homing code tells me the
theory i had (about the jump in the encoder position) is wrong. I now
think it's perfectly normal for the .motor-pos-fb pin to jump during
homing, and the homing logic in Motion compensates for it by changing
the internal home offset at the same time.

Can you show us a plot like that one, but with axis.2.f-error instead of
.f-errored, add the axis.2.joint-pos-cmd, .joint-pos-fb, and
.motor-offset pins, and then zoom in on the f-error event?

Also increase the gain so we can see the fine detail on all the
position-releated pins (both cmd and fb).

Thanks...

[andy pugh]

Post by Sebastian Kuzminsky
Also increase the gain so we can see the fine detail on all the
position-releated pins (both cmd and fb).

I was going to suggest saving the data as a .log file from Halscope, so
that people can zoom and inspect for themselves, but I can't figure out how
to open a data file.

[t***@bgp.nu]

Is this what you want…?
Loading Image...
And the log file is...
http://bgp.nu/~tom/pub/enc-5.log

-Tom

Post by t***@bgp.nu
The Halscope trace of: hm2_7i43.0.stepgen.02.position-cmd,
hm2_7i43.0.encoder.02.position, hm2_7i43.0.encoder.02.index-enable,
http://bgp.nu/~tom/pub/enc2.png

Welllll that looks fine. And my reading of the homing code tells me the theory i had (about the jump in the encoder position) is wrong. I now think it's perfectly normal for the .motor-pos-fb pin to jump during homing, and the homing logic in Motion compensates for it by changing the internal home offset at the same time.
Can you show us a plot like that one, but with axis.2.f-error instead of .f-errored, add the axis.2.joint-pos-cmd, .joint-pos-fb, and .motor-offset pins, and then zoom in on the f-error event?
Also increase the gain so we can see the fine detail on all the position-releated pins (both cmd and fb).
Thanks...
--
Sebastian Kuzminsky
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[t***@bgp.nu]

Here is more zoom fwiw…. Loading Image...
-Tom

[Peter C. Wallace]

Date: Tue, 20 Jun 2017 19:52:13 -0400
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
Here is more zoom fwiwÿÿ. http://bgp.nu/~tom/pub/enc-6.png

-Tom


This looks like it has been homed before (no large step in encoder position at
index)



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Tom Easterday]

Well, it has been homed and is searching for index when it faults with the following error....but it isn't homed as I have just killed and restarted Linuxcnc. I then move the Z axis down a little bit and then Home All...
-Tom

This looks like it has been homed before (no large step in encoder position at index)
Peter Wallace

[Tom Easterday]

So is that large jump in f-error caused by the difference between axis.2.joint-pos-cmd and axis.2.joint-pos-fb? There is a small 90 degree step in pos-cmd that is not mirrored in pos-fb near the end, in line with the spike of f-error. Is that the cause and why is that there?

-Tom

Post by Tom Easterday
Well, it has been homed and is searching for index when it faults with the following error....but it isn't homed as I have just killed and restarted Linuxcnc. I then move the Z axis down a little bit and then Home All...
-Tom

This looks like it has been homed before (no large step in encoder position at index)
Peter Wallace

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Peter C. Wallace]

Date: Wed, 21 Jun 2017 10:11:01 -0400
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
So is that large jump in f-error caused by the difference between
axis.2.joint-pos-cmd and axis.2.joint-pos-fb? There is a small 90 degree
step in pos-cmd that is not mirrored in pos-fb near the end, in line with
the spike of f-error. Is that the cause and why is that there?

Yes, and this is why you cannot do homing to index with a stepgen in position
mode.

When you home to index the encoder position makes a (possibly large on first
home after startup) step change when the index is detected. The commanded position
must make a matching step. With a servo system, this does not cause a major
glitch because the commanded and feedback positions both change at once so
any move in progress just continues, in addition the PID component watches
index-enable so is able to discard the result of the derivative terms (FF1 and
D) so they dont cause a thump.



This does not work with a stepgen in postion mode because the stepgen gets a
step change in position command, that it cannot follow, this causes a large
instantaneous following error when index is detected


You can use step motors with an encoder and homing to index, but you must
setup your hal file differently, running the stepgen in velocity mode and
using a PID component to close the position loop with the feedback from the
encoder

-Tom

Post by Tom Easterday
Well, it has been homed and is searching for index when it faults with the following error....but it isn't homed as I have just killed and restarted Linuxcnc. I then move the Z axis down a little bit and then Home All...
-Tom

This looks like it has been homed before (no large step in encoder position at index)
Peter Wallace

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Todd Zuercher]

What is strange is that pressing Machine (F2) does not clear the alarm. (That won't close the alarm notification window, you have to click the X on that window to make it go away.)

----- Original Message -----
From: tom-***@bgp.nu
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Tuesday, June 20, 2017 3:31:42 PM
Subject: Re: [Emc-users] following error only while homing

You guys are prolific, and I appreciate it! Thanks for all the input.

A few things in case it hasn’t been clear...

1) I don’t (currently) have a PID involved at all (position-mode steppers with encoders only).
2) If I set FERROR=2 and MIN_FERROR=1, homing DOES complete successfully.
2) Pressing estop after the following error, and then trying to turn Linuxcnc back on from there does NOT help, the error persists. Only exiting and restarting Linuxcnc clears it.

The Halscope trace of: hm2_7i43.0.stepgen.02.position-cmd, hm2_7i43.0.encoder.02.position, hm2_7i43.0.encoder.02.index-enable, axis.2.home-sw-in with trigger of axis.2.f-errored can be seen here:
http://bgp.nu/~tom/pub/enc2.png

I’m happy to help debug a (even obscure) bug if you want, but it sounds like I’d be better off using velocity mode and PID ANYWAY, and so should probably do that instead of what I have. To wit...

I just pushed a totally untested experimental branch named "2.7-hm2-encoder-raw-position", try building that, keep home-to-index, link the new .raw-position pin to axis.*.motor-pos-fb and let us know how that works.

If you DO want me to test this, please remind me how I go about getting/building/running it. It has been a while since I have grabbed branches. This machine runs from the standard release model, so I assume I will need to incant git (all of which I tend to forget within a week of using it for some reason)…

-Tom

Post by Sebastian Kuzminsky
It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder.

Does homing use the accumulated counts in the counter after index as part
of the homing offset? It feels like it should.
If it does, then this might not work.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[t***@bgp.nu]

Yes, when I re-enable the machine (with or without estop first) I get another (immediate) following error. That is, I understand to make the notification itself go away I click the X, but what I am seeing is a perpetual following error when re-enabling with each new notification piling up on the lower right of Axis display.
-Tom

Post by Todd Zuercher
What is strange is that pressing Machine (F2) does not clear the alarm. (That won't close the alarm notification window, you have to click the X on that window to make it go away.)
----- Original Message -----
Sent: Tuesday, June 20, 2017 3:31:42 PM
Subject: Re: [Emc-users] following error only while homing
You guys are prolific, and I appreciate it! Thanks for all the input.
A few things in case it hasn’t been clear...
1) I don’t (currently) have a PID involved at all (position-mode steppers with encoders only).
2) If I set FERROR=2 and MIN_FERROR=1, homing DOES complete successfully.
2) Pressing estop after the following error, and then trying to turn Linuxcnc back on from there does NOT help, the error persists. Only exiting and restarting Linuxcnc clears it.
http://bgp.nu/~tom/pub/enc2.png
I’m happy to help debug a (even obscure) bug if you want, but it sounds like I’d be better off using velocity mode and PID ANYWAY, and so should probably do that instead of what I have. To wit...

I just pushed a totally untested experimental branch named "2.7-hm2-encoder-raw-position", try building that, keep home-to-index, link the new .raw-position pin to axis.*.motor-pos-fb and let us know how that works.

If you DO want me to test this, please remind me how I go about getting/building/running it. It has been a while since I have grabbed branches. This machine runs from the standard release model, so I assume I will need to incant git (all of which I tend to forget within a week of using it for some reason)…
-Tom

Post by Sebastian Kuzminsky
It looks like it'd be easy to add a ".raw-position" pin to the hostmot2
encoder.

Does homing use the accumulated counts in the counter after index as part
of the homing offset? It feels like it should.
If it does, then this might not work.
--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is designed
for the especial use of mechanical geniuses, daredevils and lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

[Todd Zuercher]

Here are links to a halscope screen shot and log file for my servo machine that keeps setting following errors on first try homing.

homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc


----- Original Message -----
From: "Nicklas Karlsson" <***@gmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Thursday, June 22, 2017 1:23:29 PM
Subject: Re: [Emc-users] following error only while homing

On Thu, 22 Jun 2017 00:06:42 +0100

Post by andy pugh

Post by Peter C. Wallace
The stepgen is not computing following error it just cant be driven by a
position command with a stepwise discontinuity and move instantaneously to
the new position.

I think it might be more interesting than that. Stepgen commanded position
and encoder position track each other very well, and the f-error is small
throughout.
https://docs.google.com/spreadsheets/d/1qRVyQWFl4BIsSNKwy9IYsXrmZLTK8vgVVNX4tAuUmJM/edit?usp=sharing

Yes there could be a following error for stepper generator. I think it is like this, it output step frequency and number of stepped steps backs so there could be a difference. I modified stepper driver for my own card and also discovered decimal point is useful then stepping with a frequency close to servo loop. Without decimal there will be quite a lot of jitter then switching between integer number of steps and decimal point place flanks withing period. It might be step speed have been chosen to avoid jitter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Peter C. Wallace]

Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
Here are links to a halscope screen shot and log file for my servo machine that keeps setting following errors on first try homing.
homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc

Because the scale of the position command is so huge its hard to tell whats
going on but the ferror size matches the encoder step size at index, This (and
the one cycle ferror duration) suggests that there is a thread/operation order
issue of some kind in the hal file.


Peter Wallace
Mesa Electronics

[Todd Zuercher]

That is what I've suspected but I can't figure out what I have out of place.
I did another screen shot with the position-cmd zoomed in as much as I could and keep it on the screen.
It seems that the index enable falls, and the encoder position is reset,then the PID gets whacked for one servo period, then the position-cmd is reset.
I have the PID index-enable pin connected, but I not sure it is actually doing anything.

Here are my addf orders:

addf hm2_5i25.0.read base-thread
addf pid.x_vel.do-pid-calcs base-thread
addf pid.y_vel.do-pid-calcs base-thread
addf pid.z_vel.do-pid-calcs base-thread
addf pid.w_vel.do-pid-calcs base-thread
addf hm2_5i25.0.write base-thread

addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf sum2.0 servo-thread
addf offset.0.update-output servo-thread
addf offset.0.update-feedback servo-thread
addf mux2.0 servo-thread
addf mux2.1 servo-thread
addf pid.x_pos.do-pid-calcs servo-thread
addf pid.y_pos.do-pid-calcs servo-thread
addf pid.z_pos.do-pid-calcs servo-thread
addf pid.w_pos.do-pid-calcs servo-thread
#addf hm2_5i25.0.pet_watchdog servo-thread
addf and2.0 servo-thread


----- Original Message -----
From: "Peter C. Wallace" <***@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Friday, June 23, 2017 11:55:58 AM
Subject: Re: [Emc-users] following error only while homing

Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
Here are links to a halscope screen shot and log file for my servo machine that keeps setting following errors on first try homing.
homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc

Because the scale of the position command is so huge its hard to tell whats
going on but the ferror size matches the encoder step size at index, This (and
the one cycle ferror duration) suggests that there is a thread/operation order
issue of some kind in the hal file.


Peter Wallace
Mesa Electronics

[Peter C. Wallace]

Date: Fri, 23 Jun 2017 13:20:26 -0400 (EDT)
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
That is what I've suspected but I can't figure out what I have out of place.
I did another screen shot with the position-cmd zoomed in as much as I could and keep it on the screen.
It seems that the index enable falls, and the encoder position is reset,then the PID gets whacked for one servo period, then the position-cmd is reset.
I have the PID index-enable pin connected, but I not sure it is actually doing anything.

Yeah, those are ordered wrong so LinuxCNC's patching aound the encoder step on
index fails, but I'm not sure they can be ordered correctly with your mixed
(base/servo) thread setup. A normal servo thread only config would be
something like

addf hm2_5i25.0.read servo-thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf pid.x_vel.do-pid-calcs servo-thread
addf pid.y_vel.do-pid-calcs servo-thread
addf pid.z_vel.do-pid-calcs servo-thread
addf pid.w_vel.do-pid-calcs servo-thread
addf sum2.0 servo-thread
addf offset.0.update-output servo-thread
addf offset.0.update-feedback servo-thread
addf mux2.0 servo-thread
addf mux2.1 servo-thread
addf pid.x_pos.do-pid-calcs servo-thread
addf pid.y_pos.do-pid-calcs servo-thread
addf pid.z_pos.do-pid-calcs servo-thread
addf pid.w_pos.do-pid-calcs servo-thread
#addf hm2_5i25.0.pet_watchdog servo-thread
addf and2.0 servo-thread
addf hm2_5i25.0.write servo-thread
----- Original Message -----
Sent: Friday, June 23, 2017 11:55:58 AM
Subject: Re: [Emc-users] following error only while homing

Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
Here are links to a halscope screen shot and log file for my servo machine that keeps setting following errors on first try homing.
homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc

Because the scale of the position command is so huge its hard to tell whats
going on but the ferror size matches the encoder step size at index, This (and
the one cycle ferror duration) suggests that there is a thread/operation order
issue of some kind in the hal file.
Peter Wallace
Mesa Electronics
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

[Todd Zuercher]

I just ran another test with the pid index-enable disconnected for that axis, and the halscope trace looks exactly the same as it does when it is connected.
Is there something wrong with that pin in the pid component or is this a symptom of my ordering problem?

----- Original Message -----
From: "Todd Zuercher" <***@embarqmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Friday, June 23, 2017 1:20:26 PM
Subject: Re: [Emc-users] following error only while homing

That is what I've suspected but I can't figure out what I have out of place.
I did another screen shot with the position-cmd zoomed in as much as I could and keep it on the screen.
It seems that the index enable falls, and the encoder position is reset,then the PID gets whacked for one servo period, then the position-cmd is reset.
I have the PID index-enable pin connected, but I not sure it is actually doing anything.

Here are my addf orders:

addf hm2_5i25.0.read base-thread
addf pid.x_vel.do-pid-calcs base-thread
addf pid.y_vel.do-pid-calcs base-thread
addf pid.z_vel.do-pid-calcs base-thread
addf pid.w_vel.do-pid-calcs base-thread
addf hm2_5i25.0.write base-thread

addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf sum2.0 servo-thread
addf offset.0.update-output servo-thread
addf offset.0.update-feedback servo-thread
addf mux2.0 servo-thread
addf mux2.1 servo-thread
addf pid.x_pos.do-pid-calcs servo-thread
addf pid.y_pos.do-pid-calcs servo-thread
addf pid.z_pos.do-pid-calcs servo-thread
addf pid.w_pos.do-pid-calcs servo-thread
#addf hm2_5i25.0.pet_watchdog servo-thread
addf and2.0 servo-thread


----- Original Message -----
From: "Peter C. Wallace" <***@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Friday, June 23, 2017 11:55:58 AM
Subject: Re: [Emc-users] following error only while homing

Date: Fri, 23 Jun 2017 11:21:15 -0400 (EDT)
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: Re: [Emc-users] following error only while homing
Here are links to a halscope screen shot and log file for my servo machine that keeps setting following errors on first try homing.
homing-error.png: https://drive.google.com/open?id=0B6U6HVQUOa1fZndtbzVRU1dpOW8
halscope-homing.log: https://drive.google.com/open?id=0B6U6HVQUOa1fbmk5S1dKaFBoWWc

Because the scale of the position command is so huge its hard to tell whats
going on but the ferror size matches the encoder step size at index, This (and
the one cycle ferror duration) suggests that there is a thread/operation order
issue of some kind in the hal file.


Peter Wallace
Mesa Electronics


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Todd Zuercher]

----- Original Message -----
From: "Peter C. Wallace" <***@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Friday, June 23, 2017 2:13:45 PM
Subject: Re: [Emc-users] following error only while homing

Post by Peter C. Wallace
Yeah, those are ordered wrong so LinuxCNC's patching aound the encoder step on
index fails, but I'm not sure they can be ordered correctly with your mixed
(base/servo) thread setup. A normal servo thread only config would be
something like

Here is a halscope plot of the same pins for the Z axis (which rarely messes up), compared with the one for the W axis which almost always doesn't work.

In the Z plot the motor-pos-cmd changes on the 1st servo-thread cycle after the index. But the W motor-pos-cmd change is on the next servo-thread after that, worse yet the following error for the W appears to be delayed yet another thread cycle.

What's up with that? I am not getting real time delay messages on this machine either.

[Todd Zuercher]

So I guess my real question is why does it work on one axis and not the next?
What are the chances that switching to Master and dumping the 5 dummy axis between joints 2 and 8 might help?

----- Original Message -----
From: "Todd Zuercher" <***@embarqmail.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Friday, June 23, 2017 5:07:42 PM
Subject: Re: [Emc-users] following error only while homing

----- Original Message -----
From: "Peter C. Wallace" <***@mesanet.com>
To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
Sent: Friday, June 23, 2017 2:13:45 PM
Subject: Re: [Emc-users] following error only while homing

Post by Peter C. Wallace
Yeah, those are ordered wrong so LinuxCNC's patching aound the encoder step on
index fails, but I'm not sure they can be ordered correctly with your mixed
(base/servo) thread setup. A normal servo thread only config would be
something like

Here is a halscope plot of the same pins for the Z axis (which rarely messes up), compared with the one for the W axis which almost always doesn't work.

In the Z plot the motor-pos-cmd changes on the 1st servo-thread cycle after the index. But the W motor-pos-cmd change is on the next servo-thread after that, worse yet the following error for the W appears to be delayed yet another thread cycle.

What's up with that? I am not getting real time delay messages on this machine either.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users