When diffplugg is rendering multiport switches it seems incorrect. Potential bug:
View in diff plugg:
This is the correct view in Simulink:
The error is valid for Matlab /Simulink veriosn 2017b
Thanks for reporting! Can you add a screenshot of the details in the bottom left for this block? Might need to resize to make the detail section big enough to show them all.
As an aside, this error is purely cosmetic, and does not affect diff or signal tracing accuracy.
When parsing the structure of a Simulink model, the way that wires connect to block ports is simple, and DiffPlug is able to parse this 100% of the time. The only problem with this method is that you can’t tell if there are any extra, unconnected ports.
In order to see if there are any extra ports, you need to execute logic specific to each blocktype, including .m scripts in the mask logic of custom library blocks. However, these cosmetic masks and unconnected ports have exactly zero influence on model behavior, and DiffPlug is still able to show and diff all block properties that are the inputs to the mask logic.
For the purposes of diff and model structure, there is no need to execute cosmetic mask logic at all, so when there are inaccuracies in this cosmetic mask logic (as you have found), it does not affect DiffPlug’s analysis of the structure and changes in the model. If DiffPlug ever encounters a non-cosmetic parsing error, it will yell very loudly to make sure you know that you can’t trust the diff result. In this case, you can trust the diff result.
Hello thanks for the quick reply!
I am however interessted in using diffplug not only to do compare/diff I want to use it as a viewer aswell. In this case the viewer shows a incorrect or incomplete routing of the signals going to the multiport switch.
How do you define custom lib block? The Multiport switch block is as far as I know a standard block in Simulink /signal routing with no posibility to edit or look under mask.
Attaching screenshot of the lower left part as requested
BR /Tobias
In this case the viewer shows a incorrect or incomplete routing of the signals going to the multiport switch
This is an excellent point, and you are correct that it is a bug. We will fix it in 2.3.1 this week.
Looking at the garbled DiffPlug image, you are absolutely correct that the routing is wrong based on the labels. And that’s what users look at, so you are correct that this is a bug.
But if you look at the routing based only on the port index / position, you’ll see that DiffPlug matches Mathworks exactly. That’s what I mean by “cosmetic”. The correct wires are connected to the correct ports, but the ports have the wrong labels. In an executing model, that would not be a “cosmetic” bug, it would be functional. But because DiffPlug does not attempt to execute a Simulink model, only to show the data, we are able to simplify the parsing in ways that make it much faster to load and compare models. We don’t simulate block behavior - we just display their parameters and connections. We slap labels on ports at the end, but for DiffPlug’s internal purposes they are purely cosmetic.
The Multiport switch block is … a standard block
You are correct. Even if DiffPlug knew nothing at all about the standard Simulink block library, we could still load and display blocks, display all of their parameters, and show how their ports are connected.
The only thing we gain by implementing the block library is that we can label their ports, and show mask images. If we get something wrong in this logic, then we can end up showing extra ports or mislabeling ports - which is misleading and a big problem - but it won’t affect anything besides the labels or showing empty ports.
If you have any feature requests or bug reports similar to this in the future, what is most helpful is a sample model (just copy-paste the block into a new model) or a screenshot of the detail pane at the bottom-left (see below). We were able to easily reproduce the problem you’re seeing, and we’ll have a bugfix release this week.
Thanks I will send sample models in the future!
Resolved in 2.3.1. Thanks for reporting!