Lesson 7 · Conditions, counters and chained transports

A diagram that only fires on a timer cannot react to what the plant is doing. With conditions it looks at the state of the plant, with variables it remembers things between sequences, and with the drop-off trigger one transport can start the next one.

Time

30 min

Start from

the checkpoint of lesson 6

You will learn

branch a sequence with a condition on the state of the plant
keep a counter in a plant variable and update it from a sequence
chain a transport to the delivery of another with the drop-off trigger

Open your project from lesson 6, or its checkpoint. Prefer to watch first? Video 05 and video 06 cover variables and cyclic missions.

When demand outgrows the fleet

Suppose Line 1 speeds up and asks for material every 30 seconds, 120 an hour, more than three vehicles can carry. Change the Periodic timer of Line 1 to Interval (s) 30 and run 1 h. The queue grows all hour without limit: orders pile up that will never be served in time, and the lead time of every later order grows with them.

A real line would not keep asking: when too many orders are already waiting, it holds back. You will model exactly that, and count how many requests it holds back.

A counter

A plant variable is a named value shared by all sequences. It is defined by its own block, which has no connections, and starts at its initial value at the beginning of every run and after Reset.

Define it. Click Plant variable in the palette. In its panel set Variable name to skipped, Type to Integer and Initial value to 0. Names allow up to 40 characters: letters, digits, spaces and underscores. Park the block below the timer; it needs no connection.
Add the updater. Click Update variable. Choose Variable skipped, Operation Increment (also negative) and Value 1. Each sequence that passes through it adds one to the counter.

A condition

Condition looks at one thing once, when the sequence reaches it, and sends the sequence out of Yes or No. Insert one between Line 1's timer and its mission, with the question: are there at most 6 missions waiting?

Periodic timer30 sConditionpending ≤ 6Generate missionyes: Line 1End sequence

…ConditionnoUpdate variableskipped + 1End sequence

Open the way. Select the connection between the timer and the mission and press Delete.
Add and configure the condition. Click Condition. Set Check to Pending missions, Comparison to ≤ and Value to 6. Other things it can check are free vehicles, active and completed missions, your own variables and, with a warehouse, free cells and available pallets.
Wire the two branches. Timer → condition input. The condition's Yes output → Generate mission. Its No output → Update variable. Then both the mission and the updater → the same End sequence (several connections may enter a block, and they do not synchronise each other).

Run 1 h again. The queue now stays at a handful of orders, never more than a few above the limit. The throughput does not fall: the fleet delivers everything it can. The variable chip at the bottom of the diagram shows skipped, the number of requests the line held back, about 50 an hour here. That is the real answer to a limited fleet: not a growing queue, but a number you can discuss.

Block	Use it to
Condition	decide once and branch: yes or no, here and now
Prerequisite	hold the sequence until the condition is true, then continue

Note

With a prerequisite instead of the condition the line would not skip orders, it would wait until the queue drops. Both are valid; they model different plants.

A chained transport

Material delivered to Line 2 is processed for 40 seconds and must then go on to Repack. No timer can know when the delivery happens, but the On station drop-off trigger can: it fires every time something is unloaded at the stations you choose, whichever sequence caused it.

On station drop-offLine 2Wait40 sGenerate missionLine 2 → RepackEnd sequence

Give Line 2 a pickup role. A transport can only start from a pickup. In Draw, select Line 2 and tick Pickup as well as Drop-off: the triangle becomes a diamond.
Build the sequence. Back in Plant logic, add On station drop-off and, in Drop-offs to observe, tick Line 2. Then Wait with Duration (s) 40, Generate mission named Repack with Block pickups Line 2 and Block drop-offs Repack, and End sequence. Connect them in order.
Run and look. Run 1 h. The completed missions now include the second leg, so throughput is higher than the orders the timers create: one in six on average goes on to Repack. Each block on the diagram shows its visit count, and the Repack block's count tracks the deliveries at Line 2.

Warning

The trigger fires for any unload at the station, including one your own chained mission causes. Never chain a transport that delivers to the very station it observes, or it feeds itself without end; the model stops a loop with no waiting time, but a loop with waiting time would run forever.

What you should see

A valid diagram of nine blocks plus the variable, the skipped chip under it, a bounded queue and about 94 missions an hour counting both legs.

Try it yourself

Replace the Line 2 timer with a Cyclic mission block: a transport from Goods in to Line 2 is created whenever Line 2 has nothing waiting or running, after a delay you choose. No timer or connection back is needed.
Add a Boolean variable rush and use it in a second condition to send orders to Line 1 only while it is true.
Put the cap back to 100 and compare the two runs in the comparison table.

Checkpoint

The plan at the end of this lesson: the plant with Line 2 now also a pickup (diamond), feeding Repack through a chained transport

It contains: 9 paths · 7 stations · 1 traffic zone · 3 AGVs · 13 workflow blocks.

Download the checkpoint (aurora-07-variables.en.sim)

Open it with Project›Import project. It replaces the project you have open, so save yours first (or open it in a new browser tab). Anything you do from here on is a copy: the checkpoint file itself never changes. Use it to continue from here if you skipped a lesson, or to compare your own project with the expected one.