Make no mistake, the Raspberry Pi is an excellent piece of equipment.
Like any device, it has its limitations, and like any device, there are ways to expand those limitations with clever use of hardware and software.
One of the limitations is the number of communication pins available to the user without using an GPIO expander.
I want to perform a large number of sensor readings and position actuator operations using the Pi. I want to simplify the software that runs those actuators and sensors. Essentially, I want a much more powerful system controlling my microscope.
I can do this in two ways - one is to scrap the idea of using the Raspberry Pi, and to install a big, custom-made control system. The other is to farm out part of the computational load to other, small computers.
The first option sounds expensive, and will require everything to be written as a monolithic system - one that will require a lot of re-writing every time I want to make a change.
The second option, however ...
Enter the Arduino nano. This is a "single chip" solution - it is actually a tiny PCB populated with an AT Mega microcontroller, ancillary circuitry and a set of pins that turns the surface mounted device into a DIP package with a couple of connectors on top.
Programmed in a dedicated version of C, the device is all about sensors and control actuation. It is fast, it is cheap and, above all, can keep track of several stepper-motors, travel limit switches and indicator lamps (LEDs).
Thus, each cluster of stepper motors in this project will be overseen by an Arduino, keeping the workload of the Pi neatly centred on the task of running the microscope.
Of course, this means learning yet another programming language, but at least it is based on one that I have used before, if briefly.
Showing posts with label Stepper Motors. Show all posts
Showing posts with label Stepper Motors. Show all posts
Wednesday, 1 July 2015
Friday, 9 January 2015
Eyepiece - more on the Vickers M55 microscope
I spent time yesterday building a chassis for the stepper mechanism. Because the microscope has been modified to accept a bracket for a video camera (one of the big, old, heavy ones - which I do not have), I was able to use the mounting for this to attach the base plate. This plate is 2.5mm aluminium salvaged from an old piece of equipment. It will need a coat of the appropriate colour paint before it is finished.
Some drilling and fiddling, and I have a removable base plate with a stepper mounted on it. Since I'm still waiting for the electronic parts to arrive, that is as far as I can go.
Once the chassis was built, I turned my thoughts to the macro lenses. Swapping the micro optics for macro optics is a five-minute exercise. I tried the incident illumination, and found that it is useless for looking at rocks (no surprises there), so I got out the oblique illumination attachment (a mirror on a simple swivel mount).
This is the first time I have attempted to use oblique illumination using the macro lenses, and discovered that the adjustment screw was sheared off.
An hour later, I had removed the broken piece of screw and had to find a 6BA screw to replace it with. Luckily, I have a big pile of old clock-repair parts, including a selection of BA size screws.
(The pictures show the oblique illumination mirror with the new part - which needs a coat of paint)
Some work with a countersink and emery-paper on an old bronze motor bush produced a respectable head of the correct size to turn a long countersunk screw into a short screw with a smooth knob for a head.A spot of steel epoxy permanently fixed the screw in the knob (with an exposed slot head to enable release with a screwdriver, if necessary).
Now, the way the micro-focus mechanism operates is by moving the objective lens up and down - which has a coarse focus knob and a fine focus knob (which now has a stepper motor attached.
The macro mechanism, on the other hand, moves the specimen stage up and down, using a large knob and a friction brake. This is also the knob that is used to move the stage out of the way in order to swap the optics.
This knob is big and rather stiff (it operates a physically heavy piece of equipment, after all), and if I want to do image stacking using the macro system, it means another stepper to operate this knob. I also need to be able to lock the position as the stage is heavy enough that the mechanism drifts downward quite rapidly when released with the locking knob released.
The range of motion is enormous (15mm between micro examination and x5 macro) - and this means that I will need to be able to adjust and lock the stage elevation automatically. Since I am planning on using the macro optics a lot, then this is a change critical to the project.
I have managed to find a higher torque stepper in my parts bin (I may have something even heavier duty knocking around - somewhere), and so I will try that for size.
![]() | |
| The fine focus knob |
![]() |
| - with the old video-camera mounting base attached |
![]() |
| The stepper chassis attached with mounted stepper motor and drive belt. |
Some drilling and fiddling, and I have a removable base plate with a stepper mounted on it. Since I'm still waiting for the electronic parts to arrive, that is as far as I can go.
Once the chassis was built, I turned my thoughts to the macro lenses. Swapping the micro optics for macro optics is a five-minute exercise. I tried the incident illumination, and found that it is useless for looking at rocks (no surprises there), so I got out the oblique illumination attachment (a mirror on a simple swivel mount).
This is the first time I have attempted to use oblique illumination using the macro lenses, and discovered that the adjustment screw was sheared off.
An hour later, I had removed the broken piece of screw and had to find a 6BA screw to replace it with. Luckily, I have a big pile of old clock-repair parts, including a selection of BA size screws.
(The pictures show the oblique illumination mirror with the new part - which needs a coat of paint)
Some work with a countersink and emery-paper on an old bronze motor bush produced a respectable head of the correct size to turn a long countersunk screw into a short screw with a smooth knob for a head.A spot of steel epoxy permanently fixed the screw in the knob (with an exposed slot head to enable release with a screwdriver, if necessary).
Now, the way the micro-focus mechanism operates is by moving the objective lens up and down - which has a coarse focus knob and a fine focus knob (which now has a stepper motor attached.
The macro mechanism, on the other hand, moves the specimen stage up and down, using a large knob and a friction brake. This is also the knob that is used to move the stage out of the way in order to swap the optics.
This knob is big and rather stiff (it operates a physically heavy piece of equipment, after all), and if I want to do image stacking using the macro system, it means another stepper to operate this knob. I also need to be able to lock the position as the stage is heavy enough that the mechanism drifts downward quite rapidly when released with the locking knob released.
The range of motion is enormous (15mm between micro examination and x5 macro) - and this means that I will need to be able to adjust and lock the stage elevation automatically. Since I am planning on using the macro optics a lot, then this is a change critical to the project.
I have managed to find a higher torque stepper in my parts bin (I may have something even heavier duty knocking around - somewhere), and so I will try that for size.
Sunday, 4 January 2015
Eyepiece - on stepper drivers and motion sensors
I have spent the past couple of days designing the electronics by which to control the stepper motor that will be used to operate the fine focus of the microscope for image stacking.
The mechanism has an extremely free operation and the end stops cause the knobs to continue to rotate through use of a fairy stiff friction clutch.
The output torque of a stepper motor is roughly proportional to the current through the windings, and thus to the voltage of the electrical supply.
The motor that I have has 40Ω windings, and is designed for use at somewhere around 20V - therefore, it would be possible to drive the stepper at a lower voltage, set so that the motor stalls at the end of the focus mechanism's travel.
Stalling a stepper motor (difficult to do when fully powered) doesn't damage the motor or the drive circuitry (one of the reasons for my choice of stepper rather than a DC servo motor).
I am still refining the design and features of the board which will be used to drive the stepper motor.
While on the subject of the focus mechanism, I wanted to be able to detect when the motor stalled. One way would be to use an optical encoder, either attached to the motor or to the focus knob, but the problem remains that if the knob bounces as the motor state changes, that small motion could well be registered as continued movement.
To prevent this, a quadrature encoder would be required - and thus calling for its own additional circuitry to determine whether the motor was stalled or not.
The alternative would be to use dome form of optical device to detect the net motion of the knurling on the knob.
Now, what device do we all use to detect relative motion?
A clue, most of them are attached to our computers and located alongside the keyboard.
A cheap mouse will do the job, and ten minutes effort with Google provided sufficient information to be able to, theoretically, access a USB mouse directly from software.
Edit:
I have now tested this idea - and, not only does it work, but it detects the three microswitches, too!
Because of the way Plug 'n' Play works, multiple mouse devices are separately enumerated, and their names placed in the appropriate directory
/dev/input/by-id/
The python program that is used as a proof of concept is:
#!/usr/bin/python
# Core logic courtesy of PeterO on the Raspberry Pi forum.
# http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=80987
import struct
import binhex
# You'll need to find the name of your particular mouse to put in here...
file = open("/dev/input/by-id/usb-192f_USB_Optical_Mouse-event-mouse","rb")
while True:
byte = file.read(16)
# h = ":".join("{:02x}".format(ord(c)) for c in byte)
# print "byte=",h
(type,code,value) = struct.unpack_from('hhi', byte, offset=8)
if type == 1 and value == 1:
if code == 272:
print "LEFT PRESS",
if code == 273:
print "RIGHT PRESS",
if code == 274:
print "CENTRE PRESS",
print code
if type == 2:
if code == 0:
print "MOVE L/R",value
if code == 1:
print "MOVE U/D",value
if type == 0:
print "Clear Event", type, code, value
if (type <> 0) and (type <> 1) and (type <> 2) :
print "other event", type, code, value
While I like to build my electronics on custom printed circuit boards and, indeed, have the software to do so, it tends to be somewhat expensive - especially should any error be made in the board design.
Since it is unlikely that this electronic design will ever be anything but a one-off, I have decided that I will be building using either proto-board or strip-board.
That is, to say, AFTER testing the design out using breadboard!
The mechanism has an extremely free operation and the end stops cause the knobs to continue to rotate through use of a fairy stiff friction clutch.
The output torque of a stepper motor is roughly proportional to the current through the windings, and thus to the voltage of the electrical supply.
The motor that I have has 40Ω windings, and is designed for use at somewhere around 20V - therefore, it would be possible to drive the stepper at a lower voltage, set so that the motor stalls at the end of the focus mechanism's travel.
![]() |
| Preliminary circuit design - stepper controller |
Stalling a stepper motor (difficult to do when fully powered) doesn't damage the motor or the drive circuitry (one of the reasons for my choice of stepper rather than a DC servo motor).
I am still refining the design and features of the board which will be used to drive the stepper motor.
_______________________________
While on the subject of the focus mechanism, I wanted to be able to detect when the motor stalled. One way would be to use an optical encoder, either attached to the motor or to the focus knob, but the problem remains that if the knob bounces as the motor state changes, that small motion could well be registered as continued movement.
To prevent this, a quadrature encoder would be required - and thus calling for its own additional circuitry to determine whether the motor was stalled or not.
The alternative would be to use dome form of optical device to detect the net motion of the knurling on the knob.
Now, what device do we all use to detect relative motion?
A clue, most of them are attached to our computers and located alongside the keyboard.
A cheap mouse will do the job, and ten minutes effort with Google provided sufficient information to be able to, theoretically, access a USB mouse directly from software.
Edit:
I have now tested this idea - and, not only does it work, but it detects the three microswitches, too!
Because of the way Plug 'n' Play works, multiple mouse devices are separately enumerated, and their names placed in the appropriate directory
/dev/input/by-id/
The python program that is used as a proof of concept is:
#!/usr/bin/python
# Core logic courtesy of PeterO on the Raspberry Pi forum.
# http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=80987
import struct
import binhex
# You'll need to find the name of your particular mouse to put in here...
file = open("/dev/input/by-id/usb-192f_USB_Optical_Mouse-event-mouse","rb")
while True:
byte = file.read(16)
# h = ":".join("{:02x}".format(ord(c)) for c in byte)
# print "byte=",h
(type,code,value) = struct.unpack_from('hhi', byte, offset=8)
if type == 1 and value == 1:
if code == 272:
print "LEFT PRESS",
if code == 273:
print "RIGHT PRESS",
if code == 274:
print "CENTRE PRESS",
print code
if type == 2:
if code == 0:
print "MOVE L/R",value
if code == 1:
print "MOVE U/D",value
if type == 0:
print "Clear Event", type, code, value
if (type <> 0) and (type <> 1) and (type <> 2) :
print "other event", type, code, value
_______________________________
While I like to build my electronics on custom printed circuit boards and, indeed, have the software to do so, it tends to be somewhat expensive - especially should any error be made in the board design.
Since it is unlikely that this electronic design will ever be anything but a one-off, I have decided that I will be building using either proto-board or strip-board.
That is, to say, AFTER testing the design out using breadboard!
Subscribe to:
Posts (Atom)





