Encoder feedback with closed loop servo drivers?

Hello together,

I'm currently planning a linuxcnc based controller for a 6-axis robot arm. All axes are driven by AC synchronous motors with a quadrature encoder attached.

As I'm designing the drivers myself I opted to use the Trinamic TMC4671 as the controllers. As these are FOC capable the encoders will be connected to the drivers directly, closing the loop in the drivers instead of linuxcnc.

But here comes the part I need some guidance with. As I plan on using a mesa-card to interface the drivers, sensors, etc. it only sounds reasonable to also attach the encoders to the mesa card, allowing linuxcnc to monitor the precise rotation of the axes.

Now as far as my understanding goes, I can't have two closed loop controllers at the same time. I must close the loop in the driver or I'm losing the posibility for FOC. I can't attach the drivers over serial (UART/SPI) to use the absolute position commands they support. But then I'm only left with a STEP/DIR interface, which can potentially lose steps on the signal path, which would go undetected.

What would you say is the best way to solve this?

tommylight wrote:

Pretty sure it is possible to have the loop closed on the drives and LinuxCNC
 

Do you have any ressources on this? It would be really great if this is possible.

Adding additional encodes would also be extremely difficult, as this is an old industrial robot. But the encoders attached to the motors have a really good resolution of 2400 steps per revolution and the gearboxes have literally no backlash at all.

About the speeds and acceleration: The Robot was easily capable to throw itself through a wall if not firmly attached to the floor. And that was with with the original controller from the 80s. The new drivers will surely be more powerful and efficient than the original ones. So I see no problems arising on the mechanical or electrical layer. (More so some safety problems, but those are already solved and the bot will move way slower than it could)

Ok, I might have found a solution that closes the loop in linuxcnc without sacrificing FOC, though I'm not so sure if this might result in a loss of precision.

The drivers also support torque and velocity mode via PWM or analog. Analog seems like a bad idea, as the input range of the driver is only 0-3.3V and the noise floor in the cabinet will be quite high. Torque mode could be a problem as especially the lower axes move a lot of shifting weight which could make live difficult for the PIDs.

That would only leave velocity mode over PWM, but I suspect that this would lose me quite some precision, as attaching the drivers with STEP/DIR should give me a positional accuracy of half the (interpolated) encoder resolution.

Also I'm not sure if the mesa cards (currently looking at the 7I95) kann output this type of PWM signal.

FOC (Field Oriented Control) means controlling the direction of the magnetic field in the motor based on feedback from its back-EMF; the drive shouldn't need encoder feedback for this. FOC is basically an efficient torque control. (Although an absolute encoder, or hall sensors, helps with startup/very low speed operation, and an encoder can be used for sanity-checking/augmenting the internal field calculations at speed.)

Also, step/dir control in LinuxCNC is usually really a velocity control: the interface card (Mesa or whatever) sends a stream of steps to the drive that corresponds to a certain velocity. The velocity signal is produced by a PID controller in LinuxCNC and sent to the interface card, or to the step ("base") thread for parallel cards.

The only true position control I know of (doesn't say much perhaps ) is with EtherCAT drives: these take an actual position command and it's entirely up to the drive how to get there.

So the natural solution in your case would be to run it just like any step/dir system, with the position loop closed by LinuxCNC and the velocity and torque loops closed by the drive. If the drives require encoder feedback, it's for some other reason than FOC.

Yes, usually you don't need encoder feeedback for to the driver for FOC, but in this case it is necessary. For once the trinamic driver I selected actually prefers a high precision encoder over a simple hall effect sensor (which is also provided by the encoders).

The main reason it's needed in my application is that we are talking about slow, precise movements of a rather large and heavy robot arm (around 1.5m reach and an estimated total weight of around 150-200kg). There are situations when the load on a motor will change without it actually moving. So back-EMF will often be unusable. And if I only rely on the (digital) hall effect sensors I don't have enough precision when holding a position (hall effect only has a resolution of 1/3 to 1/6 of a degree, depending on the axis).

I'm aware that STEP/DIR is in a way a speed signal. But when using this control mode what the driver does is increment/decrement an internal position counter and then turning those to speed controls in an internal PID.

So when I close the loop in linuxcnc, I still need to attach the encoder to the driver. But when I then send step pulses to the driver I have both linuxcnc and the driver both calculating a PID for the speed, which will most likely result in some form of oscillation or overshooting.

I'm no expert with encoders but look at closing the velocity mode and position mode  in the drive/lcnc

It works perfectly find to also have encoder feedback to Linuxcnc on a step/dir commanded servo. (I am running a machine set up that way now.) And it does not cause any osculations. When using a Mesa card Linuxcnc is usually configured with a PID loop to close the position loop of the step generation anyway. In a normal open loop step/dir Mesa config, Linuxcnc sends a velocity signal to the Mesa card using a PID loop, then the Mesa card uses the velocity command to generate pulses and counts the pulses generated, then sends the pulse count back to Linuxcnc where that pulse count is used to close the PID loop. If you add an encoder to the system, you simply replace the pulse count from the hardware stepgen with the pulse count from the encoder. You will then have to tune the PID in Linuxcnc, because the encoders responce won't be the perfect one of the stepgen. but it still works quite well.