Advanced Search

Good to hear. I'd suggest slowing down the SPI comms like in the discussion above.

hal
loadrt remora-spi SPI_num=0 CS_num=0 SPI_freq=2000000

ini
#SERVO_PERIOD = 1000000
SERVO_PERIOD = 5000000

Did the subroutine execute?

You could run

halcmd show signal s-index-zero-for-ATC

From the command line to check

No, the actual index pin is not typically used by LinuxCNC

What interface card are you using for the encoder interface?

Is the encoder single ended or differential?

Is  the interface card jumpered to match the encoder type?

Another way to check the low level hardware is to set the index input to
single ended mode, and then watch hm2_7i80.0.encoder.00.input-index
in halshow as you ground the index input on the interface card.
hm2_7i80.0.encoder.00.input-index  should change state when you ground
the +index input pin

(with the encoder unplugged of course)

 

FF0,FF1,FF2 are feed forward terms

FF0 adds a proportion of the PID command to the PID output
FF1 adds a proportion of the PID commands first derivative to the PID output
FF2 adds a proportion of the PID commands second derivative to the PID output

For a simple example imagine a spindle control PID loop
This would have a PID loop with velocity command and velocity output.
Setting FF0 to 1 means that at a say commanded RPM of 3000,  means
that the PID output would be 3000 without any correction from the PID error
term. You can think of the FF terms as a way of centering the operating
point of the PID loop around the current state (rather than having
feedback have to do all the heavy lifting)

 

No, it does not.
I scrolled through the HAl and could not find the hm2_7i80.0.encoder.00.input-index pin linked anywhere. So I assume Linuxcnc does not get this signal- can this be the reason?

If you set x-index-enable high manually, does it get cleared if you jog the axis? 
(enough for one full turn of the encoder)

Beware, this may trigger a following error