XMODEM Baud Rate Mod for RC2014

Many users of the RC2014 retro computer have had difficulty getting XMODEM file transfers to work. At least part of the problem seems to be that the standard baud rate of 115200 bps is way too fast for the 7.3728MHz Z80 processor to handle. Unfortunately neither the MC68B50 ACIA used on the original RC2014 Serial I/O module nor the Z80 SIO used on the current Dual Serial SIO/2 module has an internal baud rate generator. Both boards simply feed the bus clock to the chip to generate a fixed baud rate of 115200 bps. This mod shows how to change the baud rate for one common RC2014 configuration, using the Dual Serial SIO/2 with the Dual Clock module.

The Dual Clock module generates two clocks. The CLOCK signal on pin 21 of the standard bus is used by the processor and related peripherals. The CLOCK2 signal on pin 21 of the enhanced bus is available for other uses. Each clock can be jumper-selected to a variety of rates, including divide-downs of the fast 7.3728MHz clock corresponding to standard baud rates down to 4800.

The Dual Serial SIO/2 module supports two serial ports. Port A is the primary port, wired to the RX and TX pins on the standard RC2014 bus, while Port B is wired to RXB and TXB on the enhanced bus. Port A is wired to always use the CLOCK signal from the standard bus. Port B uses the CLOCK2 signal from the enhanced bus. If the system doesn’t have a clock source connected to the enhanced bus, jumper JP1 on the Dual Serial SIO/2 module can be used to connect the two bus clocks together.

If we have both the Dual Clock module and the Dual Serial SIO/2 module, we can easily vary the baud rate of Port B by moving the clock rate jumper for CLOCK2 on the Dual Clock module. Unfortunately, lots of software (and some hardware, such as the Pi Zero Serial Terminal) assumes that Port A is the console port and also used for file transfer, so it doesn’t really help that we can set the baud rate on Port B. We can also vary the baud rate on Port A, again by moving the corresponding clock rate jumper on the Dual Clock module. Unfortunately, this changes the CPU clock as well, so as we slow down the baud rate we also slow down the CPU by the same factor. That doesn’t help with the problem that the CPU can’t keep up with the baud rate. We need to be able to lower the serial baud rate without slowing down the CPU clock. We will have to modify the wiring of the Dual Serial SIO/2 module to make this possible.

The SIO chip has five clock inputs. Pin 20 is the bus clock, which must be the same as the Z80 CPU clock. Pins 13 and 14 are the receive and transmit clocks for Port A. Pins 28 and 27 are the receive and transmit clocks for Port B. We need to separate pins 13 and 14 from pin 20, allowing pin 20 to remain connected to the CPU clock on the standard bus. Then we will need to connect pins 13 and 14 to some slower clock source.

We could choose to add a new baud rate generator for Port A. If we copied the divider circuit from the Dual Clock module, we’d need three ICs and a 2×10 header, which would be a lot of circuitry to bodge onto the Dual Serial SIO/2 board. Other circuit designs might be smaller, but still painful to add to the board. Let’s just use the existing clocks already available from the Dual Clock module. We could choose to simply use the CLOCK2 signal from the expanded bus, which is already available on the serial board. That would mean that Port A and Port B always used the same baud rate. If that’s a problem, we could instead run a flying lead from the clock select jumper pins on the Dual Clock module to Port A on the serial module. This mod accommodates either option.

On the Dual Serial SIO/2 circuit board (as of version 1.0), the wiring that connects pins 13, 14, and 20 is on the component side of the board, and is hidden under the IC socket for the Z80 SIO2. I didn’t want to remove that 40-pin socket to cut traces. Instead, I lifted pin 20 of the chip out of its socket and jumpered it directly to the CLOCK signal on the standard bus, right on the bus pin. Then I cut the trace from the bus pin to the rest of the board. That isolates the traces that connect pins 13 and 14 of the chip and also one side of JP1, the jumper that was intended to bridge CLOCK2 to the standard bus CLOCK. See photos.

IMG 8101

IMG 8103

Now we can install a jumper at JP1 to connect Port A’s clock inputs to CLOCK2, and run both Port A and Port B at the baud rate corresponding to CLOCK2. Or, we can run a flying lead from any baud rate we choose from either clock rate jumper header on the Dual Clock module to the Port A side of JP1 on the Dual Serial SIO/2 module, and run them at different baud rates.

IMG 8104

IMG 8127

I tested with the version of XMODEM for CP/M that is named XM.COM in version 2.9.1 of RomWBW. On the host side, I was running minicom 2.7 under Raspbian on the Pi Zero Serial Terminal board. I found that XMODEM transfers from the host to CP/M were perfectly reliable at 9600 baud, yielding a transfer rate of about 870 bytes/second (to RAM disk or to CompactFlash), about 90.6% efficient, on large files. I found that XMODEM transfers didn’t work at all at 19200 baud with this configuration.

Here’s a video of XMODEM working at 9600 baud on the RC2014: (YouTube)

RC2014 Remote Reset Mod

I usually operate my RC2014 Z80-based retro computer using the Pi Zero Serial Terminal module. This RC2014 module hosts a Raspberry Pi Zero and connects the Pi’s main serial port to the serial RX and TX lines on the RC2014 bus. It is intended to be used with PiGfx, a bare-metal ANSI terminal emulator. The idea is you’d hook up a monitor and a USB Keyboard to the Pi Zero, and use it locally as a standalone dumb terminal. It’s a brilliant solution, especially since actual terminals are getting hard to find.

I don’t use it that way. I prefer to run Raspbian on the Pi Zero and use a terminal emulation program (typically minicom) to talk to the RC2014. In local mode, Raspbian makes much prettier text on the screen (as of the version of PiGfx I tried), even using the composite video output. What’s more, Raspbian supports networking so I can use the RC2014 without sitting right in front of it. Raspbian of course supports all flavors of the Raspberry Pi, so I can use a Raspberry Pi Zero W instead of a plain Zero, and get built-in WiFi networking. PiGfx doesn’t yet support the Zero W, though it is on their TODO list.

So my typical working configuration has me sitting across the room from the RC2014, at a Mac with several large monitors, connected to the Zero W via ssh over WiFi, running minicom to communicate with the RC2014. There’s a problem with this setup, though. Given the parlous state of most of the software I’m trying to run (or write) on the RC2014, it’s just not that unusual that I need to push the reset button. Getting up and walking across the room to push the reset button seems inelegant. It’s also enough of a pain that I will waste time trying to find a way to un-stick the Z80 from the serial console to avoid doing it. I need a reset button I can activate remotely.

Luckily there are plenty of unused GPIO pins on the Pi, and it’s pretty easy to interface one of them to the /RESET signal on the RC2014 bus. That’s what this mod does. We’ll use GPIO4, because it’s mechanically handy and not shared with any other functions on the Pi. Note that it is not OK to hook these signals up directly, since /RESET is a +5V signal and the Pi is only rated for +3.3V.

Reset mode schematic

The transistor pulls the /RESET signal down to ground when GPIO4 is high. When GPIO4 is low, the transistor does nothing.

2N3904 pinout

Unplug the Raspberry Pi from the Serial Terminal module. We’ll be installing the components on the Serial Terminal module underneath the Pi.

There’s lots of room on the module circuit board that’s not used. Hold it up to the light to see that there isn’t even a ground plane over most of the area of the board. Drill five holes as shown below. I used a #66 drill bit, but the diameter of the hole isn’t critical. The lower three holes in a triangular pattern are for the transistor. The upper two are for the resistor; the right hole is near the base of the transistor, and the left hole is approximately over the fourth pin from the left of the Raspberry Pi connector. The two resistors shown here are standard parts on the Serial Terminal module. I drilled the holes freehand. Just get them close.

IMG 7956

Install the components on the front of the board. Make sure the transistor is oriented with the flat side toward the Raspberry Pi connector, as shown. You’ll need to bend the transistor’s leads out a little to reach the holes. Make sure the transistor sits reasonably close to the board, so it won’t interfere with the Raspberry Pi.

component placement

Make the connections on the back side of the module board. One side of the resistor and the base of the transistor are adjacent, so just bend the leads together, solder, and trim. The other side of the resistor should be able to reach the Raspberry Pi connector; bend it over and solder it to the GPIO4 pin, which is the fourth from the end. Use some wire if it doesn’t reach. The emitter of the transistor is close to the end of the pre-existing 22K resistor that just happens to be GND, so bend that lead over to touch the existing pad, solder, and trim. Add a piece of thin solid wire (I used 24 gauge telephone wire) between the collector of the transistor and the /RESET pin on the RC2014 main bus. /RESET is two pins over from the +5V pin, which has traces connected to it. There’s no particular need to insulate or strain relieve any of these connections, but you might want to drop a bit of superglue on the two longer leads. Re-install the Pi.

Connections on the rear side

Now we just need a bit of software to function as our reset button. Here’s what I came up with. Name it rcreset.py


import RPi.GPIO as GPIO

GPIO.setup(4, GPIO.OUT)
# no extra delay required; the pulse is about 10 uS naturally

# don't call GPIO.cleanup(), we want the pin to stay low.
# That's why we turn off warnings above; when we run this
# program a second time it would warn that we were already
# using the pin.

I chose to use Python because Python. I chose Python 3 instead of old-fashioned Python because 2019, though this script would probably work the same either way. I chose RPi.GPIO instead of gpiozero because the startup time for gpiozero seemed excessive. This script runs in about 650ms, which is fast enough. There are lots of other ways this script could be written.

As noted in a comment in the script, the pulse generated is usually about 10 microseconds long. Raspbian is not a realtime operating system, so it could be longer. The Z80 data sheet calls for the reset pulse to last for at least three full clock cycles, so this pulse will work for any Z80 clock faster than about 400 kHz. If your clock is sometimes slower than that, you might want to insert an appropriate delay into the script. Reset won’t work at all if the clock is stopped.

You’ll need to adjust the permissions of the Python script:

chmod +x rcreset.py

You’ll probably want to place it somewhere on your regular search path, such as /usr/local/bin.

Finally, we need to deal with how GPIO4 behaves when the Raspberry Pi starts up. By default, it starts out as an input with a weak pull-up, and stays that way until the boot process is nearly complete, and then switches to a high impedance state. The initial state holds the RC2014 in reset for many seconds, and then the high-impedance state leaves it vulnerable to spurious resets due to noise. We could use a similar Python script on startup, but that won’t run until rather late in the boot process, and if we happen to be using the local console we’ll be stuck waiting for the Raspberry Pi to boot up for no good reason. Instead, let’s use some magic words to get GPIO4 configured early in the boot process. Make sure you’re running a version of Raspberry Pi firmware that’s newer than March 18, 2018, and add these lines to /boot/config.txt:

# Drive the GPIO pin used by RC2014 reset as early as possible

With those magic words, GPIO4 goes low within a second or two of power-up, and stays that way. Much better.

So now when I’m sitting across the room and the RC2014 locks up on me, I open another ssh session to it and type


I could also use a local command on my Mac or Linux host. This could be assigned to a hot key or other shortcut to eliminate all the excess typing:

ssh pi@rc2014.local /usr/local/bin/rcreset.py

This works best if ssh has already been set up to authenticate to the Pi without requiring a password. Like this.

One final note. If you also use the RC2014 Dual Clock and Reset module, there’s a potential issue with contention on the /RESET line. I have a mod for this, too, which I recommend you install before installing the remote reset mod. See my previous post for details.


P.S. The reset script can be run from inside minicom, so there’s no need for a separate session.

1. On the Pi, create a directory to contain minicom scripts, if you don’t already have one. I named mine .minicom and put it in the home directory.

2. Create a script file inside that directory. Name it something like rcreset and put this in it:

! /usr/local/bin/rcreset.py

3. Run minicom. Ctrl-A O to open configuration. Choose Filenames and paths. Choose C to enter the script directory path. Enter /home/pi/.minicom or whatever you called your script directory. On the way out of the configuration menu, choose Save setup as dfl to make the change permanent.

Then to reset the RC2014 in minicom, hit Ctrl-A G to run a script. The first time, you’ll need to hit C and type in the name of the script (rcreset). Then hit enter to run it. Thereafter in that session you can just hit Ctrl-A G Return to reset the RC2014.

/RESET Mod for RC2014 Dual Clock and Reset Board

One of the modular components of the RC2014 Z80-based retro computer system is the Dual Clock and Reset Module. This board (as of version 2.1) actively drives the /RESET signal with a 74HCT04 inverter. This means that if any other component wishes to reset the system, it has to contend with that gate and short its high output to ground. For example, the Backplane Pro has a hard switch for /RESET, which literally shorts the signal to ground. While you can get away with this sort of thing most of the time, it’s theoretically possible to blow up the 74HCT04 this way.

I could have just disconnected the 74HCT04 from the /RESET signal and used the button on the Backplane Pro for manual resets. However, the button on the module is more conveniently placed. What’s more, the reset circuit on the module generates a power-on reset, which is very handy. I wanted to preserve these functions of the module. Here is what I came up with, showing the relevant part of the module’s schematic as modified.

Dual Clock mod schematic 01

We do disconnect the 74HCT04 U1 from /RESET, but we replace it with a 2N3904 NPN switching transistor. This acts as an inverter, just as U1B did, but it only drives actively when it’s pulling the signal low. For mechanical convenience, we pick up both the input and the output signals from P1, a 3-pin header intended for selection of either RESET or /RESET to connect to the RESET2 signal on the extended bus. I don’t use RESET2 and never installed that header. If you use this header, you’ll have to come up with a different mechanical arrangement.

Note that this assumes there is a pull-up resistor somewhere on the /RESET signal. All of the official RC2014 backplanes (the Backplane Pro, the Backplane-5, and the Backplane-8) provide such a pull-up.

Prepare a 1K resistor and a 2N3904 transistor as shown below. Solder one end of the resistor to the base (center lead) of the 2N3904. Bend the emitter lead out to one side.

Resistor connected to center pin of transistor

That’s a quarter-watt resistor, but if you have a smaller one handy, it would fit better. The value is not critical at all. Any NPN switching transistor would probably work fine, too, as long as you get the pin assignments right. This shows the pin assignment for a 2N3904:

2N3904 pinout

Now drop the assembly into the Dual Clock and Reset board, as shown below. The free lead of the resistor goes into pin 3 (RESET) of the P1 header, and the unbent collector lead of the 2N3904 goes into pin 1 (/RESET) of P1. The bent emitter lead picks up ground from pin 1 of the extended bus connector. Solder and trim both leads on the bottom of the board, and solder the emitter lead to the nearest pin on the extended bus connector and trim. Make sure the exposed base-resistor junction doesn’t touch any other exposed lead. Nothing is connected to pin 2 (RESET2) of P1.

mod assembly installed in module board

Finally, remove U1, the 74HCT04, from its socket, gently bend pin 4 up about 90 degrees, and reinstall U1 in its socket. Here’s what that looks like.

completed modification

That completes the modification. Put the board back into your system and test that reset still works. You shouldn’t notice any change in power-up behavior or behavior when you press either the reset button on the backplane or the one on the module. Rest easier knowing that resets don’t short out the 74HCT04 anymore.

Purposing a Makesmith CNC

Back in May of 2014 I was a Kickstarter supporter of the Makesmith CNC, which was an attempt to build an extremely inexpensive CNC router. The project was 822% funded, and they shipped all the kits in November, almost on time. Yay!

I began to put mine together right away. They had pretty good video tutorials on how to do it, but not much in the way of written documentation, and there were some holes in the tutorials. I made a post or two on their forum about my experiences. There were a few minor updates to the videos, made as overlaid titles, but nothing very substantial. I set the project aside to wait for the rest of the community to catch up and participate in improving the design.

Over a year later, in December 2015, I picked it up again. I found no improved documentation and relatively little more in the forums, so I just completed the assembly of the mill using my own best guesses. After jumping through some hoops to get their Macintosh software running, I was able to run some initial tests. I wasn’t impressed. As expected, it was really slow, but it’s hard to appreciate how slow without seeing it in person. Also as expected, its axes were pretty wimpy, barely powerful enough to overcome their own friction. One of the cost saving measures that makes the design feasible is that they don’t really try to prevent lost motion, they just measure it with a closed-loop feedback system and try to compensate. All this is more or less as advertised.

My particular mill had worse problems. It had a tendency to get stuck in the X and Z axes. This is undoubtedly due to alignment problems with the rails, which arise from some combination of the low-budget design and the assembly procedures I used. Because of the low-budget construction, though, there is no easy way to adjust the alignment after assembly and gluing. I’m sure there’s some way to make the mill work to expectations, but at this point it became clear to me that this mill was going to be frustrating to use. It was just too compromised to reduce cost.

By that time it was clear that Makesmith was never going into production with these machines, either. They filled the Kickstarter orders, and stopped. The software hasn’t been updated, and the user forum looks abandoned (overrun by forum spam). Maybe Makesmith reached the same conclusion: that the Makesmith CNC just wasn’t viable. They ran a new Kickstarter project in November 2016 to make a much larger CNC router at a very low cost point. I hope they and their Kickstarter backers have better luck this time.

Anyhow, I decided to give up on using the Makesmith CNC. It was fun to build and educational, so I got my money’s worth (more or less), even though I never even mounted a spindle (i.e., a Dremel tool) on the mill. I began researching commercially available mills and a few months later ended up buying the Tormach PCNC 440 with all the goodies for about 55 times the cost of the Kickstarter Makesmith CNC. Needless to say, it’s in a whole different class.

All of which is just a long explanation for why I have the carcass of a Makesmith CNC sitting around, capable (barely) of X-Y-Z positioning, but without a purpose. I also had a cheap USB microscope, which was adequately functional but which came with a nearly useless articulated-arm stand. Recently it occurred to me that the Makesmith would work as a positioner for the microscope. With a solid stand and relatively precise orthogonal positioning axes, the microscope would be transformed from a toy into a tool. Holding a lightweight plastic microscope and positioning it interactively under manual control is far less demanding for the Makesmith chassis than working as a milling machine.

I wanted interactive control of the positioner, independent of any computer software, so I bought a joystick on a breakout board and wired it up to spare I/O pins on the Arduino Mega 2560 that serves as the brains for the Makesmith CNC.


I then discarded the Makesmith firmware and wrote a dead-simple Arduino program that reads the joysticks and moves the axes, without any of the complexities of feedback or G-code interpretation or much of anything else. The software is on Github. I also added a power cable so that the Arduino was powered from the Makesmith’s power supply, instead of from the host computer’s USB port. Here’s the final lashup:


The microscope is a cheapie, but it gives decent results. My test subject here is a Raspberry Pi board. Here’s the view at minimum magnification, at 640×480 pixel resolution:

Wide small

For scale, the big black chip is 9mm square. Here’s the view at maximum magnification and maximum resolution:

Narrow big

We see just a few of the pins on one side of the same chip. Near the middle of the image is a via, a tiny hole that routes the circuit to the other side of the board. Those little white specks inside the via are formed by a silk screened annotation on the back side that happens to overlap with the hole. At this magnification, the depth of field is pretty shallow, so the top of the chip and of C78 are quite out of focus.

The motion of the Z axis is quite sufficient for focusing the microscope, even at maximum magnification. It could use more vertical travel for working on larger subjects, but that’s true of every positioner in the world. The X and Y axes are still slow, but even at minimum magnification they move the image about as fast as you’d want them to. The speed only becomes an issue when you need to move the microscope to a whole different area. Often it’s easier to just move the subject around on the platform.

The microscope can capture video, too, but the motion isn’t really smooth enough for that to be impressive. I’m using miXscope software to control the microscope from a MacBook Air. That software has a number of useful features for technical microscopy, but it’s a bit long in the tooth and a bit crashy on current versions of macOS.

The next obvious application for a microscope with a positioner is to automatically photograph a grid of overlapping images at different X-Y offsets, which can then be stitched together to create a larger high-resolution image. To do this I’d need to add back some of the complexity of the control firmware, so it’s on the back burner for now. Another variant would be to take multiple exposures at different Z offsets, which can then be merged to increase the effective depth of field. More projects!

This was a quickie weekend boondoggle, except for waiting for the joystick board to arrive. Well worth the effort to add an improved tool to the lab.

Drag Engraving Test

I did some diamond drag engraving on aluminum in the PCNC 440. Results look pretty good! It’s quick, too.


The heading across the top was done from the conversational screen in PathPilot. The two copies of the logo were converted from Adobe Illustrator via Inkscape to DWG format and imported into Fusion 360, which generated the Gcode for PathPilot.

One apparent limitation: I couldn’t find any way to tell Fusion 360 CAM that you’re working with a tool that doesn’t need to spin. If you set the spindle speed to 0, it complains that the spindle speed is out of range and won’t generate Gcode. The workaround (thanks NYC CNC) is to set an in-range spindle speed, and then edit the Gcode to remove the spindle commands. That’s messy and error-prone.

The diamond drag engraver is spring-loaded, so the Z depth is not critical. The logo on the left was engraved with a Z depth of only 0.02 inches, while the one on the right used 0.25 inches, about half the available travel of the spring head. The results are practically identical.

Spindle Lockout for Tormach PCNC 440

Recently I installed a CNC milling machine in the garage, a Tormach PCNC 440. This is the smallest and newest of three CNC mills they manufacture in China but design, QA, and support from Wisconsin. These machines are designed to be affordable but still offer a very usable level of performance. Current models are controlled by an external Linux-based PC built from standard PC components, plus a Mesa 5I25 FPGA-based PCI I/O card, running Tormach’s PathPilot software. This setup replaced an older configuration that ran third-party Mach3 software on a standard PC under a customized version of Windows.

I’m a beginner at machining, and have been taking it slow and easy as I get up to speed on operating the 440. A few days ago I was working with the Tormach Passive Probe. This is a simple mechanical sensor that mounts in the machine’s spindle (where a cutting tool would usually go) and cables up to the controller. This allows the controller to detect the X, Y, and Z locations of surfaces on the work piece or fixtures. It’s one of several ways to get the machine properly lined up to the work.

The probe comes with a prominent warning to disable the spindle before use. Obviously, if the spindle starts to spin with the probe mounted, the probe’s cable is going to get wrapped around the probe and destroyed. Tormach tells me that the warning exists because of a known problem with the older Mach3 software, which could cause the spindle to start running under certain conditions. On the older model mills, there is a control panel switch that locks out the spindle. Since the 440 never used Mach3, Tormach decided to leave out the spindle lockout switch, one of many cost reductions that makes the 440 so affordable. There is still an interlock on the spindle door, so the spindle cannot be activated with the access door open.

Unfortunately, the spindle access door can’t just be left open as a substitute for a spindle lockout switch. The top panel of the optional enclosure kit just clears the spindle with the door closed. With the door open, the machine’s head can’t be lowered into the work area. So, one has no choice but to trust that the controller won’t activate the spindle while you’re using the probe. If you make a mistake and tell the controller to activate the spindle, or if something goes wrong in the controller and it activates the spindle when it shouldn’t, there’s nothing to prevent the spindle from spinning and destroying the probe.

So, I was working with the probe. I had used it to line up X and Y, and was thinking about Z, when I got interrupted to go out to lunch. I didn’t want to lose my X and Y settings, so I left the machine turned on. When I returned from lunch, this is what I found:

Results of spindle mishap on Tormach PCNC 440
Results of spindle mishap on Tormach PCNC 440

Not only was the cable wrapped around the probe and snapped off where it enters the enclosure, but it had also grabbed and destroyed the armored hose that carries flood coolant. It had thrashed the lightweight fabric bellows that protects the Z axis ways, and also snapped off the expensive ruby-tipped ceramic probe tip. The user interface on the PathPilot screen looked normal but was unresponsive. Crashed.

I don’t know whether this was a one-time glitch (cosmic rays?) or a defect in my hardware or a systematic bug in the PathPilot software. Tormach is investigating, trying to reproduce the problem.

In the meantime, I decided to add my own spindle lockout switch. I consulted the schematic diagram for the mill and noted that the access door interlock switch is in series with the power being supplied to the module that runs the spindle motor. No combination of failures or glitches in the spindle motor driver could cause the spindle to turn when there’s no power being delivered to the driver. This is a very safe design, but it does require an interlock switch and wiring that’s able to handle all the current that the 3/4-horsepower spindle motor can draw. The schematic shows a 6 amp fuse in that circuit. I could add my own switch in series with the door interlock, as long as it could handle the 6 amps. I chose a toggle switch rated at 20 amps, GC Electronics model 35-130, because it was available at my local Fry’s.

The next question was where to mount my lockout switch. Perhaps the most obvious place would be on the side of the mill’s electronics cabinet. That’s where the main power switch is, and also the connector for plugging in the probe’s cable, and several blank panels that appear to be designed for specific future accessories. The needed circuits are readily accessible inside the cabinet on barrier strips, and there’s plenty of clearance inside the cabinet to mount a switch on the side panel. Unfortunately, my garage installation is somewhat crowded and the side panel is not very easy to reach. I worried that I might skip using a lockout switch mounted in that inconvenient location.

The easiest surfaces to reach are on the front of the mill’s enclosure, but all those surfaces are single thicknesses of sheet metal, with the inside being within the splash zone for coolant and chips. Mounting anything electrical there would mean adding a sealed enclosure for it, and finding a clean way to run heavy wires to it. That didn’t seem like the right answer.

Instead, I chose to mount the switch above the spindle motor, right next to the door interlock switch. This should be convenient, because I have to open the spindle door in order to change tools, so I will be in there every time I mount the probe. (When Tormach releases the power drawbar add-on kit, that will no longer be true. I may revisit the lockout switch placement then.) In my junk box I found some 3″x1″ aluminum C-channel. I cut a 1.75″ length of this stock, and mounted the switch on one of the small sides. I drilled two holes through the other small side, and matching holes in the back panel of the spindle enclosure, and mounted the assembly with two bolts. The C-channel is more than stiff enough to support the switch.

Spindle Lockout Switch added to Tormach PCNC 440
Spindle Lockout Switch added to Tormach PCNC 440

The switch has screw terminals, and so does the door interlock switch, so wiring was easy. I just removed one wire from the door interlock switch and moved it to my switch, and added a 6″ jumper of #14 wire between my switch and the door interlock switch.

Paul C. Buff REMOTE connector

Paul C. Buff Remote Control Connector (1st Generation)

Strobes like the Paul C. Buff White Lightning X1600 and Alien Bees have a 6P4C modular connector (like a RJ14 telephone wall cord) marked REMOTE. This connector provides strobe sync, strobe power control, and modeling light power control.

The following information was obtained by studying the LG4X wired remote controller and X1600 strobe. Later models (such as the Einstein) clearly have more going through this connector.

The jack on the X1600 rear panel is mounted with the connector’s tab up. Let’s number the pins of this connector 1 to 4, from left to right looking at the strobe’s rear panel. (Update: this may be backwards; I think the phone cords cross the wires.)

Pin Function
1 Modeling light brightness
2 Strobe power
3 Common (ground)
4 Sync

The common and sync pins are electrically connected between all four sockets on the LG4X.

The strobe power is a simple DC voltage, driven in the LG4X by a MCP604 op amp, ranging from 0V to 3.75V. These are the voltages I observed at each slider setting:

Slider Setting Voltage
Full power 0.00V
-0.5 stops 0.43V
-1.0 stop 1.03V
-1.5 stops 1.46V
-2.0 stops 1.84V
-2.5 stops 2.12V
-3.0 stops 2.43V
-3.5 stops 2.66V
-4.0 stops 2.90V
-4.5 stops 3.11V
-5.0 stops 3.31V
Min power 3.75V

LG4X Voltages

The modeling light control is also a simple DC voltage. When the LG4X switch is set for full power modeling lights, this voltage is 0. When the switch is set for modeling lights OFF, this voltage is 5.0V. When the switch is set for tracking, the voltage is connected in parallel with the strobe power voltage.

The sync pin idles at +5V with respect to the common pin. When the FIRE button on the LG4X is pressed, a single 1 millisecond pulse at 0V is output. This pin is also in parallel with the tip of the SYNC jack on the LG4X, so an external contact closure on the SYNC port also drives this voltage to 0.

That’s all there is to this interface, at least as far as the LG4X wired remote is concerned.

Dongles considered harmful

Helping to search for a missing copy-protection dongle (for embroidery software) reminds me just how awful that kind of copy-protection is.

I can understand why software publishers are tempted to use it, especially for niche market titles that command relatively high prices. The arithmetic might even work out in the publisher’s favor for hardcore engineering software used almost exclusively by corporate minions on big-budget projects. I imagine that some of the users of the embroidery software are commercial users doing embroidery for customers, and those users pretty much have to pay whatever the publisher demands. The commercial-grade embroidery machines certainly aren’t cheap; the software doesn’t materially alter the capital budget even when it’s grossly overpriced.

But there are also prosumer embroidery machines aimed at advanced hobbyists. Those machines aren’t exactly cheap either, but the price of the software really does drive the cost way up. Probably with the software so expensive, and hobbyists using it “just for fun”, there would be some who would use the software without paying, and some of those wouldn’t be technical enough to circumvent the dongle copy protection. The license fees these customers pay are the upside of copy protection for the publisher.

The downside, of course, is that all the other customers are treated like thieves. They are inconvenienced every time they run the software, for the sole benefit of the software publisher to whom they have already paid a wad of money. When the dongle goes walkabout, as it inevitably does at the worst possible time, they are prevented from doing any work until the dongle can be located or replaced. It sure doesn’t help the customer feel affection for the software or its publisher. Word of mouth suffers. Bad dongle experiences (not to mention high prices) poison the potential community of users. Great software that could have been a runaway favorite ends up feeling like a necessary evil.

Ugh. So far, we still haven’t found the dongle, so we may get a chance to find out how well the publisher and its local dealer are at customer support.