Use Ramp/Soak Sequence in Alarms

[beanoccio]

I would like to integrate a ramp/soak sequence into an alarm list.
After the TP, a temperature increase should occur after a certain time.
What information does the alarm list need?

1 minute after the TP
If BT = 100°C
Ramp/soak: 100°C to 200°C in 8 minutes

What information does the alarm list need to activate or deactivate the desired ramp/soak list?

Example:

[MAKOMO]

There are a number of things wrong in your configuration that needs to be fixed to get this going and you need to update to the just being build Continuous Build which implements an important change in processing RampSoak patterns.

Let's start from the back of things. Your RampSoak pattern looks fine, but it needs to be defined in the Ramp/Soak tab. The tabs RH1, RH2 and RH3 define patterns for quickly loading/switching, however, Artisan will only process the pattern defined in the second tab.

Now let's take a look at the alarms. You want an alarm to ring a minute after TP. However, your definition states that alarm 1 should ring after TP at minute 1:00. Note that time is taken absolute here. So your alarm triggers a minute after CHARGE or if BT is exactly 100C. Note that the time and the temperature criteria are connected by a disjunction. Further the alarm is "guarded" by not ringing before TP is noted. This is not exactly what you intended. Further, awaiting a temperature reading of exactly 100.00C BT is very unlikely to ever evaluate to true. In most cases it is better to make use >100C.

So you need somehow a relative argument to catch the specific time after TP. For this you need to split this alarm rule into two. The first one to recognize the TP event and the second (depending on the first) to work in relative mode by using "If Alarm" as "From" criteria.

As for such "relative" alarm rules both criteria, the time and the temperature one, are interpreted relative to the point the rule they depend on was triggered, the BT temperature criteria >100C will be interpreted as "if BT increased by at least 100C over the temperature at when the rule 1 was triggered". Note that I did not write "..over the temperature at TP", as the TP is set (like CHARGE and DROP) in retrospect some readings after it actual occurred. Thus the time the first rule triggers will be somewhat after TP and relative rules interpret their (relative) time and temperature w.r.t. the point the referred rule was triggered. Thus we need a separate non-relative 3rd rule to formulate that temperature criteria. Sounds all a little complex, but it is possible to get used to this and enjoy the power of this rule interpretation system;). The following will work.

Let's recap those rules. Rule 1 triggers the moment TP was set (which is a bit after the TP actually happened). Note that the time criteria is set to 00:01, the minimal period of 1 sec, as a time criteria of 00:00 is never fulfilled by definition. The temperature criteria is active here (as one of the data curves was selected, here BT). The criteria is defined such that it should be always enabled after TP as we want this alarm to trigger as quick as possible after TP. No action require for this rule.

Rule 2 depends on rule 1 in that it is linked by "If Alarm" to rule 1. This blocks the execution of this rule as long as rule 1 did not fire. As "From" criteria we have chosen "If Alarm" to make its time and temperature criteria to be interpreted relative to the point rule 1 triggered, as discussed before. That time criteria we set to our intended 1min period and the temperature criteria is disabled by choosing the empty entry. No action require for this rule.

Rule 3 depends on rule 2 and thus will not fire before rule 2 fired. Here we disabled the time criteria by setting its time to 00:00 and activated the temperature criteria by selecting BT and setting our >100C argument. This rule has an action to start the PID with the RampSoak pattern.

Previous versions of Artisan (those before the continuous build I linked above) used the roast time (time after CHARGE) to interpret the Ramp Soak patterns. This is not what you intended as you wanted the 8min of the one ramp to start exactly on starting the PID with that RampSoak pattern. That new build is now interpreting time w.r.t. the moment the PID was turned on. Further, previous versions of Artisan did initialize the SP to 0 at the begin of the Ramp Soak pattern. Thus in our case the temperature ramp would be from 0-200C. However, your intension is to have the ramp running from 100-200C if I understand correctly. That could have been achieved by adding a short Soak pattern before your Ramp pattern to initalize the start of the ramp to 100C. However, the new Artisan build now uses the PID input temperatures at PID ON to start the RampSoak pattern processing.

To test if the above specification is doing what we intended I did run the Simulator on a previous recorded profile (1sec sampling period), observing the processing of the alarms, the position of the SV slider (starting with SV=0) and the PID LCDs (Duty/SV).

This is the situation @0:55 just before TP gets marked:

A second later the TP got marked (at 0:52) and our first alarm triggered. Note that the alarm table marks triggered alarms in grey.

Alarm 2 triggers just a minute later as expected.

Finally, alarm 3 triggers a few seconds later as BT exceeds 100C and starts the PID with our RampSoak pattern starting at SV=100C.

A bit further down the row we see how the SV linearly increases from 100C to 200C within the next 8min following our defined Ramp. Note that the PID Duty is always 0 here as the simulated BT curve is always ahead.

I hope this a bit longer explanation helps to explain the basic concepts of the Artisan alarm system and how it can interact with the PID.

[beanoccio]

OK, thank you very much for the detailed explanation and the numerous tips for a reliable alarm process.
For me, it was very important to know: If I trigger a ramp/soak event in the alarms, then this refers to the first ramp/soak tab.

[Terracotta-6]

RampSoak on and RampSoak off can only be configured in the Action setting of the Alarm Table and cannot be set in the Event Button?

[MAKOMO]

There are the event actions of type Artisan Command to switch on and off the PID (PIDon and PIDoff) and there is the Artisan Command to set the PID mode (pidmode). Thus to have a button to start the PID in RS mode you would us the following Artisan Command action sequence

pidmode(1);PIDon

[Terracotta-6]

RampSoak on “running” and Pid on are in a logical AND relationship. In my test, only RampSoak off is used. After that, RampSoak will not run.

[MAKOMO]

I don't understand exactly what you are doing. Could you explain in more detail? What are the steps? What do you see? What do you instead expect to see?

Note that the PID can be switched ON and OFF and the PID mode can have any of 3 states. There is no logical AND relationship. You can switch the PID mode independent of the PID state (3 modes: manual, RS, background follow) and the otherway around. However, the time and start temperature of the RS mode is always interpreted to be the last point the PID was turned ON.

[MAKOMO]

Oh, of course the RS time needs to be reset by a PIDoff/PIDon if you want to run the same (or any other) pattern again during the same roast.

[MAKOMO]

I don't see the need. Sorry.