A worked Servomotor example

Axminster should be able to either give you the information you need or point you at the manufacturer for it before you buy. Most capable manufacturers these days leave PDF copies of their manuals etc on line.

Last I saw digital calipers and micrometers being used hooked up it was when I spent a short time making Break Linings with Ferodo at Chapel-en-le-frith the in the peaks.

They had them hooked up to cheap workstations dotted around the factory, when you were grinding or machining friction components out of feedstock you had to go and measure so many out of the batch to prove they were up to the required quality standards. The results were stored in a database on the PC for back checking and audit purposes.

The connection to them appeared to be straight into the usual RS232 serial port via a custom connector at the caliper/micrometer end.

Hope this helps

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I've started doing a little clunking around with mouse navigation sensors and just wanted to drop in my tuppence worth. I took a look at the Cypress Ovation Laser Navigation Sensor datasheet and while it's looks great on the resolution I have noticed that these things lose/miss pulses. The problem I can see with the Cypress setup is that there's no way to read the image data from the optical sensor to be able to verify its reported values. These chips usually aren't meant to be used this way. Which hasn't stopped me trying to work around that .

If you have the sensor mounted over a gray encoded encoded strip, you can always read the image data to get a better idea of placement rather than relying purely on the offset data. That way you can recalibrate the sensors position without having to home the carriage.

I'm using an Avago ADNS-5020 for testing hooked up to an Arduino, later I expect the entire code would fit into an ATTINY. I'm using this because I had a spare mouse handy that I could rip to bits. The ADNS-5020 has an image array of 15x15 pixels and has a movement resolution of 1000cpi. Looking at Avagos' products, they also have laser navigation sensor that gets 1600cpi with a 26x26 pixel image sensor (ADNS-7550).

I'm finding that the way the image reads out, if the sensor is moving it would probably be better to read a single line of image data due to the amount of time it takes to read. Then when stationary a whole image could be read for an accurate placement read. This would mean having one sensor for reading each axis rotated so the imaging sensor Y coordinate is perpendicular to the movement axis in the case of the Avago sensors.

Alternatively a codewheel on the back of a motor could be used, although I'm not ready to test that out yet.

As for SPI, I have written code for the Arduino, although it's not yet in a library form and still a bit messy from where I was learning that a 16Mhz proc talking at 1 Mhz needs to slow down somewhat.

aka47 Wrote:
-------------------------------------------------------
> Hurro Zach
>
> The design that is currently floating about mostly
> in my head has the ability to accept inputs from
> two types of encoder.
>
> 1. An SPI interface that can talk to the Laser
> Navigation (mouse type) optical sensor. See the
> Wiki page bibliography for the Cypress Data
> Sheet.
>
> 2. A Logic Level Quadrature Interface. What you
> choose to make the quadrature stream is up to you.
> Magnetic (Maybe the chip Vik was looking at),
> Optical reflective or photo-interupter etc etc
> etc. I have'nt put the Datasheet for the chip that
> Vik was looking at on the Wiki yet but will do so.
> Probably tomorrow now.
>
> 1. Has some particularly useful advantages over
> 2.
>
> At the end of the day a Universal Servo Controler
> should be able to manage enough variety to enable
> as much end user experimentation as we can
> sensibly accommodate. I think that there are often
> many ways to do something and folk prefer that
> which is to hand and inexpensive for them
> (Unfortunately not the same for everyone).
>
> Without looking at the files just yet, does your
> magnetic circuit output a quadrature stream ??

Sorry for the lack of visible progress on this front for a little while.

I have been distracted into getting some sort of test bed up and running, repairing some of my machine tooling and scraping together some access to machine tools I don't have. As well as begging borrowing or if desperate buying bits and pieces to look at whilst designing in my head (It really does help the process of visualization to be able to look at something and hold it for real).

All an

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The CNC world has standardized on a software/hardware stack with clear interfaces:

* Design: AutoCad or others
-> shape: .dxf, .stl, ... ->
* CAM software: lots of choices
-> toolpath: gcode, gerber ->
* CNC control: EMC2, Mach, Dedicated controller, ...
-> motor/tool control: step/dir, pwm ->
* Motor drivers: lots of choices
-> motor/tool driving: current chopping, commutation, limit sense, ... ->
* Motor/tool: stepper, servo, spindle motor

EMC2 is built like any good unix tool; Do one thing only, but do it very good. It sits between the gcode interface and the motor/tool control interface. It doesn't understand shapes, just toolpaths. It doesn't understand how to commutate a motor, it just sends commands to the motor drivers. Extending EMC2 to understand .stl files is not necessary, there are already tools for that.

RepRap gen1 uses almost the same stack:

* Design: Art of Illusion
-> shape: .stl ->
* CAM software: RepRap host software
-> toolpath: internal format ->
* CNC control: Stepper controller
* Motor driver hardware: Stepper controller
-> motor/tool driving: commutation, limit sense, ... ->
* Motor/tool: stepper, extruder

As you can see there is an interface missing, and the toolpaths use an internal format. And there is a very nice extra as well, the extruder. One of the two key parts of RepRap (the other is the printable bot structure).

The missing interface is added with the gen2 controller, and there is some experimental software for gcode toolpaths as well. This add an enormous amount of flexibility to the project. Just the addition of the step/dir interface makes it possible to use almost all of the motor drivers of the cnc world (I use SparkFun's EasyDriver for instance). The addition of gcode allows you to use KiCad/AutoCad and EMC/Mach to control your McWire and do light milling/pcb milling. Or use any cnc mill as a RepStrap (when the extruder control gets sorted).

Adding the Arduino to the HAL of EMC would help that project a lot, since parallel ports are a dying breed. This would allow you to reuse the stewart and scara code. But it would be a bit of a waste as well, since the Arduino can handle G-code by itself. Better use a usb->parallel port converter for that.

--Blerik

Thanks for that Blerik, much apreciated.

Something that's not clear in my mind. Or at least I think it could be but am not sure.

EMC2 can control directly at PWM level for Servo Motor Control, (The thing I am currently working on) The Current RepRap stack has no Servo Control capability at all...

ie no PID or Positional Feedback ...

Is this true ???

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

The current RepRap stack has no servo driver in it. But using the Arduino you can still control some servo drivers. Some servo drivers understand step/dir, and do all the PID stuff internally. Position feedback up the stack is more difficult, but not really necessary, since the driver keeps position itself, so it is like a stepper that never looses a step.

So you have two choices. Create a servo driver that speaks step/dir and does all the heavy lifting itself (using a PIC or an Arduino or whatever), or connect the servomotor and encoder to the Arduino directly, and have the Arduino do the pwm, quadrature decoding, and PID. That will eat pins though.

You can always check the diy cnc forums to see if somebody already designed a driver for you.

--Blerik

Thanks for that Blerik

I was wanting to be sure that the Step + Driver servomotor controller board with additional high level access wasn't already duplicated elsewhere (would have been a waste of effort).

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Well, it has been duplicated countless times before all over the place. But most of those implementations are closed, and the few that are open have all kinds of pros and cons. So creating a servo driver from scratch isn't always a waste of effort, as long as you first learn from the others.

I have never seen a servo driver that uses a camera for positioning, so that would be novel. And a simple servo driver that uses a digital caliper for positioning would be new as well. I haven't seen servo firmware for the Arduino, so that is an option.

Try this thread on cnczone: [www.cnczone.com]
And this whole subforum: [www.cnczone.com]

--Blerik

Hehe, I'm still working on using the mouse camera as a positional feedback element, just very slowly as I just finished working on one axis for my repstrap. Once I have something positive and tested I'll make a new post in the mechanics forum. I have been getting images back from the sensor and trying to work out issues with optics and the best material to be used for a readable strip. It is looking fairly promising and should have my test rig built up by the end of the week with pictures and hopefully some test runs. All the sensor parts are available from mouser and come to a total cost of under $2, a microcontroller and PCB to run it would add more, but I'll get there if this method is viable.

My feeling is that having positional feedback further away from the motor (be it stepper or servo) and closer to the bed being moved means that it's easier to compensate for backlash in the drivetrain (I hope). I think though that using a digital caliper would be a much better idea if the costs aren't too bad, I'm hard pressed to rip apart my digital calipers just now until I can get a replacement set authorized by the wife

From what I have read about how digital calipers work it should be possible to make them without the caliper. ie just PCB/s.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

andy:

now that i've gotten into GCode, i'm thinking that EMC may actually be the way to go. i feel that i still have quite a bit of mileage left in going the arduino route, as well as using the host software, but my gut feeling is that eventually we'll say... hey, these guys wrote some kickass software, so lets start using it.

one nice thing about doing it our own way first, is that we are learning lots while doing it.

Something I thought of, but am not able to experiment on, would be using cheap magnetic tape, along with a gang of crudely placed magnetic sensors, for position measurement.

If you can get your hands on a couple pieces of magnetic tape, attach them together then drag them apart. The way the stuff is made seems like it'd be a nice "optical stripe" for a magnetic sensor. Throw in enough, not perfectly aligned, in fact, ideally, each aligned to a multiple of a different prime number, and you should be able to measure movement to a very fine degree.

Of course, you could do the same thing with a few optical sensors, a printed strip, and an LED, but I think the magnetic stripe would be more tolerant of grime without becoming rapidly inaccurate.

Add in an extra sensor to feel when the device passes centerpoint, or reaches the end, and let it self-calibrate.

As an aside, you might be able to do this trick with a few old cassette tape read-heads, but I wouldn't swear to it.

And yes, ferrous materials would gunk up the stripe, but not as quickly as dust would obscure an optical stripe. Slower, in fact, as only ferro-magnetic materials would be problematic, not just anything that could hold a static charge and wasn't perfectly transparent.

Hmm, mag tape, that's a blast from the past. I have an uncanny feeling it'd work really well, unfortunately I can't experiment with that yet as all my old junk is in another country.

Just for kicks, a stereo double sided cassette tape head will have 4 pickups on it and the old cassettes ran at under 2 inches a second, some even approached 20khz at the top end of the dynamic range. It is possible to squeeze 1k bits into 1 inch of mag tape and if you use all four channels with some kind of gray encoding (1 bit changes at any transition point) the resolution should be good for 1/1000 of an inch, maybe even more as I'm being fairly conservative in my estimates. This might need a bit of dsp work. A new use for those old walkmen! I know I'm going to have home and limit detects on my carriages so auto calibration would work.

As for gunk, almost every type of position sensor on the carriage is going to be subject to gunk pollution, although I think with the right engineering, the digital caliper method would be the most durable against pollution and the pcbs could be hidden within the joins between two surfaces (if I'm thinking about how the calipers work correctly), though to verify I'd have to possibly sacrifice mine.

Edited 1 time(s). Last edit at 02/19/2008 11:12PM by skirmish.

Hi skirmish,

... the idea with old walkmen or taperecorder-heads sounds brilliant!

Then it's worth thinking about CD- or DVD-drives as rotary or 2D-polarcoordinate-encoders too.

In the past i was playing with the idea of triangulating sound-waves in a base-plate, where i'll inject three different pulse-sources at the edges of the plate and a piezo-microphone in the toolhead would sense the time-difference for triangulating it's position.

I think with highspeed-DSP and a glass-fiber or -rod with injecting short enough light-pulses at both ends you can make the same run-length-encoding with sub-micron accuracy, when needed

Viktor

A potential problem I see with using mag tape is that the voltage it produces is proportional to speed so there will be a minimum traversal speed below which you miss pulses.

---

[www.hydraraptor.blogspot.com]

Mag tape used to be the favored data carrying medium for Key Cards and Credit cards etc and suffered like all magnetic media from its suceptability to corruption from stray magnetic fields.

Not very durable, and once corrupted in situ will be a pain to reconstitute.

It was once standard practice for Hard Disk Drives that had Voice Coil Actuators to dedicate one of the platter surfaces to a magnetic servo trak so the heads could find the same track every time.

Corrupt or damaged servo tracks though left you with all your data irretrievably gone.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Anyone can suggest the good web site 4 DC servo motor driver. Actually, i want driver that can drive 12V DC servo motor and can be connected with PIC.