Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[flashtwo]

Hi Mike,

Marvellous!  Its great to know that you are making very good progress and also for using the I2C bus for the comms link , which is much more versatile than the serial comms that I use (although that was an improvement on the parallel comms that I had originally used!).

I would be interested in a block diagram showing the “architecture” of your control system. I placed all my master comms, control and servo drivers all in one 16F877 PIC, which put a bit of a strain on getting the software modules in the correct timing sequence, especially the comms code which had to be carried out without any interrupts enabled.

Have you had to put the interrupt handler at the very top of the code memory (005H?) so that interrupts can be handled from any memory page.

Its interesting the you experimented with the D part of the PID and came to the same conclusion. I never actually wrote any “D” code, since from experience in industry it was never very good – I found that feed forward control was very useful.

Have you seen my article in “Engineering in Miniature” magazine (Feb/ March 2012), which gives an overview of the monotube boiler control system?

Sorry I’ve not responded earlier, but, as you may see on the “Edwardian Steam Launch build” thread, that I’ve been a bit busy.

Photo shows VB at Herne Bay in August, chugging along with 10psi on the clock.

Ian.

[TurboTyne]

Hi Ian

" the I2C bus for the comms link , which is much more versatile than the serial comms that I use"
What serial bus do you use then? It took me ages to get the I2C to work. There was always the uncertainty of knowing whether the problems were in the master or slave PIC etc. Oh what joy when one PIC at last spoke to the other.

"I would be interested in a block diagram showing the “architecture” of your control system".

O/K., as it happens I was just preparing such a summary because I need to refresh my memory on this side of things, having just spent a couple of PIC-free months designing and building the pump.  Here it is. Each of the boards shown here has been built (3 are on veroboard but 2 are still on the breadboard) and all have communicated with 1 or more other boards, but as yet I have not interconnected them all in pattern shown in this diagram. This should be relatively straightforward (famous last words)  simply by changing the I2C addresses and ensuring the data sequences for TX and RX are correct.

"Have you had to put the interrupt handler at the very top of the code memory (005H?) so that interrupts can be handled from any memory page."

Actually I have not used interrupts at all. I have managed to steer clear of this complexity - it's been enough of a battle for me to cope with all the many other aspects of these devices  - I'm still amazed at what gets packed into a cheap device and at the number of pages in their data sheets.

" I found that feed forward control was very useful".

By this, are you referring to when you adjust the gas burner for an impending change in pump speed? I have not incorporated this sort of thing at present - something for the future if I ever get my system to function well enough in the first place.

"Have you seen my article in “Engineering in Miniature” magazine (Feb/ March 2012), which gives an overview of the monotube boiler control system?"

Yes I bought these issues as soon as they appeared - very interesting indeed.

"Sorry I’ve not responded earlier, but, as you may see on the “Edwardian Steam Launch build” thread, that I’ve been a bit busy."

Yes, I've seen that - and I'm very impressed with that hull. My gas valve and feed pump are rather bulky and may need redesign before putting into a boat. My main concern at present is to get the boiler control working. I was not sure what pump cylinder diameter to use and was afraid that too large a diameter would overload the motor. So I've made it with 1/4" diam. rams but the pump is designed so it should be relatively simple to replace the cylinders and rams for a different diameter if needed whilst retaining all the valve blocks, cylinder supports, crank etc.

Regards,  Mike

[TurboTyne]

Hi Ian

Can I please ask your advice on an aspect of wiring my control system?
I am about to make up some cable bundles with 9-way D-type connectors and also box up the boards. However, I'm worried I may run into problems with interference on the I2C bus from the high frequency switching of a couple of amps in the pump motor supply.
Power is supplied by two 6V rechargeable batteries which are connected as follows:.
The 12V from both batteries in series is sent to the feed-pump via a MOSFET that chops the signal to give the PWM control.
The same 12V also goes to a voltage regulator to supply 5V to just the electronic circuits.
(Also, 6V from one of the batteries goes to the 4 transistors which power the gas valve stepper motor). 

It would be convenient to run the power wires and the I2C bus wires in the same bundle. Do you think it likely that the serial bus would pick up electromagnetic interference from the 12V power wires over the lengths of wires typical in a model (i.e. up to a couple of feet).
Also, however,  the 5V regulated and the 12 V unregulated circuits share a common negative and I am wondering if there would be no sense in bundling the 5V and 12V wires separately anyway since the pulsed high current will still flow through the common negative and maybe could influence the 5V supply in some other way. So far things seem to be OK but ????
Do you have any experience of interference and do you think it is something I should be worrying about? Should I use a separate battery for the 5v regulated supply or am I worrying over nothing?
Thanks for any advice. 
Regards  Mike

[flashtwo]

Hi Mike,

The SPI is the “Serial Peripheral Interface” which doesn’t use a data / address bus like the I2C. It has separate data in and out pins and four slave address pins. I found SPI easier to understand and implement from scratch than I2C.

I did build a specific experimental board populated with  several PICs and LED bar indicators just to test the code – I also employed a PICO PC ‘scope in order to examine the actual waveforms being generated on the various pins, which helped enormously in detecting whether it was the Slave or Master controller that was not performing to spec. I know what you mean when the PICs start talking to each other.

I think with the SPI, you have much better control of the timing of events especially in the “real time” environment of control, i.e. you don’t have to wait for the bus to be free and you are not mixing data and addresses. Saying that, I2C can address many more PICs than SPI. You can search on Google for all the different pros and cons regarding SPI v. I2C.

Regarding Interrupts – my Master Control PIC has lots of conflicting jobs to do – it receives the feed demand PWM input pulse from the radio receiver (an interrupt), the internal Timer roll-over for servo and ESC PWM outputs (an interrupt) and  Serial Data buffer full (an interrupt).

Feed forward – yes, as you say its for adjusting the gas valve in anticipation of a steam temperature change due to a change in feed water flow.

Thanks for your “feedback” on the magazine article – I’m glad that it is of some use and will hopefully save you and other experimentalists some time.

Regarding the pump sizing – I’ve basically stayed with the ¼ inch by 1 inch stroke and just tried different sized motors and gear boxes. On my experimental steam jet boat I had a 915 (?) motor with a 29:1 gearbox. On “Vital Byte” I now run both pumps at once for high speed.

I shall have to take a break for now, but I shall read with relish the rest of your post later.

All the best

Ian.

[flashtwo]

Hi Mike,

The block diagram is a very good overview of your system – I must do one for mine someday.

I see that you have gone down the “distributed control” route with individual PICs, whereas with mine the slave PICs just supply the data and the main controller does all the work. The problem with my setup was that I was pushing the Master PIC to its limit regarding available registers, time and page space. This is the good thing about people like yourself, by not slavishly following my solution better ideas are produced – still, I have the option of changing the code and using (stealing?) your idea.

I did produce a dedicated pump controller for Steamboat Phil (see 17/2/2011 on this thread), since he just wanted to set a certain feed flow for his flash steam straight runners.

The second thermocouple is very useful for measuring other temperatures, e.g. boiler exhaust, ambient, feed inlet and so on.

I see that you are measuring the ambient and then doing the cold junction compensation in software – you might find the thermocouple amp AD595 of  interest, since it does the linearisation and compensation all in one package.

I remember that your gas valve servo has limit switches to prevent “integral wind-up”, but how do you handle it with the feed pump speed PID. 

Which LCD display are you using (the bigger the better for my eyes!)

Regarding interference –

I would keep any components that take a high current on a separate “power bus” fed from the battery directly (via a fuse!) and ensure that no high currents are taken from the supply at the PIC board. I had a problem high torque servos (even those controlling the rudder and engine reversing linkage) dragging the volts down momentarily. I ensured all servos (though not the ESCs) were powered from their own bus with only the white signal wire coming from the PICs.

Ensure that electric motors have their own earth (-ve) connection back to the battery and that all other negatives go back to a common terminal and then to the battery using thick wire in both cases. This is to eliminate high return currents lifting the volts above zero.

For those interference spikes that don’t even show up on the ‘scope, put 1500pF capacitors  between the +5v and 0v at a couple of locations on the board.

Once I had a motor whose insulation was a bit suspect and this caused spikes on the earthing system  - I changed the motor.

I do use screened signal wire on the long runs to the servos and pressure sensors – which reminds me, are you using the type K (green/white) cable for you thermocouple connections.

And, finally ensure that unused pins on the PICs are set as outputs and/or tied to 0volts, otherwise some of them have a nasty habit of causing rests or interrupts.

I have had a board failure caused by the Sun’s heat shining through the clear cover of the controller box – I had been chatting for an hour at the lakeside, but it is a reminder to ensure to keep things cool.

I have the same battery and regulator setup as you – make sure the regulator stays cool once it is mounted inside the boat though.

I hope this is helpful – I’m sure I will think of some thing else to add.

Good “bug” hunting as they say.

Ian.

[TurboTyne]

Hi Ian

Thanks very much for your replies and especially for the advice about avoiding interference. I shall incorporate all those points in my design.


"I see that you have gone down the “distributed control” route with individual PICs, ...."

I like the sound of calling my set up a “distributed control” system. I had not fully realised it was so different to Vital Byte. Your blog describing the use of a serial bus led me to read up about this concept and that led to I2C. In reality, I did not set out by designing the whole system – it just seemed to evolve in that direction after I had initially constructed the PIC board for controlling the gas valve. Also, I think the way I ended up controlling the gas valve may be placing more demands upon the PIC, so cramming all into one device would have been particularly difficult.

"I see that you are measuring the ambient and then doing the cold junction compensation in software – you might find the thermocouple amp AD595 of  interest, since it does the linearisation and compensation all in one package."

Following your earlier posts, I was going to use this device and it would probably have saved me a lot of time. As with all aspects of this project, after reading your notes on Vital Byte, I downloaded relevant Microchip application notes and went from there. Doing things my long-winded way did mean I learn more about what is going on.


"I remember that your gas valve servo has limit switches to prevent “integral wind-up”, but how do you handle it with the feed pump speed PID."

I am probably misunderstanding your question here, so I apologise that the following “essay” is so long.
If the term “servo” always means  a specific type of device that converts a PWM input to a motor-driven positional output, then I am not using servos. (I’m not being deliberately pedantic here, it’s just that I am ignorant of how these terms are commonly used).
 
In my gas valve mechanism a stepper motor turns a threaded rod and this moves a sliding block along its guides. The sliding block is connected by a lever to the end of a rod which is thus moved in the same direction as the threaded block but to a smaller extent. The end of this rod enters the body of the gas valve through an O-ring seal. The very end of the rod is tapered and forms the needle of the needle valve. It enters a hole inside the valve body through which the gas has to pass. Thus the needle is pushed or pulled in/out of the hole unlike a normal valve where the shaft of the needle is threaded and is moved by rotating it.  Unlike a servo-controlled valve, the system has no way of knowing the position of the mechanism so the sensors at each end of travel of the screwed block are essential to stop the motor turning too far so the block jams up on the end of the threaded rod.  The valve can be fully closed or opened by sending a coded message to the PIC which then turns the stepper motor until the end of travel is reached. The result of PID analysis is sent as the number of steps to open / close the valve. Because of the fine thread and the effect of the lever, it takes several hundred steps to fully open the valve.

With the pump motor, there is no separate ESC unit. The pulse width modulated power output is generated by the PIC device itself using one of its CCP modules which is based on the system clock (4 MHz). The CCP PWM output is set to a frequency of 10 KHz. (i.e. each cycle lasts 100 usecs). This means that the ON time of a single PWM cycle can vary from 0 up to 100 usecs in 400 steps of 0.25 usecs. This seemed to me to be a good enough resolution. I would be interested to know if this is how other people and Vital Byte controls electric motors.
I think I read that for the VitalByte feed-pumps, you send a PWM output to an ESC (??).  If so, do you use a commercial ESC?

The result of the PID analysis of motor speed increases or decreases the ON time of the PWM output  but the software limits this to values between zero (stop) and 400 (max speed).

One complicating factor was that,  with the PIC running at 4 MHz, I found that the timers run too fast to allow measurement of the time of rotation of the pump. So the time between successive pulses from the Hall effect sensor are measured using TMR2 running under an external 32.768 KHz crystal.   Did you find the same thing or do you accomplish the pump speed measurement in a different way?


"Which LCD display are you using (the bigger the better for my eyes!)"

My eyes seem to demand the use of "reading" glasses for more and more tasks these days. My LCD display has characters 5 mm high and has 4 rows x 16 characters. This was one of the cheaper models at Farnell (£9.34 each) and works fine, except I wish I had gone for a display with more characters per line. I may add another PIC (with a different I2C address) connected to a second display so I can send different data to each display. I think this may prove more versatile (and cheaper) than buying one big new LCD.

This is the device I use:        http://uk.farnell.com/jsp/search/productdetail.jsp?sku=2063248&CMP=i-bf9f-00001000

But I'll not be adding another LCD until I've made more progress as there is a VERY long way for me to go before I have anything near a functioning system.

Regards  Mike

[Panoramix]

Thanks Panoramix for the diagram - "Vital Byte" still appears to be somewhat short of achieving "hull speed", although its square hull section may be offering a lot of resistance.

I am just reading your answer now and I am glad that the info was useful to you. And yes a square hull is not ideal to reach hull speed.

[flashtwo]

Hi Mike,

The “integral wind-up” that I describe, is the situation when the controlling device (i.e. a valve) can’t eliminate the error and the Integral Action output of the controller keeps ramping , since its rate is governed by the error.

The controller may have some internal limit like the supply rail voltage for an analogue controller (+/- 15volts) or a numerical limit in a digital controller, say the two-byte limits of zero and 65535 (which may roll-over to zero!). When the error changes polarity, the integral output will start ramping in the opposite direction, but, if it has previously reached an out of range value, it may take a long time to return to the actuator control range. This integral wind-up lag will make control impossible.

In my case, the PWM servo and ESC operate over the range 1000 to 2000us (1 to 2ms), therefore the controller output is limited zero to 1000 (the 1000 PWM offset is added on ). When the controller output reaches the zero or 1000 limit, the Integral Action  calculation is by-passed and the integrated error value is “frozen” at the limit so that, when the error changes polarity, the integrated value comes immediately back into the control range. This is all done internally without resorting to external limits. For the gas valve I can dynamically adjust, at the Display Unit,  the 2000us (nominal closed) limit anywhere between 1500 and 2300us and observe that the gas valve physically shuts the flame off.

For the pumps I am using a commercial ESC (Robbe) which can handle the standard PWM signal of 1 to 2ms. What will you do in your system, when for example the battery volts start to decline and the motor can’t maintain the desired pumping rate and the error is not eliminated? Will the PID still keep integrating the error, although there is no hope that the feed will get to the desired flow?

That’s funny, I had exactly the same problem as you in measuring the RPMs. From the control board’s common 4MHz clock pulse, one small PIC derives two separate timing pulses (2000us & 200us) for the PICs measuring the RPMs of the pump (0-200RPM)  and engine (0-800RPM) respectively.

I divide my display data into a number of chapters and pages. The chapters represent a particular control function i.e. temperature, feed etc. and the pages represent measured and desired values, PI settings etc appropriate to that chapter. On my display console, each chapter has its own push button and then I can scroll down the pages in the chapter using the up/down buttons. You can therefore navigate around a lot of data using only one LCD.

I hope my explanations are understandable. I think if you refer to the magazine article you may get a better idea with my analogy of controlling the water level in a pond.

All the best

Ian.

[flashtwo]

Good job I kept a copy of the above long reply, seeing as it went missing off of Mayhem when I posted it last week!

Ian.

[TurboTyne]

Hi Ian

Thanks for the explanations. This reply is delayed because I first wanted to re-read your article. It is a long time since I initially read it and I clearly forgot a few things. It is interesting that now I have made more progress on my own system, I am better grasping the significance of more details mentioned in the article.  Also, I’ve had a bad week in regard to problems encountered upon returning to the electronic controls for my pump after a few months spent designing and building the mechanics.

Regarding the topic of integral wind-up, this is dealt with in different ways in my valve and pump control situations. The pump control is PWM and, as in your system, I limit the range of values permitted for the relevant control variable. (Presently 0 to 400). For the gas valve, the integral wind-up effect is mechanical rather than electronic since continued creeping of the stepper motor moves the valve. In this case movement is limited by the optical positional sensors. These are very accurate and their position can be easily adjusted. So I hope that adjusting their positions will enable the needle in the valve to be stopped from moving beyond its useful range. My PID sub-routine is based on a Microchip application note (AN964 Software PID Control of an Inverted Pendulum Using the PIC16F684). 

With regard to your point about how to cope with a failing battery, I must confess that I had not thought that far ahead. As just mentioned, the present software/hardware arrangements will hopefully stop integral wind-up but I guess it would be useful for a boat to signal to the operator that the battery is getting low so it can be brought to the bank asap. Might it be useful to use a spare A to D channel on a PIC to monitor battery voltage? If V drops below a certain level then the pump rate could be reduced to a modest speed. I can't remember if you have already discussed this in this extensive blog.

I like your semaphore system to communicate from boat to operator. Did you ever consider using 2-way radio? I have never dabbled with radio control so I have no idea if this is even feasible.

Some of the problems I have just been battling with were caused by errors or omissions in my notes. But one significant issue has cropped up.  I am now concerned that the PIC-generated 10 KHz PWM output will not have adequate resolution. It has a pulse width varying over a range of 0 to 400 and I had assumed that I would be able to control the motor speed over at least the range 150 to 400 since the motor runs fine down to below 3.3 V when using a standard DC power supply. I had assumed that a PW of 200/400 (i.e. 50% PW) would be equivalent to running the 12V motor at 6V  (i.e. 50% voltage). However,  it seems that 50% PW is much less powerful than 50% voltage.  I hope this is a recognised phenomenon and not something I’m doing wrongly. I wonder if it might be linked to induction effects in the motor windings. Whatever the explanation, it seems I shall only have effective control over a smaller range of  values. Before abandoning my present  approach and buying a commercial ESC I am going to try increasing the number of PW steps from 400 to 1600 by increasing the PIC Fosc frequency from 4MHz to 16 MHz.

One further question, if I may. Do you get a lot of noise from the motor-gearboxes on the pumps? I would guess that a boat containing my pump motor would be much noisier than expected for a steam boat.

Regards

Mike

[flashtwo]

Hi Mike,

Sorry again for the delay – I’ve been making lots of dust on the launch build!

Right –

I’m using the motors with epicyclic 100:1 gear boxes from MFA/COMO and I don’t find them unusually noisy and besides, as the boat pulls away from the shore, the engine and motor noises die away quite quickly.

Regarding the semaphore – several people have suggested that I should transmit the boiler pressure, temperature etc. back to the shore, but my intention was to make the boat’s plant control fairly autonomous with me outside the loop apart from boat speed and direction. I see that these data links are discussed on one of the other threads and that the model aircraft guys use them a lot.

Once the boat is off, I use the semaphore just as a fuel gauge (gas cylinder pressure) to know if  I need to return to shore. Sometimes it is set to indicate steam pressure, as when I set the reversing linkage to neutral, build up some pressure, then set to ahead and accelerate the boat just to show off!

I also considered making my own ESC, but found difficulty in sourcing the “H”-bridge chips at a reasonable price and besides it needed the additional voltage rails to effectively switch off the MOSFETs completely – if my memory serves me correctly. I thought that I couldn’t better the commercially available ESCs and that my time would better be spent developing the boiler controls that aren’t available commercially. By all means carry on with the ESC design – it will be an interesting part of the project and satisfying when you get it working and you will become the expert and advise other people.

I’m intrigued with your stepper motor control PID analysis – do you track the gas valve position by keeping a tally of the number of +/- pulses sent, e.g. say it takes 2000 pulses for 100% travel, do your limit switches reset the pulse count to zero when the valve is closed and to 2000, say, for when the valve is fully open?

In the distant past, I had problems with an industrial steam temperature control system that used stepper motor controlled valves. The valves had positional feedback potentiometers to the control system, but separate limit switches for the anti-windup. It was that long ago that I built a simulator on the old BBC Micro computer and even plotted the valve position on the screen. I emulated all the analogue control modules in the real system, but the simulator kept showing the control valves would bounce off their limits in ever reducing amounts. In frustration I went to the plant control desk and had a chat with the operator who clearly demonstrated the same problem had existed in real life for years, but had never reported it. The original control system design was wrong in that the limit switches were “shorting out” the error, which the control system interpreted as a change in direction and therefore opened the control valve instead of closing it, thus causing the on-going bad steam temperature control.



It was that experience (plus a instrument mechanic who had got suicidal rewiring the control loops to my latest “solution”) that encouraged me to start using PLCs for control.

All the best

Ian

[SteamboatPhil]

I would just like to add my little bit, that thanks to Ian (who's data I have benn stealing.....well actullay he gave me a few bits electronic wise that is) my radio controlled flash steam boat has moved ahead in leaps and bounds (remember I am a straight running steam type person) with luck my demo plant will be at Ally Pally in the new year..

[TurboTyne]

Hi Ian

Thanks for the replies. My motor has the cheaper spur-gears – rather than epicyclic. So now I’m wondering if the spurs are noisier. If I get a system working then I can think about upgrading.

Hearing your reasoning behind your decision to buy the ESCs makes me think I am the “fool rushing in where wise men fear to tread”. No doubt a commercial ESC will contain sophistications of which I am not even aware but I thought that if I could get the PIC to work as the heart of an ESC then it would comprise an intelligent unit directly controlled via I2C. I have not needed anything complicated like an H-bridge because it is a DC motor with no reverse - so a simple MOSFET transistor does the trick.  I have just increased the clock speed on this PIC to 16 MHz so the pulse width over which power is sent to the motor (via MOSFET driver/MOSFET) can be varied from 0 to 1023 x 0.06 usec steps, with a pulse repetition frequency of ca 16 KHz. So that seems to match the dynamic range of 1,000 x 1 usec steps you send to your ESC.

This PIC ESC seems to work fine  BUT  I find that when the speed of the 100 rpm motor drops much below  22 rpm (pulse width = 750/1023) it stalls. I don’t know if this is as to be expected for this type of motor and I would be very interested to hear if your pump can operate at speeds much less than 22 rpm using the Robbe ESC. If so, then I guess the Robbe unit is doing something special that my method is lacking.

Regarding control of the gas valve stepper motor, my approach is nowhere near as sophisticated as you seem to be thinking. Your tale about experience with the steam temperature control valves makes me wonder if I am over-looking something crucial in my system. If you spot any problems with the following plan, I’d greatly appreciate it if you would let me know.   As I understand it, the problem with tracking the position purely by counting pulses (i.e. no position sensor) is that it requires the system to calibrate itself on power up by moving to a known start position. Also, I think that any error or missed steps would accumulate over time so a periodic recalibration would be advisable. My current (but as yet untested) plan for the gas valve control is as follows.   The PID analysis generates a number (+ve or -ve) that indicates the number of steps the valve motor should move. The system does not need to know where the valve is but just if it should open or close the valve at all and, if so, by how much. If the set temperature cannot be achieved then the worst case is that the valve opens fully. It would then activate the full-open sensor. This tells the PIC not to turn the motor any further in that direction and it could also be used to trigger other responses to the situation - but I’ve not planned that far ahead.  If it is required to fully close or fully open the valve, then a suitable command tells the PIC to turn the motor in the appropriate direction until the appropriate sensor is activated to stop further movement.

I don’t understand why the steam valve you mentioned needed potentiometer position sensors?  It sounds as if the system needed to set the valves to specific positions rather than just open or close the valve a bit more. The bit more / bit less approach is also the way my pump speed control works – but in that case it is the pulse width value that is adjusted up or down according to the PID analysis result. This is basically as described for the PID-based control system in Microchip AN964.

So were you able to correct the valve control system that you so carefully analysed on the BBC?  I too have fond memories of programming a BBC computer at work.  Back then the BBC was one of the best small computers available for laboratories to use. Now, of course, a PIC costing just a few pence is equally powerful as a BBC.

I’d never heard of a “PLC” until you mentioned it in your last message. So I looked it up and discovered yet another whole new field of technology that I’d been unaware of. (It was through your blog that I first learnt of microcontrollers!!).

Best regards
Mike
 

[flashtwo]

Hi Mike,
 
You’re quite right about not using an H-bridge – I was making it too complicated for the application of a single direction motor.
 
I can measure down to 0.5RPM, although for an immediate response to a control change, the pump’s minimum strokes per minute (SPM) is set at 14, which through the 100:1 gearbox gives a motor minimum of 1400RPM. I can run at a slower SPM, but with a greater chance of stalling then overspeeding as the error suddenly builds up and results in instability. Unlike a conventional boiler, where the pump is operating against the established boiler pressure, the monotube boiler that is at minimum feed flow is also at minimum pressure and so the pump is less likely to stall.
 
Does your Proportional part of the PID analysis generate a fixed number of pulses such that, for example,  a 10% error will cause a total 100 pulses to be sent and a 20% error will send 200 pulses such that the actuator will only move a fixed (though proportional) amount and then stop? And does the Integral analysis result in a continuous run of pulses the frequency (or rate) of which  depending on the size of the error? If so, the integrating “memory” of the system is within the actuator and so stopping the pulses will stop any integrating wind-up (you’ll have to excuse me here – I’m dragging the depths of MY memory). With my system the integrating memory is within the software and so required to be “informed” when the actuator reaches it limits otherwise the integrating “memory” increases in value.
 
I think I myself could do with some integrating memory!
 
The steam valve (actually desuperheater spray water valves) used the potentiometer to feedback the valve position to the central control room for manual control. Originally, the auto control system didn’t use the positional feedback, since it relied on the limit switches. Since there were 16 valves and 64 limit switches to be accurately maintained, the system was unreliable and so I redesigned the system to just use the potentiometers as feedback and even then didn’t have to rely on 100% accuracy. Yes, the system did work and was still working 10 years (running 15 years non-stop) after I took early retirement. It has only recently been replaced after the installation of a completely “soft” control room, but even then it has been emulated in the replacement system.
 
I have one complaint – I’m having to think back a long way and its making my brain hurt!
Ian

[TurboTyne]

Hi Ian

Thanks very much for the info on the performance of your speed controller / motor. From this it seems clear that the Robbe unit is definitely doing something better than my homemade effort – which, of course,  is not surprising. Actually, I have recently made a modification to the circuit and my unit now does better than before. I can now run the pump, pumping water into a boiler at 50psi, down to 15 rpm. When pumping against no pressure it will go down to about 13 rpm before it stalls. (Before the modification the motor stalled below 22 rpm, even with no pump connected).   The control between 15 and 100 rpm is excellent so I am happy with this outcome for the time being and I'm hopeful that it will enable me to proceed with getting a working system. However, I've become a little hooked on this ESC topic now and I am curious to see if I can improve it further. I had read that a moderately high pulse repetition frequency (around 20 KHz) generally gives the best control so I have been using 15 KHz. However, I have just seen that one type of commercial model boat speed control controller  (Electronize Type FR30 HX) uses a variable pulse rate (from 2000 down to 10 Hz !!) and the description says that low pulse rate gives better results at low speeds. With a PIC-based ESC it will be very easy to investigate this directly by changing the pulse rate with all other things kept the same. Also I'm looking forward to investigating the waveforms in the circuit using a cheap oscilloscope that I've just obtained. I am wondering about writing a summary of all this and posting it in a new thread -  although I doubt it will be of interest to many others (if any at all).

Out of curiosity, do you have any idea if there are many people who are into using PIC devices in model boats etc or are microcontroller hobbyists mainly robot builders ?

Yes, your summary of how my system works (or is hoped to work) is correct. The PID software calculates a proportional term, an integral term and a differential term (currently set to zero). These are added together. Then, depending on whether the resulting number is  positive or negative, the valve motor is told to open or close the valve. If the number is negative, it is converted to a positive number. Then the original or the converted positive number is sent to the valve control PIC which moves the motor by that number of steps – or until the limit of movement is reached. When the proportional part is zero, the integral will continue causing a movement. Providing the movement limit is set so as not to be beyond the point where further valve movement makes no difference to the gas flow rate, then there should be no wind-up.

Sorry the question about past activities made your brain hurt. Yes, I too would appreciate having an upgrade to my memory chips. 

Regards,  Mike

[steamboatmodel]

My Brain is hurting too, but it is a good hurt as it is causing me to think and remember things I once partially understood. Please continue there may not be many others posting on it but I think that others may be like me and letting it mull around in our heads trying to figure it out.
Regards,
Gerald.

[TurboTyne]

Thanks for the encouragement Gerald.

So as not to encroach further about this diversion on Ian's thread I've just started a new topic called "ESCs and pulse rates" in the section "DC motors (Brushed) and speed controllers".

Regards,  Mike

[flashtwo]

Hi,
 
I was doing some research for my Edwardian Steam Launch build, when I came upon this webpage http://www.machine-history.com/Herreshoff%20Manufacturing%20Company%201800s about an 1880s American company that was manufacturing full size launches with monotube or "safety coil" boilers. It is interesting that the feed water entered at the boiler top and steam exited at the bottom, just like "Vital Byte"; nothing is new!
 
It has a separator to allow superheated steam production, which is what Gondolier88 (Greg) and I have been discussing in his recent "Gas burner jet" thread.
 
I wonder what happened to the Herreshoff design.
 
More experimentation coming up!
 
Ian.
 
 

[flashtwo]

Further research regarding the Herreshoff "safety coil" design.
 
1) It was expensive to manufacture due to the tapered boiler tube employed in its design.
2) Water treatment was primitive, such that all boilers of that era scaled up. Conventional straight tube boilers could be cleaned, but the coil boiler had to be expensively replaced; the early ones used sea water as bolier feed.
3) Ironically, Mr Herreshoff himself lost his steam engineers licence having screwed down a safety valve on a conventional boiler and causing the death of the operator (Mr H was attempting to increase the speed of a steam yacht).
 
Food for thought though.
 
Ian.
 
 

[silverbrewer]

This is a test to see if this post is going to be credited to me (silverbrewer) or to Xtian29.
The previous posts of mine on this subject have had the headings changed to Xtain 29 since page 9.


I am looking at all of this, but it is getting a bit beyond my comprehension limits!!!

[Tug-Kenny RIP]

Not to worry.  A lot of folks posts were credited to different people as the system crashed.

We'll see what we can do.

Ken

[Martin (Admin)]

Just had a look, can't really retrospectively change the post without screwing up all of Xtian29 posts, it's an 'all or nothing thing'...

[silverbrewer]

Thanks for checking it out, but it is no biggie! As long as xtan is not confused. I only had about 20 posts on here, so going back to newbie status is of no concern.

[silverbrewer]

How are things progressing? There seems to be a lull in posts. Let's hope no news is good news.
Are you thinking of selling these systems in any sort of format?
Could you come up with some sort of thrust figure for your boat next time you have it at full tilt?

[flashtwo]

Hi Silverbrewer,

No things didn't stop. The monotube boiler system was developed to a point where it could be transferred from the experimental boat into a "proper" model launch. The actual software until recently (see the XBee thread below) hasn't been changed for a couple of years.

Look at the Edwardian Steam Launch build thread http://www.modelboatmayhem.co.uk/forum/index.php/topic,37563.25.html
and videos
https://www.youtube.com/watch?v=2HV4s9MjfaQ
and
https://www.youtube.com/watch?v=Az_U-Qeb3fY

I will be doing some superheater experiments when the weather warms up, but in the meantime (during the cold weather),  I've been developing the electronics for the launch, see XBee thread

http://www.modelboatmayhem.co.uk/forum/index.php/topic,48575.25.html

and I've also started on a voice command system for the launch, see

http://www.modelboatmayhem.co.uk/forum/index.php/topic,50087.0.html

I'm afraid that, apart from Mayhem member Turbo-Tyne and a couple of others, the field of interest in steam AND computer control is quite narrow. For most steam buffs the traditional boiler satisfies their interest and the learning curve of computer control is too steep. The completed control system could certainly be used by others without too much training - it just requires an overall understanding of what its trying to achieve without delving into how the software works. I could produce another system since it is all documented.

Weren't you building a steam powered kayak using a Stuart D10 engine - how have you progressed?

Thanks for your continued interest.

Ian