<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.1" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Advanced Masking Concepts</title>
	<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/</link>
	<description>This blog is about Simulink.</description>
	<pubDate>Sun, 22 Nov 2009 23:09:44 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.1</generator>
		<item>
		<title>By: Radu</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-690</link>
		<dc:creator>Radu</dc:creator>
		<pubDate>Tue, 17 Feb 2009 18:27:00 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-690</guid>
		<description>Is it possible to create panes in a mask? For example the “Product” block from the “Commonly used Blocks” has to panes “Main” and “Signal Attributes”. I can not find documentation on this topic.
Thank you in advanced!</description>
		<content:encoded><![CDATA[<p>Is it possible to create panes in a mask? For example the “Product” block from the “Commonly used Blocks” has to panes “Main” and “Signal Attributes”. I can not find documentation on this topic.<br />
Thank you in advanced!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Seth</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-616</link>
		<dc:creator>Seth</dc:creator>
		<pubDate>Tue, 25 Nov 2008 13:39:19 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-616</guid>
		<description>@Ryan - Thanks for the clear use case!  This is very helpful in explaining your request to our development team, which is exactly what I have done with it. I can't suggest a coloring based workaround for this.  I have seen people embed information in the signal label, for example: .</description>
		<content:encoded><![CDATA[<p>@Ryan - Thanks for the clear use case!  This is very helpful in explaining your request to our development team, which is exactly what I have done with it. I can&#8217;t suggest a coloring based workaround for this.  I have seen people embed information in the signal label, for example: .</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-611</link>
		<dc:creator>Ryan</dc:creator>
		<pubDate>Wed, 19 Nov 2008 15:28:13 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-611</guid>
		<description>@Seth

I do share a similar point of view on the use of goto and from blocks.

On the signal colouring, Highlight to Source/Destination is good to analyze one signal at a time. I'm trying to think of a way to classify signals based on a similar property.

A simple example would be if I had 3 Sensors. Sensor 1 and 2 operate on 5Volts and Sensor 3 operates on 3.3 Volts .The idea is to have the signals Sensor1, Sensor2 say coloured in red and Sensor3 perhaps in green.

I was actually expecting to see a Background (Foreground...can’t really have both for a signal :) ) colour option when I right clicked on the signal. Too bad there wasn’t one !

I tried opening the model as a text file to see if there were properties I could manipulate. I could do this if I had just an unconnected signal - not really useful.
But I think the way Simulink is designed it inherits the subsystem colour the signal originates from. Wonder if there’s a work around for this</description>
		<content:encoded><![CDATA[<p>@Seth</p>
<p>I do share a similar point of view on the use of goto and from blocks.</p>
<p>On the signal colouring, Highlight to Source/Destination is good to analyze one signal at a time. I&#8217;m trying to think of a way to classify signals based on a similar property.</p>
<p>A simple example would be if I had 3 Sensors. Sensor 1 and 2 operate on 5Volts and Sensor 3 operates on 3.3 Volts .The idea is to have the signals Sensor1, Sensor2 say coloured in red and Sensor3 perhaps in green.</p>
<p>I was actually expecting to see a Background (Foreground&#8230;can’t really have both for a signal :) ) colour option when I right clicked on the signal. Too bad there wasn’t one !</p>
<p>I tried opening the model as a text file to see if there were properties I could manipulate. I could do this if I had just an unconnected signal - not really useful.<br />
But I think the way Simulink is designed it inherits the subsystem colour the signal originates from. Wonder if there’s a work around for this</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Seth</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-610</link>
		<dc:creator>Seth</dc:creator>
		<pubDate>Wed, 19 Nov 2008 14:55:59 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-610</guid>
		<description>@Ryan - thanks for adding to the discussion.  I am not one of those people who universally decry the use of GoTo and From blocks.  I think they serve a very important purpose when cleaning up the look of a diagram.  Instances where GoTo and From cause problems are usually when there is no consistency in how they are applied.  My personal preference is to see the application of modeling standards to the use of GoTo/From. For example, if all GoTo and From use will be local to a system, and never global, I think this can go a long way to cleaning up the diagram.  I also like your idea of using colors to match up the pairs of blocks, or to group them in some way.

Regarding your request to provide signal specific coloring, have you ever tried right click -&gt; Highlight to Source/Destination?  I find this very helpful when debugging the model.  In a very large model you must be patient using this feature as the time to recolor the model is proportional to the number of blocks and lines in it.  When you are done tracing, right click -&gt; Remove Highlighting.</description>
		<content:encoded><![CDATA[<p>@Ryan - thanks for adding to the discussion.  I am not one of those people who universally decry the use of GoTo and From blocks.  I think they serve a very important purpose when cleaning up the look of a diagram.  Instances where GoTo and From cause problems are usually when there is no consistency in how they are applied.  My personal preference is to see the application of modeling standards to the use of GoTo/From. For example, if all GoTo and From use will be local to a system, and never global, I think this can go a long way to cleaning up the diagram.  I also like your idea of using colors to match up the pairs of blocks, or to group them in some way.</p>
<p>Regarding your request to provide signal specific coloring, have you ever tried right click -> Highlight to Source/Destination?  I find this very helpful when debugging the model.  In a very large model you must be patient using this feature as the time to recolor the model is proportional to the number of blocks and lines in it.  When you are done tracing, right click -> Remove Highlighting.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-609</link>
		<dc:creator>Ryan</dc:creator>
		<pubDate>Wed, 19 Nov 2008 14:32:53 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-609</guid>
		<description>@Matt

Just to add in - To solve the problem of neater routing of signals, one way to do it is to use goto and from block for messey connections and use the same background colour for both the blocks.
The use of goto and from is usually not adviced. However, if the model is only for simulation, I guess it shouldnt be a problem.</description>
		<content:encoded><![CDATA[<p>@Matt</p>
<p>Just to add in - To solve the problem of neater routing of signals, one way to do it is to use goto and from block for messey connections and use the same background colour for both the blocks.<br />
The use of goto and from is usually not adviced. However, if the model is only for simulation, I guess it shouldnt be a problem.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-608</link>
		<dc:creator>Ryan</dc:creator>
		<pubDate>Wed, 19 Nov 2008 14:06:14 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-608</guid>
		<description>@Matt

Interestingly, just the other day I was wondering if it was possible to create inports or outports on the top and bottom sides of the blocks. 
I was creating data flow diagrams in Visio and then I thought...”Hey...If  I could do this in Simulink, wouldn’t it be easy to create a concept diagram into a working model??"

It would be interesting to see if your solution could do this as well.


One feature that I would also like to see is to be able to create coloured signals just the same way as subsystems or ports. Currently, the signals inherit the colour from the subsystem they originate from. I don’t know if there’s a way to manipulate this though.
It would be very easy to trace a particular signal within a complex model if it had a colour code. Any thoughts ?</description>
		<content:encoded><![CDATA[<p>@Matt</p>
<p>Interestingly, just the other day I was wondering if it was possible to create inports or outports on the top and bottom sides of the blocks.<br />
I was creating data flow diagrams in Visio and then I thought&#8230;”Hey&#8230;If  I could do this in Simulink, wouldn’t it be easy to create a concept diagram into a working model??&#8221;</p>
<p>It would be interesting to see if your solution could do this as well.</p>
<p>One feature that I would also like to see is to be able to create coloured signals just the same way as subsystems or ports. Currently, the signals inherit the colour from the subsystem they originate from. I don’t know if there’s a way to manipulate this though.<br />
It would be very easy to trace a particular signal within a complex model if it had a colour code. Any thoughts ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Seth</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-607</link>
		<dc:creator>Seth</dc:creator>
		<pubDate>Tue, 18 Nov 2008 20:15:04 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-607</guid>
		<description>@Matt Rhodes - Thanks for the comments Matt.  I'm interested in the solution you used.  The capability to put inports and outports on both sides of the block is a long requested feature.</description>
		<content:encoded><![CDATA[<p>@Matt Rhodes - Thanks for the comments Matt.  I&#8217;m interested in the solution you used.  The capability to put inports and outports on both sides of the block is a long requested feature.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Rhodes</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-606</link>
		<dc:creator>Matt Rhodes</dc:creator>
		<pubDate>Mon, 17 Nov 2008 23:32:50 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-606</guid>
		<description>Seth-

   Nevermind, I've figured this out and it works fine.  Using this technique, however, is incompatible with the mask drawing command "port_label()"  The workaround is to let it use its own labeling, and make the icon transparent... if making any kind of icon for the block, you pretty much have to use normalized or pixels as well or your port labels will probably get covered up.

-Matt</description>
		<content:encoded><![CDATA[<p>Seth-</p>
<p>   Nevermind, I&#8217;ve figured this out and it works fine.  Using this technique, however, is incompatible with the mask drawing command &#8220;port_label()&#8221;  The workaround is to let it use its own labeling, and make the icon transparent&#8230; if making any kind of icon for the block, you pretty much have to use normalized or pixels as well or your port labels will probably get covered up.</p>
<p>-Matt</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Rhodes</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-605</link>
		<dc:creator>Matt Rhodes</dc:creator>
		<pubDate>Mon, 17 Nov 2008 17:10:04 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-605</guid>
		<description>Seth-
   Ive been a Simulink user for about 8 years now across many and varied projects in both academia and enterprise, and have always loved how much time i save using such a great tool.  I've used custom masked blocks many times to convey concepts of the model.  One thing i've always thought would be useful, would be to allow in and out ports on both sides of a block simultaneously in order to facilitate neater, more straightforward routing of signals.  Ive managed to create blocks that allow this, but im having difficulty making the ends meet to make it completely functional.  Do you know of any ways to do this easily.  We are in the process of creating some very complex models, and being able to do this would be a difference of night and day for understanding the simulation diagrams.  Thanks, 
   -Matt</description>
		<content:encoded><![CDATA[<p>Seth-<br />
   Ive been a Simulink user for about 8 years now across many and varied projects in both academia and enterprise, and have always loved how much time i save using such a great tool.  I&#8217;ve used custom masked blocks many times to convey concepts of the model.  One thing i&#8217;ve always thought would be useful, would be to allow in and out ports on both sides of a block simultaneously in order to facilitate neater, more straightforward routing of signals.  Ive managed to create blocks that allow this, but im having difficulty making the ends meet to make it completely functional.  Do you know of any ways to do this easily.  We are in the process of creating some very complex models, and being able to do this would be a difference of night and day for understanding the simulation diagrams.  Thanks,<br />
   -Matt</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob</title>
		<link>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-468</link>
		<dc:creator>Bob</dc:creator>
		<pubDate>Wed, 06 Aug 2008 12:30:23 +0000</pubDate>
		<guid>http://blogs.mathworks.com/seth/2008/08/05/advanced-masking-concepts/#comment-468</guid>
		<description>I've done a few more advanced blocks like this.  While a bit more complex than regular blocks, I've found them much easier to debug than doing the equivalent in S-Functions.

Although, I tend to hide unused parameters rather than just grey them out.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve done a few more advanced blocks like this.  While a bit more complex than regular blocks, I&#8217;ve found them much easier to debug than doing the equivalent in S-Functions.</p>
<p>Although, I tend to hide unused parameters rather than just grey them out.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
