ShowFlow Logo
Home
News
Download
Support
Training
Consulting
Contact
Tips & Tricks
Tip #001 - Evaluation order
When a product moves from one element to another, ShowFlow goes through several evaluation steps. Sometimes it is important to understand these steps and know the order in which they are evaluated. For example, if you had a Trigger on exit statement that included the variable produced[E], it would be important to know that the Trigger on exit field is evaluated before the produced variable is updated.

The Evaluation Order:

  • Per event, elements are evaluated in descending order by elementnumber 3,2,1 (Can be changed in Settings|Simulate).
  • Receive from at current element.
  • Entry condition at current element.
  • Exit condition at previous element.
  • Trigger on exit at previous element.
  • Trigger on entry at current element.
  • elqueue and produced at previous element.
  • batch at current element.
  • Receive from is executed at current element.
  • elqueue at current element.
  • Time at current element.
  • batchout at current element.
  • Exit condition at current element.
  • Send to at current element.
  • Entry condition at next element (general availability at next).
  • Trigger on exit at current element.

Tip #002 - Concurrent Processing
If you have a process that has a large group of machines that do the same thing it might be advantageous to model this group as one element in your model. This way you can simplify your model and get one set results that represent the entire group of machines. There are two ways of tackling this situation. Both ways have pros and cons.

Method 1

1. Create a buffer with large capacity.
2. Trigger on entry => att1[C]:=time+negexp[50]
3. Queue discipline => min att1
4. Exit condition => time>att1[E,1]

Pros: Accurate if screen refresh is set at every 1 unit.
Cons: Slow and utilization is not recorded.

Method 2

1. Create a machine with a large capacity
2. Trigger on entry => att1[C]:=time+negexp[50]
3. Queue discipline => min att1
4. Time => if att1[E,1]-time<0 then 0 else att1[E,1]-time

Pros: Fast, doesn't depend on refresh rate and utilization is recorded.
Cons: Some inaccuracies due to the fact that a processed part will not be included in the queue sortation.

Tip #003 - Empirical Distributions
Lets say 94% of the parts produced in an element take exactly 15 seconds to process but 6% of the parts are defective and need extra work. They take 60-120 seconds to process. There are several ways to do this but the easiest is to use empirical distributions. This is how to set this up:

1. Create a distribution.

  • Select Model|Empirical Distributions
  • The first column is where you enter the percentage. In this case 94 in the firstrow and 6 in the second.
  • The second and third columns are where you enter the range of the desiredresults. In this case 'low=15' and 'high=15' on the first row, and 'low=60' and 'high=120' on the second.
  • This is what it should look like:
P[x] Low High
94 15 15
6 60 120

2. In the time field of element type in the following:

empirical[1]

Tip #004 - How to debug a model
When building complex models it is almost impossible to get them exactly right the first time. The following tips can help you discover the errors and pin point the problem areas.
  • Set the screen refresh rate to every 1 unit in View|Animation. This allows you to see the clock update and slow the model down.

  • Toggle the Repetitive button ON in the Model|Random Generators window. Using the same random number stream over and over makes the behavior of the model exactly the same every time. This way you will know that any changes in observed behavior are a result of modifications you made to the model and not the effect of a different random number stream.

  • Stop the simulation run by clicking the TLI button. Use the following TLI variables and others to check the operation of the model:

    status[x] 1=busy, 2=idle, 3=blocked, etc.
    att1[x]
    produced[x]
    time
    elqueue[x]
    laststagesend[x]
    curcycle[x]
    timespent[x]

  • Write a function called usertli which can be executed on command during the simulation. Be sure to toggle the 'Popup' button in Settings|Simulate. This function can display several TLI variables at once so that you do not need to keep typing in the same variables over and over during the simulation. The following is an example of the usertli function that returns information about transporters. To execute the usertli function you simply click the "user" button in the simulation control box that pops up during a simulation run.

function usertli

p1:=input["Transporter element number"]
tspassigned[p1]
tspelemdest[p1]
tspelemdestloc[p1]
curpath[p1]
curpathpos[p1]

Tip #005 - More colors in 2D icons
The 2D icon editor has a limited number of colors to choose from. To be able to use more colors, use the following trick:

  • Create a small (32 x 32) bitmap using a CAD program or bitmap editor.
  • Import the bitmap into a spare icon.
  • Open both the icon you want to edit and the 'spare' icon.
  • Use the dropper to select a color from the 'spare' icon.

Using this method, you can use up to 256 colors.

Tip #006 - Using products for control
Most people think about products as the items that flow through a model, and only use them to represent physical entities. Products can be anything, widgets, orders, schedules, ...

As an example, let us look at modeling CIP (Clean-In-Place) times in the food industry. Batches of product go through a machine, and on a batch change the machine needs to be cleaned. We can not model this as an 'extra time' on the machine, because that would hold back the last product of a batch (or wait with starting CIP until the first product of the next batch is available).

Instead, we do the following:
  • Create an extra buffer, with a capacity greater than or equal to the number of machines. Assume this buffer is element 34.

  • On the Trigger on exit of each machine we enter:
    { elaccept[E]:=0; movein[34,E,1]; }

  • On the Trigger on entry on buffer 34 we enter:
    attr1[C]:=time+600

  • On the Exit condition on buffer 34 we enter:
    time>=att1[E,1]

  • On the Trigger on exit on buffer 34 we enter:
    elaccept[product[C]]:=1
What this does is moving a 'token' into buffer 34 as soon as CIP starts, with an attribute1 value that indicates the time that CIP will be finished. All these tokens are stored in buffer 34, and as soon as the time for a token has expired the corresponding machine (stored as the product code of the token) will be made available again. Note that this will only work for machines with an element number less than 100, since there is a maximum of 100 different products in ShowFlow.

Valid HTML   Terms of Use   Statement of Privacy   Contact Webmaster