The Problem Of Multiple Gotos?

Hi all

I have a conceptual difficulty. I have a library of components for heat transfer analysis. The output values from these components (for example, the Pressures in components) are sent to a centralized "Output Data" block. This allows the user to handle all of his outputs from all of his components from one centralized location.

The trouble with this is that it precludes the possibility of having multiple instances of these components within a simulink model because then I get the error: Multiple Gotos found with tag named 'x_pipe'

I do not want to manually rename the tags every time because: a) there are a lot of them, and b) this completely kills flexibility and scalability of my library.

Has anyone faced this trouble before? How did you solve it? Thanks in advance!

[Muhammad Amin]

I am also facing same issue need help.

[Walter Roberson]

Do not set the TagVisibility to 'global'

https://www.mathworks.com/help/simulink/slref/goto.html

[Fangjun Jiang]

This is not about the tag visibility of the "Goto" block.

[Walter Roberson]

If "library" means "subsystem" then having two copies of the same subsystem is a potential problem for conflicts of the GoTo tags, that Simulink could potentially be confused between the same apparent tag in the two copies .

However if tag visibility is not set to global then the tag scope will not extend to the other copy of the subsystem and there should not be a problem.

If, though, "library" is not implying subsystem, then Yes, there would be a problem.

[Fangjun Jiang]

In this case, the library component must be a sbusystem block which contains the Goto block and other blocks.

Even if the tag visibility is not "global" (e.g, could be "scoped"), as long as the Goto blocks with the same tag name intend to be connected to the same centralized location, then there would be a problem (multiple sourcing "Goto" blocks for a single "From" block).

Answer 1

[Fangjun Jiang]

This is a bad practice or even incorrectr practice to put a "Goto" block inside a library component, which you know will be used in multiple instances.

The reason is clear. That is the error message you encounted. You have to remove the "Goto" block from your library component.

If the "centralized Output Data block" is for signal logging or observation, consider other ways of sigal logging, such as Simulink Data Inspector.

web(fullfile(docroot, 'simulink/slref/simulationdatainspector.html'))

If the "centralized Output Data block" is used by modeling elements, then you have no choice but to route those signals to the centralized place. If Goto/From blocks are still needed to avoid many layers of routing, then you have to put the "Goto" blocks outside of the library components and name each tag differently.

[Fangjun Jiang]

A possibility is to add a mask to the block in the library, to promote the parameter to the mask dialog. When the library block is dropped to the model every time, you can immediately specify a different parameter name to avoid duplication. This will cause a so called "parameterized link", which is fine.

However, this might not work as in this case, the parameter is the string name of the "Goto" tag.

Learn how to apply "parameterized link" on value first below and try to see if it could apply to "Goto" tag name. My gut feeling is "No".

web(fullfile(docroot, 'simulink/ug/parameterized-links-and-self-modifiable-linked-subsystems.html?s_tid=doc_srchtitle'))

[Muhammad Amin]

thanks for your time and concern. I have changed the name to rectify this issue. it worked thanks. Now, I am working on fuzzy logic portio to mitigate error (change in error). getting value trigonometery membership funtion but getting -ve value as output (I) but current -ve means of discharging but values dosenot matched.

[Fangjun Jiang]

??

@Muhammad Amin, I deleted your answer as it is completely unrelated to the Original Poster's question.