Page History

...

To Be Continued...

In the next episode of "Visualization Documentation":

...

• Trains are hidden when not in use

...

Constants.ftl

This file contains constant assignmets to various variables such that they can be used in other templates.

A big portion of those variables are the typical railway interface (which track has which number, how many tracks / lamps / points exist, values for STRAIGHT / BRANCH, ON / OFF, etc.).
Another huge portion of constants are actually defined in the wagon SCChart from the environment and represent natural constants from the railway. These includes all positions (point positions, contact positions, etc.) as well as track lengths.

The third main part of constants classifies the railway tracks (which tracks are branched / unbranched, have contacts, are unidirectional / bidirectional, etc.). These are used in higher level templates to calculate the final visualization file.
For example there are more signals on bidirectional tracks than on unidirectional tracks that have to be animated differently. These classifications are thus used to easily iterate over suited tracks to easily create a good kivis file.

BasicVisualization.ftl

This file generates the visualization for all elements that both—the environment and controller—use. Normally this is the case for the common interface variables, such as points, lamps, track_speeds, signals, etc.
On the other hand what is not handled here are variables specific to the environment (exact position of trains, errors) and controller (position of trains determined from reed contact signals).
Another animation that is placed here is hiding a train, if that train is not positioned on the railway (train_setup <= 0).

The following shows a more complex example of how signals can be animated, to illustrate the usage of templates and pre-defined variables from Constants.ftl

//------------------------------------------------------------\\
//--             SIGNALS OF BIDIRECTIONAL TRACKS            --\\
//------------------------------------------------------------\\
<#list bidir_tracks as track>
<#list ["fwd", "rev"] as dir>
<#assign dirNum = if(dir="fwd", 0, 1) />
<#-- Some tracks don't have signals -->
<#if no_signals?seq_contains(track)><#else>
animate ${track}${dir}Red {
  apply color using signals[${track?eval}][${dirNum}] {
    fillOpacity: 0 is 0, 1 is 1, 2-3 is 0
  }
}
<#if (dir="fwd" && no_fwd_yellow?seq_contains(track))
  || (dir="rev" && no_rev_yellow?seq_contains(track))><#else>
animate ${track}${dir}Yellow {
  apply color using signals[${track?eval}][${dirNum}] {
    fillOpacity: 0-1 is 0, 2 is 1, 3 is 0
  }
}
</#if>
animate ${track}${dir}Green {
  apply color using signals[${track?eval}][${dirNum}] {
    fillOpacity: 0-1 is 0, 2-3 is 1
  }
}
</#if>
</#list>
</#list>

The main loops iterate over all bidirectional tracks (defined in Constants.ftl) and over both directions ('fwd' and 'rev'). This makes sense because the index of signals on bidirectional tracks is 0 for the first in main travel direction, and 1 for the second signal in main travel direction.

There are bidirectional tracks that do not have signals (defined in Constants.ftl) thus there is a test to check if the current track is one of those without signals. In this case there is no need to create the animations.

What follows is the animation for the red, yellow and green circles of the signal. The naming scheme of the SVG file has to considered, to animate the correct element (see Model Railway Layout SVG).
The array with the states of all signals is calld signals and is two dimensional (see Interface). The first dimension is for the track, the second is for the direction (0: first in main travel direction, 1: second in main travel direction). Thus ${track?eval} will evaluate the name of the current track (e.g. KH_LN_7) to find an associated value. As all track constants are defined in Constants.ftl, this statement will result in the index of the track that the current iteration is for.

In conclusion the animation of the red, green and yellow circles is created on all bidirectional tracks that really do have signals, based on the array that holds the corresponding value for that signal. This is the intented behaviour.

ControllerVisualization.ftl

This template positions the trains on the middle of the path for track, that the train is currently standing on. The controller can only calculate the track of a train but not its exact position using the inputs from the reed contacts. Thus this simple animation is created for the controller.

EnvironmentVisualization.ftl

This template creates the visualization of trains on the main tracks as well as branches of tracks (e.g. KH_ST_4branchKH_ST_5). The environment saves the exact position of trains on the track, which is used for the generated animation.

Furthermore, errors calculated in the environment are visualized using labels. This involves two labels in most cases, one for the error message, one for a corresponding number (e.g. a message such as "point error", and a number with the actual point that has this issue).