Bug: Unable to set PI initial condition data type by value

Hello,

Almost all parameters in PID Controller block can inherit its data type after the value entered in the Block Parameters section.

Except for initial conditions which prompts an error upon inserting literal 'single(0)', by an already defined in global workspace variable or parameter:

"Invalid setting in 'PIDtest/PID Controller/Integrator/Continuous/Integrator' for parameter InitialCondition"

It allows for setting it to undefined variable (just highlights for missing variable). Then I can define it to e.x. testVar = single(0), or even Simulink.Parameter. But that does not set the Initial Condition data type.

I attach the model with test case with turned warning for "UnderSpecifiedDataTypeMsg". That will produce a warning:

The data types for some signals in this model are under-specified. Simulink is using a heuristic to select these data types. The heuristic leads to reasonable choices in most cases. Usage of the heuristic can be avoided by setting signal data types using Signal Specification blocks or signal objects. The list of signals with under-specified data types are:

Caused by:

• Signal with under-specified data types: 'Output Port 1' of 'PIDtest/PID Controller'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Anti-windup'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Saturation'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Saturation/External'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/Saturation/External/Saturation Dynamic'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Ideal P Gain'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/preSat Signal/Forward_Path'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/preSat Signal'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/postSat Signal/Forward_Path'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/postSat Signal'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Anti-windup/Back Calculation'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Tsamp - Integral/Passthrough'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Tsamp - Integral'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Integrator/Discrete'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Integrator'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/Sum/Sum_PI'.
• Signal with under-specified data types: 'Input Port 2' of 'PIDtest/PID Controller/Sum'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Ideal P Gain/Passthrough'.
• Signal with under-specified data types: 'Input Port 3' of 'PIDtest/PID Controller/Saturation/External/Saturation Dynamic/Switch'.
• Signal with under-specified data types: 'Input Port 1' of 'PIDtest/PID Controller/Saturation/External/Saturation Dynamic/LowerRelop1'.

One of the solutions to avoid this warning is setting in "Data Types" tab one of those:

• Sum output: Inherit: Same as first input or single
• Integrator output: single
• SumI2 output: single
• SumI4 output: single

Which is not the best solution because it should be inherited

Answer 1

[stozaki]

Hi,

This warning is normal behavior. Not a bug.

This is because the configuration parameter "UnderSpecifiedDataTypeMsg" is set to warning.

If it is not explicitly set in the data type setting, it is a configuration parameter to output a warning when updating the model, so if you do not want to output a diagnostic warning, could you set the value of "UnderSpecifiedDataTypeMsg" to none.

set_param('PIDtest','UnderSpecifiedDataTypeMsg','none');

[Piotr Kluczek]

This is a warning for a reason - there is a heuristic to be involved to solve the underspeification.

Although "The heuristic leads to reasonable choices in most cases", I think there is a chance to be wrong compared to successful normal data type propagation. Then I would like to specify the types that gives no ambiguity.

It is strange even apart from that warning - why there is such problem to put the Initial Value as Internal parameter with correct datatype? It even works with External Initial Condition (and warning is not triggered). I find it quite inconsistent.

[stozaki]

This warning is not caused by a parameter.

The warning is occurring depending on the output data type setting of the block. If you have set inherit, you will get a warning. If you set it to an explicit data type (for example, double), no warning will be output.

This configuration parameter is a setting to output a warning or error when the data type setting is not explicit (inherit or auto).

Please refer to the attached model.

[Piotr Kluczek]

I understand that explicit data type specification is a 100% solution. As I mentioned in the beginning, setting some of the data types can help all others to inherit well and solve the warning.

Playing around those settings leads to the integrator as a source of problem. I suppose that its data type is ambiguous due to different data type of input and initial condition which data type seems unknown. What other cause could explain that setting external initial condition with any data type solves the warning? I think that if we could set the initial condition data type explicitly (preferably by value), then inheriting would just work.

This warning just made me search on it, but the real bug, I think, is the following:

Why we cannot set the initial condition to something that does evaluate to other numeric types, only to double? I see it is just used in the integrator IC (did not search all posibilities). A standalone integrator can use any numeric data type for IC and all is correct. In the end I think that real bug lies in impossibility to set IC to types other than double.