Although absolute bearing rule sets can simplify the definition of dependencies when the database represents a regular geological block model, there are some inherent disadvantages.

Because the rules are specified relative to a Northerly orientated grid, they are independent of the blocks face advance direction. Different face advance directions will require different rule sets and if the face advance directions change, the successor ranges allocated to each rule sets will require updating.

Although relative bearing dependency rules share many similarities with absolute bearing rules, the predecessors are defined as offsets relative to the blocks face advance direction, rather than North. This overcomes many of the disadvantages associated with absolute bearing rule sets.

When Relative Bearing is selected in the Type list box of a new rule set, a grid is displayed on the right hand side of the schedule set up window that is identical to the grid used with absolute bearing rule sets. However, the grid is orientated so the blocks face advance direction is up the grid. The bearing of the grid will therefore be different for different blocks.

Axis Levels

The schedule set up window has similar controls to those available for absolute bearing rule sets, for selecting the database levels for each axis and specifying the appropriate multiplier.

Three drop-down list boxes are used to specify which database levels should be used to represent coordinates in the X, Y and Z-axes. The entry in each must be unique and in tabular deposits with only one block in the vertical plane, None can be specified for the Z-axis.

Each axis also has a multiplier text box, which is used to specify the increment in APIL numbers between successive blocks in each direction. They have a default value of 1 but this can be edited if the APIL numbering system is not based on the number of whole blocks from a given origin. Negative multipliers can also be entered if the coordinate system does not increase in the standard direction (positive toward the East, the North and upward).

New rule and edit rule

Rules are created and edited in exactly the same way as for Absolute Bearing rules. To create a dependency, select the appropriate block by clicking on it and then press the New Rule button.

Whenever the New Rule button or the Edit Rules button is clicked, the rule table will be displayed. The user must update the offset in the Z direction, if the predecessor block is above or below the successor block.

Set face advance bearing

The most obvious difference between relative bearing and absolute bearing rule sets is the additional Set Face Advance Bearing button, which when clicked causes the Productive Activities window to be displayed as follows.

The face advance bearing should be entered in the Advance Bearing column, and although different values can also be assigned for each activity, they are usually all given the same value.

It is important to note that a blocks face advance direction is quite different to its mining direction / elevation. Mining direction /elevation is the bearing and inclination each activity will be performed in within the block. This is only used when constructing period progress and mine status plots. But the face advance direction refers to the overall direction the face in which the block occurs will advance.

As an example, consider an open cut coal mine that is subdivided into strips that run East-West. A dragline will mine the blocks in each strip along the strip, say toward the West. But the face will advance perpendicular to the strips over time, say in a Northerly direction.

The face advance bearing is normally stored in a field of the main database, allowing each record to have a unique value. To specify which field the face advance bearing should be obtained from, the code of the field should be entered in the Advance Bearing column of the productive activities window or it can be selected from the drop-down list.

When a main database field is used to store the face advance bearing, each record must be assigned an appropriate value, either using an XCM script or by importing appropriate data.

The relative address method supports 8 face advance directions and these should be entered as bearings in degrees. The eight valid face advance directions are shown below along with the bearings that must be used in the database field to represent them. If the bearing does not match one of the eight standard face advance directions allowed, the nearest valid face advance direction will be used.

Successor range

When relative bearing rules are applied to each block in the successor range, the grid is orientated to the blocks face advance direction before the rule is applied. If the face advance directions are changed, the rule set should be re-applied and the dependencies will be automatically re-orientated.

Predecessor filter

Before the rule set creates a dependency, XPAC tests whether the predecessor record occurs within the range specified in the Predecessor Filter list box. If the predecessor record is within the range, the dependency will be created as normal. But if the predecessor record is not in the range, the dependency will not be created. By default the Predecessor Filter range will be set to All, ensuring that every dependency will be created.

Lag

The Lag list box under the grid allows users to assign a delay to each of the dependencies created by the rules in the set. The duration of the delay is specified in calendar days and either a reference to a main database field or an absolute value can be specified. If a main database field is selected, a unique delay can be assigned to each record.

When a lag is assigned to a dependency, the successor will not become available when the rule has been satisfied. This will be delayed by the duration specified in the Lag list box, with the delay beginning the moment the rule is satisfied.

Release profile

The Release Profile list box under the grid allows the user to assign a release profile to the dependencies created by the rule set. A release profile allows the successor record in each dependency to become available for mining as soon as a specified percentage of the predecessor has been mined. Release profiles are described in greater detail later in the chapter.