Code Question


 
R

Rob Burk

New member
Short Background: Bought a Char-Griller Akorn ( Fauxmado ) a year ago. Ran across this project while looking for some ways to control the thing. Saw the 4.2.4 was out a couple of months ago. Built one and a servo/fan combo like this http://tvwbb.com/showthread.php?46004-INTRODUCING-the-quot-Roto-Damper-quot&p=552847&viewfull=1#post552847

I've read through the development thread and I'm not sure how much else. Started tinkering with the Arduino code. Did a fork off your repository and synced in your latest changes.

Things I've done or found so far:
Rewrote the Fan Voltage control - I'm using a Pentium 4 cpu fan. Discovered the stock code wouldn't go below 7Vdc. Basically 35% was the same at 1%. I can run it down to 1 Vdc now.
Reworked the PID - Derivative is more reliable now for me at least. Integration is more contained. Disabled resetting Integral accumulator when you change Integral value.
Tweak the decimation - helped with the Fan control which I least expected.
Added a new mode for fan ganging - Seems to work. Last weekend it was holding steady at 225F in crazy winds. Fan went from off to over 30% during time.
Discovered likely source of servo chatter - The servo isn't real picky about the refresh timing. The pulse width though is very touchy. I was able to make an ISR that could make servo growl. It was funny and then annoying after a few hours. Debating if 50 HZ refresh is even needed once it's on target.

Posted the code so you can pull what you want or tell me I need to work on it. Rob HM Fork

So my questions:
How in the world do you access the HMLG debug output? I've never been a fan of the Lua script file system that Openwrt uses. Feel like i'm in Dos playing with ini's truthfully. Keep getting lost trying to figure out where the output is being sent ( or is it pulled? )
Can I modify the linkmeter code and copy it straight to the Raspberry? I'd like to add the 5th bit flag to the PidOutputFlag ( Thank you for renaming those functions! ). I'm using the manual set field. Works but the web page is off

Enough for my first post I think
 
Wow, you're the first person to ever write code for HeaterMeter I think!

I can't take any of this code though, because you made two giant commits and made all the changes. I can't look at it and tell what can be affected by close to 500 changed lines. There's just waaaay to much to consider. Also your whitespace is tabs, and the code uses spaces.

What is fan ganging? What makes your PID calculation better? Why wouldn't it go below 7V? There are also other things to consider with the fan voltage, that it can be set low and read artificially high because the step down isn't putting out enough current for the blower to turn on. There's also the question of code space usage.

The HMLG goes through the streaming connection to the browser. Open the javascript console and the log messages are written out there. Don't write like 1000 things per second either because it can't keep up.

I edit all the linkmeter code directly on the Raspberry Pi then copy it off to commit it to git. Disable the cache in /etc/config/luci and clear /etc/luci-modulecache/* otherwise your changes won't take effect. (cache is precompiled lua)
 
No it doesn't. You can't implement 10 different features and dump them all into one commit. If any of this is going to make it back to mainline, then each feature should have it's own commit, and should be discussed separately.

EDIT: Sorry if it comes off sound like a dick, but this is a device where one bit missing in a register means something completely unrelated stops working. It's just good development to break things into small self-contained pieces where the merits and dangers can be discussed.
 
Last edited:
Bryan Mayland said:
Wow, you're the first person to ever write code for HeaterMeter I think!

I can't take any of this code though, because you made two giant commits and made all the changes. I can't look at it and tell what can be affected by close to 500 changed lines. There's just waaaay to much to consider. Also your whitespace is tabs, and the code uses spaces.
Click to expand...
I realized that later. I saved it at various points and I think I can break the first commit into smaller parts. The whitespace explains why copying your latest commits still didn't look the same. Compiled fine so I shrugged and went on.

Bryan Mayland said:
What is fan ganging?
Click to expand...
Fan speed is determined based on servo position. PID output is only on the servo. If servo is very high then it either starts the fan or "shifts" up a speed. The reverse if fan is low then the reverse. Each shift changes the fan by 10%. Can only do 1 shift every 30 seconds to give the PID a change to react
Bryan Mayland said:
What makes your PID calculation better?
Click to expand...
I'm not certain it is. Was trying to figure out how to control the overshoot and why you have to have wack the integrator accumulator at setpoint. Still believe derivative is the key to the overshoot on startup or else a setpoint ramp.
Bryan Mayland said:
Why wouldn't it go below 7V?
Click to expand...
Pretty certain it's because the default code the lowest the PWM puts out is 2/256 ( fast PWM combined with the Arduino analogWrite). I'm using an axial fan and the rotor is much lighter. It spins all the way down to 3.5 V and will start on 3.9V. So my fan simply doesn't put enough load to drag the regulator output down any lower. Probably happens to others I just happened to have a voltmeter on when I was trying to find the shutoff point.
Bryan Mayland said:
There are also other things to consider with the fan voltage, that it can be set low and read artificially high because the step down isn't putting out enough current for the blower to turn on. There's also the question of code space usage.
Click to expand...
The start up boost is pretty nice and I certainly didn't take it out. I know I'm using more code. My last compile was 24,700 I believe.

Bryan Mayland said:
The HMLG goes through the streaming connection to the browser. Open the javascript console and the log messages are written out there. Don't write like 1000 things per second either because it can't keep up.
Click to expand...
Oh that's great. Now I can quit hacking into the unused temperature probes!.

Bryan Mayland said:
I edit all the linkmeter code directly on the Raspberry Pi then copy it off to commit it to git. Disable the cache in /etc/config/luci and clear /etc/luci-modulecache/* otherwise your changes won't take effect. (cache is precompiled lua)
Click to expand...
Interesting. I'll admit that I'm terrible when it comes to html. I can read C code and follow the logic. Web code takes me forever.
 
Bryan Mayland said:
No it doesn't. You can't implement 10 different features and dump them all into one commit. If any of this is going to make it back to mainline, then each feature should have it's own commit, and should be discussed separately.

EDIT: Sorry if it comes off sound like a dick, but this is a device where one bit missing in a register means something completely unrelated stops working. It's just good development to break things into small self-contained pieces where the merits and dangers can be discussed.
Click to expand...
Your right. I have it broke into stages on my HDD as I was going along. Github was frustrating me at first. Didn't expect the first thing to happen was that mainline had just jumped forward. So the new commits didn't match at all.

Think I can start a new branch. Roll back to last week. Start adding smaller commits till it's to present. I'm going to be out of town the rest of this week but I'll work on it next week. Then you can tell me what needs fixed :)
 
Rob Burk said:
Fan speed is determined based on servo position. PID output is only on the servo. If servo is very high then it either starts the fan or "shifts" up a speed. The reverse if fan is low then the reverse. Each shift changes the fan by 10%. Can only do 1 shift every 30 seconds to give the PID a change to react
Click to expand...

Does this mean the servo goes from 0 to 100 controlled by the PID, and then when the servo is at 100, the fan then turns on low.. and then faster... and faster if the temperature hasn't recovered yet?

I've been meaning to see if that was suggested yet. Servo 0-100, and then fan 0-100.. and reverse when the temperature starts dropping.
 
Rob Burk said:
I realized that later. I saved it at various points and I think I can break the first commit into smaller parts. The whitespace explains why copying your latest commits still didn't look the same. Compiled fine so I shrugged and went on.
Click to expand...
Thanks for all the explanation and, again, sorry if I came off snippy initially. I've been working 60+ hours a week for the past month and a half so weekday evenings by the time I get home I am almost completely out of brain power.

Before you go too crazy breaking the code into a bunch of commits, let's take each feature one at a time and talk about it first. Once I'm convinced it is a good idea, then it can be made a commit. I'd hate for you to go through and do all the features serially then have one in the middle that I reject and it breaks all the subsequent patches!

If I am understanding the fan ganging feature correctly, I think I really like the concept. So the PID controls the servo position and if it is at, for example 90%, the blower goes up to 10%. 30 seconds later if the servo is still above 90% it bumps up to 20%, and so on? That's a cool concept although I think it could use a more straight-forward name. How does it interact with lid open mode, does it reset on lid? How many configuration items control it, or is it fixed for the high/low threshold, blower increment, and interval?

Wow your blower runs at 2/256 duty cycle? That's <1%! What is the current draw on that bad boy? This is one of those things I probably would not take. The actual FPM of a blower running at 62khz 1% duty cycle in a pressurized environment has got to be insanely low and not a typical use case. I'd suggest adding a small power resistor to increase the current draw over adding more code for it. It reduces the granularity for all blowers, and I see you go up to 13.3V which cuts off more than 10% of the usable range for everyone running 12V power supplies. I'm willing to debate this at a later date though so hold off on this one.

The integral cut is in there because there are really two different phases in BBQ control, startup and normal operation. If you tune all your PID parameters for startup, where you need a lot more "power" because things are heating up, you will be sub optimal for normal operation where things are relatively stable. HeaterMeter is really just seeking the proper PID I value to maintain temperature with 0 P and 0 D. During the startup you can get a pretty giant I value because when the D term cuts the fan to 99%, you're still a good 20+ degrees off target so you get 20xI, where in normal operation you get like ~1xI. I'll agree it's a bit of a hack but my I sum is like 70-80% the first time the temperature is reached which is clearly too high.

If you want to edit things on the RPi, I highly recommend using Notepad++ and WinSCP. WinSCP is awesome in that you can right-click edit a lua/html file on the Pi and launch Notepad++. Every time you save it automatically pushes the changes back (the first save is a little slow but the rest are <1s). It is super great, when I am done I open a second session in WinSCP and copy the file from the Pi to my git box for commit.

Wow this post is huge and unfocused!
 
I took the laptop with me over the weekend and did some cleanup. Redid the commits last night.

Wish I could up with a better name for the mode. Fan-by-Servo? I dunno. The controls are compiler defines. Wrote a Readme and put in one of the commits. I'm currently using 10 increments. So each shift is 10% of max ( steady or startup). As soon as it sees _pidOutput go to 0 it will jump to 0, worst case it might be 30 seconds slow.

Yeah I didn't expect the fan to work as good as it does. it was probably a $50 fan back when the Pentium 4's were out. Guessing it has roller or fluid bearings as it spins forever. Using the Javascript console did a quick check and it runs down to what is basically .8/256. Truthfully 1/256 is plenty to get down to 8%. Wish I had went with the resistor kind of just got caught up in seeing how far the SMPS could go. It doesn't need 13.3 V as I was curious and the heatup is too fast to control on a kamado style for low cooks. I can say on my last cook I wasn't paying that much attention ( which is the whole point right). Came back from doing yardwork to find the fan was running 10%. Top vent was too far closed apparently. Small tweak and a few mins later was back down to normal convection flow.

Random thought. Why not just measure the max voltage when starting the fan and use that instead of a fixed value? Probably not worth it as no one really is running full power except during warm up.

Yeah I get what the Integral is doing. Just never seen one jacketed against itself instead of the full output. I'll have to check where Integral is next time I fire up the grill. As it can't start moving till D pushes the controller off derivative it only has 20-30 degrees to build up.
 
I've submitted some stuff to your line. Although I just found out today how to pull a patch from Git. I have everything up on my main messy line Rob. I can cleanup stuff as you want/need for mainline.

You were right that the Fan SMPS I had went overboard. I was basically able to replace the analogWrite with something more specific and some tweaks to AdjustFeedBack to get it to work well.

Submitted the changes for Mode 5. Renamed it Fan-By-Servo, best I can think of to describe it. Put the updated Configuration page as well.

I've made some tweaks to the lucid daemon and index.htm in my line. Resized the fan bar in the legend. Made the graph resizeable but only tested on Android and Windows 7. Got the Fan speed as a separate line on the main graph. You were not kidding when you told someone else that was alot of work! I had to trace the whole path from Arduino, through Luci, RRD, JSON, and into Jscript/Jquery/Flot.

I'd considered at the start trying to graph the PID values. I'd still like to but syncing the pidstatus with the regular status. Might be awhile before I get that inspired..

Played with what is causing the servo jitter/chatter. Anyway to flip the Led1 and Servo pins in the next hardware rev? I reduced it some but had to get rid of the nice ramping you had for the servo to do it.
 
No chance of changing pins. Hardware should be as backward compatible so you don't end up with having to maintain a dozen different AVR firmwares. There is currently just one supported firmware that runs through all the way back to running in a Linksys router. Adding a new variation just to make a servo be a little more quiet occasionally doesn't seem like a good enough reason.
 
You must log in or register to reply here.

 

Back
Top