User Tools

Site Tools


analyzer-en

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

analyzer-en [2018/11/12 08:56] (current)
Line 1: Line 1:
 +====== Track plan Analyser ======
 +[[:​english#​rocrail|{{ ​ :​server.png}}]][[:​english|{{ ​ :​rocrail-logo-32.png}}]]
 +[[:english | Content ]] -> [[:​english#​rocrail|Rocrail Server]]\\
 +  * **[[analyzer-en|Track plan analyser]]**
 +    * [[rocrailini-analyser-en|Rocrail setup dialog]]
 +
 +
 +\\
 +{{:​schaakbord.png?​200}}
 +
 + \\
 +
 +
 +=====Important change=====
 +^Analyzer Route name changed^
 +|:!: From Rev. 12.859+ is the "​**autogen-**"​-prefix (see below) by the option __**[[route-gen-en#​automatically_generated|Automatically generated]]**__ replaced. \\ For routes, which still contain the leading "​autogen",​ this will be removed during the next analyzer run and replaced by the new option. \\ In addition, "​Generated by the analyzer"​ is entered in the '​Description'​ field. \\ In the dialog __**[[route-index-en|Route:​ General]]**__ a leading "** * **" in the "​Description"​ column shows the activated option '​Automatically generated'​. \\ In the examples down on this page the changes did executed. |
 +
 + \\
 +
 +===== Features =====
 +  * Analyse the track plan and create all possible routes automatically. ​
 +  * Sets the **routes** field in all track, signal and sensor objects -> route representation {{SpDrS60-track-route.png}} (**[[rocrailini-analyser-en|optional]]**).
 +  * Sets the **block** field in all track, signal and feedback objects for block occupancy display -> block representation {{SpDrS60-track-occ.png}} (**[[rocrailini-analyser-en|optional]]**).
 +  * The **[[#​direction_tracks|direction track]]** can be used to restrict a route generation only in that direction.
 +  * With **[[#​connector|connectors]]** routes across other objects, empty fields and track plan levels can be created.
 +  * Turnout commands are added to the route.
 +  * Signal pair assignment to **[[block-signals-en|block (signals)]]** as plus(+)- and minus(-)-side signals (**[[rocrailini-analyser-en|optional]]**).
 +  * Enter- and In- sensor assignment to **[[block-routes-de|block (routes)]]** (**[[rocrailini-analyser-en|optional]]**).
 +  * Module support. ​
 +  * Fiddle Yard support.
 + \\
 +
 +==Note:==
 +The Analyser was introduced as a tool especially for the new and inexperienced user allowing for quick access to fully automated model railroading. \\ 
 +However, with complex or unusual layouts the Analyser may fail to generate all routes possible or it may generate unexpected routes or in worst case it may even hang. \\ 
 +In all these cases settings have to be adjusted or completed by hand while those routes generated correctly by the Analyser can serve as a blueprint. \\
 +See also **[[analyzer-en#​Limitations|section Limitations]]**
 + 
 + \\
 +
 +===== Operation =====
 +
 +==== Requirements ==== 
 +  - Track plan must be __**[[planhealth-en|healthy]]**__ before analysing!
 +  - All items must be connected without a space in between them. Exception: The [[#​connector|Connector]]
 +  - Only one item at one position in the plan is allowed. (**No overlapping.**) ​
 +  - The analyser is based on the symbol sizes found in the default **[[:​symbols-themes-spdr60-en|SpDrS60]]** theme. (See also **[[symbols-theme-props-en#​basics|themes basics]]**)
 + \\
 +
 +==== Activation ====
 +The Analyser can be activated manually.
 +
 +The feature is started manually by
 +  * either entering **z** in the Rocrail server terminal if the **-console** option is active
 +  * or by selecting **[[rocgui-menu-en#​file|Analyse]]** from the File menu of Rocview. ​
 +
 + \\
 +
 +==== Clean up====
 +If the analyzer is re-started after changes to the track plan, all routes with the option "​automatically generated"​ are deleted.
 +This ensures that no invalidated routes are included in the plan before routes are created or recreated.
 +The option "​automatically generated"​ must be activated for all routes so the changes can be implemented.
 +Manually-added routes with no auto-created option remain unchanged in the list.\\
 +
 + ​\\ ​
 +
 +==== Sensor and Signal Configuration ====
 +|  {{  :​analyzer:​analyser-bk-fb-sg.png?​750}} ​ |
 +|  The graphic shows the positioning of feedback sensors (// fb //) and Distant- (// sgv //) and Main (// sgh //) signals for a block (// bk //). \\ The sensors and signals are thus correctly assigned to the block and the routes of both sides of the block. \\ On both sides of the block, the sensors and signals must be positioned between the block and the next turnout (// sw //). \\ The order of objects between block and turnout is arbitrary. ​ |
 +| :!: The signals - as shown - __must__ be aligned with the "//​symbol in the direction of travel to the right of the track//"​. (//​Exception,​ for example: __**[[:​symbols-themes-sbblsignals-en|SBB-L signals]]**__)//​ |
 +| :!: If the route between two blocks __ does not contain a turnout__, then signals could be assigned to the wrong block. |
 +\\
 +=== Sensors ===
 +The sensors are assigned to the routes __all enter +__ and __all enter -__, respectively. \\ The __all enter +__ route is for all routes entering the + side of the block (marked with the little + in the block). \\ The __all enter -__ route accordingly is used for all routes entering the - side of the block. \\
 +Sensors have to be assigned to the routes on the routes tab of **[[block-routes-en|Block:​ Routes]]** in the block properties. \\
 +**Note:**\\
 +The assignment by the analyzer works only when using "​enter"​ and "​in"​ sensors. \\ 
 +In addition, place only one sensor on each side between the block and the next switch. \\ 
 +For blocks with one, three or four sensors there are no usable items. \\ 
 +With more than one sensor on a block side, only the sensor nearest the block will be considered.\\
 +=== Signals ===
 +The distant signal associated with a main signal of a block must be positioned on the opposite side of the block.\\
 +The assignment is visible on the tab **[[block-signals-en|Block:​ Signal]]** and can be changed manually, if necessary.\\
 +\\
 +
 +==== Direction Tracks ====
 +Direction tracks (s. also **[[:​tracks-gen-en#​type|Types of Tracks]]**) can be used to restrict the routes generated by the analyser to one particular direction. For this purpose the direction track is placed between one or more blocks:
 +^ Example ^ Description ^ Routes generated by the analyser ^
 +| {{:​analyzer:​dir-no.png}} | Two blocks connected by tracks | From A to B __and__ from B to A |
 +| {{:​analyzer:​dir-all.png}} | Two blocks with a track indicating both directions in between | Same as above; the track for both directions is descriptive only but has no function |
 +| {{:​analyzer:​dir-right.png}} | Two blocks with a direction track in between, arrow pointing to the right | __Only__ from A to B |
 +| {{:​analyzer:​dir-left.png}} | Two blocks with a direction track in between, arrow pointing to the left | __Only__ from B to A |
 +| {{:​analyzer:​dir-no1.png}} | Branch without direction tracks | A to B, A to C, B to A and C to A |
 +| {{:​analyzer:​dir-right1.png}} | Direction track within a branch | A to B, A to C and B to A |
 +| {{:​analyzer:​dir-right2.png}} | Direction track in front of a branch | A to B and A to C |
 +{{  :​symbols:​no-route.png}}
 + \\
 +**Tip:** If there is no route to be created in a track section in both directions, this can be achieved by two opposite direction track symbols, or for the time of analyzer activity, a track symbol is removed from the section.
 +
 + \\
 +
 +==== Connector ===
 +Connectors can be used to connect distant elements: The analyser is seeking for a counterpart (second connector) in the same direction and ignores gaps and elements between these two.\\ ​
 +
 +^ Examples for connectors \\ Avoiding track elements without function ^^
 +| {{:​analyzer:​verbinder.png?​800}} ​ ||
 +| \\ ||
 +^ Connectors illustrating a bridge ^^
 +|  {{:​analyzer:​bridge.png}} \\ {{:​analyzer:​bridge-connector-example.png}} ​ |  {{:​analyzer:​bridge-crossing-example.png}} ​ |
 +|  Bridge with two connectors \\ Top with track type "​connector"​ \\ Below with track type "​tracknr"​ = **2**  |  Bridge with one symbol of track type "​tracknr"​ = **3** \\ Thus the analyzer is able to recognize and generate the possible routes A- < > B+ und C- < > D+  |
 +\\
 +  * The maximum distance between corresponding connectors is unlimited \\
 +  * Connectors on the same track plan level where the orientation is in the way shown in the above example and the connectors face each other are handled as counterparts (Exception below)\\
 +  * Connectors configured with **[[tracks-gen-en#​number|a track number]]** between 10 and 99 must have one corresponding connector with the same track number anywhere in the plan. The direction of the counterpart doesn'​t matter. The counterpart may be on a different track plan level.\\
 + \\
 +
 +==== Avoid connectors on module plans ====
 +With module plans, connectors can be used at the module transitions when paired \\
 +  * with **any** (also different) number in the range **0 - 9** opposite each other..
 +or\\
 +  * are defined with **the same** number in the range **10 - 99**.
 +
 +**Disadvantages:​**\\
 +If a connector with a number in the range **0 - 9** has no partner at the transition, no other connector without partner may face in the direction up to the module plan edge. \\
 +Connectors at the module transition without a partner with the same number in the range **10 - 99** the analyzer reports as error. \\
 +If the module layout is set up in a different compilation,​ affected connector pairs with numbers in the range **10 - 99** must be adapted. \\
 +If in the compilation two connectors with the same number in the range **10 - 99** are forgotten somewhere, "​strange"​ routes can arise.
 +
 +**Recommendation:​**\\
 +To the mentioned disadvantages - among others: Errors, high effort for changes, etc. - it is recommended to avoid connectors at the module transitions. \\
 +Instead of the connectors, "​straight track elements"​ {{: spdrs60-track-norm.png}} should be positioned so that they match each other without interruption when compiling the modules. \\
 +This results in the perspective of the analyzer continuous track connections from which routes can be easily generated.
 +
 +With this method, all the disadvantages with connectors at module transitions are eliminated in a very simple way.
 +\\
 +| On Module transitions use straight track elements :!:  |
 +|  {{:​modules:​no-connector.png?​200}} ​ |
 +\\
 +
 +===== Limitations =====
 +  * The analyser ist not perfect, errors can occur.
 +  * Not all '​weird'​ situations are recognized. ​
 +  * The analyser configures sensors (feedbacks) only after the option "​Assign sensors to blocks"​ in **[[rocrailini-analyser-en##​assign_feedbacks_to_blocks|Sensors in blocks]]** has been enabled (by default this option is off).
 +  * If "​Assign feedbacks to blocks"​ is activated, the analyser tries only to allocate the sensors **enter** and / or **in** in generic routes that are not yet fully generated (whether manually configured by the user or already existed from previous analyzes). \\ **Note:** Previously configured **enter** and / or **in** sensors are maintained and the analyser does not change them (even if they were completely wrong).
 +
 +  * The above applies only to the closest (there are exceptions in special situations) sensors near a block that are unique to this block.
 +  * If a configured **enter2in** is found in a block, then no change is made to this block.
 +  * An **enter2in** sensor is never assigned (or deleted) by the analyser.
 +  * Roads are not supported.
 +  * Only a few objects of the **[[switch-gen-en#​accessory|Switch type "​Accessory"​]]** and the **[[tracks-gen-en#​type|Track typ "​tracknr"​]]** are recognized:
 +\\
 +^Switch Type "​Accessory"​^^
 +^Accessory#​^Description^
 +|  1  | double track railroad crossing, obsolete |
 +|  10  | single track railroad crossing, ungated| ​
 +|  11  | single track railroad crossing, one side barrier | 
 +|  12  | single track railroad crossing, double sided barriers ​ | 
 +|  40  | double track flap bridge |
 +|  41  | single track flap bridge |
 +| ||
 +^Track Typ "​tracknr"​^^
 +^Number^Description^
 +|  2  | bridge connector |
 +|  3  | bridge crossing |
 +\\
 +Other accessory or track numbers are __not supported__ . It doesn'​t know the various grid sizes and orientations of these symbols. Therefore, before starting the analyser these objects should be replaced __temporarily__ (and possibly later again) with normal track objects. \\
 +> **Note:** Do not use two or more double track items consecutively. The Analyser will generate some wrong routes :!:
 +
 + \\
 +
 +===== Example =====
 +{{:​analyzer:​demo-plan.png?​500}}\\
 +{{:​analyzer:​demo-plan.zip}}\\
 +
 +==== Generated Routes ====
 +<code xml>
 +<​stlist>​
 +  <st id="​[01+]-[02+]"​ generated="​true"​ bka="​01"​ bkb="​02"​ bkaside="​true"​ bkbside="​true"​ show="​false"​ x="​0"​ y="​0">​
 +    <swcmd id="​sw1"​ cmd="​straight"/>​
 +  </st>
 +  <st id="​[01+]-[03+]"​ generated="​true"​ bka="​01"​ bkb="​03"​ bkaside="​true"​ bkbside="​true"​ show="​false"​ x="​0"​ y="​0">​
 +    <swcmd id="​sw1"​ cmd="​turnout"/>​
 +  </st>
 +  <st id="​[04+]-[01-]"​ generated="​true"​ bka="​04"​ bkb="​01"​ bkaside="​true"​ bkbside="​false"​ show="​false"​ x="​0"​ y="​0"/>​
 +  <st id="​[02-]-[04-]"​ generated="​true"​ bka="​02"​ bkb="​04"​ bkaside="​false"​ bkbside="​false"​ show="​false"​ x="​0"​ y="​0">​
 +    <swcmd id="​sw2"​ cmd="​straight"/>​
 +  </st>
 +  <st id="​[03-]-[04-]"​ generated="​true"​ bka="​03"​ bkb="​04"​ bkaside="​false"​ bkbside="​false"​ show="​false"​ x="​0"​ y="​0">​
 +    <swcmd id="​sw2"​ cmd="​turnout"/>​
 +  </st>
 +</​stlist>​
 +</​code>​
 +** Note: ** The previously used prefix **autogen-** is replaced by the parameter **''​generated = "​true"''​** in the route record((See **[[#​important_change|Important change]]** at the top of this page.))
 +
 +===== Tips and Tricks =====
 +==== Keep Routes ====
 +Q: Why is analyser always overwriting or removing my changes?\\
 +A: At first the analyser __deletes all__ routes with the activated option '​Automatically generated'​.\\
 +\\
 +Q: How can I prevent analyser to recreate a route?\\
 +A: By deactivating the option '​Automatically generated'​ (-> no deletion -> no recreating)\\
 +\\
 +
 +==== Alternative Routes ====
 +Preventing alternative routes from A- to B+ (avoid changing tracks)
 +
 +{{:​analyzer:​alt_route_ab.png}} \\
 +- Before:
 +  * "​[A-]-[B+]"​ (direct route)
 +  * "​[A-]-[B+]-42"​ (alternative route using side track)
 +- Manual actions:
 +  * deactivating the option '​Automatically generated'​ of "​[A-]-[B+]"​
 +  * delete/​remove "​[A-]-[B+]-42"​
 +- After:
 +  * calling analyser will leave "​[A-]-[B+]"​ untouched (the option '​Automatically generated'​ is deactivated) and will not create any alternative route from [A-] to [B+], because there is already a "​manually configured"​ route for this relation.
 +\\
 +
 +==== Messages in the server log ====
 +
 +- ''​ANALYSER:​ max. recursion depth (101 > 100) reached''​
 +  * On search for routes between 2 blocks more than 100 track diagram elements were found \\ **[[http://​forum.rocrail.net/​viewtopic.php?​p=89410#​p89410|Look at this thread in the german forum]]**
 +  => Please follow the **[[goldenrules-en|Best practice]]**
  
analyzer-en.txt ยท Last modified: 2018/11/12 08:56 (external edit)