feature? staged temperature limits?


 
J

Johannes S

TVWBB Member
as i already mentioned in another thread, i own a qmaster senior as well. one great feature of this pid controller is that it can hand over pit control from pit probe to meat probe.
EG: so you set pit probe hold 115°C (240F). you now can set an alarm to inform your when your bbq reaches 92°C (198F). but this won't change a thing. you can now lower temp by script or do something else.
what qmaster does: it hands over pit control to the bbq probe. so you want the meat to maintain 92°C (198F) for 2h and change the pit temperature accordingly. after that, as your guests have not arrived yet, you want to keep the meat warm and automatically set bbq temp to 70"C (160F) for infinity, and pit temp is controlled by bbq temp.
maybe this is already possible and i haven't found it. if not: what do you thing about it?
 
would you mind sharing this script? has anyone done that before and wants to share? i'm no coder so this is a bit above my horizon. (i read the scripting wiki pages of course)
 
I've heard of ramp and hold scripts for the HM but none that re-assign the pit probe? I had long requested a feature in the HM that would allow you to choose the pit probe among the 4 available, Bryan indicated that was more of a programing issue than he wanted to tackle. (I think it has something to do with the web page display and rearranging the probe that is displayed as PIT PROBE, and or the LCD display on the HM unit). So to my knowledge that feature has never been included in the HM, however, some time ago I came up with the idea to make the Pit Probe flow down stream, meaning, if you disable PROBE 0 then Probe 1 becomes the pit probe, if Probe 0 & 1 are disabled then Probe 2 becomes the pit probe.... This feature is nice and currently in place, however, it still doesn't directly allow you to SELECT the probe to use as the pit probe.

So, with the features we have available the only way I can think to get what you are after is to put the food in question on Probe 1 and then write a script that would change the setpoint AND disable PROBE 0 when an alarm is triggered.
 
Last edited:
haven't heard of swaping probes as well, but i'm a noob about all heatermeter stuff.
bryan pointed me to the beta firmware that can handle probe hand-over. so if you disable probe0, then probe1 will become the PIT PROBE. and so on. this would be totally fine for me as i use probe0 as pit probe and probe1 as bbq/meat probe. and you are right, disabling probe0 doesn't rearrange the webpage etc. but this is no big deal for me. it just would indicate that the "main part" is over if it says "OFF" and it started holding temperature.
so ralph your idea is brilliant, but i'm afraid it's not that easy because PIDs will be TOTALLY different for a probe that is inside the grill, and a probe that is inside several kg/lbs of meat. this is like a speedboat and an oil tanker. isn't it?
to change the temperature of the meat for only a tenth of a degree it needs minutes leaving it set on the grill. so PIDs would be different. but: can we change PIDs by script as well? or am i wrong and we don't need to?
 
Last edited:
I have never given thought to running a pit with the pit probe stuck in a piece of meat, that is a bit of an odd concept...

I don't think you would have to alter the PID settings for the grill because the dynamics of the fire and grill haven't changed, the meat volume is the same, the vents the same etc...

Obviously what you would get is a long choking of the fire to drop the pit to the meat temp, then as long as the fire hasn't been put out the HM should be able to work the pit temp around the meat temp pretty well... as long as that temp is not lower than your pit can achieve otherwise. The big worry here would be putting the fire out during the long choke, but there are ways you can prevent this if that is your plan of action.

So I think if you can have a meat alarm trigger a script that changes your setpoint to the meat done temp and disables Probe 0, and your meat is on Probe 1 (or the next non-disabled probe) you should achieve your goal. kinda.

That said, I don't think it will work the way you want it to in practice. Reason being, even after you pull a large piece of meat out of a grill it continues to rise in temp. So after your meat alarm triggers at say 195F, and lets say the pit is 250. The pit has to drop 55F and during that time the meat will likely continue to rise in temperature, so when the pit hits 195 the meat will be hotter than that so the HM will allow the pit to continue to cool, by the time your meat cools back to the target temp the fire will likely be out.

Anticipating that you might time your script so the change happens a few degrees prior to your target done temp for the meat, and make the new setpoint be the actual done temp. This way as the pit cools the meat will rise and if you've got everything just right they should meet right around the done temp and hold there for however long...

And thinking of the concept further I think you would have to get this down to an EXACT science. Reason being, say your meat ends up a couple degrees below the "hold" temp. Now the HM is going to stoke the fire, but the pit probe being stuck in the meat isn't going to react (or will react EXTREMELY SLOWLY) to the change in pit temp, so the HM will continue to stoke the pit way up beyond the target temperature because it doesn't know the temp is already above the setpoint.

So, bottom line, I really don't see the point in running the pit with the pit probe stuck inside a piece of meat, it will just make it hard for the HM to control your pit temp. You should just trigger the alarm to change the setpoint to hold temp using the same pit probe as always. Or you could use a fancy ramp and hold script that you trigger a bit below the done/hold temp that would slowly lower the pit temp as the meat approaches the done temp. This is IMHO the best way to achieve what you are after here, a ramp and hold situation....
 
Last edited:
ok. i rethought that. as i said this is not my idea, but how other bbq controllers do it. and it does work. so i wanted to replicate it with the heatermeter.
my last bbq went on the grill at 19:00 and was done 5:00 in the morning. the bbq alarm went off and i got up. with an automatic the grill would have turned down temp to 90C and hold it there, then reduce it further to keep the bbq warm till ready to eat (i foil after 7h on the grill so the meat won't become dry no matter how long it's on the grill).
so of course setting the pit temperature to 90C would be good enough as soon as the bbq reaches 90C. it will gain temperature and will maybe reach 92C something. which is fine. this is not rocket science after all. 2 degrees more or less won't do any harm. and 1-2h later the pit temperature will be set to 60C and bbq will cool down slowly but won't go below 60C.
the grill will go out it air is cut for 20min+. and there will be some overshoot because the fan will kick in too late and it will take some time to add up temperature again.
this may be solved by giving some short air burst every min or so. just enough not to let the fire go out.
can all this be done with scripts?
 
You don't need a script for dropping to a holding temp, you just put 90 in the "Setpoint" box on the alarms page. When the alarm goes off, it lowers the setpoint to 90. There's no built in timer for changing the temperature though.

If I do this I usually use the script from the wiki to have the setpoint ramp down as the meat temp comes up. Reason being, like you say, if you try to drop from 225F to 190F, it can take so long that the fire might go out.

You can also change the Food 1 probe to be the control probe in an alarm script so it controls the pit, but that won't work at all because the food temp takes too long to change (as Ralph pointed out). Your output would go be either 0% or 100% within a minute and your fire will either go out or spike by a couple hundred degrees.
 
The alarm setting to change the setpoint is a down and dirty way to accomplish this, and that would probably work well if say you are cooking at 225 and want your hold temp top be 195-200. I think the pit could prob drop 25F an still be burning, but more than that IDK.
The ramp and hold script, though a little more complicated, is a much better solution for this. Like Bryan said, it will lower the pit small amounts every so often which will allow the pit to breath a bit and keep the fire from going out....

I watched someone do a ramp and hold cook a while back and it was pretty cool, though I have never done it because I am usually present to do these things manually.

Had you (Bryan) thought of building the ramp and hold script into the default HM alarm configuration? It would be kinda nice to be able to select "ramp and hold" rather than just a new setpoint. I think you would just need provide a few more data fields, like ramp start temp, done temp, and incremental temp change and time between steps??
 
Yeah I can see the use for it, but there's a lot more to it than just adding a start / end /duration fields. I don't know if start and end are needed at all, start is the setpoint, end is the meat temp. End could be useful though. The bigger thing is showing the user that it is happening (I am not a fan of "just add another indicator to the screen with 300 things on it already"), and how to turn it off if it is on. I would imagine any setpoint change would turn it off, and the HeaterMeter wouldn't know it is in ramp mode because it doesn't understand time at all. So linkmeterd would be handling it and what if the user changed the setpoint on the device, going around HeaterMeter! It's complicated.
 
what I meant by start and end temp and duration is:

Start = temp where ramping script begins

End = final holding temp of the grill/meat

Duration = how long between temp steps

I guess you would also want a setting for how many steps or how many degrees per step.

Start and end are already there with the trigger temp and setpoint change fields. As for duration, how does the ramp and hold script manage that now, is it not a timed step scenario?

The way I envision it the ramp and hold script that is available now gets added to the HM code and activated when you fill in these extra fields on the alarm page, or when you check a box for "Ramp and Hold".

As for what to do if the user changes the setpoint either on the screen or HM directly, the user should know not to do that if they are using ramp and hold.....
 
Oh derp, that makes more sense now. Do we even need a duration? I mean the duration is set by the End temp. Basically, it would scale the pit temp between SetPoint and End proportional to how far along between Start and End it is, right? Example:

Setpoint: 225
Start: 180
End: 200
Control: Food 1

So when Food 1 hits 180, the setpoint is "captured" and set to 225.
Food 1 = 181, Setpoint = ((225-200)*(1-(181-180)/(200-180))) + 200 = 223.75
Food 1 = 185, Setpoint = 218.75
Food 1 = 190, Setpoint = 212.5
Food 1 = 200, Setpoint = 200

I could put separate "Ramp and Hold" box on the Alarms page for now that would allow the input of the Start, End and Control probe. Control probe can be set to Disabled to disable the feature. Is there something wrong or not optimal with this implementation?

the user should know not to do that if they are using ramp and hold.....
Click to expand...
hahahah the user never knows what not to do. Besides, the HeaterMeter should try to do the right thing based on user input regardless of its state. I can try to code it as defensively as possible though which should work most of the time.
 
Having not used the ramp and hold script I admit I am a little foggy on it.... but you're right, if you trigger the pit temp to drop each time the food temp rises that should do the trick (without any duration setting).

As for the question "what if the user changes the pit temp manually"... What I would expect the HM to do if you have ramp and hold enabled and then you manually change the setpoint is ignore the alarm and ramp script and follow the manual setting. IDK if that is a problem, to kill the script if the setpoint is changed manually?

I like the idea if ramp and hold setting and I think it would be a popular feature if enabled.
 
RalphTrimble said:
I like the idea if ramp and hold setting and I think it would be a popular feature if enabled.
Click to expand...
Yeah I agree, and it isn't super complicated apart from the possibility that if power is lost the ramp wouldn't continue properly because the original setpoint would be lost. I probably will store it in non-volatile flash which shouldn't be a problem.

The only issue I can see is trying to detect when the user manually changes the setpoint through the HeaterMeter menus. There's a certain amount of disconnect between the script and the HeaterMeter device so when it says "Change setpoint from 100 to 99" it doesn't know if it took for a second or more so if the user just happens to change the setpoint in that second, the script wouldn't know so it would override the setpoint the user selected next time the script changes it. Super small chance but it is one of those things where you think you made the change and a few minutes later if goes back to ramping. I'll have to see if I can figure out how to properly detect it.
 
How difficult would it be to put some sort of indicator on the HM web page (and/or) lcd when a ramp/hold script is triggered and functioning? This would at least let the user know if the ramp hold is active or has been deactivated for some reason (like a manual setpoint change).
 
Yeah there's gotta be some sort of indicator. Maybe something like this with a common color to indicate the two are linked (although the color I chose almost at random for the mockup)
 
That would be great... You would know straight away that the HM is under control of the ramping script, and if/when it has been canceled by manual override.
 
I added this to the todo list, it isn't all that complicated now that we're talked it out. I don't know when I am going to get a chance to work on it though. I've put in 52 hours this week for work so far and it's 9am on Friday. This weekend I drive 7 hours each way to visit family. I wish we had self-driving cars I could totally code this up on the way!

I also didn't realize how far along the PID auto-tuning code was. I mean it is virtually complete apart from the manual step of setting it up, and a cool UI to show you the data
Code: 
New -1 peak @1437138728=41.9 half=1619 per=6332 amp=-5.2 gain=-0.2
   Ziegler P=2.4 I=0.001 D=63.3
root@OpenWrt:~# lmclient LMDS
Histogram=95409,1993,425,615,469,353,294,77,0,...,0
hmMode=3
hmUpdateCount=0,1,99635,0,0
peakCurr (01) @1437141489=45.1 half=0 per=0 amp=0.0 gain=0.0
peakLastHigh  @1437137109=47.1 half=4713 per=6357 amp=5.0 gain=0.0
peakLastLow   @1437138728=41.9 half=1619 per=6332 amp=-5.2 gain=-0.2
All sorts of fun data that it continuously tracks, even when not tuning. We can see I have a ~5F swing in temperature, with a ~6300 second period, 4713 seconds to climb to the high peak, 1619 seconds to return to the low peak. The controller spends all of its time running less than 7% speed, which would be an indicator that there's too much airflow.
 
Wow, if we get Auto Tune and Ramp and Hold alarm scripts built into the next software release it'll be like christmas! Where's the Google car when you need it! LOL
 
I have been waiting to try one of these Ramp scripts on a brisket. Checked Costco again last week and I almost need to put the brisket on my home equity loan at $5.69per lb. If I understand this correctly it should be meat lovers nirvana. I think I paid $1.69 last year for a cheap grade after labor day.
 
You must log in or register to reply here.

 

Back
Top