Schedule Editor

Overview#

The Schedule Editor provides a powerful, flexible and modern interface to support the creation of schedules.

The Schedule Editor shows a list of the schedules on the left hand side of the editor. The Main pane of the editor is used to edit schedules. Note that above the list of schedules there are buttons which can be used to add new and delete existing schedules as shown here.

Directly above the list of schedule names is a filter textbox. The filter can be used with the wildcard * to filter the list of schedule names shown, as in the following screenshot.

A schedule can be opened for editing by double clicking it. Additionally a context menu is shown when a right mouse button click is performed on the schedule list. This is shown in the following screen shot.

The “right click” context menu allows the user to:

• Create a new schedule
• Delete a schedule
• Rename a schedule (Note that references to renamed schedules are updated automatically)
• Create a copy of an existing schedule with a new name

Note that the right hand (or main) pane shows the schedule operation sequence at the top and a single schedule operation data editor at the bottom. Each operation in the sequence contains a summary description along with an icon relevant for the operation type.

If a change is made to a schedule, an “unsaved” indicator is shown by the schedule name as shown in the following screen shot. Note the small icon on the right hand side of “Schedule 1” where as “RunSchedule1Batch” is unmodified and hence no indicator is shown.

Adding Schedule Operations#

Schedule operations can be added by right clicking on the location that the new operation should be added. Right clicking will show a context menu on the operation sequence as shown in the following screen shot

The context menu shows the following options which are dependant on the location of the mouse click:

• Add operation to sequence : Adds a new operation to the end of the selected operation sequence
• Insert operation : Adds a new operation at the location of the list cursor (note that the list cursor is the black horizontal line that changes location as the user clicks on the schedule operation list. This is where the operation will be appended)
• Delete operation : Will delete the currently selected operation as shown by the light yellow highlighting on an operation
• Cut : Will save the selected operation data to the clipboard and remove the operation from the schedule
• Copy : Will copy the selected operation data to the clipboard
• Paste here : Will create a new operation at the location of the list cursor from the data on the clipboard
• Paste into sequence : Will create a new operation from the data on the clipboard and append the operation to the end of the currently selected operation sequence
• Enable : will enable the selected operation or operations
• Disable : will disable the selected operation or operations. Disabled operations will be skipped when the schedule is run. This provides a simple way of temporarily skipping schedule operation steps

When the user opts to add a new operation the following dialog box is shown to allow selection of the required type of operation

Schedule Operation Sequences#

Operation sequences are schedule operations that contain nested child operations. A good example of this is the loop operation sequence which will perform a sequence of child operations a given number of times. The schedule editor shows child operations of sequences by indenting the child operation from the margin. This is shown in the following screen shot which shows a schedule that uses the loop operation which has four child operations.

Multiple operations can be selected by holding down the Ctrl key and clicking the required operations. The selected operations will be shown highlighted by a light yellow background color. Note that multiple operations can be selected and then copy/pasted or deleted as required. Note however that it is only possible to select multiple operations that are sequential within the schedule.

The following screen shot shows an example where three operations are selected from the loop operation sequence:

Editor Cursor Line#

The schedule editor provides two indicators to aid editing the schedule operation sequence. Selected operations are shown by highlighting the operation by a light yellow background color while sequence location is indicated by use of a horizontal “list cursor” which can be set to either the top or bottom of an operation to allow the user to indicate where new operations should be inserted or created at.

The following screen shot which shows the list cursor set to the bottom of a transfer operation.

Schedule Operation Types#

Revolution supports many different types of schedule operations as follows. In addition, custom operations can easily be created.

Transfer Plate#

The transfer schedule operation is used to move labware from and to instrument locations and stores. Bar code read operations and plate lid operations can also be performed as part of the transfer. Configuration parameters are as follows:

• Object name – used to specify the object (labware object) that is to be transferred. In the case of the first reference of a piece of labware within a schedule a unique object name must be specified. Note that schedules can handle multiple labware objects ( such as multiple MTPs ) where each different object requires an object name so that operations that act upon the object are clearly defined.
• Transfer from current location - specifies if the transfer should transfer the object from its current location. Note that this is not possible for the first transfer of an object within a schedule since the object’s location will not be known by the scheduler yet. Once an object has been introduced into the schedule all following transfers may use this option to transfer an object from the location that it will be at.
• Source – the source of the transfer. This is required for the first transfer of an object within a schedule since its current location will not be known yet.
• Destination – the destination of the transfer.
• Lid handler action – specifies any lid operation such as removal, replacement etc if required.
• Read bar code – indicates that the bar code of the labware object should be read.
• Ignore bar code read failure – indicates that the scheduler should ignore any failure to read a bar code and continue without an error.
• Priority – the priority of the transfer which is used to control contention for robots, slides and other transfer devices. A higher value for the priority will indicate that the scheduler should try to perform the transfer before other transfers with a lower value of priority.

Device Operation#

The device operation is used to run operations or methods on instruments/devices. There are two different modes of device invocation as follows:

1. Invocation at object current location :– used to invoke device operations on the device at which a specified object is currently located. It is possible to specify that an object should be transferred to any device of a given type and hence it is required that device invocation should choose to invoke the device at which an object is located rather than a specific device.
2. Specific device invocation :– used to invoke a specific device regardless of the locations of labware objects.

The operation takes the following parameters:

• Object name – specifies the name of the labware object. Only required if required to invoke a device at a given labware object location
• Device invocation type – specifies the type of device invocation to perform as discussed above. IE invoke device at object current location OR invoke a specific device by name.
• Device type – used to specify the type of device when invoking an operation at a given labware object location.
• Device - used to specify the specific device when invoking a specific device rather than a device at a labware location
• Operation name – specifies the device operation to invoke

Loop#

The loop operation is used to perform a sequence of child operation a given number of times

While#

Will invoke the child sequence of operations while a given condition or expression is true.

Break Loop#

The break loop operation is used to stop invocation of an operation sequence such as the loop operation or while operation. Schedule execution will continue from the next operation step following the loop/while operation.

If/Else Operation#

A conditional operation that is used to evaluate a condition or expression and depending on the result will run either one of two operation sequences.

Composite Operation Sequences#

The composite operation sequence is used to group a set of operations and ensure that all resources that are required will be claimed before commencing the execution of the set of operations. This can help to ensure that there are no long delays while resources are busy performing other tasks. The composite operation sequence can be used to perform time critical operations and also increase system throughput if used correctly.

Start Next Schedule Thread#

This operation is used when the schedule pacing mode is set to “event driven mode”, it is used to request the scheduler to start the next schedule thread which can be used to bring the next labware object into the system and commence the sequence of schedule operations.

End Schedule Thread#

This operation informs the scheduler to stop the schedule thread of execution. Note that any other schedule threads that are running will not be affected and any labware objects in the system will be unaffected. This operation is generally of use as part of conditional error handling and is not required if a schedule runs to its natural completion at the end of the schedule.

Run Schedule#

This operation is used to start a secondary schedule thread of execution. The thread is given a name ( instance name ) to allow other operations to refer to the schedule thread as required.

• Schedule name – the name of the schedule to execute
• Instance name – the name given to the schedule thread so that it can be referenced in other operations such as the “Join schedule thread” operation which can be used to wait for schedule thread completion

Join#

The join operation will suspend the current thread of execution until a given schedule thread has completed. This operation takes one parameter as follows:

• Instance name – the instance name species the name of a schedule thread on which to await completion

Object/Plate Completed#

Informs the scheduler that a labware object has now completed the required sequence of operations and the scheduler should remove the object from the list of managed objects. This allows reuse of the name of the object, within a given schedule, for a new labware object. This operation is rarely required since reuse of the same labware object name is not generally required. This operation takes the following parameters: Object name – the name of the labware object.

Sleep#

The sleep operation will suspend the current schedule thread for a given number of milliseconds.

Fill/Clear Store#

The fill store operation can be used to reset store contents data so that the store is filled with labware of a specified type. This operation is useful in a schedule batch scenario where it can be useful to have an automatic reset of store data to save time consuming manual store configuration.

Run Schedule#

The run schedule operation is used to start the execution of a schedule.

Note that this operation differs from the “run schedule thread” operation which will simply run a single named schedule thread. This operation will run a schedule with a given number of threads of execution and observe the schedule execution pacing mode. Note that by combining the use of the “Fill store” operation with this operation it is possible to create batch schedules that can reset store data and subsequently start schedule execution as required.

• Schedule name – the name of the schedule to run
• Schedule thread count – the number of threads to execute

Send Message#

This operation will send an email message to the standard recipient list. The subject and message can be specified. This allows the scheduler to inform users when a given point of a schedule is reached.

OS Command#

Runs any OS command on the system. Useful for executing scripts and other applications. The schedule can either wait for the command to complete before continuing to the next step of the schedule or start the command and immediately run the next step in the schedule.

Schedule Pacing Mode#

Schedules can be executed in different modes depending on the nature of the required execution. Consider a simple schedule that extracts a MTP from a store and transfers to three different instruments before placing the MTP back into a store. For the purposes of this example the schedule defines the sequence of transfers and operations but not the number of MTPs to run through the schedule (although it is possible to define the number of MTPs to act upon if required). If we define, for the purpose of this example, that we want to run 100 MTPs through the sequence of the schedule then we might want to bring each MTP into the system in an “orderly fashion” and with an appropriate pacing time which will result in all MTPs being treated equally and also to ensure that no MTP is left in the system ( possibly without a lid and exposed to evaporation or other environmental conditions ) for a significant amount of time.

Schedule execution mode is set from the “Properties” tab. This is shown in the screen shot as follows.

The scheduler supports two modes of execution which can help to ensure that all labware objects are treated equally. These modes are as follows:

** Manual Pacing Mode ** Manual pacing mode allows the user to specify a fixed time between the start of each schedule thread of execution which will bring a labware object into the system.

** Event Driven Pacing Mode ** Event driven pacing mode is an alternative to manual pacing mode which instead of using a fixed time duration between each schedule thread execution start, an operation event is used which starts the next schedule thread ( IE will bring the next labware object into the system ). See the “Start Next Schedule Thread” operation in section 4.6.8.

The Schedule Properties tab also contains the following settings:

• Priority – controls the priority at which the schedule will run. Schedules with a higher priority number will be able to claim resources before lower priority schedules
• Suspend child thread starting on error – when set, this will cause child thread starting to be suspended upon an error. This provides a “pause plate input on error” feature where in if an error occurs no more plates will be brought into the system until the user resets the child thread starting

Schedule Parameters#

Schedules can be parameterized to allow runtime control of flow (IE via use of the if/else/loop/while operations) and also to pass parameter values to instruments. The following screen shot shows an example of a schedule with two parameters defined.

In the following screen shot we can see a simple example of how parameters can be used in a schedule to influence how the schedule will work at runtime. Note how the IF operation and the final transfer both use parameters. The IF operation uses the seal_plates parameter and the transfer operation uses the destination_store_name as the name of the store to transfer to.

Schedule parameters can be useful when the user requires many schedules with the same basic flow, but with slight differences. The differences can be built in using schedule parameters and hence avoid having to write and maintain many very similar schedules.

Schedule Interaction Diagram#

The Schedule Interaction diagram can be found under the Interaction tab as shown in the following screen shot.

The interaction diagram shows the tree of schedules that are invoked by the current schedule in the schedule editor. This allows the user to quickly see how schedules interact with each other. Additionally the links between the schedule nodes also show how many schedule threads will be run and also if the schedule will be started will be “forked” or not.