|
Professional Data Management - the Object Explorer:
The new Explorer allows effective managing and editing
of data
in a Windows-Explorer like manner. The Explorer shows three window
panes, that allow among others:
arranging
of data in a customized folder structure.
listing of common properties of groups of objects (e.g.
names, digital addresses and date of last modification of all turnouts).
effective viewing and editing of the details of single
objects.
|
The Explorer Window
The possibility to open
several
Explorer windows simultaneously allows quick comparison of object
attributes.
|
|
Comprehensive Print Jobs:
It is now possible to arrange comprehensive and detailed
printouts of all data stored in TrainController™.
Among others these
printouts can contain:
switchboard, block and schedule diagrams.
lists of objects on a one-object-per-line base arranged
by
type, e.g.
all signals, or by individual Explorer folder structure, e.g. all
objects, that belong to a certain yard. Sorting is possible according
to different criteria such as name, digital address or date of last
modification.
object details, that show all attributes of an object
and all
references to and from other objects on a one-object-per-section/page
base.
|
Sample Printout - Turnouts
sorted by Address
Arranging a Print Job
The printouts are composed by using HTML technology. That means, that
people familiar with HTML and cascaded style sheets (CSS) can customize
the
overall layout and contents of the printed pages to their personal
needs.
|
|
Dr. Railroad Data Diagnosis:
Dr. Railroad is another outstanding new feature of TrainController™.
This function checks all data entered into TrainController™ with
artificial intelligence and detects automatically logical and other
failures, lists them in the message window and gives hints to correct
this.
It is also possible now, to copy the content of the message
window to the clipboard or to save it to file.
|
|
Custom Train Functions /
Function Library:
The set of available function names and symbols (function library) can now be
extended with own functions. It is also possible to customize the names
and symbols of existing functions to personal needs. For editing of
custom function symbols a specific integrated bitmap editor is
provided, too.
Editing a custom Function
Symbol
|
|
Unlimited Number of Train
Functions per Engine:
More than only nine functions per train can be arranged now. Function
controls can be added and deleted. Their order can be easily
rearranged. |
|
Hidden Train Functions:
It is possible to specify certain engine functions as hidden. Hidden functions are useful
in conjunction with automatic control, schedules and macros; but they
do not cover any space in the train window. |
|
Resizing Property Dialogs:
All property dialogs can be resized now to personal needs. This
improves significantly the convencience and clarity during editing of
object attributes, especially in cases, where lists of objects with a
large number of entries or where controls with long text strings are
managed. |
|
 |
|
'Dummy' Symbols without
physical Connection:
It is now possible to create 'dummy' symbols for turnouts, signals,
accessories, engines and feedback indicators without physical
connection to a digital system and without the need anymore, to
configure a 'dummy' offline digital system. Such symbols are often very
useful for specific control logic.
|
|
Automatic Assignment of Train Control:
The manual assignment of train control from the computer to the digital
system or back is no longer necessary for all digital systems, that
properly support this feature. Trains, that are controlled with a
handheld/throttle of the digital system will be automatically tracked
and monitored until they are released or stopped again. This feature
will be at least available for the following digital systems: ROCO
Multimaus, Intellibox, Twin Center, Tams, Digitrax, Müt. |
|
Nested Conditions and Triggers:
It is possible now to mix logical terms AND, OR and (new) NOT in one
single trigger or one condition of an object. Terms can also be nested
within each other.
|
|
Redesigned Signalling System / Prototypical
Signalling:
It is possible to specify logical rules for the state of signals based
on nested logical triggers (see above). The possibility to evaluate the
signal status calculated for each block supersedes the former
assignment of signals to blocks. The combination of these stati with
other conditions extends the flexibility of the signalling system
significantly. Simultaneously the complexity to configure sophisticated
signalling systems is reduced heavily due to the fact, that complex
triggers can be assigned directly as signal rules without the need to
arrange complex flagman structures.
With these means the rules of almost every prototypical signalling
systems can be modelled now.
Signal rule: turn the signal to yellow/slow,
if a train passes Block "Main Line East" to the top
and if one of the two diverging routes "Hidden Yard East 1"
or "Hidden Yard East 3" is active.
|
|
Integrated
Block Signals:
For simplified signalling it is to assign two signals to each block,
each associated with one of the possible two directions of travel. Such
"integrated" block signals show the internally calculated block signal
for the associated direction of travel. These signals can also be
operated manually by clicking to their symbol in the traffic box. |
|
Train
Guidance:
It is possible to limit the use of blocks and routes to certain
engines, trains and train groups. Once and for all and without the need
to define specific schedules the ICE can be kept away from the branch
line, the freight train from the passenger platforms, the electrical
locomotive from the non-electrified track sections, etc. Experienced
users will appreciate the significant reduction of the number of
necessary schedules. New users will appreciate, how easy trains can be
automatically directed to the right tracks. |
|
Extended
Control of Block States in Conditions and Triggers:
Beside the "classic" occupancy and reservation information additional
states of blocks can be evaluated in conditions and triggers of other
objects:
the fact, whether a block is the current block of a
train
(this is the block, where the head of the train is assumed).
the direction of travel, in which a block is passed
(e.g. to
the right, to the left).
the orientaion of the train, which is currently
reserving a
certain block (e.g. headlights to the right or to the left).
the direction dependent block signal currently
calculated by
the Dispatcher for a certain block (e.g. red to the right, green to the
left, etc.).
|
|
Evaluation of Schedule Activity in
Conditions and Triggers:
In conditions and triggers of other objects the status of schedules can
be evaluated. In this way it is for example possible to activate a
Virtual Contact as a stop point for certain schedules only.
|
|
Stopping of Schedules by Operations:
A running schedule can be stopped by operations of buttons, macros or
indicators, etc. Usually all trains running on that schedule are
stopped. In the specific case, that a macro or indicator is triggered
in the context of a train (e.g. by schedule or an engine function) only
this train is stopped; other trains controlled by the same schedule are
not affected in this
case. By calling this function from a macro, which is triggered by a
schedule, this allows to automatically cancel the current schedule.
|
|
Destination and End Blocks of Schedules:
There is a new schedule rule, with which end blocks (in previous
versions called 'calculated destination blocks') can be prevented from
being used as destination blocks. This rule is selected by default for
all newly created schedules and gives even more control, where trains
shall terminate as in previous versions. This new rule is for example
useful for AutoTrain™ through reversing loops, where it is now easily
possible to safely prevent the train from going back to the start
block, if this is not desired.
|
|
Improvements for the Speed Profile:
Version 5.8 D1 provides certain improvements for measuring the speed
profile of a locomotive in TrainController™.
Measuring of a single speed step is much easier now: the speed step can
be selected first, before the locomotive is started.
Furthermore it is now possible for users of TrainProgrammer™
to program the most important, speed
related CVs (CV2 to CV6) directly from the speed profile function in TrainController™
without the need to start TrainProgrammer™
separately. In this way the speed
characteristics (e.g. maximum speed) of a decoder and the speed profile
can be adjusted in one process.
If a single speed step is measured, then TrainController™
displays the scale speed at the end of the test run. The result can be
used together with the possibility to program the maximum speed into
the decoder without leaving TrainController™ to
adjust the maximum speed of the decoder efficiently and conveniently.
|
|
Support
of the new ESU ECoS:
From Version 5.8 C1 TrainController™ supports the new ESU ECoS
digital system. TrainController™ is therewith the first
officially released software for model railroad computer control, that
supports digital systems, which are connected via Ethernet. The ECoS
software version 1.0.4 is required.
During this project we sent a number of suggestions for extensions and
improvements of the ECoS to ESU, which have been
mostly implemented by ESU. The ECoS provides, for instance, a default
protocol for new locomotive objects. This feature enables TrainController™
to control trains without prior definition of
according ECoS locomotive objects or laborius linkage of each
particular locomotive to an ECoS locomotive object.We suggested,
to provide such default protocol for new ECoS accessory objects, too.
Now it is also possible for TrainController™ to
operate turnouts, signals and
other accessories ad hoc, too, i.e. like trains without laborius
linkage of each
particular turnout or signal symbol in TrainController™ to an ECoS object.
|
|
New
Features of TrainProgrammer™:
From Version 5.8 D1 TrainProgrammer™ supports a new "standard"
decoder configuration, which can be used for convenient and intuitive
programming of the most
frequently used decoder options of almost all NMRA DCC compatible
locomotive decoders.
Furthermore it is now possible to extend the decoder database of TrainProgrammer™
by import of all existing XML based JMRI decoder
definition files into the database. You can certainly
create and import own definition files in XML format, too.
|
|