Refitting a TORCAM CNC lathe controller

It’s been an interesting three weeks since Part 2 (and before that, Part 1) of this project to reverse engineer and make operational a twenty year old CNC lathe and mill at my favourite local high school.

If you like anything about the video above, we can all thank my son Calder. Upon showing him an early version of the video, me: “Well?” Him: “Needs to be much shorter and you need to point out what you’re talking about.” I like that clarity of feedback.

The TL;DR: I’ve constructed a functional adapter cable to connect a standard PC parallel port to the proprietary 25-pin data port on the TORCAM controller. This should allow the school PC’s running Mach3 to control these tools. It’s time to take this rig back to the classroom and try driving the actual lathe and mill rather than just my test motors.

Of course the real fun was in the challenges so far. All the (re)learning, test rigs, and failures. Speaking of failures…

TORCAM_z-axis_problem-1

three weeks ago this setup looked like a slam dunk. Cable signal wires carefully redirected to appropriate pins. Unused-buffer inputs carefully grounded. USB-provided 5V on pin 13 to supply the internal buffers in the TORCAM box. Positive and negative tests on the cable passed. A little trial and error to correctly hook the TORCAM motor driver outputs to my stray-mutt test motors pulled out of some dumpster-trawled line printer years ago.

And it did work. Three or four successful test runs, being careful not to overheat the undersized motors. Then on with the hot glue for cable strain relief. Buttoned up the box. Shot the victory video, and then… the Z-axis started to freak out, stuttered, twitched, and then stopped completely. Hardware debug time.

TORCAM_z-axis_problem-2

I swapped the motors on the two axes, and Z motor ran fine hooked to X controller, so nothing wrong with the cable or motor. Tested resistance on DB-9 motor connector back to the pair of L6203 full bridge motor drivers. All good. Same test on the data pins 6 and 7, Z-axis step and direction.

TORCAM_z-axis_problem-5

Double-checked config of output pins in TurboCNC. It seemed unlikely that they would spontaneously change, but cosmic rays being what they are, I checked. Good.

TORCAM_z-axis_problem-4

Considered that ESD (electro-static discharge) may have possibly killed any and all chips in the mix. It’s the beginning of the nasty dry season when ESD is particularly well-positioned to pump a couple of kilovolts into a very necessary chip from a hapless fingertip. So I started probing voltages while manually setting pin values in TurboCNC. But that’s not a definitive test. The most bothersome ESD effect is where a gate sort of half dies. Not completely dead, but not up to it’s pre-ESD-incident ability to source/sink current. The high-impedance input of your otherwise trusty multimeter can be fooled by such a faker.

I started checking pins with the oscilloscope and wow! Although we’re theoretically talking about digital signals for control, everything is analog if you look closely enough. So much noise on all these lines. But the Z-step line was either flat-lined or a mess. That got me thinking that perhaps the parallel extension cable I was using was too long. There can be a fair amount of capacitance added by a 6-foot cable. And additional capacitance makes for sloppier digital signals, so I built…

TORCAM CNC 006

a much-shorter 18-inch parallel extension cable out of a couple of DB-25 connectors and an old IDE (remember that?) cable. A benefit of the additional mid-cable connector on that cable was that I could tap in between the laptop and CNC box to check signals as shown above. Pin 6 was still dead, so it was starting to look like I had killed the internal port buffer in the laptop. Logic low was about 0.7V and logic high was around 3.7V on most pins on the laptop except for pin 6. In the photo above, I put a series of pulses on the X and Z axis with an Arduino, trying to eliminate the laptop as a variable. Still had problems with the Z-axis. So I thought…

TORCAM_z-axis_problem-3

maybe I had fried one of the TORCAM 74HC240 buffers. I swapped two of these socketed chips inside the TORCAM box, but that didn’t solve the problem either.

TORCAM_z-axis_problem-2

This all led me to break the signal chain down into component parts again and test each one as best as I could. If you’re still with me, here’s the punchline: somewhere between soldering the adapter cable, testing it, and then hot-gluing it for strain relief, pin 6 had been shorted to ground. The heat from the glue must have softened up the connector pin housing, allow the pin to shift just enough to ground out. That certainly reaffirms the need to check and re-check.

I fixed up that short and hooked up a different old Win98 laptop, aaand… still a problem with the Z-axis. What? It would move, but much less smoothly than the X axis. Some cursory testing led me to believe that pin 6 had been hosed on this laptop as well. So, pulled laptop #3 from the junk bin, loaded on DOS, and then build…

TORCAM CNC 022

a very ugly intermediate buffer circuit out of some MC14050BCP CMOS hex buffers that I had in the parts bin. I first tried to do this on a solderless breadboard, but that just made matters worse; nothing worked. Committing to solder, I nailed down the X and Z step/dir signal pairs down, plus the spindle control on pin 8, powered it all from another USB power supply, and…

Now it all works smoothly and reliably. For fun, I fooled around with different frequency and acceleration rates for the two axes. After a couple of dozen test runs, both axes are still rockin’. I added a second MC14050 hex buffer the the board so I could use this same rig to drive the three axis mill, and pull in inputs like Emergency Stop, Limit, and four of the front panel buttons back to the PC just for fun in case we can configure those in Mach3.

All of this is why James Bastow laughed at me as I carried the TORCAM box out of the high school, declaring I would only spend a couple of hours on this project and call it quits. Right!

Back to school.

DW

This entry was posted in maker resource and tagged , , , . Bookmark the permalink.

4 Responses to Refitting a TORCAM CNC lathe controller

  1. NoseyNick says:

    I’m still pretty convinced you’re wasting time with the parallel port and would do better to ditch it completely, replace it with an Arduino… But hey, you’re having fun! 🙂

  2. dw says:

    Well Nick, I’ve been looking at the Arduino-based GRBL platform, especially as it relates to the recently released browser-based Easel design/CAM software. I think that’s a fantastic watershed in simplifying the whole toolchain and engaging new makers. The design side has been the missing link in all of this motion-controlled rapid prototyping from CNC machining to 3D printing. Creating parts designed by other people is good for a Hello World test, but for real utility makers need to be able to design the pieces they need. .I’ve got an Arduino on the bench (photo above) ready for GRBL so we can try that on the mill using Easel. If that works, we can have kids designing and cutting workpieces in 5 minutes, giving them a taste of the magic of rapid prototyping. As I understand it, GRBL does have some limitations in the G-code it can process, simply due to the Arduino’s limited processing power and memory. So with the ability to drive the lathe/mill either directly from Mach3 out a parallel port for more advanced operations, I think we’ll have all the bases covered. Thanks for the comment. DW

  3. Pingback: TORCAM CNC mill comes alive with Easel/GRBL | makebright

Comments are closed.