Bridgeport TorqueCut-22 Conversion

18 Apr 2024 19:49 #298571 by arsenix
I posted about this machine before ( 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.

Please Log in or Create an account to join the conversation.

19 Apr 2024 17:43 #298636 by andypugh
The only real reason to use the Mesa UARTS is if you need realtime control.

This is probably useful for controlling the spindle on a lathe, where CSS has the spindle speed constantly varying, but is largely unecessary on a mill where the spindle speed stays the same between tool changes.

If you wanted a much bigger project you could consider adding FPGAs to your board and using the Mesa firmware to make your own mega-mesa-card. (This has been done). Or you could do it the way you describe and probably get it finished.

Please Log in or Create an account to join the conversation.

20 Apr 2024 14:52 #298733 by arsenix

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 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."

Please Log in or Create an account to join the conversation.

20 Apr 2024 17:04 #298741 by andypugh
The LinuxCNC PID component has a "feedback-deriv" pin which is intended to be driven by encoder velocity. I think that works on the D term, but check the docs to be sure.

Please Log in or Create an account to join the conversation.

20 Apr 2024 20:49 #298749 by arsenix
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.

Please Log in or Create an account to join the conversation.

22 Apr 2024 15:41 #298847 by arsenix
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))] }

  • DigF = Digital Filter
  • DBF = Dead Band Function
  • PLmt = Dynamic Pwm Limiter
  • (PWMax current limiter)
  • OLrnt =Overall Limiter (Bound PWM to limits)
  • 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)

Please Log in or Create an account to join the conversation.

22 Apr 2024 20:57 #298867 by andypugh
If VG is actually Velocity _command_ gain, then it is the same as FF1.
The following user(s) said Thank You: arsenix

Please Log in or Create an account to join the conversation.

20 May 2024 21:55 - 20 May 2024 22:07 #301038 by arsenix
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.
Last edit: 20 May 2024 22:07 by arsenix. Reason: screwing with the image!

Please Log in or Create an account to join the conversation.

Moderators: cncbasher
Time to create page: 0.128 seconds
Powered by Kunena Forum