Table of Contents
ZNF: FREMO Tracking System
The FREMO train number notification system (ZNF) is used to simplify operations and communication between the operating units. The train number is passed on from one ZNF track field to the next. This is done by means of telegrams that are distributed to all signal boxes via a server.
The most important task of the ZNF is to inform: namely when which train is where.
The goal is to design the communication between ZNF and Rocrail in such a way that. 1) the systems communicate with each other and behave compatibly in the different operating situations. 2) create a Rocrail implementation that allows less experienced Rocrail users to operate their station within a FREMO-ZNF arrangement with Rocrail.
The function of the ZNF is represented compatibly in Rocrail with an architecture that differs from the prototype. The communication is done according to the "Spezifikation Implementierung einer Zugnummern- Meldeanlage für eine FREMO-Betriebsstelle, Bodo Mertins, 17.11.2013." This also describes the basic structure and function of a ZNF in more detail.
Interaction between ZNF and RR
The equivalent of the ZNF track field is the Rocrail block - both describe the location of a train. Each ZNF field has a Track Field Identification Number (GBNR) which, when combined with the Substation Number (UST), provides the unique address of each field. However, the GBNR is limited to six numeric characters, unlike the Rocrail Block Id. Therefore, the GBNR is stored in a different block attribute, namely the trackingID. The trackingID is thus composed of the two-digit substation number and the four-digit track field number, including leading zeros if necessary. For example, track 1 in UST 15 gets the trackingID 150001. Blocks without trackingID do not send telegrams to the ZNF server. So ZNF track field number = RR block trackingID
The blocks at the transition to another interlocking district have a special function. Through these transition blocks trains can enter and leave the RR area from another interlocking district. Only there trains can be assigned and generated by the ZNF also in RR blocks. Transfer blocks also have a block transferID number in addition to the trackingID. It follows the same nomenclature as the trackingID and can, but does not have to be identical. So transfer blocks with transferID only at the very border of the interlocking district.
ZNF does not take over any train protection tasks. Routing, route selection, route interlocking, train protection, etc. are not handled by the ZNF, but exclusively by the local interlocking in whose area the train is currently located. The train number is passed on from one track field to another if certain conditions are met. Nevertheless, according to the ZNF, changes to the train number are possible from the outside, for example if a train was accidentally dispatched with a wrong number. Therefore, the train number must be a secondary property so that RR auto mode continues to work.
Unlike ZNF, Rocrail also handles block-to-block routing in a plan that can be operated with auto mode. Therefore, in Rocrail it is clear from the beginning which train is in which block and the message to ZNF can be directly linked to the train movements.
Even if trains with train numbers are available as objects in Rocrail, they have other tasks and run in RR according to the timetable. Therefore the ZNF train number is a secondary property of a locomotive. The shortID (%lcshortid%) is used for this purpose. The shortID must not contain leading zeros and is for use with ZNF a maximum of 5 digits and purely numeric. So ZNF train number = RR lok shortID.
A locomotive moving in automatic or semi-automatic mode in an RR interlocking district informs the ZNF server about the locomotive movements by means of a transmitted telegram. Thereby status changes of the blocks or changes in the occupancy of the blocks are used as triggers to send ZNF telegrams. This part is called RR2ZNF.
So that a block can inform the ZNF server about the allocation, block must get an entry in the tab Wiring CTC / Interface ID and Display, in addition the trackingID and if necessary a transferID. The trackingID is used as address for sending, the transferID processes received telegrams. Only train movements are reported. Blocks that are only used for shunting do not get a trackingID. A (shunting) locomotive that only moves within the interlocking district does not need a shortID.
A train entering the transfer block to the RR interlocking district from outside is reported by telegram 05, 06 and/or 02. The reported train number is searched for as a shortID in the locomotive list and the matching locomotive is placed in the transfer block. If no suitable shortID is available, a new locomotive is generated.
Sometimes an error number must be generated, for example if a non-reported train appears in a transfer block (ghost message). The error number syntax is FuuNN F = leading "F uu = two digit UST NN = contiously increasing two digit number, re-start with 00 after reaching 99 i.e shortID = F1501
glossary translation table
Rocrail and ZNF speak to different dialects as terms are being uses differently.
|A block is a position where a train may stop. A block may only be occupied by one train at a time.
|The unique ID of a block in the ZNF system. It is composed by the two digit UST and the 6 digit number.
|The most generic object to represent a train in Rocrail is a loco.
|The train number is stored as a secondary value of the loco, the shortID.
|The system to track the position of the train across the layout and to hand over trains from one interlocking district to another.
|transfer block / Übergabeblock
|A block that is displayed on two interlocking systems to hand over trains. Typically a stretch of branch line. Transfer blocks are the only blocks to exectute inbound ZNF telegramm into RR actions (exception 21,30).
|A message sent via the ZNF system to inform other stations on train positions and changes.
|A loco in automode has a set destination block and will be routed along the interlocking district towards that block. In a pure RR environment, also the speed commands are sent to the loco in automode. As on a FREMO meeting the loco driving command system is completely separated, these commands are simply not used. RR users know the driver controlled operation as half automatic. On a FREMO meeting, it is not necessary to put locos in half automatic mode but automatic mode will do.
Login 'Station Name' in the ZN-Server. (Bahnhofsname)
At the right side of the Interface ID field is used as station acronym at ZN-Server login. (Bahnhofskürzel)
If UDPBroadcast is not possible the ZN-Server IP:Port can be set statically.
The Port seems to be 50100 per default.
Enables tracking events to Rocrail clients.
See: Tracking Monitor
Enables the local ZN-Server.
To be able to find the ZN-Server an UDPBroadcast packet is send to the following IP:Port address:
Make sure that UDPBroadcast is not blocked.
Note: No find will be issued in case the Hostname and Port are set.
Tracking & Transfer ID
This ID is used to publish movements to the ZN-Server. The first two digits of the trackingID contain the substation number (UST).
This ID is used for incoming ZN-Server telegrams. The first two digits of the transferID contain the substation number (UST) of the neighbouring district.
The transferID is usally set to the branch line field number of the neighboring station and hence modified according to the meeting layout. The transfer ID shall only be set in transfer blocks (Übergabeblock) at the border of the district.
+ Block enter side
Determines the direction of newly placed locos in the transfer block (Übergabeblock). Set the hook to place locos in the + direction.
The ZNF Controller IID.
Must be set greater than zero te be active.
The locomotive Short ID.
Note: Leading zeros in the Short ID should be avoided.
Supported Telegram Types
Rocrail to ZN (sent telegrams)
The current shortID of the locomotive is always used in the telegram. Only blocks with trackingID send ZNF telegrams. For events that are triggered in response to an incoming ZNF telegram, no telegram is sent in response.
|ZNF telegram type sent
|Additional Rocrail actions
|A loco reaches the next block, in-event triggered by sensor (block red)
|Regular information to ZNF when a loco continues it‘s journey and reaches the next block. Triggers ZNF Gleisfeld or ZNF Spiegelfeld with matching IDs.
|In (only blocks with transfer ID)
|A loco reaches an transfer block.in-event triggered by sensor (block red).
|Create shortID if not set. Set shortID=Fehlernummer if shortID not set
|A loco is leaving the RR district. Assign Fehlernummer if no shortID set. Triggers ZNF Gleisfeld or ZNF Spiegelfeld with matching IDs.
|Ghost-Train in transfer block. See Telegram 10.
|a route is set for a loco to the next block. The block is reserved (block yellow)
|Announcement to ZNF that a loco is underway to next block. Triggers ZNF Vormeldefelder with matching ID only.
|Loco is entering the next block, enter event is fired by sensor (block blue)
|Announcement to ZNF that a loco is entering next block. Triggers ZNF Vormeldefelder with matching ID only.
|Set block occ
|A loco is newly set
|A train is starting in the RR district.
|Block free → closed
|A block is put out of operation. VH=00000 (gesperrt)
|Announce close of block.
|Block Occupied → closed
|A block turns to closed after train has left. VH=00000 (gesperrt)
|Announce close of block.
|Block Free → ghost (only trackingID set)
|A ghost train appears. VH 0F0F0 (belegt ohne Zugnummer)
|Annouce close of block.
|Block closed→ open
|A block is put into operation
|A block was closed and is now opened again.
|A GHOST disappeared or is reset by user.
|Announcement of track availability.
|Block ghost → closed
|A GHOST disappeared or is reset by user in a closed block. VH 00000 (nicht verfügbar)
|Chance block from "occupied by unknown train" to "not availabe"
|Reset block occ
|A loco2block assignment is reset
|A train is ending in the RR district.
|Reset Replace block occ
|A loco is placed in an occupied block and replaces former block assignment.
|A loco continues as another train, i.e. change of direction.
|Loco shortID changed
|The value of shortID is changed by user
|Correct wrong number, ie. Fehlernummer.
|Offer train to next station
|Accept train from next station.
|Deny train from next station.
|Sign up on ZNF server
ZN to Rocrail (recieved telegrams)
There there are ZNF telegrams, which contain only train number(s) and are independent of the block.
These are type 21 "Delete train number" and type 30 "Train number replace". For shortID=train number will be found in the locomotive list and the change is made only (!) on the shortID. If the train number is not found in the shortIDs, nothing happens.
Only blocks with transfer ID will listen to ZNF Telgrams and execute events.
|Telegram type recieved
|Action in RR
|Query shortID shortID = null
|Delete train number
|For compatibility only.
|Query shortID shortID = new train number
|Replace train number
|Train has startet with wrong number, i.e. Fehlernummer or because of human error.
All other incoming telegrams are only handled in the transfer blocks only at the edge of the interlocking district. The transfer blocks have a transferID set. Changes to the block assignment are only accepted if there is no locomotive in auto mode in it.
|Telegram type recieved
|Action in RR
|Loco is set into transfer block.
|If block is allready reserved or enter by previous telegram 05 or 06, fire enter2In-Event. Else create loco if shortID non existent in loclist and set block assignment
|A train is entering the RR district.
|02 with trackingID from different district
|A loco is removed from any transfer block
|Iterate lclist for %lcshortid%. Reset found loco from block
|A train has left the RR district and is reported to have arrived neighboring district / has left transfer block
|A Loco with Fehlernummer is created and set into transfer block.
|Create loco with shortID=Fehlernummer and set block assignment. Treat like 02 with Fxxx train
|A train carrying a Fehlernummer is entering the RR district.
|A train enteres the transfer block (Übergabeblock) while the block is occupied with other train
|An transfer block is reserved for loco.
|Create loco if shortID not existent. Reserve Block for Loco
|A train is being pre-announced to enter the RR district.
|Transfer block is entered by loco.
|Fire enter-Event in transfer block
|A pre-announced train is underway into RR district.
|10 with train number
|Loco is set into transfer block.
|Create loco if shortID non existent in loclist. Set block assignment
|A train is entering the RR district.
|10 with Verfügbarkeitshinweis 00000 oder 0F0F0
|Close transfer block
|Put transfer block out of operation
|transfer block is blocked/not available announcement by other station.
|10 with Verfügbarkeitshinweis FFFFF
|Transfer block is not available for electical traction.
|20 with Verfügbarkeitshinweis FFFFF
|Transfer block is available for electical traction.
|20 with Verfügbarkeitshinweis 00000 oder 0F0F0
|Re-open previsouly closed transfer block
|Put transfer block into operation.
|Transfer block has been closed and con now be re-opened.
|Remove train number
|Train is offered by next station.
|Train is accepted by next station.
|Train is accepted by next station.
ZNF800 telegram can be sent by using the <tracking /> node within an xml script.
<tracking iid="Amsterdam-CS" cmd="10" id="4711" dir=" " location="42" currblock="430100"/>
sends a telegram 4210 4711430100<cr><lf> to the ZNF800 server.
The block action state: "tracking".
- https://forum.rocrail.net/viewtopic.php?f=122&t=27615 (Rocrail DE-Forum)
Using the monitor to track telegrams
For debugging and tracking the ZNF telegrams, a Tracking Monitor is available under control → tracking.
This is the telegram sequence for an inbound train from district 98 to 96 with shortID 1234.
Every block needs to have multiple entries in order to interact with ZNF:
- trackingID (mandatory) - is used as identification for publishing train movements to the ZNF server (outbound)
- display: interface (mandatory) - must be set to the interface ID your ZNF controller uses
- display: number(mandatory) - must be set to something greater than 0
- display: text (mandatory) - must be set to %lcshortid%
- transferID (optional) - is used to hand over incoming trains from another district. Set to the trackingID of the neighbouring stations transfer block
Every loco needs to have a shortID (max 5 numbers) set.
Step by Step from a standard rocrail plan to a ZNF enabled interlocking
Precondition is a working and healthy Rocrail plan. The Plan muss be able to run trains in automatic or, more precisely in half-automatic mode. Most importantly, blocks, connecting routes and sensors need to be defined and assigned. If you don't have physical sensors in your layout, you can allways activate them manually in your Rocrail plan.
Step 1: Define the interface
open up the Rocrail properties and define a new controller type ZNF.
Enter InterfaceID and Station Abrreviation. Get in touch with the FREMO Signal forum and aquire a substation number (UST) to be entered. Typically, Hostname can be left empty and ZN-Server unhooked.
Step 2: Identify blocks with train movements and enter ZNF tracking details
Tracking should be enabled whereever trains move. Note that shunting operations do not need to be tracked. Siding tracks and blocks that are designated for shunting purposes only do not need to be tracked.
In each block definition, go to the wiring tab and enter values for the CTC interfaceID / display nr / text. This enables publishing of train movements as such to the "display" ZNF. Just think of the ZNF of a big CTC table with a lot of train number fields.
The values in the Tracking box define the adress of that display field. Enter an unique trackingID for each block. The trackingID is composed of the own substation number followed by the 5 digit track number with leading zeros. Track 1 in the substation 96 would hence get the trackingID 9600001.
repeat entering details for every block!
Step 3: Identify transfer blocks and enter transferID
The transfer blocks lie on the very border of your interlocking district. A transfer block is usually a stretch of branch line connecting two stations. These stretches are modelled in both adjacent interlocking systems, on each side with it's own trackingID. Trains present in a transfer block are hence visible in both stations and are usually being handed over from one district to another. To enable the handover, you just have to enter the trackingID of your neighbours block into the transferID of your block.
So if the neighbour had the substation number 98 and the branch line was called 0400 on his system, you enter 980400 into the transferID of your transfer block.
As layouts change from FREMO-meeting to meeting and hence the neighbours change, you will have to adjust the transferID in preparation of the meeting. Note that it's possible to agree on one single ID for that block. In this case, the ID needs to be entered both in trackingID and transferID the same.
make sure to enter transferIDs in all of your transfer blocks Transfer blocks are the only blocks that execute RR actions in response for a ZNF telegram. In example, a loco will be (created and) set in transfer block with a 02 type telegram arriving for that block. To avoid interference, resulting actions are blocked if the block is allready occupied with a loco that has targets and a route set (running in automode).
Step 4: Enter Loco shortID
If you have any loco listed in your loco list you need to add a shortID in order to be announced the locos movements to the ZNF system.
Locos without a shortID will not be tracked until they reach a transfer block and only then automatically retrieve a shortID with error number from the System.
You can but you do not need to have a loco pre-defined for every train entering the district. A loco entering the district will automatically be created if the shortID is not yet present in the loco list. However, it might be beneficial to pre-define the trains as you can add additional information in the locID. For example, the train "901" entering the district could be presented as "EC901" if the shortID was pre-defined with "901".