You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The line below shows a range of a to-be-controlled parameter/state s, with indicated upper and lower bounds (ub, lb) and upper and lower setpoints (usp, lsp).
lb * lsp usp * ub
|---------|--------------|----------|
s ->
Quite common control use cases are of these types:
Once s < lb, s must rise up to lsp;
Once s > ub, s must fall down to usp.
Up to now, we used to view this problem as 'when the parameter s is in one of these starred (*) regions, there must be some memory that says whether s is on its way to a setpoint or not'.
However, DiscreteControl only takes action at changes of conditions. Therefore, it is useful to consider how the parameter s entered the starred regions. More specifically:
s is on its way to lsp if it did an up-crossing at lb;
s is on its way to usp if it did a down-crossing at ub.
Proposal by example
Say we have the following conditions for the situation described above:
s > lb
s > lsp
s > usp
s > ub
and also the control states 'rise' and 'fall', 'free' for making s rise, fall, and change freely respectively.
We introduce truth values in addition to T and F:
U for an up-crossing, which is a special case of T;
D for a down-crossing, which is a special case of F.
Then for the upper set point case, the control logic can be as follows (using the wildcard 'A' from #440):
AAAT -> 'fall'
AAAD -> 'fall'
AATF -> 'free'
AAFA -> 'free'
Note that the second case implies the third case. So, we say that crossing-type specific truth states take precedence.
Shortcoming
The above does not work when an extra condition on s is added within the relevant starred region.
The text was updated successfully, but these errors were encountered:
Motivation
The line below shows a range of a to-be-controlled parameter/state
s
, with indicated upper and lower bounds (ub
,lb
) and upper and lower setpoints (usp
,lsp
).Quite common control use cases are of these types:
s < lb
,s
must rise up tolsp
;s > ub
,s
must fall down tousp
.Up to now, we used to view this problem as 'when the parameter
s
is in one of these starred (*
) regions, there must be some memory that says whethers
is on its way to a setpoint or not'.However,
DiscreteControl
only takes action at changes of conditions. Therefore, it is useful to consider how the parameters
entered the starred regions. More specifically:s
is on its way tolsp
if it did an up-crossing atlb
;s
is on its way tousp
if it did a down-crossing atub
.Proposal by example
Say we have the following conditions for the situation described above:
s > lb
s > lsp
s > usp
s > ub
and also the control states 'rise' and 'fall', 'free' for making
s
rise, fall, and change freely respectively.We introduce truth values in addition to
T
andF
:U
for an up-crossing, which is a special case ofT
;D
for a down-crossing, which is a special case ofF
.Then for the upper set point case, the control logic can be as follows (using the wildcard 'A' from #440):
Note that the second case implies the third case. So, we say that crossing-type specific truth states take precedence.
Shortcoming
The above does not work when an extra condition on
s
is added within the relevant starred region.The text was updated successfully, but these errors were encountered: