Index Homing odd offset

The tool change position changes. Which is absolute and does not change with any offsets...and so does the position of a 4 Inch stackup on the mill table (according to my probe)

When I rehome and do the checks... the new position repeats to within 0.002mm.

I am using inductive sensors as the initial home signal trip. Could it be that the sense position is changing? Would debounce help? But that makes no sense?

Oh... I'm always measuring in G59.3 offset with the probe

I have absolute encoders on my drive servos. I initially wanted to forgo homing by
using the absolute encoders but realised that linuxcnc does not track the absolute encoder empirically. So if ,for example, my z would fall a bit while brake was applied when shutting down, linux would not track that.

That is when decided to use index homing instead.

Then realised I need to use closed loop step gen for index homing to work.
I subsequently setup and tuned my system for closed loop using position control step gen.

I got index homing to work (or so I though). The issues I describe above ensued. Hence the questions around Step gen in position control vs velocity control.

After some trouble shooting it turns out that my servo drives being setup for absolute encoders could be the issue. It seems that when in absolute encoder mode, it doesn't pass the actual index through to linux but rather an inferred index (which could vary in position).Well that is my theory anyway.

Ive set my servo drives up to use the absolute encoders as incremental encoders and that seems to have solved the issues i was having (holding thumbs)


Does this seems like it could have been a reasonable cause?

I am assuming index homing works for stepgen systems setup in position control , closed loop?

Thanks guys. Hopefully my experience helps someone down the line.

If they are absolute encoders, and if LinuxCNC receives the absolute data, then this would be the best way to work.
How are you getting the encoder feedback back to LinuxCNC?

Im using a 7i77 Mesa card to input the encoder signals. See attached picture. PA, PB and PC. PC is the index signal. Not sure how to send the absolute data to Linux. There is a serial output for the encoder as well but not sure how this would work. I'm not sure how this will help anyway since apparently Linux doesn't track the absolute encoder anyway... I'm told it simply saves the current position in a position file and reloads that position on startup. If the encoder moved during shutdown (tracked by the drive and abs encoder) linux will not know. (or am I wrong?)




What does your HAL look like for this? I didn't think that that worked (maybe you have proved that it doesn't work?)

#*******************
# AXIS X JOINT 0
#*******************

setp pid.x.Pgain [JOINT_0]P
setp pid.x.Igain [JOINT_0]I
setp pid.x.Dgain [JOINT_0]D
setp pid.x.bias [JOINT_0]BIAS
setp pid.x.FF0 [JOINT_0]FF0
setp pid.x.FF1 [JOINT_0]FF1
setp pid.x.FF2 [JOINT_0]FF2
setp pid.x.deadband [JOINT_0]DEADBAND
setp pid.x.maxoutput [JOINT_0]MAX_OUTPUT
setp pid.x.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
#setp pid.x.maxerror 0.012700


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

# Step Gen signals/setup

setp hm2_7i76e.0.stepgen.02.dirsetup [JOINT_0]DIRSETUP
setp hm2_7i76e.0.stepgen.02.dirhold [JOINT_0]DIRHOLD
setp hm2_7i76e.0.stepgen.02.steplen [JOINT_0]STEPLEN
setp hm2_7i76e.0.stepgen.02.stepspace [JOINT_0]STEPSPACE
setp hm2_7i76e.0.stepgen.02.position-scale [JOINT_0]STEP_SCALE
setp hm2_7i76e.0.stepgen.02.step_type 0
setp hm2_7i76e.0.stepgen.02.control-type 1
setp hm2_7i76e.0.stepgen.02.maxaccel [JOINT_0]STEPGEN_MAXACCEL
setp hm2_7i76e.0.stepgen.02.maxvel [JOINT_0]STEPGEN_MAXVEL

# ---closedloop stepper signals---

net x-pos-cmd <= joint.0.motor-pos-cmd
net x-vel-cmd <= joint.0.vel-cmd
net x-output <= hm2_7i76e.0.stepgen.02.velocity-cmd
#net x-pos-fb <= hm2_7i76e.0.stepgen.02.position-fb
net x-pos-fb => joint.0.motor-pos-fb
net x-enable <= joint.0.amp-enable-out
net x-enable => hm2_7i76e.0.stepgen.02.enable

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

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


net x-encpos-fb <= hm2_7i76e.0.encoder.01.position
net x-vel-fb <= hm2_7i76e.0.encoder.01.velocity
net x-pos-fb => joint.0.motor-pos-fb
net x-index-enable joint.0.index-enable <=> hm2_7i76e.0.encoder.01.index-enable
net x-pos-rawcounts <= hm2_7i76e.0.encoder.01.rawcounts




LinuxCNC relies on the encoder counts resetting to zero at the index, and then the next counts read being the motion that has happened since index. This is a feature of the encoder counter, though, not the encoder itself.

How do you get the encoder position data into LinuxCNC.

See Above

That seems like a waste.
I know right!


Not as far as I know... Hence the changes to stepgen to reset on index.
I don't even know what you mean by "position mode, closed loop". Do you mean that you have a PI~D driving the stepgen with the encoder as the feedback?[/quote]

stepgen has two control modes, which can be selected on a channel by channel basis using ctrl_type. Possible values are "p" for position control, and "v" for velocity control. The default is position control, which drives the motor to a commanded position, subject to acceleration and velocity limits. Velocity control drives the motor at a commanded speed, again subject to accel and velocity limits. Usually, position mode is used for machine axes. Velocity mode is reserved for unusual applications where continuous movement at some speed is desired, instead of movement to a specific position. (Note that velocity mode replaces the former component freqgen.)

That's what I mean by position control. "p" for position control vs "v" for velocity control. I may have been confused by the term "velocity mode" ... that is apparently required for Index Homing?
My machine is currently working the way I have it set up. Its receives feedback from the encoder and uses that feedback loop. Ive checked my following error on Halscope and it goes up to 0.01mm at most.

Index homing also seems to be working now that Ive changed my drive to use the encoder as an incremental encoder.

If you have any other insights and the community would benefit from any more info I can give then please let me know.

I'm sorry. Pasted the wrong Hal file. It had the same name but different version number.

This is my Latest HAL. The old one still had :
net x-encpos-fb <= hm2_7i76e.0.encoder.01.position

This is the Latest.

#*******************
# AXIS X JOINT 0
#*******************

setp pid.x.Pgain [JOINT_0]P
setp pid.x.Igain [JOINT_0]I
setp pid.x.Dgain [JOINT_0]D
setp pid.x.bias [JOINT_0]BIAS
setp pid.x.FF0 [JOINT_0]FF0
setp pid.x.FF1 [JOINT_0]FF1
setp pid.x.FF2 [JOINT_0]FF2
setp pid.x.deadband [JOINT_0]DEADBAND
setp pid.x.maxoutput [JOINT_0]MAX_OUTPUT
setp pid.x.error-previous-target true
# This setting is to limit bogus stepgen
# velocity corrections caused by position
# feedback sample time jitter.
##setp pid.x.maxerror 0.012700

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

# Step Gen signals/setup

setp hm2_7i76e.0.stepgen.02.dirsetup [JOINT_0]DIRSETUP
setp hm2_7i76e.0.stepgen.02.dirhold [JOINT_0]DIRHOLD
setp hm2_7i76e.0.stepgen.02.steplen [JOINT_0]STEPLEN
setp hm2_7i76e.0.stepgen.02.stepspace [JOINT_0]STEPSPACE
setp hm2_7i76e.0.stepgen.02.position-scale [JOINT_0]STEP_SCALE
setp hm2_7i76e.0.stepgen.02.step_type 0
setp hm2_7i76e.0.stepgen.02.control-type 1
setp hm2_7i76e.0.stepgen.02.maxaccel [JOINT_0]STEPGEN_MAXACCEL
setp hm2_7i76e.0.stepgen.02.maxvel [JOINT_0]STEPGEN_MAXVEL

# ---closedloop stepper signals---

net x-pos-cmd <= joint.0.motor-pos-cmd
net x-vel-cmd <= joint.0.vel-cmd
net x-output <= hm2_7i76e.0.stepgen.02.velocity-cmd
##net x-pos-fb <= hm2_7i76e.0.stepgen.02.position-fb
##net x-pos-fb => joint.0.motor-pos-fb
net x-enable <= joint.0.amp-enable-out
net x-enable => hm2_7i76e.0.stepgen.02.enable

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

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


net x-pos-fb <= hm2_7i76e.0.encoder.01.position
net x-vel-fb <= hm2_7i76e.0.encoder.01.velocity
net x-pos-fb => joint.0.motor-pos-fb
net x-index-enable joint.0.index-enable <=> hm2_7i76e.0.encoder.01.index-enable
net x-pos-rawcounts <= hm2_7i76e.0.encoder.01.rawcounts





I have absolute encoders on my drives and was attempting to use them in absolute encoder mode (outputting PA,PB and PC from the Drive to my 7i77 where Pc is supposed to be the index). That did not work. I changed the drive setting to use the absolute encoder as an incremental encoder (there is a setting in the drive for that - it does the serial conversion to pulses internally to output PA,PB,PC). The index homing seems to be working now.

Is there a "how to" on using the serial data to input to linux via Mesa cards?