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

7 vues (au cours des 30 derniers jours)
Piotr Kluczek
Piotr Kluczek le 29 Sep 2021
Commenté : Piotr Kluczek le 30 Sep 2021
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:
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

Réponses (1)

stozaki
stozaki le 29 Sep 2021
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');
  3 commentaires
stozaki
stozaki le 30 Sep 2021
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
Piotr Kluczek le 30 Sep 2021
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.

Connectez-vous pour commenter.

Catégories

En savoir plus sur Simulink dans Help Center et File Exchange

Produits


Version

R2020b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by