Advantage of closing the position loop in LinuxCNC

Thanks for all the opinions. 
I think I’m going to use a 7i76e for now and go with Step/Dir controlled Delta Servos. 

Moving the Schaublins axis by Hand is probably not necessary I think. But I never really thought about it before. 
If I’m going to encounter problems with the Index signal or want to be able to move the axis like tommylight likes, I can always add a 7i85 and use the encoder signal like arvidb does  

arvidb wrote:

You can have feedback to LinuxCNC without closing the loop there.

Yes, of course.
You can also set LinuxCNC to show the position from that feedback and use the other feedbacks for inner workings.

arvidb wrote:

And if I'm not mistaken LinuxCNC will internally set actual (i.e. commanded) position to fed back position while drives are disabled.

I do not think so, changing feedback while LinuxCNC is running would cause a lot of issues in a lot of situations.
But i am also sure that if inclined, it can be made to do just that.

arvidb wrote:

I do know that I can run my EtherCAT drives like that: the loops are closed in the drive (no pids loaded in HAL at all), I get actual position feedback from the drive (that works also when the drives are disabled), and there is no problem with turning the drives back on again after they've been moved; LinuxCNC keeps track of where they are also while disabled.

In that case, it is a closed loop system at the LinuxCNC side, also most probably loop is closed in the drives so LinuxCNC gets just the actual position.

tommylight wrote:

arvidb wrote:

And if I'm not mistaken LinuxCNC will internally set actual (i.e. commanded) position to fed back position while drives are disabled.

I do not think so, changing feedback while LinuxCNC is running would cause a lot of issues in a lot of situations.

It does, here is the code:

tommylight wrote:

arvidb wrote:

I do know that I can run my EtherCAT drives like that: the loops are closed in the drive (no pids loaded in HAL at all), I get actual position feedback from the drive (that works also when the drives are disabled), and there is no problem with turning the drives back on again after they've been moved; LinuxCNC keeps track of where they are also while disabled.

In that case, it is a closed loop system at the LinuxCNC side, also most probably loop is closed in the drives so LinuxCNC gets just the actual position.

No, the loops are closed only in the drives. That LinuxCNC receives feedback does not mean it's closing the loop since it does not use that feedback to produce a control signal. (It only outputs an open-loop position reference.)

I guess you could argue that it's kind of a time-shared control where the drive closes the loop while the servos are active and LinuxCNC closes the loop when the servos are inactive. But besides being a bit silly it also misses the point that you can get the performance benefits of closing the loops in the drives and still be able to move the joints by hand without any problems.

arvidb wrote:

How is this different from using feed forward in the drive's controller? (LinuxCNC's HAL pid component calculates the feed forward values reactively too, from the derivative of the command signal.)

The LinuxCNC PID had a "command-deriv" pin that can be connected to the joint motor velocity output for direct feedforward. ( joint.N.joint-vel-cmd )

I am controlling a robotic arm using a few servo motors
Sometimes it is necessary to disable the motors and move the arm manually. In this case, I want to receive the position change from the motor encoder.
Does anyone know how to do this?

Yes, you wire the "machine-is-enabled" or "amplifier-enable" pin to actual drive enable.
But first, are the encoders wired back to LinuxCNC in any way?