-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a unique identifier to Block objects #16
Comments
With "unique" you mean: unique to each instance of the block in a given simulation? Or in the given model/diagram? Who should assign this names, the engine? Some possible targets (such as Drake) already have a concept of unique instance name, but it is already managed at the level of the engine (see https://drake.mit.edu/doxygen_cxx/classdrake_1_1systems_1_1_system_base.html#ad5260b9627048b854b45d05ed34adc22). If this name is completed managed by the engine, perhaps it make sense to just have a |
Talking about Simulink, I was thinking that the S-Function read the name of the block from the model and assigns it to the block object. In order to be unique for each block, it should be the absolute name from the root of the model (if you imagine having subsystems and seeing it as a graph). Another option in order to minimize (but not remove) name collisions, is to use
Another option I like is having in std::string getName(core::BlockInformation*) const; And putting the logic of gathering the name inside the |
How? |
Back in time, we used the block priority as a unique identifier from which we could define block execution order |
Probably coming from the Simulink inheritage and its Simstruct, we never had the need to assign to a block a unique id or name. However, especially with the new plugin architecture, it might be worth adding the following to
blockfactory::core::Block
Since these are not virtual methods, the downstream classes that implement the interface would not need to be modified.
For what concern the S-Function, we should store it as additional RTW parameter and modify the TLC file to get this information. If we ever want in the future to create a system to override mask parameters, being able to access the block object with a unique id will be fundamental.
It is not clear to me if we should also add a
getName
method in theBlockInformation
interface.The text was updated successfully, but these errors were encountered: