ISE 167 Laboratory Welcome to the lab Green

ISE 167 Laboratory • • • Welcome to the lab Green Sheet Schedule Adds, drops, etc. Pro. Model™ is loaded in E 405, E 407 on first come, first served basis

ISE 167 Laboratory • • Lab Tour Pro. Model Tour Sequence of Solution Prologue program: Keep this on disk, as we will be modifying it (as needed) to illustrate the lab concepts.

Pro. Model™ - Sequence • Essentially, this is no different than a topdown computer programming exercise. • First, define what you have, and what you need. • Haves: Entities, arrival schemes, locations, processing limits (if any). • Needs: Process details, system statistics, entity statistics

Pro. Model™ - Sequence • It is usually easier if you draw a picture / flow chart / etc. Note: This will be required for your reports. • It is also usually easier to work backwards from the “needs” to the “haves” as one would do in chemical synthesis.

Pro. Model™ - Sequence • Once a clear picture of what is required is defined, then declare and define the following modules within Pro. Model: • Locations • Entities • Arrivals • Processing • Variables • Fun Stuff

Pro. Model™ - Locations • Locations are where events are carried out upon entities flowing through the system. • On some versions, limited numbers of locations are available. There may be occasions where creativity will be needed to model the system (but not for a while…).

Pro. Model™ - Locations • Things to define in the Location module found under the “Build” tab: • Name • Capacity – How many entities at a time • Units – How many of this location type • DTs – Downtime logic (covered later) • Rules – Decision rules (FIFO, random, etc. ) • Color, size, and layout placement can be done.

Pro. Model™ - Entities • These are defined (within Pro. Model!) as the parts that flow through the system. • The entities are often also limited in number, depending upon the program type, so creativity may again be required. • Entities are discrete units that can be bundled. This aspect is covered later.

Pro. Model™ - Entities • Things to define in the “Entities” module under the “Build” tab: • Name • Speed of Travel (default is 150 fpm) • Color, size, etc. • Attributes are set by a separate module under “Build” and cover locations and entities. This is a future topic as well.

Pro. Model™ - Arrivals • Arrivals are defined for entities entering the system. • Can be a single occurrence, infinite, or anything in between, as defined in the logic. • Each entity entering the system will have its own arrival protocol.

Pro. Model™ - Arrivals • Things to define for “Arrivals” under the “Build” tab: • Entity Name • Location of arrival • Quantity at each arrival • First time of arrival (default is when the system FEL causes the arrival)

Pro. Model™ - Arrivals • Things to define for “Arrivals” under the “Build” tab, continued: • Occurrences – number of times arrivals will occur during the simulation • Frequency – Logic for when arrivals occur, can be either an integer number or a distribution that has all required parameters (Note that Uniform Distribution uses the half width as a parameter) • Logic – Special conditions, etc.

Pro. Model™ - Processing • This is where the meat of the program is defined. Following the road map (picture) that was developed, walk each entity through all of the processing steps from start to finish. During this time, name and locate the variables used to track the performance of the model / system. • One other caveat: the system will do exactly what it is told to do, so when cutting and pasting, be sure you don’t change the entity name in processing.

Pro. Model™ - Processing • Things to define for “Processing” under the “Build” tab: • Incoming Entity (one entry allowed) • Location – where the entity is NOW • Operation – What logical steps are to be applied to the entity at the location above. Can be waits, updates on tracking variables, costing, etc. • Output – Declare the SAME entity unless you are really intending to change entities in this step.

Pro. Model™ - Processing • Things to define for “Processing” under the “Build” tab, continued: • Destination – The target location. Can be more than one, but each location is defined separately, using the return key. If more than one location is used as a target, you need rules for selection. • Rule – This section defines the logic for how and which location gets the entity, whether as a preloaded subroutine or a user-defined subroutine. • Move Logic – Used for Resources, primarily.

Pro. Model™ - Variables • Variables are used for tracking system, location and entity performance. • Can be used for verification purposes. • Essentially there is no limit on the number of variables that can be issued.

Pro. Model™ - Variables • Things to define for “Variables” under the “Build” tab: • ID – Declares the variable name • Type – Integer or real, default is integer • Initial Value • Notes – Useful for large programs to track what this variable is supposed to do. • Icon – This tells you when a counter appears on the layout.

Pro. Model™ - Fun Stuff • More items available, and to be discussed later: • Resources – Forklifts, techs and the like. • Path Networks – used to constrain movements within a shop model, for example. • Arrays, Macros, User Distributions, etc. help convert the process into a definable model. • Background Graphics can be used for labeling and identifying components in a layout.

Pro. Model™ - Distributions • Distributions are declared in Pro. Model shorthand, thusly: • N(12, 3) means a normal distribution with mean 12 and standard deviation of 3. • U(10, 1) means a uniform distribution with a center of 10 and a half-width of 1 (ranges from 9 to 11). • T(1, 2, 3) means a triangular distribution with a minimum of 1, a mode of 2, and a maximum of 3. • E(5) means an exponential distribution with a mean time between events of 5.

Pro. Model™ - Distributions • All distribution types have theoretical expected values and variances, refer to the ISE 130 notes, or your text for these. • The expected values are to be used for model verification in comparison to the model-generated confidence intervals.

Pro. Model™ - Attributes • Two types: Entity and Location. Entity is more common. • Attributes can be examined and acted upon by the logic in any part of the program from arrivals to departures. • Attributes of an entity are copied over whenever an entity is cloned. This happens when entities are split, for example.

Pro. Model™ - Attributes • Within Pro. Model, select the Attribute field from the drop-down Build menu. • The required elements are “name”, “type” (integer / real), and classification. • Values are assigned in the logic. • Attributes are especially useful when assigning a user condition for routing.

Pro. Model™ - Attributes • Today’s exercise for the prologue is to do the following: • Create an attribute for the entity to bypass the inspection step as a “good part” since it comes from an ultra-reliable supplier. One third of the entities received are from this supplier. Track the bypassed as well as the good parts in the graphics.

Pro. Model™ - Downtimes • These are elements used to model situations where a part of the simulation is not available for operations. • The setup field is available for Locations and Resources, primarily. • Types of downtimes include intentional (e. g. maintenance or breaks) and casualty.

Pro. Model™ - Downtimes • For locations, select the Build -> Locations sequence. • For a given location, go to the DTs field and select the task button. • There are four types of downtime: clock, entry, usage, and setup.

Pro. Model™ - Downtimes • Types of Downtimes: • Clock – models downtimes on a time basis, regardless of entity usage. Downtime begins if no entity is being processed. • Entry – models downtimes on an entry usage basis, after the triggering entity has left the location.

Pro. Model™ - Downtimes • Types of Downtimes: • Usage – models downtimes on a time basis, regardless of entity usage. Blocked time is not included which differs from clock. Also, usage is only available for single-capacity locations. • Setup – models downtimes on an entry change basis, when the triggering entity has arrived at the location. Available only for single-cap locations, it models the setup time to swap tooling.

Pro. Model™ - Downtimes • Clock Fields • Frequency: Time between successive downtimes, can be scalar or expression. • First time: Determined by frequency logic if left blank. • Priority: Code assigned if downtime is preemptive, default is “ 99” if not assigned.

Pro. Model™ - Downtimes • Clock Fields • Scheduled: Determines whether the downtime is scheduled. If yes, the hours spent in downtime are not considered when determining utilization, percent down, etc. • Logic: Where the delay is defined, either as a “wait” statement or something more complex that utilizes an attribute, etc.

Pro. Model™ - Downtimes • Entry Fields • Frequency: Number of entities between successive downtimes, can be scalar or expression. • First time: Determined by frequency logic if left blank. • Logic: Delay action defined as for clock.

Pro. Model™ - Downtimes • Usage Fields • Frequency: Usage time (not blocked) between successive downtimes, can be scalar or expression. • First time: Determined by frequency logic if left blank. • Priority: As defined for clock. • Logic: Delay action defined as for clock.

Pro. Model™ - Downtimes • Setup Fields • Entity: The incoming entity. The reserved word “ALL” can be used for identical setups, but logic will be needed to model the delay properly. • Prior Entity: The previous entity. “ALL” can be used here as well. • Logic: Delay action defined as for clock.

Pro. Model™ - Downtimes • Today’s exercise for the prologue is to do the following: • Create a downtime field for the machining and inspection activities. When they go down, the waiting time for recovery is defined as follows: • Inspection: U(15, 2) with frequency of 150 min, unscheduled • Machining: T(12, 15, 20) with frequency of 10 hours, scheduled, and N(20, 3) with frequency of E(100) parts

Pro. Model™ - Downtimes • Today’s exercise for the prologue, continued: • Compare the input queue length, utilization, and throughput (e. g. the total good parts) for the one machine and two inspector case. As always, remember to use 95% C. I. s.

Pro. Model™ - Resources • A Resource is person, equipment item, or device that performs the following functions: • Entity transport • Assisting in operations (such as an inspection) • Location maintenance • Resource maintenance

Pro. Model™ - Resources • Resources can consist of one or more units with common characteristics, such as a group of forklifts. • Resources can be dynamic (requiring a path network) or static. Downtimes are also included as part of the model. • Resources have names and name-index numbers. Path networks also have names and nodes.

Pro. Model™ - Resources • Access the Resource fields by Build -> Resources. The following fields are available: • Icon – The Pro. Model icon attached to the resource name • Name • Units – Fixed at the beginning of the simulation run, so downtimes should be used to vary the number of a given resource available.

Pro. Model™ - Resources • Stats • Specs – Defines the network used (if any), set the speed, and define pickup / delivery times. • Search – Sets the Work Search and Park Search logic when path networks are used. • Logic – Refers to the operational logic executed when the resource enters or leaves at a particular path node. • Pts – Auxiliary graphical storage locations.

Pro. Model™ - Resources • Static Resources • Will appear in only one location during the operation of the model, however, it can be used logically to move entities between locations. • There is no status light, but the resource will be green when in use and red when down (if no other graphics are used).

Pro. Model™ - Resources • Dynamic Resources • Requires definition of the Path Network before creation, since it will be referenced in the Specifications dialog box. • The Specifications dialog box defines the rules by which the resource will operate. • Each Resource is defined using the Build -> Resources task sequence

Pro. Model™ - Resources • Fields for Building Resources • Name – The user-defined name of the resource • Units – The program will give it a suffix similar to the location • DTs – As for Locations, Clock and Usage only. Individual units can be selected. • Stats – As for Locations

Pro. Model™ - Resources • Fields for Building Resources, continued • Specs – Provides exact details for Resource implementation. • Search – Separate from the one in Specifications, this refers to the work search (where the jobs are) or the park search (where idle time is allowed) • Logic – Logic defined for when networks are accessed or left • Pts – Used for graphical location of icons

Pro. Model™ - Resources • Details on New Things • Specs – Subunits include the defined path network (not assigned if static), the node specifications, the search logic for resources and entities, and motion rules. • Node specifications – the “home” node is where the resource begins the simulation. Check the “Return Home” if the resource is to return to the home node if idle. Otherwise, it waits where it is.

Pro. Model™ - Resources • Specs, continued • Resource and Entity Search – These define the rules for selecting the next resource and entity to be used. • Motion – These define the speeds and handling times for entities processed by the resource.

Pro. Model™ - Resources • Dynamic Resources • Resource Searches: • Work Search – A list of locations where entities are waiting for pickup. Can be exclusive (can only service its list), or non-exclusive (will default to the Resource Search rule if no work is available in its list) • Park Search – A list of nodes where the resource will park if no work is available

Pro. Model™ - Path Networks • Select from Build -> Path Networks • Name – The network name • Type - Passing or non-passing, where the network segment has to be clear to run a resource along it • T/S – Selects the basis for measuring movement along the node, either as Time or Speed and Distance

Pro. Model™ - Path Networks • Paths – The number of path segments in the network. Clicking on the heading button opens the edit table • Interfaces - The number of location-node interfaces in the network (entity dropoff / pickup points) • Mapping – Used to specify nodes for restricting movements • Nodes – The number of nodes in the network, controlled using the Node Edit table

Pro. Model™ - Path Networks • Path Segment Editing • From and To - The beginning and ending segment nodes. • BI – Used to specify whether uni- or bidirectional travel is allowed on the segment. • Distance (or Time) – The specified distance between the nodes. Default is based on the network graphic layout

Pro. Model™ - Path Networks • Interface Editing • Node - The node number • Location – Used to specify what location is attached to a node number. Locations can be only interfaced with one node, but a node can be interfaced with multiple locations • Mapping Editing – Multiple-branch networks will select paths with the minimum path length. Mapping forces a specified path for a given node destination.

Pro. Model™ - Path Networks • Node Editing • Node - The node number • Limit – The maximum number of resources that can occupy a given node. Blank means unlimited. • Path networks are assigned to resources using the resource dialog box described earlier

Pro. Model™ - Path Networks • Neat ways to avoid trouble • Start by defining the nodes in the “Node” menu. Make all locations singles, and left click to get the node spot. One node for each location. • Then, assign the nodes logically with the Interface editor by double-left-click on the spots just created

Pro. Model™ - Path Networks • Neat ways to avoid trouble, continued • Next, build the network from the Paths editor using the left click, right click to set pairings. Pay attention to which direction you are setting the segments, since that will be the direction assigned if the segment is a unidirectional one.

Pro. Model™ - Path Networks • Tonight’s exercise: • Using the prologue model we have developed over the course of the lab, create a resource (forklift) and the associated path network. The code is in the reader (the network has to be modified to allow the bypass), and observe the changes in operation.

Pro. Model™ - Reporting • On Pro. Model 2002 the reporting broken up into discrete elements. The combined report used by version 4. 2 is gone. • It is also a little more complicated to get the confidence intervals printed automatically. The sheet modification tool is on the taskbar, and has to be assigned for each report page, each time it is used.

Pro. Model™ - Reporting • Within the output viewer, “Sheet Properties” must be selected from the task bar, and the confidence intervals, etc. , are in the additional reports section. • Each report section has to be set up individually.

Pro. Model™ - Reporting • Key items that are useful for reports are: • Locations: Maximum Contents (for queues), Current Contents (for queues), Average Time Per Entry (Locations with no blockages, backs up the operation variable), Pct Utilization (for operations) • Entity Activity – All times and the exits (for throughput)

Pro. Model™ - Reporting • Variables: Total Changes (functions as a de facto counter), Average Time Per Change, Min/Max Times (for operation tracking variables) Current value (for counter variables, and for some operational items), and average value (for operation variables)

Pro. Model™ - Reporting • With respect to the variable reports, it is important to remember that the Total Changes count is done after the warmup period, while the Max, Min, Current, and Average all function and track during the entire simulation run. So, for throughput in a given steady state period, use the Total Changes field.

Pro. Model™ - Reporting • Reporting the experiment is a vital part of the process. There is a reason that the experiment was run in the first place. The key elements for this course is as follows: • Executive Summary / Introduction – This is a one - or two-paragraph statement of what the problem is, including background information, limitations, etc. This sets the scene for the reader.

Pro. Model™ - Reporting • Solution Process – This section addresses the process involved in solving the problem stated in the summary. Pseudocode, flow charts, and a description of the program highlights (such as why a particular construction was used) are appropriate here. Detailed logic statements are not. • Results – This section is used to report the results of the simulation, and the significant highlights for results. Tables are usually useful here with appropriate commentary and 95 % C. I. s.

Pro. Model™ - Reporting • Verification – This section addresses the performance of the model as defined by the modeler. It is not related to the output or results, per se, as those parts answer the design questions. All parts of the model (machine times, distribution calls, arrivals, expected transit times, etc. ) are to be verified. Again, tables are useful for reporting the 95% C. I. s. • Conclusions – Report the conclusions drawn from the analysis of the data, particularly if specific questions were asked. Experiments are run for a reason, after all. • Appendices – Put the model listings, report printouts and other useful information (such as verification tables for all variables) here.

Pro. Model™ - User Distributions • Access using the Build -> More Elements > User Distributions sequence in the dropdown menu. The edit table will contain the following fields: • ID: The declared name of the distribution • Type: Discrete or continuous • Cumulative: Yes / No • Table: Defined / Undefined

Pro. Model™ - User Distributions • Discrete Distributions: • The edit table will give a selection of values based upon the probabilities assigned. Percentages go on the left, the variable response on the right side. The first line covers the first x-percent of the probability field, so plan the proportions accordingly. Also, ensure that the percentages add up to 100.

Pro. Model™ - User Distributions • Discrete Distributions: • Non-cumulative will have the probabilities as separate numbers less than 100. Cumulative will have the cumulative probabilities which will track up to 100. Interpolation is not allowed.

Pro. Model™ - User Distributions • Continuous Distributions: • As for the discrete case, the probabilities are assigned responses, but interpolation is now allowed between declared values. The issues noted for the discrete case also apply in the continuous case as well.

Pro. Model™ - User Distributions • Continuous Distributions: • Non-cumulative will have the probabilities as separate numbers less than 100. Cumulative will have the cumulative probabilities which will track up to 100. Both must start with a zero declaration. • In both cases, the distribution call would be as for any other distribution, e. g. • Transit = dist 1()

Pro. Model™ - User Distributions • Expected Values and Variances

Pro. Model™ - User Distributions • Tonight’s exercise: • Create a user distribution for the machining center, where the operation time will conform to the following set of probabilities, as a discrete distribution: Probability 0. 20 0. 15 0. 25 0. 30 0. 10 Value (min) 8 9 10 11 12

Pro. Model™ - User Distributions • Tonight’s exercise, continued: • Report the following and hand in on a sheet: • Expected value and variance on the machining center • How well the machining center performance compares to the expected values • Utilizations on the machine, inspection, and resource • Total good product shipped. • 10 replications, 40 hours, 8 hours warm up. Report 95% C. I. s.

Pro. Model™ - Operations • Combine • This is a function that was used in the Prologue to create a lot out of three separate entities. • Entities lose their individual identities once combined, unlike the Group command. • Note that this command does not specify the items combined. Use Join to be specific, as on an assembly. • Cannot be used with Group, Load, Create, Ungroup, Unload, or Split As, or on conveyors.

Pro. Model™ - Operations • Group • This is a function that temporarily consolidates entities into a group. • Entities maintain their individual identities once combined. • Syntax can also include a directive to combine as another entity. • Cannot be used with the related grouping statements described above

Pro. Model™ - Operations • Join • Used to join specific entities together as a single entity, such as for assembly of component parts. • Entities to be joined must be routed from the upstream location using the Join rule. • The model will wait for all components to arrive before executing the Join and moving on. • Resources owned by a joining entity are transferred to the base entity

Pro. Model™ - Operations • Combine, Group, and Join • Time statistics are stopped for entities in the Combine mode, and entities are considered as exits. Cost is forwarded, however. • Time and Cost stats are forwarded in the Group mode, since this a temporary state. • Time statistics are stopped for entities in the Join mode, and entities are considered as exits. Cost is forwarded, however.

Pro. Model™ - Operations • Tonight’s exercise

Pro. Model™ - Stat: : Fit • This a pre-loaded program that can be used for data analysis, including curve fitting and assessment of distribution models. • Topics: • Data Entry and Manipulation • Statistical Analysis • Graphs and other Output

Pro. Model™ - Stat: : Fit • Data Entry and Manipulation • Data can be entered manually or using external files, via the Clipboard route. • File data will be accepted with the following file types: . sfp, . dat, . *, . bmp. • Data are as single measurements, not as cumulative data. The data table has an index field on the left side to aid in locating data points.

Pro. Model™ - Stat: : Fit • Data Entry and Manipulation • Input Options: Auto, Sturges, Lower Bounds, Scott, and Manual. • Auto and Manual are straightforward, but note that the automatic mode will minize intervals without losing information. • Rules, where k is the number of intervals and N the number of data points:

Pro. Model™ - Stat: : Fit • Data Entry and Manipulation

Pro. Model™ - Stat: : Fit • Data Entry and Manipulation • Distribution Type: Either, Continuous, or Discrete. • Precision: 6 significant figures are reported unless otherwise designated.

Pro. Model™ - Stat: : Fit • Data Entry and Manipulation • Operate: Sets up a single mathematical operation (Add, subtract, multiply, divide, etc. ) to be run on the data. • Transform: Allows transformation of data by a single mathematics function. • Filter: Discards unwanted data outside of filter boundaries.

Pro. Model™ - Stat: : Fit • Statistical Analysis • Descriptive Statistics: Provides N, minimum, maximum, mean, median, mode, standard deviation, variance, coefficient of variation, skewness, and kurtosis as a single view. • Binned Data: Provides the end points, mid points, density, ascending cumulative and descending cumulative in proportion and percentage terms

Pro. Model™ - Stat: : Fit • Statistical Analysis • Independence Tests: Scatter Plot, Autocorrelation, and Runs tests. The first two yield plots, and the runs test a table that includes the necessary details for above/below median and turning points assessments. Included are the alpha value, and a hypothesis test assessment.

Pro. Model™ - Stat: : Fit • Statistical Analysis • Goodness of Fit Tests: Chi-squared, Kolmogorov. Smirnov, and Anderson-Darling • Distributions available are legion, from beta through Erlang, gamma, Weibull, and the usual suspects. • User selects the accuracy of fit and the level of significance (alpha)

Pro. Model™ - Stat: : Fit • Statistical Analysis • Goodness of Fit Tests: Also available is the auto: : fit mode, which assigns a ranking of a selection of distributions with the acceptance level (as accept / reject) of the distribution as a model for the input data.

Pro. Model™ - Stat: : Fit • Output • Graphs: Density, Distribution, Difference, Box Plot, QQ plot, PP plot are available. The distribution PDF

Pro. Model™ - Stat: : Fit • Tonight’s exercise

Pro. Model™ - Costing • Using Pro. Model • Build -> Cost to get dialog box • Select the costing type (Locations, Resources, Entities) • For Locations, the fields are Per (for time standard), and Operation Rate. The costs accrue when WAIT or USE blocks are executed.

Pro. Model™ - Costing • Using Pro. Model • For Resources the fields are Regular Rate, Per, and Cost Per Use (for access costs) • For Entities the field is Initial Cost • All are set at time of start, except that a Set. Rate statement can be used to modify the Regular Rate field for the resource.

Pro. Model™ - Costing • Using Pro. Model • Costing stats are kept only if the costing function is enabled. The costing types are not modifiable. Refer to the manual for specifics. • Or, you can model the costs using the distribution calls and variables. This is recommended for targeting purposes.

Pro. Model™ - Optimization • In general terms • It is useful to work theoretical model first. Not only is the expected value defined for each model element (good for verification), but the starting points for locations can be found. • When possible, rough cut models should include queues in front of processing locations to aid in identifying bottlenecks

Pro. Model™ - Optimization • In general terms • However, if the locations are too numerous to add queues, then the blocking data can be helpful. Go to the farthest-process location without significant blocking and work backwards, by adding locations and testing results. • Queue maximum and current values should have a significant gap between them. Lack of a gap combined with a high current value is a clear sign of a blockage.

Pro. Model™ - Optimization • In general terms • Work the throughput issue first, then the utilization issues. This is due to the observation that low utilizations can be affected by several causes other than too many locations, such as blocking. Once throughput is in the vicinity of theoretical maximum, the utilizations can be adjusted to reach the desired level. • Don’t forget the transport aspect (Resources).

Pro. Model™ - Arrays • Accessed by Build -> Arrays • ID – Name of the array • Dimensions – Defined by the numbers entered for the quantity of cells. Two-dimensional arrays maximum, with the rows given first followed by columns (e. g. 50, 5 refers to a 50 -row, 5 -column array). Single numbers are assumed to be rows. • Type – Integer or real. Character arrays are not allowed.

Pro. Model™ - Arrays • Import File, Export File – Spreadsheets used to populate and receive array data. • Initializing the array is required if the initial value is anything other than zero. This can be done as a subroutine within a WHILE-DO loop structure. Use separate variables for the rows and columns. • Array data is accessed during run time by the array name followed by the cell location in square brackets, e. g. Arr 1[row, column]. Assign variables and call by variable value. Don’t try expressions.

Pro. Model™ - Arrays • Array values must be exported to be reviewed after run time, since statistics are not created for array elements. • Arrays can be nested, since an array call returns a numerical value. Watch out for recursion errors (endless loops). • Numeric values only, no character strings allowed. • Arrays are not reset after warmup so all values are carried, even if not part of the “run” time. Ensure the array has sufficient capacity or the model crashes

Pro. Model™ - Macros • Macros are a place holder for frequently occurring expression, set of statements, or functions. It is a text call, rather than a function call, and so no values are passed or returned. • Macros must be appropriate to the context of the program element where they appear. In other words, do not try to fit character strings into numeric fields with the macro.

Pro. Model™ - Macros • • Fields: ID – the reference name of the macro Text – The text to be inserted RTI – Run Time Interface, this tool allows modification of model parameters at the beginning of a simulation run.

Pro. Model™ - Subroutines • Subroutines are used much like function calls in that a set of statements are executed and a value may be returned. In this respect subroutines differ from Macros, which are text calls.

Pro. Model™ - Subroutines • Subroutine Fields: • ID – user-defined name • Type – Real, Integer, None or Interactive. Refers to the numeric value returned by the subroutine call. Interactive subroutines can be accessed during run-time in the Interact menu. • Parameters – Refers to the parameters passed over to operate within the subroutine logic • Logic – Program fragment that executes when called.

Pro. Model™ - Arrival Cycles • Used to meter arrivals, such as when lot sizing is used • Build -> More Elements -> Arrival Cycles • Used to create a variable arrival cycle. This can model the customer flow to more accurately reflect peak vs. slow periods. • Fields: • ID – The user-defined name

Pro. Model™ - Arrival Cycles • Fields, continued: • Qty / % - Defines the basis for the total number of arrivals per cycle occurrence • Cumulative – Selects whether the cumulative format is used for the data table. • Table – Forwards the user to the edit field.

Pro. Model™ - Arrival Cycles • Table Editing • Two fields: Time and Qty / %. The time field is always cumulative in terms of hours. • The arrivals are randomly spaced within the arrival band. • Once the table is defined, the next task is to summon it from the Arrivals menu.

Pro. Model™ - Arrival Cycles • Arrivals Editing • The fields affected are the Qty each, Number of Occurrences and Frequency • Qty Each – Use the expression for the numerical quantity for the whole cycle, and select the cycle by name from the drop-down menu. • Number of Occurrences – Defines the number of cycles expected per simulation run • Frequency – Sets the time between the start of on cycle until the start of the next cycle. This must be longer than the cycle time or you will get a runtime error.

Pro. Model™ - Shifts & Breaks • Applies to Locations and Resources • Used to model a more typical workweek than the 40 -hour continuous model. • Build -> Shifts -> Define • The editor window gives the user a menu, and a one-week block of time in graphical layout.

Pro. Model™ - Shifts & Breaks • Creating a block of time can be done by dragging the cursor (similar to path networks). However, there are rules to be followed in this phase: • Shift blocks cannot overlap other shift blocks. • Break blocks must be drawn on top of a shift block. Break blocks also cannot overlap other break blocks.

Pro. Model™ - Shifts & Breaks • Once created, time blocks can be edited by selecting the block and adjusting the parameter of interest. If changing, don’t forget to update the data. • Assigning shifts are done for locations and resources. Keep in mind that these are going to be specific resources / locations assigned to a specific shift regime. Sub-units can be independently assigned as well.

Pro. Model™ - Shifts & Breaks • The shift files must be defined, as well as the priorities for the following events: • Ending shift – An entity of higher priority can cause delaying of the end-of-shift event, otherwise the shift ends and work stops. • Off shift – Will stay unavailable unless forced by a higher-priority item. • Starting Break – Will go on break unless interrupted by a higher priority item. • Break – Will stay on break unless interrupted.

Pro. Model™ - Shifts & Breaks • Shift-specific logic: • Skip – Causes the skipping of a scheduled off-shift or break time • Priority – Changes the priority value of the shift block if desired. • DTLEFT() – Returns the remaining off-shift time • For. Location(), For. Resource() – Boolean flag for type of shift block encountered. Returns TRUE if the type matches the function call. • Resource() – Returns the name-index number of the resource currently processing the off-shift logic.

Pro. Model™ - SEND • Used for initiating a pull-type system • Syntax: • At the location where the pull is implemented: the Routing rule is IF SEND. • At some point upstream: • SEND entity TO location • “ALL” cannot be used as the entity name.

Pro. Model™ - SEND • Used for initiating a pull-type system • Syntax: • Locations that are used to prioritize (such as for SON systems) can use an attribute max or min in the RULES block in Build -> Locations sequence in conjunction with this command.