Outsourcing a Model

Sometimes, it is a good idea to hide a Model (Data Model or Component) from the user or to avoid having the same Model duplicated into each database that would need it.

Making a Model a library and distributing only its interface will do that.

 

Built-in Models of vsTASKER have been created this way: designed into vsTASKER, tested, improved until they were complete enough to be extracted from the development database and converted into one header and its associated source file, ready to be compiled and added into the simulation engine library.

 

The user can do the same with its own models and gather them into specific libraries to be delivered or deployed along with the simulation engine, keeping the code proprietary.

 

Although the process of generating a library is simple, the inside code may have to be modified because from the library standpoint, their will be no visibility of database specific variables, models or entity parameters. The library component will need to rely on external declaration dependencies and virtual functions.

 

 

 

Create a myTest component.

 

In Declaration, do the following (this is just to add some data in order to give something to do later):

 

And in Runtime, add the following:

 

Then, click on Make Lib button (and click Yes on the question window)

You will be asked to specify where to store the header file of the model, then the source file. It is a good practice to create your own directories inside model/include and model/src ones. You also have the chance to rename the files. By default, the name of the model is taken as is. If you rename it, you will need to change the #include directive in the .cpp file.

 

You will get this result:

 

 

Now, you need to add these two files into a solution to create a library.

You have the choice to use an existing solution, although it is not a good idea as the next update of vsTASKER will erase all your entries.

 

The best approach is to create your own folders and solutions.

You can have as many as requested, all organized in different folders.

Here we are going to create a myModels folder in both Model\Include and Model\Src one.

Then, we will move the mytest.h file into Model\Include\myModels and mytest.cpp into Model\Src\MyModels (you can also combine .h and .cpp into the same folder somewhere else).

 

Now, rename the template solution UsrLib.vcproj (in Model\Make\vc90|100|140) into myModels.vcproj.

Open your C++ VisualStudio and load this solution.

 

Then, add mytest.h and mytest.cpp in the correct filters (you can remove the template_*.* entries that are useless)

 

In the myModels properties window, change the name of the library to: $(VSTASKER_DIR)\lib\vc90\myModelsD.lib (vc90|vc100|vc140...) and D for debug, nothing for release.

 

Compile and build myModels.lib and myModelsD.lib libraries.

 

 

Although the code generator tries to do its best to out source the model code, there are things that cannot be automatically translated. You will have to manually fix that from Visual Studio.

The most common errors you will encounter are the following:

 

Entity class only exists inside vsTASKER database. From outside (Sim or Libraries), only Vt_Entity is known. Entity is code generated and inherit from Vt_Entity, defined in include/engine/vt_entities.h

So, in the code, Entity* must be replaced with Vt_Entity* wherever it is possible. If your model is using specific variables defined in Entity class and are code generated, then it will be difficult to access them from a library. You need to reconsider the design of your model or leave it code generated.

 

 

In order to use the new component from vsTASKER, it must be added into a directory.

In Model folder, you will find some directory files (default_cp.lst, default_dm.lst...)

 

It is possible to modify these files to add user Components or Data Models but with the risk to lose the entry at each update of the product.

The best way is to create its own entry and add it into the preferences of vsTASKER.

 

Rename (or duplicate) user_cp.lst into myModels.lst and open it.

 

The entry in the directory list must be understood as is:

 

 

+myModel.Components: + to name a tree list entry with myModel as the first entry and Components as a embedded list. All following lines (data) will fill the entry until a new list is encountered.

 

A data line will be made of 4 items separated by spaces or tab:

1) myTest, label used in the tree list

2) myTest, name of the Component class

3) myModel/mytest.h, header file, with relative path from /Model/Include/

4) myModel.lib, name of the library where the Component is stored

 

In order to be able to use this new directory list (myModels.lst), it is mandatory to include it into vsTASKER.

 

Open the D:\VirtualSim\vsTasker\7\Model\myModels.lst file and add it to the list with , then Save.

 

 

Now, in vsTASKER, importing predefined Components will include myModels component list (1 for now, but the list can grow):

 

Now that the Component is available as an external source, it can be either imported from the above list, or converted if already in the database (like in this example).

In the myTest Component, change the Local to External:

 

Then open/select the myTest component to replace the actual Local one:

 

The myTest Component will then change to External, all references will remain unchanged and the symbol will be changed to read-only.

 

 

 

 

 

If a new Dyn-UI variable must be added into the Component once it is external, some precaution must be taken.

 

In the following example, if we need to add the altitude variable, let's do it this way:

 

In mytest.h, add the following entry: float my_altitude; //&& DEF[0]

 

In mytest.cpp, do the following:

 

add:

 

add:

 

add:

 

add:

 

Repeat this process for all Dyn-UI variable additions or changes.