Process control - need very slow variable frequency
Erlend
Posts: 612
As part of one of my projects I need to control an impulse pump using a varable frequency signal of 5 - 60 HZ with ~10mS pulses - this drives the pump coil through a fat MOSFET. Easy to do from a Propeller pin. I also need to control a servo which operates the valve of a propane burner. The pump, burner, and a pipe coil act together to produce hot water at a controlled rate and temperature.
In the present solution the pump has to pause each time a new setting servo signal is needed for temperature control (it stays in position when there is no signal) - or otherwise I have to spend one more cog to allow the pump continue running in the other cog. I do not have spare cogs now.
So- my idea was to move these two tasks out and onto a chip - a cheap multichannel PWM controller I thought. Except, I cannot find one which can go that low in frequency (5Hz).
Do I have to use a small microcontroller connected by e.g. I2C which I can program to do both vF and servo control, or is there a suitable chip which is easily availble?
Erlend
snippet of code:
In the present solution the pump has to pause each time a new setting servo signal is needed for temperature control (it stays in position when there is no signal) - or otherwise I have to spend one more cog to allow the pump continue running in the other cog. I do not have spare cogs now.
So- my idea was to move these two tasks out and onto a chip - a cheap multichannel PWM controller I thought. Except, I cannot find one which can go that low in frequency (5Hz).
Do I have to use a small microcontroller connected by e.g. I2C which I can program to do both vF and servo control, or is there a suitable chip which is easily availble?
Erlend
snippet of code:
PRI Volume | freq, heat, strokes 'Ignite (if not burning) heat, and pump setpoint volume (= n 100strokes) at setpoint pressure, min and max setpoint temperature freq:= 30 heat:= 80 strokes:= 0 ReadGlobals IF flameRate < CintMinFlame Ignite(1) REPEAT UNTIL tempWater > intSPtemp 'Wait until water is hot enough for brewing 'flash 'Wait' indicator REPEAT UNTIL strokes > LintSPvol Pump1sec(freq) strokes:=+ freq 'Count how much / how many strokes have been pumped ReadGlobals IF opmode== 0 'Check for stop command from parent Stop IF pressWater > LintSPpress + 5 OR tempWater < LintSPtemp 'Speed control freq:= (freq - 5) #> 0 ' IF pressWater < LintSPpress AND tempWater > LintSPtemp + 1 freq:= (freq + 1) <# 20 IF tempWater < LintSPtemp 'Heat control heat:= (heat + 1) <# 100 ServoPos(heat) IF tempWater > LintSPtemp + 1 heat:= (heat - 5) #> 50 ServoPos(heat) IF tempWater > 100 'Overheat shutdown stop IF pressWater > 1600 'Overpressure shutdown stop IF flameRate < CintMinFlame 'Flameout shutdown stop Stop
Comments
You might consider a VCO chip, such as the DS1099. You may need to develop a resitance ladder to provide the appropriate voltages or a digitally controlled pot might work.
http://www.maximintegrated.com/en/products/digital/clock-generation-distribution/silicon-crystal-oscillators/DS1099.html
But there are other VCO chips that are adjustable, and one can always divide the frequency down.
Erlend
Isn't another Prop chip the logical solution as it is a very good "multi-channel PWM controller"? This is the "cheapest" solution as you have the parts and tools, software, and experience for this, unless of course you are building production quantities which leads on to the next question.
However, I also have to ask what is it that has used up all the cogs? I always like to stand back to look at the application objectively and weigh the requirements in such a way that one comes up with a simplistic but elegant solution (rather than just "Prop'ing" it up )
Brewed and drank first gas'presso coffee just now, but I am not yet happy with the hot water control. Anyway, with all that is going on in the background the cogs get eaten away quickly.
Here's an overview:
Erlend
Most small uC can cascade timers, to clock a PWM unit from a prescaler, or another timer.
Standard chips like LED drivers do often have PWM options, but I'm not sure they can scale to your numbers, as that is not so useful an area for LED dimming.
However, Peter has the best suggestion for development - just use another Prop - Cheaper than another Micro's eval kit, and you already have code proven.
but what I see is that you use COGs for ADC / I2C etc. drivers.
Maybe this is required in SPIN ??
In Tachyon I2C, SPI, SD, NMEA-Serial etc. can be handled without needing a separate COG.
As long as the frequency of the readings are low, many such sensors can be handled from the main program COG.
Maybe the timer COG can be utilized for cyclical polling of the sensors.
It does not sound like you have really hard microsecond timings for reading the sensors.
The timing within I2C and SPI protocols is handled by dedicated kernel routines.
Probably not an option to rewrite your existing program - just mentioning this different approach.
Er, you are some freak! Do you have some photos of your "Frankenstein"? I hope it makes really good coffee or do you have to wait for a lightning storm?
You can save at least 4 pins by combining those two external I2C buses with P28,P29 as there is no reason to have separate pins and "bus" infers that it can handle multiple chips. It also looks like you can combine a few functions into the one cog easily enough such as having the same cog read the I2C and SPI bus as none of these devices here require ultra-high update rates. That's just for starters.
Do you have the original of your diagram, it looks interesting.
EDIT: Just saw MJB's post. Yes, if you use Tachyon this would make the whole task easier and fit onto a single Prop chip. But I wonder, where is your networking connection? How otherwise are we to know when the coffee is ready?!
Anyway, I think you can do the pump pulses and the servo PWM in one cog without waits. Just make a fast repeat loop and check if it's time for a pulse or pulsend with the help of the systemcounter CNT. For such low frequencies this should work fine in Spin.
Here is the idea in code form, in addition you need to declare the variables, the pins and pindirections and maybe more. Is absolutetly untested:
Andy
The Franken'spresso is still a crow's nest, I have not moved out from the P Dev Board and onto a permanent pcb. It is powered off 12V solar energy and a bottle of Propane, but maybe I should look into lightneing...
The serious part of this project is to build a range of 'modules' = sets of know-how, code, electronic, electric, mechanical - for a range of sub-functions. This machine does a lot of things, and from that toolkit/set of modules I can build virtually anything. That means I try to avoid tailor making and combining - like putting I2C and SPI into one cog. I want the 'modules' to be generic, not spesific to Franken'spresso. Networking? I have been putting that off, because I fear it will be (yet another) steep learning curve, but definitly, the Forumers deserve to know when coffee is ready, and where in the world it is. (and start hacking into the machine...).
The diagram I posted is in png format and should be zoom'able, but some day soon I will update my web too.
I am in love with Spin, I would never cheat on her - even with sporty Tachyon.
Erlend
Excellent. I will do this. Guess I am hampered by human thinking patterns - the scheme you propose would be very exhausting if it were me who had to run around checking if the pulses have expired yet.
Erlend