Cycling behavior during switching due to probing

Question

Hello,

I have already solved a "Cyclic behavior during switching, Switches that bounced" error by detecting that a probe component was the cause, but I would want to understand right why it happened. The probe measured a temperature which was a direct feedthrough input to a C-Script block: this block acted on a IGBT whose activation affected the temperature. The solution for me was to add a simulation step delay ("Memory") between probe component and C-Script block.

My question is: is the following diagnosis right?

An algebraic loop appeared because acting on the IGBT immediately affects the temperature to be measured; but in that same step, modifications on the temperature could potentially affect C-Script outputs and so vary the actuation on the IGBT, so the solver "does not know what to decide".

Thanks in advance.

Comments

Also, the temperature could not (yet) affect actually the C-Script output by how was the code built.

---

Pablo, without a model it is difficult to say exactly what is going and what the internal dependencies are.  You can always email support@plexim.com with your model if you are not able to post it publicly.

---

Hello Bryan, I've uploaded a model reproducing the issue. Setting input to non-direct feedthrough gives out error for accessing it in the output function (is it bad practice not to use update function?).

---

Pablo, the model you shared sounds like it shows a different phenomena than what you were describing in your initial post, as when I follow your instructions I receive "Attempt to access a non-direct-feedtrough input signal" instead of an algebraic loop warning.

From the C-Script component help: "An input signal has direct feedthrough if you need to access the current input signal value during the output function call. This has an influence on the block sorting order and the occurrence of algebraic loops (see Block Sorting)."

If you use an input signal in an output function, then it would be by definition be a directfeedthrough signal, which generates this error.

---

Hello Bryan,

I'm attaching a screenshot to this comment: setting the input as direct feedthrough triggers that error. I have also updated the model here with input marked as direct feedthrough.

Answer 1

Thanks for the additional information Pablo. I can recreate your observations.

Firstly, the variable B is essentially a discrete state and really should only be assigned in the update function.  From the PLECS Manual:

> In general, output signals should be continuous and smooth during minor time steps; discontinuities or sharp bends should only occur during major time steps. Whether or not the call is made for a major time step can be inquired with the IsMajorStep macro. For details see "Modeling Discontinuities" below.

> Note  It is not safe to make any assumptions about the progression of time between calls to the output function. The output function may be called multiple times during the same major time step, and the time may jump back and forth between function calls during minor time steps. Code that should execute exactly once per major time step should be placed in the update function.

So in your case if the output function is called multiple times during the same major time step, then B will toggle within the same model step, toggling the gate and leading to the cyclical switching error.  Changing the direct feedthrough setting (or adding a delay) changes the block ordering, and therefore the solver behavior such that the output function call was only done once.

Attached is an example where we can print to the console each time the output function runs and we can see it's running twice with the direct feedthrough enabled.

A few other observation from my side, again pointing to this being related to the solver behavior:

• I did not observe this error when using PLECS 4.7.  I noted your model was in PLECS 4.6 and saw the error message when I down-graded.
• You are using a fixed-step solver.  Switching to a variable-step solver eliminates the error message (but not the underlying issue) in PLECS 4.6.

Comments

Splendid, thank you very much Bryan.