lbl-srg / modelica-buildings

Modelica Buildings library
253 stars 157 forks source link

Simplify Latch block #3796

Closed AntoineGautier closed 6 months ago

AntoineGautier commented 6 months ago

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:

  when initial() then
    y=not clr and u;
  elsewhen {clr, u} then
    y=not clr and u;
  end when;

(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 for Controls.OBC.ASHRAE.G36.AHUs.SingleZone.VAV.SetPoints.Validation.FreezeProtection although I cannot see exactly why.)

AntoineGautier commented 6 months ago

@JayHuLBL

  1. I confirm that the simplified implementation proposed above has no impact on any validation model within Buildings.Controls.OBC.
  2. I have second thoughts on the intent of the Latch block. Currently, if the input 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: Latch the new Latch block would produce: Latch But no other impact is observed on any validation model within Buildings.Controls.OBC.

Let me know what you think of point 2.

JayHuLBL commented 6 months ago

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): Latch_,

and see the results difference:

Latch_Results

AntoineGautier commented 6 months ago

@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.