Final assignment

Warning

Please carefully read the information on fraud.

Introduction

The final assignment is an extension of the midterm assignment. Where for the midterm assignment only part of each workstation needed to be modeled, for the final assignment, the complete workstation must be modeled and controlled. You can continue from where you ended with the midterm assignment.

The goal of the assignment is to develop and validate a real-time controller for your workstation. Validation is done by means of interactive simulation, real-time testing on the digital twin and, optionally, real-time testing on the actual Festo workstation.

Assignment

For more detailed information on each workstation and its components, please have a look at the Festo hardware manual.

Assumptions

A number of assumptions is usually necessary before a complete model can be developed. These assumptions must be reasonable, and must be supported by arguments. Parameters that are not given in the assignment should be realistically estimated. Clearly state and explain your assumptions in your report.

Plant and controller common info

Controller

Your controller should be:

  • Time efficient, leading to a high throughput.

  • Energy efficient, e.g., by switching off equipment that does not need to be active.

  • Safe for equipment and operators.

  • The same for control via TwinCAT and control via simulation in Eclipse.

You may use happy flow controllers, assuming no errors to be present in the physical system, unless explicitly stated otherwise in the specific information for your workstation below.

Each workstation has an interface panel with three buttons and a key. If your workstation has two interface panels, you may only use the first panel. The buttons on the interface panel should implement:

Plant

Every plant has an actuator and sensor for Upstream and downstream communication. The user must be able to toggle the state of the sensor for downstream communication by clicking on the sensor to mimick changing the ready/busy state of the downstream station.

For instance, the processing station has an actuator a_processing_ready to communicate to the previous (upstream) workstation (the conveyer of the 2TB workstation) that the processing station is ready to receive a product. Communication with the downstream station (the sorting station) takes place via the s_sortingbusy sensor, which indicates whether the sorting station is busy or can receive a product.

Note

This year, stop and reset functionality for the stop and reset buttons, respectively, are not needed and will not be graded, even though the example startup controller in the templates reacts to stop button presses. You may use the stop and reset button to implement any kind of functionality that you like, including doing nothing, as long as you explain the functionality in the report or operator manuals.

The files in folder lib in your assignment repo, are not meant to be changed.

Plant and controller specific info

Controller

  • Use only the interface panel of the Distributing Station and not the one of the Handling Station.

  • The controller should be able to efficiently control the recipe where product stacks 1 and 2 contain products of the same type.

  • The controller should alternate between taking products from stack 1 or 2, and products from stack 3. Such a strategy could be used, for example, to control a system where stacks 1 and 2 contain jars that will be filled with liquid, and stack 3 contains lids for those jars.

  • The auto position of the key (see Festo manual) should ensure that the rotating transfer cylinder only places products in the Testing Station when the Testing Station is ready to receive a product; the manual position of the key should cause the Handling Station to ignore whether or not the Testing Station can receive products.

  • When the key is turned while a product is being transferred by the rotating transfer cylinder, the transfer cycle should finish normally, before the new setting of the key comes into effect.

  • When a product is removed from the gripper unexpectedly, the controller should pick up a new product from the same set of stacks (either 1 and 2, or 3), such that products arrive at the Testing Station in the correct order.

Plant

  • In manual mode (2-ctrl-plant-first/last.tooldef), it is very difficult to stop the sliding manipulator exactly above the drop off point, indicated by sensor s_xpos_atdrop. Therefore, you may make this sensor clickable, such that clicking it causes the position of the sliding manipulator to be set exactly at the drop off point. See the digital twin operator manual of workstation 1DH for an example of how this could work.

  • The simulation visualization should contain three buttons for each stack. One button to add a single product to the stack, one button to fill up the stack and the last button to empty the stack.

  • Black products, and small and large products should be rejected. The other products should be delivered to the processing station. In other words: only the red and aluminium products of normal height should go to the processing station, the other products should be rejected.

    This behavior corresponds to the value of the sensor s_productheight in the digital twin, when the elevator carrying a product has reached a stable, fully up position.

  • To understand how product height is measured, carefully read the height measurement section in the Festo manual.

  • Unexpected removal of a product from the conveyer should be detected, and the operator should be alerted by means of one of the LEDs at the interface panel. The operator should ensure that the system can safely continue and push a button, after which the system should continue without the removed product.

Efficiency

When the Sorting Station cannot receive products, the Processing Station should continue processing for as long as possible.

Upside down products

The system should be able to cope with upside-down products entering the Processing Station. If an upside-down product is detected, the operator should be notified by means of one of the LEDs at the interface panel. However, the system should continue processing other products and accepting new products (for as long as possible).

Please note, that an upside-down product is not detected by any of the six product sensors under the table, when the table is correctly positioned at one of the six fixed positions.

After detection of an upside down product, the operator should turn the key to manual to indicate that the product will be corrected. The product should move to the empty slot after the exit, to be correctly placed by the operator. After correcting the product, the operator has to options:

  • Press a button to indicate that the product orientation has been corrected and the next product can be corrected.

  • Turn the key back to auto so that processing can continue as normally.

  • A full slide should be indicated to the operator by means of one of the LEDs at the interface panel. The operator will then empty the full slide and press a button, to indicate the system can continue.

  • Unexpected removal of a product from the sorting belt should be detected, and the operator should be alerted. The operator ensures that the system can continue safely and then presses a button to continue operations.

  • New products arrive in the single product buffer preceding the conveyer. This buffer models the exit position of the preceding processing station. You should also model the transportation of the product in this buffer onto the conveyer.

  • The key (autoswitch) indicates the sorting scheme that is used. In the vertical position, all products should be sorted by color. When the key is in the horizontal position, the first slide should be filled with alternating red and black products and the second slide should be filled with grey products. The last slide may be used to place products that do not fit the pattern of the first slide.

Use cases: introduction

The assignment also requires three use cases. The essence of a use case is that operator actions are modelled and automatically executed, such as placement and removal of products, and pressing of the start, stop or reset buttons.

Use cases should convince the user of your model, that your group has correctly implemented the most important functionality.

The user of your model can be the person who grades your model, or it could be the imaginary customer who pays you to develop a high tech system. The user needs to thoroughly test your model via simulation to establish whether your controller satisfies the requirements.

The user will check how your model responds to different scenarios, such as different kinds of product sequences entering your workstation. The user will also observe how the controller responds when products are unexpectedly removed from the workstation (if required in the assignment), when buffers become full, or when the pause and reset buttons are pressed.

The difference between the normal mode of operation and a use case is that in the normal mode of operation, the user needs to press the start or reset buttons and the user needs to press buttons to select a different product color, to select products to enter the system or to remove products from the system, whereas in a use case, all these actions are executed automatically by the use case and the user can just sit back, relax and watch.

The user no longer needs to think of all kinds of scenarios for testing your models, but instead can simply press a button for a specific use case and watch how your model reacts. Each use case should have its own visualization button for execution.

Use cases and operator controlled validation

  • The visualization of the simulation model should clearly show all physical components of the plant, including the status of actuators, sensors and product movement.

  • The simulation model should provide three use cases to automatically show and validate the most important functionality of the controlled system.

  • In addition to selecting execution of the three use cases that follow a fixed plan, the operator should be able to manipulate the simulated physical system, including the processed products. This User-input mode is already provided in the plant model in the repository for the midterm assignment.

  • Use cases are required only for the SVG simulation, not for the digital twin.

  • Use cases can never show all possible relevant behavior, but try to show the most important behavior of your system and try to show how you system behaves under normal circumstances and how it deals with errors.

Manual mode of operation

For manually switching on actuators, a special tooldef file 1_manual_plant.tooldef is provided. Experiment with this manual mode to test how your plant model reacts to unexpected input. Actuators can be switched on and off by pressing the actuator buttons.

Real-time control on the Festo workstation

As a result of the Corona situation, testing on the Festo workstations is optional. Grading of the real-time controller will take place on the digital twin instead.

Before you may download your real-time controller to your Festo Workstation Group, you must first show the simulation with visualization to the teacher for approval. The controller used in the simulation should also be executed on the digital twin of your Festo workstation. When both have been approved the controller may be downloaded for real-time control and may be executed on your Festo workstation.

For more information on how to do real-time control using your own controller, check the TwinCAT in the Festo Lab user guide.

Report

  • Title page with name of the assignment/workstation; name of the course (4TC00 etc.); Group number; names with initials, identity number, bachelor/master track (if known, W/WMT/INF/IVO etc.) of the group members; the date. There should be no additional text on the front page.

  • Keep the report short: max 3 pages, including front page. No abstract. Do not describe the workstation in the report.

  • Commit and push a digital version of the report to the repository. A paper version of the report is not needed. You may use a docx or pdf file.

  • Description of the main functionality of the control strategy. Do not explain the CIF model line by line, but explain the important control decisions and control logic. E.g., how does your controller handle errors and unexpected events, how does your controller react to the reset and pause buttons, how are a high throughput and low energy use realized.

  • Description of the assumptions and parameter estimates. Also explain how the estimates were obtained and provide reasonable arguments for your assumptions.

  • Description of the use cases that are actually working in your simulation model. Do not describe use cases that cannot be simulated automatically.

  • Operator instructions for the simulation in manual and automatic mode and for the digital twin / Festo workstation. These operator manuals should allow someone familiar with the course to operate your simulation model and the digital twin / Festo Workstation for real-time control. Only present information that is specific for your models, such as a specific start-up sequence or the meanings of LEDs and buttons.

Additional requirements

  • Do not change any filenames of the files or folders that are supplied in the repository for the midterm assignment.

  • Do not add any folders to the repository that is supplied for the midterm assignment, which is used as a basis also for the final assignment. You may add files in the top level directory, but no folders.

    If you add files, ensure that import statements in CIF use exactly the same capitalization of imported file names as the actual file names, otherwise you will get errors. To avoid these problems, use lowercase file names only.

    You may add temporary folders in intermediate commits, but in the last commit for the deadline, there should no longer be any additional folders.

  • Do not change or add any actuators or sensors.

  • Ensure that the interaction between controller and plant takes place via actuators and sensors only.

  • Start each file with a comment including the surnames, initials and ID numbers of the three members of your group.

    Do not add any other comments in your CIF files. If you really think you need comments, use full line comments only: do not combine code and comments on the same line by adding a comment to the end of a line of code.

  • Do not exceed lines beyond column number 120. You may set a line indicating column 120 in the Eclipse editor: Eclipse menu | Window | Preferences | General | Editor | Text Editors | Print margin column: 120.

  • Nicely format and indent your models for optimal readability. Look at the models provided in the lectures for examples.

  • All CIF files must compile without errors: each separate CIF file must open in Eclipse without any error indications.

  • Do not commit any generated PLC code.

Additional sources of information

Normal vs late submission

Normal submission

  • Your submission commit should be tagged final. This final commit will be graded, assuming it has been created before the deadline and unless there is also a tag final-late.

    For additional info on tags, see Section Normal submission of the midterm assignment.

Late submission

  • If you decide to take the late submission deadline, your submission should be tagged final-late.

Grading

Go to Final assignment grading