Closed AntoineGautier closed 6 months ago
@JayHuLBL
Buildings.Controls.OBC
. u
is true and the input clr
switches to false then the output remains false. One have to wait for u
to transition back from false to true to trigger a true output. This seems counter intuitive that the block can yield a state where u
is true and clr
is false, which is currently the case.
Imagine that a stage up command u
is true but inhibited by a certain condition clr
. When this inhibiting condition becomes false then no transition will occur, despite the stage up command still being true. The only way a sequence can trigger the stage transition is to sample u
until the stage transition occurs.
Making such a change is simply done by adding not clr
to the array of the elsewhen
clause here above.
Instead of the following output:
the new Latch block would produce:
But no other impact is observed on any validation model within Buildings.Controls.OBC
.Let me know what you think of point 2.
For the point 2, I would suggest keeping as it is.
There would be some cases when the clear input changes from true
to false
earlier than the changes for the u
input, and we still need to maintain false
output. For instance, what if the clear input is a rising edge (for just clear the output), we want to keep the false
output.
For the case you mentioned that when the clear input changes from true
to false
and the input u
is still true
, and we want the output change from false
to true
, I think we can implement as below (for the instance swiInpCle1
):
,
and see the results difference:
@JayHuLBL Thanks for the valuable insight. This is a good point: adding not clr
to the array of the elsewhen
clause here above does not match the intent of the Latch block when a Dirac pulse is used for the clr
signal.
This is to refactor
Controls.OBC.CDL.Logical.Latch
based on the comment originally posted by @AntoineGautier in https://github.com/lbl-srg/modelica-buildings/issues/3787#issuecomment-2044447526. The implementation can even be further simplified to:(For some reason, merging the two branches of the when clause into one clause
when {initial(), clr, u} then y=not clr and u; end when;}
generates different results forControls.OBC.ASHRAE.G36.AHUs.SingleZone.VAV.SetPoints.Validation.FreezeProtection
although I cannot see exactly why.)