Dual PID loops with motor encoder + scale encoder per axis

I don't think your home switch will work. Home switches need to stay triggered until the end of travel. This lets Linuxcnc which direction to travel to find the triggering edge. I predict some big crashes under the current config.

Hi Rod,
Unless I'm missing something, I'm not sure I follow your concern. The switches are located at the end of travel on each end of the table. They stay active for at least 10mm of table travel beyond their initial trigger point. They're positioned as limit switches really, but I should be able to home off of the left one as well.

I know it looks like there's more travel on my Bridgeport table beyond the switches, but it's not actually usable travel. The motor mount interferes with the saddle on the left side which makes a physical limit. On the right side, the bearing casting does clear into the saddle, but this travel isn't really usable as the X axis gage wheel sensor runs off the end of the table, meaning the X axis DRO stops working. The usable travel at each end is essentially where the edge of the table lines up with the edge of the saddle on the respective side, ~24 inches total.

      

I must admit that I'm no longer sure what we're debating.  But here's a reflection of my current understanding.

The original motors do not have an analog tacho, but they do have a digital incremental encoder.  The drive hardware appears to be an open-loop H bridge that is PWM controlled.  The motor encoder does not connect to the drive hardware, but it did connect to the original microcontroller-based control unit.

Other than when stopped, the open loop drive hardware seems to act like a velocity drive.  Commanded PWM value correlates to speed, not torque.  It is not commanding the drive to output a current, it's commanding the drive to output a voltage. 

When stopped with a 0 PWM command, it does appear to be a bit like a torque drive in that the shaft can be rotated (though there is some resistance as you try to spin it quickly). 

However, in the original system, there was a control loop running on the microcontroller that took take the place of the tacho feedback in your drawing, and if it "saw" motor encoder movement when stopped, it would command a PWM value to try to maintain the zero position.  And likewise when moving, it could more closely control the rotational speed to the commanded value by monitoring the encoder in the control loop.

If my understanding is correct, as a system, the original inner loop probably acted like a proper velocity drive, but the feedback was implemented with a digital encoder and a control loop in firmware instead of with analog tachos and op amps.  If we focus on just the hardware portion of the drive as we have been, it's really not exactly a velocity drive (but it is similar), nor is it a torque drive (except it kind of looks like one when commanded to stop).

 

  It is not commanding the drive to output a current, it's commanding the drive to output a voltage. 


 

The voltage is what produces the current. No voltage - no current.

A velocity mode drive rotates the shaft at an RPM that is proportional to the command signal based on the velocity-gain setting.
They are rate devices.

With zero command, the negative-feedback will fight any attempt to rotate the shaft by hand.

If you attempt to drive this motor with only the P-term (I=0,D=0), it will overshoot.

Craig
 

But if it was a torque mode drive as you seem to suggest, for a given commanded PWM value the motor current should NOT increase when the motor is mechanically loaded, and it very demonstrably does, by significant amounts.