Matho's controller

[SBOB]

The correct code is


void load_pid_settings () {
myPID.SetTunings(r_set(1) - 100, (double)((r_set(2) - 100.00) / 250.00), r_set(3) - 100);
WindowSize = r_set(5);
myPID.SetSampleTime(r_set(4) * 250);
}

This section call the parameter from EEPROM and set the PID before start the elecrical Mash process.

I have downloaded this code from public dropbox space

MaxN68, while you are here...do you maintain/modify any of the code
While playing with Lael's kit I found an error in the LCD20x4_ENG.h file which causes the PID settings to show an invalid character at the end of the line on every setting except the first, as the first settings (Electric/Gas) are offset by one too many chars (current cursor offset is 10,2 but needs to be 9,2 to make the Gas and Electric strings stop at the same location as the other settings). Looking at the history of the file it seems it was modified back in Feb and changed from (9, 2) to (10, 2).

e.g.

void PidSet(int pidSet, byte i){
if (i == 0) {
lcd.setCursor(9, 2); //<- This line was previously lcd.setCursor(10, 2);

 

[heffa35]

I see that the dropbox code is same as github code if we remove all the comments.
Thats a good sign. Maybe it is correct and working just my process thats wrong.


Today I realized that the r_Set array is set in the set_PID () function.

Back to square one.

I will give it another go tonight.

Thanks for the responses

 

[MaxN68]

The released code is Open Source nature and as such is maintained, particularly as regards the various translations.
The files in question are sent by people they did a tremendous job for the good of the community, some of them even make beer.
I can not verify every time the accuracy of that code, it would be impossible to do so, but I will only control the bugs reported on the program logic.
Very often this feedback even happens and we find ourselves continually to debug to ensure that you do not have serious errors on the procedure.

I'm sure that there are no errors on the PID procedure, also because I use ArdBir and I have a temperature error <+ - 0.25.
The process of setting the PID is long and tedious, but it can very well be done one step at a time to every Mash. Do not come into play only the values ​​of PID constants but also the values ​​assigned to SampleTime and WindowSize. Sampling time high reactivity minor damage but facilitate the setting, lower speeds can make everything very fast intervention of correction but also less stable.

As for the display error would have liked to have a feedbak with a proper file to be sent to the email address [email protected]

I thank you for the attention you show in our project, we will soon have some news to announce.

Stay tuned

[Google Translate]

 

[megabyte]

MaxN68, while you are here...do you maintain/modify any of the code
While playing with Lael's kit I found an error in the LCD20x4_ENG.h file which causes the PID settings to show an invalid character at the end of the line on every setting except the first, as the first settings (Electric/Gas) are offset by one too many chars (current cursor offset is 10,2 but needs to be 9,2 to make the Gas and Electric strings stop at the same location as the other settings). Looking at the history of the file it seems it was modified back in Feb and changed from (9, 2) to (10, 2).

e.g.

void PidSet(int pidSet, byte i){
if (i == 0) {
lcd.setCursor(9, 2); //<- This line was previously lcd.setCursor(10, 2);

Ahh, I just came across this post. I submitted a code fix and pull request on github earlier today to clear that last character but I think moving the "Electric/Gas" text one position left as SBOB suggested would have been a more elegant solution.

Pull request can be viewed here: https://github.com/ArdBir/Open-ArdBir/pull/3/files

Incidentally, can anyone point me to the specifics about compatibility with the particle photon shield shield? I read there was a pin mapping issue but I can't find the specifics. Surely nothing that a stanley knife and soldering iron can't fix?

 

[MaxN68]

Sorry for the lack of maintenance of GitHub but I can not do it.
I don't have a DSL connection and I had to delegate the maintenance to others.
My only possibility to connect at internet is my phone, but I have low GB profile of data traffic.
I can connect in office also, but in this moment I don't have work.

Please give me any suggestion, bug report or correction in email: [email protected]

Thank you.

 

[real_beer]

Sorry for the lack of maintenance of GitHub but I can not do it.
I don't have a DSL connection and I had to delegate the maintenance to others.
My only possibility to connect at internet is my phone, but I have low GB profile of data traffic.
I can connect in office also, but in this moment I don't have work.

Please give me any suggestion, bug report or correction in email: [email protected]

Thank you.

Max, you and your team have done a great job with all the new features in the code, it can't be easy writing technical information, code and answering questions from around the world in so many different languages, excellent work. :beer:

 

[megabyte]

Hey MaxN68, just wondering why is the temperature rounded to the nearest half-degree? E.g. 25.00c, 25.50c

 

[MastersBrewery]

Hey MaxN68, just wondering why is the temperature rounded to the nearest half-degree? E.g. 25.00c, 25.50c

The resolution ie accuracey would increase code size of the PID library. There is simply no more space for code on the arduino uno. If you are using Laels kit or arduino mega the code space is there to expand these sorts of capabilities. How ever I know nothing of coding at all so some smart bunny would have to put in the work and create a variation for the mega with changes to increase resolution (the probe is capable of easily 0.1) .

MB

 

[lael]

Do people really need more than 0.5 accuracy for brewing?

 

[real_beer]

If you've ever seen the 'Vicar Of Dibley' .. Yes ............. yes, yes, yes, yes yes........... No! :lol:

 

[SBOB]

Do people really need more than 0.5 accuracy for brewing?

I think its more the OCD side of things of seeing the temp jump in 0.5 steps

And on that note, Lael can you tell me the exact model of the temperature probe?
The current adruino code is progammed to assume's its a 'DS18S20 or DS1820'. Its part of the 'one-wire' library.

The code to read the temperature needs to be slightly different for the DS18B20 (and DS1822), because it returns a 12-bit temperature value (0.0625 deg precision), while the DS18S20 and DS1820 return 9-bit values (0.5 deg precision).

From the checklist it says 'DS18B20'. Is that correct?

 

[MaxN68]

The probe resolution with oneWire library is 0.25.

You can put the probe resolution at 0.125 or 0.0625 whit Dallas additional library.
The space for coding is 99.9% full, you can use Arduino Mega for this solution but the probe resolution (0.125) cause a delay of 65%, for 0.0625 probe resolution the delay is 135% (it's verified!!!); .
The ArdBir code run on Arduino Uno shield with minimal delay problems with 0.25 resolution.

We have evaluated every possible solution to add new features, but this would necessarily lead to the PCB's restructuring and rewriting code.

if I write code, I'll totally rewriting with new proprietary algorithms simplifying some logical and reviewing the entire structure and layout and of course a new PCB dedicated

 

[lael]

Sbob, its an ds18b20. You can prob check previous versions of ardbir to see versions that have .25 resolution. The mega has plenty of space

 

[MaxN68]

Sbob, its an ds18b20. You can prob check previous versions of ardbir to see versions that have .25 resolution. The mega has plenty of space

It's not an ArdBir Version problem!!!!

The probe resolution is RESIDENTIAL in the probe.

If you have used the DS18x20 whit another resolution these is permanent in probe.
You must reprogram the resolution probe with any example sketch of Dallas Library


it's NOT a space question, the Mega is not a solution

 

[lael]

Hi max, I thought the max resolution was in the probe and you can read a lower resolution using software?

So the natural resolution of the ardbir software is normally 0.25?

 

[MaxN68]

The max resolution of the probe is 0.0625. In ArdBir and Brauduino has always used a resolution of 0.25, it is clear also from the temperature settings that have just steps of 0.25.
If you set 0.125 resolution you have the 60sec of timer = 96sec real time

 

[MaxN68]

If you want to use 0.125 resolution you need to rewrite timing code using a RTC module and a new PCB and use 3 new library (1 for the probe and 2 for the RTC).

 

[MaxN68]

the benefit you get going from 0.25 to 0125 does not justify the amount of work and recoding necessary hardware and software, regardless of the increase in spending.

 

[lael]

To be honest Max, I don't even think that 0.5 increments are a big problem. I think for most people it is something that would be nice. I think mainly because it shows the heating changing faster.

I confirmed last night it is the probes. One temp probe I stuck in went up by .25, the other up by .5 (different styles of probe).

 

[MaxN68]

You can set the probe with any Dallas Library example