Page36 INSTRUCTION MANUAL CENTRAL COMMAND STATIONS MX10, MX10EC
Menu point ObjectDB vehicles
object list by addresses
GREEN
The centralised Object Database in the central command station usually contains automatically pro-
duced copies of all entries which are or were stored in the controllers (also if they were deleted from
the controllers in the meantime). This centralised database is the basis for the sending organisation of
data packets on the tracks as well as for transferring the GUI data between the input devices.
The menu point “ObjectDB vehicles” shows the contents of the centralised data base (registered loco
addresses including their current driving data and data communication statistics) which can also be
controlled there. Additionally, specific measures can be taken, especially deleting single addresses to
relieve the sending cycle, or stopping the trains.
Calling up this menu point, the list of loco addresses with their (available) names, current speed step
and driving direction are presented (“basic display”).
Rotary knob
Scrolling through the list of addresses, “
“ as the cursor shows the current position.
Button
1
(
)
Changes the information shown for each address
Basic display 0: Address Name MAN bit speed step direction arrows
*)
Button
1
(
)
Displ 1: Address “in” traction name (or number) activation code
**)
Button
1
(
) Displ 2: Address device info: on which device this address is active (also LoR)
Button
1
(
)
Displ 3: Address P F M „Fu“
x x
***)
Button
1
(
)
Displ 4: Address DCC packages / sec RailCom feedback / sec track format
***)
Button
1
(
)
Displ 5: Address feedback (via RailCom) speed (km/h)
*****)
Button
1
(
)
Displ 6: Address manufacturer Decoder type (if ZIMO) ID
******)
Button
1
(
)
Displ 7: Debugscreen
*******)
Press
button
1
(
) LONG resume to basic display
Button 2 (MENU)
Sub menu, inter alia, deleting from the database (back from sub menu with but-
ton 3)
Press rotary knob
to “BaseCab” screen (if by mistake, resume with button 3)
*)
Basic
Display 0: Name & driving data
Shows name (if available) and current driving data (i.e. MAN
bit, speed, direction) for the loco address in question.
**)
Display 1: Display traction info and activation code
Those two do not have anything in common, they are com-
bined for reasons of space. Traction info shows, where ap-
plicable, in which consist (name or number) or train the loco
address is integrated.
Activation codes in display 1:
FG object (loco address) is in the
foreground
on the controller
HG object (loco address) is in the
LoR
of at least one controller
CS this object (loco address) received commands from the
computer
in the last 5 seconds
HG CS both ….
***)
Display 3: DCC-packet monitor function
Shows in intervals of about 0.5 seconds, what kind of
packets were sent during this period for this address. The
“flickering” frequency of a certain packet indicator (e.g. F or
the third
) represents the sending intensity of this data. If,
for example, the slider on the controller is moved, the “F”
indicator flickers every time, i.e. the DCC speed packet for
this second was sent at least twice per second.
Especially interesting for diagnose and analysis are of
course the addresses that are currently inactive or in the
background of an input device, and therefore rarely inte-
grated in the “refreshing” cycle. Potentially appropriate ac-
tions can be derived, like settings in “FUMZ” on the control-
ler to avoid unnecessary packet transmissions.
Types of packets and their indicators:
P
= programming commands (OP PROG);
F
= driving
commands (speed steps and direction);
M
= MAN bit; „
Fu
“
…
= the 5 function packets:
F0 .. F4
|
F5 .. F8
|
F9 .. F12
|
F13 .. F20
|
F21 .. F28.
****)
Display 4: DCC statistics & RailCom
This is where the number of sent DCC packets and re-
ceived RailCom feedback for the corresponding address is
display:
In the cursor’s line ”
“: Number/sec
In the other lines on the screen: cumulated number of
packets / feedback since the last power on.
*****)
Display 5: RailCom feedback
This is where the content of the RailCom notifications is
shown, especially the speed feedback (km/h), but also oth-
er information
(compare: statistics of RailCom feedback in previous
screen).
******)
Display 6: Decoder information
The most important information of the decoder of the cor-
responding loco address, i.e. manufacturer (according to
“NMRA-ID” in CV #8), type (if ZIMO decoder or different
registered manufacturer), ID (if available)
**)
Display 2: device info
*******)
Display 7: Debugscreen
NOTE: Driving operation is also possible without looking at the Object Database. In the ZIMO system,
almost any number of addresses can be managed at the same time; theoretically, the refresh cycle
holds up to 8000 loco addresses (compared to other manufacturers, who are usually limited to 64 or
128). If this possibility is used (to some extent), it may be useful to investigate, why reaction times, for
example, are getting longer, why refreshing packages are received infrequently, or which entries in the
database could be deleted - and actually deleting them.
NOTE: Those values only show, how many packets / feedback are
counted to a certain address and do not distinguish between differ-
ent types of packets (speed steps, function commands, etc.); the
latter is shown in the previous screen (packet monitor).
