October 13, 2014
Generation of MODL Database Access Constants
One for MODL coders only! I was recently building a model with a database and needed to refer to the contents of the database from custom blocks and equations. This seemed a good place for the use of a header file. However, it would have been tedious to code all the constants I needed by hand so I wrote a little utility block to automatically generate the required code. As it is general purpose I though someone out there may also find it useful.
Take a copy of any model with a database and add the block from the library you can download here CodeGen or on the downloads page. If you open the block dialog you are presented with four check boxes:
- I often keep a simple table for model parameters. Just two fields in each record. The first is a string name for the parameter and the second a value. Checking this option searches for a ModelParameters table and for each record, generates a Constant with its name based on the name field and its value is set the MODL DBAddress for the value field.
- The second check box causes a ModelState table to be treated in the same way.
- This option causes the generation of a full set of indices for all databases, tables and fields in your model.
- ExtendSim also uses database for internal purposes. Normally you will not be interested to generate indices for these so use the check box to ignore them.
To generate the header file just click on the button and a file save dialog is opened. Select the all file types option (*.*) and give your file a .h extension and directory. Hitting save causes the file to be generated. The results will be similar to this (first few lines shown):
CONSTANT P_MinimumSpeedDBAddr is 20002002000002;
CONSTANT P_MaximumSpeedDBAddr is 20002002000003;
CONSTANT P_DistanceDBAddr is 20002002000004;
CONSTANT S_ActiveServersDBAddr is 20003002000002;
CONSTANT S_ClientsInSystemDBAddr is 20003002000003;
CONSTANT D1_ExampleDatabase is 1;
CONSTANT D1T1_ModelParameters is 1;
CONSTANT D1T1F1_Name is 1;
CONSTANT D1T1F2_Value is 2;
The naming convention is rather cumbersome but it does avoid naming conflicts as well as being simple to decode. P_ is used as a parameter suffix, S_ is a model state suffix while D1 means database 1, D1T1 means database 1 table 1 and so on. The code is quite straightforward – I have not had time to document it but variable names should help if you want to modify it. As usual let me know if you have any suggestions.