Stc-1000+

[nickmv]

Cool, thanks for your hard work. I'll try to remain professional on any future frustrations.

My biggest deal was that it was 1:45am and I never did solve things. That's the point at which you just pull your hair out and "aaahhhH!!!!!! why wont this work? damnit!!!"

I def appreciate all you're doing here, and will be flashing this when I get home. And here's the upside -- I now have TWO modded controllers!

 

[disney7]

With the latest work commit, things look pretty dang good. The delays are working like they should.

The only thing I noticed was that the delays are a little short and get worse as the delay increases.

I'm using an ice pack and warm water to manipulate the timer. I started a stopwatch when the solid cooling led went off, then raised the temperature back above the set point. Stopped the clock when the cooling led came back on solid instead of blinking.

A 60 second delay was pretty close.

A 5 minute delay was more like 4m50s.

A 10 minute delay was about 9m40s.

A 15 minute delay was a little less than 14m30s

I've run those tests a couple of times each and they're as consistent as my reaction time can be with a stopwatch.

This isn't a big deal for the heat/cool delays. If the programs are using the same timing system it might add up on long steps and cause a problem. Though, when we're talking about step times for a fermenting process, even an hour or so either way is probably not going to make any difference.

 

[disney7]

Just ran a test with a 1 hour step on Pr0. It did not short the step by 2 minutes like I expected. It's hard to tell exactly when it changed because you have to keep checking the set point, but it looks like it switched right at 60 minutes. I'll run a longer test and let it cook all night.

 

[atoughram]

I was wrong about the factory behavior. The factory units I have here do not have separate initial cooling and cooling delays. They both match whatever the user setting for cooling delay is. The default is 10 minutes, that might be where I got that idea from.

Anyway, 60 seconds sounds good to me for initial cooling. I don't see much need for any initial heating delay, but 60 seconds won't hurt anything.

Yes - that's how mine work. Delay on cooling only - settable in the menus.

 

[uatuba]

Every time I get on this board, you bastards post something that makes me spend money.

Monday I'll have a couple more STCs, a new soldering iron, as well as an Arduino.


Sent from my iPad using Home Brew

 

[adam01]

> Every time I get on here...

Same here...

This is supposed to be my year of not buying any brewing equipment.

 

[nickmv]

Just wow. This latest work branch version, alpha, is amazing.

So many improvements, and I'm really liking the up & down button quick-views (they work well). It's really handy to see how many hours have elapsed.

I'm going to keep testing, but this is a night-&-day difference versus last night's experience with the previous build. You should def push this to the main public branch for "official" releases, though that's purely a symbolic move anyways.

 

[tom_hampton]

Cool, thanks for your hard work. I'll try to remain professional on any future frustrations.

My biggest deal was that it was 1:45am and I never did solve things. That's the point at which you just pull your hair out and "aaahhhH!!!!!! why wont this work? damnit!!!"

I def appreciate all you're doing here, and will be flashing this when I get home. And here's the upside -- I now have TWO modded controllers!

Come on, now. I've spent a large portion of my life developing embedded products: from robotics to avionics to industrial controls. 145am is just barely getting started. If the sun isn't up yet, it is a good night.

 

[atoughram]

I'm looking at some of the programming.... Wow... I salute you...

I'm still trying to figure how you figure the temperature out with this... I need more scratch paper...

	for (i = 0; i < 32; i++) {
if((temperature & 0x1f) <= i){
temp += ad_lookup[((temperature >> 5) & 0x1f)];
} else {
temp += ad_lookup[((temperature >> 5) & 0x1f) + 1];
}
}

I get the for loop..

If the lower five bit of the variable temperature <= i - I get this...

temp = temp + look up the value in the variable ad_lookup at the location held within bits 5-10??

Do this 32 times?

You sir must be a genius... I'm still scratching my head.

(I've never been a professional C programmer - but I can kinda read it..)

 

[nickmv]

Come on, now. I've spent a large portion of my life developing embedded products: from robotics to avionics to industrial controls. 145am is just barely getting started. If the sun isn't up yet, it is a good night.

Haha, true, but I have a job by day (proj mgr and systems analyst). Gotta get sleep or I'll be grumpy and useless at work the next day.

 

[tom_hampton]

Haha, but I have a job by day (proj mgr and systems analyst). Gotta get sleep or I'll be grumpy and useless at work the next day.

Program manager!?! Well that explains everything.

Engineers have day jobs, too... Ya know. Somehow we still manage not to kill ALL the program managers in the morning.

 

[alphaomega]

With the latest work commit, things look pretty dang good. The delays are working like they should.

The only thing I noticed was that the delays are a little short and get worse as the delay increases.

I'm using an ice pack and warm water to manipulate the timer. I started a stopwatch when the solid cooling led went off, then raised the temperature back above the set point. Stopped the clock when the cooling led came back on solid instead of blinking.

A 60 second delay was pretty close.

A 5 minute delay was more like 4m50s.

A 10 minute delay was about 9m40s.

A 15 minute delay was a little less than 14m30s

I've run those tests a couple of times each and they're as consistent as my reaction time can be with a stopwatch.

This isn't a big deal for the heat/cool delays. If the programs are using the same timing system it might add up on long steps and cause a problem. Though, when we're talking about step times for a fermenting process, even an hour or so either way is probably not going to make any difference.

Well, wow. Unless you've been reading the code... I didn't think anyone would notice.
The delays are short, but the reason is a good one.
In fact one of the things I have been very careful in doing, is selecting counter sizes so they wont overflow.
The frequency of the main timer is also very carefully selected.
I need one hour to fit in a 16 bit counter, that means frequency needs to be below around 18Hz. I also want 1 sec marks to be easy to detect (i.e. freq. should be power of 2). And I also need frequency to be high enough to sample buttons.
This pretty much leaves 16Hz as only option (62,5ms). It is a bit slow for buttons, but will work.
Now unfortunately, 16Hz is not possible to achieve with the timers. Closest possible value is 16,66Hz (60ms). That means that the one second marks (16*60ms) really only is 960ms. So yeah, it is close, but not really accurate.
The one hour mark occurs on the counter being 60000 which should be an hour exactly (of course no timer is totally accurate, but I have no control over that).

Just wow. This latest work branch version, alpha, is amazing.

So many improvements, and I'm really liking the up & down button quick-views (they work well). It's really handy to see how many hours have elapsed.

I'm going to keep testing, but this is a night-&-day difference versus last night's experience with the previous build. You should def push this to the main public branch for "official" releases, though that's purely a symbolic move anyways.

Thanks! There really is not that big a change from yesterday, except that I found the compiler problem (which is really not my fault).
I'll push the changes.

I'm looking at some of the programming.... Wow... I salute you...

I'm still trying to figure how you figure the temperature out with this... I need more scratch paper...

	for (i = 0; i < 32; i++) {
if((temperature & 0x1f) <= i){
temp += ad_lookup[((temperature >> 5) & 0x1f)];
} else {
temp += ad_lookup[((temperature >> 5) & 0x1f) + 1];
}
}

I get the for loop..

If the lower five bit of the variable temperature <= i - I get this...

temp = temp + look up the value in the variable ad_lookup at the location held within bits 5-10??

Do this 32 times?

You sir must be a genius... I'm still scratching my head.

(I've never been a professional C programmer - but I can kinda read it..)

The loop is for interpolation between the lookup points.
As you said, upper five bits are used to lookup the value in in lookup table. Lower 5 bits are used to interpolate.
((32-x)*lookup[y] + x*lookup[y+1]) / 32 (where x is lower 5 bits and y upper)
Only the MCU doesn't have hardware multiplier, so the multiplication is rolled out to additions.

 

[nickmv]

The loop is for interpolation between the lookup points.
As you said, upper five bits are used to lookup the value in in lookup table. Lower 5 bits are used to interpolate.
((32-x)*lookup[y] + x*lookup[y+1]) / 32 (where x is lower 5 bits and y upper)
Only the MCU doesn't have hardware multiplier, so the multiplication is rolled out to additions.

WHaaaaaaat? Uhhh.......yeah. Sounds right, totally.

That just flew 1,000,000 ft over my head.

 

[atoughram]

Thanks! Multiplication.... Hmm... I understand the bit shift rights for division - and it was in the comments - so in a sense you're adding up a value and taking the mean average?? I'll find some more scratch paper.. I've tried to use a thermistor on an arduino - ended up attempting to use a steinhart-hart equation - had it kinda working without a lookup - tried a DS18B20 instead and never looked back. I understand why you don't want to make a hardware change though, the STC is already a nice package.

I've read a lot of PLC code - and it's always amazing to figure out someone elses code. You really get to know the programmer, even if you've never met.

 

[alphaomega]

Thanks! Multiplication.... Hmm... I understand the bit shift rights for division - and it was in the comments - so in a sense you're adding up a value and taking the mean average?? I'll find some more scratch paper.. I've tried to use a thermistor on an arduino - ended up attempting to use a steinhart-hart equation - had it kinda working without a lookup - tried a DS18B20 instead and never looked back. I understand why you don't want to make a hardware change though, the STC is already a nice package.

I've read a lot of PLC code - and it's always amazing to figure out someone elses code. You really get to know the programmer, even if you've never met.

No, not mean average, linear interpolation.
The lookup table can not be big enough to hold every possible AD value, but it does not need to be. If looking at a small enough piece of the NTC temperature/resistance curve, it is linear enough.
So, the upper five bits in the AD value tells me the temperature I want is between that point in the lookup table and the next. How far between is the lower five bits.
Instead of multiplying I add x times the value from the second lookup point and 32-x times the value from the first. Divide by 32 and the resulting value is between the two points proptionally to the least significant bits of the AD value.
Maybe my explanation is not that great, wikipedia has a decent article on linear interpolation

 

[alphaomega]

Ok, latest updates.

I have pushed two more changes to work branch.
I have fixed sensor alarm. If it works as it should then sensor failure should sound the alarm and disengage relays, it will also turn off the display as the functionality is shared with 'power off'. (A temperature reading out of range is considered a sensor failure). Pretty useless feature IMHO, as if you forgot to attach the probe, you would see that you don't get a reading, and if sensor fails later, you might not be around to hear it.

And I have also added the degree dot (+ 'C' if celsius) when displaying a temperature.

And that is it. I don't have any more issues that I plan to fix or features that I plan to add.
So, now main focus is testing and fixing any bugs.

 

[MikeInMKE]

It looks like you already found and worked around the compiler bug, and the following suggestion would not have helped, but I've used "lint" on more than one occasion to find bugs before debuggers became available.

 

[disney7]

Alpha, would it be better to leave the display on under sensor alarm and show an indication (such as 'AL') or does it need to use the power off routine due to memory?

Also, I just finished setting a program that I'm going to let run for 72 hours and log the temp changes. Is there any way to have the setting change rate boost after you've held the up/down button for more than X seconds? It took me a while to set 10 set points and 9 duration. No problem if it can't be done, it would just be handy.

Thanks!

 

[disney7]

I just finished an 8 hour step test. It actually took 8 hours and 2 minutes to switch to SP1.

I'm not sure when it actually sets and activates the profile. I assumed it was when you hit set after switching from thermostat mode to Pr0. That's when I started the timer.

Not a problem unless you think it indicates one.

 

[nickmv]

I just finished an 8 hour step test. It actually took 8 hours and 2 minutes to switch to SP1.

I'm not sure when it actually sets and activates the profile. I assumed it was when you hit set after switching from thermostat mode to Pr0. That's when I started the timer.

Not a problem unless you think it indicates one.

Sounds pretty damn good/close to me. Wouldn't you say?

 

[alphaomega]

It looks like you already found and worked around the compiler bug, and the following suggestion would not have helped, but I've used "lint" on more than one occasion to find bugs before debuggers became available.

Yeah, I've tried lint once or twice. It can be a useful tool, but in this case, I could pretty much guarantee that lint would not know that the compiler I intended on using had a bug

Alpha, would it be better to leave the display on under sensor alarm and show an indication (such as 'AL') or does it need to use the power off routine due to memory?

Also, I just finished setting a program that I'm going to let run for 72 hours and log the temp changes. Is there any way to have the setting change rate boost after you've held the up/down button for more than X seconds? It took me a while to set 10 set points and 9 duration. No problem if it can't be done, it would just be handy.

Thanks!

I won't lie, it probably wouldn't be that hard to show "AL" on alarm. Dammit. Now I probably have to go fix that, just because you think it is 'the right thing' (tm).

I know programming by hand is frustrating because of this, and while it might not be impossible to speed up or increment by more than 1, it would probably be a kludgy mess, and I'd like to avoid that. But I hear you. I'll think about it. Maybe. If I can do something clever. Like triggering button_menu_fsm from it's own timer and gradually increase frequency of the timer. Dammit....

I just finished an 8 hour step test. It actually took 8 hours and 2 minutes to switch to SP1.

I'm not sure when it actually sets and activates the profile. I assumed it was when you hit set after switching from thermostat mode to Pr0. That's when I started the timer.

Not a problem unless you think it indicates one.

Yes your assumption is correct to within the second. It is not a problem, that would mean an accuracy of 0.4% if my math is correct which is better than to be expected of the internal timer.

 

[alphaomega]

Oh man!!!!

That timer idea was pretty incredible You gotta try it out!!!
That **** is smoooooth now!

Check it out, I pushed to work branch.

 

[rattle_snake]

Can any of the regular Microchip programmers be used to download code to the PIC16 using MPLABX?
Real ICE, ICD3, Pickit 3...

 

[atoughram]

Can any of the regular Microchip programmers be used to download code to the PIC16 using MPLABX?
Real ICE, ICD3, Pickit 3...

I'll tell you in a few days - I'm trying a K150 and microbrn.exe

 

[atoughram]

Alpha - Are you using the arduino sketch to load the hex file now - specifically is the hex file embedded within the sketch? I'm wondering what the huge hex constants located at the end of the sketch or for? Can I use one of the *.hex files and my pic programmer instead of an arduino? Or am I forced to utilize an arduino?

 

[alphaomega]

Yes, the hex data is embedded n the sketch, to make uploading as easy as possible.
I see no reason why using a regular PIC programmer wouldn't work. And yes, I also provide the hex files for those who'd rather go that route.

 

[atoughram]

Yes, the hex data is embedded n the sketch, to make uploading as easy as possible.
I see no reason why using a regular PIC programmer wouldn't work. And yes, I also provide the hex files for those who'd rather go that route.

Thank You

 

[balrog]

Yes, the hex data is embedded n the sketch, to make uploading as easy as possible.

alphaomega, you mentioned a compiler bug earlier in the thread. If I wanted to set up SDCC and GPUTILS (say to set up different defaults to be flashed rather than using the buttons to enter profiles) what was the bug and what was the cure? And actually, would it be feasible to edit the hex data area of the file to 'pre-load' different profiles to the 'stock' AlphaOmegaSTC file?

 

[alphaomega]

alphaomega, you mentioned a compiler bug earlier in the thread. If I wanted to set up SDCC and GPUTILS (say to set up different defaults to be flashed rather than using the buttons to enter profiles) what was the bug and what was the cure? And actually, would it be feasible to edit the hex data area of the file to 'pre-load' different profiles to the 'stock' AlphaOmegaSTC file?

Theres no problem using SDCC to compile the code now. You can't rely on static local variables to be initialized. I moved the variables to global scope as a workaround.

I think this area could stand a bit of improvement. I've been cheating a bit in the sketch when uploading the hex. Ideally, I would separate the EEPROM data to it's own HEX file and not erase EEPROM unless that data is uploaded.
There really is no reason to reset EEPROM when uploading a newer version if EEPROM config has not changed.
I'm even considering reserving two bytes of EEPROM for a magic byte and version, so this could be automatic.
A tool to allow the user to set the data would be cool, and could probably be done with macros in the sketch. But that would be prio 2.

 

[disney7]

I haven't had a chance to try the latest commit with the change to the setting acceleration. Looking forward to it.

I'm out of town this weekend, but I did set up a 10 step program to cover a 72 hour period. BrewPi is logging it in a dorm fridge.