-3

I'm trying to track a reference in PLECS (power electronics simulation software) with this circuit. C-Script is where I have the code below which basically tells the IGBT devices to open (0) and close (1). However, I can't understand why I get "0" as output when it is clear that the voltage across the capacitor (VCS) is not even close to zero volts, as shows this figure.

int track(double ref, double isb, double vcs) {
    int out;

    if(ref > isb){
        out = 1;
    }
    else if(ref < isb && vcs == 0.0){
            out = 0;
        }

    return out;
}

In C-Script block, signal values may only be accessed by using macros, not by pointer arithmetic. For example, I declared Inputs and Output as follows:

#define REF Input(0) // Reference Current
#define ISB Input(1) // Snubber Output Current
#define VCS Input(2) // Capacitor Voltage
#define IGBT Output(0) // IGBT Firing
Zrakk
  • 11
  • 2
  • 6
    First of all, this will return an indeterminate value (uninitialized `out`) if `ref == isb` or `ref < isb && vcs != 0`, which might even be a trap representation -> undefined behavior. Second, you forgot to exactly describe what's your input, your expected output and your actual output, see [mcve]. –  Apr 29 '18 at 17:22
  • 1
    And if you already make UB from `out` like that, what else might you be doing wrong that we can't see in this ellipsised, context-free example? Hence: MCVE, please. Another thing: your question can be read as either (A) the wrong branch executes, so why does my test not do what I expect? or (B) both branches execute, so how on Earth am I giving the compiler sufficient leeway to do that? – underscore_d Apr 29 '18 at 17:37
  • http://idownvotedbecau.se/beingunresponsive -- oh and close-voted as well. without a [mcve], this question doesn't make any sense and should just vanish. –  Apr 29 '18 at 18:31

1 Answers1

-1

Your figure shows places where ref < isb and vcs is not zero. Neither your if nor your else if includes this condition, so program execution does not go through either of their clauses. Hence, for those cases, the code is effectively:

int out;

return out;

Thus, it returns an uninitialized value. That may have happened to have the effect of returning zero, but the behavior is unreliable.

To remedy this, either initialize out to what you want to return in these cases or add an else clause that sets it.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • 2
    To be honest, although this is a very obvious problem with the code -- without a proper MCVE, your answer looks like guessing as well :o (and I would strongly oppose getting SO in a mode where someone posts an unclear question, a lot of people are guessing and the clarity finally comes from the OP selecting an answer .. or maybe even never) –  Apr 29 '18 at 18:29
  • Here as well, no offence intended. Kudos for analyzing a PNG with some graphs, really. But still, I can't be sure this answer is correct and I **am** sure we should still require [mcve]s .. because then it's easy to follow what's going on and (potentially) more than one person will profit from the answer. –  Apr 29 '18 at 18:39
  • @FelixPalmen: There is no guessing. The graph clearly shows multiple places where REF exceeds ISB and vice-versa. (It fails to label which is red and which is green, but, since both orders occur, we know that both cases occur.) And, at all places, `VCS` is non-zero. Therefore, the data does include places where `ref < usb` and `vcs != 0`. All of the data needed to discern the error in the code was available (although it should have been included in the post, not referred to). – Eric Postpischil Apr 29 '18 at 18:57
  • 2
    IBTD. It's obvious this **is** a problem with the code, but without a MCVE, we can't be sure it's the case OP was asking about. Of course, now, having picked your answer, we are sure. But this isn't how SO should work. Well, nevermind ... this is probably too much of a *meta* discussion :) –  Apr 29 '18 at 19:03
  • @FelixPalmen: You are asking for an unreasonable standard. The question presented the code and the data and stated what unexpected result was obtained, and there is only one explanation for it (unless you want to hypothesize external influences such as a signal handler run amok, but allowing that without evidence would break a lot of questions on Stack Overflow). Most questions on Stack Overflow are not going to become shining references for future seekers, so it is best just to provide a solution and get them over with. – Eric Postpischil Apr 29 '18 at 19:08
  • 2
    "*and there is only one explanation for it*" <- your explanation involves an uninitialized local to hold a representation of `0`. IMHO, this is already a *lot* of guessing. Most implementations use the stack in a way that `0` is just as unlikely as any other value for an uninitialized variable. –  Apr 29 '18 at 19:12
  • @FelixPalmen: The code is defined for the cases where `ref > isb` or `ref < isb && vcs == 0.0`. Therefore, the only code path that can produce the unexpected behavior is where `ref < isb && vcs != 0.0`. That is simple logic. Your complaint that another value **could have been produced** is irrelevant. Given `vcs != 0`, there is only one code path that **could** have produced zero, and therefore it is the code path that **did** produce that result. The fact that the same code path might have produced a different result is irrelevant to that deduction. – Eric Postpischil Apr 29 '18 at 19:53
  • 1
    @FelixPalmen: Incidentally, my explanation does not require an uninitialized object to hold zero. Per the C standard, the behavior is completely undefined. It does not need to follow the model of there being some object with some definite but unknown value. The C standard allows **any** behavior to occur. The zero might have been in an uninitialized variable, or the compiler might have simply optimized the code by changing the entire routine to `return ref > isb ? 1 : 0;` (equivalently, `return ref > isb`). – Eric Postpischil Apr 29 '18 at 19:56