A tale about an ancient piece of hardware
re-animated with modern electronics
Years ago, in fact, decades ago even, I aquired a Strobe Model 100 drum plotter from a
used equipment disposal sale at the local university. Although originally sold with a choice
of interface card for use in various computers of the day, this one came with nothing
beyond the plotter itself. Back then in the 80's, I hacked together a wire wrapped
circuit board to fit into my Apple][ after reverse engineering the plotter's internal
Figure 1: Strobe
Model 100 Digital Graphics Plotter
Figure 2: The arrow pad and drive over-ride
Figure 3: The back of the plotter with power
and interface connectors
I wrote some simple software back then and was able to get the plotter to draw. Dragon
curves were especially fascinating to draw. In the process, I learned about (the existance of)
Bresenham's line and circle algorithms, although I never got around to implementing circles
or arcs. Keep in mind this was well before the World Wide Web - you had to get your
information from papers in the library. The plotter was put away, not lost or forgotten,
just shelved while other projects had their time.
Fast forward to a different topic starting near the end 2010. A question was posed on
CNCZone.com in the PIC Programming/Design forum: "
PIC-Based Step Generation With Linear Acceleration?"
Various methods of generating linear acceleration ramps were discussed. I
started examining a Direct Digital Synthesis algorithm capable of generating these ramps
and started contributing my results to the discussion. I created a
to publish my results.
Acceleration ramps by themselves are not overly useful. It was time to do something practical
with the code I had built. I expanded the firmware to operate multiple axes and started writing
a G Code interpreter front end. By now, the software can run a milling machine in 2.5 axis
mode, with step rates as high as 100kHz, all running on a PIC18F14K22 on a lightly hacked
BOB (Breakout-Out-Board) from piclist.com.
A PIC18 is capable chip in its own right, but now a days there are, in my opinion, better
choices for hobby hacking. The PIC24FV family is particularly interesting because it operates
at 5 volts and is available in 20 and 28 pin dip packages. So I started porting my G Code
interpreter to the PIC24. The trouble is, a milling machine is not an ideal piece of
equipment for testing code, debugging and troubleshooting. It's simple too big and bulky,
not to mention noisy and messy. She who is to be obeyed won't allow it in the living room
for some reason. Go figure!
And so we are led back to that old plotter shelved years ago. It makes a perfect device
for testing PIC24 code as it is developed. I hacked together a simple circuit board with
a PIC24FV32KA301 that plugs directly into the interface port on the back of the plotter.
An FTDI UBS/Serial cable plugs into a header on the board to allow communication with the
outside world - a link for sending G Code files and receiving status reports.
Figure 5 & 6: Front and back sides of the (rather ugly)
PIC24 circuit board that plugs directly into the back of the plotter
Recall from the picture of the plotter above that it has an arrow pad for moving the pen
around. What do you suppose might happen if you pressed the sequence "
up up down down left right left right enter"? Hmmm... watch the
video below to find out!
So How Does It Work?
In short, by carefully crafting software and hardware to work harmoniously, just about
anything can be achieved.
Let's look at the PIC24 interface circuit first.
Figure 7: A rough circuit diagram. (Click for PDF)
This diagram was used for construction which is why it shows a bottom view of the PIC24.
There is nothing too noteworthy here. The PIC's internal oscillator is used at maximum
speed. Two pins are unused - these happen to be for the I2C peripheral for possible
future expansion. Applying 5 volts to the pen and phase pins of the plotter's interface
port energizes each respective coil courtesy of the power transistors inside.
Perhaps the only tricky part is the button interface. There were not
enough pins to read each button seperately so I put the arrow pad and the ENTER key
together on an analog pin. The resistor network coupled with the fact that each button
is pulled high and shorts to ground results in a unique voltage for each button. The
10K pullup isn't really needed, but the circuit works great as is. Since this circuit
does not recognize multiple simultaneous presses, the FAST button gets its own pin
because it is expected to be used together with direction buttons for 'turbo speed'.
(Which by the way is not currently implemented.) The LED visible in the picures above
is connected to pin 9 of the PIC.
The other magic ingredient is of course the
project source code. The firmware was built with MPLAB 8.9x and C30.
(I have no desire at present to fight with MPLAB-X. The old stuff works, so I use it.) This
version does not contain any G-Code stuff.
Two axis linear motion control with real-time acceleration is handled by an assembly language
interrupt routine. This routine is told distance and direction in X and Y, acceleration,
maximum speed and which axis is the longer one. This last detail, along with the direction
data, is needed to apply Bresenham's line drawing algorithm outside of the first octant.
Once started, the ISR handles everthing about when and in which order to energize the
stepper coils to move to the destination point. The steppers are run in half-step mode,
alternating between single and double coil energization, resulting in 500 steps per inch.
The ISR, which is timer based, also handles polling the serial port. The ISR fires much
faster than the serial rate so overruns are not an issue. This architecture is a carry-over
from the older PIC18 code and needs to be re-evaluated given the better interrupt capabilities
of the PIC24.
The remainder of the code is written in C and consists of standard setup code and a main
loop that monitors user input and reacts accordingly. I don't use library functions to
set up peripherals, preferring instead to twiddle the settings bits myself so that I know
exactly what's going on.
Arrow button presses shift the pen and drum around as expected. Button releases are stored
in a buffer which is compared to the secret code when the ENTER button is seen. If the code
matches, the easter egg plotting routine takes over and plots the message string, returning
the pen to the starting point when finished.
The characters themselves are a bit interesting. Since the plotter is a vector device, the
letters must be stored as a sequence of lines. I accomplished this by defining each character
as lines drawn on a 14x16 grid. This allows the X and Y coordinates of each point to be encoded
into the nibbles of a byte. Due to the limited character set required to spell the easter egg
message, a neat trick allows characters to be built from other characters, resulting in a
slight (and likely not worth the trouble) data compression. For example, the letter "a" can
be drawn by first drawing two short segments, then drawing a "c". Likewise, a "d" is a short
segment followed by an "a". Setting the X nibble to 'F' identifies that Y nibble specifies
the chained character. The offset to the next character is also encoded in the definition,
given that the ending point of each character could be anywhere in the width. An X nibble of
'0' marks the end of the character, with the Y nibble holding the distance to shift right
to start the next character. If you watch the video closely, you can see that the pen starts
each character from the bottom left. An interesting side effect of the vector nature of the
character drawing is that different sizes are trivial. A simple parameter to the drawing
routine sets the size of the output.
Figure 8: Text printed at different scales. The bottom
one is 5X and is not really legible. Each one higher is scaled 5 more - 10X, 15X, 20X etc.
If you have any questions or comments, feel free to post in the
or send an email to vegipete at this domain dot net.