Routing Scripts for Next-Step Selection 
The system supports scripting for routing next-step selection.
Certain points on a routing may have multiple next steps in handling the way defects are processed at your installation. This process may vary from one installation to another, and on the same routing. The system allows you this flexibility through custom scripting logic. After one step at an operation is completed, custom logic makes the step selection when multiple next steps are possible.
When a step has multiple next steps, there are multiple connectors exiting from the step. Each of the connectors (lines) can have a decision script associated with it. These scripts are evaluated when an SFC number completes the step. The return values from all of these next steps are used to determine the next step for the SFC numbers.
Each script is associated with the paths between steps. In Routing Maintenance, to display the scripting dialog box for the next step, display the Routing panel and double-click the label on the line that represents the path to the next step.
Example
The following figure depicts an example of the routing that includes rework logic:
In the above example, the routing includes a simple set of logic for determining the next step after the TEST operation. When an SFC number exits the TEST step, it can exit in one of four different ways.
Assume that the production engineer has included the following scripting for the next-step possibilities:
For the TEST-to-SCRAP next step, the SFC number should be scrapped if it fails and has been retested too many times (3 times). Therefore, the next-step definition between TEST and SCRAP would include the following scripting code:
if (NC_CODE!=null && LOOP_COUNT>=3) exit(true);The TEST-to-PMR_ROUTER next step is defined to cover the case where the SFC number fails, but the loop count is less than 3, as specified in this sample code:
if (NC_CODE!=null && LOOP_COUNT<3) exit(true);The TEST-to-PMR_ASSEMBLE next step is defined to handle the special case when the failure (NC) that is logged is MISSING_COMPONENT, to send the SFC number directly back to ASSEMBLE. The script logic for this would be the following:
if (NC_CODE =="MISSING_COMPONENT") exit(true);The TEST-to-PMR_ASSEMBLE next step is defined in this sample coding without scripting. If none of the exceptions described above are encountered, the SFC number is allowed to travel through to SHIP.
Additional examples for Next-Step Selection include the following:
Simple Test/Debug Loop
The following figure depicts a simple routing that starts with a TEST operation followed by either the SHIP or DEBUG step:
Note that the DEBUG step always returns to TEST for a retest.
The following table describes the script logic associated with the TEST step:
From/To Steps | Script |
|---|---|
TEST to SHIP (No Failure) |
|
TEST to DEBUG (Failure) |
|
The other next steps have no scripts associated with them. Two possible scenarios with this routing are the following:
The SFC number passes the TEST and proceeds to SHIP.
The SFC number fails the TEST and is sent to DEBUG. The SFC number is repaired at DEBUG by adding a repair NC code. The SFC number is then sent back to TEST. It passes the TEST and is sent to SHIP.
Failure-Dependent Routing
The following figure depicts a routing that sends the failing SFC number to two different locations, depending on the NC_CODE:
Note that the same thing can be done with the Failure ID associated with the NC_CODE.
The following table describes the script logic associated with the TEST next step:
From/To Steps | Script |
|---|---|
TEST to SHIP (No Failure) |
|
TEST to DEBUG (Failure) |
|
TEST to ASSEMBLE (Assembly Failure) |
|
The other next steps have no scripts associated with them. The possible scenarios with this routing are the following:
The SFC number passes the TEST and proceeds to SHIP.
The SFC number fails the TEST with the MISSING_COMP NC Code and is sent to ASSEMBLE. The assembly problem is fixed on the SFC number and at ASSEMBLE. The SFC number is then sent back to TEST. It passes the TEST and is sent to SHIP.
The SFC number fails the TEST and is sent to DEBUG. The SFC number is repaired at DEBUG by adding a repair NC code. The SFC number is then sent back to TEST. It passes the TEST and is sent to SHIP.
Using Custom Data Fields
This routing uses the custom field associated with the SFC number's material to determine where to send the SFC number when it fails.
The script logic associated with the TEST next step is shown below:
From/To Steps | Script |
|---|---|
TEST to SHIP (No Failure) |
|
TEST to DEBUG (Failure) |
// Get the custom property COST
// Default the cost to $100
// If the item is worth less than $500, go to DEBUG
|
TEST to MRB (High Value Failure) |
// Get the custom property COST
// Default the cost to $100
// If the item is worth more than $500, go to Material Review Board (MRB)
|
The two lengthier scripts for the failure cases illustrate how to retrieve data for objects in the system, including custom data fields.
The script for TEST to MRB is described below:
If there is no failure, then the SFC number should not follow the TEST to MRB path:
if (NC_CODE==null) exit(false);This statement gets the custom COST property for the material using the convenience method getCustomItemProperty():
cost=getCustomItemProperty("COST");The next statement sets a default value for the material’s cost if COST is not defined:
if (cost==null) cost =100;The last statement includes the logic to decide whether to send the SFC number to MRB:
if (cost>=500) exit(true); else exit (false);
The size of the script is not limited, but longer scripts run slower.