You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we initialize an object in the system class using a value from an FMI port (x.getValue()), the FMI value set from the outside is not actually used. It just uses whatever value was fed to the constructor in the beginning.
The only workaround I have so far is putting a check in the thread operation and do initialization on the first call. This is a little hacky.
The text was updated successfully, but these errors were encountered:
ldcouto
changed the title
Initialization using FMI input vars doesn't wornot properly respected
Initialization using FMI input vars doesn't work properly
Jun 7, 2017
There is not easy way to fix this in the tool I'm afraid. The inputs are set from a main context which is only available after the system is created. However, parameters should be set to the appropriate values before the system is created. How important is this feature? Usually the system in VDM is constructed using a static structure using values and not changing inputs. The system cannot change during simulation so it in that case only reflects the initial input anyway.
That's a pity. This is a big deviation from the standard.
Our use case for this is pretty standard. We have objects instantiated and deployed in the System class. True, the System class does not change but the variables inside its objects change all the time. These objects use input ports to represent sensor readings so the initial sensor reading is off and is only corrected after taking the first step. In some cases, this can really affect some of the evaluations we want to do.
Anyway, if this too hard to fix, we will live with it. But would be good to try to address in the long run.
If we initialize an object in the system class using a value from an FMI port (
x.getValue()
), the FMI value set from the outside is not actually used. It just uses whatever value was fed to the constructor in the beginning.The only workaround I have so far is putting a check in the thread operation and do initialization on the first call. This is a little hacky.
The text was updated successfully, but these errors were encountered: