Shop OBEX P1 Docs P2 Docs Learn Events
dc motor rpm control and display — Parallax Forums

dc motor rpm control and display

stefansailorstefansailor Posts: 2
edited 2006-11-04 21:59 in BASIC Stamp
Hi Friend,

I learned about this BASIC Stamp think TODAY! when I talked to a Swis sfriend (I live in Switzerland) and I think I could use the Basic Stamp to solve my problem in a costeffective way. Now I just need your professional advises and help (Thanks in advance to all forum members for your kind support!)

I am developing a very simple dc motor controller with an rpm display. I assume many of you have already tired and solved this problem. Are there any free documentation around? any links? any posts?

My setup:
- dc motor, +/- 24 V, max 2 Amps, max 20'000 rpm
- I use Hall sensors for signal generation (left/right; 0-100% rpm)
- I need a display (rpm and bar graph i.e. % of max rpm). I found this "catalogue application" which I like very much http://www.parallax.com/html_pages/robotics/machining/RPM_display.asp

Here is the plan:
- use a motor mind B controler (specs are ideal!)
- use a basic stamp board
- use a basic stamp 2 ic
- use a Noritake VFD display (2x16)

Now I just need to know how to connect these and get the controller up running!

Does anyone have a read setup? any ideas on how to solve this?

Thanks a lot for any advise and help,

Regards, Stefan
Zurich, Switzerland


freaked.gif

Comments

  • stefansailorstefansailor Posts: 2
    edited 2006-11-01 20:21
    Hi again,

    I forgot to add the following information:
    - the rpm to be displayed will be calculated based on the motor voltage supply and the voltage/rpm constant (no need for a tacho)
    -
  • Dennis FerronDennis Ferron Posts: 480
    edited 2006-11-02 19:22
    stefansailor said...
    Hi again,

    I forgot to add the following information:
    - the rpm to be displayed will be calculated based on the motor voltage supply and the voltage/rpm constant (no need for a tacho)
    -

    So I assume you are using the back emf voltage to determine RPM? For the motor controller for one of my robots, I did an experiment where I tested the relationship between back emf and rpm. I had assumed it would be constant. Instead, the back emf for a given RPM was actually HIGHER when load was higher. However, I was using a belt driven mechanism between the motor and the RPM encoder plus load. It is possible the belt was slipping and the motor was turning faster than the measured RPM when under load. However, it may also be that the amount of magnetic energy stored in the coils themselves was greater underload, and hence produced a higher back emf when the motor supply was shut off for measurement of the back emf.

    I'd be very interested in your results. Also, have you thought of using the voltage spike which occurs when the motor brushes change coils on the commutator as a way of determining RPM? I believe I can do this with an op amp configured as a "rate of change detector" (i.e., measure the derivative of the signal not the actual value) but I haven't tested it yet.

    Incidently, I used a Basic Stamp 2 sx and an LCD display show RPM for my motor test rig. But I used an optical encoder to measure the RPM I displayed (so that I could compare it against the back emf measurement I made with other equipment). I don't have the source code handy but I'll post it later. I also have a research fair poster I made about it.
  • Dennis FerronDennis Ferron Posts: 480
    edited 2006-11-02 19:56
    Also, IMO the motor mind B has some horrible design flaws. For one thing, it would have been very easy to make it so that you have a "forward" and "backward" command. Instead, the designers put in a "reverse" command that simply toggles the direction of the motor to the opposite of what direction it was in before. But there's no way to query the motor controller to find out what direction it had been in before!! So how do you know which direction it is going if you reverse it a few times? You'd have to keep track of it in software but what if your software got out of sync? What if the basic stamp gets reset and the motor mind does not? Now it is impossible to know which way the farking motor is going to turn when you turn it on!

    Their manual shows you using a shaft encoder with the motor mind to find out which way it is turning. This is stupid - some applications wouldn't need an encoder, if only the control protocol would let you be sure which direction you were specifying. What if you were using it in an application where turning the motor the wrong way could damage the physical mechanism? Then you'd have to risk a few tenths of a second damage to find out which way the motor is turning. Or perhaps your robot might roll off the edge of a table while it tries to figure out which direction the motor mind is going to go.

    Add to that the fact that the manual warns that the required communication speed will depend on temperature - they probably aren't using a crystal for their microcontroller clock and haven't heard of temperature compensation. They expect you to make your Basic stamp software changes *its* baud rate to match the motor mind's temperature: ok, so how is the basic stamp going to know what the motor mind's temp is? Jeez.

    And they didn't add a reset pin. This wouldn't be so bad except the controller often stops responding - probably the temp compensation issue - and has to be reset to reinit the baud rate! They require you to put a power switch to cut power to the motor mind to reset it. Um, excuse me, I'm using an integrated motor controller to avoid having to build discrete power electronics - this switch is going to have to be a piece of power electronics, a power transistor or relay, and it is only necessary because the motor mind b designers screwed up. So what's the point of using the motor mind if I have to include another piece of power electronics? I could have controlled the motor with a MOSFET directly then (if I only needed one direction that is).

    The motor mind B can also damage your Basic Stamp! I had the motor mind on a separate board from my Basic Stamp. The on/off for the motor power board was in the ground side instead of the + side. Dumb setup, I know (never gate the ground on a digital circuit), but it certainly doesn't excuse what the motor mind module did in this scenario - it seems that if you interrupt the ground connection to the motor mind, the module passes the full 15 volts motor supply current, and up to 2 amps, through the digital serial communication pins!!!! There is no protection there at all. I don't know if they have their motor output connected back to a microcontroller input which busts through a diode to the serial comm pins, or what weird thing they are doing, but basically without the ground bias their module will dump motor voltage onto your digital lines. It fried the basic stamp I had connected to it.

    Generally I have been very impressed with all products Parallax sells on their site EXCEPT this one (it is actually manufactured by a third party, Parallax just resells them). I noticed there is now a motor mind C, which may have fixed the problems in the motor mind B, but I haven't tried it - after the motor mind B I'm not exactly rushing out to buy any other solutions cubed products.

    I've had a lot more success using the motor controllers from the Pololu company with Basic Stamps; they work perfectly together. If Parallax sold Pololu controllers (hint hint smilewinkgrin.gif ) then I would just order the two of those together.
  • Bill ChennaultBill Chennault Posts: 1,198
    edited 2006-11-03 02:51
    Dennis--

    For exactly the reasons you stated (I think; I am a newbie), I bought the L298 Compact Motor Driver Kit from Solarbotics. (It has not arrived, yet.) My research leads me to·believe it addresses all the problems of the Motor Mind B and possibly more.

    Do you have experience with this device? Or comments? I do not mind making a financial mistake; I do mind making one I could have avoided by simply asking someone more knowledgeable than myself, though.

    --Bill

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You are what you write.
  • Dennis FerronDennis Ferron Posts: 480
    edited 2006-11-04 06:48
    No I haven't used that one. I don't know if it is good or not but I think it could be ok depending on your application. Note that it doesn't include it's own PWM - you will have to do your own PWM in software. The motor mind and similar controllers include a PWM controller which is essentially a small microcontroller on the motor controller that you talk to with serial data. The solarbotics module you have there does not have an integrated controller - it only outputs what you tell it to output with no automatic operation. Again, depending on your application this could be good or bad. On the one hand, it ties up your microcontroller; on the other hand, there is no worry about badly designed serial protocols because there won't be any serial protocol at all - it's just an output device, somewhat like a relay - there's no real "data" involved.

    Post Edited (Dennis Ferron) : 11/4/2006 6:52:53 AM GMT
  • Bill ChennaultBill Chennault Posts: 1,198
    edited 2006-11-04 21:59
    Dennis--

    Thank you for your insight. Of course, I completely missed the fact that is has no PWM. Although I wish it had, my application--at least the one I have in mind--really does not require it. (If I turn out to be wrong, then the 18 bucks will be written off to experimentation!)

    --Bill



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    You are what you write.
Sign In or Register to comment.