Professional Documents
Culture Documents
Precision Mining Spry Destination Scheduling Documentation 2016
Precision Mining Spry Destination Scheduling Documentation 2016
Destination Scheduling
Destination Scheduling in Spry is a natural extension of Source Scheduling and in this section we will
look at the setup and core concepts of Destination Scheduling. Then we will look at Destination Paths
and Priorities, followed by an extension of Dependencies.
CONCEPTUAL
In the Source Scheduling section we looked at how to set up and run a dig schedule. All of the
concepts addressed including Processes, Equipment, Source Paths and Dependencies carry over to
Destination Scheduling in some way. The documentation for Destination Scheduling makes the
assumption that you are familiar with the basics of Source Scheduling and that you have a Source
Schedule (either from Spry or an Input Schedule) to work from already.
In a simple conceptual sense, Destination Scheduling takes material from a Leaf in your Source Table
and places it in a Leaf in your Destination Table. The amount of material moved is called the
Destination Quantity and is not necessarily the same amount as the related Source Quantity. In
other words, when you work a Source Task you are removing material, when you work a Destination
Task you are filling a space with material.
The primary difference between Destination and Source Scheduling is the way you think about
paths. In Source Scheduling, you are controlling each piece of productive equipment which means
that each Equipment has its own Source Path. Destination Scheduling however is often (but not
always) independent of the Equipment and generally relates to the location of the source (the Leaf).
It can also be dependent on the Process and Date of the schedule as well. That part of a Destination
Path is the filter which is described below.
As each line of the Output Schedule is generated, the first part completed is the Source Schedule. Each partially completed Output Schedule Line is
compared to each Destination Path Filter to see which Destination Task Lists may apply. Destination Task Lists are then (in order of priority) tested to see if
there is an Available Destination Task to work.
Effective use of Destination Paths themselves and Priorities is discussed in the next section.
PRACTICAL
In order to run Destination Scheduling tick on the option in the Scenario Settings tab. Once ticked on
you will need to define the Destination Table, and which field defines the Destination Quantity
(capacity) of each Leaf.
You may wish to set a Default Destination Quantity Field for each Process you are Destination
Scheduling.
Each Process AND Equipment that you wish to use for Destination Scheduling also requires selection.
To create a new Destination Path right click Destination Paths and choose Add -> New Destination
Path. The five options before writing your Destination Path (the actual Path is addressed in the next
section). The first four relate to your Destination Path Filter:
CONCEPTUAL
In the previous section, we looked at the basics of how Spry uses Destination Paths in general. This
section addresses the actual writing of a Destination Path itself.
If youre familiar with writing a Source Path, writing Destination Paths should be quite simple. Not
only are there not any new concepts, there are less options available! If youre not familiar with
writing a Source Path, the recommendation is to read the Conceptual section there first, and then
come back here for the practical.
The next section will address Priorities for Destination Paths and some simple examples on how you
can use them to simplify workflow.
PRACTICAL
Destination paths are both case and white space insensitive and the path can be built up over
multiple lines with each line adding more steps to the path.
This section will build a simple example Path that uses the full variety of options available to you.
THE BASICS
The simplest Destination Path possible is a single wildcard asterisk (*) character which tells
equipment to work logically lowest index to highest (refer to your Destination table Setup Levels)
and all sub levels are completed before moving to the next index.
equipment. In the examples below, case 1 would ensure that elevation 200 is completed filled for all
blocks in strips 15 and 16 before moving on to the next elevation. In case 2, strip 15 would be
completely filled from elevation 200-260 before starting strip 16. The only difference between the
two examples is a slight change in the order that the levels are specified in.
Node order must have the same names as defined in levels on the table it is defined in and is \
separated. Not all levels have to be used, but no level can be used more than once. This will override
the default order set in your Destination Table Fields
PERCENTAGE ( ):
Allows for only a portion of a task to be scheduled (e.g. A\15 (50%) or A\15 (0.5)).
PATH ARRAYS
Introduced in Spry 0.3.0.329, path arrays allow for multiple lines to be combined into a single line
paths. The arrays are specified between {} characters with semi-colons (;) delimiting entries. For
example:
AlphaIP/S1/B1-B3/{300;280;260}-{290;270;250}
AlphaIP/S1/B1-B3/300-290
AlphaIP/S1/B1-B3/280-270
AlphaIP/S1/B1-B3/260-250
The number of items in each array for a path must be the identical. Hovering the mouse over an
arrayed line shows the expanded version of it.
CONCEPTUAL
In Source Scheduling, each Source Path represents an individual piece of Equipment with an ordered, single set of instructions. One major way in which
Destination Paths differ is that they can technically overlap, so at any one point in time you might have multiple instructions for the one piece of
Equipment. When a line of your Output Schedule has more than one Destination Path Filter that applies, the Priority takes over.
Why is that useful? Lets say your preference is to dump in pit. The way the in pit dump is completed occurs in a certain order (In Pit Path #1). But what
happens when you run out of space either with a dependency or constraint? Your backup dump is out of pit and is built up in its own way. You could add
the path for the out of pit dump to the end of In Pit Path #1, but by adding it as a lower priority path (Out Of Pit Path #1) you can compartmentalise the
work. It means that for In Pit Paths #2, #3, #4 etc you dont have to replicate your out of pit path.
PRACTICAL
Each line of the schedule as it is filtered for a Destination Path may have more than one possible option. The options are taken in order of priority. If no task
in the first Priority is available, the next Priority down will be tested, etc. See the screenshot below for an example.
Expands Upon
The Snapshot Viewer - Destination Scheduling adds Destination Tasks to the Snapshot Viewer
CONCEPTUAL
All Dependencies and Constraints (except Process Dependencies) have a sibling that creates
Destination to Destination relationships. In addition to this, both Range and Solid Overlap
Dependencies have Source waits on Destination and Destination waits on Source options. This
allows you to create Dependencies that say "You can't dump in this Destination until these Source
Tasks are finished" using a Range Dependency, or "You can't dump in this Destination Solid until
there is no Source Solid within 25m" using a Solid Overlap.
Capacity and Proximity Constraints can also limit a combination of source and dump location. These
can be used to, for example, ensure that only a certain amount of material goes from one pit to go
to a particular dump (Capacity) or to force two excavators working in the same area to send their
truck fleets to different dump locations (Proximity).
Sequence: Sets Dependencies between different Destinations within a group. Normally used
to create bottom up vertical Dependencies.
Offset: Sets regular dependencies between Destinations based on one or more Offsets.
Commonly used for staggers where there are roughly regular sized Solids/Mining areas.
Range: Sets Dependencies between ranges of Tasks by explicitly defining Predecessor and
Successor pairs. Commonly used in Destination Scheduling to control Dump and Dig toe or to
ensure a particular Destination fill pattern.
Cone: Sets Dependencies based on Centroids in a Cone either above or below the Task in
question. Commonly used for angle of repose/highwall angle enforcement.
Solid Overlap: Sets dependencies where Solids overlap in Plan View based on an Overlap
Percentage. This is commonly used where Destination and Source Solids intersect to ensure
dumping doesnt begin until the space is available or when blast polygons have different
layouts between different benches.
PRACTICAL
Every Dependency and Constraint you would have created up until this point in Source Scheduling
has had a Relationship/Constraint Type that has by default is Source. Make sure you select the
correct one when relating to Destination Scheduling or you might find your options don't make
much sense! If your Expressions and other options don't include references to Destinations this is
normally the issue, pay particular attention when using Offset Constraints!
In larger models for Destination waits on Source and vice versa, it's recommended to use Range
Dependencies when reserves are cut neatly, and Solid Overlap where Range Dependencies are
difficult to implement due to different sizes/locations of the Positions.
Predecessor: Alpha/{1:S1..S12}
Successor: AlphaIP/{1:S1..S12}
If you wanted to maximise the performance of this Dependency you may wish to ensure that only
the final Seam or Process is included in the predecessor
That would mean that SourcePit Alpha would be in the "Al" group, and Destination Dump AlphaIP
would be in the "Al" group as well! Using Grouping Expressions this way can reduce the number of
calculations required to create Solid Overlap Dependencies and therefore reduce Scenario run times.