Implement Distributed Control in a Flexible Manufacturing System

This example shows how you can use Stateflow® charts to model a flexible manufacturing system that uses two independently operating pick and place robot arms to place balls into cups. The model uses distributed control logic to send commands to and monitor the status of off-the-shelf components.

The example uses Stateflow charts to model:

• Reusable, componentized control algorithms for the robots and shuttles.

• A network layer that communicates with the physical components.

Additionally, the example uses Embedded Coder™ to generate embedded code from the Stateflow charts. It uses Simulink® 3D Animation™ to animate the model. For software and hardware requirements for Simulink 3D Animation, see Unreal Engine Simulation Environment Requirements and Limitations (Simulink 3D Animation).

The physical components of the manufacturing system include:

• A robot that picks and places cups.

• A robot that picks and places balls.

• Four shuttles that hold and move objects.

• A conveyor belt with five designated shuttle stations.

• A slide that leads to a bin for assembled products.

These components operate according to a defined workflow:

1. The first robot arm places a cup into a shuttle.

2. The shuttle moves to the second robot arm.

3. The second robot arm places a ball inside the cup.

4. The shuttle moves to the slide.

5. The shuttle releases the cup.

6. The cup slides into the bin.

Model Flexible Manufacturing System

The sfManufacturingSystem model is a distributed plant-controller system that uses 3D animation.

• The Distributed Control subsystem contains the controllers for each component of the manufacturing system. It also contains a network layer that sends commands to the plant model.

• The Actor Motion Control area is the plant model. The blocks and subsystems in this area turn commands into animations.

• The Scene Creation & Configuration area is not part of either the plant or controller. Instead, the blocks in this area initialize the animation settings and components.

The plant model and the distributed controllers communicate using signal lines. Additionally, in the Distributed Control subsystem, the Network Layer subsystem uses the data store memory flags in the Command Ready Flags area to signal when the plant model should read a command.

Reuse Logic by Using Libraries, Subcharts, and Parameters

The Controllers chart models each shuttle and robot as a separate, masked atomic subchart, linked from the ShuttleAndRobotLibrary library. The robots link to one library chart and the shuttles link to another. For more information, see Create Reusable Subcomponents by Using Atomic Subcharts and Reuse Charts in Models with Chart Libraries.

Every atomic subchart that links from the same library chart contains identical states, transitions, and data objects. However, by using mask parameters and mappings, the atomic subcharts initialize their data objects to different values. For more information, see Mask Atomic Subcharts and Boxes in Stateflow.

For example, from the top level of the model, navigate to Distributed Control > Controllers. Double-click on the CupRobot atomic subchart to open the Block Parameters window.

Double-click on the BallRobot atomic subchart. Observe the differences between the values.

The parameters define different locations, dropoff points, and types for each robot. Similarly, each robot has different mappings. In the Block Parameters window, select the Mappings tab.

The Block Parameters window shows how symbols in the BallRobot atomic subchart map to data objects in the Controllers chart. For example, the pickLocation input in BallRobot receives data from the ballRobotTargetLoc object in Controllers. For more information about mapping, see Map Variables for Atomic Subcharts and Boxes.

Similar to the robots, the shuttles use parameters and mappings to define unique values.

Distribute Logic by Using Parallel Subcharts

To simulate the simultaneous, independent action of each shuttle and robot, the example models the components as parallel atomic subcharts.

Parallel subcharts execute concurrently. In other words, when the Controllers chart is active, every robot and shuttle subchart is also active. For more information, see Define Exclusive and Parallel Modes by Using State Decomposition.

Parallel subcharts execute on the same step, but not simultaneously. To prevent race conditions, parallel subcharts execute in a defined order during each step. The execution order is displayed in the upper-right corner of each area or subchart.

First, the subcharts in the Robot area execute in the order they appear in the manufacturing system:

• CupRobot

• BallRobot

Afterwards, the subcharts in the Shuttles area execute in ascending order:

• Shuttle1

• Shuttle2

• Shuttle3

• Shuttle4

Model Cup and Ball Robot Control Logic

The robot charts operate in a loop, transitioning along a linear series of states. Each state represents a command.

A robot begins the loop by waiting for a shuttle in the WaitForGoSignal state. When a shuttle arrives, robotGo becomes true and the robot transitions to the next state.

At each state in the loop, the robot sends a command to the network layer. When the plant model completes the command, the robot moves to the next state. After the robot completes the full sequence of commands, the subchart informs the rest of the model by setting the robotDone output to true.

The robots send commands using data objects:

• The robotCommand output defines what action the robot should take and where the action should be performed.

• The robotCommandReady data store specifies whether a command is ready.

The RobotAction enumeration defines the available actions for robotCommand:

• Undefined — No command set.

• GoToPosition — Move the hand of the robot arm.

• Query — Get the position of the ball or cup.

• Attach — Grab the ball or cup.

• Detach — Release the ball or cup.

For example, in the DetachTarget state, the cup robot drops a cup into a shuttle by:

1. Creating an action to detach the cup.

2. Setting the shuttle in front of the robot as the destination.

3. Marking the command as ready.

After sending the command, the cup robot waits for the command to complete. When robotCommandComplete becomes true, the robot transitions to the BacktoHome state.

Model Conveyor Belt and Shuttle Station Control Logic

To prevent collisions as the shuttles move through the manufacturing system, the Controllers chart models the status of the five shuttle stations as Boolean values in the local vector Lock.

Before a shuttle moves, it checks if the destination station is occupied. If the station is unoccupied, the shuttle moves to and locks the station by setting the associated boolean to true. When the shuttle leaves the station, it resets the boolean to false.

To improve readability, the ShuttleStations enumeration maps each shuttle station in Lock to a name:

• CupDropOff

• MidwayToCupRobot

• CupRobot

• MidwayToBallRobot

• BallRobot

For example, to access the station between the cup and ball robots, you enter Lock(ShuttleStations.MidwayToBallRobot).

Additionally, the model uses parameters imported from the data dictionary sfRobotDictionary.sldd to display constants in a readable format. Parameters include:

• aboveTargetPickLoc: A scalar that represents the height at which a robot picks up a ball or cup.

• midwayToTargetYLoc: A scalar that represents the initial offset height of the robot above the target.

• lastShuttleInQueue: A scalar that represents the ID of the last shuttle to begin moving through the system.

• shuttleLocations: A vector that represents the coordinates of each shuttle station.

For more information, see Share Parameters with Simulink and the MATLAB Workspace.

Model Shuttle Initialization

When the manufacturing system initializes, the shuttles queue between the slide and the cup robot. The first robot enters the cup robot station, receives a cup, and leaves. Afterwards, the next shuttle takes its place. This continues until all shuttles leave the starting queue.

The shuttle subcharts model the initialization process by using the Init state and the connected transitions. The image below is cropped to show only the initialization logic in the shuttle subcharts.

When the model initializes, each shuttle subchart begins in the Init state. The Lock vector, which is shared between subcharts, marks the queuing location, CupDropOff, as occupied.

When the Controllers chart takes a step, every shuttle evaluates the transition from Init to Move_Shuttle, starting with the Shuttle1 subchart. Shuttle1 detects the MidwayToCupRobot station is unlocked, so the shuttle:

1. Occupies MidwayToCupRobot

2. Sets the target position to Robot1

3. Transitions to the Move_Shuttle state

In the same step, Shuttle2, Shuttle3, Shuttle4 sequentially execute. Each shuttle detects MidwayToCupRobot is occupied and remains in Init.

After Shuttle1 enters the Move_Shuttle state, it begins to move through the manufacturing system. When it leaves the MidwayToCupRobot station, Shuttle2 takes its place. The process continues until all the shuttles leave the initial queue. When the final shuttle leaves, it unlocks the CupDropOff station.

Model Shuttle Operation

Once each shuttle initializes, it operates in a loop, moving along the conveyor belt and performing actions.

Similar to the robots, the shuttles use two data objects to send commands:

• The shuttleCommand output defines what action the shuttle should take and where the action should be performed.

• The CommandReady data store specifies whether a command is ready.

The ShuttleAction enumerations defines the available actions for shuttleCommand:

• Undefined — No command set.

• GoToPosition — Move along the conveyor belt.

• Unload — Release any held objects.

• Stop — Stop moving.

Shuttles start the loop by entering the Move_Shuttle state and executing several actions:

1. Create a movement command for the shuttle.

2. Set the position the shuttle will move to.

3. Inform the network layer the command is ready to execute.

Afterwards, the shuttle waits for the command to execute.

When the command executes, the shuttle transitions to one of five paths representing the shuttle stations. The chart organizes the paths from top-to-bottom according to which station appears first in the manufacturing system. Each path corresponds to different behaviors.

• Robot1 Path — Move to the cup robot and wait for a cup.

• Park2 Path — Queue in front of the ball robot.

• Robot2 Path — Move to the ball robot and wait for a ball.

• Unload Path — Move to the slide and release the ball-in-cup.

• Park1 Path — Queue in front of the cup robot.

After a shuttle completes a path, it returns to the Move_Shuttle state to prepare for the next path.

For example, when a shuttle takes the Unload path, the shuttle performs several actions:

1. Enter the Unload state.

2. Create an Unload command to release the ball-and-cup. Set commandReady to true.

3. When commandDone becomes true, transition to the Wait state.

4. When the CupDropOff station becomes available, lock the CupDropOff station. Unlock the Unload station. Set the next targetPosition to Robot1Park.

5. Transition to the Move_Shuttle state, which moves the shuttle to the next station.

Observe the Model

In the Simulation tab, click Run to simulate the model. The model may take time to load and prepare the animation assets.

As the model transitions between the states of the robot and shuttle charts and executes commands, the manufacturing system animates the components.