Modified by dietmarw on 19 Mar 2012 10:07 UTC
Section 3.2 Definition of a Type (fmiType) of "FMI for Model Exchange" says that EnumerationType has integer-valued attributes min and max, and a list of zero or more Items.
Comment in the corresponding UML diagram:
"First item has value=1, Second value has value=2, etc."
I guess this comment implies that the min attribute has value 1 (at least if there is at least 1 Item), and max is the number of Items. If so, the constraints for min max of an EnumerationType should be made explicit in the spec.
However, I propose to generalize the current rep in a backward compatible way to also support non Modelica enums, e.g. those that start from 0, or contain gaps and duplicate values.
Background: a customer used the FMI to also represent
control software compiled from C code. His example used an enum
that started from -2 (meaning 2nd reverse gear in this case)
and contained gaps.
The proposal is to fully support C enums.
- Item defines an optional integer-valued attribute "value"
- By default, enum vlaues start with 1, unless the first Item defines a different start
- A value attribute in Item resets the value counter to the given value
- min and max are constrained to be the extremal values of the enum defined this way
This would e.g. allow the encoding of the following C enum
enum e_tag{
a, b, c, d=20, e, f, g=20, h
}var;
The names declared inside the enumeration are constants with int type. Their values are these:
a == 0
b == 1
c == 2
d == 20
e == 21
f == 22
g == 20
h == 21
This enum is of course ugly. But if we do not support such enums, it will be difficult to create automated conversion procedures from C to FMU. A tool could issue a warning here, but it should not silenty
use a different value encoding (error prone) or force the user to stick to Modelica enum rules in their C code (difficult if he uses a code generator).
Reported by jakob on 25 Dec 2010 13:33 UTC
Section 3.2 Definition of a Type (fmiType) of "FMI for Model Exchange" says that EnumerationType has integer-valued attributes min and max, and a list of zero or more Items.
Comment in the corresponding UML diagram:
"First item has value=1, Second value has value=2, etc."
I guess this comment implies that the min attribute has value 1 (at least if there is at least 1 Item), and max is the number of Items. If so, the constraints for min max of an EnumerationType should be made explicit in the spec.
However, I propose to generalize the current rep in a backward compatible way to also support non Modelica enums, e.g. those that start from 0, or contain gaps and duplicate values.
Background: a customer used the FMI to also represent
control software compiled from C code. His example used an enum
that started from -2 (meaning 2nd reverse gear in this case)
and contained gaps.
The proposal is to fully support C enums.
- Item defines an optional integer-valued attribute "value"
- By default, enum vlaues start with 1, unless the first Item defines a different start
- A value attribute in Item resets the value counter to the given value
- min and max are constrained to be the extremal values of the enum defined this way
This would e.g. allow the encoding of the following C enum
enum e_tag{
a, b, c, d=20, e, f, g=20, h
}var;
The names declared inside the enumeration are constants with int type. Their values are these:
a == 0
b == 1
c == 2
d == 20
e == 21
f == 22
g == 20
h == 21
This enum is of course ugly. But if we do not support such enums, it will be difficult to create automated conversion procedures from C to FMU. A tool could issue a warning here, but it should not silenty
use a different value encoding (error prone) or force the user to stick to Modelica enum rules in their C code (difficult if he uses a code generator).
Migrated-From: https://trac.fmi-standard.org/ticket/42
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent