Bridgeport TorqueCut-22 Conversion

I posted about this machine before (forum.linuxcnc.org/10-advanced-configura...32-conversion#253308) but am getting serious about converting it. Since that post years ago I've worked in/around the control pretty extensively and know it back and forth. Although it works just as well as it did when it was delivered in 1998 I'm tiring of the lack of a real trajectory planner (bad stuttering on surfacing and adaptive toolpaths) and the lack of any automated probing cycles. The latter is mostly just a convenience feature but the former really sucks a lot of my time. A set of parts I was running a few weeks ago took at least two hours of additional spindle time due to stuttering. It can be reduced with enough tool path adjusting and smoothing but that also sucks time!

My thought is to build a wiring PCB that is essentially a 1:1 replacement for the "BMDC" board that is the heart of the "DX32" control on the machine. The control is quite well documented including the order of operations for tool changes, spindle gearbox changes etc. Use its existing PWM DC servo amps (essentially PWM torque mode control, but no smoothing essentially just driving IGBTs directly) and existing auxilliary boards that do higher voltage GPIO outputs (the AUF and LcTLAUF boards). The latter are connected via dedicated RS422 serial interfaces. My hope is that if I finish this others could use this PCB to very easily do "no wiring" conversion on similar machines or any of the many Bridgeport mills/lathes that used the DX32 control. These are great machines and they are very cheap due to their antiquated control. No one remembers how to use DOS apparently! It has been a fine "garage VMC" for me complete with seamless wifi network connectivity, rigid tapping, probe scanning and other features that many machines from the 90's lack.

The BMDC board has:

1. 11x low voltage GPIO inputs (used for front panel controls)
2. 4x Analog inputs (for 2x speed override pots and a spindle load feedback signal)
3. 5x Analog outputs (only one is used on my machine for spindle control)
4. 1x MPG encoder input for the jog dial
5. 2x low side power drivers (1A) for the ESTOP and the spindle gearbox
6. 2x RS422 serial ports for connecting to the AUF (auxilliary functions) and LcTLAUF (Tool Changer) boards
7. 4x PWM differential outputs for axis torque control - RS422 levels @25 khz
8. A few additional GPIOs to enable and reset the servo amps
9. 5x RS422 level differential encoder inputs

All of the above connections leave the board through 2x 50 pin ribbon cables and 4x 10 pin ribbon cables (for the 4 supported axes). My PCB will have these on them so the original wiring can plug right in.

My thought is to use the following MESA boards

• 6i25 - PCIe FPGA card
• 7i52 - Six channels of encoder input and RS422 output - For #4, #7, #8, #9 - Essentially all the axis controls as well as the front panel MPG
• 7i66-8 - Use this for the analog inputs, GPIOs, power drivers (#1,#2, #5). Hooked to the 7i52 via SSERIAL
• SPINX - Single PWM->Analog channel for the spindle control. Hook this to one of the outputs on the 7i52. I might leave empty spots for more of these since some machines that used the BMDC (including lathes) used Analog servo amps instead of the PWM control.

For the RS422 ports I was thinking I'd just put some additional RS422 serial ports (PCIe) on the PC.

A few questions I was hoping to ask here:
1. For the RS422 controlled AUF and LcTLAUF boards I am fairly certain I can reverse engineer the protocol. I was thinking I'd write a simple HAL module to talk to these. I noticed that there was now a way to do serial ports directly through the Mesa boards (pktUart). Would using this be preferable and/or easier than just using a standard serial port? In general these outputs are all "low speed" such as running coolant, air solenoids, etc.
2. I assume the analog input pins on the 7i66-8 will be adequate resolution for reading some pots? The spindle load is a pretty noisy/rough signal anyways.
3. Will setting up the gains for the direct control of the DC servo amp IGBTs be difficult? The past LinuxCNC conversions I have done used analog velocity control so it was pretty straightforward (FF1, some P). The DX32 manual has a fairly extensive discussion of the BMDC PWMINT control loops including a digital filter to reduce vibrations from the PWM drive. The manual says this is to remove quantization noise caused by the encoders are very low speeds. I assume this is fairly similar to using a Mesa 7i29, which folks have done (although it seems uncommon). One reason I'm thinking about using the original amps is that if they ever died I could then fairly easily replace them with 7i29(s).

Any other feedback on my "design" is welcome! I'm sure this will evolve as I go through it. It is also likely I might want some additional monitoring on the machine that the old control left out. As with many older machines like this they were clearly limited by their GPIO inputs and consequently many faults with the machine don't have clear error messages and can be difficult to interpret.
 

andypugh wrote:

Don't tempt me.   As an engineer this approach is dangerously appealing. I have no idea if there are enough DX32-powered machines out there to warrant that but it is conceivable. Bridgeport made a lot of machines (mills, lathes, grinders) using this control. Many of them aren't as well documented as my TC22 though so supporting them all would likely be a challenge.

Your comment about the serial ports makes sense. On this machine those outputs are all certainly "soft real time" at best. A normal serial port is adequate.

I realize now that the "duty cycle control" here is not the same as torque control, since it must compensate for the back EMF. Obvious in retrospect and this also explains why I was having trouble tuning my 4th axis based on this signal. The Bridgeport documentation explains their control methodology in depth. The control generates what they call a "Virtual PWM" based on the encoder velocity feedback that is translated into a nominal PWM. It has parameters for the encoder counts, volts/rpm and maximum voltage that are used to scale this value. The PID loops then add onto this value.

What is the best way to setup a duty cycle controller like this in LinuxCNC? The PID elements mention that FF1 can be used to compensate for back EMF, but FF1 is based on the derivative of the command and not the motor true velocity right? There are a number of servo amps like this that folks have used (the Mesa 7i29 and the Pico Systems PWM Servo Amps) but not a lot of info about how folks set them up.

Looking at linuxcnc.org/docs/stable/html/drivers/pico-ppmc.html it seems like the Pico Systems driver is doing something like this. Ie "Velocity scaled in user units per second." ... "This can be fed to the PID HAL component to produce a more stable servo response."
 

I suppose I could implement it exactly how the Bridgeport controller does. Add a scaled velocity component to the output of the PID controller before the pwmgen. In the original controller they are doing all of this in hardware (one reason it is all integer math) every 250uS. Surprisingly there seems to be almost enough technical information in the TC22 manual to re implement the whole control servo control loop.

This is how the Bridgeport manual explains how they calculate the PWM command (added to the "Virtual PWM" which compensates for back EMF). They are just using three different gains in a velocity loop. Seems like they correspond to FF1, P and D to me. Seems like if I work through changes in the scaling I can probably use the control's existing gains as a starting point in LinuxCNC? This seems straightforward enough.

PwmCmd(t) = OLmt{ PLmt[ DBF( 
     DigF( ((Vel(t) * VG) +(FE(t) * FeG) +(DFe * DFeG)))/(2"SG))] }
let:

• DigF = Digital Filter
• DBF = Dead Band Function
• PLmt = Dynamic Pwm Limiter
• (PWMax current limiter)
• OLrnt =Overall Limiter (Bound PWM to limits)

where:

• Vel = Commanded Velocity (CUMs/Tick)
• VG = Velocity Command Gain   (This is equivalent to FF1?)
• FE = Following Error (CUMs)
• FeG = Following Error Gain    (Equivalent to P gain)
• DFe = Differential Following Error
• DFeG = Differential Following Error Gain   (Equivalent to D gain)
• SG = Overall Servo Gain (integer shift amount)

I did some prodding of the interfaces over the weekend. This machine has two auxilliary I/O boards called the "AUF" (auxilliary functions) and the "LCTCAUF" (Low Cost Tool Change AUF), both of which are connected over serial. The maint manual describes the interface to these but there are already some discrepancies. The manual said they were 9600 bps and used RS485 in a multidrop config. They clearly use 38400bps and are RS422 with independent TX/RX pairs to either board. The boards appear to support RS485 but this machine doesn't use that configuration. If more than two are required maybe it was supported.

In any case the protocol was not as obvious as I was hoping. In both cases the units send packets to each other that start with a unique packet magic byte (0x23 or 0x29 for the AUF and 0x26 for the LCTLAUF), payload bytes that all appear to be 0x3_ or 0x6_ and some sort of checksum byte that is always 0x4_. The packets are firing at about 50Hz. The 4 bit "checksum" appears to be additive in some way but I have not been able to discern the algorithm used. Turning the coolant on off caused a single bit to flip on the outbound packet to the AUF as well as a change in the checksum byte. The LCTLAUF has a fairly small outbound packet but also has a counter in the packets for some reason. Decoding all the error states in particular might be a challenge. An AUF packets at startup for the curious:
 

Although elegant to reverse engineer these and have a "wiring free" conversion I'm sure it would be easier to replace or modify these boards with Mesa Smart Serial I/O endpoints. It is quite nice to be able to switch back and force between controls though easily especially if the conversion takes a while. Something to ponder.

I fairly recently did a retrofit on a Bridgeport R2E3 mill. I think it is one generation earlier than the machines with the BMDC, but the servo side is fairly similar. My machine had Contraves NC400 servo amps that make a maddening whine, so I replaced them with AMC brush-type servo amps. I used the original motor/tach units, and originally used the stock encoders, too. These encoders were 250-line resolution. They caused some servo hunting noise, and one unit was contaminated. So, I eventually replaced all the encoders with eBay knockoffs labeled Omron, with 2500 line resolution. I used my own PPMC interface board set (full disclosure - I make these as Pico Systems). I also added a spindle encoder so I can do rigid tapping. It all works incredibly well!
After some issues with properly programming a cheap Chinese VFD, I ended up getting an Automation Direct unit that came with a real manual.
Jon