Simulink: Is there any setting that allows for partial library linking?

I am building a library of generic blocks and I am having some trouble getting the library to function in the way I want to. I have the "Allow library block to modify its contents" option box checked, but when I try to run a linked block with a callback that changes the tag name for some goto's, the model siezes up and fails to run. If I disable the link, the callback changes the tag to the proper value and everything runs fine. I've tried moving the callback to various places, a subsystem mask, block properties on the top level linked subsystem, in the initialization parameters of the mask, but nothing works.

Unfortunately, the goto needs to be underneath the subsystem mask, so I can't move it to a higher level, but I want to maintain a library link to the technical content of the blocks. Is there anyway to create what I will call a "scoped" or "partial" library link for lack of a better term? Ideally there would be a feature that allows the user to opt-out of linking for selected child blocks when the parent subsystem retains an active link but I don't think that exists or is planned.

Thanks,

Stephen

[Vivek]

Hi Stephen, I think I have implemened almost exactly what you have described. I too have created some custom libraries and one of the blocks is a custom GoTo block that automatically picks up the signal name, and adds a prefix/postfix if needed and assigns it to itself (tag). The way I did this is to check the "Allow library to modify contents" and used a masked subsystem over the normal simulink GoTo block. I didn't have any trouble not running it. I could even build it for embedded targets. The only issue I had was that Simulink kept throwing a warning saying that it was a library link and that I am overriding values within a library. It also says I can change the warning settings but that doesn't work. Anyway, let me know if you need any more clarifications on how I did this.

Cheers,

Answer 1

[Kaustubha Govind]

I'm not 100% sure, but I don't think such functionality currently exists. It seems like such a feature might cause a nightmare for maintaining libraries. You could confirm with Tech Support if your license is on maintenance.

However, it seems like what you are asking for may not be an encouraged modeling practice. Is there a reason that you need to change the Goto tag? Is it because the signal from the Goto is read in a From block outside of the subsystem? Why not simply output that signal from the subsystem instead, and connect a Goto block outside of the library block if need be.

If you are using someone else's library, can you confirm what the "Tag visibility" of the Goto block in the library subsystem is? If it is set to 'scoped', you might be able to wrap the subsystem with a nonvirtual subsystem in your model. Do not change the tag of the Goto, but use the same tag as the library uses in a 'From' block (also having visibility set to 'scoped') inside that nonvirtual subsystem. That way, your tag won't clash with others in the model.

[Stephen]

The Goto's are simply used for ease of connectivity. When I pull a subsystem from this custom library, and connect it to another block from the same library, a routine runs that goes and matches the tags of these goto's so that each bus link acts like a two way connection.

While rebuilding the blocks with non-virtual subsystem wrappers would work, this defeats the purpose of the library, which is to have a group of library blocks that is simple to connect, as the user would then need to pull a technical block and a interface block out and connect them. Also, I want to be able to have larger scale systems comprised of these blocks in my library, so adding a wrapper is a work around that works in the small picture, but not in a larger context.

The GoTo's in question are all set to global.

[Kaustubha Govind]

Stephen: In my opinion, making connections between library blocks using Goto and From tags is not good modeling practice. It makes the signal flow opaque to someone looking at the model and can make debugging difficult. Also, in general, Goto-From connections cannot cross non-virtual subsystem boundaries, so it limits the use of your blocks to root-level or virtual subsystems unless the blocks are inside the same subsystem. If you still think that using From-Goto tags in this way is essential for your application, please submit an enhancement request to MathWorks Tech Support with your use case so that the development team that owns Simulink library support can consider this for a future release.

[Stephen]

I assure you that your concerns about signal flow are unwarranted in the framework we have devised. We developed this because without it the model chart for models of even moderate complexity have opaque signal flow given the current capabilities of simulink. This process enhances debugging and signal flow as opposed to hindering it.

I agree that this adds complications with regard to non-virtual subsystem boundaries, though we've devised ways to workaround that when desired.

Long ago we requested the ability to make it possible to have signals be two way signals, or for the ability to have inports on all 4 sides and outports on all 4 sides of a given subsystem. If Mathworks were to implement either of these features in basic simulink then we wouldn't need the GoTo's. If Mathworks isn't going to enhance the basic features of block connectivity, then what good would submitting an enhancement request for the workaround do?

[Kaustubha Govind]

Stephen: I am very sorry that the current capabilities of Simulink do not satisfy your requirements. I'm not sure what the reasons for not having the ports on any side feature are, but regarding two-way signals - it looks like you might be operating in a domain that doesn't fit the "signal flow" paradigm in Simulink very well. For example, the SimScape domain has a different principle of "signal direction". See http://www.mathworks.com/help/toolbox/physmod/simscape/ug/bq89sba-1.html#bq89sba-5

Nonethless, I will still urge you to send an email to Tech Support and put in an enhancement request, so that the development team is aware of your need, and also so you may be notified if such a feature is ever introduced.

Answer 2

[Vivek]

Hi Stephen, I think I have implemened almost exactly what you have described. I too have created some custom libraries and one of the blocks is a custom GoTo block that automatically picks up the signal name, and adds a prefix/postfix if needed and assigns it to itself (tag). The way I did this is to check the "Allow library to modify contents" and used a masked subsystem over the normal simulink GoTo block. I didn't have any trouble not running it. I could even build it for embedded targets. The only issue I had was that Simulink kept throwing a warning saying that it was a library link and that I am overriding values within a library. It also says I can change the warning settings but that doesn't work. Anyway, let me know if you need any more clarifications on how I did this.

Cheers,