Content → Command Stations → Protocols

• ZNF Tracking System
• Tracking Monitor
• TrackingService

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.

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

Rocrail and ZNF speak to different dialects as terms are being uses differently.

Note: The ZNF controller should be the last one in the list.

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)

Used as sub station number (UST). Contact the fremo-forum "Signal" https://forum.fremo-net.eu/c/spezial/signal/ in order to obtain your sub station number.
Look up assigned substation numbers.

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: 255.255.255.255:57111
Make sure that UDPBroadcast is not blocked.
Note: No find will be issued in case the Hostname and Port are set.

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.

Determines the direction of newly placed locos in the transfer block (Übergabeblock). Set the hook to place locos in the + direction.

The CTC Display must be set active to the ZNF controller to be able to publish movements to the ZN-Server.

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.

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.

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.

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.

ZNF800 telegram can be sent by using the <tracking /> node within an xml script.

Example:

<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://fremo-stw.sourceforge.net/ZNF800/index.en.html
• https://forum.rocrail.net/viewtopic.php?f=122&t=27615 (Rocrail DE-Forum)

• Rocrail2ZN by Jens Kulenkampff (DE)

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.

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.

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.

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!

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).

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".

Supported Command Stations: add ZNF controller\\

• Note: ZNF is as Protocol library defined.

Details: add ZNF in the display description