startTime of (SignalPWM) -> ZeroOrderHold

[dietmarw]

When using the startTime parameter of the Modelica.Electrical.PowerConverters.DCDC.Control.SignalPWM block I would expect the output "fire" to stay "false" until the block activates after startTime has passed. However, it starts "true" which causes issues when one wants to use the component to model two interlock switches with a time delay where they definitely should not be active simultaneously. Of course, one could also add an additional logic outside but I think the sane default should be that the output until startTime has passed should be "false".

Here is the behaviour:

[AHaumer]

Digging deeper into this issue, the problem has its origin in Modelica.Blocks.Discrete.ZeroOrderHold. The first trigger instance occurs at initial(): when {sampleTrigger, initial()} then instead at time>=startTime: when {sampleTrigger, time>=startTime} then Provided no one opposes, I'll provide a PR and prove that this cures the bug @dietmarw reported. @MartinOtter @christiankral @dietmarw @beutlich @HansOlsson any objections? I expect the same issue in Modelica.Blocks.Discrete.Sampler (where ySample.start is not defined).

[HansOlsson]

Digging deeper into this issue, the problem has its origin in Modelica.Blocks.Discrete.ZeroOrderHold. The first trigger instance occurs at initial(): when {sampleTrigger, initial()} then instead at time>=startTime: when {sampleTrigger, time>=startTime} then

I agree it makes sense that it triggers at time>=startTime, but it seems normal that startTime=0, and in that case the initial logic for when makes it more complicated (only when-clauses explicitly enabled with initial() are run initially).

Thus I believe it should be:

when {sampleTrigger,initial()} then
  if time>=startTime then 

Due to the definition of sampleTrigger I think that when {sampleTrigger, time>=startTime} then would be redundant.

[dietmarw]

I tested the change as suggested by @HansOlsson in ZeroOrderHold:

when {sampleTrigger, initial()} then
    if time>=startTime then
      ySample = u;
    else
      ySample = pre(ySample);
    end if;
  end when;

And now it works as expected. I agree with @AHaumer that the start time should probably also be recognised in Sampler since it seems strange to be able to specify startTime which then is simply ignored or has no function.

[AHaumer]

Isn't the functionality of Sampler and ZeroOrderHold the same (despite the fact we have improved ZeroOrderHold)? Shouldn't Sampler extend from ZeroOrderHold to increase maintenability (not taking the Icon into acoount)?

[HansOlsson]

Isn't the functionality of Sampler and ZeroOrderHold the same (despite the fact we have improved ZeroOrderHold)?

There are two differences:

• ZeroOrderHold adds an infinitesimal delay, so it will be messy to merge them.
• Conceptual difference: Sampler is intended to sample a continuous signals, whereas ZeroOrderHold holds the signal (and indicates that it is sort of intended for discrete signals).

[dietmarw]

So better to also apply the same change to Sampler as part of #4037 ?

[AHaumer]

There are two differences: * ZeroOrderHold adds an infinitesimal delay, so it will be messy to merge them.

Right.

* Conceptual difference: Sampler is intended to sample a continuous signals, whereas ZeroOrderHold holds the signal (and indicates that it is sort of intended for discrete signals).

That's the point I don't understand: Both blocks sample the input u at the trigger time instances, so the outputs are both discrete with respect to time.

Regarding @dietmarw 's remark: Yes I agree it's better to apply the same change to Sampler.

[TManikantan]

@dietmarw HI!!! I have recently assumed the role of MAP-lib Project Deputy, I have read through the discussion threads guess that you have the fix for the ticket. Would you commit the fix, We can process the ticket further for review and merge it?

[dietmarw]

@TManikantan As you can see from the ticket, the fix is already provided in #4045 which is still waiting for agreement from this ticket which in turn is waiting on the input from the library officer @AHaumer which this ticket is also assigned to.

[TManikantan]

@TManikantan As you can see from the ticket, the fix is already provided in #4045 which is still waiting for agreement from this ticket which in turn is waiting on the input from the library officer @AHaumer which this ticket is also assigned to.

@dietmarw Thankyou and Excuse me for my negligence ,i missed it.