Page 38 TETHERED CONTROLLER MX32, RADIO CONTROLLER MX32FU
Handover/Takeover of consist between controllers:
If an address in the
LoR
is marked with "FT (..)", the ve-
hicle can not be activated directly because it is part of a
consist in another controller *), which is NOT ACTIVE at
the moment (not in that controller
’s foreground). If, on the
other hand, this consist is currently ACTIVE in the other
controller (i.e. one of the vehicles involved is in the fore-
ground on that controller), "FS (..)" is displayed in the
LoR
(= external control with the number of consisted vehicles).
*) This is also the case if this other controller
, the “owner” of
the consist, is no longer connected to the system or the radio
communication is lost.
These "FT (..)" or "FS (..)" markers are also shown in
the main address field (after the vehicle is brought to
the foreground with the
A-Key
from a
LoR
line or via
the
F-
and
U-key
) together with the corresponding note
“External Consist” or “External Control” in the header.
If a takeover attempt of such a vehicle is made (by
pressing a function key or changing the speed), the
header closes and in its place the WINDOW
“External Consist” or “External Control” opens
with these options:
U-Key
the consist (= with all participating engines) is
taken over and controlled by the new controller. At the
same time the
ownership
**) of the consist changes
from the old to the new controller, and all vehicles in-
volved *) receive a mark such as
“
T1
”
,
“
T2
”
…“, while
on the old controller these addresses are changed to
"FS (..)".
*)
Addresses that belong to the consist but have not yet ex-
isted on the new controller will also automatically be in-
cluded in the
LoR
(with the markers
“T1”, “T2”…“
).
**) A consist can only belong to one user; this one can be
changed; the original creator does NOT matter.
A- Key
the consist will NOT be taken over, the con-
troller once again displays the header as before.
After the consist has been taken over, all the address-
es involved are located in the
LoR
of the "new" control-
ler and marked with
“
T1
”
,
“
T2
”
etc., whereby the sys-
tem attempts to reassign the previously used T-number
(if free).
Technical Supplement to the Instruction Manual:
This part is theoretical in nature and not necessary for the normal operation of the MX32
.
Basics:
The ZIMO system has a decentralized intelligence: each controller has, independently of each other, T1
…T9 at its disposal; the system ei-
ther has to deal with so many consists that the number is practically never reachable, or it would need a very complicated procedure with
the corresponding GUI messages in case the memory is full.
The MX10 takes over the consists only temporarily until the system is turned off; however, they are stored permanently in the controller
(including the calibration values). Each time a controller starts up and starts communicating with the MX10, it must send its own consist
data to the command station, where it will remain active until the next system shutdown (the information is ignored if the consist already
exists in the MX10
– i.e. after cable connection or radio interruption). In the MX10, the consists must have an identifier attached to it, made
up of the T-number (1, 2...9) from the controller and the ID of the controller itself (unique worldwide).
To avoid inconsistencies, the controllers send their consist data regularly (preferably every 30 seconds). From this, the command station
recognizes for example, when a consist has been deleted (and therefore needs to delete it also in the command station, as well as the
"FTs" in the other controllers).
ATTENTION: This does NOT mean that the MX10 (except for Power-off) can forget a consist because it simply does not receive messag-
es from a controller (it may be disconnected from the cable or radio), BUT: a consist must be erased in the MX10 memory after receiving a
MESSAGE from the "owner"-controller that the consist no longer exists. The consist will be registered by the MX10 again at any time,
should the controller send the message again.
Preliminary remarks about ending consists in the LoR and ObjDB
In cases in which the LoR or ObjectDB lines are processed with the C or TP key, remain unchanged for the "first development stage"
AND the "second development stage".
If an address that has been assigned to a local consist (T1
…T9), but is NOT THE SECOND LAST ADDRESS of this consist, is deleted
from the LoR (
with the C-key
), it disappears from the LoR but remains in the ObjectDB without consist markers. The MX10 is informed
that
“this address has been removed from the local consist” - the MX10 response to this information depends on the" development lev-
el" (also removed in the MX10 with the "first" and "second" level).
If an address that has been assigned to a local consist (T1
…T9), but is NOT THE SECOND LAST ADDRESS of this consist, is deleted
from the ObjDB (
with the C-key
), it disappears from the LoR and ObjctDB. The MX10 is informed that
“this address has been re-
moved from the local
consist” - the MX10 response to this information depends on the" development level" (also removed in the MX10
with the "first" and "second" level).
If the SECOND LAST ADDRESS of a local consist (T1
…T9) is deleted from the LoR (
with the C-key
), it disappears from the LoR but
remains in the ObjectDB without consist markers. At the same time, the consist number at the last address of this consist in the LoR
and ObjDB is removed; the consist number becomes available again for other consists. The MX10 is informed that both the second
last and the last addresses have been removed from the local consist - the MX10 response to this information depends on the" devel-
opment level" (also removed in the MX10 with the "first" and "second" level).
If the SECOND LAST ADDRESS of a local consist (T1
…T9) is deleted from the ObjectDB (
with the C-key
), it disappears from the LoR
and the ObjectDB. At the same time, the consist number at the last address of this consist in the LoR and ObjDB is removed; the con-
sist number becomes available again for other consists. The MX10 is informed that both the second last and the last addresses have
been removed from the local consist - the MX10 response to this information depends on the" development level" (also removed in the
MX10 with the "first" and "second" level).
If for an address, which is assigned to a local consist (T1
… T9) but is NOT THE SECOND LAST ADDRESS of this consist, the traction
marker is removed in the LoR OR in the ObjDB (
with the TP-key
), the address remains in LoR and ObjctDB, the consist marker how-
ever is removed in LoR AND ObjDB. The MX10 is informed that "this address should be removed from the consist in the MX10".
If for an address, which is assigned to a local consist (T1
… T9) as THE SECOND LAST ADDRESS of this consist, the traction marker is
removed in the LoR OR in the ObjDB (
with the TP-key
), the address remains in LoR and ObjDB. However, the consist number is also
removed from the last consist address in the LoR and ObjDB; the consist number becomes available again for other consists. The
MX10 is informed that "the second last as well as the last address should be removed from the consist in the MX10".
.
The
“First” and “Second Development Level” for Consists:
The MX32 has to send the consist data concerning locally defined consists
(T1… T9) at least every 5 sec to the MX10 command station–
these are those that are stored in the local LoR memory (Note: there are no consists that exist in the ObjctDB, but not in the LoR). If no
such "consist data" arrives at the MX10 for 10 sec, the consist is cleared from the MX10, but the data for the individual vehicles remains
unchanged in the cycle (but not in the special consist packet cycle). That means:
(1) 10 seconds after the controller is disconnected from the CAN bus (or radio communication is interrupted), the MX10 no longer sends
these addresses as a consist (i.e. no longer in the consist mode cycle); when reconnecting (or radio communication is reestablished), the
controller sends the "consist data" again in 5 sec intervals, and the MX10 sends the data out again in the correct consist data package.
(2) if a MX32 message says "this address has been removed from the local consist", then this address will be removed from the consist in
the MX10. To be on the safe side, the MX10 automatically breaks-up the consist if only one address remains.
The
“Third Development Level”
for consists
– with additional MX10 based consists:
Consists now remain in the MX10, even if the relevant controller is temporarily or permanently logged off and even if a message from a
controller arrives that says "this address was removed from the local consist in the controller", BUT NOT when the message says "re-
move this address from the consist in the MX10", which is the case when an address is removed from a consist with the T-key (but not if
the address was deleted with the C key).
So, the MX10 will continue to send out all the addresses involved as consist addresses, in the packet-type cycle for consists, etc.
When a MX32 is attempting to take over one of the participating consist addresses (i.e., trying to activate or assign it to another consist /
train), a prompt-window pops up with the existing MX10 consist, with the option to delete it.
WHAT THIS WILL LOOK LIKE, IS YET TO BE DEFINED.
The Help-File for
Consisting
WILL BE ADDED LADER
