The Stevens CNC pickup winder project was goin'
great...
until...
This is
the Arduino Uno microcomputer I bought to be the
'brains' of my 1940's Geo. Stevens pickup coil
winder I've been working on converting to CNC
(Computer Numerical Control) drive for awhile now.
You can read about the
progress I've made up to now here
To recap - This computer was meant to use two
motors to replace many missing gears and cams
my winder needed to wind a pickup coil, which
nowadays are made of solid unobtainium.
In this photo,
the Arduino is counting the amount of
turns the main shaft
(and the pickup bobbin)
has already turned
and plotting the relative
position of the traverse (wire feed)
system
to its original position at the
beginning of the wind.
I had a list of features I wanted to have on my new
winder, such as
1) the ability to generate, edit and save its own
program 'variables' data files (so I wouldn't have
to
constantly be rewriting the program every time I
changed something small!)
2) the ability to use a touchscreen to input data to
the Arduino without having to use a dedicated
laptop computer to do it. Why use an microcomputer
to run a machine if you have to use a 'real'
computer just to program it?
3)
The winder must be able to sense if anything goes wrong,
like a coil wire breaking or the main
motor
stopping.
If that happens, I want
the winder to shut down and an alarm
to go off.
Why? So
I don't have to keep
watching it and I can do other
things while it runs.
4)
The machine must be able to count and make moves
very accurately indeed. For example,
one
strand of AWG 42 gauge plain enamel coil wire (used
in Gibson type humbucker pickups and Fender
Telecaster pickups since 1952) is roughly .0026
inches in diameter, or about 2.6 thousandths of an
inch.
If a pickup coil width (between the inner sides of a
bobbin) is 1/4" or .250 of an inch, I must wind
around
95 winds of my wire to wind just one layer of a
pickup coil! For
reference - according
to Wikipedia an
average human hair is about
.0006 inches diameter. This
means the coil wire I want
to use in the example
above is only about three
times as thick as a human
hair!
This is very important because if I want to lay one
wrap of coil wire exactly next to the one next to
it,
the traverse assembly (the wire feeder) *MUST* be
accurate enough to do it. Also, if I want to use
other gauges or types of wire to make other
types of pickups, I must be able to tune the program
to
accept all the new data that I have to change! (See
#1 above)
After I wrote the program, I found out that the Uno
simply didn't have the computational power to
'get 'er done'. The major problem was RAM... there
simply wasn't enough memory available to do
what I wanted the winder to do.
For example, the touchscreen/microSD memory card
board shown in the photo above was the
most efficient one I could find. Unfortunately, its
control interface to the Uno ate up too much of the
I/O
bus (input/output control) wiring, so I couldn't add
other necessary functions like wire breakage sensors
or even an emergency stop switch. You can see this
for yourself in the photo above - the green screw
terminal strips mounted on the boards on either side
of the Uno are interface hookups for adding the
wires for controlling the motors and sensors I
wanted to use. Most of these were already used just
to
work the touchscreen, SD card and the turn count
sensor,
without even hooking up the main or traverse motor's
control boards yet!
I also researched using a smartphone as a 'remote
control' to use instead as a combination control
panel
and memory for the winder, but this introduced an
entirely new set of issues - like a huge new program
for the Uno to run all by itself without even
collecting any data, and also not to mention
forgetting where
you left the %*&!@# smartphone while the winder
was running... and now it's not...
Speed was also an issue, because the program
couldn't be run fast enough to sustain any real
speed.
If I tried to increase the motor's speed, the
'winder RPM' and 'turn counter' counters started to
skip
counts or not even count at all! Streamlining the
program itself didn't help at all... no matter how
much
smaller the program got the problems didn't go away.
The microprocessor was simply too slow for the job.
So, what
happens now?
I'm researching new microprocessors to replace the Uno, like
an Arduino Mega 2560 or a Raspberry
Pi.
The Arduino Mega 2560 (which is the 'big brother'
to the Uno) is used in many larger robots and 3d printers.
It offers a much faster 'clock speed' than the Uno, much
more RAM memory, and also a much larger I/O control
system bus so I can connect all the sensors I need to
use to it. Best of all, since it is a bigger version of the
Uno
with the same basic design, I supposedly can reuse much of
the same parts (like sensors and motor driver
'shield' control boards) I bought for the Uno... as well as
also reusing the program I already wrote for the Uno!
The Raspberry Pi is
about the same size as the Mega, but it's a 'real' computer
not a microcontroller
like the Arduino. It's supposedly much more efficient than
the Mega, and you would write programs
directly to the Pi. Unfortunately, I would have to learn a
whole new programming language, not to mention
junking all the motor control boards, touchscreen monitor
and everything else I bought for the Arduino.
Decisions, decisions...