News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Encoder...

Started by nevraxSMD, March 13, 2014, 04:48:25 AM

Previous topic - Next topic

nevraxSMD

Hi i'm new around here, and also to microsoft assembly.
so.. can someone give me some pointers on how to read data from a motor encoder ?
thansk. :)

ragdog

Hello and wellcome

What for a  motor encoder?

any example or information?

nevraxSMD

this is the encoder http://www.pololu.com/product/2590
in the long run i have to implement algorithm which will enable the crontrol of the motor speed under load... but for now i wanna figure out how to read the data ill be working with...

dedndave

you need a little circuit to convert the phase-encoded data into direction+count signals



the 74LS14 is a Schmitt trigger inverter
they are used to convert the sine-like signals into square waves
the 74LS14 and 74LS74 are low-power TTL devices
probably ok, because the encoder runs on +5VDC
i might use B-series CMOS, because high speed is not required and they use less power
for the Schmitt trigger, you can use a CD4093B (MC14093B) or MC14584B
for the flip-flop, use a CD4013B (MC14013B)

if you use a 9V battery, you can use an LM78L05 3-terminal voltage regulator to get +5VDC

from there, you might want to use a wireless transmitter (serial mode) and a USB dongle
when you get that far, it's not hard to treat the port like a serial COMM device for communications

nevraxSMD

oO, well that clear;s a few things, i was wondering how get a proper signal.
umm and i have to use a paralel port, the hole thing has to be controlled with the help of a board - EVZ3
thank you  :biggrin:

dedndave

well - if you have to use a parallel port, you have to
i thought you might be making a remote robot or something   :P
it would really sux to have an LPT cable following it all over the place - lol

i have no experience programming for the parallel port,
but it may be very similar to a serial port

nevraxSMD

nope, nothing too fancy, but still as i start thinking what i need to do to make it work, and how troublesome is gonna be to program ... meh is gonna a be a challenge....

dedndave

74LS TTL might be a better match for a parallel port
i can't recall ever using CMOS with a parallel port - i'd have to re-visit the spec-sheets

where do you plan on getting power ?

would have been easier in the old days
the ideal situation might have been to generate interrupts for each clock pulse
can't do that so easily under NT windows

soooooo.....
you might want to add a counter to get speed in a parallel fashion

nevraxSMD

exactly how is the 74LS14 connected to 74LS74, cuz the datasheed shows a different pin out :D

umm a 5v, 1A phone charger, worked great on powering some 5v boards that i used :D think it should do the job

dedndave

you're right about the pin-out   :t

one input goes to Clk (Clock), the other goes to D (Data)
the Q output gives you direction ("Q not" gives you the opposite logic level)

a 74LS74 has 2 flip-flops per package
you can use either one - unused D/Clk lines should be grounded
Set and Clr lines may be left open (in TTL, that is interpreted as a 1)


dedndave

what is the maximum RPM of the motor ?

are you going to use the 12-counts-per-rev wheel or the 20-counts-per-rev wheel ?

nevraxSMD

1000rpm or 625rpm , i'll place the order when i know al the parts that i require.
umm and i dono.  i'm not sure whit what type of wheel the kit comes.(i'm buying from a local suplier..)
but i think i'll go with 20 counts, is it safe to assume that is gonna give a better read?

dedndave

the data sheet says it comes with both wheels (3 tooth, 5 tooth)
you select what you need based on desired resolution

if you used a 1000 RPM motor and a 5 tooth wheel, you'd get a maximum frequency of 20 KHz
well within the rate of CMOS devices

however, TTL devices have a little better drive capability (more compatible with a parallel port)
CMOS and LS TTL circuits can be mixed rather nicely, too   :biggrin:

dedndave

i think i'd use two 8-bit binary counters, with a 1 second gate
when you read the low-order counter, the data from the high-order counter would be stored with an 8-bit latch
that way, the value read in the high-order byte coincides with the low-order byte
then, write the code so you always read the low-order byte first

dedndave

after a little more thought.....

using a 0.5 second gate might be a little better
you'd get RPM, to 0.1 RPM resolution, updated 2 times per second