Pitfalls when using trace analysisΒΆ
Signals with different time axes
If signals with different time axes are used in an expression, the expression is evaluated at any time at which at least one signal has a value. For signals with no value at the concerning timestamp, hold values are used. However, if the signals start at different timestamps, there is not yet a hold value for each signal. For this reason, expressions are only evaluated beginning at the first timestamp of the signal starting at the latest.
Furthermore, the use of functions can influence the time of the first evaluation. If, for example, a function can only be evaluated from the second signal value onwards, the expression can be evaluated for the first time at the second value of the relevant signal. On the other hand, the HasValue function can be evaluated even if the signal has no values (yet).
Integer Overflow
Depending on the data type of a signal, an integer overflow may occur.
In particular with small or unsigned data types (e.g. uint8), this situation can occur quickly.
For example, the expression Signal - 1 in a calculation trace step leads to an overflow
if the signal of type uint8 has a value of 0. Then, the result is not -1 but 255.
An overflow also occurs when 1 is added to a signal of type uint8 if the signal has the value 255.
Then, the result is not 256, but 0.
Overflows can be avoided by converting an operand into a type that can represent the actual result;
in the example: float(Signal) - 1 or Signal - 1.0.
Start of trace and end of trace
Start of trace and end of trace are determined by all signals used in an episode. Thus, the length of a trigger range that stops at the end of the trace also depends on the signals used in the episode.
If a function that is dependent on start of trace or end of trace is used in a trace step, the trace step will be influenced by other trace steps of the episode. For example, the Value function is only evaluated for timestamps for which the time calculated with deltaT is before end of trace.
Logical operators in expressions of calculations and trigger blocks
Even if the expressions have to be specified in Python syntax, the evaluation is done by a separate
interpreter, which exhibits a different behaviour when evaluating logical operators:
Both sides of the expression are always evaluated. With the expression
Signal != 0 and 1 / Signal < 3, for instance, this means that even if the partial expression
Signal != 0 detects a value of zero, 1 / signal < 3 is still evaluated and yields a
ZeroDivisionError.