Sorry, I know where wrong. Now it can repeat the timer. But the increase 1 degree not hit. ton.Q not change to true when reach 20 second.
ton.Q does change to 1 when the timer expires at 20s, but you are unlikely to see it because ton.Q will only be 1 for a single scan, which is by design to ensure the setpoint increase by only 1, not by 1 on each of several scanse. A single scan typically lasts a few milliseconds or less, so any monitoring program is unlikely to show the change. Even so, one way you know that ton.Q became 1 is that the timer restarts: the current ton timer
Elapsed Time (ton.ET) will return to a value near zero and start increasing again. Another way you know is that the setpoint will increase by 1; that can only happen if and when ton.Q becomes 1.
And may I know if the actual oven temperature not able increase 3 degree in 1 minute but the SET_POINT keep increase 1, then will it be SET_POINT reach 280 degree but the actual temperature still not reach
If the burner is not able to increase the current oven temperature by 1deg every 20s (= 3deg/min), then that does not affect the setpoint algorithm, and the code's behavior is still consistent with the specification provided in Post #1:
...
increase the burner to 280 degree celcius and every minute only can increase 3 degree Celsius ...
Changing the setpoint cannot change the thermal capacity of the physical burner, it will only prevent the burner from raising the temperature more than 3deg/min*.
If the burner does not have the capacity to drive the furnace at 3deg/min, then the setpoint algorithm is not needed, or perhaps it is needed only at lower oven temperatures, i.e. when heat losses are less.
* This is not strictly true: for example, say the oven temperature fell behind the setpoint because the feed gas pressure dropped temporarily or was lost entirely. When the feed gas pressure recovers, the the setpoint will have advanced several degrees, and the burner will heat the oven as quickly as possible, which could be at a rate of more than 3deg/min at the higher feed gas pressure. In the case where the feed gas was lost entirely, the setpoint algorithm would merrily advance to 280deg. Then, when the gas recovers, and the burner would again proceed to heat the oven at an uncontrolled rate. So I ask you to tell me: look at @parky's program and at my prorgram; how can we stop the setpoint from increasing if the actual temperature fell too far behind the setpoint progression?
P.S. @parky's algorithm uses the variable SET_point instead of hard-coding 280. That is a good idea, as the limit of the setpoint algorithm is actually independent of the algorithm, so it would be a good idea to make that limit a user-specified value. Perhaps someday the temperature sensor will develop an offset error, so it reads 280deg when the actual temperature is 275deg, or a new type of glass requires a different temperature. Having the target as a variable that the operator can set without changing the program will be more convenient than editing the hard-coded setpoint lime.
P.P.S. Note that @parky's algorithm has the same three sections. Each may be implemented differently, but the basic steps are the same. For example @parky's resets the VAR_Set_Point when, after it is increased, it exceeds the SET_Point value (280deg). It is useful to look at such differences and think about how they will affect the process; you understand your process the best, so you should look at all options or even come up with some of your own. For example, I see @parky codes his AND expression with more parentheses; that is probably based on experience and I will seek to follow that example in future: it is easier to use parentheses to make logic explicit than to learn the precedence rules for a programming language.