| Contents | Index |
| On this page… |
|---|
Navigate the Simulink XML Comparison Report Display Items in Original Models |
The XML Comparison report shows changes only, not the entire XML text file contents. The report shows a hierarchical view of the portions of the two XML files that differ. The report does not show sections of the files that are identical.
To step through differences, use the toolbar or the Comparison menu. To move to the next or previous group of differences, either:
Click the toolbar buttons Next
or Previous
.
Select Comparison > Next or Comparison > Previous. See Step Through Changes.
You can also click to select items in the hierarchical trees and observe the following display features:
Selected items appear highlighted in a box.
If the selected item is part of a matched pair it is highlighted in a box in both left and right trees.
When you select an item, the original model displays and the corresponding item is highlighted. See Display Items in Original Models.
Report item highlighting indicates the nature of each difference as follows:
| Type of report item | Highlighting | Notes |
|---|---|---|
| Modified | Pink | Modified items are matched pairs that differ between the two
files. When you select a modified item it is highlighted in a box
in both trees. Changed parameters for the selected pair are displayed in a separate Parameters panel for review. If strings are too long to display in the Parameters table, right-click and select Compare as Text to open a new comparison of the parameters. |
| Unmatched | Green | When you select an unmatched item it is highlighted in a box in one tree only. |
| Container | None | Rows with no highlighting indicate a container item that contains other modified or unmatched items. |
Icons indicate the category of item, for example: model, subsystem, Stateflow machine or chart, block, line, parameter, etc.
Use the toolbar buttons or the Comparison menu for the following functions:
Refresh —
Run Chawathe analysis again to refresh the comparison report.
Swap Sides —
Swap sides and rerun comparison. Runs the Chawathe analysis again.
Next and Previous —
Select the next or previous group of differences. See Step Through Changes.
Expand All —
Expands every item in the tree.
Collapse
All — Collapses all items in the tree to the most
compact view possible.
Printable
Report — Opens the Export Printable Report dialog
box, where you can choose to save a printable version of the XML comparison
report. See Export Printable Report.
Filter —
Opens the Filter Current Comparison dialog box. Select check boxes
to enable or disable display of categories of changes in the report.
Use the filters to show only the changes you are interested in. By
default the report hides all nonfunctional changes, such as repositioning
of items. Turn off filters to explore all differences
including nonfunctional changes. See Filter Out Differences.
Highlight —
Enable or disable highlighting of items in original models. See Display Items in Original Models.
Merge Node —
Merge the selected node from the left side of the report to the right.
See Merge Simulink Models From the Comparison Report.
Undo Merge
Operations — Revert all merge operations (also
in the Edit menu).
Export to
Workspace — Export XML comparison results to workspace
(also in the File menu). See Export Results to the Workspace.
For examples with instructions, see also Examples of XML Comparison .
If you click Next repeatedly, you can step through every group of changes in the report, in the following order:
First you step through each group of changes in the left tree. When selected items have a match in the right tree then they are also highlighted.
When you reach the last item in the left tree, then Next steps through the remaining unmatched items in the right tree.
When you have stepped through all changes, Next returns to the beginning of the left tree.
If you click an item in the report, the Next/Previous controls will step through changes from the point you selected.
When you compare the XML text files exported from Simulink models, you can choose to display the corresponding items in the original models when you select report items. You can use this reverse annotation function to explore the changes in the original models. When you select an item, the report invokes reverse annotation to the original model and highlights the corresponding item in the model.
Tip If you click a Subsystem contents node, the report highlights all visible modified objects in the subsystem. |
Click a report entry to view the highlighted item (or its parent) in the model:
If the item occurs in both models, they both appear with highlighting.
If there is no match for the item, the unmatched report item row is green. It is considered unique and appears highlighted by itself. An appropriate system in the other model also displays to show the context of the missing item.
If the XML comparison tool cannot highlight an item directly (e.g., configuration parameters), then it highlights the nearest ancestor of the selected node.
If you change a block parameter value from the default, you only see the new parameter in the report. Use reverse annotation to view both blocks.
To maximize screen space the models display with the status bar, menu bar, and model browser turned off.

You can use the report to explore differences in the model Configuration Parameters. If you select a Configuration Parameter item, the report displays the appropriate root node pane, if possible, of both Configuration Parameters dialog boxes.
The Parameters pane of the report displays the label text from the dialog controls (or the parameter name if it is command line only), and the parameter values. Some configuration parameters have a different hierarchy in the XML file and the dialog box. You can right-click to merge a selected parameter value in the Parameters pane.
You can toggle reverse annotation on and off by clicking the Highlight toolbar button in the Comparison Tool.
By default, models display to the right of the comparison report, with the model corresponding to the left side of the report on top, and the right below. If you move or resize the models your position settings are respected by subsequent reverse annotation operations within the same session. The tool remembers your window positions.
If you want to preserve window positions across sessions, position the window, and then enter:
slxmlcomp.storeWindowPositions
This preserves the placement of any Simulink windows, Stateflow windows, and truth table windows.
To stop storing window positions and return to the defaults, enter:
slxmlcomp.clearWindowPositions
You can use the Filter button or Comparison menu item to control display of categories of changes. Turn off filtering to view all identified changes. Categories for filtering include:
Nonfunctional changes. The report processing identifies certain items in the XML file as nonfunctional, for example, tags representing parameters such as block, system, chart or label positions, font and color settings for blocks and lines, and system print and display settings. The report processing tries to identify "consequential" changes as nonfunctional (that is, changes as a consequence of another change). For example, if a block name changes from block_A to block_B, a line emerging from that block has a change in its source block parameter. This change in the line parameters is considered nonfunctional. Lines are highly functional, but line changes can be very noisy because of changes in blocks they connect to.
Line changes. Hide all changes to signal lines including functional changes.
Changes in block parameter defaults. Hiding changes in defaults can avoid duplication in the report, as any changes in blocks are also reported as functional changes where you can use reverse annotation. Block parameter defaults are an undocumented part of the Simulink XML file that store the default parameters for the blocks used in a model. See also Changes to Parameter Defaults Appear As New Parameters.
Changes in the graphical interface. This information is a summary of inports and outports at the top level of the model. Filter graphical interface changes to avoid duplication in the report, as any changes in root ports are also reported as functional changes where you can use reverse annotation.
The report does not filter out changes to Block and System names, annotations, and Stateflow Notes as nonfunctional, even though changes to these items do not affect the outcome of simulation. The report always displays these changes to facilitate review of code changes, because they can contain important information about users' intentions.
In certain rare cases the report filters out changes that can impact the behavior of the design. By default moves are filtered as nonfunctional, but in the following cases moves can change design behavior:
Moving blocks can in some cases change the execution order.
In a Stateflow chart, if you move states or junctions so that they intersect, the model fails to simulate.
To view these types of changes in the report, turn off the filter for nonfunctional changes.
You can merge Simulink models from the XML text comparison report. You can merge individual parameters, blocks or entire subsystems.
The merge feature enables you to merge two versions of a design modeled in Simulink. You can merge from the left (or base) model to the right (or edited) model using the XML text files. Use swap sides if necessary. You can click Undo to revert all merge operations. You can merge modified, added or deleted nodes in the report as follows:
Select a report item and click the Merge Node toolbar
button
, or select Comparison > Merge Node. Merge is disabled when you cannot merge the selected
node. For example, you cannot merge the top level model nodes, data
nodes, or nodes within configuration settings.
View the results in the report and the models.
The report merges the selected node from the left side of the
report to the right. Merged report nodes have gray row highlighting,
and a green merge arrow if the node has an icon, e.g.,
.
The merge copies the change (a modified, added or deleted item) from the left model to the right model. If the node exists only in the left tree, then the merge inserts it into the right tree. Simulink Report Generator attempts to connect all lines to blocks after the merge, but you may need to manually connect some blocks.
To merge individual parameters, right-click an item in the Parameters pane and select Merge Selected Parameter.
You cannot insert or delete parameters, and not all parameters can be merged. For example, you cannot merge Simulink Identifier (SID) parameters. You can merge parameters that have changed from the default (only found on one side of the report), as long as the parameter exists in both blocks and is writeable. See Changes to Parameter Defaults Appear As New Parameters.
If you merge all possible parameters for a node then the report
marks that node as merged, e.g.,
. If you partially merge
some parameters of a node, the report marks the node as partially
merged with a green merge arrow icon and no gray row highlighting.
(Optional) To revert all merge operations, click the
Undo Merge Operations toolbar button
or select Edit > Undo. A dialog prompts you to confirm you want to throw away
all merge operations and revert the report and models to their original
state.
You will lose your merge changes if you change filter settings after any merge operations. A dialog prompts you to confirm you want to throw away all merge operations and revert the report and models to their original state. If you click Yes to continue, the Chawathe analysis runs again and you see a new report with the new filtering applied.
Tip If you want to merge subsystems, be aware that in XML text files subsystems are represented by two nodes, the container and the contents. The two nodes have the same name but different properties, for example, name changes are a property of the container node. You can merge the container parameters and contents independently. If you want to merge a subsystem and all its properties, merge both the container and the contents nodes. |
To understand the report, it is helpful to understand how the Chawathe results from the exported XML text files relate to the original models. Some special features of the report include:
Hierarchical node tags (such as subsystem tags in the .xml file) appear twice in the tree as nested nodes. This is because the container node and the contents can have separate differences in their properties.
This feature of the XML report allows you to distinguish between property differences of the node itself, and differences contained within nodes nested inside.
To see an example of nested nodes for a Stateflow block and its Stateflow chart, see the slxml_sfcar example.
Simulink software adds new parameters when the value of that parameter differs from the default, for example, rotating a block adds a new "rotated" parameter.
If the original models contain MATLAB Function block components, and if differences are found, the XML comparison tool lists them in the Stateflow section of the report. Click the new comparison icon at the end of the MATLAB Function block report items to open new comparisons in the Comparison Tool, showing the text difference reports for the MATLAB Function block components. See the example slxml_eml_radar.
If the original models contain truth tables, and if differences are found, the XML comparison tool lists them in the Stateflow section of the report.
Click the new comparison icon at the end of the MATLAB Function node to see a summary of all changes.
Click the truthtable node to reverse annotate and display both truthtable editors.
Click the new comparison icon at the end of the Condition Table node to open a new text comparison showing only Condition differences.
Similarly click the new comparison icon for Action Table to view only Action changes.
See the example slxml_truthtables.
If you see unexpected results within an XML comparison report, see How the Matching Algorithm Works in the MATLAB Report Generator documentation.
Note It might not be possible for the analysis to detect matches between previously corresponding sections of files that have diverged too much. |
If you cannot see changes you expected to see in the report, click the Filter button to turn off filters and see all identified changes. See Filter Out Differences.
Changes to Parameter Defaults Appear As New Parameters. If you change a block parameter value from the default, you only see the new parameter in the report. Use reverse annotation to view both blocks. You see only the new parameter in the report because Simulink adds new parameters when the value of that parameter differs from the default. For example, rotating a block adds a new "rotated" parameter.
The XML comparison report applies only to the currently selected models, and does not include changes to any referenced models or linked libraries. For compatibility with source control and peer review workflows, the comparison report shows only changes in the files selected for comparison.
If you want to examine your whole hierarchy instead, try using a Simulink Project, where you can examine modified files and dependencies across your whole project, and compare to selected revisions. See Managing Projects in the Simulink documentation.
If you are creating an XML comparison report for models that contain referenced models, and you have more than one referenced model with the same name, then your MATLAB path can affect the results. For example, this can happen if you generate an XML comparison report for the current version of your model and a previous baseline. To avoid seeing unexpected changes in model reference blocks, make sure that your referenced models are not on your MATLAB path before you generate the report.
The reason why results can change is that Simulink records information in the top model about the interface between the top model and the child model. This interface information in the top model enables incremental loading and diagnostic checks without any need to load child models.
When you load a model (for example, to export it to XML) then Simulink refreshes the interface information for referenced models if it can find the child model. Simulink can locate the child model if it is on the path. If another model of the same name is higher on the path, Simulink updates the interface information for that other model before exporting to XML. This can produce entries for model reference blocks in the comparison report that you did not expect. If you make sure your referenced models are not on your path before you generate the report, then you can avoid these unexpected results. If both model versions are off the path, the interface information in the top model is not refreshed during the exporting to XML process. Instead the cached information is used, resulting in a valid XML comparison report.
With library links, Simulink does not update the cached interface information when exporting to XML, and so the report correctly captures library interfaces. However with both referenced models and library links, Simulink updates the information when displaying the model. When displaying report items in original models, you may see unexpected results because Simulink may find a model or library that is higher in the path. To obtain the clearest results, make sure that the models and associated libraries are temporarily removed from the path. By removing the files from the path you will see unresolved library links and referenced models when you view the original models, but their interfaces will be correct and will correctly align with the comparison report.
![]() | Compare XML Files Exported from Simulink Models | Export, Print, and Save XML Comparison Results | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |