Screenshots
|
| |
Model construction
|
The model building workspace shows the folder tree of models on the left, the current model in the middle, and
details of the selected component on the right. Models are built by dragging components off the bar at the top
and connecting them together. Component parameters are set on the right along with textual descriptions of what
they are intended to do.
|  |
|
Models can also be viewed and edited in a text/tabular format. The middle tree shows the internal structure of
a single model file. The model takes the form of a structured document with descriptive text for each
subcomponent as well as the parameter values.
|  |
|
Optionally, a model can have associated script fragments that give a programmatic way to define behaviors.
This is an alternative to modeling the control system graphically, and also adds the ability to link out to
independent software to provide more complex control. For each possible event generated from the model,
a corresponding block is provided to enter the code that should be run when the event occurs.
|  |
|
The header of the script editor shows all the quantities that are available to use from within script fragments
and the methods that are provided to control the model. The names and types of these methods depend on
the input and output ports defined for the components from which the model is built.
|  |
Running models
|
Depending on the data recorded as the model runs, different possible views will be available. This one shows
a movie of the rat in the maze. New views can be configured from the available data and will be automatically
available for other models of the same type. The "auto rerun" option causes the model to be rerun whenever
a parameter on which it depends is changed which is convenient for tuning models to achieve particular behaviors.
|  |
Component construction
|
Designing components is very similar to building models except there are no wires needed. There is a standard set
of field types that can be put in a component (integers, floating point values, sets, etc). Connections between
components are handled by adding "sockets" and "plugs" (squares and circles on the diagram). The colors indicate
what type of information flows through the connection. These connection types can be defined in much the same
way as components are defined.
|  |
|
Script fragments are required in order to define the behavior of a component. A fragment
can be provided for each of the input ports. Each output port gives rise to a method that can be called
from the fragments. As an alternative to the embedded fragments, scripts can also delegate the
creation and behaviors of components to external modules. This provides a route to use efficient external
implementations while keeping the accessibility of component based models.
|  |
|
