Track Node Module

From Planimate Knowledge Base
Jump to: navigation, search

Introduction

An advanced feature of Planimate® has always been its ability to model railways with the Planimate® Tracks feature. As part of the continual improvement process Planimate® Tracks were completely redesigned between version 5.10p and 5.2x. This significant change allows increased interaction and communication between a model's programmed system controls and the Planimate® internal controls and has made the older Track Loop objects obsolete.


Make clear that this is to version 5.2x (current version). Future versions may include newer functionality.


Track Loop objects have now been replaced with the Track Node Module. Track Nodes increase the capability of simulating systems requiring tracks and track loops.


This document is intended for use by those who have mastered the basics of developing Planimate® models and who need to utilise these more advanced features of Planimate® for the purpose of modelling a railway system.


This document is limited to Planimate® features available in version 5.2xx and does not include details of features added or removed after that time.


Purpose

This document together with its referenced sample railway model provides Planimate® modellers with details of how to build and control railway track models using Track Nodes and the available features to communicate with and control the underlying Planimate® track control logic.


Through the use of flow diagrams, screen captures and text, this document provides a detailed description on the internal workings of the demo model.


With the main areas of focus being tracks and track nodes, the information required for understanding, developing and constructing track models is conveyed using a systematic approach.


The demo model endeavours to detail the technical foundations used in the design and construction of the model as well as outline the possibilities for future enhancements. In addition, provide details for using the demo model track nodes as well as sufficient information for further development.


The primary focus of the documentation is to convey the functionality and use of the track node. Terminal nodes are not treated with the same detail however the principles that apply to track nodes may be applied as appropriate by the modeller to terminal nodes.


Demo Model Description

The track demo model represents a simple system consisting of:

  • 1 port
  • 2 mines
  • 3 track nodes
  • and track to connect the locations


General

The system operates by creating 10 items (trains) at the port and routing the trains sequentially to mines A and B.


The following steps define a train cycle (operating plan):

  • assign task and route to train
  • traverse train from Port to selected mine
  • incur time delay at Mine to simulate an activity (eg. load time)
  • traverse train from Mine to Port
  • incur time delay at Port to simulate an activity (eg. unload time)
  • repeat cycle from first step


This system is referred to as a cyclic system and offers several user inputs to change the behaviour of the trains cycles. These include:

  • delay at port
  • delay at mines
  • track section times
  • track type settings
  • track node capacity settings
  • track node behaviour settings

The screen capture below shows the trains traversing over the track whilst cycling as per the operating plan.

Track node model.png

Track Nodes

Track nodes are a self contained module (in a Planimate® portal) used to represent a station, passing loop or junction in a track network. The nodes maintain the capacity set at the location as well as control item movements in conjunction with Planimate® Tracks.


The nodes have been constructed in a generic format to allow for adaptation to a wide variety of models and various geographical layouts.


Track nodes are connected by Planimate® Tracks.


Track Node General

The track node is represented by a Portal object in Planimate®. This portal is used to connect sections of track together and therefore form a communication link between the connected portals.


When an item is destined to traverse a section of track, the item first looks forward to determine if the section and next track node is available. At this point the item does not commit to moving but is merely assessing the situation ahead. This is referred to as a Planimate® lookahead test. In this lookahead test, all decisions and changes to values that would normally take place when the item commits to moving are changed. However, these changes are recorded and reversed once the lookahead thread has completed (in most common use).


As the item lookahead is looking forward, questions are asked of the track sections, track nodes or terminal ends of the system based on the item's route. The question's asked are to determine if the item can be accommodated in available capacity.


For example, an item wanting to depart a track node to proceed forward over the next track section determines if a road in the section can accommodate the item by asking a question in the lookahead test. If yes, the item then continues in the lookahead test to determine if the next capacity point (track node) can accept the item. If undetermined, the tests continue following the item's route until a decision can be made. If a track section, track node or terminal end can not accommodate the item, the lookahead test is stopped and changes are reversed.


Once an item lookahead test passes and the item can proceed, the path ahead (based on the item's route) is committed to. The track node registers the item at each of the track sections, track nodes or terminal ends to prevent any other item from consuming the capacity before the testing item arrives at these objects.


Once registered, the item proceeds to traverse the track and track nodes. Once the item exits a track node, the capacity it occupied is released therefore allowing another item to consume the capacity.


In the event the lookahead test failed and the item can not proceed, the item is registered in the Planimate® Blocked Trains list. This list controls the retesting interval for items. All opportunities whereby a situation may have changed triggers the items in the list to retest and commence the process again.


Track Node Detailed

The following diagram illustrates the design of the track node operation whilst also identifying the 2 layers of operation (lookahead and during move).

Track node design.png

The track node entry is a Planimate® Portal object. It is important to understand that any item wanting to enter into the track node will send in a lookahead thread first. Before any item proceeds forward to the next capacity point, Planimate® sends a lookahead thread to test if the move is possible and if so, allow the item to move replicating its lookahead thread (under most common usage).


When a lookahead thread or move takes place, these are directed to the next Planimate® object.


Once the item has arrived at the Portal object and secondary forward test is performed. This test is referred to as the Portal Entry test. The purpose of the secondary test is to allow Planimate® to register the objects and flow paths to traverse to the next capacity point.


The Track Lookahead Separator (Tlooka) Switch is a Planimate® object that has the mode of the switch set to “Track Lookahead Separator”.


The switch functions by directing the lookahead thread or move to the appropriate connecting flow lines. The following descriptions illustrate the behaviour of the switch mode with the various options available.


Blocking Switch Option (red icon)

Track Lookahead Thread

When a track lookahead thread reaches the switch then the lookahead is directed to the lowest outgoing flow path number connected.


Portal Entry Test

When an item arrives at the track node entry, the Planimate® portal entry test is trigged. The switch responds to this test by directing the test onto the 2nd lowest flow path connected to the object.


Move

When a train arrives at the switch, then the item is directed to the 2nd lowest flow path number connected to the object.


Non-Blocking Switch Option (green icon)

Track Lookahead Thread

When a track lookahead thread reaches the switch then the lookahead is directed to the lowest outgoing flow path number connected. Under this mode, the switch requires 2 track lookahead threads to be performed for operation. The first priming the switch whilst the second takes the path of the primed decision. This requires use of the more advanced routine operation EnabledTrackCheckNext.


Portal Entry Test

When an item arrives at the track node entry, the Planimate® portal entry test is trigged. The switch responds to this test by directing the test onto the 2nd lowest flow path connected to the object.


Move

When a train arrives at the switch, then the item is directed to the 2nd lowest flow path number connected to the object.


The Test Situation Routine evaluates the capacity of the node as well as any further evaluations of connecting nodes if required.


When the lookahead thread enters the routine the following flow diagram illustrates the decision process:

Track node lookahead logic.png


(1) Routine Start


(2) Disables the Planimate® lookahead reversal process. By setting s.DisableUndo attribute to 1, this prevents any changes from being registered until the the attribute is set back to 0 (active). By default Planimate® reverses all changes that take place during the lookahead thread. Once the lookahead thread has completed (reached a Planimate® Object recognised as a capacity point) all changes are reversed back to the original values as per the start of the lookahead thread.


(3) This test identifies whether the item has already been booked into the track node. If so, then the lookahead is marked as allow (next step 23) to notify the item that it can proceed. If not, testing continues on at step 4.


(4) This is a broad test that prevents unnecessary detailed testing in the event all capacity points are occupied. If this condition is not breached then testing continues at step 5. Otherwise the lookahead is blocked at step 24.


(5) Does the item testing have a route? This is determined by testing the item route step (current position in the item route) against the item route step count (total number of steps in the item route).


Note: During lookahead only, an item with a step value greater than the count identifies the item as having no route.


(5.1) Determine if the track node has capacity to cross items.


(5.2) Set the default controlling portal attribute (lookahead_result) value to Refer. Depending on the decisions further into the routine, this result may remain unchanged.


(6) Set the default controlling portal attribute (lookahead_result) value to Allow. Depending on the decisions further into the routine, this result may remain unchanged.


(7) At this point the trk_route_stack table is populated. This table records the previous location details based on where the item came from. The table registers the node model object name and the node configuration index. These details are required for the booking system once a successful result is returned from the Test Situation Routine.


(8) Set the situation_from and situation_to routine attributes. The situation_from attribute stores the value the item came from whilst the situation_to attribute stores the next location in the item's route. These attributes are written to and used for assessing the situation at the track node.


(9) Does the item testing have a route? This is determined by testing the item route step (current position in the item route) against the item route step count (total number of steps in the item route). If an item route exits then proceed with step (10) else jump to step (12).

Note: During lookahead only, an item with a step value greater than the count identifies the item as having no route.


(10) Determine if the track node has been configured to represent Transparent Capacity. If so, then Refer the lookahead on to the next location following the item's route.


Transparent Capacity if active forces the test situation routine to return a lookahead result of Refer. This option allows the user to configure the track node to only allow entry into the node based on the next track nodes situation assessment following the item's route.


This setting is suitable for simulating a situation where a junction node or optional crossing loop is not a capacity point and is connected via more than a single track.

The node requires a capacity setting of at least the maximum number of roads in a track section connected to the node. This is automatically configured during initialisation of the track node. In this situation the Transparent Capacity allows a user to notify the node that it can not stop items at this location.


The behaviour slightly changes in the event a track closure is activated between the time a item books a path forward and traverses the sections. In this event an item will enter the Transparent Capacity track node and wait until the track section becomes available again.


(11) Test to see if the the track node has capacity to hold/cross items. If not then refer the lookahead on to the next node following the item's route. At this point there is no need to test further as the item can not stop at this location and is therefore dependant on the next nodes situation assessment.


(12) Calculate the remaining capacity at the track node.


(13) Determine if only one road remains. If so, then a detailed assessment is required. Otherwise the default lookahead result is engaged.

Track nodes require detailed assessment when only one road remains. In this case it is important to determine if occupying the last road will prevent item traffic from flowing. If more then one road remains then sufficient capacity exists to accept the item. The underlying principle of the tracks logic is to proceed a item to the next capacity point if it can accept the item.


(14) Engage the default lookahead result determined at step 5.2 or 6.


(15 to 18) At this point it is important to conduct a detailed assessment of the committed items at the track node. This is performed by iterating through each of the committed trains and recording the number of trains travelling to the same location as the train testing, from the same location as per the testing train and trains that travel from and to the same location as per the testing item's route.


Once the counts have been established, then the following rules can be applied.


(18 to 22) If the item is terminating at this location then the default lookahead result is engaged. A terminating train is identified by the item attribute i.trk_destination value equalling the model object track node name. Please refer the the item attribute dependencies for a detailed explanation on using the attributes.


If this item is not a terminating train then further rules are applied. In the event a item is detected that is travelling from and to the same location as a item that is already committed to the track node, then Block the lookahead.


This rule prevents an item from occupying capacity at a track node if an item travelling with a similar route steps has been detected. The underlying assumption is that if a train can not or has not yet proceeded then the testing train with similar route steps would encounter the same situation. The track node logic will always leave a remaining road in an alternate direction to allow traffic flow to continue as a general rule. It is possible to overtake trains at junctions if destined to different locations as already committed items.


Any item starting a location its route at the testing track node will Refer the lookahead on to the next testing node based on the item's route. This rules exists to ensure a train being injected into a system doesn't consume the last point of capacity therefore preventing traffic flow.

The assumption in the track logic is that the trains are always dependant on the train ahead proceeding. In the event of a cyclic system flow and the cycle of trains catches the tail, then no train movements are possible. Therefore it is necessary to ensure capacity in the system remains before injecting another train.


In the event a train is ending (not terminating) its route at a node (no route steps beyond the testing track node) then it is assumed that if an already committed train is detected that is travelling from the same location as the testing train, whilst all committed items are destined to the same location, then the testing train would encounter a similar situation as the committed train. Therefore the lookahead is Blocked to prevent the testing item from proceeding.


The lookahead is Referred in the situation where the track node assessment returns a count of trains that identifies more then 1 train either from or to the same connecting node. This is the general rule that governs the track movements if the above rules have not yet caught the situation.


(23 to 25) At this point the lookahead result portal attribute is actioned if it has been set to Allow. Varying values set to p.lookahead_result will result in no actioning and just exiting out of the routine.


(26) The booking system is triggered when a successful situation assessment of the traffic node is returned. The following diagram illustrates the functionality of the booking system from initialisation to operation.

Track node booking logic.png

(27) Enables the Planimate® lookahead reversal process. By setting s.DisableUndo attribute to 0, this reverses registered changes. Any settings beyond this line of code will be reversed during the lookahead undo process.


(28) Set the i.trk_location attribute and exit the routine.

The item attribute will return to its original value (set in the location the item is testing from) as the lookahead reversal process has been activated at step 27.


Modifying Test Situation - Hint

It is important that there is available capacity for the item to consume at the testing track node. If there is not then this may lead to model and/or Planimate® generated error messages as a miscommunication exists between the Track Node Situation assessment logic and the Booking System. The track node caters for this by providing a booking system that functions with the track node situation assessment logic.


The Lookahead Result Switch (Situation) directs the lookahead based on the set portal attribute (p.lookahead_result) into either a portal exit, normal item exit or blocks the lookahead at the switch.


The portal attribute supported value range is as follows:

0 = Block the lookahead

1 = Allow the lookahead

2. = Refer the lookahead


These values are set in the Test Situation Routine and therefore control the action for the item testing. The switch conditions are set to reflect the lookahead actions mentioned and connect the Planimate® objects for the desired action via flow lines.


Portal Exit – Refer Lookahead

Sending the lookahead into a portal exit refers the Planimate® lookahead onto the connected track via the assigned item route and then onto the connected track node. This action can be repeated through many track nodes before a decision is determined.


Exit Object – Allow Lookahead

Sending the Planimate® lookahead into a Exit Object notifies the Planimate® lookahead that the item can reach a point of capacity. The Exit Object is identified as a point of capacity by the internal Planimate® systems. The founding rules that govern item movements ensure that the item can proceed to the next capacity point. As the Exit Object is recognised in such a way, the item is released from its current capacity point.


Block at Switch – Block Lookahead

If the portal attribute (lookahead_result) is set to 0, then this informs the switch that it should block the lookahead attempting to pass through it. At this point the Planimate® systems take control and block the item testing to proceed. Most common usage of the track node will see that the item will be registered in the Planimate® Blocked Trains list for retesting.


The Planimate® Blocked Trains list triggers a lookahead retest for all the trains in the list only when another successful move is committed to or takes place in the entire model. The retesting takes place as this may have changed the situation for the blocked trains. To ensure all trains are retested at the earliest opportunity, Planimate® iterates through the Blocked Trains list testing all the trains in the list. (Located under menu bar item Track > Blocked Trains).


Loop In and Out Delays

The Loop in and out delays can be activated on a portal. This is located with in the portal options.


Once activated, the controls for the loop in and out delays can be found in the Planimate® menu bar item ‘Track’ then ‘Loop Entry Delay’ or ‘Loop Exit Delay’. These values can be set to read from several locations. Eg. Item attributes, tables, portal attributes, etc.


If an item can not pass through a track node in zero time, then Planimate® activates the loop delays. During the loop delay, the section of track the item came into the track node from is unavailable until the item has completed the loop in delay. This is to simulate the item's entry into the track loop during braking.


The actual item holds at the capacity point within the track node until the delays have elapsed.


Once the loop in delay has elapsed, Planimate® tests forward in the item's journey to see if it can proceed. If so the loop out delay commences. During this period the section of track ahead in the item's route is unavailable. This is to simulate an item's speed up whilst exiting a track node.


More advanced loop controls are available upon request from InterDynamics staff.


Track Node Dependencies

The following sections detail the track node dependencies.


Item Attributes

All item attributes have an initial value of zero. No further attribute options are required to be activated.

  • trk_booking_destination (internally controlled)
This attribute stores the location where the lookahead result is successful and booking commences. This attribute is used to determine the value to write for item attribute “trk_node_occupancy_tracker”. If the booking location is not reached, then the “trk_node_occupancy_tracker” is populated with the next locations node occupancy index. Otherwise it is cleared to a default value of 0.
Units Label
Label _Model_Objects


  • trk_booking_destination_reached (internally controlled)
This attribute is used to identify if the item has reached the destination. On entry into the node the trk_booking_destination_reached is set to 1. This happens before arriving at the Planimate® capacity object. When the item tests forward in lookahead and is successful in proceeding, the item attribute trk_node_occupancy_tracker attribute is populated in the Test Situation routine. Therefore when the item proceeds to the #Generic#_Sitn Out routine, there is no need to write the trk_node_occupancy_tracker value as it has already been written. The trk_booking _destination_reached attribute prevents this value from being overwritten at the booking location only.
Units Value
Label -


  • trk_destination (requires setting)
This attribute should be set to the location at which the item's route shall end or turnaround back onto its self. e.g a mine, port or track node if terminating there.
Units Label
Label _Model_Objects


  • trk_ID (requires setting on item creation)
This marks the item ID based on the system item ID value. The system ID is not used as it is possible to reference the wrong ID value when introducing messaged, split or broadcasted items. Note that Planimate® item ids commence from 0, therefore if testing for a valid ID, the user must test for a value greater than or equal to 0.
Units Value
Label -


  • trk_location (requires setting on item injection only)
This attribute marks the location of the item. This is updated on entry into every track node or #Generic#_Sitn In Module.
Units Label
Label _Model_Objects


  • trk_loop_in_delay (requires setting on item creation)
This attribute holds the value of the Loop In delay to be applied.
Units Time HH:MM (no seconds)
Label -


  • trk_loop_out_delay (requires setting on item creation)
This attribute holds the value of the Loop Out delay to be applied.
Units Time HH:MM (no seconds)
Label -


  • trk_node_configuration_index (internally controlled)
This attribute is used to to record the table node configuration index from the previous location. This information is stored in the trk_route_stack table. These values are retrieved when a successful lookahead result is achieved and the booking system is triggered. The booking system requires these values to register the item at track node/s.
Units Value
Label -


  • trk_node_occupancy_position (internally controlled)
This attribute is used to reference the trk_node_occupancy position locally from within the track node. The attribute is written to from the trk_node_occupancy_tracker item attribute on entry into the node. All references to the trk_node_occupancy table use this attribute. This attribute eliminates the need for searching for the written trk_node_occupancy position therefore increasing efficiency.
Units Value
Label -


  • trk_node_occupancy_tracker (internally controlled)
This attribute is used to recall the index to the trk_node_occupancy table when traversing through the node/s (during move). The attribute recalls the index value from the trk_node_occupancy table (column: booked_row_tracker). Each location in the table points to the next locations node occupancy index as per following the item's route. This attribute eliminates the need for searching for the written trk_node_occupancy position therefore increasing efficiency.
Units Value
Label -


  • trk_origin (requires setting)
This attribute should be set to the location at which the item's route shall start its route or injection location e.g. a mine, port or track node if commencing from there.
Units Label
Label _Model_Objects


  • trk_route_stack_step (internally controlled)
This attribute counts the number of track nodes the lookahead has passed through. When a successful lookahead result is achieved, then this value is used by the booking system to register the item at the traversed locations. This attribute is decremented back to 0 during the booking process.
Units Value
Label -


Tables

The following tables are required for the track node to operate. In order for the track node to operate these tables must be constructed as per the definitions below.

  • trk_location_configuration
Column Position 1 2 3
Title Location Additional Roads to Mainline Transparent Capacity
Tuple Name Location Additional Roads to Mainline Transparent Capacity
Units Label Value Label
Labels _Model_Objects - _boolean
Clear Value 0 0 0
This table allows the user to influence the track node decision logic and therefore behaviour.


This table is referenced during model initialisation only. The trk_node_configuration table reads values from this table to determine if the track node being initialised has any additional roads to the main line or transparent capacity active.


By default the track node initialises the capacity to the maximum number of roads in a track section connected to the node. This is required so that all the roads in the track section are usable. A user may add additional roads to the minimum roads required by the track node.


For example, a node that has single lines connected to it without any additional roads would initialise to a capacity of 1 (example 1). This location would only allow for a single train to enter and be dependant on the location beyond that location for entry (following the item's route). The table below represents some further examples of common node settings:
Example Track Type Setting Default Capacity Additional Roads to Mainline Transparent Capacity Overall Capacity
1 Single Track Connection 1 0 False 1**
2 Single Track Connection 1 1 False 2
3 Double Track Connection 2 0 False 2
4 Double Track Connection 2 1 False 3
5 Double Track Connection 2 0 True 2**
** Allows the number of trains to enter as specified in the Overall Capacity but forces trains to test the situation of the location beyond the testing location following the item's route. Under most common use this node will not allow an item to stop at this location. Items may be forced to stop in the event a track closure is activated and therefore the item/s enter the node and not the track beyond the node. This is dependant on track type settings and resource closure programmes.


  • trk_node_configuration
Column Position 1 2 3 4 5 6
Title location loop_capacity situation_current_occ occ_start_row occ_row_pointer transparent_capacity
Tuple Name location loop_capacity situation_current_occ occ_start_row occ_row_pointer transparent_capacity
Units Label Value Value Value Value _boolean
Labels _Model_Objects - - - - -
Clear Value 0 0 0 0 0 0
This table is used internally by the track node to monitor train bookings, cache user inputs and track values for linked list booking system.


The node configuration table stores the details of the following:
    • location – Stores the track node model object name
    • loop_capacity – Store the total number of items that can enter the track node. Note that the node entry logic prevents items from consuming capacity in one direction under most common situations.
    • situation_current_occ – Stores the current number of items committed to or occupying the track node at any time.
    • occ_start_row – Stores the starting position of the assigned trk_node_occupancy rows.
    • occ_row_pointer – Stores the value of the next available trk_node_occupancy row for this track node. This is part of a system that registers the item's trk_node_occupancy index to prevent the need for searching for the written position. This increases the track nodes performance.
    • transparent_capacity – Stores the value set in the trk_location_configuration table under Transparent Capacity. This value is written from the trk_location_configuration table to allow for direct referencing as well as allow for system set values for nodes that are node available in the trk_location_configuration table.


  • trk_node_occupancy
Column Position 1 2 3 4 5
Title trk_id origin destination linked_list_row_pointer booked_row_tracker
Tuple Name trk_id origin destination linked_list_row_pointer booked_row_tracker
Units Value Label Label Value Value
Labels - _Model_Objects _Model_Objects - -
Clear Value -1 0 0 0 0
This table is used internally by the track node to register the train occupancy details and booking linked list system references.


This table dedicates a row for each capacity point for each location. For example, if a location has a capacity point of 2, then 2 rows would be dedicated to this location. The pointers mapping the rows to the location are stored in the trk_node_configuration table.


The details stored in this table are:
    • trk_id – Stores the item id from the item attribute “trk_id”.
    • origin – Stores the item location before the location being booked. If the item is created at the location, then the origin would be set to the location.
    • destination – Stores the item location after the location being booked. If the item is ending its route at the booking location, then the booking location is written.
    • linked_list_row_pointer – Stores the value of the next available row in the table. This is part of a system that identifies the next available row for use to prevent the need to search for an empty row. This increases the track node performance.
    • booked_row_tracker – Stores the trk_node_occupancy index for the location one step ahead in the item's route. This is part of a system that registers the item's trk_node_occupancy index to prevent the need for searching for the written position. This increases the track nodes performance.


  • trk_section_times
Column Position 1 2 3 4 5 6 7 8 9
Title From To Section Name Section Type Out Time Back Time Track 1 Track 2 Track 3
Tuple Name From To Section Name Section Type Out Time Back Time Track 1 Track 2 Track 3
Units Label Label Label Value Time hh:mm Time hh:mm Value Value Value
Labels _Model_Objects _Model_Objects _Model_Objects _Section_Types - - - - -
Clear Value 0 0 0 0 0 0 100 100 100
This table is auto generated by Planimate® if not created by the user. After the auto creation of the table, the developer my change some column details to suit the application. In this case, the table differs slightly to the auto generated type.


  • trk_route_stack
This table is static in size and therefore must contain rows. The number of rows should be set to a value that is equal or greater to the maximum number of route steps contained in a route. By default and as per the demo model, the number of rows is set to 50. This table can be resized by clicking on the Planimate® Table Menu Bar “Table” then “Resize”. A new Row value should be entered followed by clicking or pressing OK.
Column Position 1 2
Title trk_node node_configuration_index
Tuple Name trk_node node_configuration_index
Units Label Value
Labels _Model_Objects -
Clear Value 0 0
This table is used internally by the track node to register the locations the item lookahead has passed through. This table then communicates the registered locations to the booking system that registers each train at each location.


As an item looks forward in lookahead, each location that the item passes through is registered in this table. The track node under test registers the previous step into the table. At this point of registration, an item attribute “trk_route_stack_step” is incremented to record the number of steps the lookahead has passed through. Once a successful lookahead result is reached, then he booking system iterates through the route steps booking each location.


This table only reads the number of values based on the number of steps registered in the item attribute “trk_route_stack_step”. Values beyond this value if not at the end of the table are ignored.


Note: The changes performed in lookahead are maintained and not reversed by default due to the s.DisableUndo routine operation set in the Test Situation routine. This attribute disables the lookahead reversal functionality.


It is important to reset these values before commencing a new forward lookahead test. This is performed in the #Generic#_Sitn Out module by default.