Index Homing odd offset

CNCCustoms wrote: 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.

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?

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.

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

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.

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.

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)

That seems like a waste.

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

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?

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.

CNCCustoms wrote: 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?)

That is not correct. It was correct a couple of versions ago, but is not the case now.
If you can get the absolute data into LinuxCNC then you can use it by using HOME_ABSOLUTE_ENCODER.
linuxcnc.org/docs/2.8/html/config/ini-co...t__lt_num_gt_section

What format is the encoder data in? The Mesa firmware knows how to interpret a few formats, SSI, BISS and Fanuc:
linuxcnc.org/docs/2.8/html/man/man9/host...%20Interface%20(SSI)

There is even an example of someone who appears to be using SSI encoders here: forum.linuxcnc.org/38-general-linuxcnc-q...rking?start=0#203460

I assume that 7i76e.0.encoder.01 really is the X encoder?

If you open Halscope you should be able to check that the encoder.01.position goes to zero when the index is seen.
At that point the pin joint.0.motor-offset should update.

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

I am confused now. How could you use index homing without an incremental encoder? Were you using absolute + index?

Anyway, part of the problem seems to be that nothing is driving the x-pos-fb pin (or, if there is, it isn't in the HAL you showed)
(and, yes, there is a duplicate line)

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?

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

Just to be clear, is that working properly? It looks OK.

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.

How is that mode different from quadrature + index incremental? Is that a mode that sends serial data on the ABZ lines at power-up? (LinuxCNC doesn't understand that.)

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

Not that I know of. I don't think it is all that hard, but you would need the right firmware on your 7i76E and probably a 7i74 board to connect the encoders.
I wrote the LinuxCNC part of the drivers, but without any absolute encoder hardware to test with.

Do you have any documentation on the format (logical and electrical) of the absolute encoder data?