Arduino Development Thread

[Zizzle]

Cool, some others are interested in these so I'm putting together a Ubuntu VirtualBox image with the toolchain installed and setup, a simple FreeRTOS example project with touch and LCD drivers working and an easy to use menu framework.

Done. With videos.

http://zizzle-brewbot.blogspot.com/2012/10...creen-demo.html

If anyone tries it out, let me know how you get on.

 

[Edak]

Done. With videos.

http://zizzle-brewbot.blogspot.com/2012/10...creen-demo.html

If anyone tries it out, let me know how you get on.

Great guide Zizzle, I am sure that it will be enough to get others interested.

 

[vortex]

Done. With videos.

http://zizzle-brewbot.blogspot.com/2012/10...creen-demo.html

If anyone tries it out, let me know how you get on.

Nice work

 

[randyrob]

Anyone using Nixies to display time/temperature?

I just got some soldered up into some PCB's that I designed, Just gotto knock up an enclosure.



Cheers Rob.

 

[bonj]

Anyone using Nixies to display time/temperature?

I just got some soldered up into some PCB's that I designed, Just gotto knock up an enclosure.

View attachment 58088

Cheers Rob.

That's so 1337

 

[vortex]

Can any of you guys give me a hand with I2C on Raspberry Pi at all? Having a hell of a time getting the hardware side to play ball...

 

[vortex]

Can any of you guys give me a hand with I2C on Raspberry Pi at all? Having a hell of a time getting the hardware side to play ball...

Actually, it looks like the 7 segment display board and LCD I have has a dodgy I2C implementation.

 

[Edak]

Actually, it looks like the 7 segment display board and LCD I have has a dodgy I2C implementation.

Does that mean you have figured it out vortex?

 

[vortex]

Does that mean you have figured it out vortex?

If you define "give up and buy a better board" as "figuring it out", then yes

Actually, I started a thread on the Raspberry Pi forum, and the maker of the boards I'm using found that it's not quite implemented correctly: http://www.raspberrypi.org/phpBB3/viewtopi...=44&t=27235
Something about sending the I2C bus high, but that's over my head really.

 

[jonw]

Can any of you guys give me any hints on setting PID tuning parameters?

I'm building an arduino based controller, and I'm using the PID library for my HLT and MLT direct fired RIMS. I don't know where to start with the PID parameters, or how to use the PID autotune library - the doc and example for the latter are fairly light on.

I think Matho used Kp = 100, Ki = 20, Kd = 5 in the Braumiser. That may not suit my 3V system, but it's a starting point for the time being.

Cheers,

Jon

 

[bonj]

Can any of you guys give me any hints on setting PID tuning parameters?

I'm building an arduino based controller, and I'm using the PID library for my HLT and MLT direct fired RIMS. I don't know where to start with the PID parameters, or how to use the PID autotune library - the doc and example for the latter are fairly light on.

I think Matho used Kp = 100, Ki = 20, Kd = 5 in the Braumiser. That may not suit my 3V system, but it's a starting point for the time being.

Cheers,

Jon

Tuning is the hardest part of the whole process in my opinion, and the lack of documentation on the autotune library makes it pretty well useless. Of the multiple iterations I've run it through, I can get a much better tune just by manually following the process in this article: http://www.embedded.com/design/embedded/42...D-without-a-PhD (link to the original pdf in the top of the article, or just read on for the html version)

 

[Edak]

I tried to explain it here

 

[vortex]

Picked up a couple of I2C relay boards:

Relay board by auvortex, on Flickr

Small one has 8 relays, 10a@250v, I2C connection.


Relay board by auvortex, on Flickr

Big one has 8 relays, 30a @250v. I2C connection also. Likely to need a bloody big heatsink

Got them from http://www.ereshop.com/shop/i2cbus-boards-c-143.html ordered last thursday, arrived today. Not the cheapest boards around but should do the job! Documentation is a little thin on the ground, though Ti chip, so hoping it's common enough that there is plenty of doco around for it.

 

[vortex]

Picked up a couple of I2C relay boards:

(snipped)

Got them from http://www.ereshop.com/shop/i2cbus-boards-c-143.html ordered last thursday, arrived today. Not the cheapest boards around but should do the job! Documentation is a little thin on the ground, though Ti chip, so hoping it's common enough that there is plenty of doco around for it.

FWIW, they both use the PCF8574 I/O Expander chip as outlined on the link above, and documentation is fairly easy to come by. For example: http://garagelab.com/profiles/blogs/tutori...er-with-pcf8574
The work I'll be doing will be in C++ but shouldn't be hard to get it working (and there may already be a library, I haven't looked yet)
Edit: Well that was hard: http://arduino.cc/forum/index.php?topic=109340.0

One of the boards will be used with Arduino, the other with BeagleBone or Raspberry Pi.

 

[jonw]

Tuning is the hardest part of the whole process in my opinion, and the lack of documentation on the autotune library makes it pretty well useless. Of the multiple iterations I've run it through, I can get a much better tune just by manually following the process in this article: http://www.embedded.com/design/embedded/42...D-without-a-PhD (link to the original pdf in the top of the article, or just read on for the html version)

Thanks guys.

Bonj, That's a good article. I'd be grateful if you would elaborate on your tuning process, just so I can make sure I'm on the right track. For example, did you start off with "set all gains to zero", and does that mean Kp, Ki, and Kd are all zero for the Arduino PID implementation, or have I misunderstood that and e.g. Kp != proportional gain?

Also, I think the Arduino PID library defaults to PI rather than PID. There's a command to set it to PID, but I don't see that in anybody's code. Are people happy just using PI? If so, that sounds like it makes the tuning process a little easier.

Cheers,

Jon

 

[zxhoon]

You won't be needing a heatsink as they are mechanical relays not Solid State Relays (SSR), what's the end application for them?
If it is turning a heating element on and off you might want to check the rated number of switching actions for the relays.
Looks like 100,000 on the smaller ones, can't find one on the larger ones.

 

[vortex]

You won't be needing a heatsink as they are mechanical relays not Solid State Relays (SSR), what's the end application for them?
If it is turning a heating element on and off you might want to check the rated number of switching actions for the relays.
Looks like 100,000 on the smaller ones, can't find one on the larger ones.

Oh, thanks for clearing that up Glad to hear it actually as I wasn't sure how I was going to handle mounting it to a heatsink.
The large ones will be as you thought, two of those at least will be for 240v elements (HLT and RIMS), two others at least for March pumps. One will also end up controlling a LBP for HLT recirc.
The 4 of the small ones will be used in a fermentation controller (really didn't need 8!) for switching heating and cooling circuits on; I can build in protection for excessive switching pretty easily into the software for both.

 

[zxhoon]

There's pros and cons for both types, obviously SSRs don't wear out, but being an electronic part they can still fail and can typically fail ON, they are also susceptible to mains voltage spikes although on a domestic supply these are less likely.

Mechanical relays wear out and contacts can weld shut if used on too high a power load or large inductive loads, compressor motors, things with a large inrush current, etc.

I'm not sure how often your heating elements will need to cycle on but at say twice a minute for an hour that is 120 actions which would give over 800 hours... perhaps not an issue but something to be aware of, should be fairly easy to change them if needed down the track anyway

 

[bonj]

Thanks guys.

Bonj, That's a good article. I'd be grateful if you would elaborate on your tuning process, just so I can make sure I'm on the right track. For example, did you start off with "set all gains to zero", and does that mean Kp, Ki, and Kd are all zero for the Arduino PID implementation, or have I misunderstood that and e.g. Kp != proportional gain?

Also, I think the Arduino PID library defaults to PI rather than PID. There's a command to set it to PID, but I don't see that in anybody's code. Are people happy just using PI? If so, that sounds like it makes the tuning process a little easier.

Cheers,

Jon

What I tend to do, is arbitrarily pick a P value, and then follow their instructions with regard to setting the I and D values. Following the very basic premise that the P gain sets to speed at which you approach your target and the I gain sets the rate at which you adjust for error over time (If the correction isn't correcting enough, it accumulates the I gain to correct faster... that can lead to over correction and instability if the accumulator has a chance to run away. This is why Matho only enables PID control within 5C of the target temperature and also why we experimented with clamping the accumulator (I use the modified library in my HERMS, but matho elected not to, in favour of the 5C method)). The D term attenuates (dampens) the speed at which you approach the target as you get closer, so as to hopefully avoid overshoot.

Apart from that, you basically have to run the system a number of times under similar to expected conditions in order to adjust the gains by trial and error. I played with mine in a 2.4KW kitchen jug which enabled me to check it was working and the tuning iterations were faster (albeit completely different from an actual system), but the jug is so over powered for the volume of water that it is very hard to tune.

The arduino PID algorithm, incidently doesn't disable the D term by default. Most people are happy with a PI system, or even a PD. The article I linked does a good job of explaning the benefits and drawbacks of the various configurations.

 

[jonw]

What I tend to do, is arbitrarily pick a P value, and then follow their instructions with regard to setting the I and D values. Following the very basic premise that the P gain sets to speed at which you approach your target and the I gain sets the rate at which you adjust for error over time (If the correction isn't correcting enough, it accumulates the I gain to correct faster... that can lead to over correction and instability if the accumulator has a chance to run away. This is why Matho only enables PID control within 5�C of the target temperature and also why we experimented with clamping the accumulator (I use the modified library in my HERMS, but matho elected not to, in favour of the 5�C method)). The D term attenuates (dampens) the speed at which you approach the target as you get closer, so as to hopefully avoid overshoot.

Apart from that, you basically have to run the system a number of times under similar to expected conditions in order to adjust the gains by trial and error. I played with mine in a 2.4KW kitchen jug which enabled me to check it was working and the tuning iterations were faster (albeit completely different from an actual system), but the jug is so over powered for the volume of water that it is very hard to tune.

The arduino PID algorithm, incidently doesn't disable the D term by default. Most people are happy with a PI system, or even a PD. The article I linked does a good job of explaning the benefits and drawbacks of the various configurations.

Bonj, thanks. I'd got the PID library and PID autotune library confused - it's the latter that defaults to PI.

I've since looked through the PID library to see how the output is calculated, and it's a whole lot simpler than I'd thought. In the sort of scenario a PID's going to be used for in a home brewery, it seems to me that the D term is ineffective unless the gain (Kd) is very high. For example, in my HLT, I'm getting about 1 degree a minute temp rise. That's a small fraction of a degree per second. Unless Kd is several hundred, the impact of the D term is going to be insignificant. However, my DS18B20 measures at 12 bits, so increments in 0.0625 degree jumps every several seconds. I therefore get several seconds of D=0 followed by one of D=high, i.e. noise. I've therefore effectively disabled D by setting it to 1.

When I originally went through Matho's code, I didn't understand why (a) he'd disabled PID until within 5 degrees, and ( B) set the PID output to 100 when his PID window size is 5000ms (at least I think he's done that, now I'm not sure

I had my PID output set to 5000, as that's what my window size is. The trouble is the I term winds up to 5000 very quickly, and unless Ki is large, the accumulator takes ages to unwind and you get huge overshoot. I've now set my output to 100, and just use a multiplier to convert that to my window size (i.e. max output x 50 = window size.) With Ki limited to max output, it's a lot quicker to unwind with a smaller Ki. Here's the sort of response I'm getting on a test run of my HLT ~ 2/3 full with Kp = 100, Ki = 1.4, Kd = 1



I'm still getting some overshoot, but no oscillation, and it settles down to target temp within a few minutes. That's fine for the HLT. Next is the direct fired RIMS MLT which might be a bit more tricky to tune.

Cheers,

Jon