Author Topic: A digital governor for model engines  (Read 17998 times)

Offline Jasonb

  • Full Member
  • *****
  • Posts: 9489
  • Surrey, UK
Re: A digital governor for model engines
« Reply #105 on: May 20, 2020, 07:35:01 AM »
Thanks for the update Willy, confirms what I said and also the same as both editors comments to me when made aware of the thread.

The 4 whole pages from Model Engineer without permission are considered well in excess of "fair use"  and as Jo points out the terms when registering state not to post copyright material unless you have permission. A single picture, paragraph, part of a drawing or similar would tend to be considered "fair use"

Did not mean to have a go at anyone but there may be new members who see a post with 10 pages from magazines, don't know 3 were posted by the author and then get the impression it is OK to post this sort of material.

Online Jo

  • Administrator
  • Full Member
  • *****
  • Posts: 15305
  • Hampshire, england.
Re: A digital governor for model engines
« Reply #106 on: May 20, 2020, 07:52:04 AM »
I do not agree with your interpretation of Copyright Jason, each case must be considered in context.

In the future if any one has any concerns about a post could they please use the "Report to Moderators"  feature, rather than taking it upon themselves to police our forum. Thank you.

Jo
Enjoyment is more important than achievement.

Offline MJM460

  • Full Member
  • ****
  • Posts: 1648
  • Melbourne, Australia
Re: A digital governor for model engines
« Reply #107 on: May 20, 2020, 12:04:09 PM »
Hi Jadge, thanks for that explanation of how the 7805 works, it’s very helpful.  I have seen the circuit of the 7805, but it was beyond me.  A bit intimidating and hard for someone at my level to work out where to start, but at least I have seen it.  Thanks also for the explanation of the output capacitors.  Between you and Don, I am learning a lot out of this thread.  I would love an oscilloscope, but hard to justify for the number of times I actually need it.  I need a neighbour with one!

Hi Admiral, the Picaxe version of the 8 pin PIC chip has only two accessible ADC blocks.  I don’t know about the base chip.  There are definitely compromises in providing the simple interface for beginners.  I use one ADC for the speed set point input as you have noted, and have now learned how to free up a pin to give me access to use it for proportional band.  The issue for the I is the way I understand it requires a timer, and I am already short of those as I have described.  I am thinking I might be able to implement it using a count of program loops as a proxy for time, even though the loop time is variable with engine speed due to the time taken to measure the input pulses.  Still pondering the need for I while I carefully observe the governor behaviour now that at last I have it working.  If I do add the I function, I agree it will need some tuning.

For those unfamiliar with the terminology, I is for Integral, in the calculus sense.  It takes into account the time over which an error has existed, and uses that to boost the correction.  It reduces/eliminates the error inherent in a proportional only system.

Hi Don, I inserted the diode in conjunction with that extra 2000 mF capacitor to maintain power to the processor through any voltage drop in the supply.  My thinking is that if the servo draws a brief current transient each time the motor starts, that capacitor might carry the processor through.  Whereas I understand that beginners  who don’t have an adequate power supply have trouble with random processor restarting due to this issue.  The diode then is intended to prevent the servo drawing on the energy stored in the capacitor.  Of course that idea is based on an ideal diode and an adequately large capacitor.  The performance of the real components I have selected may vary.

As I take in more of what you and jadge are saying, I think that once I include the recommended capacitors associated with the regulators, I am still trying to deal with ripple from those motor transients rather than pulses due to more switching transients from whatever source.  Obviously a servo starts moving often rather than running continuously, though motor commutator sparking also has to be dealt with by capacitors on electric motor driven models, and I assume also internally in servos.  With my governor valve imposing such a small load, it may not be a big issue in this case.

Thank you so much for your support.  You will appreciate that this is not a complex build by the standards of this forum.  The challenge is to devise a concept to make a working governor, similar to the digital electronic governors that are replacing the flyball type on today’s industrial machines.

It’s been pretty heavy going at times to get to the present status, so today I decided to take a break play”.  But I will write about that in a separate post.

Thank you all for such interesting and helpful comments.

MJM460
The more I learn, the more I find that I still have to learn!

Offline MJM460

  • Full Member
  • ****
  • Posts: 1648
  • Melbourne, Australia
Re: A digital governor for model engines
« Reply #108 on: May 20, 2020, 01:57:08 PM »
As I mentioned in the previous post, I decided to take a break today and have a play, just to enjoy the achievement after quite a long haul.

When I started this project, Craig was encouraging us to live dangerously and post in real time as we go, warts and all.  I decided I was not that brave, but more significantly, I thought my project might get strung out by life events, and take so long that people would forget what it was about between posts.  And sure enough, I have taken a 17,000 km road trip, had a death in the family, been on a summer beach holiday, and now all this since I started the first steps.  One bright side of the current crisis, is that lockdown has enabled me to spend enough time to get the project complete to the stage of working.  So I am now up to date with my posts, this and any future posts will be in real time.

I hope I have however, been honest about some of the challenges, many of which are just inexperience.  I have been severely pushing my knowledge of electronics, which has always been only at the hobby “dabbler” stage for me.  Overcoming these challenges is what keeps us all interested, even though it is very frustrating at times.

I have mentioned a while back about the need for testing the “transfer function”, or the relationship between engine speed and the required servo position.  Again I am trying to use the correct technical term, but I am not sure whether I should use the engine speed as measured by the governor, or the set point speed. 

I also wanted to explore the calibration of the engine speed as measured by the governor, compared with the speed read on the hand held digital tachometer.

Now making a log sheet and carefully taking readings might sound a bit heavy to describe as play, but there is a limit to how long I would be fascinated by watching the engine run at different steady speeds while adjusting the set point occasionally.  A bit like a video of the servo hardly moving with breaks to the display for excitement.

For the transfer function, I recorded the set point speed, the Displayed speed and the servo position as calculated by the controller.  I had an extra column for the digital tacho reading, and I did a series at each of two different compressor settings to see the effect of air supply pressure.  I don’t have anything to use as a load, so I could not do a further test with the engine under load.  Possibly another Meccano project.  Suggestions anyone?

A table of figures can be hard to digest without the additional challenge of reading my writing, so I put readings into a spreadsheet, and used the computer to draw the two relevant graphs shown in the attachment.

As with any test run, especially with manual recording, there is a degree of scatter in the results.  Readings are rarely absolutely steady so taking a reading involves a degree of picking an average of what you can see on the gauge.  The air pressure gauge was the most active, oscillating rapidly over a small range, which actually makes it easier to pick about the centre.  With a constant compressor setting, effectively a blowoff valve pressure setting, the pressure measured at the engine end of the hose decreased a little as the engine speed, so air consumption, increased.  I have not tried to make a graph of that, though I still have the readings if I decide to explore it further.  The variation seemed reasonably in line with what I would expect, and not very great.

The blue series of points was taken at an air pressure reading of nominally 220 kPa(g), say 30 psig.  The red series was at about 100 kPa(g).  Not very easy to set a precise value between the gauge vibration and the coarse adjustment knob on the compressor, but I left the setting constant for each series rather than try to chase a particular reading.  You can see the difference in range of speeds obtained, and also the difference in servo position required for any speed.  All looks pretty reasonable to me.

The trend lines calculated for the transfer function should allow me to improve the maths in the program, a light bit of evening entertainment some time.  But it was clear that my linear assumption was quite good.  I tried exploring whether a polynomial function would give a better fit, but I had to go to six decimal places to get a constant different from zero for the x^2 term, and then it was still 0.1, so linear is more than adequate.  I was really expecting it to depart from linear much more dramatically.  The graph does show that I could extend the low end of the operating range by lowering the minimum governor position to about 120 instead of the current 135.  I will check if the servo linkage will allow this without binding.  I think the engine has loosened up a bit with more running as it would previously not run below 135 position.

You can see that the lower pressure required the servo to open the valve more to achieve a given speed.  An increase in engine load would be expected to move the curve in the same direction, but how much would depend on the load.  Another whole range of possibilities for experiment.

The calibration curve is possibly of even more interest.  This checks the accuracy of my pulse measuring and bladed wheel approach to speed measurement, so of interest for any speed measurement application.  The trend line for this suggests that the calculation is giving a reading about 4% high.  I suspect that is a combination of any inaccuracy in my machining of the blades, and the difference between the exact switching points of both the on and off of the input to the processor and the assumed timing exactly with the edge of the blades.  I will have to give that some thought.  More puzzling is that there seems in addition to be a constant error of about 20 rpm across all speeds.  Another puzzle to ponder during the approaching winter evenings.  No road trip to interrupt this year, unfortunately.  This curve is obviously not affected by the air pressure, so all the points are valid from 400, which was the minimum engine speed with the servo at minimum position, to the maximum achieved with the higher pressure, displayed as 1840 rpm, and reading 1800 on the hand held tacho, are valid for one curve.

With more time to observe today, I notice that the settling to a new speed is reasonably quick despite my earlier feeling that it was a bit slow, and it seemed to settle quickly with reasonable overshoot, and perhaps two or three well damped oscillations before it settled.  Pretty good for a proof of concept. 

Overall a successful day.

Thank you all for following,

MJM460

 
The more I learn, the more I find that I still have to learn!

Offline zeeprogrammer

  • Full Member
  • *****
  • Posts: 6811
  • West Chester, PA, USA
Re: A digital governor for model engines
« Reply #109 on: May 20, 2020, 10:37:16 PM »
Overcoming these challenges is what keeps us all interested, even though it is very frustrating at times.

Indeed. I'm an engineer because I love solving puzzles. That was my job.
My problem is that once I see a solution, I'm pretty much done. It's why I'm a starter and not a finisher.
Once I see the solution, I'm looking for the next puzzle.

Ah the 7805. I've used those many many times. Back in the day.

Anyway, not to hijack the thread. Just letting you know I've been following.
Carl (aka Zee) Will sometimes respond to 'hey' but never 'hey you'.
"To work. To work."
Zee-Another Thread Trasher.

Offline gary.a.ayres

  • Full Member
  • ****
  • Posts: 1297
  • Isle of Skye & sometimes France
Re: A digital governor for model engines
« Reply #110 on: May 21, 2020, 01:18:48 AM »
Hi Admiral, Mum had a pressure cooker years ago when I was quite young.  They are still in vogue here, at least periodically.  The idea is that the food cooks quicker at the higher boiling temperature of water under pressure, and it quite significantly reduces cooking time.  They are basically an aluminium saucepan with an elliptical lid that fits in when then seals with an o-ring to seal on the inside of the rim on the pot when the handles are lined up.  No idea what pressure they operate it,

MJM460

I seem to recall that you can expect about 15 psi from a household pressure cooker. Some people use them as boilers to run small oscillators and the like. Just with it sitting on the cooker hob, and steam oil/water emulsion spluttering all over the kitchen worktop...  ::)

Offline Zephyrin

  • Full Member
  • ****
  • Posts: 769
  • near Paris, France
Re: A digital governor for model engines
« Reply #111 on: May 21, 2020, 07:45:29 AM »
Hi MJM, Nice achievement with your regulator, very pleasant to follow.
I supose that the speed and reactivity of the set up depends on the the size of the flywheel and the load of the engine, of inertia at large...even if the electronic reacts at a quarter of a turn.

We use here the the pressure cooker in the kitchen very often, mainly for vegetable soup, I did not test the pressure but 15 psi seems a good estimate.
I'm not allowed to steam my engines with it, even if I know that it would be a piece of cake for this boiler.

Offline gary.a.ayres

  • Full Member
  • ****
  • Posts: 1297
  • Isle of Skye & sometimes France
Re: A digital governor for model engines
« Reply #112 on: May 21, 2020, 09:30:08 AM »
Great for soup (seals in the flavour), and they make short work of brown rice too.

It's ok to run engines on them, but probably not at the same time as you are cooking food in them.   :)

Offline MJM460

  • Full Member
  • ****
  • Posts: 1648
  • Melbourne, Australia
Re: A digital governor for model engines
« Reply #113 on: May 21, 2020, 01:02:22 PM »
Hi Willy, I do believe I have overlooked your comment on the gramophone.  My earliest recollections do include wind up ones but I don’t remember hand cranked designs.

The propellor would not be a governor, but the torque to drive a propellor varies with the square of the speed, and the power with the cube.  So as you crank the handle faster, when you reach a certain speed the torque and power required is increasing quite rapidly with speed of rotation.  Consequentially, it becomes relatively easy to maintain a steady torque on the handle in that region, and thus approximately constant speed.  But propellors make noise when they are going faster.  I don’t know how they dealt with that, perhaps it helped to cover the scratchy sound quality.  And of course the sound quality, if that is the right word, would also help up you get a feel for how hard to turn.   I imagine that an experienced operator would be able to coax better sound out of the recordings.   I don’t know if they would have had a centrifugal brake mechanism and perhaps a flywheel as well to help maintain an even speed, probably more important than the actual speed in those days.  But it would be interesting to see inside one to see how thy actually did it.

Hi Zee, not hijacking the thread at all, I am glad to welcome you on board.  I am totally with you on that point of when you can see a solution.  It took quite a bit of self discipline to follow this through to being complete on the model steam plant.  Probably helped along a bit by discovering in my Thermodynamics thread that I really needed that stop valve, and the project grew to why not an electronic governor as well.  I am glad that I persisted, as most of the issues arose after I was sure that I could see the solution, both the practical issues of soldering and a rare for me “letting the smoke out”.  And when I finally completed the assembly, I was having trouble with random glitches of the servo.  Tracking that down revealed much more than reading the manual with the syntax of all the commands, and even following all the recommended circuit diagrams.  All my simple tests conducted one or two at a time passed with ease,.  Only when I asked everything to happen at once did I finally discover and eventually solve all the problems and my initial concern with processor speed turned out to be not an issue.  With all that solved, my testing is still revealing better solutions than some I chose.  For example, I followed through to a working controller using pulse times in the logic, and only converted to rpm for display purposes.  I thought that would reduce the processing overhead to keep the job within the chip capability.  But now I see that had I gone to rpm as soon as I had the pulses measured, the system is totally linear, and the maths so much easier, so less processing!  Dividing by the time length of a pulse is quite inconvenient with the integer maths limitations, as well as being non-linear.  I can now see a second generation design coming on with the calculations for the control algorithm, all based on rpm, as not just an improvement, but a better solution.

Hi Gary, so running the engine on the pressure cooker sprays oil all over the stove?  That sounds like the voice of experience.  Mum would be pleased.  Didn’t you get the message about having a separator on the engine exhaust?  But running the engine while cooking food would not be advised.  Boiling in that situation often foams and carries over due to compounds in the food, and those same compounds would really gunk up the engine.

Hi Zephyrin, thank you for those comments.  Now I am past the worst of the problems I am really  enjoying the project.  You are quite correct in that the flywheel and the moment of inertia of all the rotating parts all slow the engine response, so the system has to be slowed down to let the engine react to the governor valve movement.  In fact, I ended up doing this by limiting the maximum servo movement at each loop of the program, so several loops were required to reach the desired speed.  This very effectively damped the response which was initially a bit inclined to oscillation.

With a turbo machine, the speed is quite uniform, so measuring the speed several times each revolution can help, but with a reciprocating machine like the engine I am using, the rotational speed varies significantly within each revolution.  On a full size machine, limiting speed variation to 7% seems a common criteria for flywheel sizing, and it requires quite a large flywheel.   To get a useable speed measurement, you need several points in one revolution, and average them, or perhaps limit to one measurement of the whole revolution.  I have a wheel with dimensionally equal blades and gaps made on the rotary table, and take four measurements of time for the gap to pass, and average the times.  Each measurement is for 1/8 revolution.  I want eventually to try and explore whether I can prove that I am taking four consecutive measurements within one revolution, and also get an idea of how much variation I have.  (Need to be careful of that “can see a solution” syndrome.)

I must try and dig out our pressure cooker, as we make quite a bit of soup these days.  It makes it easy to keep up our recommended number of serves of vegetables despite some dietary issues.  There I go, off on another topic again!  By the way, roughly how long for pumpkin, and similar vegetables?

Thank you all for following along,

MJM460
The more I learn, the more I find that I still have to learn!

Offline jadge

  • Full Member
  • ****
  • Posts: 503
  • Cambridge, UK
Re: A digital governor for model engines
« Reply #114 on: May 21, 2020, 09:46:13 PM »
Hi Andrew. do they still make  OC71's. and OC72's   any more.  or is that really old school ??

The answer is no, and the original Mullard is long gone. I've still got some OC71s somewhere, albeit the later ones with an opaque filler. For the non electronics guys the OC71 was a germanium transistor sealed in a small glass envelope. The original sealant was transparent and some smart engineer found that you could scrape off the black paint on the outside and the transistor then acted as a photo-transistor. Once Mullard twigged this they changed the sealant to opaque. Of course they still sold the devices with transparent sealant, but called them photo-transistors and charged a lot more. It wasn't that long ago that germanium power transistors were still available, the lower forward voltage outweighing the disadvantages, primarily high reverse leakage currents. Although germanium transistors seem to be completely obsolete now some specialist manufacturers still make germanium diodes, mainly for signal detectors where the low forward voltage is a big advantage.

Two other semiconductors from my early days in electronics, the BC108 small signal transistor and 2N3055 power transistor are still available from professional suppliers. Amazing really, they've be going for more than 60 years.

I visited the Mullard semiconductor factory in Hazel Grove (SE of Manchester) back in the 1970s. The people I was with were assessing the company to see if they were fit to supply to the Ministry of Defence. So we got treated rather well! Including a rather nice lunch in the directors dining room complete with beer and waitress service.

Andrew

Online Kim

  • Global Moderator
  • Full Member
  • *****
  • Posts: 7922
  • Portland, Oregon, USA
Re: A digital governor for model engines
« Reply #115 on: May 21, 2020, 10:35:38 PM »
Two other semiconductors from my early days in electronics, the BC108 small signal transistor and 2N3055 power transistor are still available from professional suppliers. Amazing really, they've be going for more than 60 years.

I remember using the 2N2222 a lot in various projects I did in my younger days.  This was a little plastic package where as the 2N3055 was more of a power transistor in a TO-3 case if I remember right.  I used those too.  Those were the good 'ol days! :)

Kim
« Last Edit: May 22, 2020, 05:32:37 PM by Kim »

Offline jadge

  • Full Member
  • ****
  • Posts: 503
  • Cambridge, UK
Re: A digital governor for model engines
« Reply #116 on: May 21, 2020, 11:08:05 PM »
........where as the 2N3055 was more of a power transistor in a TO-3 case if I remember right.

Correct, along with the specially shaped mica insulation pads and little plastic top hats to insulate the fixing screws from the heatsink. It was a right faff to assemble and even worse if one had to use heatsink compound. The results could be spectacular if the insulation assembly was faulty.  :-[

Andrew

Offline gary.a.ayres

  • Full Member
  • ****
  • Posts: 1297
  • Isle of Skye & sometimes France
Re: A digital governor for model engines
« Reply #117 on: May 21, 2020, 11:40:46 PM »

Hi Gary, so running the engine on the pressure cooker sprays oil all over the stove?  That sounds like the voice of experience.  Mum would be pleased.  Didn’t you get the message about having a separator on the engine exhaust?  But running the engine while cooking food would not be advised.  Boiling in that situation often foams and carries over due to compounds in the food, and those same compounds would really gunk up the engine.

MJM460

MJM -

TBH I have never tried running an engine on a pressure cooker, though I wouldn't rule out trying it just for fun and curiosity.

When I was about 12, though - long, long ago - I went through an obsessive chemistry phase and I recall one Saturday setting up a Leibig condenser (rubber jointed - my pocket money wouldn't strecth to saving for an all-glass one) and distilling chloroform on one side of our small kitchen while my mother baked apple tarts at the other side. Strange but true.  :Mad:

Fast forwarding back to the present, however, I don't think my good woman - tolerant as she is - would be quite so indulgent were I to steam up in the kitchen using our pressure cooker, even if it was not being put to simultaneous culinary use. She does, however, tell me (in answer to your earlier question) that it very much depends what you are cooking, but I gather that it probably takes between 25% and 50% of the time it would take in an open pot. And often tastes better.

Funny, though. We started on about pressure cookers here in fun, but now I am seriously thinking that it would be quite pleasing to have one sitting on top of a charcoal BBQ in the back yard driving a small oscillator at 15 psi. Another crazy project, perhaps...

Apologies.  I digress...

 :)

Offline awake

  • Full Member
  • ****
  • Posts: 303
Re: A digital governor for model engines
« Reply #118 on: May 22, 2020, 01:23:09 AM »
This may already have been answered above, and I missed it - apologies if so.

Urgent questions: How long should one run the pressure cooker in order to ensure that the engine is done? With these "Insta-Pot" style that have all the buttons, can I just throw all the parts in, press the button, and it will come out finished automatically?
Andy

Offline Muzzer

  • Full Member
  • ****
  • Posts: 68
Re: A digital governor for model engines
« Reply #119 on: May 22, 2020, 11:15:16 AM »
Interesting historical stuff here! I have here the Mullard Reference Manual of Transistor Circuits (2nd edition 1961) that contains everything you could possibly want to know about germanium transistors - and much you probably wouldn't besides. There is even a chapter on the OCP71 phototransistor Andrew mentioned. I recall years ago scraping paint off an OC70 (or 71 or 72? they were selected on hfe) but they didn't work quite as well as the real thing. I'd post an extract here for interest but I expect it would only end up be removed ;-)

Later, germanium transistors were prefixed with an A (eg AC18) and silicon with a B (BC108 etc), with the second letter denoting the application (C = signal, F = RF etc) under the Pro-Electron naming convention. The 1N, 2N etc categorisation was a Mercan (Jedec) system that we had to learn and live with over here. https://www.electronics-notes.com/articles/electronic_components/transistor/transistor-codes-numbering.php

 

SimplePortal 2.3.5 © 2008-2012, SimplePortal