MATRIXx

cancel
Showing results for 
Search instead for 
Did you mean: 

What is the best way to maintain models with common components?

I work for a company that uses MatrixX/SystemBuild (v62.2) to build functional models of trains for use in driver training simulators.  We are currently in the early stages of a project in which we will need to build and maintain multiple train models which are likely to have some common components, but may have some significant differences.  Before we get too far into the modelling, I would like to come up with a decent method of maintaining the common components while keeping the differences separate.
 
Ideally, I would like to find a way of quickly and easily determining the difference between two models and a way of conditionally pushing the differences from one model to another - in a similar way that one might diff two text files and conditionally copy the changes in one to another.
 
I found a script (mx_62.2\sysbld\scripts\compare_catalogs.msc) that seems to accept two catalogs for comparison, outputing a difference log. However, I'm unsure how to use this as I don't know how to load two catalogs within the same instance of Xmath or how to assign a catalog to a variable for passing in to a function.  Does anyone know how to use this script?
 
I am also thinking that it might be useful to be able to convert a catalog to an xml - I can probably write a script to do this, however I am wondering if there's anything freely available to do this.
 
Does anyone have any other ideas?
0 Kudos
Message 1 of 3
(8,665 Views)

Let me first discuss about comparing models, then I'll talk about my ideas about modularization.

Comparing models in anything before v8 is difficult. In v6 or v7, there's no way to load to separate files containing the same yet different superblocks. The tool scripts you found don't seem to be documented anywhere. Given the history of some of the things added into the product, I'm not surprised. Which means that it's useless to us. After looking at the scripts, it's difficult to figure out what the inputs to that script should be. You can launch multiple instances of xmath/sysbld and load the models separately, but that's about it.

One suggestion if you have to compare models is to use the exportcatalog.msc script which will generate a text file containing the SBA commands to re-create the model. Do the same for both models then perform a text difference between the generated SBA commands in the generated files.

Another possibility is to use SBA to get the details of each superblock (similar to exportXXX.msc scripts) into a form that's easier to compare between. I'm going to guess that some kind of generated SBA content is the expected input to the compare_catalogs, but I'm not sure.

Now, within v8, we've created a hierarchical compare tool, that compares model files and shows differences. Copying changes between the compared models is a future enhancement. However, in the context of using v8, you could manually copying the changes between the models using the editor and/or project system as appropriate. Yes, in v8 you can separately load models containing the same named superblocks. Try it, I'll bet you'll like it and it will save you lots of time!


Now, on to modularization. I'm not sure you're use of 'components' is the meaning of the Components feature in Sysbld or not. I'm going to assume that you are not using Components and you're generically using the term components as a set of logically related superblocks, or as I perfer to call them, a module.

The only modularization tool you have in Sysbld is the file. What I mean here is that you are able to group sets of superblocks into separate savefiles (.sbd) then combine them to create a complete model. So, essentially, you will need to partition your model into modules and each module is a separate savefile. Then, you can choose which module (i.e. savefile) to load to construct a complete model.

In v8, there's a project system specifically designed to make this kind of modularization within a project easy and straightforward to use and maintain. I'd suggest that you use v8.

For previous versions, the best you can do is create xmath scripts for each complete model you need. The script will contain all of the steps needed to load the separate modules to make a complete model. Thus, you'd have a different script for each model. Also, becareful in v6,v7 that you'll have to manually manage which superblocks are part of which modules, it's tricky stuff. Again, you'll need to use scripts to help maintain this level of complexity in these versions of the Sysbld.

Now, I do not want to recommend FileSuperBlocks, it's a legacy feature to deal with limited resources not applicable on today's machines.

Also, I can't really recommend the the Component feature in Sysbld. It's really not a component, but more of an object, sort-of. And it sort-of gives you unique names and it sort-of gives you parameters. It will not help with the modularization I think you want so don't use these.


In general, there are features within our latest v8 release of MATRIXx that will help you with all of your issues. If you can, upgrade!

Bob Pizzi
MATRIXx R&D

0 Kudos
Message 2 of 3
(8,654 Views)
Thanks for the feedback.
 
I wasn't able to find exportcatalog in the xmath install folder, however I did find exportsuperblock which I had not seen before - looks like it could be promising.  I think I could fairly easily extend this to export all superblocks within a catalog or in one block heirarchy.  I am a little concerned about the apparently random order in which it retrieves the block IDs - but I guess I'll just have to sort this out myself.
 
A note on components - as you pointed out, I am using component as a group of blocks forming a piece of functionality rather than the SystemBuild interpretation - I will try and use the term module in future to avoid confusion.  I have not personally found any great advantage in using SystemBuild's component feature.
 
For now, I think we will be keeping our models within a single file - If the models are built right, it should be obvious which superblocks contain a module, and which are merely functions containing part functionality.
 
As for upgrading - I would need to convince my boss(es) that this would be cost effective.  As you say, there are a few useful improvements, but we do currently manage with what we have (despite interactive simulator crashes, as I have mentioned in another post).
 
We currently use MatrixX mainly for modelling in SystemBuild and for it's Autocode capabilites.  In order to upgrade, we would need to be sure that we could update our current models, and that the output of the Autocoder will still integrate with our system.  Feel free to contact me directly or to forward my details to your sales department through the email address in the attached picture.
0 Kudos
Message 3 of 3
(8,641 Views)