Universal Motor Speed Control

[Bridges]

Thanks Allan for your time in explaining things to me.
Today I have had some success with the LM2917. I made up a 2 lobe optical encoder disk and that worked fine with my modified power supply. If I had looked more carefully at the data sheets then I would have bought the 14 pin version with floating inputs. I copied the basic version as shown in the data sheet and it said the output with an 8 lobe encoder was 67hz/volt. Therefore 330hz would be 5v. With my 1 magnet in the collet holder and the hall effect sensor. at 10,000rpm I measured 168hz. Therefore 2 lobes would give me 336 hz and that should generate the 5V output I wanted. For simplicity I abandoned the hall effect in favour of the earlier inductive pickup and made a 2 lobe encoder and sure enough at 3,000rpm I get 1.70V and at 10,000rpm I get 6.15V. The main board I made has a preset resistor I can adjust to get 5V at 10,000rpm. So the next thing I plan to try tomorrow is the whole system using the LM2917. I will be back with results. Photos are of the 2 lobe encoders i am using.
This router is a very different performer than the larger washing machine motor and stops very quickly. Maybe 2 or 3 seconds
ps. Yes I do use the PICaxe Editor's Simulator. but I don't know and haven't found any instructions on how to insert or change values. I did prefer the older version because it stayed at the top of the screen instead of having to keep opening it every time I step. I will try to reload the older version as you suggest.
Thanks again Allan

 

[AllyCat]

Hi,

AFAIK the only formal documentation for the PE6/Simulator is the original PE6 Beta Release Briefing Page 9 (to interactively set the input/variable values). Otherwise it seems to be a matter of searching the forum for a few hints, probably in a relevant post from hippy.

Using the inductive sensor gives the LM2917 some "added value", but I think the 8-pin version should be sufficient. Section 10 of the Data Sheet gives some indication of how to adapt the external component values, e.g. for the required volts/rpm : The ratio of the capacitors on pins 2 and 3 will set this sensitivity, but (for good stability) I think you might need to reduce either the value of R or C on pin 3 to make the (PICaxe) feedback control loop faster-acting.

Cheers, Alan.

 

[Bridges]

Finally back to the project after a few days working. Since I am now back to using an inductive sensor as opposed to the hall effect sensor, I have decided to abandon the LM2917 and return to the design of #53. I really liked the simplicity of the schematic and the big improvement with the mosfet driver. I hope to be back to testing again tomorrow and will return with more.

 

[AllyCat]

(From post #72)
......... the speed sensor I have been using has failed and I am unable to find anything that will substitute for it so I will need to use a hall effect sensor to measure the speed ......

Hi,

At post #53 you were using a Tacho generator; does post #83 mean that you have now found a substitute, or are you hoping to use just a pickup coil in place of the Hall sensor? An advantage of the Tacho was that it produced an analogue (i.e. numerical) value for every revolution, apparently with an output frequency (or "sampling rate") up to 1200 Hz (at 10,000 rpm, equivalent to 167 Hz, from the photos in #67), so more than 6 "updates" per revolution. Even then, I was considering ways to "improve" the Tacho sensing (e.g. by using full-wave instead of half-wave rectification), but didn't proceed any further, if it was no longer available.

A useful feature of the LM2917 is that it has an integrated high-gain amplifier/comparator to detect the small signal from an inductive (coil) sensor. However, ALL the present PICaxe chips have an on-chip comparator, but not usually supported by the Operating System, so may need some slightly more "advanced" programming. But, as indicated in the previous paragraph, I think a good speed-control loop will need to receive a "continuous", accurate (and not excessively delayed) analogue (numerical) indication of the motor shaft speed.

Cheers, Alan.

 

[Bridges]

At post #30 the inductive pickup I was using with the router failed so I had to use another motor, the washing machine motor, which has a build in tacho. Now I have secured another inductive sensor, as shown in post #81 and have gone back to working with the router motor. Since the inductive sensor will work directly into the 0M2 I decided there was nothing to be gained from using the LM2917. Another reason is that the LM2917 doesn't work to well at 5V but needs at least 9V Vcc to produce the 5V output. If more pulses from the sensor will produce better control then I can make a new encoder ring with more segments. It's simple for me to make.
Regarding the advanced level of programming, unfortunately I don't have that skill and already struggle with those you have been kind enough to write for me.

 

[AllyCat]

At post #30 .... the washing machine motor, which has a build in tacho. Now I have secured another inductive sensor, as shown in post #81 and have gone back to working with the router motor. Since the inductive sensor will work directly into the 0M2 I decided there was nothing to be gained from using the LM2917. .... . If more pulses from the sensor will produce better control then I can make a new encoder ring with more segments. It's simple for me to make.

Hi,

Thanks for the clarification, I hadn't appreciated that the "Tacho" was built into the (washing machine) motor. That's perhaps why it was a very "good" sensor, with lots of scope for development: It generated a "pure" sinewave at a significantly higher frequency than the motor's rpm and with a (peak to peak) amplitude proportional (approximately) to the motor's speed. As it was built-in, the output frequency might have been an integer multiple (perhaps 8) of the motor rpm, but even if not, it probably would give a very consistent (smooth) output frequency (throughout a single revolution). Although you were rectifying the (peak) amplitude of the sine wave (and reading it with an ADC), it would have been possible to measure the frequency directly (with PULSINs) and with a sampling/update rate down to about 1ms (at 10,000 rpm). Even so, there appeared to be some issues with the stability of the speed control loop?

The 'scope photo of the new sensor seems more confusing because it is so "spikey"; I would NOT have expected a "pure" sinewave from a simple "magnetic search coil", but I would expect a much more "rounded" waveform than shown. Presumably Channel2 was the output from the LM2917 (6.12 volts d.c.) ? A "zoomed in" view across the width of a single Channel1 pulse, and of the 400 mV pk-pk a.c. ripple (=7% ! ) of Channel2 might be helpful. The alternating heights, particularly of the positive pulses, in Channel1 hint at the problems of creating multiple "timed events" within a single rotation, and clearly any attempt to detect a voltage proportional to the rotational speed is unlikely to be successful. In fact the (assumed) variation of amplitude with rpm is likely to make (the choice of a threshold level for) the accurate measurement of the time duration between pulses more difficult.

The 'scope's displayed calculated data appears to have assumed that the gap between the higher positive pulses represents a single cycle/rotation (166.1 Hz). But the "Duty Cycle" (52.18%) is puzzling because this ratio normally represents a "pulse" width relative to a "gap" or cycle time. Here, it's perhaps related to the gap(s) between the higher and lower amplitude positive pulses, again suggesting the difficulty in achieving accurate sub-divisions of a single revolution/cycle. "52%" might seem quite a precise value, but represents a 4% "noise to signal (rpm) ratio". Also, 'scopes can have quite sophisticated averaging and analysis algorithms; even the PICaxe Store's humble PCB Scope can do a "Fast Fourier Transform" (although at best, only a few times a second, and with the help of Windows ! ). Thus I have highlighted (in bold) a section in the quote above, because I wonder how much useful data a PICaxe program can extract from the "spikey" input waveform.

To summarise, I think we need to clarify the stability of (and reasons for) the widths and amplitudes of the the "spikes" generated by the new sensor. My inclination is that it will be necessary to measure over a full revolution of the motor shaft and hope that this gives sufficiently fast sampling/update rate to stabilise the control loop. The measurement might use either PULSIN for both the Pulse and its associated Gap (unless the Pulse is always very narrow) or (the equivalent of) a COUNT of at least 50 segments on a rotor ring (perhaps with some "tricks" akin to the vernier scale found on a micrometer or mechanical calipers). But my concern with the magnetic rotor is that even a tiny eccentricity can introduce very significant variations in the "air gap", which nearly always dominates the behaviour of many magnetic circuits

Cheers, Alan.

 

[Bridges]

I ran into lots of frustrating problems yesterday because the new inductive sensor just didn't produce pulses as the previous one did. The reason I discovered much later is that it is not magnetic as the previous one was, even though they look identical, so I have reverted to using the magnet and getting one pulse per revolution. Prior to this I again tried the Hall effect sensor A3144 and the O8M2 but it didn't work as well as the original inductive sensor so I have abandoned that. Then just as I have it running again properly the Mosfet failed. I now have 800V 20A ones fitted. I think that I am going to stick with what I have now and will focus on fitting the motor and putting it to work. If it proves unsatisfactory I will return to the forum.
Thank you to everyone who has helped me, especially to Fenando_G for mosfet drivers, inglewoodpete and AllyCat for their patience and especially for showing me how to improve my programming, the importance of noise and filtering plus new ideas. There is just so much to learn and be excited about even though I'm and old person now.
Regards,
Bridges