Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

GrafTab: an innovative requirements specification method for a PLC system So, So-ming 1995

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1995-0646.pdf [ 6.45MB ]
Metadata
JSON: 831-1.0064918.json
JSON-LD: 831-1.0064918-ld.json
RDF/XML (Pretty): 831-1.0064918-rdf.xml
RDF/JSON: 831-1.0064918-rdf.json
Turtle: 831-1.0064918-turtle.txt
N-Triples: 831-1.0064918-rdf-ntriples.txt
Original Record: 831-1.0064918-source.json
Full Text
831-1.0064918-fulltext.txt
Citation
831-1.0064918.ris

Full Text

GrafTab — An Innovative Requirements Specification Method For A PLC System by So-MingSo B.Eng., McMaster University, 1993 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL ENGINEERING We accept this thesis as conforming to the required standard The University of British Columbia September 1995 © So-Ming So, 1995 In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. 'Department of Electrical Engineering The University of British Columbia 2356 M a i n ' M a l l Vancouver, B C . V 6 T 1Z4 ' Dat,: Oct If Abstract The flexibility and intelligence of Programmable Logic Controllers (PLCs) has. been improved tremendously since their first appearance in 1968. Today, P L C appli-cations range from food production to nuclear plant operation. As the applications become more complicated, the use of informal English as a medium to write the requirements specification for these P L C systems is no longer adequate or satisfac-tory. A new semi-formal specification method, GrafTab, is introduced in this thesis. It is characterized by a graphical and tabular description method. A complete re-quirements specification in GrafTab consists of a system abstract, a monitored and controlled variable specification, an external interface document, and a system re-quirements document. GrafTab, is a powerful method that offers an unambiguous, complete, and readable requirements specification document. Since each document in GrafTab possesses a formal syntax, mechanisms for transforming a GrafTab spec-ification into two executable programs (ladder diagram a n d S F C ) are developed as well. A method to analyze the performance of these programs directly from the specifcation is included in this thesis. Table of Contents Abstract ii List of Tables ix List of Figures x Acknowledgment . xiii Chapter 1 Introduction 1 Chapter 2 Programmable Logic Controller 6 PLC . : . . . . . . . . . . . . . . 6 Programming Languages in PLC . 8 Ladder Diagram . . . . . . . . . . . . . . . . . . . . . . 8 Sequential Function Chart 10 Design and Implementation Problems in a PLC System . . . 12 Problems in a Requirements Specification . . . . . . . 12 Problems in the Programming Languages 13 Sequential Function Chart 13 Rescan . 14 Simultaneous Branch 14 Selection Branch 15 Ladder Diagram 15 Discrepancy Between Internal Update and Physical Update 15 Lack of Overall View of the Program Flow . . . 16 Performance . 16 Solution to the Problems . . . . . . . . . . . . . . . . . 11 • , . . i i i Table of Contents Chapter 3 Requirements Specification 18 What is a Requirements Specification? . . . . . . 18 Methods in Writing a Requirements Specification 20 Informal Method 20 Semi-Formal Method 21 Formal Method . 21 Functional Documentation Method ( F D M ) . . . . . . 22 System Requirements Document . . . . . . . . . . 23 System Design Document 24 Software Module Guide 24 Module Interface Specification 25 Uses-Relation Document . . . . . . . . . . . . . . 25 Module Internal Design Document. . 26 Optional Documents . . . . . . . . . . . . . . . . . 27 Statechart 27 Hierarchy 28 Zooming In and Out 29 Default State 30 H-entrance 30 Orthogonality 31 Additional Statechart Features 31 Chapter 4 GrafTab — A PLC Requirements Specification Method 34 GrafTab 34 Documents in a GrafTab Specification 35 System Abstract 35 Running Example: Drill Machine 36 Monitored and Controlled Variables Specification . . . 37 Monitored Variables. . 37 Controlled Variables . 38 Running Example: Drill Machine 39 iv Table of Contents External Interface Document 40 Input Addresses . 40 Output Addresses . 41 Internal Addresses -. . . .41 Running Example: Drill Machine 42 System Requirements Document 43 Chapter 5 ESD and S-Spec 45 Enhanced State Diagram (ESD) . . . . . . . . . . 45 State .46 Super-State and Sub-State 46 Entry State 47 Running Example: Drill Machine 48 Concurrent State . . 50 Running Example: Drill Machine 50 Common State . 51 Transition 52 Normal Transition 52 Entry Transition . 52 Non-Entry Transition 53 Selective Transition 54 Broadcast Transition 55 Running Example: Drill Machine . . . 57 Parent Bubble 59 Summary of the E S D .60 State Specification (S-Spec) 62 S A T 63 Running Example: Drill Machine 66 C A T 66 Running Example: Drill Machine 67 S-Spec for a Concurrent State .68 Running Example: Drill Machine 68 • v Table of Contents Evaluation of GrafTab 69 Strengths and Weaknesses of GrafTab 70 Differences Among GrafTab, Statechart, and Functional Documentation Method 72 Chapter 6 GrafTab Specification To Executable Program 75 From Specification to a SFC or a Ladder Diagram 75 State Condition 75 Retentive Value 76 Resetting Variables 77 Reconnecting Broadcast Transition and Entry Transition 77 Primitive State 77 From Specification to a SFC 79 Initialization 79 Basic State and Transition 79 Selective Transition 79 Common State . 80 Loop 80 Concurrent State 81 Concurrent State with Selective Transition 82 Parent Bubble 85 From Specification to a Ladder Diagram . . . . 85 State 85 Transition 87 Selective Transition .89 Super-state . 90 Concurrent State . 92 Unlatching Flag 93 Loop 94 Parent Bubble 95 Overall Structure of the Executable Programs 96 Ladder Diagram Structure 96 vi Table of Contents • SFC Structure . . . . . . .97 Chapter 7 Performance Analysis . . . . . . . . . . . . . . . 99 Size . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Rungs in a Ladder Diagram and a SFC . . . . . . . . 100 Transition 100 State Condition Subroutine 100 Rungs in a Ladder Diagram 101 Initial State . . . . . . 101 Level 0 of an ESD 101 Primitive State . . . . . . . . . . . . . . . . . . . . . . . . 102 S-Spec . . . . . . . . . . . . . . . . . . . . . . . . 102 Additional Rungs . . . . . . . . . . . . . . . . . . 103 . Super-State ". . . . . . . . . . . . . 103 ^ Concurrent State 104 Rungs in a SFC 104 Initial State . . . . . . . . . . . . . . . . . . . . . . . 105 Primitive State 105 Concurrent State 105 Size Difference in a Ladder Diagram and a SFC . . 106 Running Example: Drill Machine 108 Run Time I l l Run Time in a Ladder Diagram 112 Logic Execution Time 112 File 2 and Super-state 113 Primitive State 114 Run Time in a SFC 114 Scanning Sequence. . 115 Primitive State 116 Case 1: exiting.transition condition = false . . . 116 Case 2: exiting transition condition = true . . . 118 vii Table of Contents State with Selective Transitions 119 Concurrent State . . . . 122 Case 1: cond_l = False 123 Case 2: cond_l = True and cond_2 = False . . 125 Case 3: cond_l = True and cond_2 = True . . . 128 Significance of the Run Time Differences . . . . . 130 Chapter 8 Conclusion and Future Works . . . . . . . . . 132 Features of GrafTab . 132 Evaluation 133 Future Work 135 Verification 136 Editing Tool 136 Transformer 137 Bibliography . . 138 Appendix A Housekeeping Time in a Ladder Diagram . . 141 Appendix B Drill Machine 146 Appendix C Traffic Light Controller 151 Appendix D Executable Programs of the Drill Machine . 166 Ladder Diagram . . . . . . . . . . . . . . . . . . . 166 viii List of Tables Table 5.1 Summary of the E S D . . . . . . . . . . . . . . . . . . . . . . 62 Table 5.2 The SAT for the "Start" sub-state .66 Table 5.3 The C A T for the "Start" sub-state . . . . . . . . . . . . . . . 67 Table 5.4 The C A T for the "In Position" concurrent state . . . . . . . 69 Table 6.1 SAT — S-Spec of a Primitive State 78 Table 6.2 C A T — S-Spec of a Primitive State . 78 Table A.1 Housekeeping Time for Case 1 142 Table A.2 Housekeeping Time for Case 2 144 Table A.3 Housekeeping Time for Case 3 145 ix List of Figures Figure 2.1 Rung 10 Figure 2.2 S F C Building Blocks 11 Figure 3.1 Uses-Relation Diagram 26 Figure 3.2 Super-state and states 29 Figure 3.3 Zooming In and Out . 29 Figure 3.4 Default State 30 Figure 3.5 H-entrance 30 Figure 3.6 Orthogonal State 31 Figure 3.7 Condition Entrance 32 Figure 3.8 Selection Entrance 32 Figure 3.9 Time-out Notation 33 Figure 4.1 Hardware Block Diagram of the Drill Machine .37 Figure 5.1 Super-State and Sub-State 47 Figure 5.2 Entry State . 48 Figure 5:3 Level 0 E S D diagram of the Drill Machine 49 Figure 5.4 Concurrent State 50 Figure 5.5 Concurrent States in the Drill Machine 51 Figure 5.6 Common State 51 Figure 5.7 Entry Transition 53 Figure 5.8 Non-Entry Transition 54 Figure 5.9 Selective Transition with Priority Number 54 Figure 5.10 Broadcast Transition in a Concurrent State . . . . . . . . . . 56 Figure 5.11 Broadcast Transition with a Normal Transition in a Concurrent State 56 Figure 5.12 Broadcast Transition points out from a Super-State . . . . . 57 Figure 5.13 Broadcast Transition points out from a Concurrent State . . 57 Figure 5.14 Level 0 of the E S D specification of the Drill Machine . . .58 Figure 5.15 Level 1 of the E S D specification of the Drill Machine . . . 59 Figure 5.16 Parent Bubble 60 Figure 5.17 Format of SAT 64 Figure 5.18 Format of C A T 67 List of Figure Figure 5.19 Format of C A T for the Entry States of a Concurrent State . 68 Figure 5.20 The SAT for the "In Position" concurrent state 69 Figure 5.21 Specifying Time Out Situation in the E S D 71 Figure 6.1 Check Flag . 76 Figure 6.2 Transforming Primitive State 78 Figure 6.3 Transforming Selective Transitions 80 Figure 6.4 Transforming Common State 80 Figure 6.5 Transforming Loop .81 Figure 6.6 Transforming Simple Concurrent State . . . . . . . . . . . . 81 Figure 6.7 Transforming Complex Concurrent State . . . . . . . . . . . 82 Figure 6.8 Concurrent State with Selective Transition 83 Figure 6.9 Putting Simultaneous Branch and Selection Branch Together 84 Figure 6.10 Transforming Parent Bubble . . . . 85 Figure 6.11 Transforming States into Subroutines 86 Figure 6.12 State Transition Variable 88 Figure 6.13 Common State and Selective Transitions . . 88 Figure 6.14 Combining Action Rung and Transition Rung . . . . . . . . 89 Figure 6.15 Transforming Selective Transition 90 Figure 6.16 Transforming Super-State 91 Figure 6.17 Transforming Concurrent State 92 Figure 6.18 Unlatching Flag 94 Figure 6.19 Transforming a Loop 95 Figure 6.20 Transforming Parent Bubble 96 Figure 6.21 Ladder Diagram Structure . . . . . . . . 97 Figure 6.22 S F C Structure 98 Figure 7.1 Scanning Sequence (Ladder Diagram) for Primitive State: Exiting Transition Condition is False 116 Figure 7.2 Scanning Sequence (SFC) for Primitive State: Exiting Transition Condition is False . 117 Figure 7.3 Scanning Sequence (SFC) for Primitive State: Exiting Transition Condition is True 118 x i List of Figure Figure 7.4 Scanning Sequence (SFC) for Primitive State: Exiting Selective Transition Conditions are False 120 Figure 7.5 Non-entry States in a Concurrent State 123 Figure 7.6 Scanning Sequence (Ladder Diagram) for Concurrent State: Entering Transition Condition of the Non-entry State is False . 1 2 4 Figure 7.7 Scanning Sequence (SFC) for Concurrent State: Entering Transition Condition of a Non-entry State is False . . . . . 124 Figure 7.8 Scanning Sequence (Ladder Diagram) for Concurrent State: Entering Transition Condition of the Non-entry State is True 126 Figure 7.9 Scanning Sequence (SFC) for Concurrent State: Entering Transition Condition of the Non-entry State is True . . . 126 Figure 7.10 Scanning Sequence (SFC) for Concurrent State: Exiting Transition Condition of the Non-entry State is True . . . 128 Figure A . l Ladder Diagram for Case 1 . . . 141 Figure A.2 Ladder Diagram for Case 2 143 Figure A.3 Ladder Diagram for Case 3 145 xii Acknowledgment I am very grateful to my supervisor, Dr. Mabo Robert Ito, for his unfailing support throughout this work. He introduced me to a thesis topic that best suited my research interests. His patience, guidance, and perceptiveness are most appreciated. I would also like to thank all the members of the High Performance Computing and Networking Laboratory. Special thanks go to Kendra Cooper for providing many insights into the technical aspects of my thesis project, Mohammad Rezai for helping me to solve all the "Publisher" (a not quite user-friendly word processor) problems, and John Tanlimco and Raymond Cheng for helping me solve all the computer-related problems. Thanks also go to my officemates, Yue He, Bikash Sonah, and Darren Tsang, for supporting me, constantly encouraging me, and chatting and laughing with me during my spare time. I would also like to thank Carrie Hanson and Gary Wardberg for proofreading this thesis report. M y greatest thanks go to my wife, Michelle Yik, for putting up with me throughout this work and my whole life. Thank you for proofreading this thesis report and for always being ready to help me write better sentences. Finally, thanks go to my parents for bringing me up and helping me to do the work that I really want to. xiii Chapter 1 Introduction Programmable Logic Controllers (PLCs) have been used in industry since 1968 [14]. The first programmable controller was no more than just a relay replacement because it was capable of on/off control only. Its application was limited to machines and processes that required repetitive operations. However, the flexibility and intelli-gence of the PLCs have been improved greatly in the last two decades, mainly due to the innovations in microprocessor technology, the improvement of memory capacity in the P L C s , and the capability of remote input/output. Along with these hardware enhancements, software enhancements have brought about computer-like statement instructions, on-line monitoring of the process, and a user-friendly graphical inter-face. Nowadays, in addition to performing repetitive operations, PLCs are suitable for a wide range of applications in metallurgical, chemical, agricultural and food, and petrochemical industries [17]. PLCs have also been applied to safety critical systems, for example a nuclear plant. ' A set of tasks performed by a programmable logic controller (PLC) is called a P L C system in this thesis. As the complexity of the P L C systems has increased enormously, conventional methods of writing the system requirements specification, such as flowcharts and natural language description, are no longer capable of accommodating 1 1 Introduction 2 the complexity of the system. If the requirements specification is written in natural language (for example, English), it is very likely subject to the ambiguity and imprecision which are inherent in the properties of that natural language. A n unambiguous, precise and complete requirements specification is important not only because it is able to describe a P L C system thoroughly, but because it can also (a) serve as a contract between a customer and designer, (b) help a programmer to implement the system effortlessly, and (c) serve as a formal reference for future modification and maintenance of the system. In this thesis, an innovative semi-formal method for writing a requirements specification for a P L C system is introduced. The method, called GrafTab, is characterized by graphs and tables. A complete requirements specification in GrafTab consists of a system abstract, a monitored and controlled variables specification, an external interface document, and a system requirements document. The system abstract is an informal document describing the overall function of the P L C system. The monitored and controlled variables specification is used to identify the inputs and outputs of the system. The external interface document is used to map those monitored and controlled variables onto physical addresses in the P L C . The system requirements document is the most important one in GrafTab because it describes the system states and the relationships among the monitored variables and the controlled variables. The Enhanced State Diagram (ESD) and the State Specification (S-Spec) I Introduction 3 are used to specify the system state and the relationships respectively. The E S D is a hierarchical state diagram with the capability of specifying concurrency, broadcast transition, and memory. Each primitive state in the E S D is described by a S-Spec. Each S-Spec consists of a State Action Table (SAT) for specifying the state condition, and a Control Action Table (CAT) for describing the actions in the state. A P L C system specified by GrafTab will be unambiguous, complete, and readable. The requirements specification is unambiguous because all documents will possess a well-defined syntax in mathematical terms, except for the system abstract. It is complete because all necessary information (software and hardware) about the system is specified. It is readable because the E S D is described by graphs and the S-Spec is described by tables. GrafTab is also easy to learn because of its simple ideas and syntax. Since GrafTab has a well-defined syntax, a P L C system specified in GrafTab can easily be mapped onto an executable program. Mechanisms for transforming the specification into two P L C programming languages, ladder diagram and sequential function chart, will be introduced in this thesis. The performance analysis (in terms of run time and memory requirement) of these programs which can be performed directly from the specification will be discussed. / Introduction 4 Thes is O r g a n i z a t i o n Chapter 2 will sketch the historical background of the PLC, describe the program-ming languages used in a PLC, and discuss the design and implementation problems in a PLC system. ' Chapter 3 defines what the requirements specification is and describes the methods used in writing the specification The focus is on Parnas and Madey's Functional Documentation Method [22] and Harel's Statechart [10] from which the basic idea of GrafTab is derived. GrafTab is described in Chapter 4. In addition, the system abstract, the monitored and controlled variables specification, the external interface document, and the system requirements document are formally defined. The formal syntax of the ESD and the S-Spec will be delineated in Chapter 5. The differences among GrafTab, Functional Documentation Method, and Statechart will also be discussed in this chapter. Chapter 6 will describe the mechanisms for transforming the requirements spec-ification of a PLC system, which is written in GrafTab, into a ladder diagram and a sequential function chart. A performance analysis of these executable PLC systems will be given in Chapter 7. The analysis will be based on the differences between these two programs in terms of run time and memory requirements. / Introduction 5 Finally, the thesis will be concluded by summarizing the features of GrafTab. Future works in GrafTab such as verification methods, editors for writing a require-ments specification, and tools for transforming automatically a specification into an executable program will be proposed. The GrafTab requirements specification of a drill machine will serve as a running example in Chapters 4 and 5. Its complete S-Spec will be in Appendix B. An additional example, traffic light controller, will be included in Appendix C. The specification of a drill machine will then be transformed into executable programs, written in a ladder diagram and a SFC, in Appendix D. Chapter 2 Programmable Logic C o n t r o l l e r 2.1 PLC The first Programmable Logic Controller (PLC) appeared in the United States automobile industry in 1968 [14] . The primary goal at that time was to use the P L C instead of an expensive and inflexible relay-controlled system to develop an automated production line which could keep pace with technical evolution and new production models. The functionality of the first P L C , however, was. limited to on/off control only. Few mathematical and algorithmic style functions were available, and documentation was usually done by hand [25]. The flexibility and intelligence of the PLCs were improved greatly during the 1970s because of innovations in microprocessor technology. Capabilities of operator interface, complex arithmetic, data manipulation, and computer communication were added to the PLCs. The memory capacity of the PLCs was also increased tremen-dously so that large application programs and data could be stored in a single P L C . Communication enhancements between 1975 and 1979 allowed the PLCs to commu-nicate not only with a computer but also with other PLCs and remote input/output systems. The maintainability of a large P L C system was remarkably improved, and its cost was reduced. These improvements were due to the fact that the system could 6 2 Programmable Logic Controller 7 be divided into smaller subsystems by using remote input/output systems. Moreover, software enhancements during this period brought about computer-like statement in-structions. These instructions allowed easy utilization of the many hardware enhance-ments. Another software improvement worthy of mentioning was the system routines for on-line monitoring of the process. With all these enhancements, the PLCs became more widely used in many industrial applications. During the last decade, all aspects of the PLCs were improved significantly. The cost of the PLCs was reduced, while its functionality was increased. They gained faster run times and the ability to connect directly to many special interfaces, such as strain gauges, thermocouples, and fast response inputs. Floating point calculations also became available in the PLCs . These software enhancements allowed one to organize a program into functional blocks, and do an off-line diagnostics and fault detection. Nowadays, PLCs offer much more than was ever anticipated. Their applications are no longer limited to replacing mechanical relays. They now range from food production to power plant operation. The following are some examples of P L C applications. — Food Industries: PLCs are used at mixing stations in the on-line production of finely powdered products, and in the drying and testing of products. — Rubber Industries: PLCs provide accurate scale control, mixer logic functions, 2 Programmable Logic Controller 8 and multiple formula operation of carbon black, oil, and pigment used in the production of rubber. — Chemical Industries: PLCs monitor and control large compressors that are used during the manufacturing of ammonia, ethylene, and other chemicals. — Steel Industries: PLCs control and operate furnaces in the steel making process according to preset specification. They also calculate oxygen requirements, alloy additions, and power requirements. — Power Plant: PLCs regulate the proper distribution of available electricity, gas, or steam. The controllers also monitor power house facilities, schedule distribution of energy, and generate distribution reports. 2.2 Programming Languages in P L C PLC programs can be developed in the following languages: Sequential Function Chart (SFC), Ladder Diagram, Grafect [18], Boolean, and other high level program-ming languages [6, 15]. The ladder diagram and the SFC will be discussed in this section because they are the languages available in the controller used in the present study (i.e., Allen-Bradley PLC-5/15). 2.2.1 Ladder Diagram -"V Ladder diagram was the first programming language used to program the PLCs. Its most primitive form is a graphical representation of Boolean switching functions based on an analogy to physical relay systems. A ladder diagram program consists 2 Programmable Logic Controller 9 of a set of rungs which are executed in order. A rung is made up of a set of input instructions, which serve as a rung condition, and a set of output instructions (Figure 2.1). Once the rung condition is true, the output instruction in that rung will be executed (called active rung). The input instructions can be organized in series (ANDed) and/or in parallel (ORed), but output instructions in a rung must be in parallel only. Values of the input instructions can come from the external physical devices or from the internal signals (i.e., an internal timer or counter). Six categories of instructions can be placed in the output of a rung: relay-type, timer/counter, arithmetic, data manipulation, data transfer, and program control. A ladder diagram program is always located at the File 2 in Allen-Bradley P L C . When a program is scanned (executed), the controller will always scan (execute) the rungs sequentially. In other words, the first rung in the File 2 will be executed first, and then the second rung, and so on. A scan cycle of a ladder diagram in a Allen-Bradley controller consists of the execution of the program, the housekeeping (internal check, and update the outputs and inputs internally, the outputs and inputs are stored in the memory area called image table), and the physical update of the outputs and inputs. Readers are referred to [4] for the syntax of the ladder diagram and [5] for its instructions set in the Allen-Bradley PLC-5/15 controller. 2 Programmable Logic Controller 10 Rung Condition Output Instructions a E-< > ( > Figure 2.1: Rung 2.2.2 Sequential Function Chart S F C is also a graphical language, but unlike the ladder diagram, it explicitly specifies the. control flow in a program. A S F C program consists of steps and transitions (Figure 2.2a). A step, which occupies one step file, contains a set of rungs defined in terms of the program actions. Each transition, which occupies one transition file, is a Boolean predicate which is used to control the flow of the program. A S F C program is a bipartite graph in which steps and transitions must alternate. When the current step is active and the transition condition between.the current step and the next step becomes true, the current step and the next step will be deactivated and activated respectively. , There are two types of branching structures in S F C : selection branch and si-multaneous branch (Figures 2.2b and c). A selection branch contains two or more alternative paths from which the controller selects one. This is equivalent to an "OR" structure. A l l paths in a simultaneous branch will be executed in parallel by the con-2 Programmable Logic Controller 11 - Transition 001:*- Label Step (b) Selection Branch - Transition (a) GOTO 001 (d) GOTO and Label (c) Simultaneous Branch Figure 2.2: SFC Building Blocks trailer. The controller finishes running a simultaneous branch when it has scanned each step in each path at least once and the common exiting transition is true. In a normal situation, program flow propagates from top to bottom unless otherwise indicated by a G O T O statement and label (Figure 2.2d). The G O T O statement and label tell the controller to stop scanning the current path and jump to the corresponding labelled step. In Allen-Bradley controller, a scan cycle of a S F C program consists of the execution time of the active step file and the succeeding transition file of the active step file, the housekeeping (update the outputs and inputs internally, the outputs and 2 Programmable Logic Controller 12 inputs are stored in the memory area called image table), and the physical update of the outputs and inputs. Readers are referred to [4] for the syntax of S F C and the rules for placing selection branches, simultaneous branches, G O T O statements and labels in a S F C program. 2.3 Design and Implementation Problems in a PLC System In this section, the problems in a requirements specification and those in the programming languages of a P L C system will be identified. The problems in the requirements specification are defined because the specification exerts a significant impact upon the behavior of a P L C system. The problems in the programming languages will be discussed since these problems directly affect the final outcome of the system. 2.3.1 Problems in a Requirements Specification A requirements specification document is used to describe the behavior of a system. Therefore, it must be prepared and thoroughly analyzed before the system can be constructed. However, this procedure often is not done in software engineering practice, mainly because of time constraints, cost of doing thorough analysis, and limitations of design methods and design tools. When it is done, the document is frequently written in anthropomorphic analogies and intuitive languages. Furthermore, . the guideline or method for writing a requirements specification document usually is 2 Programmable Logic Controller 13 missing. As a result, the document describes the system inaccurately, and is often full of ambiguities. For example, the specification " A l l files are controlled by a file control block" might be read as (a) One control block controls the entire set of files, (b) Each file has its own block, or (c) Each file is controlled by a control block, but one control block might control more than one file. There are two other problems associated with the intuitive languages that are worthy of mention. First, a specification written in intuitive languages is very hard to analyze and verify because intuitive languages do not have a well-defined syntax and sematic. Secondly, a direct link between the specification and the executable program is hardly visible as well. 2.3.2 Problems in the Programming Languages This section delineates and discusses the problems inherent in the sequential function chart and the ladder diagram, which are used in the PLCs from Allen-Bradley. 2.3.2.1 Sequential Function Chart The problems in the S F C arise primarily from the scanning properties of the controller. The scanning properties are the rules which the Allen-Bradley controller follows when a program is being executed. Three such properties are rescanning in step transition, scanning in a simultaneous branch before exiting the branch, and activating one branch in a set of selection branches. 2 Programmable Logic Controller 14 Rescan The controller always rescans the current step once before it transits to the next step. During the rescan cycle, all non-retentive output instructions1 in the step will be reset to false (de-energized). This can be ineffective, since the designer of a P L C system often wants to keep the value of an output steady until another condition occurs, and this condition might not always happen within the current state. In this case, the output must either be specified in the next step, or be a retentive output instruction2. The programmer need to pay extra attention to the value of the outputs, otherwise the outputs value will be easily changed by the rescan cycle. Simultaneous Branch A l l steps within the simultaneous branches must be scanned at least once before the controller can exit the branches. Even when, if the common transition condition of the branches becomes true before all steps in these branches are scanned, the controller cannot exit the branches until all steps have been scanned once. The programmer has to make sure that this scanning prop-erty matches the system requirements when he/she is transforming the requirements specification into a S F C program; otherwise step transitions in the program will not correctly reflect the requirements of the system. In an non-retentive output instruction, the controller enables the output if and only if the input condition that precedes the non-retentive output instruction are true. If the input condition is false, the controller disables the non-retentive output instruction. In a retentive output instruction, the controller enables the output if the input condition that precedes the retentive output instruction are true. And when the input condition becomes false, the output remains enabled. 2 Programmable Logic Controller 15 Selection Branch Choosing a branch in a set of selection branches depends on the entering transition condition of each branch. If more than one entering transition condition becomes true simultaneously, only the steps on the left-most such branch will be activated. In other words, the left-most branch has the highest priority among all other branches, and the right-most branch has the lowest priority. Therefore, the programmer needs to allocate the steps carefully; otherwise an undesired branch will be selected. The designer of the system also needs to specify the priority of the transitions clearly in the requirements specification document. 2.3.2.2 Ladder Diagram In writing a ladder diagram program, the programmer has the absolute freedom to organize the program structure. Owing to the fact that different programmers have different programming styles, the final program will not be understood easily by most people. Furthermore, if there is not any guideline for writing a ladder diagram program, the dependence conflict among different rungs (for example, different rungs try to turn on and turn off an output simultaneously) in the program frequently can be overlooked, and the performance (run time) of the program will be degraded. It is also difficult to control the program flow because the idea of state and transition is not inherent in the ladder diagram. Discrepancy Between Internal Update and Physical Update While no out-puts and inputs are updated physically until the end of each execution cycle, they are 2 Programmable Logic Controller 16 updated internally in the image table3 at each execution of an instruction in a rung 4 . In other words, when the value of an output is changed in the program, the value of that output in the image table will be changed immediately and can be used by other rungs. One can only see the physical change of that output at the end of the program. This discrepancy is a problem if one tries to turn on and then turn off the output in the same scanning cycle 5. This is because the physical output will only take the latest value (off in this case). Lack of Overall View of the Program Flow A ladder diagram program is continuously scanned by the controller, so an user has no overall picture of the program flow. If the program faults for some undetermined reasons, the programmer must study the code carefully in order to locate the problem. Even when the prob-lematic rung is isolated, the programmer has no way of knowing what events have led up to that malfunction. Performance The run time of a ladder diagram program depends on the execution time of both the active rungs and the non-active rungs, even though the non-active rungs take a smaller fraction of time to be scanned. Thus, the number of non-active rungs need to be minimized in the ladder diagram. One way to do this is to group 3 Image table is a memory space which stores the inputs and outputs in a controller. 4 This discrepancy also happens in SFC. The inputs/outputs, however, will be physically updated at the end of each step instead. 5 Scanning cycle = Rungs Execution + Physical Inputs/Outputs Update 2 Programmable Logic Controller 17 all the related rungs in a program into a subroutine so that the main program will contain only a jump to subroutine rung. By using subroutines, a faster run time will be achieved. 2.3.3 Solution to the Problems In this thesis an argument is made that using a semi-formal and graphical requirements specification method will produce a clearer, more precise, and less ambiguous requirements specification document for a P L C system. A clear document would have the added benefit of serving as the input to all subsequent analyses and testing activities. Furthermore, a direct link between the specification and the executable programs could be established because a formal syntax in the document could be directly translated into an executable program. Chapter 4 will present an innovative method employing a graphical state diagram and tabular specification for specifying a P L C system. The name of this specification method is GrafTab. GrafTab formally defines what kind of information is needed in a requirements specification. Chapter 6 will describe mechanisms for transforming the GrafTab specification of a P L C system into two executable programs. These mechanisms help resolve the problems in traditional P L C programming languages. Chapter 3 Requirements Specification 3.1 W h a t is a R e q u i r e m e n t s Spec i f ica t ion? In the I E E E software engineering glossary [28], a Requirements Specification is defined as: (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). Requirements are often divided into functional and non-functional requirements [30, 12]. The functional requirements define the functions which a system must perform. They specify how inputs are transformed into outputs in the system. They detail the inputs and their validation. The changes of the system state and the responses of the system to both normal and error conditions are also specified. Non-functional requirements, in contrast, describe the environmental constraints, user interface, reliability, maintainability, and mandatory standards of the system. 18 3 Requirements Specification 19 The requirements specification must correctly define only the system require-ments. Any design, verification, or project management details, except for required design constraints, are not permitted in the specification. In [1], the characteristics of a good requirements specification are stated as follows: — Unambiguous: A specification is unambiguous if the specification statements have only one interpretation. — Complete: A specification is complete if it includes all the requirements (functional and non-functional) necessary to build the product. It defines the responses of the system to all realizable classes of input data in all realizable classes of situations. It states all conformities to any standards that apply to the system. Also all graphs, figures and tables in the specification must be labelled. — Verifiable: Every requirement stated in the specification must be verifiable. A requirement is verifiable if there exists some finite cost-effective process with which a person or machine can check to see that the software product meets the requirement. — Consistent: A specification is consistent if and only if no specification state-ment is in conflict with any other statements in the specification. The conflict could be naming conflict in the same real object, characteristics conflict in the real world object, or logical conflict between two specified actions. — Modifiable: A specification should be written in such a way that any necessary 3 Requirements Specification 20 changes to the requirements can be made easily, completely, and consistently. — Traceable: The origin of each requirement in a specification is stated clearly. The specification should also facilitate the referencing of each requirement in future development of enhancement documentation. 3.2 Methods in Writing a Requirements Specification The methods for writing a requirements specification are often categorized into three different approaches. They are the informal method, the semi-formal method, and the formal method. 3.2.1 Informal Method A natural language (for example, English) specification is a typical informal method. No special technical skills are required for the writer who uses this approach to write the specification. The requirements specification is also readable and accessible to most readers rather easily. The requirements are usually organized into certain predefined sections [1, 8], each of which is written in natural language with a free style format. This approach, however, is subject to the ambiguity and imprecision which are inherent in the natural language. The writer of the requirements specification must be especially careful in reviewing the requirements for ambiguity. Moreover, owing to the fact that the informal method is lacking in restricted syntax and semantics, the specification is very difficult to verify. 3 Requirements Specification 21 3.2.2 Semi-Formal Method The semi-formal method possesses a well defined syntax but a loosely defined semantics. Structured analysis [7, 11] is a typical semi-formal method. It offers a graphical description of the data and control flows in a system, and a textual de-scription of the data processing and the control processing. Structured analysis relies on decomposing the system into various levels of data transformation abstraction. Each level of abstraction is represented by a data flow diagram. A data flow dia-gram shows the flow of information (data) and how the information is processed by a transformation center called process. Owing to the lack of well-defined semantics in the structured analysis method, different users can advocate various conventions and rules-of-thumb in the method which cause confusion in the specification. Moreover, the specification written in structured analysis method cannot be verified automatically because each process is still written in natural language. On the other hand, structured analysis has less potential for ambiguity than an informal method because it has precise syntax in the graphical notations. The graphical representation of a system also enhances the readability and comprehension of the specification. 3.2.3 Formal Method For a method to be formal, it must have a well-defined vocabulary, syntax and semantics. The need for a formal semantics definition means that the specification 3 Requirements Specification 22 language cannot be based on natural language, but must be based on mathematics [26, 29]. Because of the mathematical basis of a formal method, the requirements specification written in formal method is more precise and usually more concise than informal and semi-formal ones. The formal method reveals ambiguities, incompfe-tions, and inconsistencies in a system design. In particular, the mathematical basis in the semantics enables us to verify the specification automatically (for example, by a model checker or a theorem prover). On the other hand, because of the restricted syn-tax and semantics in the formal method, the writer of the requirements specification must be trained to use the formal method correctly. The requirements specification also becomes less readable and accessible to the non-trained readers. Many formal methods have been proposed by different researchers, for example, Anna [16], Calculus of Communication Systems (CCS) [19], Petri Nets [24], Vienna Definition Method ( V D M ) [13], and Z [27]. Two methods will be discussed in detail are Parnas and Madey's Functional Documentation Method [22], and Harel's Statechart[10]. The basic idea of GrafTab is derived from these two methods. 3.2.3.1 Functional Documentation Method (FDM) Parnas and Madey, in [22], propose Function Document Method (FDM) for writing precise specification documents for a computer system and its components. As they point out, "functional" is in its mathematical meaning and "relational" could be a more accurate term for their documentation method. A function is a mapping from a set of elements known 3 Requirements Specification 23 as its domain to another set of elements known as its range; every element of the domain is mapped onto exactly one element of the range. In case of a relation, however, an element of the domain can be mapped onto more than one element of the range. In both function and relation, the elements in the range and domain are not restricted to scalar values; they may include scalar vectors, functions, vectors of functions, and time functions. The domain and range in a computer system are, respectively, the environmental quantities to be measured and controlled by the system. These quantities are carefully represented by mathematical variables. The relationships among those variables are then specified by mathematical functions or relations. Two major documents are required in the functional documentation method for specifying a computer system: the system requirements document and the system design document. When the computer system is organized into a set of modules, four additional documents are needed: (i) the software module guide, (ii) the module interface specification, (iii) the uses-relation document and (iv) the module internal design document. Some other optional documents may also be needed to reveal the computer system thoroughly. These are the software behaviour specification, the hardware descriptions, the communication protocol descriptions, and the data-flow document. A l l of these documents will now be discussed in the following sections. System Requirements Document The complete computer system is treated as a 3 Requirements Specification 24 "black-box" in the system requirements document. This document begins with iden-tifying the environmental quantities to be measured or controlled by the system, and associates each of the quantities with a mathematical variable. The variables to be measured by the system are called monitored variables, and the variables to be con-trolled by the system are called controlled variables. Two types of functions/relations, namely NAT and REQ, are then described in the document. In NAT, the environmental constraints placed on the value of the monitored variables and the controlled vari-ables are specified. The environmental constraints include the nature of the system and the previously installed systems. In REQ, the system constraints imposed on the environmental quantities are described. In other words, it specifies the relationships among the monitored variables and the controlled variables in the system. System Design Document The registers which can be read or set by the computer system are identified in the system design document. Those registers are associated with mathematical variables. Two functions/relations, namely IN and OUT, are then specified. The relationships among the mathematical input variables and the monitored variables are defined in IN.-It specifies the behaviour of the input devices. OUT describes the relationships among the mathematical output variables and the controlled variables. It specifies the behaviour of the output devices. Software Module Guide The software module guide is an informal document that 3 Requirements Specification 25 describes the division of the system into modules by stating the responsibilities of each module. Each module described in the guide should satisfy the stated requirements in the system requirements document. A n example of a module guide is in reference[3]. Module Interface Specification Each module is treated as a black-box in this specification. The specification identifies those programs that can be invoked outside the module. It also describes the externally-visible effects of the programs. Writing a module interface specification is similar to writing the software requirements document, but some simplifications are possible. First, because most modules are entirely internal, there are no environmental quantities to monitor or control, and all communications are external invocations of the programs of the modules. Second, the state transitions in a module can be treated as a sequence of discrete events because the state set of a module is finite, and the real-time aspect can be neglected. This allows the writer to specify a module by a sequence which describes the history of discrete events. Parnas and Madey suggest that the trace assertion method [23] can be used to write the history. Uses-Relation Document In this document, the uses relationships among the modules are described. For example, we say module A uses module B if correct execution of B is necessary for A to complete the task described in its specification. The modules are often useful to be assigned into different levels. Level 0 is the set 3 Requirements Specification 26 of all modules that uses no other module; Level / (i > 1) is the set of all programs that use at least one module on Level i-1 but no module at a level higher than i-1 [20]. Once this hierarchical ordering exists, each level offers a testable and usable subset of the system. Moveover, the uses-relation can be represented in the form of a diagram. For instance, in Figure 3.1, there are three levels of modules. Module A is in Level 2, which uses modules B in Level 1 and module E in Level 0. Module B uses modules C and D in Level 0. c D • E Level 2 Level 1 Level 0 Figure 3.1: Uses-Relation Diagram Module Internal Design Document The module internal design document de-scribes the data structure in each module, states the intended interpretation of that data structure, and specifies the behaviour of each module in terms of mapping from the input data to the output data. The document need to be sufficiently precise so that one can verify the workability of the design. A n LD-relation method [21] is suggested by Parnas and Madey for writing the behaviour of a module. 3 Requirements Specification 27 Optional Documents Software Behaviour Specification is used to record additional design decisions. Those decisions impose more restrictions in the implementation of the system. Hardware Descriptions is a black-box description of the behaviour of the hardware chips used in the computer system. It is used to define the interface for both the chip designers and those who integrate the chip into the rest of the system. Communication Protocol Descriptions describes the design of a communication protocol used in a computer system. The services provided by the protocol are also specified. Data Flow Document describes the information flows (data flows) from one variable to another. 3.2.3.2 Statechart Harel's Statechart [10] is a visual method for describing the system states of a reactive system. A reactive system is characterized by continuous reaction to external and internal stimuli (event-driven). Statechart extends a conventional state transition diagram with notions of hierarchy (depth), concurrency (orthogonality), and broadcast communication. It describes states and transitions in a modular fashion, and encourages "zoom" capabilities for moving easily back and forth between levels of abstraction. Harel summarizes the syntax of Statechart as 3 Requirements Specification 28 the following equation: Statechart = state diagram + depth + orthogonality + broadcast communication. The following sections describe the syntax of Statechart. For the semantics of Statechart, readers are referred to [9]. Hierarchy A rounded rectangle is used to denote a state at any level of Statechart. Encapsulation is used to express the hierarchy relation of states. A n arrow (transition) may originate and terminate at any level of the diagrams. Each transition will be labelled with an event and with an optional parenthesized condition or actions. Figure 3.2 shows three states A , B , and C, and a super-state D. State D is called a super-state because it encapsulates states A and C . Each arrow is along with an event (i.e., a, (3, 7 , and 8). State A can travel to state C if event 7 occurs and condition P holds at the instant of occurrence. To be in super-state D , one must be in state A or C , but not in both. This is an exclusive-or (XOR) property in Statechart. The arrow with event (3 is a common arrow of state A and B, and actually originates from them. In other words, state A or C can transfer to state B if event f3 occurs. The representation of a common arrow is one of the most important features in Statechart because it tremendously reduces the number of arrows. 3 Requirements Specification 29 D A TCP. C ^ a L J 6 Figure 3.2: Super-state and states Zooming In and Out Statechart can provide an abstract view of the system by zooming out of the diagram. For example, if Figure 3.2 is zoomed out, the states inside super-state D will not be shown (Figure 3.3a). The arrows terminating at the vertical bars inside super-state D denote that they point to some specific states within super-state D. The details of super-state D are shown by zooming in the diagram (Figure 3.3b). D B A (a) Zooming Out Figure 3.3: Zooming In and Out (b) Zooming In 3 Requirements Specification 30 Default State A default state is the starting state of a super-state, and is designated by an open-ended arrow. In Figure 3.4, if the system enters the super-state D by the arrow with event a , it is actually entering state A , because state A is the default state of super-state D. Figure 3.4: Default State H-entrance When an H-entrance is activated by an arrow, it means that the system will enter the state which was most recently visited. If super-state D is activated by an arrow with event a in Figure 3.5, the most recently visited state (A or B) will be entered, or state A will be entered if this is the first time that the system has entered the super-state D. Figure 3.5: H-entrance 3 Requirements Specification 31 Orthogonality A n A N D decomposition of a system is notated in Statechart by splitting a box into components with dashed lines. When the orthogonal state is activated, the system is actually entering all of the A N D components simultaneously. Figure 3.6 shows an orthogonal state Z , consisting of A N D components A and B. Being in Z entails being in some combination of C or D with E , F , or G . Each component has the same properties as the super-state, such as X O R and default state. Harel calls state Z the orthogonal product of A and B. Entering Z from outside is actually entering the combination (C, E) because they are the default states. If event a then occurs in component A , the system will transfer state C to state D , resulting in combination (D, E). Figure 3.6: Orthogonal State Additional Statechart Features The following are some additional Statechart features; readers should refer to [10] for details. 3 Requirements Specification 32 — Condition Entrance: When some arrows enter the same super-state with the same event but different conditions, these arrows can be replaced by one arrow terminated at a condition entrance (Figure 3.7). Figure 3.7: Condition Entrance — Selection Entrance: Selection occurs when the state to be entered is determined in a simple one-to-one fashion by the 'value' of a generic event. This event is actually the selection of one of a number of clearly defined options, and the designer has chosen to model those options as states (Figure 3.8). Figure 3.8: Selection Entrance 3 Requirements Specification 33 Time-out: This notation is used to limit the lingering of the system in a state. "Time-out" is especially important in specifying a real-time system. Figure 3.9 shows the notation which is used in Statechart. / V W V S ^ A < 2 sec .timeout Figure 3.9: Time-out Notation Parameterized States: If different states have identical internal structure, they can be viewed as a single state with different parameters. Overlapping States: By overlapping states, one can know that there is an interrelationship between the states. Chapter 4 GrafTab — A PLC Requirements Specification Method As mentioned in Section 2.3, a requirements specification document tends to be potentially full of errors if it is written in an intuitive language. A n innovative specification method for a P L C system, called GrafTab, is presented in this chapter. GrafTab consists of a graphical description of the states in a P L C system and a tabular specification of the relationship among the inputs and outputs of the system. GrafTab is regarded as a semi-formal method because it has a precise syntax only (formal semantic has not been defined) in the graphical and the tabular description of the specification. A requirements specification of a drill machine will serve as a running example of GrafTab. 4A GrafTab The main goal of developing the new method is to specify a P L C system in a complete, correct, and readable way. Another goal is that the method should not be too difficult and complicated to learn. In order to accomplish these goals, four distinctive documents will be used in GrafTab. They are the system abstract, the monitored and controlled variables specification, the external interface document, and the system requirements document. The general idea behind GrafTab is that the P L C system 34 4 GrafTab — A PLC Requirements Specification Method 35 first is described briefly by the system abstract. The environmental variables are then identified in the monitored and controlled variables specification and the external interface document. Finally, the flow of the system states and the relationship among the environmental variables in each state are specified in the system requirements document. In the system requirements document, the flow of the system states is described by an Enhanced State Diagram (ESD), which is adopted from Statechart. The relationship among the environmental variables in each primitive state is specified by a State Specification (S-Spec) consisting of two functional tables, namely State Action Table (SAT) and Control Action Table (CAT). The four documents in GrafTab will be defined in Section 4.2. The syntax and properties of the E S D and the S-Spec will be described in Chapter 5. 4.2 Documents in a GrafTab Specification Formal definitions of the four documents in a complete GrafTab requirements specification are delineated in this section. 4.2.1 System Abstract Regardless of the size of a P L C system, a basic understanding of the system, such as the functionality of the system and the type of data input and output, is very important. The system abstract is to be written in English, the most accessible and readable language to most readers. When readers have any questions about the system, they must always refer to the other three documents for the formal description 4 GrafTab — A PLC Requirements Specification Method 36 of the system. In fact, the writer of the system abstract must explicitly require readers to refer to the other documents for a formal specification of the system. Even though no specific guideline will be provided in writing the system abstract, the bottom-line is that the abstract must precisely and concisely provide the basic functionality of the system and the type of data input and output. A long abstract will normally provide some unnecessary and ambiguous information about the system which adds burden to readers. 4.2.1.1 Running Example: Drill Machine The following is the system ab-stract of a drill machine. It uses simple and direct English to describe the overall function of the drill machine. It also includes a diagram to specify the hardware locations. Note that readers are asked to refer to other documents for a formal spec-ification of the system at the end of the abstract. System Abstract The conveyor of the drill machine is started when A U T O is selected by an operator. The operator then places a block of wood onto the conveyor. Once the wood is moved into the position which actuates LSI, the conveyor will stop, the CL1 will clamp the wood, and the drill station will move forward. When LS3 is closed by the drill station, the drill motor will be turned on. The drill station keeps on travelling until it is in full depth, which is indicated by closing LS4. This will initiate a 2 second dwell. After the dwell, the drill station moves backward. The drill motor stops when LS3 is released by the backward movement of the drill station. As the drill station reaches the home position and opens LS2, the drill station will stop, the clamp will open, and the conveyor will start forward. The wood is ejected when LS5 toggles, indicating that the cycle is complete. If an error occurs during the execution of the system, the PLC controller will 4 GrafTab — A PLC Requirements Specification Method 37 turn off all the motors and light up an emergency light. Then, the controller w i l l wait until all switches and motors are reset to their initial values. Readers should refer to Figure 4.1 for the hardware block diagram of the dri l l machine and consult the other three documents for the formal requirements specification of the system. AUTOo FWD Off o t Load Station Conveyor Motor Drill Motor LSI LS2 N.O. LS3 LS4 N-0.F=O LS5 N.O.-I Q FWD Clamp CL1 Figure 4.1: Hardware Block Diagram of the D r i l l Machine 4.2.2 Monitored and Controlled Variables Specification This document is used to specify the inputs and the outputs of a P L C system. It consists of the monitored variables section and the controlled variables section. 4.2.2.1 Monitored Variables The inputs of a P L C system are designated as the monitored variables in the GrafTab specification method because they are always monitored by the P L C system. In this document, each monitored variable should be given a name and a set of possible values. If a variable is used to represent some kind of special equipment that provides a constant value in a steady state of the system, that value also must be specified. For example, when the input equipment is a limit 4 GrafTab — A PLC Requirements Specification Method 38 switch, the normal value needs to be specified. However, no initial value for the monitored variables are to be specified, as the system specification document is able to describe the system correctly with any given input state. The following is a portion of the monitored variables in the drill machine. Monitored Variables: A U T O L S I — switch to start the process. — limit switch for indicating a — possible values: {On, Off} block of wood is in position — possible value: {Open, Close} — normal value: Open 4.2.2.2 Controlled Variables The outputs of a P L C system are designated as the controlled variables in GrafTab because they usually are used to control some external or internal terminals. Each controlled variable should be given a name and a set of possible values. Since the P L C controller allows one to force a value into a controlled variable, the initial value of each variable should be stated as well. If the controlled variable also is used as an input of the system, it is still considered to be a controlled variable, as this input can be referenced internally in the controller. In other words, there is no hardwiring between the output and the input of the controller. On the other hand, an internal output, such as a timer or counter, is considered to be a controlled variable, even though it does not have a physical terminal. The following is a portion of the controlled variables in a drill machine. 4 GrafTab — A PLC Requirements Specification Method 39 Controlled Variables: C L l T I M E R — clamp — possible values: {On, Off} — initial value: Off — internal drilling timer — possible value: {On, Off} — initial value: Off 4.2.2.3 Running Example: Drill Machine The complete monitored and controlled variables specification document for the drill machine are shown below. Monitored and Controlled Variables Specification Monitored Variables A U T O — switch to start the process — possible values: (On, Off} — : limit switch to indicate that a block of wood is in a preset position — possible values: {Open, Close) — normal value: Open LS2 — limit switch to indicate that the drill station is in the home position — possible values: {Open, Close} — normal value: Close LS3 — limit switch to indicate that the drill motor can be turned on or off — possible values: {Open, Close} — nonnal value: Open — limit switch to indicate that the drill station is at the full depth position — possible values: {Open, Close} — normal value: Open LSI LS4 LS5 limit switch to indicate end of cycle possible values: {Open, Close} normal value: Open 4 GrafTab — A PLC Requirements Specification Method 40 Controlled Variables Conveyor — conveyor motor — possible values: {On, Off) — initial value: Off CLl — clamp motor — possible values: {On, Off} — initial value: Off DrillStatFor — drill station forwarding motor — possible values: {On, Off} — initial value: Off DrillMotor — drill motor — possible values: (On, Off} — initial value: Off DrillStatBack — drill station backwarding motor — possible values: {On, Off} — initial value: Off EmLight — emergency light — possible values: {On, Off} — initial value: Off TIMER — internal drilling timer — possible values: {On, Off} — initial value: Off Error — internal error signal — possible values: {True, False} '-— initial value: False 4.2.3 External Interface Document In this document, the physical addresses of all the monitored variables and the controlled variables are specified. Each variable must be mapped onto a unique physical address. This document is divided into three sections: input addresses, output addresses, and internal addresses. 4.2.3.1 Input Addresses This section is used to specify the physical addresses of the monitored variables. Each of the monitored variables defined in Section 4.2.2.1 must be mapped onto a physical input address. The type of input also is specified such as D C input or analog input. 4 GrafTab — A PLC Requirements Specification Method 41 Input Addresses: A U T O L S I — Address: 1:000/0 — Address: 1:000/1 — Type: D C — Type: D C 4.2.3.2 Output Addresses The output addresses are the physical addresses of the external controlled variables defined in' Section 4.2.2.2. Each external controlled variable is mapped onto one physical output address. The type of output also is specified. Output Address: CL1 — Address: 0:001/0 — Type: D C 4.2.3.3 Internal Addresses This section is used to specify the physical ad-dresses of the internal controlled variables. Each internal controlled variable is mapped onto one physical address. One also specifies the address type such as timer, counter, integer, floating (real), or binary. Internal Address: T I M E R — Address: T4:0 — Type: Timer 4 GrafTab — A PLC Requirements Specification Method 42 4.2.3.4 Running Example: Drill Machine The following is the external interface document for the drill machine. Each variable defined in the monitored and controlled variables specification document is mapped onto a hardware address in the controller. External Interface Document Input Addresses A U T O — Address: 1:000/00 — Type: DC LSI — Address: 1:000/01 — Type: D C LS2 • — Address: 1:000/02 — Type: DC Output Addresses Conveyor — Address: 0:001/00 — Type: DC C L l — Address: 0:001/01 — Type: D C DrillStatFor — Address: 0:001/02 . — Type: DC Internal Addresses TIMER — Address: T4:0 — Type: Timer LS3 LS4 Address: 1:000/03 Type: DC — Address:' 1:000/04 — Type: DC LS5 — Address: 1:000/05 — Type: DC DrillMotor — Address: 0:001/03 — Type: DC DrillStatBack — Address: 0:001/04 — Type: DC EmLight — Address: 0:001/07 — Type: DC Error — Address: B3/150 — Type: Binary 4 GrafTab — A PLC Requirements Specification Method 43 4.2.4 System Requirements Document The system requirements document is the most important document in the GrafTab specification. It describes the functionality of a P L C system thoroughly and formally. The document first identifies the system states, using an Enhanced State Diagram (ESD), and then specifies the relationship among monitored and controlled variables in each primitive state with a State Specification (S-Spec). The E S D is a graphical description of the flow of the system states. In a conventional state diagram, the number of possible transitions between states increases exponentially with the number of states. The E S D , however, will minimize the number of transitions and states by adding a hierarchical structure and broadcast transitions into a state diagram. The E S D can be used to specify concurrent actions of the system as well. The formal syntax and properties will be presented in Chapter 5. Each primitive state in the E S D will be specified by a S-Spec in which two functional tables are used. The first table is called State Action Table (SAT) and the second is called Control Action Table (CAT). The fundamental function of SAT is to specify the relationship between the internal states (self-explanatory states within the primitive state of the ESD) and monitored variables. Each relationship corresponds to some specific actions, which are used to assign values to controlled variables and/or activate the C A T . The predicate formed by the monitored variables is a state condition. In accordance with the state condition and the current internal state, some specific 4 GrafTab — A PLC Requirements Specification Method 44 actions will be activated and the internal states will be alternated. The C A T table is used to specify the relationship between controlled variables and monitored variables. According to each predicate formed by the monitored variables, different values will be assigned to different controlled variables. The details of S-Spec will be described in Chapter 5. The system requirements document of the running example will go along with the description of the E S D and the S-Spec. Chapter 5 ESD and S-Spec In this Chapter, the syntax and properties of the E S D and the S-Spec, used in writing the system requirement document in GrafTab will be presented. The differences among GrafTab, Statechart and Functional Documentation Method will be discussed at the end of the Chapter. 5.1 Enhanced State Diagram (ESD) The Enhanced State Diagram (ESD) is similar to a conventional state diagram in the sense that both use graphical descriptions to show the flow among the system states in a P L C system. The conventional state diagram, however, is a flat diagram which shows all states on one level. Thus, the diagram becomes increasingly complicated and unclear as the number of transitions and states increases. It is also very difficult to present a parallel action in a conventional state diagram. In contrast, the E S D has a hierarchical structure in which the top-most level provides an outline of the system states and the lower levels contain more details of the system. The mechanism for specifying a parallel action is also present in the E S D . The following subsections will describe formally the syntax and properties of the E S D . 45 5 ESD and S-Spec 46 5.1.1 State A state is represented by a rounded rectangle in the E S D . There are two general and two special states in the E S D . The general states are a super-state and a sub-state; the special states are an entry state and a concurrent state. A state is activated if its predecessor state has already been activated and the transition condition of the entering transition is true. Right before the state is activated, its predecessor state is deactivated. Once the state is activated, it is kept active untilone of its exiting transition condition becomes true. The transition and transition condition will be described in Section 5.1.2. 5.1.1.1 Super-State and Sub-State The E S D has a hierarchical structure in that it consists of different levels of states. The top level state is called the super-state of the states beneath it; the states beneath the super-state are called sub-states. A super-state must have more than one sub-state if it is to exist. A sub-state can have its own sub-states; thus, it becomes a super-state. In other words, state can be a super-state, provided that there are some sub-states below that state in the hierarchical structure. If a sub-state does not have any sub-states, it is a primitive state and must be specified by a S-Spec. This will be described in Section 5.2. Each super-state has a super-state name and a super-state number in the top left-hand corner of the rounded rectangle. Each sub-state has a sub-state name and a sub-state number inside the rounded rectangle (Figure 5.1). The super-state number 5 ESD and S-Spec 47 has a hierarchical structure. For example, 0.1.2 tells you that this super-state is at level 2 of the E S D because there are two dots in the number; .2 is the sub-state number at level 1; .7 is the sub-state number at level 0. Note that level 0 is the top-most level in the E S D . Sub-State Name Sub-State Number Figure 5.1: Super-State and Sub-State 5.1.1.2 Entry State A n entry state is the starting sub-state of a super-state. When the super-state is activated by a transition which points to the boundary of the super-state, the entry state always will be activated first. The entry state is designated by ah entry transition, which is an open-ended transition inside the super-state (Figure 5.2). There can be only one entry state and entry transition within a super-state because only one sub-state can be activated when a super-state is active. 5 ESD and S-Spec 48 y Figure 5.2: Entry State 5.1.1.3 Running Example: Drill Machine Figure 5.3 shows the Level 0 E S D diagram of the drill machine. In this specification, the drill machine is divided naturally into two main super-states, the "Drill Machine" state and the "Error Han-dling" state. The "Drill Machine" contains the states of the normal execution of the system. The "Error Handling" state represents the states which the system enters when an error occurs in the "Drill Machine" state. The system starts when the entry condition " A U T O = On" is true. As described in Section 5.1.1.2, this condition leads the system to the entry state, "Start", of the "Drill Machine" state. The "Start" state is responsible for turning on the conveyor. In the "In Position" state, the conveyor stops, the clamp closes, the drill station moves forward and the drill motor is turned on. The drill station is stopped and the drill timer is turned on in the "Drilling" state. Once the drilling time is up, the system enters the "Backup" state, which is 5 ESD and S-Spec 49 responsible for moving the drill station backward and turning off the drill motor. Finally, when the system enters the "Home" state, it indicates that the drill station is back at its starting location; thus, the clamp opens and the conveyor starts again (The transition with the transition condition "LS5= Close" pointing to the boundary of the "Drill Machine" super-state means that it points to the entry state). If the system enters the "Error Handling" state, the system will shut down the drill machine and turn on the emergency light. The system stays at the "Error Handling" state until the error has been resolved successfully. V , ; ; Figure 5.3: Level 0 ESD diagram of the Drill Machine 5 ESD and S-Spec 50 5.1.1.4 Concurrent State A rounded rectangle, divided into components with dashed lines, represents a concurrent state (Figure 5.4) in the E S D . When the concurrent state is activated, the entry states in each component will be activated simultaneously. For example, in Figure 5.4, when concurrent state Y is activated by the transition with the condition 7 , the system enters the sub-states A and B at the same time. If the transition condition a becomes true, the system is transformed into the sub-states A and C. Note that we can only exit super-state Y from its sub-state C , if and only if the transition condition 6 is true and sub-state C is activated. Y;0.1 Figure 5.4: Concurrent State 5.1.1.5 Running Example: Drill Machine As described in Section 5.1.1.3, the "In Position", "Drilling" and "Home" states contain parallel actions. Thus, concurrent states can be used to describe these states (Figure 5.5). 5 ESD and S-Spec 5 1 Drilling; OJ S t o p S t a t i o n F x w u d Suit Tima 2 Figure 5.5: Concurrent States i n the D r i l l Machine 5.1.1.6 Common State A common state is formed if there is more than one transition entering the state (Figure 5.6). The transitions, however, must be mutually exclusive, meaning that only one transition can be enabled at any time. Figure 5.6: Common State 5 ESD and S-Spec 52 Both the "Error Handling" state and the "Start" state in the Level 0 diagram (Figure 5.3) of the drill machine are common states. The "Error Handling" state is a common state because every sub-state inside the "Drill Machine" super-state can travel to the "Error Handling" state via the transition with the condition "Error = True". Although the "Start" state is an entry state and there is only one entry transition in this state, it is nonetheless a common state. This is because if the entry transition is re-connected to the transitions terminating at the boundary of the "Drill Machine" state, the "Start" state actually is connected by the transitions with the conditions " A U T O = On", "Error = False", and "LS5 = Close" respectively. 5.1.2 Transition A transition is used to connect two states. Except for the entry transition, there is a transition condition associated with each of the transitions. A transition can be a normal transition, an entry transition, a non-entry transition, a selective transition, or a broadcast transition. 5.1.2.1 Normal Transition A normal transition is a basic transition which connects two states. If it points to the boundary of a super-state, it always is associated with the entry transition inside the super-state. 5.1.2.2 Entry Transition A n entry transition is an open-ended transition which connects to an entry state. Other than the entry transition in the first level (Level 0) of 5 ESD and S-Spec 53 the ESD, there will not be any transition condition along with any lower level entry transitions. This is because a lower level entry state is activated by the transition terminating at the boundary of the super-state of this entry state. For example, in Figure 5.7, when the super-state Y is activated by the transition condition 6, the sub-state A will be executed because it is connected with an entry transition. Entry Transition Transition Gondtion Figure 5.7: Entry Transition 5.1.2.3 Non-Entry Transition When a transition is not connected to the entry state in a super-state, it is called a nonTentry transition. In the ESD, this transition terminates at a bar inside a super-state (Figure 5.8a). When the sub-state A is zoomed in, the state which is connected by the non-entry transition must be specified (Figure 5.8b). 5 ESD and S-Spec 54 (a) (b) Figure 5.8: Non-Entry Transition 5.1.2.4 Selective Transition In the ESD, it is possible to have more than one transition originating from a state. Such transitions are called selective transitions because in the case that more than one transition becomes true simultaneously, only one transition can be selected. . In order to identify which transition is selected, a priority number is added to each transition (Figure 5.9). If no priority numbers are given, the left-most transition is assumed to have the highest priority, and the right-most one will have the lowest priority. A .1 /a. p Y \8 - ) / ( 2 ) - y i K Figure 5.9: Selective Transition with Priority Number 5 ESD and S-Spec 55 Since there are two transitions coming out from each of the sub-states (i.e., "Start," "In Position," etc.) in the "Dril l Machine" super-state (Figure 5.3), a priority number "(1)" is assigned to the transition with the condition "Error = True". The priority number for another transition can be omitted because there are only two transitions coming out of the sub-state. The transition with the condition "Error = True" has the highest priority because all the motors must be shut down immediately when an error occurs, no matter what is happening with the other transition conditions. 5.1.2.5 Broadcast Transition The notation of a broadcast transition in ESD is a double-headed arrow. A broadcast transition A broadcast transition either terminates at the boundary of a concurrent state, or originates from the boundary of: a super-state or a concurrent state. A broadcast transition implies that the transition will be used by more than one state. Use of broadcast transitions enhances the clarity of presentation in the ESD. When a broadcast transition terminates at the boundary of a concurrent state, it indicates that the transition is connected to all entry states in the concurrent state (Figure 5.10). The broadcast transition concept can be applied in any situation as long as the transition is connected to all the entry states. This broadcast transition applies even if there is another transition entering into some of the sub-states (Figure 5.11). A broadcast transition never terminates at a normal super-state because only one sub-state in the super-state can be executed at any time. 5 ESD and S-Spec 56 Y;0.1 Broadcast Transition Figure 5.10: Broadcast Transition in a Concurrent State Y;0.1 Y:0.1 Figure 5.11: Broadcast Transition with a Normal Transition in a Concurrent State A broadcast transition originating from the boundary of a super-state or a concur-rent state implies that the transition actually originates from all the sub-states within the super-state or the concurrent state (Figures 5.12 and 5.13). A broadcast transition can be used if and only if all the transitions from the sub-states have the same tran-sition condition. When there are several kind of transitions, including the broadcast transition, originating from a sub-state, the broadcast transition always has the lowest priority unless overridden by priority numbers. 5 ESD and S-Spec 57 Y; 0.1 0 Y; 0.1 B r o a d c a s t T r a n s i t i o n Figure 5.12: Broadcast Transition points out from a Super-State Y; 0.1 Y; 0.1 A .1 B .2 B r o a d c a s t T r a n s i t i o n Figure 5.13: Broadcast Transition points out from a Concurrent State 5.1.2.6 Running Example: Drill Machine By using the broadcast transi-tion, one can reduce the number of transitions needed in the drill machine speci-fication. First, the transition with the condition "Error = True" can originate from the boundary of the super-states in all levels of the diagram (e.g., "Drill Machine" super-state) because it is connected to each sub-state in those super-states. Secondly, for the same reason, the transition with the condition "Error = False" can originate from the boundary of the "Error Handling" super-state in the Level 0 of the ESD. The following diagrams show the final ESD specification of the drill machine. 5 ESD and S-Spec 58 Figure 5.14: Level 0 of the ESD specification of the Drill Machine 5 ESD and S-Spec 59 LS4-»Clo» Backup; 0.4 Station Backup LSI-Open. Stop Drill Motor BlN=TlUB S t o p | O p e n 1 f . Start B a c k u p 1 C l a m p 1 C o n v e y o r .1 i ! .2 ) 1 I "3 Figure 5.15: Level 1 of the E S D specification of the Dril l Machine 5.1.3 Parent Bubble In a conventional state diagram, it is difficult to specify a common state which is connected back to its previous states by the transitions which have the same transition condition (Figure 5.16a). This state transition is represented by a transition pointing to a circled P in the ESD (Figure 5.16b). This circled P is called a parent bubble. It possesses the advantage of reducing the number of transitions needed in the diagram. The parent bubble can be used in an ESD diagram if and only if it is connected to a common state and all the exiting transition conditions from the common state are the same. 5 ESD and S-Spec 60 If t h e p r e c e d i n g s t a t e o f s t a t e C i s s t a t e A a n d c o n d i t i o n p i s t r u e , t h e s y s t e m t r a n s i t s t o s t a t e A . (a) (b) Figure 5.16: Parent Bubble 5.1.4 Summary of the E S D Table 5.1 summarizes the syntax of the ESD. The main function of each notation used in the ESD is delineated. Name Notation Function Remark State Representing a system state. Transition a Connecting states together. Except for an entry transition (excluing the entry transition in the Level 0), each transition must go along with a transition condition. Super-State Y;0 Representing an abstraction view of a set of sub-states. A super-state must contain more than one sub-state. Table 5.1 Summary of the ESD (Continued) J ESD and S-Spec 61 Entry-State CO Indicating a starting state in a super-state when that super-state is activated by a transition terminating at the boundary of the super-state. There is only one entry state in a super-state. Concurrent State A ; 0.1 C \ i ^ V ! ! J Representing a parallel exeution of the sub-states. Each component of a concurrent state must have an entry state. Common State a P T A 5 Indicating that a state is connected by multiple transitions. Only one transition can enter a common state at any time. Entry Transition A state which is pointed to by this transition is an entry state. No transition condition is needed except the entry transition of the system in Level 0 of the ESD. Non-Entry Transition Indicating that a transition points to a specific sub-state inside a super-state. Selective Transition a p y 8 (1) (2) (3) (4) Indicating that only one of the transitions can be selected at any time. Priority numbering should be used; otherwise the left-most transition has the highest priority. Table 5.1 Summary of the ESD (Continued) 5 ESD and S-Spec 62 Y;0.1 r \ ) A broadcast transition can Broadcast Transition A ; 0.1 c \ \ ) P Denoting that a transition is connected to multiple states. only terminate at the boundary of a concurrent state. Parent Bubble a An indication of a state transition from a common state to its previous state. Table 5.1 Summary of the ESD 5.2 State Specification (S-Spec) The state specification (S-Spec) is the lowest level specification in the E S D . In other words, when a sub-state (primitive state) cannot be decomposed any further, it is described by a S-Spec, The S-Spec consists of a State Action Table (SAT) and a Control Action Table (CAT). When a primitive state is executed, the controller executes the SAT first. Then depending on the actions specified in the SAT, the controller could assign a value to a controlled variable, execute the C A T , or both. Except for primitive entry states in a concurrent state, each primitive state must have its own pair of SAT and C A T . A l l primitive entry states in a concurrent state J ESD and S-Spec 63 can be specified by one pair of SAT and C A T because all the primitive entry states have the same state condition. 5.2.1 SAT The S A T is like a simple finite state machine in a primitive state. It specifies the immediate relationship between the internal states and the monitored variables. This relationship only occurs at the moment of the table being activated. In other words, the S A T is only valid at the moment that a primitive state is activated because the value of the monitored variables is changing constantly. The SAT of a primitive state must be executed if this primitive state is currently activated. The row heading contains the internal states, which must be primitive and self-explanatory. The column headings are the state conditions, which are formed by the monitored variables. The cells specify the action and the next state (Figure 5.17). The format of the cells is A C T I O N S / N E X T _ S T A T E . In the A C T I O N S field, multiple actions can be specified; however, only one next state can be specified in the N E X T _ S T A T E field. A SAT is complete if and only if all cells are filled and the state conditions have an opposite relationship. For example, if one o f the state condition is equal to " A U T O = True", another condition must be equal to " A U T O = False". 5 ESD and S-Spec 64 State Conditions Internal States ffftSfSffStSffSfSSSSfStff/SftfSSfSSSSfSS. y / y / y y y / y / y y y y y y y / y / y y y / y / y y y / y y y y / y y y y y Actions/Next State Actions/Next State Actions/Next State Actions/Next State Figure 5.17: Format of SAT A cell in the table can be executed if and only if its corresponding state condition is true and the corresponding internal state is the current system internal state. Once the cell is executed, the A C T I O N S will be carried out first and then the internal state will be changed to the N E X T _ S T A T E . The A C T I O N S could be used to activate the corresponding C A T , and/or to assign a retentive value to a controlled variable (is called assignment action), or both. When there are multiple assignment actions, they will be executed simultaneously because all actions have the same state condition. Since the controlled variables in the assignment actions can be used as the conditions in the corresponding C A T , the assignment actions and the C A T must be executed sequentially if they are placed together in the A C T I O N S field. The state specified in the N E X T _ S T A T E field must be one of the internal states in the row heading of the current SAT table. The state condition must specify the expected value of all monitored variables at the moment the state is entered. If there is a large number of monitored variables, the state condition will become lengthy and complicated. Two functions are defined 5 ESD and S-Spec 65 in order to make the state condition simpler and clearer. The first function is used to specify a new value which has been assigned to the monitored variable at the immediate predecessor state but has not been changed during the state transition. This function is defined as follows: UC(mo,mi...,mn) = (mo = £n ) A ( m i — xi) A . . . A (mn = xn), where m n , m i . . . , mn are the monitored variables, and XQ,X\, ...,xn are the values that have been assigned to the monitored variables at the immediate predecessor state. The function is useful when the current state is a common state, and the preceding states assign different values to the monitored variables. This function also helps check for any error during the state transition. For example, when the state condition, UC{mo,m\), is being checked in the current state, and if the value mo is not equal to its assigned value at the immediate predecessor state, one will know that an error occurs during the state transition. The second function is used to specify that all monitored variables stated in the function are untouched by the previous state. In other words, the previous state has riot assigned any new values to these monitored variables. This function is defined as follows: UT(mQ,m\....,rnn) — (mo = yo) A ( m i = y\) A ... A ( m n = yn), where mo , m i m n are the monitored variables, and yo, y\,yn are the most recent values assigned to the monitored variables. One can use this function in the current state condition when the value of a monitored variable has not been changed at the immediate predecessor state. 5 ESD and S-Spec 66 5.2.1.1 Running Example: Drill Machine Table 5.2 is the SAT of the "Start" sub-state in the "Drill Machine" super-state (Figure 5.14). The predicate of the state condition is written outside the table because it is too long to be placed in the table. In this predicate, the function <yC(ran, m i m n ) is used to describe the values of the LS5 and the Conveyor because they are changed in the one of the preceding states: "Home" sub-state or "Error Handling" super-state. The "=" sign is an equality operator, and the ":=" is an assignment operator. SAT: Start; 0.1 Let IniiCon = (LS\ = Open) A (LS2 = Open) A (LS3 = Open) A (LS4 = Open)A UC(LS5, Conveyor) A (CLl = Off) A (DrillStatFor = 0 / / ) A (DriUMotor = Off) A (DrillStatBack = Off) A (TIMER = Off) A (Error = False) InitCon - True InitCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle Table 5.2 The SAT for the "Start" sub-state 5.2.2 CAT This table is used to specify the relationship between controlled variables and monitored variables. The controlled variables and the monitored variables (conditions) are placed in the row headings and the column headings of the table respectively. The cells are used to specify the resulting values of the controlled variables (Figure 5.18). This table can be executed if and only if the action " C A T " in the SAT is activated. 5 ESD and S-Spec 67 Conditions Controled Variables SSSSSSSSSSfSSSfffSSSSSfSSfSfSSfffSffSfSS ///////•///////////////•////////////////// '//////////////////////////////////////// Value Value Value Value Figure 5.18: Format of CAT The value specified in the cell is assigned to the corresponding controlled variable if and only if the condition is true and the table has been activated by the SAT. The value assigned to the controlled variable is retained until a different value is reassigned by a different condition. Note that only one value can be assigned to a controlled variable at any time; however, more than one controlled variable can be assigned a new value simultaneously. A C A T is complete if and only if all cells are filled and the conditions have the opposite relationship. 5.2.2.1 Running Example: Drill Machine During the execution of the C A T table of the "Start" state (Table 5.3), if " A U T O " is equal to "On", the con-trolled variable, "Conveyor", will be assigned the value "On"; otherwise it will be assigned the value " O f f . C A T : Start; 0.1 A U T O = On A U T O = Off Conveyor:= On Off Table 5.3 The CAT for the "Start" sub-state 5 ESD and S-Spec 68 5.2.3 S-Spec for a Concurrent State A l l the primitive entry states can be specified by one special S-Spec due to the fact that these states must have the same state condition and internal states. In other words, there is only one SAT for these primitive entry states. A special C A T (Figure 5.19) is needed to distinguish the assignments for each entry state. This special table has one extra column, allocated at the right-hand side of the normal C A T , for specifying the entry states or the concurrent state itself. When an entry state is not activated, its assignments will not be executed. However, the assignments in other entry states will still be executed as long as they are active. Controled Variables Conditions ysssssssssssss.. . yssssssssssssssss Value Value Value Value Entry States or Concurrent State Figure 5.19: Format of CAT for the Entry States of a Concurrent State 5.2.3.1 Running Example: Drill Machine The 'In Position" sub-state in the E S D specification of the drill machine is a concurrent state with entry states and a sub-state. The C A T table for the entry states of a concurrent state is used here to describe the assignments in the state. Each row in Table 5.4 represents the assignment for the entry state specified in the right-hand column of the table. For example, the 5 ESD and S-Spec 69 second row of the table is for the "Stop Conveyor" state. The assignment in the last row of the table is for the "In Position" concurrent state itself, meaning that this row applies to all entry states in the "In Position" concurrent state. The complete S-Spec of the drill machine can be found in Appendix B. SAT: In Position; 0.2 Let InPosCon = (AUTO = On) A (LS5 = Open) A (Conveyor = O n ) A UT(LS2, LS3, LS4, CLl, DrillStatFor, DrillStatBack, DrillMotor, TIMER, Error) InPosCon = True InPosCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle Figure 5.20: The S A T for the "In Position" concurrent state CAT: In Position; 0.2 L S I = Close LSI = Open Conveyor := Off no_opt Stop Conveyor C L l := On no_opt Clamp Wood DrillStatFor := On no_opt Station Forward Error := no_opt True In Position Table 5.4 The C A T for the "In Position" concurrent state 5.3 Evaluation of GrafTab The syntax of each document in GrafTab was presented in Chapters 4 and 5. In the next section, the strengths and the weaknesses of GrafTab are discussed. Then the differences among GrafTab, Statechart, and Functional Documentation Method are discussed. 5 ESD and S-Spec 70 5.3.1 Strengths and Weaknesses of GrafTab GrafTab is capable of specifying a P L C system completely and unambiguously. Regardless of whether the P L C system is a discrete real-time system or an analog real-time system, one can use GrafTab to describe the system because the first three documents (Section 4.2.1, 4.2.2 and 4.2.3) in GrafTab are essential to every system. The system then is modelled by a set of the system states in the system requirements document. The only difference in modeling a discrete real-time system and an analog real-time system is the way the transition conditions and the state conditions are specified. In a discrete system, one can specify a condition as a discrete event such as " Switch^! = 1". However, in an analog system, the condition will be a continuous event such as " V t ( t l < < < f o ) S witch-\(t) = 1" where Switch-l(t) is a function of time. The value assigned to the controlled variables is retentive in all systems. The notations in the E S D are sufficient to cover most of the situations in the specification of a P L C system. The E S D has pre-defined notations to describe a normal state transition, a parallel state transition (Section 5.1.1.4) and a "parent" state transition (Section 5.1.3). The number of states and transitions needed in a state diagram is reduced significantly by the use of broadcast transition notation and common state notation in the E S D . The hierarchical, structure of the E S D provides a clear view of the system state flow. Finally, the description of a primitive state is written precisely in a S-Spec. 5 ESD and S-Spec 71 One situation not directly covered by the E S D is that there is no special notation dedicated to specifying the maximum duration that a controller can stay in a state. This situation, however, can be specified by using a concurrent state with one component as a time-out state. For example, in Figure 5.21, there is a timer instruction in the Time Out state. When the time of the timer is equal to the maximum duration that the controller can stay in state A , the transition "T(TIMER) = x" will become true. Thus, the controller will transit to a state which handles the time-out situation. Y ; J U iT Time Out ( \ A -•• I ' 2 J T(TIMER) = x Note: T(TIMER) is a function which returns the time of the TIMER. x is the duration that a controller can stay in state A. Figure 5.21: Specifying Time Out Situation in the ESD Although GrafTab provides a complete specification of a P L C system, it mainly deals with the software behavior. Only one document, the external interface docu-ment, is directly related to the hardware part of the system. If one wants to obtain a truly complete specification of the whole system, he/she will need to write some additional documents for the hardware parts of the system. For example, there should be a document for specifying the hardware configuration of the system, as well as a document for describing the communication protocol between hardware modules. 5 ESD and S-Spec 72 One also should specify the non-functional requirements of the system such as the environmental constraints, user interface, reliability, and maintainability of the system. 5.3.2 Differences Among GrafTab, Statechart, and Functional Documentation Method GrafTab as a method for writing requirements specification possesses features that distinguish itself from both Statechart and Functional Documentation Method (FDM). The distinctive features are listed below: — Uniqueness GrafTab is specially designed for writing a requirements speci-fication for a P L C system. It contains four documents (Section 4.2) which are essential to a P L C system. In contrast, F D M and Statechart aim at the specification of a general computer system. They lack some of the essential specification documents of a P L C system. For example, the system state of a P L C system must be specified, but F D M does not include any document to describe this. Statechart does specify the states of the system, but does not document any physical information such as physical addresses of the variables. — Well Defined Writing Format GrafTab not only defines which documents are required, but also provides. the writing format for each document. It allows one to develop a mechanism for transforming the documents into an executable program. In F D M , however, the writing format of the documents is not specified. Different writers will use different writing styles for the same 5 ESD and S-Spec 73 document. Hence, there is no way to form a transformation mechanism and readers will not be able to understand the documents easily. — Optimal Combination of States and Functions F D M focuses on the mathe-matical functions or relations among environmental variables. Statechart tries to specify the flow of the system states. Both of these methods are inadequate for specifying a PLC system because documenting the relationships among the environmental variables and the system states are equally important in a PLC system. The E S D in GrafTab is used to specify the system states and the S-Spec is responsible for documenting the relationships. GrafTab provides a unique environment for specifying a PLC system. — Useful ESD Notations The E S D and Statechart both try to describe the flow of the system state by using a hierarchical state diagram. The E S D , however, is more systematic, easier, and more powerful than Statechart. First, systematic naming and numbering conventions in the E S D makes the diagram more traceable. Information about state level and linkage between super-state and sub-states can be traced easily from the state number. Secondly, E S D is easier to learn and read because it has only three major components (state, transition and parent bubble). Designers can learn the E S D easily and quickly, and readers can understand the diagram without any difficulty. A final advantage of the E S D is that the priority number in the selective transition (Section 5.1.2.4), the 5 ESD and S-Spec 74 parent bubble (Section 5.1.3), and the S-Spec for a primitive state offer a clearer and more powerful tool for specifying a PLC system than does Statechart. Chapter 6 GrafTab Specification To Executable Program In this Chapter, the mechanisms for transforming a GrafTab requirements speci-fication into a S F C program and a ladder diagram program are presented. Note that a S F C and a ladder diagram refer to a S F C program and a ladder diagram program respectively in the following discussion. One should refer to Section 2.2 for the definitions of instruction, rung, step, transition, step file, and transition file. 6.1 F r o m Specification to a S F C or a Ladder Diagram The following transformation techniques are used when one wants to convert a GrafTab requirements specification into a S F C or a ladder diagram. 6.1.1 State Condition A state condition is the entry condition of a state. It must be checked before any actions specified in a S-Spec can be executed. In order to make a ladder diagram clearer and more systematic, the verification of the state condition is programmed as a subroutine. The code size also can be reduced because a subroutine can be reused if different states have the same state condition. In the Allen-Bradley controller, a program is scanned. repeatedly. The state condition, however, needs to be verified only at the moment of entering the state. After that, as long as the system stays in the same state, the state condition will no 75 6 GrafTab Specification To Executable Program 76 longer need to be verified. In order to resolve this conflict, a flag, called check flag (cf), is introduced to the state condition rung as its rung condition. When the flag is false, the state condition rung will be executed. After the execution, the flag is set unconditionally to true (i.e., latched) so that when the controller rescans the program, the state condition rung will not be executed again (Figure 6.1). The flag will be reset when the exiting transition condition of the state is true. cf_l -(C)— RET — Figure 6.1: Check Flag 6.1.2 Retentive Value In the E S D , the value of a variable is retained between states. The output value of a non-retentive instruction, however, is reset when its rung condition becomes false in a ladder diagram or when a step transition occurs in a S F C . In order to satisfy the E S D retentive property, retentive instructions must be used for all variables in a S F C or a ladder diagram. For example, the "Retentive Timer On" (RTO) instruction is used if the variable is a timer. A n "Output Latch" (OTL) instruction is used to assign a true value to a variable. cr_ -3/E JSR State_Con 6 GrafTab Specification To Executable Program 77 6.1.3 Resetting Variables Since the value of a variable is retentive, we must reset it at the state specified in the E S D . Internal variables (e.g., check flag or state condition) of the current active state must be reset when the current state is deactivated. For example, the internal variables of the current state can be reset in the transition rung (when the transition condition becomes true) of the current state, or in the first rung of the succeeding state. 6.1.4 Reconnecting Broadcast Transition and Entry Transition Before the transformation begins, one must expand all the broadcast transitions and the entry transitions by reconnecting them to their respective states. For example, a broadcast transition originating from the boundary of a super-state needs to be reconnected to all the sub-states in that super-state. A n entry transition in a super-state should be connected to the transition which terminates at the boundary of the super-state. By doing the reconnection, one can know directly how many transitions originate from and terminate at the state. 6.1.5 Primitive State A S-Spec is represented by a step in a S F C or a subroutine file in a ladder diagram. The state condition used in a SAT is transformed into a JSR (jump to subroutine) rung, as suggested in Section 6.1.1. The actions in a cell of that S A T will be converted into a rung called an action rung. Each Column of a C A T will then be converted into 6 GrafTab Specification To Executable Program 78 one rung called an assignment rung. For example, Tables 6.1 and 6.2 are converted into Part I (action rung) and Part II (assignment rungs) of Figure 6.2 respectively. SAT: Motor; 0.1 Let InitialCon = (Switch2 = Off) A (Switch^ = On) A (Error = False) InitialCon = True InitialCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle Table 6.1 SAT — S-Spec of a Primitive State CAT: Motor; 0.1 Switch_l = On Switch_l = Off Motor := On v Off Table 6.2 CAT S-Spec of a Primitive State Part I Part IT cf -3/E-InitialCon -3/E-JSR InitialCon Error — InitialCon Switchl M o t o r InitialCon Switchl Motor -a H / E - ^ -Switch3 Switch2 Eiior InitialCon H H/H/E— (L) R E T Figure 6.2: Transforming Primitive State 6 GrafTab Specification To Executable Program 79 6.2 From Specification to a SFC 6.2.1 Initialization The first step of a S F C is used to initialize all the controlled variables and internal variables. This step is used as the initial file because there is no transition placed before the step. Two rungs are needed in this step. The first rung is for resetting all the internal variables, and the second rung is for initializing; the controlled variables. 6.2.2 Basic State and Transition A l l primitive states are transformed into steps in a S F C . Since a super-state is just an abstract view of its sub-states, it does not need to be converted into a S F C . It will, however, provide the sequencing information in a S F C . The meaning of transition in an E S D is the same as that in a S F C . The transition condition is specified in the transition file. 6.2.3 Selective Transition A set of selective transitions in the E S D is converted into a set of selection branches in a S F C (Figure 6.3). Since the left-most selection branch always has the highest priority, the selective transition with the highest priority must be located at that branch. 6 GrafTab Specification To Executable Program 80 Figure 6.3: Transforming Selective Transitions 6.2.4 Common State In a S F C , different steps can be referred to the same file. Thus, each entering transition of a common state is converted into a transition in a S F C , which is then connected to a step with the same reference file number (Figure 6.4). Figure 6.4: Transforming Common State 6.2.5 Loop In the E S D , a loop is formed, for example, when state A goes to state B via the transition with condition /?, and then state B goes back to state A via the transition with condition 7. This is mapped onto a S F C by using a label and G O T O pair (Figure 6.5). 6 GrafTab Specification To Executable Program 81 a 001 : A .1 B .2 A - P B — Y GOTO 1 Figure 6.5: Transforming Loop 6.2.6 Concurrent State If a concurrent state contains only the primitive entry states and one exiting transition (simple concurrent state), it can be transformed into a step and a transition as a normal primitive state (Figure 6.6). This condition occurs because there is only one S-Spec for this concurrent state. Y; 0.1 B .2 -a => Y -P S-Spec of Y -End-Figure 6.6: Transforming Simple Concurrent State 6 GrafTab Specification To Executable Program 82 A concurrent state is complex if it contains the entry states, sub-states and one exiting transition. A complex concurrent state is converted into a set of simultaneous branches in a S F C (Figure 6.7). Each component of the concurrent state is transformed into one of the simultaneous branches. Note that only the entry state allocated in the left-most branch will be required to verify the state condition because all branches are run simultaneously. Y; 0.1 — a Figure 6.7: Transforming Complex Concurrent State 6.2.7 Concurrent State with Selective Transition If a set of selective transitions serves as the exiting transitions of a complex concurrent state (Figure 6.8), these transitions will be converted into a set of selection branches, which are allocated in one of the simultaneous branches in a S F C . However, when the selection branches and the simultaneous branches are combined, some extra steps and transitions will result because both branches create their own starting and ending step and transition pair. Thus, some steps and transitions within the 6 GrafTab Specification To Executable Program 83 simultaneous branches and the selection branches will be dummy ones. The following steps provide a transformation procedure to resolve this problem. Step 1: Create simultaneous branches. The number of simultaneous branches is equal to the number of components in the concurrent state. The exiting transition created by the simultaneous branch is a dummy transition6. The step in one of the branches in which the selection branches will be located is a dummy step7 (Figure 6.9a). Step 2: Add a step and transition pair in the simultaneous branches. Other than the state with the selective transitions, each pair of state and transition is transformed into a pair of step and transition in the S F C (Figure 6.9b). Figure 6.8: Concurrent State with Selective Transition 6 Dummy transition is a transition file without any rung. 7 Dummy step is a step file without any rung. 6 GrafTab Specification To Executable Program 84 Step 3: Create selection branches. The selection branches should be allocated at a branch which corresponds to the state with selective transitions. The number of branches in the selection branch should be equal to the number of selective transitions in that state. (Figure 6.9c). Step 4: Create selection branches right after the simultaneous branches. The num-ber of branches should be the total number of exiting selective transitions in the concurrent state. The step created by this selection branch will be a dummy (Figure 6.9d). Dummy Step a Step and Transition Pair (a) a - Dummy Transition +-8 Selection Branches Y Dummy Step Dummy Transition ~ (o) - Dummy Transition (b) ± L -t-T Dummy Step Dummy Step | Selection Branches -T (d) Figure 6.9: Putting Simultaneous Branch and Selection Branch Together 6 GrafTab Specification To Executable Program 85 6.2.8 Parent Bubble When a common state is connected to a parent bubble, it is transformed into a set of step and transition pairs with the same file reference number in a S F C . Each transition in the S F C then is connected back to its parent step (Figure 6.10). A B X .1 .2 .n ® Figure 6.10: Transforming Parent Bubble 6.3 From Specification to a Ladder Diagram 6.3.1 State Each state in the E S D is transformed into a subroutine file embedded in a ladder diagram. Since a subroutine also can call up other subroutines, the hierarchical structure of the E S D is preserved. The subroutines within a subroutine can be viewed as the sub-states within a super-state (Figure 6.11). The term "state" and "subroutine" will be used interchangeably in the following discussion. The first ladder diagram file (File 2 in Allen-Bradley controller) is equivalent to Level 0 of the E S D because a controller always will execute this file first. The first 6 GrafTab Specification To Executable Program 86 Note: JSR = Jump to Subroutine Figure 6.11: Transforming States into Subroutines rung of File 2 contains an "examine off" instruction (XIO) for an internal variable as the rung condition, and a "jump to subroutine" instruction (JSR) as the rung output. The internal variable is set to false manually 8 before the system can be started. Then this variable is set unconditionally to true in the subroutine where the JSR instruction will jump to, thus, the subroutine only will be executed once. The subroutine is responsible for initializing all controlled variables according to the specification and resetting all the internal variables. The structure of the subroutine is described in Section 7.1.2.1. Other rungs in File 2 represent the sub-states in Level 0. In order to obtain a common structure for all the primitive subroutines, the following procedure is used when a primitive state is transformed into a ladder diagram. The first rung of the subroutine is used to unlatch the internal variables. If a group of primitive states is a set of sub-states in a super-state, only the primitive entry state will contain an unlatching rung. The second rung is used to jump to the state In Allen-Bradley PLC controller, one can force a value to any variables. 6 GrafTab Specification To Executable Program 87 condition verification subroutine, and then there are the rungs for the S-Spec (Section 6.1.5). The rung before the R E T rung (last rung in the diagram) is a transition rung (Section 6.3.2). If a set of selective transitions are used, each transition requires one rung. The R E T instruction always will return the updated values of the internal state variables and the global variables (if there are any) to the caller. 6.3.2 Transition Each exiting transition in a primitive state is transformed into a transition rung in that primitive state subroutine, with the transition condition being the rung condition. Each rung is associated with an internal variable called a state transition variable (stv). When a transition condition becomes true, its stv is latched. Once a set of stv variables is defined, the rung condition of a "jump to subroutine" rung in a super-state file (i.e., File 2) can be formed. The rung condition is constructed by using the stv variables of the entering and exiting transition of the state. In order to jump to a subroutine, the stv of the entering transition and the exiting transition of a state must ' be true and false respectively (Finger 6.12). Since a stv is latched if its transition condition is true, it must be unlatched when the state activation no longer is dependent on it. It is recommended that a stv is unlatched at least two states after it has been latched. For example, in Figure 6.12, stv_f3 is unlatched within the subroutine C. 6 GrafTab Specification To Executable Program 88 stv a stv B stv b stv 7 stvjf stv_5 JSR A JSR B JSR C IE $r\ RET Figure 6.12: State Transition Variable In the rung condition of a "jump to subroutine" rung, the stv variables of a set of selective transitions are placed together serially (ANDed). In contrast, the stv variables of the transitions terminating at a common state are put in parallel (ORed) (Figure 6.13). <x\ p T A A .1 s t v _ a S t v - E s ^ - 1 ! s t v j ; s t v . s_tv_p s t v y , s t v S . 4H JSR A Figure'6.13: Common State and Selective Transitions If an exiting transition condition of a primitive sub-state is set to true in its S-Spec, one should combine that action or assignment rung and the transition rung together to reduce the size of the program. This can be done because the rung condition of the transition rung is equal to the output of the action rung or assignment rung. For 6 GrafTab Specification To Executable Program 89 example, if the primitive state of the S-Spec (Tables 6.1 and 6.2 in Section 6.1.5) has an exiting transition with a transition condition "Error = True", this transition and the action "Error := True", specified in the SAT (Table 6.1), should be combined into one rung. Thus, Part I of Figure 6.2 is transformed to the rung in Figure 6.14. -a/E-InitialCon Error stv_Error Figure 6.14: Combining Act ion Rung and Transition Rung 6.3.3 Selective Transition If a set of selective transitions is used as the exiting transitions of a state, each transition rung must be mutually exclusive, and the priority of the transitions must be preserved. In order to accomplish these two conditions, the rung condition of the transition with priority i will depend on its transition condition and the stv variables of the transitions with priority higher than / (Figure 6.15). 6 GrafTab Specification To Executable Program 90 A .1 (L: X\ stv_e stv_r| " E ^ E — = — - ( L : ^ S t V _ E S t V _ T | S t V _ C H H O E - ( L ; 6 stv_e stv_ri stv_C stv_8 HH/H/H/E (LV Figure 6.15: Transforming Selective Transition 6.3.4 Super-state As mentioned in Section 6.3.1, all states are transformed into subroutines. The sub-states of a super-state are equal to the JSR rungs in the main subroutine of the super-state. Once the state transformation is done, the rung condition of each JSR rung must be assembled in such a way that no extra stv variables are created. In Figure 6.16, super-state Y contains sub-states A and B. Sub-state A has its own sub-states, namely states C and D . In order to maintain the hierarchical structure in a ladder diagram, super-state Y is transformed into a subroutine which contains two JSR rungs for sub-states A and B. The first rung is conditioned by the stv of the entering transition of super-state Y and the stv of the exiting transition of sub-state A . The second rung is conditioned by the stv variables of the entering transition and the exiting transition of sub-state B . Then, in the ladder diagram of sub-state A , two JSR rungs are formed for sub-states C and D. The condition of jumping into sub-state 6 GrafTab Specification To Executable Program 91 C depends upon the stv variables of the entering transition and the exiting transition of sub-state C. Note that the entering transition of sub-state C is the same as that of super-state Y . Hence, they have the same stv. In the subroutine file of sub-state D , the stv of its exiting transition is equal to the stv of the exiting transition of sub-state A . The stvjx (entering transition of sub-state A) is not unlatched in sub-state D because sub-state D is not the next state of sub-state A . It is unlatched in the succeeding state of sub-state B . Y; 0 :v y stv A ; 0.1 / a JSR A 'i— JSR L B C \ 5 .1 s t v j stv 8 HHP / a T ' JSR L C JSR D 5 H e stv_5 s t a t e _ c o n D -Cuv-RET HE- slv_P -(b) s t a t e _ c o n B RET Note: state_conX = state condition variable of state X Figure 6.16: Transforming Super-State 6 GrafTab Specification To Executable Program 92 6.3.5 Concurrent State A concurrent state containing only a set of primitive entry states is converted into one ladder diagram in the same way that a primitive state is converted into a ladder diagram (Section 6.1.5). However, if the concurrent state also contains some sub-states, the following transformation steps must be followed in order to obtain a correct result. Step 1: A rung is created for the state condition of the entry states (Figure 6.17 Step 1). Y ; O . l Step 1 Step 2 Step 3 Step 4 Step 5 cf_l -3/E-J S R S t a t e C o n . o f D e f a u l t S t a t e s S-Spec of A S-Spec of B stv -3/1 -Spec of C stv_p -<D-:f 2 H/E-J S R S t a t e C o n . o f S-Spec of D H E -stv_7 - (L> RET Figure 6.17: Transforming Concurrent State 6 GrafTab Specification To Executable Program 93 Step 2: A rung with branch instruction is created for the S-Spec of the entry states which do not connect to other sub-states (Figure 6.17 Step 2). Step 3: Trie S-Spec of each entry state, which is connected to sub-states, is converted into one rung. Its rung condition will depend on the stv of the exiting transition of the entry state (Figure 6.17 Step 3). Step 4: Each exiting transition which is connected to a sub-state of the entry states is converted into one transition rung (Figure 6.17 Step 4). Step 5: Each sub-state is transformed into one JSR rung. Its rung condition will depend on the stv variables of the entering transition, and the exiting transition of the sub-state (Figure 6.17 Step 5). 6.3.6 Unlatching Flag The first rung of a primitive subroutine is used to unlatch the internal variables. This rung needs to be executed only once even if the subroutine is being rescanned, because those variables might be referenced in the other rungs of the subroutine. Thus a flag called unlatching flag (uf) is added to the first rung as a rung condition. The initial value of the. unlatching flag should be false so that the first rung can be executed. The flag is then set to true (latched) in the output of the first rung so that, during the rescan cycle, the rung is not executed again (Figure 6.18). This flag must be reset (i.e., unlatched) either in the transition rung or the first rung in the next state. 6 GrafTab Specification To Executable Program 94 uf_l stv_l <u> stv_2 uf_l Figure 6.18: Unlatching Flag 6.3.7 Loop When a loop in the E S D is transformed into a ladder diagram, the rung condition of the starting state will depend upon all the stv variables of the entering transition and the exiting transition of the state. In other words, the stv of the exiting transition must be false and one of the entering stv must be true in order to activate the starting state. To activate the second state of the loop, the stv of the entering transition must be true and the exiting stv must be false (Figure 6.19a). As a result of this dependence condition, the stvs of the exiting transition of the current state and the next state must be latched and unlatched respectively when the exiting transition condition of the current state becomes true (Figure 6.19b,c). 6 GrafTab Specification To Executable Program 95 A .1 B .2 isv a r~3 En isv v -9F isv_p -3/T> JSR A isv B isv Y HE— ] /E -JSR B P i s v j M E r—(L)— isv v •—(uy-RET (a) (b) Y isv_Y isv B RET (C) Figure 6.19: Transforming a Loop 6.3.8 Parent Bubble A parent flag, pf, is added to each state which is connected to the common state with a parent bubble. For example, states A and B in Figure 6.20 will have their own parent flags. When the transition condition 7 or 6 is true, its own parent flag (pf_A for state A , and pf_B for state B) will be set to true before the transition occurs. Thus, when the transition condition ( in state C becomes true, the subroutine rung of the parent state can be executed again. 6 GrafTab Specification To Executable Program 96 A .1 B .2 C .3 stv V s t v « s t v - e pj A stv C I 4 H P JSR A / 8 stv 6 stv_ti /Hhr3/E-pf B stvC stv y stv t; - y l T / r : JSR B 5JSR C Figure 6.20: Transforming Parent Bubble 6.3.9 Overall Structure of the Executable Programs In the foregoing sections, the transformation mechanisms for each individual notation in the E S D have been presented. This section will discuss the overall structure of the complete programs. 6.3.9.1 Ladder Diagram Structure When a specification is transformed into a ladder diagram, one should convert the Level 0 E S D diagram into File 2 (in Allen-Bradley control, File 2 is the first program file). File 2 must always contain the JSR rungs only, and the first rung is always used to jump to a subroutine which contains the rungs for initializing the controlled variables and the internal variables. The other JSR rungs in File 2 are used to jump to the subroutines which either represent the super-states or the sub-states in the lower level E S D diagrams. If a subroutine 6 GrafTab Specification To Executable Program 97 represents a super-state, this subroutine normally contains a set of JSR rungs which are used to jump to the sub-states of this super-state. If a subroutine represents a sub-state, this subroutine contains the rungs for the state condition, the actions, and the assignments which are specified in the S-Spec of this sub-state. Figure 6.21 shows the relationship between the specification structure and the ladder diagram structure. Level 0 ESD File 2 Super- Super- Super-State State State S u b r o u t i n e S u b r o u t i n e S u b r o u t i n e f o r t h e f o r t h e , f o r t h e , S u p e r - 5 t a t e + S u p e r - S t a t e 1 " S u p e r - S t a l e * * Primitive States •k Subroutine for the Primitive State + Contains JSR rungs only (a) Specification Structure (b) Ladder Diagram Structure Figure 6.21: Ladder Diagram Structure 6.3.9.2 SFC Structure Since states and transitions are inherent in the S F C language, the super-states in the E S D do not need to be converted into a S F C . The primitive states are the only states transformed into a S F C . The first step in a S F C is always used to initialize the controlled variables and the internal variables. According to the activation order of the primitive states, the primitive states are placed in a S F C in a top-down fashion. In other words, the entry state in Level 0 E S D is the second step in a S F C , and the succeeding state of the entry state is the third step in a S F C , and 6 GrafTab Specification To Executable Program 98 so on. Figure 6.22 shows the relationship between the general specification structure and the S F C structure. Z;0 y (a) Specification Structure (b) SFC Structure Figure 6.22: S F C Structure Chapter 7 Performance Analysis In Chapter 6, the mechanisms for transforming a GrafTab specification into a ladder diagram and a S F C are presented. Since both of them must represent the same system, it would be interesting to compare their performance in term of the size and the run time of the respective programs. The following sections discuss a method for estimating the size and the run time directly from the specification. Thus, one can get a general idea of how much memory he/she needs for the P L C system, and how fast the programs can run before the system is actually built. 7.1 Size Instead of estimating the memory size used in a ladder diagram and a S F C , the number of rungs needed by them is estimated. It is impossible to estimate the actual memory size of the programs because different instructions require, different memory sizes in the P L C controller. Moreover, since both the ladder diagram and the S F C represent a single P L C system, most of the rungs in the primitive state files will be the same. Thus, comparing the number of unique rungs needed in the ladder diagram and the S F C seems to be the best way to compare memory size. 99 7 Performance Analysis 100 7.1.1 Rungs in a Ladder Diagram and a SFC The number of rungs needed for a transition and a state condition subroutine is the same in both the ladder diagram and the S F C . 7.1.1.1 Transition Each transition in a GrafTab specification requires one rung in both a ladder diagram and a S F C . In a S F C , although the transitions can refer to the same file if they have the same transition condition, each of these transitions is still considered to occupy one rung. This is because each of them is still assigned a distinct transition symbol in the S F C . The total number of transition rungs needed in the system is denoted as Rtc. Only the transitions with transition conditions are counted. 7.1.1.2 State Condition Subroutine Each state condition subroutine requires three rungs in both the ladder diagram and the S F C . The first rung is used to check the state condition, the second rung is used to latch the check flag, and the third rung is the return, R E T , rung. Therefore, the total number of such rungs needed for the system is Rsc = 3 * sc where sc = the number of different state conditions in the specification. 7 Performance Analysis 101 7.1.2 Rungs in a Ladder Diagram Since a hierarchical structure is forced onto a ladder diagram, some additional rungs and files are added. The following sub-sections will present a systematic method for estimating the numbers of rungs needed. 7.1.2.1 Initial State The controlled variables must be set to their initial values, according to the specification, and all of these should be done in one rung. The state condition variables, check flags (cf), state transition variables (stv), unlatching flags (uf), and parent flags (pf) also need to be set to their respective initial values. One rung is used to set the state condition variables and the check flags because they appear in the S F C as well. Initializing the stv variables is done in one rung. Resetting the parent flags is done together with the unlatching flags, because it is unusual to have many parent bubbles in the specification. Another rung is needed for the return (RET) instruction at the end of the file. Thus, the initial state file contains 5 rungs in total, excluding transition rungs. 7.1.2.2 Level 0 of an ESD Level 0 of an E S D specification is converted into File 2 in a ladder diagram. Each sub-state in Level 0 requires one rung in File 2. Other than that, the very first rung in File 2 must be used as the JSR instruction for the initial state. The number of rungs in File 2 is denoted by Rm = ™su + 1 7 Performance Analysis 102 where nsn = the number of sub-states in Level 0 of an E S D specification. 7.1.2.3 Primitive State The number of rungs required for a primitive state is equal to the number of rungs for its S-Spec and a number of additional rungs as described below. S-Spec The number of rungs needed to transform a S-Spec into a ladder diagram depends on the following conditions: 1. Number of state conditions: Since verifying a state condition is done in a subroutine file, each state condition in a S-Spec will require a rung for the "jump to subroutine" (JSR) instruction. The total number of JSR rungs is denoted as RSCJSR. 2. Number of actions in a SAT: Other than the action which is used to activate the C A T , each action in a SAT is equal to one rung. The total number of such action rungs is denoted as RSAT-3. Number of columns in a C A T : If the values assigned to the controlled variables in a column of C A T are different from the actions in the corresponding SAT, this column will require one rung. The total number of such assignment rungs is denoted as RCAT-4. Number of identical action/assignment and exiting transition condition pairs in the S-Spec : While the S-Spec rungs are combined with the transition rungs, every single action, assignment, and transition is counted according to the above 7 Performance Analysis 103 conditions. Hence, the rung count must be reduced by the number of these pairs. The total number of rungs reduced is denoted as RP. For example, in Table 6.1 (SAT), there is only one state condition, and there is one action (Error := True) that is not used to activate the GAT. Thus, RSC JSR = 1 and RSAT = 1. In the C A T (Table 6.2), there are two columns, so that RCAT = 2. If there is an exiting transition with condition "Error = True", RP will be equal to one because this condition is the same as the action. Therefore, the total number of rungs needed for the Tables 6.1 and 6.2 is equal to 1 + 1 + 2 - 1 = 3. A d d i t i o n a l Rungs Other than the rungs for the S-Spec, two extra rungs are required; an unlatching rung and a return R E T rung. However, if there is more than one primitive sub-state in a super-state and they are connected together by transitions, only the primitive entry sub-state will have an extra rung for unlatching the internal variables. The total number of unlatching rungs and R E T rungs for the system is Ra = 2 * m — rips where m = the total number of S-Specs in the specification, and nps = the number of primitive non-entry sub-states which are connected to the primitive entry state in all super-states. 7.1.2.4 Super-State A super-state is transformed into a file which consists of the JSR rungs for its sub-states, and a R E T rung. Thus, each super-state file requires 7 Performance Analysis 104 n + l rungs, where n is the number of sub-states in that super-state, and the additional rung is for the R E T rung. The total number of rungs for all super-states is equal to X i=l where nt = the number of sub-states in the ith super-state. 7.1.2.5 Concurrent State Since a concurrent state containing a set of primitive entry states is similar to a primitive state in terms of transforming it into a ladder diagram, counting the number of rungs needed for a concurrent state is the same as counting the number of rungs needed for a primitive state. The non-entry states in a concurrent state, however, are programmed as the "jump to subroutine" rungs in a ladder diagram. Each non-entry state thus adds one extra rung in the entry state file. Moreover, the C A T for the entry state which is connected with a non-entry state will occur in its own rung. The total number of extra rungs for this concurrent state is Rnd = 2*nnd where nnd = the number of non-entry states in all the concurrent states. 7.1.3 Rungs in a SFC Since a hierarchical structure is inherent in a S F C , the structure of a S F C program is less complicated than the one for a ladder diagram. The following sub-sections present a systematic method for estimating the number of rungs needed in a S F C . 7 Performance Analysis 105 7.1.3.1 Initial State The controlled variables must be set to their initial values according to the specification, and all of them should be done in one rung. The internal variables (stv and cf) are initialized in another rung. Thus, the initial state file contains 2 rungs in total. 7.1.3.2 Primitive State Conditions 1, 2, and 3 (in Section 7.1.2.3), used in counting the number of rungs for a primitive state in a ladder diagram, also apply to the primitive state in a S F C . Condition 4, however, does not happen in a S F C . This is because a transition is always written in a transition file, and an action/assignment in a S-Spec never can be combined with a transition. Thus, for instance, Tables 6.1 and 6.2 require 4 rungs in a S F C . 7.1.3.3 Concurrent State Counting the number of rungs needed in a concurrent state that contains only primitive entry states is the same as that for a primitive state. However, when a concurrent state also contains some non-entry primitive states, the primitive entry states are no longer converted into a single file. Each entry state occupies a step file in each simultaneous branch. Since the entry state located in the left-most branch contains a JSR rung for verifying the state condition, one can use the counting method for a primitive state in this entry state. The number of rungs in this state is denoted as Rdi- Other entry states do not require the state condition rung so that only Conditions 2 and 3 in Section 7.1.2.3 are considered in the rung 7 Performance Analysis 106 counting. Since Conditions 2 and 3 are the same in all entry states, one can calculate the total number of extra rungs needed for all these entry states by Rdf = (ndf - l) * (Rdi ~ Rdfsc) where ndf = the number of entry states in a concurrent state, and Rdf sc = the number of state conditions in the entry states. The number of extra rungs needed for the entry states in all concurrent states that use simultaneous branches is where Rdft= the number of entry state rungs in the ith concurrent state; 7.1.4 Size Difference in a Ladder Diagram and a SFC From the foregoing sections, one can see that when a GrafTab specification is transformed into a ladder diagram, the total number of rungs needed for the whole system is Riadder = 5 + (see Section 7.1.2.1) x (see Section 7.1.2.2) Rs + (see Section 7.1.2.4) X 2~2 (Rsc-JSR + RSAT + RCAT - Rp)i + Ra + (see Section 7.1.2.3) Ru + (see Section 7.1.1.1) Rsc + (see Section 7.1.1.2) 7 Performance Analysis 107 Rnd (see Section 7.1.2.5) where i = the ith S-Spec, and x = the number of S-Specs. When the same specification is converted into a S F C , the total number of rungs required in the program is equal to RSFC = 2 + (see Section 7.1.3.1) X E (Rsc-JSR + RSAT + RcATJi + (see Section 7.1.3.2) i Rtc+ (see Section 7.1.1.1) R s c + n (see Section 7.1.1.2) Rcon-df (see Section 7.1.3.3) where i = the ith S-Spec, and x = the total number of S-Specs. The difference in the number of rungs needed in a ladder diagram and a S F C , for the same specification, is given by Rdiff — Rladder ~ RsFC x = Rm + Rs + Ra + Rnd + 3 —' Rp — RCon-df. i Both Rn(i and RCOn-df m the above equation are related to the existence of some non-entry states within a concurrent state. If this kind of concurrent state does not appear in an E S D specification, both of them will be equal to zero. If they are not equal to zero, it is difficult to tell which one is bigger because both of them depend on different kind of states in a concurrent state (i.e., Rnd depends on the number 7 Performance Analysis 108 of non-entry states and Rcon-df depends on the number of entry states). In order to make the following discussion possible, both of them are assumed to be equal to zero. In general, since most of the primitive states.require two additional rungs, and the number of identical transition condition and action/assignment pair are unlikely X to be greater than two in a S-Spec, Ra is often larger than Rp,- I n this c a s e ' Rdiff is often greater than zero meaning that a ladder diagram often requires more rungs than a S F C for the same P L C system. This is due mainly to the fact that the ladder diagram does not have an inherently hierarchical structure. Extra rungs and internal variables are needed to force the hierarchical structure into a ladder diagram. Although a ladder diagram has more rungs than a S F C , their difference in terms of physical memory requirements might not be that significant. The physical memory requirement of a ladder diagram is the total of the physical memory of each instruction in all rungs. However, the physical memory requirement of a S F C also includes the memory size of the symbols used in the S F C (e.g., a pair of step and transition symbol needs 8 words). Even though transforming a GrafTab requirements specification into a S F C might not help to reduce the actual memory requirement significantly, a S F C is more preferable to a ladder diagram because it has an inherently hierarchical structure. 7.1.5 Running Example: Drill Machine The following is an estimation of the number of rungs needed in transforming the GrafTab specification of the drill machine into a ladder diagram. 7 Performance Analysis 109 R m = 6 + 1 = 7 R, = 3 + *Error Handling* * Backup* ^ (B-sc-JSR + B-SAT + Be AT — Rp)i 2 + 1 + 2 - 1) + *Start* * 1 + 1 + 1 - 1) + *In Position* 1 + 1 + 1 - 1) + * Drill Motor* 1 + 1 + 1 - 1) + *Drilling* 1 + 1 + 1 - 1) + * Station Backup* 1 + 1 + 1 - 1) + *Stop Dill Motor* 1 + 1 + 1 - 1) + *Home* 1 + 1 + 2 - 1) + *Shut Down* 1 + 1 + 2 - 1) * Emergency Light* = 22 Ba = 2*9 - 3 = 15 Rtc = 19 Bsc = 3*9 = 27 Rnd = 2*1 - 2 * Drill Motor* Therefore, Rladder = 5 + 7 + 6 + 22 + 27 + 15 + 19 + 2 = 103 rungs. The following shows an estimation of the total number of rungs needed for the transformation of the specification into a S F C . 7 Performance Analysis 110 ^ (Rsc-JSR + RSAT + RcAT)i 2 + 1 + 2) + * Start* 1 + 1 + 1) + *In Position* 1 + 1 + 1) + * Drill Motor* 1 + 1 + 1) + * Drilling* 1 + 1 + 1) + * Station Backup* 1 + 1 + 1) + * Stop Dill Motor* 1 + 1 + 1) + *Home* 1 + 1 + 2 ) + *Shut Down* 1 + 1 + 2 ) * Emergency Light* = 31 Rtc = 19 Rsc = 3 * 9 = 27 Rcon-df — (3 — 1) * (3 — 1) = 4 * In Position* Therefore, RsFC = 2 + 31 + 27 + 19 + 4 = 83 rungs. The number of rungs in the ladder diagram and the S F C differ by Rdiff = Rladder ~ RsFC j = R m + Rs + Ra + Rnd + 3 — ^  Rp — Rcon-df = 7 + 6 + 15 + 2 + 3 - 9 - 4 = 20 rungs. 7 Performance Analysis 111 7.2 R u n Time The program run time in both a ladder diagram and a S F C consists primarily of the I/O time and the program logic execution time. Additionally, the ladder diagram and the S F C have different overhead. The Allen-Bradley PLC-5/15 controller is used in the present study and all data (instruction run time and overhead) are adopted from [5]. In order to make the analysis possible, the following assumptions will be used: — Local I/O Modules: A l l input and output modules are located locally. In other words, they are located in the same chassis as the controller module. Thus, the I/O time in a ladder diagram is included in the housekeeping time which is equal to 1.34 ms in the present study (see Appendix B). In a S F C , the I/O time and the housekeeping time are two distinct values. The housekeeping time in a S F C is assumed to have no DH+ traffic time 9 and becomes 0.7 ms. The I/O time in a S F C is discussed in Section 7.2.2. — A l l false instructions: If a rung condition is false, all instructions in that condition are assumed to be false regardless of whether they are in parallel (ORed) or serial (ANDed). The additional run time of a branch instruction is ignored. DH+ is an abbreviation of Data Highway Plus. It is a connection between the local controller module and the remote modules (I/O or other controllers). The traffic time is the communication time between modules. 7 Performance Analysis 112 — A l l true instructions: If a rung condition is true, all instructions in that condition are assumed to be true regardless of whether they are in parallel or serial. Tfie additional run time of a branch instruction is ignored. 7.2.1 Run Time in a Ladder Diagram The run time is the time the controller takes to execute the logic (the rungs in a ladder diagram) once, perform housekeeping tasks, and then start executing the logic again. Since true and false logic execution times are different in the instructions of a rung, and different instructions are executed at different rates, the logic execution time (Ti0gic) fluctuates in a system. In the housekeeping (Jhid period, the following activities are performed: — processor internal checks; — updating the input image table with processor-resident I/O (i.e., local I/O) input status; — updating processor-resident local I/O output modules with data from the output image. 7.2.1.1 Logic Execution Time According to the transformation mechanisms in Chapter 6, the Allen-Bradley P L C controller first scans (executes) File 2 (the first file) of the program repeatedly until one of the rung conditions is true, and then jumps to a subroutine file. If the subroutine file is used to represent a super-state, it jumps to another file until it reaches the primitive state file. After the execution of the primitive 7 Performance Analysis 113 state file, it will return to File 2 and execute the rest of File 2. Therefore, the logic execution time will consist of the execution times in File 2, in the super-state file (if it exists), and in the primitive state file. File 2 and Super-state At any time, only one JSR rung can be activated in File 2 or the super-state file. Thus, the time for executing all logic rungs in the files consists of the time spent in checking the conditions in the active rung, executing the JSR instruction in the active rung, and scanning the non-active rungs. This time is equal to Y rm = 1.3z + (56 + 2 1 r ) - r ^ ( 0 . 8 Z B + 15) l*s n where x = the number of condition instructions in the active rung, r - the number of return parameters in the JSR instruction at the active rung, Y = the number of non-active rungs, and Zn = the number of condition instructions in the nth non-active rung. In the super-state file, the execution time of the R E T instruction also need to be added to Tm. It is equal to Tr = 48 + 21r' us where r' - the number of return parameters1 0. Note that r' must be equal to r if the super-state file is called by File 2.. 1 0 Return parameters are the variables which will need to be returned by the subroutine. 7 Performance Analysis 114 Primitive State The execution time of a primitive state file is equal to the execution times of the S-Spec rungs (TS), the transition rungs (TLRAN), and the unlatching rung and RET rung (TE). The calculations for TS and Ttran are not shown because they will be the same in the SFC; thus there is no influence on the run time comparison. Note that denotes the execution time for the false transition rung. The execution times of the unlatching rung (TU) and the RET rung (TRET) are equal to TU = (1.3 + 1.66+ 1.6z) ^ TRET = (48 + 21 r") fxs. Hence, r e = (1.3 + 1.66+1.6i) + (48 + 21r") [is = 1.6(6+ i) + 21r" +49.3 ps where b = 0 if a branch instruction is not used, b = 1 if a branch instruction is used, i = the number of internal variables that need to be unlatched, and r" = the number of return parameters. Note that r" must be equal to r if the primitive state file is called by File 2. TE will not include TU if the primitive sub-state file is a non-entry sub-state of a super-state. 7.2.2 Run Time in a SFC The run time in a SFC includes the following: — Time to execute the logic of a step, plus a 0.1 ms overhead. A step in a SFC represents the S-Spec of a primitive state, so that the execution time of a step is equal to TS. 7 Performance Analysis 115 — Time to re-scan the logic of a step (Tp), plus 0.1 ms overhead. Tp is the time required by the controller to reset all non-retentive outputs before the step transition occurs. Since the controller scan through the whole step, Tp is assumed to be equal to Ts. — Time to execute the logic of a transition. The transition rung can be either false or true. If the rung is false, the execution time is equal to Tj^, plus 0.1 ms overhead. If the rung is true, the execution time will be Ttr<m, plus 0.25 ms overhead. — Time for I/O scanning, T[/o, equal to 0.6 ms. — Time for housekeeping, T^, equal to 0.7 ms. — Time for overhead, T0h, equal to 0.02 ms. — Time for divergence overhead, T0d. When the controller enters into a simulta-neous branch, a divergence overhead must be included in the run time. Each step in the simultaneous branch contains a divergence overhead at the first scan of the branch. Toc{ is equal to 0.3 ms. — Time for convergence overhead, Toc. This is the overhead added to each rescanning step while the controller is exiting the simultaneous branch. Toc is equal to 0.2 ms. 7.2.3 Scanning Sequence The scanning sequence is a sequence which the PLC controller follows while a program is being executed. From the scanning sequence, one can determine the 7 Performance Analysis 116 run time of a program. The following sections will compare the scanning sequence and the run time of the same system written in both a ladder diagram and a SFC. It is worth mentioning again that both programs are transformed from a GrafTab specification according to the mechanisms stated in Chapter 6. 7.2.3.1 Primitive State If a primitive state is transformed into a ladder diagram, which is then executed, the controller first will scan the rungs in File 2 until it reaches the rung which is used to jump to that primitive state. After the primitive state is executed, the controller will return to File 2 and execute the remaining rungs in the file. There two possible scanning sequence for a primitive state: (1) exiting transition condition is equal to false, and (2) exiting transition condition is equal to true. Case 1: exiting transition condition = false Figure 7.1 shows the scanning sequence of the primitive state when the exiting transition condition of the state is false. Main-1 State Trans. 4 Main-2 hk . Note: - Main-1 includes the active JSR rung and all the JSR rungs prior to that active rung in the File 2 - Main-2 is the remaining JSR rungs in the File 2 - hk is the housekeeping period Figure 7.1: Scanning Sequence (Ladder Diagram) for Primitive State: Exiting Transition Condition is False I Unlatch RET Rung 7 Performance Analysis 117 If the same primitive state is transformed into a SFC, which is then executed with the exiting transition condition as false, the following scanning sequence will take place (Figure 7.2). State I/O Trans. hk' Figure 7.2: Scanning Sequence (SFC) for Primitive State: Exiting Transition Condition is False According to Figure 7.1, the run time of a primitive state and a transition in a ladder diagram can be estimated as follows: Tladder = Tm + Ts + ^Tfon + T]ik = r m + r s + % ^ + r e + i.34 ms. According to Figure 7.2, the estimated run time of the same primitive state and transition in a SFC is equal to TSFC = Ts + 0.1 + TI/0 + T j ^ + 0.1 + Thk, = Ts + T t i a ^ + 1 - 5 m S -7 Performance Analysis 118 The run time difference between the ladder diagram and the SFC is equal to Tdiff = Tiadder - TsFC . — Tm + Te 0.16 ms Y = [l.3x + (56 + 21r) + (0.8Zn + 15)+ 1.6(6 + i) + 49.3 + 2 1 r ] * 1 0 - 3 - 0.16 ms Y = [1.3x + 42r+]T(n.8ZB + i5)+ ii 1.6(6 + 0 + 105.3] * 1 0 - 3 — 0.16 ms. Case 2: exiting transition condition = true If a transition condition is true, the run time of a primitive state and a transition in a ladder diagram is lengthened only by a longer execution time of the transition rung. The scanning sequence for the ladder diagram is the same as the sequence in Figure 7.1. In a SFC, however, the total run time has to include a rescan time and a longer overhead in executing the transition rung. Figure 7.3 shows the scanning sequence of a primitive state with a true transition condition. The estimated run time in the SFC is equal to TSFC = 2(Ts + 0.1) + Tj/o + Ttra1l + 0.25 + Thk, = 2TS + Ttran + 1.75 ms. State I/O Tran. hk' rState Note: rState = Rescanning the State Figure 7.3: Scanning Sequence (SFC) for Primitive State: Exiting Transition Condition is True 7 Performance Analysis 119 Therefore, when the transition condition is true, the run time difference between the ladder diagram and the SFC becomes smaller. It is equal to Tdiff = Tiadder' -TsFC = r m " + r e - 0 . 4 1 -Ta ms . Y = [1.3s + (56 + 21r) + ] £ ( 0 . 8 Z n + 15)+ n 1-3 1.6(6 + i) + 49.3 + 21r] * 10 - 0.41 - Ts ms Y [1.3a: + 42r + 5^(0.8ZB + 15)+ n 1.6(6 + i) + 105.3] * 10~3 - 0.41 - Ts ms. 7.2.3.2 State with Selective Transitions The scanning sequence of a state that has a set of selective transitions in a ladder diagram, assuming all transition conditions are false, is the same as the sequence in Figure 7.1. The only difference is that it takes a longer time to execute all the transition rungs. The execution time of the transition rungs is equal to a V T-  ; / j traiii i where a = the total number of transition rungs, and ^trani ' the execution time of the ith transition. In a SFC, an overhead is introduced between each transition rung.. The scanning sequence for a set of selection branches and a primitive state is shown in Figure 7.4. 7 Performance Analysis 120 State I/O T _ l oh T_2 oh T_n hk' Note: T_x is the transition rung x, x = (1,2,...n) Figure 7.4: Scanning Sequence (SFC) for Primitive State: Exiting Selective Transition Conditions are False The total run time required in the SFC is equal to a TSFC = Ts + 0.1 + TI/Q + ^ (%^,. + 0.1) + (a - 1) * 0.02 + Thk> i a = ^ + ^ f e + 0 . 1 2 a + . 1 . 3 8 m S -i The run time difference between the ladder diagram and the SFC is Tdiff = Tladder - TSFC . a = (Tm + Ts + J2Tt^-u + T* + L34)-i a (rs + E%^,+0-12a+1-38) i '= Tm + Te -0.12a -0.04 ms Y = [1.3x + (56+.21r)"+2(0.8Zn + 15)+-n 1.6(6 + i) + 49.3 + 2 1 r ] * 1 0 - 3 - 0.12a -0.04 ms Y = [1.3x + 42r + ^ ( 0 . 8 Z „ + 15)+ n 1.6(6 + i) + 105.3] * 1 0 - 3 - 0.12a -0.04 ms. When one of the selective transitions, assuming the transition with the highest priority, has a true condition, the run time of a ladder diagram is estimated to be 7 Performance Analysis 121 equal to a Tladder' = Tm -\- Ts ~f- T^rani + ^ ] -^tran; ~\~ Te -f- T/jfc t=2 = T m + T s + Tfranj + ^ T ^ . + T e + 1.34 m s . t=2 This run time is similar to the run time of a ladder diagram which has false conditions in all the selective transitions, except that the execution time of the transition with a true condition is longer. . In a SFC, the controller will rescan the current state when the transition condition in one of the selective transitions become true. Owing to the assumption that the first transition condition is true, the scanning sequence of the selection branch is the same as the sequence for a primitive state with a single true transition condition in Figure 7.3. The run time is estimated to be equal to TSF c> = 2(r s + 0.1) + TI/Q + Ttrani + 0.25 + Thk, = 2TS + Ttrani + 1.75 ms. 7 Performance Analysis 122 The run time difference between the ladder diagram and the SFC is Tdiff = Tiadder! ~ TsFC a . = (Tm + TS + Ttrani + J2 fe + Te + 1-34)-i=2 (2TS + Ttrani +1.75) = T m + T e + fe - ^ - 0-41 rns i=2 y = [1.3a; + (56 + 21r) + ]T (0.8Z„ + 15)+ o 1.6(6 + 0 + 49.3 + 21r] * 10" 3 + - ^ - 0 . 4 1 i=2 y = [1.3s + 42r + ^ ( 0 . 8 Z „ + 15)+ n a 1.6(6 + z) + 105.3] *1(T 3 +YlTt^Ti, ~ T s - ° - 4 1 m 5 -»=2 7.2.3.3 Concurrent State If a concurrent state which contains entry states only is converted into one file in a ladder diagram or a SFC, the scanning sequence will be the same as the one described in Section 7.2:3.1, or Section 7.2.3.2 if the exiting transitions of the state are the selective transitions. The process is different for a ladder diagram when a concurrent state contains some non-entry states such as in Figure 7.5a. The controller will scan the rungs for State A and State B first. Then, if the exiting transition condition of State B is true, the controller will jump to State C (Figure 7-5b); otherwise, the rung for jumping to State C will be scanned with a false condition. If this concurrent state is transformed 7 Performance Analysis 123 \cond_0 State A .1 [ State B |cond_l State C .3 State A State B JSR for State C RET to Caller (b) Transforming (a) into a.ladder diagram cond 0 cond_2 (a) Non-Default State in Concurrent State State A State B cond_l State C (c) Transforming (a) into a SFC Figure 7.5: Non-entry States in a Concurrent State > into a S F C , a simultaneous branch must be used so that States A and B or States A and C can be executed at the same time (Figure 7.5c). Depending on the transition conditions, there are three possible scanning se-quences of this concurrent state. Case 1: cond_l = False If the exiting transition condition (cond_l) of State B is false, the scanning sequence of the ladder diagram includes: the logic rungs in File 2, the unlatching rung in the subroutine of State A , the logic rungs of State A and State B, the transition rung (cond_l), the rung for the non-active JSR rung for State 7 Performance Analysis 124 C , the R E T rung, and the housekeeping cycle (Figure 7.6). The scanning sequence for a S F C includes the scanning of the State A and State B rungs, the transition rung, the divergence overhead, the I/O, and the housekeeping cycle (Figure 7.7). Nonactive JSR Rung A Main-1 i State A State B l 1 Main-2 hk Unlatch cond_l RET Rung Figure 7.6: Scanning Sequence (Ladder Diagram) for Concurrent State: Entering Transition Condition of the Non-entry State is False State A od State B i I/O hk' State A I/O State B I/O i hk' cond_l cond_l Figure 7.7: Scanning Sequence (SFC) for Concurrent State: Entering Transition Condition of a Non-entry State is False In order to obtain the average run time different between the ladder diagram and the S F C , it is assumed that the controller will scan the ladder diagram and the S F C n times. The run time for n scans in the ladder diagram is Tiadder = (rm + Te + TS_A + TS_B + T j ^ ^ + TJSR_C + Thkj * n 7 Performance Analysis 125 where TJSR_C = the time it takes to scan the non-active JSR instruction for State C . The divergence overhead in the S F C is included only in the first scan of program. Therefore, the run time for n scans in the S F C is equal to TSFC = (TS_A + 0.1 + Tod + TS_B + 0.1 + Tj^^ + 0.1 + Tk-<) + (TS_A + 0.1 + TS_B + 0.1 + + 0.1 + Thk) * (n - 1) ms = (TS_A + TS_B + + 1-6) * n + 0.3 ms. The difference between the run time for n scans in the ladder diagram and the S F C is Tdiff = Tladdtr - TSFC = (rm + Te + TJSR_C + T/tJb - 1.6^ * n - 0.3 y = {[(1.3a; + (56 + 21r) + ^  (0 .8Z m + 15))+ (1.6(6 + i) + 49.3 + 21r) + (0.8n c + 15)] * 10~ 3 + 1.34 - 1.6} *n- 0.3 ms Y , = {[(1.3a; + 42r + 1.6(6 + i) + (0 .8Z m + 15)) + 0.8n c + 120.3] * 10~ 3 - 0.26} * n - 0.3 ms. Case 2: cond_l = True and cond_2 = False In the ladder diagram, if cond_l is true and the exiting transition condition (cond_2) of State C is false at the current scanning cycle (i.e., before the housekeeping cycle is performed), the controller will not-jump immediately to the State C subroutine because the rung condition of the JSR rung will not have been updated. However, right after the housekeeping is 7 Performance Analysis 126 performed, the controller will scan the rungs for State A and State B with a true and a false condition respectively. Then it will jump to the State C subroutine and scan the rungs of State C (Figure 7.8). Non-JSR active ^ung A c JSR tive ^ung Main-1 State A State B Main-2 hk Main-1 ^ t Nonactive S t a t e A State B State C Subroutine Main-2 hk Unlatch cond_l RET Unlatch condj RET Rung Rung Figure 7.8: Scanning Sequence (Ladder Diagram) for Concurrent State: Entering Transition Condition of the Non-entry State is True In the S F C , the controller will not scan State C until the I/O is updated and State B is rescanned.. The scanning sequence is shown in Figure 7.9. StateA od State B I/O hk' StateA I/O pStateB State C I/O hk' StateA I/O State C I/O hk' cond_l cond_2 cond 2 cond_2 Figure 7.9: Scanning Sequence (SFC) for Concurrent State: Entering Transition Condition of the Non-entry State is True 7 Performance Analysis 127 The run time for n scans in the ladder diagram is Tladder' = {/I'm + Te + Ts_A+Ts_B + (Tm + T e + TS_A + T-JlB + Ttrancon_i + TjSR.C + Ts_c> + T)lkj * (n - 1) = (Tm + T e + T S _ A + T i r a n a + 1.34) * 71+ ( T g I S + TjSR_c + Ts_c)*(n-l)+-where Ts_c, = Tec + Ts_c + The run time for n scans in the S F C is equal to n TSFC' = TSFC[ + TSFC2 + z\l TSFC'I i=3 where TSFC', TSFC*, and T S F C i are the running times for the first, second, and fth scans respectively. They are equal to TSFC[ =  TS-A + 0.1 + Tod + TS_B + 0.1 + . r t r a n i + 0.25 + TIfo + Thk, = TS_A + TS_B + Ttrani 4- 2.05 ms, TSFC'2 = Ts-A + 0.1 + TI/0 + TS_B + 0.1 + T s _ c + 0.1 + TI/Q = TS_A + TS_B + T s _ c + %^r c o n_ 2 + 2.3 ms, TSFC[ ~ TS_A + 0.1 + TIfo + Tj^con_2 + 0.1 + TS_C + 0.1 + T j l o + T i ^ c o n _ 2 + Q . l + T h k , = Ts_A + Ts_c + 2 T 1 ^ c m _ 2 + 2 . 3 ms. 7 Performance Analysis 128 Therefore, TSFC =nTs_A + 2TS^B + ( n - l)Ts_c + Ttranoon_x + ( 2 ^ - 3 f c c o n _ 2 + 2.3n - 0.25 ms. The run time difference between the ladder diagram and the S F C is equal to Tdiff = Tiadder' ~ TsFC = (Tm + Te) * n + (TSIff+TjSR_C + Tec + Ttran^) * (n - 1) + fe__2 * (2 - n) + TJSJEC + 0.25 - 0.96n - TS_B Case 3: cond_l = True and cond_2 = True In the ladder diagram, if cond_l is true in the first scanning cycle and cond_2 is also equal to true during the execution of State C , the scanning sequence is the same as the one in Case 2, except it does not have a loop. The run time can be found by substituting n = 2m the equations in Case 2, and executing the transition rung for cond_2 under the true condition. In the S F C , if all states have been executed at least once and if cond_2 is equal to true, the controller will do the housekeeping and will rescan all convergence states immediately (Figure 7.10). State A od State B I/O hk' State A I/O rState B State C I/O hk' rState A OC rState C cond_l cond_2 Figure 7.10: Scanning Sequence (SFC) for Concurrent State: Exiting Transition Condition of the Non-entry State is True 7 Performance Analysis 129 The run time for the ladder diagram is equal to ^ladder" ~ (Tm + Te + TS_A + Tirana + Tfcfc) * 2+ TSZB + TJSR-C + TslC" + Ts-B + TJSRTU M S where Ts_c" = Tec + Ts_c + TtranCOn_2-The run time for the S F C is equal to TSFC" -  TSFC[ +  TSFC'± +  TSFCp where TSFC> is equal to the one in Case 2. T S F C < i is also equal to the one in Case 2, except the run time for the exiting transition (cond_2) is longer. T S F C » is the rescan run time at the end of the sequence. TSFC» and TSFC" can be found by the following equations. TSFC! = T s - A + 0-1 + TI/Q + TS_B + 0.1 + Ts_c + 0.1 + TI/0 + TtranCon_2 + °- 2 5 + Thk> ms. = TS_A + TS_B + TS_C + Ttrancon_2 + 2-45 ms. TsFCp = Ts_A + 0.1 +-T0C + Ts_c + 0.1 ms = TS_A + Ts_c + 0.4 ms. Therefore, TsFC" = 3Ts_A + 2Ts_B + %Ts_C + r<ranCOn_i + Ttrancon_2 + 4.9 ms. 7 Performance Analysis 130 The run time difference between the ladder diagram and the S F C is equal to Tdiff" — Tladder" ~ TsFC" = 2 ( T m + TE) + T ^ - g + TJSR_C + TJSR_C + T T C + T T R A N I — 1.22— (TS_A + TS_B + Ts_c) rns. 7.2.3.4 Significance of the Run Time Differences In the above sections, the run time difference between a ladder diagram and a S F C is mainly due to the housekeeping time, the I/O time, and the overhead time. A l l of them are in the order of milliseconds. The execution time of the rungs does not play a significant role in the run time difference because most of the rungs in a ladder diagram and a S F C are the same. If the execution time of the rungs is not considered in the run time differences in the above sections, the run time of a S F C will be longer than the run time of a ladder diagram. This is because there are many different types of overhead in the S F C such as divergence overhead and convergence overhead (see Section 7.2.2 for other overhead). In order to reduce the run time of a S F C , one should try to reduce the overhead. For example, one should try to minimize the use of selection branches and simul-taneous branches in order to reduce the divergence overhead and the convergence overhead respectively. Combining two or more steps also will reduce the overhead time since every single step has a 0.1 ms overhead. 7 Performance Analysis 131 The run time of a ladder diagram is dominated by the housekeeping time. Writing better code (i.e., minimizing the use of internal variables) in a ladder diagram does not offer a significant reduction in run time. A better way to improve the run time of a ladder diagram, unfortunately, is to use a faster controller for the system. If a faster run time is a major criteria in a P L C system, one should transform a GrafTab requirements specification into a ladder diagram. This is because the overheads in a S F C are difficult to eliminate. Chapter 8 Conclusion and Future Works 8.1 Features of GrafTab GrafTab is an innovative method for writing a requirements specification for a P L C system. The features in GrafTab are summarized as follows: — Unambiguous: Since GrafTab is a semi-formal method with a formally defined syntax, the requirements specification has less potential for ambiguity. — Readable: Graphical (in the ESD) and tabular (in the S-Spec) description techniques are used in writing the system requirements document in GrafTab; thus the specification is highly readable. — Complete: GrafTab offers a complete requirements specification for a P L C system. A l l necessary information is specified in the GrafTab documents. First, the overall function of the system is described in the system abstract. Secondly, the environmental variables are identified in the monitored and controlled variables specification and in the external interface document. Finally, the flow of the system states and the relationships among the environmental variables are specified carefully in the system requirements document. — Learnable: The syntax of GrafTab is comprehensible. Conventional and simple notations are used. Only limited training is needed for using GrafTab. 132 8 Conclusion and Future Works 133 — Powerful: GrafTab is a powerful tool for specifying system states. By using the concurrent state notations in the E S D , one can specify parallel actions in the system. Broadcast transitions can reduce the number of transitions needed in the E S D diagrams substantially. A parent bubble records the history of state transitions. — Precise: In specifying a primitive state with a S-Spec, one is forced to specify completely the internal state condition and the actions. This results in an extremely precise specification. — Executable: Because of the formal syntax in GrafTab, a requirements spec-ification written in GrafTab can be transformed mechanically into executable programs — Predictable Performance: Since there is a direct mapping between the require-ments specification and the executable programs (ladder diagram and SFC), the run time and the memory requirements of the programs can be estimated ac-curately from the specification. 8.2 Evaluation There are many advantages of using GrafTab as a specification tool for a P L C system. These advantages are seen not only in the design stage of a P L C system but also the programming stage of the system. 8 Conclusion and Future Works 134 Benefits in the design stage of a PLC system The features of the E S D allow a designer to model the system states in an elegant and economical manner. For example, using the broadcast transition notation reduces the number of transitions needed in a diagram. The S-Spec provides an accurate and unambiguous specification of a state. The E S D and the S-Spec help to eliminate errors in the design of a P L C system; thus the maintenance cost of the system is reduced and the safety of the system is improved. A requirements specification written in GrafTab is more accessible than one written in formal method because of the ease-of-use effect resulting from graphical notations in the E S D . Due to the simple and well-defined syntax in GrafTab, no lengthy training period is required for using it. The cost of producing a requirements specification of a P L C system also is reduced considerably. Benefits in the programming stage of a PLC system The graphical and tabular no-tations in GrafTab offer an easy understanding of the requirements specification. The four documents required in GrafTab provide a definition of a complete requirements specification for a P L C system. From this complete specification, the time it takes to write an executable program is reduced significantly because a programmer should be able to obtain all information from the specification. The question and answer period between a designer and a programmer is minimized. The transforming mechanisms provided in Chapter 6 also help to reduce the programming time. Not only will the 8 Conclusion and Future Works 135 programming time be reduced, but the correctness of an executable program will also improve because of the unambiguity inherent in GrafTab. By using the transformation mechanisms delineated in Chapter 6, one can ob-tain the highly structured executable programs. Although a ladder diagram and a S F C which follow the transformation mechanism in Chapter 6 need more memory (especially for the internal variables) than the free-style programs (programmers can structure the programs freely), one can easily capture the control flow from the well structured programs. Knowing the control flow is extremely helpful when one wants to monitor the programs, or locate the problematic rungs in the programs. Cost of using GrafTab The cost of using GrafTab to specify a P L C system is minimal. First, it will take longer time to write a requirements specification in GrafTab than in English. However, as aforementioned, the writing time will be offset by the minimal maintenance time and programming time of the system. Secondly, although the notations in the E S D help reduce the size of the state diagram, the state diagram still will be really big if a P L C system is very complicated. Finally, since each primitive state in an E S D specification has to be specified by a S-Spec, the specification tends to be lengthy. 8 . 3 F u t u r e W o r k In this section, three major areas: (a) developing a verification method, (b) 8 Conclusion and Future Works 136 making an editing tool, and (c) building an automatic transformer for GrafTab will be discussed. 8.3.1 Verification P L C systems are becoming increasingly complex and often safety critical, thus verification of the requirements specification is an important step in the design process. Completeness, consistency, reachability, non-determinism, deadlock, and safety properties of the specification should be verified before the specification is transformed into an executable program. The conventional manual verification method is no longer an effective method for a complex P L C system. A n automatic verification tool needs to be built. In order to build the tool successfully, one will need to define the formal semantics of GrafTab. If a verification method and tool can be built, the safety and correctness of a GrafTab requirements specification would be increased dramatically. Both the method and tool are extremely important to the safety-critical systems. 8.3.2 Editing Tool Since there is a well-defined syntax for all documents in GrafTab, one should be able to build an editing tool for it. The tool would have a standard format for entering the monitored and controlled variables specification and the external interface document. The tool would consist of a drawing editor and a table editor for entering the E S D and the S-Spec respectively. The drawing tool would have a zoom-in 8 Conclusion and Future Works 137 function for viewing the details of a super-state, a zoom-out function for viewing the abstraction of a state, and a balance check for examining the transition balance between a super-state and its sub-states. When a user zooms into a primitive state in the E S D , the tool should automatically invoke the tables editor for the S-Spec and it should be able to check the syntax as well. If this editing tool is built, the time it takes to write and edit a GrafTab requirements specification for a P L C system would be shorter. The tool also would make it easier to enter the specification. The correctness of the specification in terms of the balancing between super-state and its sub-states would be increased as well. 8.3.3 Transformer Although the mechanisms for transforming a requirements specification into an executable program are presented in this thesis, the transformation is done manually. Mistakes might occur in the transforming process and the transformation time is long. Thus, a future line of work would be to build a transformer for doing this job automatically. The transformer would be able to read the requirements specification and then apply the rules specified in Chapter 6 for transformation. When this transformer is made, the time to obtain an executable program from a GrafTab requirements specification would be minimal. The correctness of the executable program would also be increased significantly. Bibliography [1] A N S I / I E E E Std. 830. IEEE Guide to Software Requirements Specifications. The Institute of Electrical and Electronics Engineers, New York, 1984. [2] Jean-Raymond Abrial. Steam-boiler control specification problem. In Dagstuhl Meeting: Method for Semantics and Specification, August 1994. [3] K. H . Britton and D. L . Parnas. A-7E Software Module Guide. N R L Memorandum Report 4702, United States Naval Research Laboratory, Washington D . C , December 1981. ' [4] Allen-Bradley Company. PLC-Programming Software — Programming. Allen-Bradley Company, Inc., Release 4.5 edition, November 1991. [5] Allen-Bradley Company. PLC-Programming Software — Instruction Set Refer-ence. Allen-Bradley Company, Inc., Release 4.5 edition, June 1994. p .Al -p .B16 . [6] A . J. Crispin. Programmable Logic Controllers and their Engineering Allications. McGraw Hil l , New York, 1990. [7] Tom DeMarco. Structured Analysis and System Specification. Yourdon Press, Prentice-Hall Inc., New Jersey, 1979. [8] DOD-STD-2167A. Military Standard, Defense System Software Development. Department of Defense, United State, 1988. [9] D. Harel, A . Pnueli, J. P. Schmidt, and R. Sherman. On the formal semantics of statecharts. In Proc. 2nd IEEE Symposium on Logic in Comp. Sc., 1987. [10] David Harel. Statecharts: A Visual Formalism for Complex System. Sc. Comp. Prog., 8:231-274, 1987. 138 Bibliography 139 [11] D. J. Hatley and I. A . Pirbhai. Strategies for Real-Time System Specification. Dorset House Publishing Co. , Inc., New York, 1987. [12] Hubert F. Hofman. Requirements Engineering: A Survey of Methods and Tools. Technical Report 93.05, Instituts of Informatics, Univ. of Zurich, Winterthurerstr, Zurich, March 1993. [13] C . B . Jones. Systematic Software Development Using VDM. Prentice-Hall International Inc., 1986. [14] C. T Jones and L . A . Bryan. Programmable Controllers — Concepts and Applications. International Programmable Controls, Inc., United States, 1983. [15] A . J . Laduzinsky. PLCs Develop New Hardware and Software Personalities. Control Eng., 37(2):53, February 1990. [16] D. C . Luckham and F. W . von Hemke. A n Overview of Anna: A Specification Language for Ada. IEEE Software, 2(2):9-23, March 1985. [17] Gilles Michel. Programmable Logic Controller. John Wiley & Sons Ltd., England, 1990. [18] Gilles Michel. Programmable Logic Controller, chapter 5. John Wiley & Sons Ltd., England, 1990. [19] A . J. R. G . Milner. A Calculus of Communication Systems, In Lecture Notes in Computer Science 92. Springer-Verlag, 1980. [20] D . L . Parnas. Designing Software for Ease of Extension and Contraction. IEEE Trans, on Software Eng., 5(2): 128-138, March 1979. [21] D. L . Parnas. A Generalized Control Structure and Its Formal Definition. Comm. of the ACM, 26(8):572-581, August 1983. [22] D. L . Parnas and J. Madey. Functional Documentation for Computer Systems Engineering. Technical Report CRL-237, Comm. Research Lab., McMaster Univ., Bibliography 140 Hamilton, Ont., Canada, September 1991. [23] D. L . Parnas and Y . Wang. The Trace Assertion Method of Modue Interface Specification. Technical Report 89-261, C&IS, TRIO, Queen's Univ., Kingston, Ont , Canada, October 1989. [24] J. L . Peterson. Petri Nets. Computing Surveys, 9(3), September 1977. [25] Robert D. Sandusky. P L C and P C System Documentation Concepts. In Rubber and Plastics Industries, 1989. [26] Ian Sommerville. Software Engineering. Addison-Wesley Publishing Company, 4th edition, 1992. [27] J. M . Spivey. Introducing Z: A Specification Language and Its Formal Semantics. Cambridge University Press, 1988. [28] I E E E Std.610.12. IEEE Standard Glossary of Software Engineering Terminology. The Institute of Electrical and Electronics Engineers, New York, 1990. [29] Jeannette M . Wing. What is a Formal Method?. Technical Report C M U - C S - 8 9 -200, School of Comp. Sc., Carnegie Mellon Univ., Pittsburgh, US, November 1989. [30] Marie Helene Wong. Informal, Semi-Formal, and Formal Approaches to the Specification of Software Requirements. Technical Report 94—23, Dept. of Comp. Sc., The Univ. of British Columbia, B . C . , Canada, September 1994. Appendix A Housekeeping Time in a Ladder Diagram In Chapter 7, the housekeeping time of a ladder diagram program is assumed to be 1.34 ms. This value is not specified in [4, 5]; rather it is an experimental value found from the following case studies. Case 1: There is only one rung in the program in this case (Figure A.1) which consists of a timer (RTO instruction) and a counter ( A D D instruction). When the program is executed, the timer starts, and will not stop until it reaches a preset value, T. While the timer is running, a counter with an initial value 0 will also increment on each rescan of the rung until the timer stops. From the final value of the counter, C, one can determine the run time of the program, Trun. _ T J- run — ~~Q Program L i s t i n g R e p o r t Rung 2:0 I Rung 2:1 PLC-5/15 F i l e HK_C1 Rung 2:0 +RTO + I +RETENTIVE TIMER ON+-(EN)+-+ I Timer T4:0| ITime base 0.01+-(DN) I P r e s e t 100| lAccum ' 100| + + T4:0 +ADD--T + +-]/[--+ADD ++ DN I S o u r c e A I S o u r c e B I Dest N7 : 0 | 707 | 1 I N7 : 0 | 707 I . + I [END OF FILE] + Figure A.1: Ladder Diagram for Case 1 141 Appendix A Housekeeping Time in a Ladder Diagram 142 Since TTUll = logic execution time(Tiogic) + housekeeping time^T^j.), the housekeeping time is equal to From the data in [5], Tiogic = 39 + 0.8 + 36 + 0.8 + 0.8 us = 77.4 tis. Table A . l shows the housekeeping time of the program, with various Ts. Note that the housekeeping time is equal to 1.34 ms in the majority of trials. 7/(ms) C Trm (ms) Thk (ms) 1000 707 1.41 1.33 2000 1412 1.42 1.34 3000 2117 1.42 1.34 4000 2822 1.42 1.34 5000 3530 1.42 1.34 Table A . l Housekeeping Time for Case 1 Case 2: In this case, the housekeeping time of a program that consists of two dependent rungs is investigated. The program is similar to the one in Case 1, except that Case 2 contains two symmetric rungs (Figure A.2). When the program is executed, only one of the rungs is activated and the other rung is not. The timer and the counter in the first rung are denoted as 77 and CI respectively, and the corresponding ones in the second rung are denoted as 72 and C2 respectively. Appendix A Housekeeping Time in a Ladder Diagram 143 Program L i s t i n g R e p o r t PLC -5/15 F i l e HK_C3 Rung 2 : 0 Rung 2:0 ' I T4 :1 +RTO ---+ I + - - ] / [ +-+RETENTIVE TIMER ON+-(EN)+-+ I . EN I |Timer T4:0 I | | | 1 ITime base 0 .01+-(DN)| | 1 1 I P r e s e t 300| | | ' 1 I lAccum 3001 I I 1 I + - - - + II 1 I T4:0 +ADD . (. | | 1 +-]/[--+ADD + + 1 1 DN |Source A N7:0 I I 1 1 20491 I ' 1 1 I S o u r c e B i ' 1 1 1 1 1 1 IDest N7 : 0 | I 1 1 20491 I 1 + — + | Rung 2:1 I T4 :0 +RTO + | + _..] [ +-+RETENTIVE TIMER ON+-(EN)+-+ I DN 1 I Timer T4:1| | | 1 I ITime base 0 .01+-(DN).| | 1 1 I P r e s e t 5001' | | 1 1 lAccum 500 1 II 1 I + + 1 1 1 1 T4:1 +ADD +| | 1 + - ] / [ --+ADD + + 1 1 DN I Source A N7:1 | | 1 1 34131 I 1 i 1 Source B i 1 1 1 1 1 1 I Dest N7:1 | I 1 1 34131 I . 1 . _| y | Rung 2:2 I 1 i r PMn CW PTT 1 1 + + Figure A.2: Ladder Diagram for Case 2 When the first rung is active and the second is inactive, the logic execution time of the program is equal to Tiogic, =(1.3 + 39 + 0.8 + 36 + 0.8 + 0.8) + (0.8 + 24 + 1.3 + 14 + 0.8 + 0.8) us =120.4 us. When the first and the second rung are inactive and active respectively, the logic execution time of the program is equal to Tio9ic2 =(0.8 + 24 + 0.8 + 14 + 0.8 + 0.8) + (1.3 + 39 + 0.8 + 36 + 0.8 + 0.8) us = 119.6 us. Appendix A Housekeeping Time in a Ladder Diagram 144 Table A.2 shows the housekeeping time of the program for various combinations of T l and T2. Again, the housekeeping time is equal to 1.34 ms in most combinations. Tl (ms) T2 (ms) CI C2 Tm (ms) Tm (ms) 1000 5000 679 3416 1.35 1.34 2000 4000 1362 2731 1.35 1.35 3000. 3000 2044 2049 1.35 1.34 4000 2000 2730 1366 1.34 1.34 5000 1000 3413 683 1.34 1.34 Table A.2 Housekeeping Time for Case 2 Case 3: The program examined in this case contains a timer and counter rung, a physical input/output rung, and a physical output which depends on the timer output (Figure A.3). This program allows us to investigate how the physical input/output instructions affect the housekeeping time. The program is executed with two different input conditions. First, the input with the address 1:000/00 in Rung 2 is kept open during the program execution. Second, that input is kept closed during the execution. When the input (1:000/00) is open, the logic execution time of the program is Tiogic = (39 + 0.8 + 36 + 0.8 + 0.8) 4- (0.8 + 0.8) + (0.8 + 0.8) us = 80.6 fis. When the input (1:000/00) is closed, the logic execution time of the program is T'logzc = (39 + 0.8 + 36 + 0.8 + 0.8) + (1.3 + 1.6) + (0.8 + 0.8) us = 81.9 jis. Appendix A Housekeeping Time in a Ladder Diagram 145 Program L i s t i n g Report Rung 2:0 PLC-5/15 F i l e HK_C3 Rung 2:0 + Rung 2:1 I 1:000 +RTO + +-+RETENTIVE TIMER ON+-(EN)+ I Timer T4 : 0 | ITime base 0.01+-(DN) I Preset 500 1 lAccum 500 1 T4:0 +ADD +-]/[--+ADD DN I Source A I I Source B i I Dest I - + + + N7 :0 3527 1 N7 :0 3527 I 00 Rung 2:2 I T4 :0 0: 001 -- ( L ) - -01 0:001 I DN Rung 2:3 I + [END OF FILE] 02 Figure A .3: Ladder Diagram for Case 3 The housekeeping times of the programs with the above conditions are shown in Table A.3. C o p e n and Cciose(i denote the counter value when the input (1:000/00) is open and closed respectively. T(ms) Copen ^closed Thk open ( m s) Thk closed (ms) 1000 705 701 1.34 1.34 2000 1408 1406 1.34 1.34 3000 2114 2110 1.34 1.34 4000 2821 2815 1.34 1.34 5000 3527 3522 1.34 1.34 Table A .3 Housekeeping Time, for Case 3 From the above cases, we can conclude that the housekeeping time of an Allen-Bradley PLC-5/15 is equal to 1.34 ms. Note that all input and output modules are assumed to be located in the same chassis as the controller. Appendix B Drill Machine S-Spec SAT: Start; 0.1 Let InitCon = (LS1 = Open) A (LS2 = Open) A (LS3 = Open) A ( LS4 = Open)i\ UC(LS5, Conveyor) A (CL1 = Off) A {DriUStatFor = Off)A (DriUMotor = Off) A (DriUStatBack = Off) A (TIMER = Off) A (Error = False) InitCon = True InitCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle A U T O = On A U T O = Off Conveyor := On Off SAT: In Position; 0.2 Let InPosCon = (AUTO = On) A ( iS5 = Open) A (Conveyor = On)A UT(LS2,LS3,LS4, CL1, DriUStatFor, DriUStatBack, DriUMotor, TIMER, Error) InPosCon = True InPosCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : In Position: 0.2 L S I = Close L S I = Open Conveyor:= Off no_opt Stop Conveyor CL1 := On no_opt Clamp Wood DriUStatFor := On no_opt Station Forward Error := no_opt n True In Position no_opt = no operation 146 Appendix B Drill Machine 147 SAT: Drill Motor; 0:2.4 Let MotorCon = (LS1 = Close) A (LS2 = Close) A (Conveyor = 0 / / ) A (CLl = On) A (DrillStatFor = On)A UT(AUTO, LSI, LS4, LS5, DriilStatBack, DrillMotor, TIMER, Error) MotorCon = True MotorCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : Drill Motor: 0.2.4 LS3 = Close LS3 = Open DrillMotor := On no_opt Error := no_opt True SAT: Drilling; 0.3 Let DrillingCon =(LS3 - Close) A (DrillMotor = On)A UT(AUTO, LS1.LS2, LS5, Conveyor, CLI, DrillStatFor, DriilStatBack, TIMER, Error) DrillingCon = True DrillingCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : Drilling; 0.3 LS4 = Close LS4 = Open DrillStatFor := Off no_opt TIMER-:= On no_opt Error := no_opt True 147 Appendix B Drill Machine 148 SAT: Station Backup; 0.4.1 Let BackupCon = (LS4 = Close) A (TIMER = On) A (DrillStatFor = 0 / / ) A UT(AUTO, LS1,LS2, LS3, LS5, Conveyor, CLl,DriilStatBack, DrillMotor, Error) BackupCon = True BackupCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : Station Backup; 0.4.1 T ( T I M E R ) 1 2 = 2s T(TTMER) <> 2s DriilStatBack := On no_opt T I M E R := Off no_opt Error := no_opt True SAT: Stop Drill Motor; 0.4.2 Let StopMotorCon =(TIMER = Off) A (DriilStatBack = On) A (£S4 = Open)/\ UT(AUTO,LSl, LS2, LS5, Conveyor, CLl, DrillStatFor, DrillMotor, Error) StopMotorCon = True StopMotorCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : Station Backup; 0.4.1 LS3 = Open - LS3 = Close DrillMotor := Off no_opt Error := no_opt True T(TIMER) is a function which will return the time of the TIMER 148 Appendix B Drill Machine 149 SAT: Home; 0.4 Let HomeCon = (LS3 = Open) A (DriUMotor = 0 / / ) A UT(AUTO, LS1.LS4, LS5, Conveyor, CL1, DriUStatFor, DriUStatBack, TIMER, Error) HomeCon = True HomeCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : Home: 0.5 LS2 = Open LS2 = Close DriUStatBack := Off no_opt CL1 := Off no_opt Conveyor:= On no_opt Error := no_opt True SAT: Shut Down; 1.1 ErrorCon = ^[(Conveyor = Off) A (CL1 = Off) A (DriUStatFor = Off) A (DriUMotor = Off) (DriUStatBack = Off) A (AUTO = Off) A ( L S I = Open) A (LS2 = Open)A (LS3 = Open) A (LS4 = Open) A (LS5 = Open) A (TIMER = Off)] ErrorCon = True ErrorCon = False idle /problem /fix problem CAT/idle /fix fix /idle (Error := False); CAT/idle 149 Appendix B Drill Machine 150 C A T : Shut Down: 1.1 Error = True Error = False Conveyor := Off no_opt CL1 := Off no_opt DriUStatFor := Off no_opt DriUStatBack := Off no_opt DrillMotor := Off no_opt T I M E R := Off no_opt Em Light := no_opt off SAT: Emergency Light; 1.2 ErrorCon = True ErrorCon = False idle /problem /fix problem CAT/idle /fix fix /idle (Error := False); CAT/idle C A T : Emergency Light; 1.2 Error = True Errror = False EmLight := On Off 150 Appendix C Traffic Light Controller System Abstract The traffic light controller is used to control traffic and pedestrian flow at the intersection of a main road and a cross road. The controller is to provide safe crossing of the main road by vehicles and pedestrians. Vehicle sensors are placed in the intersection which detect the presence of a vehicle1 stopped at any of the four sides of the intersection. There is also a crossing button for a pedestrian who wishes to cross the intersection. Three sets of light are located at the intersection, and they are main road light (RED, Y E L L O W , G R E E N ) , cross road light (RED, Y E L L O W , G R E E N ) , and pedestrian light (WAIT, W A L K ) . Normally the pedestrian light shows WAIT, the cross road light is R E D , and the main road light is G R E E N . When a pedestrian wishes to cross, he pushes the crossing button for 200 ms to assert P B U T T signal to the controller. After a 30 seconds delay, the pedestrian light and the cross road light change to G R E E N and W A L K respectively for 25 seconds. The main road light changes to R E D as well. However, changing the light from G R E E N to R E D must include 5 seconds of Y E L L O W light (it is also true for the cross road light). The main road light stays R E D for an additional 5 seconds after the pedestrian light has changed back to WAIT. When a vehicle is sensed on the cross road, then after a delay of 10 seconds, the cross road light and the pedestrian light turn G R E E N and W A I T respectively for 20 seconds. The main road light will change to R E D as described aforementioned. The cross road vehicle sensing and pedestrian sensing need be performed only when the main road light is G R E E N . Once the controller enters the delay period, no sensing is needed to be done. When the crossing button is pushed and the cross road vehicle is sensed at the same time, the crossing button signal will have a higher priority. No right turn is allowed when the light is on R E D . If error happens in the controller, all R E D lights will be flashing until an operator resets the controller. Readers must read the following documents for the formal requirements specifi-cation of the traffic light controller. 151 Appendix C Traffic Light Controller 152 Monitored and Controlled Variables Specification Document Monitored Variables P B U T T . — the crossing button, — if there are more than one button, they are connected in parallel — possible value: {pressed, unpressed} X V E C H — sensor which detects whether there is a vehicle on cross road or not — if there are more than one sensor, they are connected in parallel — possible value: {on, off} Reset — a reset switch which is used to reset the controller — possible value: {on, off} Controlled Variables M R E D — R E D signal on the main road light — possible value: {on, off} — initial value: off M Y E L — Y E L L O W signal on the main road light — possible value: {on, off} — initial value: off M G R N — G R E E N signal on the main road light — possible value: {on, off} — initial value: on X R E D — R E D signal on the cross road light — possible value: {on, off} — initial value: on Appendix C Traffic Light Controller 153 X Y E L — Y E L L O W signal on the cross road light — possible value: {on, off} — initial value: off X G R N — G R E E N signal on the cross road light — possible value: {on, off} — initial value: off W A I T — "WAIT" signal on the pedestrian light — possible value: {on, off} — initial value: on W A L K — " W A L K " signal on the pedestrian light — possible value: {on, off} — initial value: off TIMER[0..7] — T1MER[0] is an internal timer for the 25 s delay after the P B U T T signal has been asserted — TIMER[1] is an internal timer for the 25 s W A L K signal delay — TIMER[2] is an internal timer for the 5 s delay after X V E C H signal has been sensed > — TIMER[3] is an internal timer for the 20 s X G R N signal delay — TIMER[4] is an internal timer for the 5 s M Y E L signal delay — TIMER[5] is an internal timer for the 5 s X Y E L signal delay — TTMER[6] is an internal timer for the 200 ms P B U T T signal delay ' — TIMER[7] is an internal timer for the 2 s delay for turning on all the R E D lights — TIMER[8] is an internal timer for the 2 s delay for turning off all the R E D lights — possible value: {on, off} — initial value: off U N _ P B U T T — internal signal for indication whether the crossing button has been pressed for 200 ms or not Appendix C Traffic Light Controller 154 — possible value: {True, False} — initial value: False U N _ X V E C H — internal signal for indication whether the X V E C H stays on during the 10 s delay period or not — possible value: {True, False} — initial value: False Error — system malfunction signal — possible value: {True, False} — initial value: False External Interface Document Input Addresses P B U T T Reset — Address: 1:000/00 — Address: 1:000/07 — Type: D C — Type: D C X V E C H — Address: 1:000/01 — Type: D C Appendix C Traffic Light Controller 155 Output Addresses M R E D — Address: 0:001/0 — Type: D C M Y E L — Address: 0:001/01 — Type: D C M G R N — Address: 0:001/02 — Type: D C X R E D — Address: 0:001/03 — Type: D C Internal Addresses TIMER[0..8] — Addresses: T4:0 — T4:8 — Type: Timer X Y E L — Address: 0:001/04 — Type: D C X G R N — Address: 0:001/05 — Type: D C W A I T — Address: 0:001/06 — Type: D C W A L K — Address: 0:001/07 — Type: D C U N _ X V E C H — Address: B3/48 — Type: Binary U N _ P B U T T — Address: B3/32 — Type: Binary Error — Address: B3/160 — Type: Binary Appendix C Traffic Light Controller 156 System Requirements Document Part I: ESD Error Handling; 1 TfTIMER[5]) = 5s Appendix C Traffic Light Controller 158 Appendix C Traffic Light Controller 159 Part II: S-Spec SAT: M-Green; 0.1 Let InitCon = UC(MRED, MG RN, XRED, XYEL) A (MY EL = off) A (XGRN = off) A (WALK = off) A (WAIT = on) A (T/MBiJ[0..4, 6] = -off) A ( E r r o r = False) InitCon = True InitCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : M-Green: f ).l TTMER[5] = on (TIMER[5] = off) A (UN_PBUTT = Fasle) A (UN_XVECH = False) [(UN_PBUTT = True) V (UN.XVECH = True)] MGRN := on on no_opt MRED = off off no_opt XRED = on no_opt no_opt XYEL : = off no_opt no_opt TIMER[5] := off no_opt no_opt UN_PBUTT := no_opt13 no_opt False UN_XVECH := no_opt no_opt False SAT: PButt Timer; 0.2.1.1 Let ButtTCon = UT(MYEL, XGRN, WALK, WAIT, Error) A (MRED = off) A (MGRN = on) A (XRED = on) A (XYEL = off) A (TIMER = off) ButtTCon = True ButtTCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : PButt Timer: 0.2. .1 P B U T T = pressed P B U T T = unpressed TIMER[6] := on off U N _ P B U T T := False True no_opt = no operation Appendix C Traffic Light Controller 160 SAT: PButt; 0.2.1.2 Let PButtCon = UT(M RED, MY EL, MGRN, XRED, XYEL.XGRN, WAIT, WALK, TIMER[0..5],Error)/\TIMER[6] - on PButtCon = True PButtCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : PButt: 0.2.1.2 V(0<T(T fj\fBR[6])<200ms) (PBUTT = pressed) 3(O<T(TIMBB[6|)<200mi) (PBUTT = unpressed) U N _ P B U T T := False True TIMER[6] := no_opt off SAT: Delay; 0.2.2 Let DelayCon = PButtCon DelayCon = True DelayCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : Delay; 0.2.2 TIMER[6] = 200ms TIMER[6] <> 200ms TIMER[0] := on off TIMER[6] := off off Error := False True Appendix C Traffic Light Controller 161 SAT: Walk; 0.2.3 Let WalkCon = UT{M RED, XRED, XYEL, XGRN,WAIT, WALK,TIMER[1, 3,5, 6], Error) A (TIMER[0, 2] = off) A (TIMER[4] = on) A (MGRN = off) A {MY EL = on) WalkCon = True WalkCon = False idle /correct /error correct CAT/idle /error error . /idle (Error := True)/idle C A T : Walk: 0.2.3 T(TIMER[4]) = 5s T(TIMER[4]) <> 5s W A L K := on no_opt W A I T := off no_opt M R E D := on no_opt M Y E L := off no_opt X R E D := off no_opt X G R N := on no_opt TIMER[1] := on no_opt TIMER[4] := off no_opt Error := False True SAT: X - G r n Delay; 0.3.1 Let XDelay Con = Butt!'Con XDelayCon - True XDelayCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : X - G r n Delay; 0.3.1 X V E C H = on X V E C H = off TTMER[2] := on off U N _ X V E C H := False True Appendix C Traffic Light Controller 162 SAT: X-Green; 0.3.2 Let XGrnCon = WalkCon XGrnCon = True XGrnCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle C A T : X-Green: 0.3.2 T(TIMER[4]) = 5s T(TIMER[4]) <> 5s W A L K := on no_opt W A I T := orr- no_opt M R E D := on no_opt M Y E L := off no_opt X R E D := off no_opt X G R N :=. on no_opt TIMER[3] := on no_opt TIMER[4] := off no_opt Error := False True SAT: M-Yel; 0.4 Let MYelCon = UT(M RED, MY EL,MGRN, XRED, XYEL,XGRN, WAIT, WALK, TIMER[1,3,4,5], Error) A ((TIMER[0] = on) © (TIMER[2] = on)) A (TIMER[6] = off) MYelCon = True MYelCon = False idle /correct /error correct CAT/idle /error error /idle (Error := True)/idle Appendix C Traffic Light Controller 163 C A T : M-Yel ; 0.4 {T(TIMER[0}) = 2 5 s ) © (T(TIMER[2\) = 5s) {T(TIMER[0]) <> 25s)A (T(TIMER[2]) <> 5s) TIMER[4] := on no_opt M G R N := off no_opt M Y E L := on no_opt TIMER[0] := off no_opt TTMER[2] := off no_opt Error := False True SAT: X-Yel; 0.5 Let XYelCon = UC(MGRN, XYEL,TIMER[0,2,5,6]) A (MRED = on) A (MYEL = o / / ) A (XRED = off) A (XGRN = on) A (WAIT = off) A (WALK = o n ) A (TIMER[4] = off) A ((TIMER[1] = on) $ ( T / M B i l [ 3 ] = o n ) ) A UT(Error) XYelCon = True XYelCon = False idle /correct /error correct . CAT/idle /error error /idle (Error := True)/idle C A T : X-Yel : 0.5 (T(TIMER[l)) = 25s)® (T(TIMER[3]) = 20s) [T{TIMER[1]) <> 25s)A (T(TIMER[i\) <> 20s) T I M E R [5] := on no_opt X Y E L := on no_opt X G R N := off no_opt W A I T := on no_opt W A L K := off no_opt TIMER[1] := off no_opt TIMER[3] := off no_opt Error := False True Appendix C Traffic Light Controller 164 SAT: A l l Red On; 1.1 Let ErrCon = -,[(MRED = on) A (MYEL = off) A (MGRN = off) A (XRED = on) A (XYEL = off)A (XGRN = off) A (WALK = off) A (WAIT = on) A (TIMER = 0//)] ErrCon = True ErrCon = False idle /problem /fix problem CAT/idle /fix fix /idle (Error := False)/idle C A T : A l l Red On: 1.1 Error = True Error = False M R E D := on no_opt X R E D := on no_opt W A I T := on no_opt M Y E L :=• off no_opt M G R N := off no_opt X Y E L := off no_opt X G R N := off no_opt W A L K := off no_opt TTMER[7] := on off TIMER[8] := off off SAT: A l l Red Off: 1.2 ErrCon = True ErrCon = False idle /problem /fix problem CAT/idle /fix fix /idle - (Error := False)/idle Appendix C Traffic Light Controller 165 C A T : A l l Red Off; 1.2 Error = True Error = False M R E D := off no_opt X R E D := off no_opt W A I T := on no_opt M Y E L := off no_opt M G R N := off no_opt X Y E L := off no_opt X G R N := off no_opt W A L K := off no_opt TIMER[7] := off off TTMER[8] := on off SAT: Master Reset; 1.3 ErrCon = True ErrCon = False idle /problem /fix problem CAT/idle /fix fix /idle (Error := False)/idle C A T : Master Reset: 1.3 Reset = True Reset = False M R E D := on no_opt X R E D := on no_opt WAIT := on no__opt M Y E L := off no_opt M G R N := off no_opt X Y E L := off no_opt X G R N := off no_opt W A L K :=• off no_opt T I M E R := off no_opt Appendix D Executable Programs of the Drill Machine In this appendix, the ladder diagram and S F C of the Drill Machine in Appendix B will be listed. The mechanisms presented in Chapter 6 are used in here to transform the specification into executable program. A.1 Ladder Diagram Program L i s t i n g Report Rung 2:0 I Must be I f a l s e when • I the system I s t a r t s I B3 + 1 / [ I 7 Rung 2:1 PLC-5/15 Addr 0 I STV_AUTO STV_LS1 STV_ERR_T I B3 B3 B3 +-+--] [ + - T;]7[ — - - — ] / [ I I 0 | 46 160 I |STV_LS5 | I I B3 I |'+ — ] f + I I 80 I I ISTV_ERR_FI I I B3 | -I + ---] [---+ I 96 Rung 2:2 I I 1 STV_LS1 STV_LS4 STV_ERR_T I B3 B3 B3 + ---] t 1/1 ] / [ 16 32 160 I I I I I Rung 2:3 I I STV_LS4 STV_TIMER STV_ERR_T I B3 B3 B3 + . . . ] [ ] / [ ] / [ I 32 48 160 I I I I Rung 2:4 I I STV_TI MER- STV_LS2_OP STV_ERR_T I I I I I I Rung [ — 48 B3 - ] / [ - -64 B3 - ] / t ~ 160 Rung 2:0 I n i t i a l Routine +JSR + -+JUMP TO SUBROUTINE+ I Prog f i l e number 91 I Input par I I Return par B3:0 I + - - + . S t a r t +JSR + -+JUMP TO SUBROUTINE+ I Prog f i l e number 3 I Input par I Return p a r B3:1 I Return par B3:10 I I In I P o s i t i o n I I +JSR + I - +JUMP TO SUBROUTINE+- + I Prog f i l e number 4 1 I I Input par I I I Return par B3:2 I I j Return par B3:10 I j Dr i-1 l i n g I +JSR + I -+JUMP TO SUBROUTINE+-+ I Prog f i l e number 5 I I I Input par I I I Return par B3:3I I I Return par B3:10I I Backup I +JSR + | -+JUMP TO SUBROUTINE+-+ I Prog f i l e number 61 I I Input par I ! I Return par B3:4 I I I Return par B3:10I I File 2: Level 0 ESD (Continued) . . . 166 Appendix D Executable Programs of the Drill Machine 167 I STV_LS2_0P STV_LS5 STV_ERR_T I B3 B3 B3 + j [ ]/[ )/[ I 64 80 160 Rung 2:6 STV_ERR_T STV_ERR_F B3 B3 ] t ] / [ 160 96 Rung 2:7 Home +JSR + -+JUMP TO SUBROUTINE+-I Prog f i l e number 7 1 I Input par I I Return par B3:5 j I Return par B3:10 I E r r o r I Handl ing I I +JSR + | -+JUMP TO SUBROUTINE+-+ l-Prog f i l e number 81 I IInput par I I j Return par B3:6 j I I Return par B3:10I I - [END OP PILE] -File 2: Level 0 ESD Program L i s t i n g Report Rung 3:0 I UP_1 I B3 + - - ] / [ I 24 I Rung 3:1 I I LS5 CF_1 I riOOO B3 • + - - ] / [ - — ] / [ I 05 183 I I I Rung 3:2 I I LS5 CF_1 I 1:000 B3 + —1 [---]/[ I 05 183 I I I Rung 3:3 I INIT_C0N1 AUTO I B3 1:000 + - + - — ] [ - - - + - ] [-•----I I 176 I 00 I |INIT_CON2l I I B3 I I +---] !- —+ I 177 Rung 3:4 I INIT_CONl AUTO I B3 1:000 + - + - — ] [- — + - ] / [ | 176 I 00 IINIT_CON2I I B3 I 4 - - — ] [ - - - + 177 Rung 3:5 i INIT_CONl INIT_CON2 PLC-5/15 Addr 0 Rung 3:0 STV_LS2_OP B3 + - — ( U ) + -I 64 | ISTV_LS3_OP| I B3 | + — ( U ) + I 65 I ' I UF_1 I I B3 I + ( L ) - + 24 In i tCon 1 +JSR + -+JUMP TO SUBROUTINE +-I Prog f i l e number 10 I I Input par I I Return par B3:111 I n i t C o n 2 +JSR + -+JUMP TO SUBROUTINE +-I Prog f i l e number 111 I Input par I I Return par B3:111 I B3 - ] / [ - -176 B3 - ] / [ — 177 -+ I CONVEYOR O:001 — (L) 00 CONVEYOR O:001 — (U) 00 I ERROR | B3 I - + ( L J - + - + I 1501 | |STV_ERR_T| | I B3 I I + - - - ( D - - - + | I 160 I | IERROR_CON| | I B3 | | + -—(U)—-+ I I 256 | | I UF_1 |- | I B3 I | + (U)-+ I File 3: Start; 0.1 (Continued) . . Appendix D Executable Programs of the Drill Machine 168 I • 1 - 2 4 1 I ' I CF_1 I I I B3 I I + (U)- + | • 183 Rung 3:6 I LSI STV_ERR_T STV_LS1 I 1:000 B3 B3 +..] [ ]/[ 1 ( L J ; _ ! I 01 160 I 16 I | |IN_POS_CON| I I B3' I + (U) + I 192 I | I MOTOR_CONI | i I B3 - I + (U)- —+ I 193 | | I UF_1I | ' I B3 | + (U)- + I I 24 1 | I CF_1I I I B3 I | + (U)- + | 183 Rung 3:7 I +RET + I ; - + RETURN () +- + | I Return par B3:1 I I I I Return par B3:101 I I + + | Rung 3:8 I • I + . [END OF FILE] T + File 3: Start; 0.1 Program L i s t i n g Report Rung 4:0 I ' UF_2 I B3 PLC-5/15 40 Rung '4:1 I CF_2_1 I B3 + - - ] / [ I 199 Rung 4:2 I IN_POS_CON LSI I B3 1:000 + ] [ ] [--192 01 3r 0 Rung 4:0 STV_AUTO | B3 | _ _ + ( u ) _ _ _ + _ + I 0 I STV_LS5 I B3 + (U) — I 80 I STV_ERR_F I B3 + (U) — I 96 ISTV_ERR_T2 I B3 + - — ( U ) - - - -I 97 ISTV_ERR_T3 I B3 + -—(U) I 98 i UF_2 I B3 + (L)-+ I 40 I InPosCon I ' I +JSR + I -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 12 1 I 11nput pa r ' I I . I Return par B3 :12 I I I I I I I Rung 4:3 I IN_POS_CON LSI STV_LS3_CL I B3 1:000 B3 + ] [ ] [ ]/[ I 192 . 01 33 Rung 4:4 I IN_POS_CON CONVEYOR O:001 — (U)- — + -00 I C L l I O:001| (L)-+ 01 D_S_F O:001 — (L) — 02 ERROR File 4: In Position; 0.2 (Continued) Appendix D Executable Programs of the Drill Machine 169 B3 - + - — ] / [ + -I 192 I I LSI IN_POS_CONI 11:000 B3 •• 1 + - ] / [ ] [ + 01 192 I I Rung 4:5 I LS3 STV_ERR_T I 1:000 B3 + --] 1 ] / [ I 03 160 Rung 4:6 I I I STV_LS3_CL I B3 +---- ] [ I 33 Rung 4:7 B3 -<L) I + - + I 1501 I |STV_ERR_T| | I ' B3 I I + -—(D---+ I I 160 I | |ERROR_CONI I I . B3 | | + — ( U ) - - - + | I 256 - | | I UF_2 | | I B3 | | + (U) • 40 | | CF_2I I B3 | I -(U)-+ I 199 | STV_LS3_CL | B3 "(L)--33 D r i l l Motor I , Rung 4:8 I • ' . + [END OF FILE] -+JSR + I -+JUMP. TO SUBROUTINE +- + I Prog f i l e number 13 I I I Input par I I I Return par . B3:2I I I Return par B3:10I I +RET + I - + RETURN {) • +- + I Return par B3:2 I I I Return par -B3:10I I + _ + | I File 4: In Position; 0.2 Program L i s t i n g Report Rung 5:0 I UF_3 I B3 + - - ] / [ I 56 Rung 5:1 PLC-5/15 Rung 5:3 I DRILLINGCO I B3 + -+—]/[—,— -I I 208 Rung 5:0 STV_LS1 | B3 I - + — ( U ) — + - + I 16 | | I UF_3| | I B3 I | + — (L)-+ | 56 I D r i l l i n g - I I Con I I CF_3 I | B3 , " + JSR + | + - - ] / [ - : ; +JUMP TO SUBROUTINE +- + I 215 . • I Prog f i l e number 15 1 I I I Input par I | I I Return par B3:131 I • I : + + | Rung 5:2 I DRILLINGCO LS4 D_S_F I I . 'B3 . . I:000 0:001 | +----] [ ] [ + ' ---(U)- + - + I 208 04 | 02 I I I I +RTO + ' | | I ++RETENTIVE TIMER ON+-(EN)+ I I I Timer T4:01 - . |. I I Time base . . 1.0+-(DN) I I . I Preset 21 I I "lAccum . 0| I -ERROR B3 — ( L ) - + 150 | File 5: Drilling; 0.3 (Continued) Appendix D Executable Programs of the Drill Machine 170 IDRILLINGCO LS4 I I B3 1:0001 + ---] t ]/[- + 208 04 Rung 5:4 |STV_ERR_TI I I B3 I I + — - ( D - - - + I I 160 I I |ERROR_CON| | I B3 I I + - - - (U) - - -+ I I 256 I I I UF_3 I I I B3 I I + (U)-+ I I 561 I I CF_3I I I B3 I | + (U)-+ I 215 | + CMP -+COMPARE I Expression |T4:0.ACC = 2 STV_ERR_T -+ B3 + ] / ! I 160 I Rung 5:5 STV_TIMER B3 - + (L) + I 48 I IBACKUP_CON| I B3 | + --- (U) + I 224 | ISTOP_MOT_C| I B3 | + - — ( U ) + I 225 I I UF_3I I B3 I + (U)- + I 56 I I CF_3I I B3 + (U)-215 Rung 5:6 I I + RET + -+RETURN () +-I Return par B3:3 I I Return par B3:10I • [END OF FILE] -File 5: Drilling; 0.3 Program L i s t i n g Report Rung 6:0 I STV_TIMER STV_LS3_OP I B3 B3 + ] [ .- — ] / [ I 48 65 PLC-5/15 Rung 6:1 I I STV_LS3_OP STV_LS2_OP B3 B3 ] [ ]/[ 65 64 Rung 6:2 I Rung 6:3 I - [END OF FILE]-Addr 0 Rung 6:0 Stat ion Backup +JSR + | -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 23 1 I I Input par I I I Return par B3:4 I I I Return par B3:10 I I Stop D r i l l Motor +JSR -+JUMP TO SUBROUTINE I Prog f i l e number I Input par I Return par B3:4 I Return par B3:10 I 17 1 I I + RET -+RETURN () I Return par I Return par B3 :4 I B3 : 1 0 | File 6: Backup; 0.4 Appendix D Executable Programs of the Drill Machine 171 Program L i s t i n g Report Rung 7:0 I UF_5 I B3 + - - ] / [ PLC^5/15 Addr 0 Rung 7:0 I I I I I Rung 7:1 I I CF_6 I B3 +--]/[ I 247 I I I Rung 7:2 I HOME_CON STV_TIMER B3 -+—(U) -—+ - + I 48 | | I UF_5 I I I B3 I I + (L)-+ I HomeCon I B3 -] [--240 LS2 1:000 - ] / [ — 02 I I Rung 7:3 I " I HOME_CON B3 - + - - ] / [ I 240 |HOME_CON LS2 B3 1:0001 -] [ ] [- + 240 02 I I Rung 7:4 I LS5 STV_ERR_T I 1:000 B3 +--] [ ] / [ — I 05 160 I I Rung 7:5 I I Rung 7:6 I +JSR + I -+JUMP TO SUBROUTINE +-'+' I Prog f i l e number 19 I I I Input par I I I Return par B3:15| I + + | I D_S_B O:001 I - + (U)- + - + I 04 I I I CL1 I I I 0:0011 | i (U)-+ | I 01 | | I CONVEYOR| I I 0:001 | | + — ( L ) — + I 00 ERROR B3 - + (L)- + I 150| ISTV_ERR_TI | I B3 I I +---(L)---+ | I 160 I I IERROR_CON| | I B3 I I + — ( U ) — -+ I I 256 | I I UF_5 I I I B3 | | + (U)-+ I I 88 | | I CF_6 | | I B3 I | + (U)-+ I 247 | STV_LS5 | B3 I •+ (D--+-+ I 80 I I |INIT_CONl| I I B3 I I + - — ( U ) — + I I 176 I I |INIT_CON2| | I B3 I I +---(UJ---+ I I 177 I I I UF_5 I I I B3 I I + (U)-+ I I 88 I I I CF_6I I I B3 I I + (U)-+ I 247 | + RET + I -+RETURN () +-+ I Return par B3:5 I I I Return par B3:10 I I + + | - [END OF FILE]-File 7: Home; 0.5 Appendix D Executable Programs of the Drill Machine ' 172 Program L i s t i n g Report Rung 8:0 I PLC-5/15 Addr 0 Rung 8:0 Shut Down I STV_ERR_T I B3 + - + -—] [----160 . STV_ERR_T3 B3 ] [ STV_ERR_T2 B3 ] / [ 97 I ! I I I I +-I • • 98 Rung 8:1 I I I STV_ERR_T2 STV_ERR_T3 I B3 -] [ — 97 Rung 8:2 I B3 - ] / [ - -98 +J SR + - +JUMP TO SUBROUTINE +-I Prog f i l e number 20! I Input par I I Return par B3:6 I I Return par B3:10I Emergency ! L i g h t I I +JSR--- + I -+JUMP TO SUBROUTINE +-+ I Prog f i l e number. 211 j I Input par I I I Return par B3:6 I I I Return par B3:10 I I +RET + I RETURN (j + - + I Return par B3:6 I I I Return par B3:10I I Rung - [END OF FILE] ' . + File 8: Error Handling; 1 Program L i s t i n g Report Rung 9:1 PLC-5/15 . Rung 9:0 STV_AUTO B3 — ( U ) — + -0 I STV_LS1| B3 I -—(U)—+ - 16 I STV_LS4| B3 | -—(U)—+ ' 32 • |-I STV_LS3_CL| I B3 I + - — (U) + I 33 I I STV_TIMER| I B3 , I + ( U ) — + I 48 | ISTV_LS2_OPI I B3 | + -—(U) + I 64 I-I STV_LS3_OP| I B3 | + - — ( U ) — — + I 65 | I STV_LS5| I B3 | +-—--(U)- -+ I 80 | I STV_ERR_F | I B3 I + (U)- —+ I 96 | I STV_ERR_T I I B3 I + ( U ) - - - + I 160 | I STV_ERR_T2 I . I B3 I + — ( U ) + I 97 | I STV_ERR_T3 I I B3 | + — (U) + File, 9: Initialization (Continued) Appendix D Executable Programs of the Drill Machine 173 .1, R u n g 9 :2 R u n g 9 :3 C P _ 1 B3 + (U1- + -I 183 1 I B3 I + ( U ) - + I 1981 I C F _ 2 I I B3 I + ( U ) - + I • 1991 I C F _ 3 I I B3 I + ( U ) - + I 21'5| I C F _ 5 | I B3 | + — r — - ( U ) - + I 2301 I C F _ 4 | I B3 I + ( U ) - + I 2311 I C F _ 6 I I B3 I + ( U ) - + I 2471 I C F _ 7 | I B3 I + ( U ) - + I 2631' I I N I T „ C 0 N 1 | I B3 I + ( U ) — - + I . 176 | I I N I T _ C O N 2 | I B3 | • + — - - ( U ) — + I ' 177 ' | I I N _ P O S _ C O N | I B3 • I + - — ( U ) + I 192 I I M O T O R _ C O N | I B3 . I + ( U ) — + I 193 ' I I D R I L L I N G C O | I B3 I + - - - (U) + I 208 | | B A C K U P _ C O N | I • B3 I + — ( U ) - - —+ I 224 , I | S T O P _ M O T _ C | I B3 | + - — (U) + I 225 I I H O M E _ C O N | I B3 I + ( U ) — + I 240 . | I ' E R R O R _ C O N I I B3 I + ( U ) — + 256 ' UF 1 B3 I - + - ( U ) - + I 241 ! UF_2I -, I B3 I + - ( U ) - + •I 4 0 ! I U F _ 3 I I B3 I +-<U) -+ I 56 I I UF_4I I B3 I + - { U ) - + File 9: rnitialization (Continued) Appendix D Executable Programs of the Drill Machine VIA I • I 721 I ! I UP_5| I I I B3 I I I ' +-(U)-'+ I I 88 I Rung 9:4 ! AUTO STV_AUTO I I 1:000 B3 I + __] [ + _ _ ( L ) _ _ _ + _ + I 00 I 0 I I I I B3 I I I + (L)-+ I I 7 |. Rung 9:5 I +RET + I + + RETURN () +- + I I Return par B3:01 I I + + | Rung 9:6 I ' I + __ [ END OF FILE]' + I I File 9: Initialization Program L i s t i n g Report PLC-5/15 Addr 0 Rung 10:0 Rung 10:0 I LSI LS2 LS3 LS4 CONVEYOR CLl D_S_F D_M D_S_B ERROR I 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001 T4:0 B3 > + - - ] / [ — ] / [ - — ] / [ — - ] / [ ] / [ ] / [ — ] / [ — ] / [ — ] / [ — ] / [ — ] / [ > I 01 02 03 04 00 01 02 03 04 EN 150 > INIT_CONl I < B3 I <-—(L) + < 176 I Rung 10:1 ! CF_1 I I B3 I + ( D - - + I 183 I Rung 10:2 I ' +RET + I + + RETURN () +- + I , I Return par B3:111 I I + + | Rung 10:3 I I + [END OF FILE] + File 10: InitCon 1 Program L i s t i n g Report , PLC-5/15 Addr 0 Rung 11:0 Rung 11:0 I • LSI LS2 LS3 LS4 CONVEYOR CLl D_S_F D_M D_S_B ERROR I 1:000 1:000 1:000 1:000 O:001 O:001 0:001 O:001 O:001 T4:0 ' B3 > + - - ] / [ — - ] / [ - — ]/[ — -]/[' ] f ] / [ . _ - ] / [ . . _ ] / [ _ _ _ ] / [ _ _ _ ] / [ _ _ _ ] / [ > I 01 02 03 • 04 00 01 . 0 2 03 04 EN 150 •> INIT_CON2 I < B3 I • • < — (L) + < 177 I Rung 11:1 I CF_1 | I B3 | + . ( D - - + I 183 I Rung 11:2 I • +RET + I + + RETURN () +- + I I Return par B 3 : l l | I I ' + . _ _ + | Rung 11:3 I - I + [ END OF FILE] File 11: InitCon 2 Appendix D Executable Programs of the Drill Machine 175 Program L i s t i n g Report PLC-5/15 Addr 0 Rung 12:0 Rung 12:0 I AUTO LS2 LS3 LS4 LS5 CONVEYOR CL1 D_S_F D_M D_S_B ERROR I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001 T4:0 B3 > + --] [- — ]./[ — ] / [—-1/1- — ] [ ] / [ — ] / [ — ] / [ - — ] / [ — - ] / [ — ] / [ > I 00 02 03 04 05 00 01 02 03 04 EN 150 > IN_POS_CON | < B3 I • < (L) + < 192 I Rung 12:1 I CF_2 I I B3 ' | + ( D - - + I 199 I Rung 12:2 I + RET + I + + RETURN () +- + I I Return par B3:12 I I I + + | Rung 12:3 I I + [END OF FILE] + File 12: InPosCon Program L i s t i n g Report Rung 13:0 I I ,CF_2_2 I B3 + - - ] / [ I 198 I I I Rung 13:1 I MOTOR_CON LS3 I B3 1:000 + ] [ ] [ I 193 03 Rung 13:2 I MOTOR_CON I B3 +-+---]/[---+ I I 193 |-I I LS3 I I 11:000 I I +-]/[ + I 03 I I PLC-5/15 MotorCon Rung 13:0 I I + I +JSR -+JUMP TO SUBROUTINE +-+ tProg f i l e number 14 I 1 I Input par I i I Return par B3:12 I I I I Rung 13:3 I LS4 STV_ERR_T I 1:000 B3 + -- ] [ ] / [ I 04 160 I I 0:001 I - - (L) — + 03 I ERROR | B3 | -+ (L1- + - + I 1501 I |'STV_ERR_T| I I B3 I I + - — ( L ) — + r I 160. I I |ERROR_CON| | I B3 | | + - — ( U ) — -+ I .1 256 I I I B3 I I + (U)-+ I I 1981 | I CF_2I I I B3 I I + (U)-+ I I • 1991 | I UF_2| I I B3 | | + (U)-+ I 40 I STV_LS4 B3 • (L) -I 32 I I IDRILLINGCOI I I B3 | | + — ( U ) 208 -+ I I I B 3 • ( U ) -1981 I CF_2 B3 - ( U ) -199 UF_2 B3 I I I ! + I I I I I File 13: Drill Motor; 0.2.4 (Continued) . Appendix D Executable Programs of the Drill Machine 176 i i Rung 13:4 I I I Rung 13:5 I + (U)-+ I 40 I + RET + I -+RETURN () +-+ I Return par B3:2 I I I Return par B3:10 I I + + | [END OF FILE] File 13: Drill Motor; 0.2.4 PLC-5/15 Addr 0 Program L i s t i n g Report Rung 14:0 I LSI LS2 LS4 LS5 CONVEYOR C L l D_S_F D_S_B D_M ERROR I 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001 T4:0 B3 + --] [- — ] [---]/[ — ]/[ ]/[ ] I---] [- — ]/[ — ] / [ — -]/[ — ]/[--I 01 02 04 05 00 01 02 04 03 ' EN 150 MOTOR_CON I < B3 I <-—(L) + < 193 | Rung 14:1 Rung 14:0 Rung 14:2 Rung 14:3 - [END OF F I L E ] -File 14: MotorCon - ( L ) - -198 +RET + -+RETURN () + I Return par B3:12.| PLC-5/15 Addr 0 Program L i s t i n g Report Rung 15:0 I AUTO LSI LS2 LS3 LS5 CONVEYOR C L l D_S_F D_M D_S_B I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001 + --] [---] [- — ] [---] [---]/[ ]/[ ] [---I [ — ] [ — ]/[ — - ] / ! -I 00 01 02 03 05 00 01 02 03 04 EN DRILLINGCO I < B3 I < — (L) + < 208 I Rung 15:1 I I Rung 15:0 ERROR T4 :0 B3 -]/[ > 150 > CF_3 B3 - ( L ) - -215 Rung 15:2 I I Rung 15:3 + RET + I -+RETURN () +-+ I Return par B3:13I I - [END OF F I L E ] -File 15: DrillingCon Program L i s t i n g Report PLC-5/15 Addr 0 Rung 16:0 Rung 16:0 I AUTO LSI LS2 LS3 LS4 LS5 CONVEYOR C L l D_S_F D_M D_S_B I 1 :000 1:000 1:000 1:000 1:000 1:000 O:001 O-.001 0:001 O-.001 O:001 T4 :0 > + --] [---] [ —-] [---] [---] [- — ] / [ ] / l ] [- — ] / [ - - - ] I- —] / [ — -] I > I 00 01 02 03 04 05 00 01 02 03 04 EN > ERROR BACKUP_CON I < B3 B3 I <-] / [ (L) + < 150 224 I Rung 16:1 I ' CF_4 | I B3 | + (L)- -+ | 231 I File 16: BackupCon (Continued) . . Appendix D Executable Programs of the Drill Machine 177 Rung 16:2 +RET -+RETURN () I Return par B3:14l I Rung.16:3 - [END OF FILE] '— + File 16: BackupCon Program L i s t i n g Report Rung 17:0 I I CF_5 I B3. ' + - - ] / [ I 230 I I I Rung 17:1 I STOP_MOT_C LS3 I B3 1:000 + ] [ - T ] / [ - - — - -I 225' 03 Rung 17:2 I STOP_MOT_C I B3 + - + - - - ] / [ + I 225 I I LS3 I 11:000 I + -] [ + 03 PLC-5/15 StopMotorC I I I I I I I I I ' Rung 17:3 I LS2 STV_ERR_T I 1:000 B3 + - - ] / [ ] / l I 02 160 I I I I I I I I Rung 17:4 I I I Rung 17:5 Rung 17:0 I I +JSR + I -+JUMP TO SUBROUTINE +-+' I Prog f i l e number 18 I I I Input par • I j I Return par B3:14 I I + + | D_M | O:001 | — (U)—+ 03 | ERROR | B3 | - + ( L ) - + - + I 1501 ,1 |STV_ERR_TI | I B3 I I + — . < D — + I I 160 | | I CF_5 | | I B3 I I + (U}-+ | ' 230 1 STV_LS2_OP | B3 I - + — ( L ) + - + I 64 | | I HOME_CONI I I I I B3 • (U)-240 | | C F _ 5 | I B3 | | - - ( U ) - + I 230 I +RET + | -+RETURN () ' " +-+ I Return par B3:4 I I I Return par B3:10 I I [END OF FILE] - - ; File 17: Stop Drill Motor; 0.4.2 Program L i s t i n g Report • ' PLC-5/15 Addr 0 Rung 18:0 Rung 18:0 I AUTO LSI LS2 LS4 LS5 CONVEYOR CL1 D_S_F D_M D_S_B ERROR I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 0:001 O:001 O:001 T4:0 •B3 > + — ] ' [ — ] [---] [ — ] / [ — ] / [ ] / [ '] [ — ] / [ — -] [- —] [- — ] / [ - - - ] / [ > I 00 01 02- 04 ' 05 00 01 02 . '03 04 EN 150 > STOP_MOT_C | < B3 | <-—(L) + < 225 I Rung'18: l I CF_5 I I , B3 I + _ _ ( L ) - - + I •• 230 I Rung'18:2 I +RET ' ' + I + ___ : + RETURN () +- + File 18: StopMotorCon (Continued) . . . Appendix D Executable Programs of the Drill Machine 178 I i Rung. 18:3 I I Return par B3 :14 | - [END O E ' F I L E ] -Fi le 18: StopMotorCon PLC-5/15 Addr 0 -Program L i s t i n g Report Rung 19:0 ' -I LSI . AUTO LS3 LS4 • 'LS5 - CONVEYOR C L l D_S_F D_M D_S_B I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001 + --] ' • [ — ] [ - - - ] / [ . — ] / [ — - ] / [ ] / [ 1 [- — ] / [ — - ] / [ - - - ] [ — I 01 00 ' 03 04 • 05 00 01 02 03 04 HOME_CON I ' • , • < B3 i • ' . • • ,<--(L) + < 240 ' | Rung 19:1 I . . • I + ' I . Rung 1 9 : 2 ' I • ' . Rung 19:0 ERROR T4 : 0 B3 - ] / [ — EN 150 CF_6 I B3 I - ( D - - + 247 I I I Rung 19:3 I + RET . -+RETURN () l-Return par -+ I +- + B3 =15 1 I + 'I - [END OF F I L E ] -Fi le 19: HomeCon Program L i s t i n g Report Rung 20:0 UF_6 B3 - ] / [ - - -104 PLC-5/15 Rung 20:0 ' INIT_C0N1 B3 + ( U ) — + -I 176 | I INIT_CON2I I- B3 | t (U)- —+ 177 I STV_AUTOI B3 ' I - - ( U ) - - - + 0 | STV_LS1I B3 , | -—(U)—+ 16 | STV_LS4 I B3 I -—(U)—+ • 32 | I STV_LS3_CLI ! B3 I + (U) + I 33 I I "STV_TIMER | I B3 | t ( U ) — + I 48 | I STV_LS2_OP| I B3 | + (U) + I 64 | I STV_LS3_OP| I Rung 20:1 I B3 I - (U)- — + • 65 I STV_LS5| B3 | -—(U). —+ 80 -| UF_6 I B3 I (L)-+ 104 Fi le 20: Shut Down; 1.1 (Continued) Appendix D Executable Programs of the Drill Machine 179 CF_7 B3 - ] / [ - -263 I Rung 20:2 I ERROR_CON ERROR I B3 B3 + ] / [ - - - . - - ] [ — I 256 150 I I I -Rung 20:3 I ERROR_CON STV_ERR_T2 I B3 B3 + ] [ ] / [ . I 256 97 I I I Rung 20:4 I ERROR_CON ERROR I . B3 B3 + ] [ ] / [ - -I 256 150 Rung 20:5 I ERROR I B3 -] [--150 I I Rung 20:6 I +JSR + -+JUMP TO SUBROUTINE +-I Prog f i l e number 22 1 I Input par ' I I Return par B3:16l CONVEYOR O:001 — ( U ) - - - + -00 I CL1 I O :001| (U)- + 01 I D_S_F| 0:001| (U)-+ 02 I D_M I O:001| (U)- + 03 I D_S_B| O:001I (U)-+ 04 | T4 :0 | (RES) + I ERROR I B3 i - + (U) -+- + I 1501 I ISTV_ERR_T| I I B3 | | + - — (U)— -+ i i 160 | | I STV_ERR_F | | I ' B3 I I + - - - (L) 96 I I I UF_6 I I I B3 | | + (U)-+ I I 1041 I I C F _ 7 | | I B3 I I + (U)-+ I 263 1 ' EM_LIGHT | O:001 | (U) + 07 I STV_ERR_T2 I B3 I - + - - - ( L ) + - + I 97 I ISTV_ERR_T3I I B3 - (U)-CF_7 | B3 | - ( U ) - + 263 I I -+ • I I I I I Rung 20:7 I + R E T - - + I -+RETURN () +-+ I Return par B3 : 6 I I I Return par B3:10 I I I • [END OF F I L E ] -File 20: Shut Down; 1.1 Program L i s t i n g Report PLC-5/15 Addr 0 Rung 21:0 Rung 21:0 File 21: Emergency Light; 1.2 (Continued) . . . Appendix D Executable Programs of the Drill Machine 180 I CF_7 I B3 + - - ] / [ — I 263 E r r o r C o n +JSR + -+JUMP TO SUBROUTINE +-I Prog f i l e number 22 I I Input par I I Return par B3:16 I Rung 21:1 I ERROR_CON ERROR I B3 B3 + ]/( ] [ I 256 150 Rung 21:2 I ERROR_CON STV_ERR_T3 I B3 -] [ — 256 B3 - ] / ! - -98 I I Rung 21:3 I ERR0R_CON ERROR I B3 B3 + ] [ ] / [ - -I 256 150 Rung 21:4 I ERROR I B3 -] [ — 150 Rung 21:5 I Rung 21:6 EM_LIGHT I 0:001 I ( L ) + 07 I ERROR | B3 | + (U1- + - + I 1501 I |STV_ERR_T| | I B3 I I + -—(U)—+ I I 160 I I |STV_ERR_F| I I B3 I I + - ~ (L)—"+ I I 96 I I I CF_7I I I B3 I I + (U)-+ I 263 I : EM_LIGHT I 0:001 | i —_(U) + 07 I STV_ERR_T3 I B3 I + — - ( L ) + - + •I 98 I I I STV_ERR_T2 I I ! B3 | | +-—(U) + I I 97 | | I C F _ 7 | | I B3 | I + (U)-+ | 263 I +RET + I -+RETURN () +-+ I Return par B3:6 I I I Return par B3:10I I + + | -[END OP F I L E ] -File 21: Emergency Light; 1.2 Program L i s t i n g Report PLC-5/15 Addr 0 Rung 22:0 Rung 22:0 I AUTO LSI LS2 LS3 LS4 LS5 - CONVEYOR C L l D_S_F D_M D_S_B I 1:000 1:000 1:000.1:000 1:000 1:000 T4:0 O : 0 0 l ' O:001 O:001 O:001 O:001 > + - - ] / [ - - - ] / [ - — ] / [ - - - ] / [ - - - ] / [ — - ] / [ - - - ] / [ ] / [ ] / [___]/ [___]/ [___]/ [ > I . 00 01 02 03 04 05 EN 00 01 02 03 04 > ERROR_CON I < B3 I <-— (L) + < 256 I Rung 22:1 I ' ' CF_7 | I B3 I + _ _ ( L ) - - + I 263 I Rung 22:2 I +RET + I + _ + RETURN •() +- + I I Return par ' B3:16 I I f. + _ _ _ + | Rung 22:3 I ' I + [END OF FILE] + File 22: ErrorCon Appendix D Executable Programs of the Drill Machine 181 Program L i s t i n g Report Rung 23:0 I UF_4 I B3 + - - ] / [ I 72 PLC-5/15 Rung 23:1 I I Rung 23:0 STV_LS4 B3 + (U) — I ; 32 I STV_LS3_CL I B3 . + -—(U) I 33 I UF_4 I B3 + ( L ) - + 72 CF_4 I B3 + - - ] / [ I 231 I I I Rung 23:2 I BACKUP_CON I B3 + - + - — ] / [ I I 224. I I +CMP ++COMPARE I Expres s ion IT4:0.ACC <> BackupCon +JSR + -+JUMP TO SUBROUTINE ' + I Prog f i l e number 16 I I Input par I I Return par B3:14 I I + I I I • Rung 23:3 I BACKUP_CON I 1 B3 +CMP + ] [ +COMPARE BACKUP_CONI • + T4 :0 B3 I + -- ] [ ] [ + I EN 224 I ERROR | B3 | - + ( D - + - + I 1501 | |STV_ERR_T| | I B3 | | + — ( D - - - + I I 160 | | |ERROR_CON| | I B3 I I + -—(U) — D_S_B 0:001 I 224 I | + I Rung 23:4 I LS3 STV_ERR_T I 1:000 B3 "+ — ] / [ ] / [ I 03 ' 160 I I I I I I I I Rung 23:5 I I Expres s ion | T 4 : 0 . A C C = 2 Rung 23 :6' I 256 I I UF_4 I I B3 I I - ( U ) - + I 72 I I CF_4 I I B3 - I I -<U)-+ I 231 I + - ( D - + - + I 04 1 I I T4 : 0 | | +(RES)+ I I STV_LS3_OP | B3 I - + — ( L ) — — + I 65 | | I UF_4| | I B3 I I + (U) 72 I I CF_4I I B3 I I - (U)-+ I 231 I + RET + | -+RETURN () +-+ I Return par B3:4 I I I Return par B3:10 I I - I - [END OF F I L E ] -File 23: Station Backup; 0.4.1 Appendix D Executable Programs of the Drill Machine A.2 SFC 182 I n i t i a l i z a t i o n 002 - + -003 I I 001 : I -- + --004 S t a r t ; 0.1 I Stat ion Forward; 0 .2 .3 006 I I 002 : I I 025 Shut Down; 1.1 D r i l l I Motor; - + -006 I 027 I GO TO 002 < + I -+Emer-Igency -+Light ; 1.2 - - + I - + -026 I GO TO 001 < + I I - + -026 I GO TO 001 I 009 I 006 I - + -013 I -- + + 022 I Dummy Dummy Dummy D r i l l i n g ; 0.3 Stop +-Conveyor; I 0.2.1 +-007 I 008 I + + + Clamp Wood 011 I + + + I - + -010 + + + I 011 I + + + I GO TO 002 012 014 006 I 015 Fi le 1: Sequential Function Chart (Continued) Appendix D Executable Programs of the Drill Machine 183 S t a t i o n 0 .4 .1 • Stop D r i l l Motor; 0 .4.2 Home; 0.5 - + -' 021 I GO TO 001 002 < + 006 I GO TO 002 016 ] Backup; --+---+ 006 GO TO 002 I -018 I 01 006 I -•' GO TO 002 File 1: Sequential Function Chart Appendix D Executable Programs of the Drill Machine 184 Program L i s t i n g Report ' PLC-5/15 Addr 0 • Rung 2:0 Rung 2:0 I CONVEYOR I I 0:001 | (U) - - -+ -1 00 I 1 CL1 1 1 0:0011 + - - - - (U) -+ 1 01 I ! D_S_F 1 ! 0:001 | +- - - - (U) -+ 1 02 I 1 D M 1 1 0:001 | +— - - (U) -+ 1 03 1 1 D S B! 1 0:001 | + - - — (U)- + 1 04 | 1 EM LIGHT| 1 0 :001 1 + - - (U)-- -+ 1 07 . | 1 TIMER| 1 T4 :0 | + - -| -(RES)+ j I' ERROR| 1 B3 | —(U)-+ I 150 Rung 2:1 I INIT_CONl I B3 + _ + ( U ) - - - + -I • • I o r I I INIT_CON2| I I B3 | | + ( U ) - - - + I - 1 1 1 I |IN_POS_CON| I I B3 | | • , . +—(U) + I I 16 I I I MOTOR_CON| I I B3 | I „ + ( U J - - - + I I 32 I I |DRILLING_C| I I B3 | | +---(U) + I I 48 | I |BACKUP_CONI I I B3 | | +---(U) + I . I 64 I I ISTOP_MOT_C| I I B3 | I . +-.-- (U) + I I 80 I I I HOME_CON| I " I B3 I | . . . + ( U ) — + I I 96 | I I ERROR_CON| I I B3 I | + _ ± _ _ ( U ) _ _ _ + I I 112 I I I CF_1I I • • I B3 I | • + ( u ) _ + I ' • I 71 I •• - I CF_2 I I I B3 I | + ( u ) - + I . 1 - 2 3 1 I * I C F _ 3 | I I B3 | | • + (U)- + I I 39 1 I I C F _ 4 | File 2: Initialization (Continued) Appendix D Executable Programs of the Drill Machine 185 Rung 2:2 I + [ E N D OF FILE] -I B3 I + (U)- + I 55 1 •I CF_5I I B3 I + (U)- + I 71 I I CF_6I I B3 I + (U)- + I 87 1 I C F _ 7 | I B3 I + (U)- + I 1031 I CF_8 I I B3 | + (U)- + 119 Fi le 2: Initialization Program L i s t i n g Report PLC-5/15 Addr-0 Rung 3:0 Rung 3:0 I AUTO I I 1:000 ' I + __] [ : [EOT]- + I 00 ' I Rung 3:1 . ' I. I + . [END OF FILE] + Fi le 3: Transition Condition: A U T O = O n Program L i s t i n g Report Rung 4:0 I I I LS5 CF_1 I 1:000 B3 + - - ] / [ - - - ] / [ I 05 7 I I I Rung 4:1 I I I LS5 CF_1 I 1:000 B3 + - - ] [- — ] / [ I 05 7 I I I Rung 4:2 I INIT_CONl AUTO I B3 1:000 +-+---] [---+-] [ I I 0 I 00 I |INIT_CON2l I I B3 I I +- —] [_-- + I 1 Rung 4:3 I INIT_CONl AUTO I B3 1:000 + - + - — ] [- — + -]/[ I I 0 I 00 I IINIT_CON2| I I B3 I | +___] [. . .+ I 1 Rung 4:4 I INIT_CONl INIT_CON2 I B3 B3 + ]/[ ]/[ I 0 1 Rung 4:5 I PLC-5/15 •Addr 0 Rung 4-0 I I n i t C o n _ l +JSR + I -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 30 1 I I Input par I I I Return par B3:0 I I InitCon_2 +JSR -+JUMP TO SUBROUTINE I Prog f i l e number I Input par I I I Return par B3:0I I 29 I I CONVEYOR I O:001 I — (L) + 00 I CONVEYOR I O:001 I — (U) + 00 I ERROR B3 — <L)--150 • [END OF FILE] File 4: Start; 0.1 Appendix D Executable Programs of the Drill Machine 186 Program L i s t i n g Report Rung 5:0 I LSI I 1:000 +--] [ I 01 I I I I I I I I I I I Rung 5:1 I PLC-5/15 Rung 5:0 IN_POS_CON I B3 I + — - ( U ) + - + I 16 | | I MOTOR_CONI | I B3 | | (U)- —+ I 32 I I CF_1 I I B3 I I - - ( U ) - + | 71 I I I + [EOT]+ I I I - [END OF FILE] + Fi le 5: Transition Condition: L S I = Close Program L i s t i n g Report PLC-5/15 Addr 0 Rung 6:0 Rung 6:0 I ERROR ERROR_CON I I B3 • B3 I + - - ] [ : _ + ___ ( u ) _ _ _ + _ + I 150 I 112 | | I I CF_8I | I 'I B3 I | | . + (U)-+ | I , " I 1191 I I I I I I + [EOT]+ | Rung 6:1 I I + [END OF FILE] - r + Fi le 6: Transition Condition: Error - True Program L i s t i n g Report Rung 7:0 I CF_2 B3 -] / [ — 23 PLC-5/15 Rung 7:0 InPosCon Rung 7:1 I IN_POS_CON LSI I B3 1:000 + ] [ ] [ I 16 01 Rung 7:2 I IN_POS_CON I B3 + - + - — ] / [ + -I I 16 I I I LSI IN_POS_CONI I 11:000 B3 I I +-] / [ ] [ + I 01 16 Rung 7:3 +JSR + I -+JUMP TO SUBROUTINE ' +-+ I Prog f i l e number 31 I I I Input par I I -1 Return par B3 :1 I |. CONVEYOR O:001 — (U) 00 [END O F ' F I L E ] Fi le 7: Stop Conveyor; 0.2.1 ERROR I B3 I — ( D - - + 150 I Program L i s t i n g Report Rung 8:0 I IN_POS_CON LSI I B3 1:000. + ] [ ] •[ I 16 01 Rung 8:1 I IN_POS_CON PLC-5/15 Addr 0 Fi le 8: Clamp Wood; 0.2.2 (Continued) Rung 8:0 CL1 I O:001 I - - ( D — + 01 I ERROR | Appendix D Executable Programs of the Drill Machine 187 I B3 B3 + - + — ] / [ + ( L ) - -I 16 I 150 |IN_POS_CON LSI | I B3 1:0001 + ---] [ ] / [ - + 16 01 • Rung 8:2 I [END OF FILE] File 8: Clamp Wood; 0.2.2 Program L i s t i n g Report Rung 9:0 I IN_POS_CON LSI I B3 1:000 + ] [ 1 [------I 16 01 Rung 9:1 I IN_POS_CON I B3 + - + - — ] / [ -PLC-5/15 Addr 0 16 IIN_POS_CON I I I +• B3 -] [--16 Rung 9:2 I I LSI | 1:0001 - ] / [ - + 01 Rung 9:0 I D_S_F O:001 I - - ( L ) — + 02 I ERROR I B3 I - - ( L J - - + 150 I I I I • [END OF FILE] + File 9: Station Forward; 0.2.3 NO RUNGS IN FILE 10 File 10: Dummy Transition NO RUNGS IN FILE 11 File 11: Dummy Step Program L i s t i n g Report PLC-5/15 Addr 0 .'Rung 12:0 Rung 12:0 I LS4 DRILLING_C I I 1:000 . ' • B3 I + __] [ _ + - - - ( U ) + - + I 04 | 48 | | I I C F _ 2 | | I I B3 I I | + ( u ) . + | I I 23 1 I I . I CF_3 I I I I B3 I I | + ( U ) _ + | I I 3 9 | | I , . I I I I + [EOT]+ | Rung 12:1 I I + [END OF FILE] + File 12: Transition Condition: LS4 = Close Program L i s t i n g Report Rung 13:0 I LS3 I 1:000 + „ ] [ I 03 Rung 13:1 I PLC-5/15 Addr 0 Rung 13:0 I • [EOT] --[END OF F I L E ] -File 13: Transition Condition: LS3 = Close Appendix D Executable Programs of the Drill Machine 188 Program L i s t i n g Report PLC-5/15 Addr 0 Rung 14:0 Rung 14:0 I ' I I D r i l l i n g C I I CF_4 I I B3 +JSR + I + - - ] / [ : +JUMP TO SUBROUTINE +- + I 55 I Prog f i l e number 331 I I I Input par 1 I I I I Return par B3:3I I I + + i' Rung 14:1 I DRILLING_C LS4 D_S_F I I B3 1:000 O:001 I + ] [ ] [ + (U1- + - + I 48 04 I 02 I I I l+RTO + | | I ' , ++RETENTIVE TIMER ON+-(EN)+-I I I Timer TIMER I I I I Time base 1.0+-(DN) I I I Preset 2 1 I I lAccum 0| I I + _ _ + I Rung 14:2 I DRILLING_C ERROR I I B3 B3 I + - + - — ] / [ + ( L ) - - + I I 48 I 150 I I |DRILLING_C LS4 I I I I B3 1:0001 I | +___] [ ]/[_+ | I 48 04 . • • I Rung 14:3 I ' I + [END OF FILE] + File 14: Drilling; 0.3 Program L i s t i n g Report Rung 15:0 I TIMER.DN PLC-5/15 I T4 :0 -] [--DN Rung 15:1 I Rung 15:0 BACKUP_CON ' | B3 I - + — ( U ) + - + I 64 | | I CF_4 I • B3 I + (U)- + I 55 1 I I • [ E O T ] ! | - [END OF F I L E ] -File 15: Transition Condition: T(TIMER) = 2 s Program L i s t i n g Report Rung 16:0 CF_5 B3 - ] / [ - -71 PLC-5/15 I I Rung 16:1 I BACKUP_CON I B3 +CMP + ] [ +COMPARE I 64 [Express ion I ITIMER.ACC = 2 | + j . . . I I Rung 16:2 I BACKUP_CON I B3 +-+---]/[ I I 64 BackupCon Rung 16:0 I I I + I +JSR . -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 34 I I I Input par I I I Return par B3:4 I I + -File 16: Station Backup; 0.4.1 (Continued) i D_S_B I O:001 | -+-(L)-+-+ I 04 | | I TIMER | | . I T4 : 0 | | + (RES) + I ERROR | B3 | — ( D — + 150 | Appendix D Executable Programs of the Drill Machine 189 |BACKUP_CON TIMER.EN I I B3 +CMP . - - + T4:0 ! + ] [ + COMPARE + ] [ + 64 I Expres s ion I EN •I TIMER. ACC <> 2 I Rung 16:3 [END OF FILE] File 16: Station Backup; 0.4.1 Program L i s t i n g Report Rung 17:0 I LS3 I 1:000 + - - ] / [ I 03 I I I I I I I Rung 17:1 I PLC-5/15 Addr 0 Rung 17:0 STOP_MOT_C I B3 I - + - - - ( U ) +- + I 80 | | I CF_5I I I B3 | | + (U) 71 | I I I I + [EOT]+ | • [END OF F I L E ] -File 17: Transition Condition; LS3 = Open Program L i s t i n g Report Rung 18:0 I I CF_6 I B3 + - - ] / [ — I 87 I PLC-5/15 .Addr 0 Rung 18:0 I Rung 18:1 I STOP_MOT_C LS3 I B3 1:000 + ] [ ] / [ I 80 03 Rung 18:2 I STOP_MOT_C I B3 + - + — ] / [ + -I I 80 I I |STOP_MOT_C LS3 I I | B3 1:0001 | +. . . ] [ [_ + I 80 03 Rung 18:3 StopMotorC I I +JSR + | -+JUMP TO SUBROUTINE +-+ ]Prog f i l e number 35 1 ! I Input par I I I Return par B3:5 I I D_M I 0:001 I —(U)--+ 03 I ERROR I B3 I — ( L ) - - + 150 I - [END OF F I L E ] -File 18: Stop Drill Motor; 0.4.2 .Program L i s t i n g Report Rung 19:0 I LS2 1 1:000 + - - ] / [ I 02 ' Rung 19:1 PLC-5/15 Addr 0 Rung 19:0 HOME_CON | B3 I + — ( U J - - - + - + I 96 I C F _ 6 | I B3 | 4- (U)- + I 87 | I I il I I • [EOT] + -[END OF F I L E ] -File 19: Transition Condition: LS2 = Open Appendix D Executable Programs of the Drill Machine 190 Program L i s t i n g Report Rung 20:0 I I I CP_7 I B3 + - - ] / [ I 103 PLC-5/15 Addr 0 Rung 20:0 HomeCon I I Rung 20:1 I HOME_CON LS2 I B3 1:000 + - - - ] [ ] / [ — I 96 02 I Rung 20:2 I HOME_CON I B3 + - + - - ] / [ + I I 96 I IHOME_CON LS2 I I B3 1:0001 + - - J [ ] [- + 96 • 02 +JSR + | -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 36 I ] I Input par I I I Return par B3:6 I I D_S_B I O:001 . I - + (U)- + - + I 04 I I I CL1 | | I 0:0011 I + (U)-+ | I 01 | I I CONVEYOR I I I O:001 I I + — ( L ) — + I 00 I I I I Rung 20:3 I •- [END OF FILE] Fi le 20: Home; 0.5 i ERROR | B3 I - - ( L ) — + 150 | I I • Program L i s t i n g Report Rung 21:0 I LS5 I 1:000 + __] [ I 05 I I PLC-5/15 Addr 0 Rung 21:1 - [END OF F I L E ] -Rung 21:0 INIT_CONl | B3 I - + — ( U ) — + - + I 0 IINIT_CON2 I B3 - ( U ) — -1 ' CF_7 B3 — (U)-103 - - [EOT]+ Fi le 21: Transition Condition: L S 5 = Close Program L i s t i n g Report Rung 22:0 I I CF_3 I B3 + - - ] / [ I 39 I I I Rung 22:1 I MOTOR_CON LS3 I B3 1:000 + ] [ 1 [--I 32 03 Rung 22:2 I MOTOR_CON I B3 +-+---]/[ PLC-5/15 Addr 0 MotorCon Rung 22:0 I I I + I +JSR -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 32 I I I Input par I j I Return par B3:2 I I I D_M | 0:001 | — (D—+ 03 | ERROR | B3 | File 22: D r i l l Motor; 0.2.4 (Continued) . . . Appendix D Executable Programs of the Drill Machine 191 I I 32 I ' 150 I IMOTOR_CON LS3 I I I B3 '1:0001 | +.__] [_ ] / t _ + I 32 03 Rung 22:3 + [END OF FILE] File 22: Drill Motor; 0.2.4 FILE 23 IS NOT TYPE LADDER File 23: Not Used FILE 24 IS NOT TYPE LADDER ' File 24: Not Used Program L i s t i n g Report Rung 25:0 CF_8 B3 -] / [ — 119 PLC-5/15 Addr 0 Rung 25:0 Rung 25:1 ERROR_CON ERROR B3 B3 — - ] / [ ] [ — 112 150 E r r o r C o n +JSR + -+JUMP TO SUBROUTINE +-I Prog f i l e number 37[ ]Input par i I Return par B3:7I CONVEYOR O:001 - - ( U ) — + -00 I C L l I O:001| (U)- + 01 ! D_S_FI O:001I (U)-+ 02 I D_S_BI O:001I (U)- + 04 I D_M I O:001 | - (U)-+ 03 I TIMER I T4 :0 I (RES) + I I + I I I I I I CF_1 I B3 I - < U ) - + 71 CF_2 I B3 I - -(U)-+ 23 I CF_3 I B3 I - - (U)-+ 391 CF_4 I B3 I - - ( U ) - + 55 1 CF_5 I B3 I - - ( U ) - + 71 I CF_6 | B3 | --{U)-+ 87 | CF_7 | B3 | - - (U)-+ 103 I File 25: Shut Down; 1.1 (Continued) Appendix D Executable Programs of the Drill Machine 192 i i Rung 25:2 I ERROR_CON I B3 + ] [ •I 112 Rung 25:3 I ERROR I' B3 + - - ] / [ I 150 Rung 25:4 [END OF FILE] Fi le 25: Shut Down; 1.1 CF_8 | I B3 | | - (U)-+ I 119 I ERROR | B3 | (U)--+ 150 I EM_LIGHT I 0:001 I — (U) + 07 | Program L i s t i n g Report Rung 26:0 I ERROR I B3 + - - ] • / [ I 150 PLC-5/15 Addr 0 Rung 26:0 I I Rung 26:1 I ERROR_CON B3 - + — < U ) - — I 112 I CF_8 I B3 + (u)-I 119 IINIT_CONl I B3 + — < U ) — -I 0 I1NIT_C0N2 I B3 '+-—<U)---I 1 I + -I -[EOT]+ | I I - [END OP PILE] ' + Fi le 26: Transition Condition: Error = False Program L i s t i n g Report Rung 27:0 CF_8 B3 - ] / [ - -119 PLC-5/15 E r r o r C o n Rung 27:0 I Rung 27:1 I ERROR_CON ERROR I B3 B3 + ] / [ '] [ - -I 112 150 Rung 27:2 I ERROR_CON I B3 + ] [ I 112 Rung 27:3 I ERROR I B3 . + - - ] / [ I 150 Rung 27:4 I +JSR + I -+JUMP TO SUBROUTINE +-+ I Prog f i l e number 37 1 I I Input par j I I Return par B3:7 I I EM_LIGHT I O:001 | - — ( L ) + 07 I - [END OF F I L E ] -ERROR | B3 | - - ( U ) - - + 150 | EM_LIGHT | O-.001 I _ _ _ ( U ) + 07 | I Fi le 27: Emergency Light; 1.2 FILE 28 IS NOT TYPE LADDER File 28: Not Used Appendix D Executable Programs of the Drill Machine " 193 Program L i s t i n g Report PLC-5/15 Addr 0 • Rung 29:0 Rung 29:0 . I LSI LS2 LS3 LS4 CONVEYOR C L l D_S_F D_M D_S_B TIMER.EN ERROR I 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001' T4:0 B3 > + — ] / [ — ] / [ - — ] / [ — - ] / [ ] ••[ — - - - ] / [ - - - ] /I---]./[ — ]/[ ]/[ " ] / [ > I 01 02 03 04 00 01 02 03 ' 04 EN 150 > INIT_CON2 | - ' < B3 I < — (L) + < r i • • • . • • Rung 29:1 , I ' CF_1 I I B3 I + _ _ ( D - - + I ' • • 7 | Rung 29:2 I • .. ' ' +RET + I + + RETURN () +- + I I Return par B3:01 I I • . . + + | Rung 29:3 I • ' I + : [END OF FILE] + File 29: InitCon 2 Program L i s t i n g Report PLC-5/15 Addr 0 ' ' • Rung 30:0' Rung 30:0 I LSI LS2 LS3 LS4 " CONVEYOR C L l D_S_F D_M D_S_B TIMER.EN ERROR I 1:000 1:000 1:000 Ir.OOO O:001 O:001 O:001 O:001 O:001 T4 :0 ' ' B3 > + — ]/[ — ]/[ —]/[ — -]/[ — --] /[ ]/[ — -]/[ — ]/[- — ]/[ ]/[ ]/f > I 01 02 03 04 00 01 02 . 03 04 . . EN 150 ' > INIT_CONl I < B3 | < - - - (L) + < 0 I ' . ' • Rung 30:1 I • • CF_1 I I • ' B3 I + _ ( L ) - - + I ' 7 | Rung 30:2 I : • +RET +" I + + RETURN ()' +- + I I Return par B3:01 I |. • + _+ | Rung 30:3 I I + _ [END OF FILE] ^ + File 30: InitCon 1 Program L i s t i n g Report PLC-5/15 Addr 0 Rung 31:0 Rung 31:0 I AUTO LS2 LS3 LS4 LS5 CONVEYOR D_S_F D_M D_S_B TIMER.EN ERROR I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 O:001 0:001 T4:0 . B3 > + - - ] t - — ] / [ — - ] / [ — - ] / [ — ] / [ • ] [ ] / [ — ] / [ — ] / ' [ ] / [ ] / [ > I 00 02 03 04 05 00 02 03 04 EN 150 > IN_POS_CON I < B3 I <-— (L) + . • • • < 16 I Rung 31:1 I CF_2 'I I B3 I + ( L J - - + I 23 I Rung 31 :2 ' I ' • • ' +RET + I + • + RETURN {) +- + I I Return par . B3 :1 I -I | + ___ + | Rung 31:3 - [END OF FILE] File 31: InPosCon Appendix D Executable Programs of the Drill Machine 194 Program L i s t i n g Report PLC-5/15 Addr 0 Rung 32:0 Rung 32:0 I AUTO LSI LS2 LS4 LS5 CONVEYOR CL1 ' D_S_F D_S_B D_M TIMER. EN I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 O:001 0:001 O:001 T4 :0 > + - - ] [ — ] [---] [ - — ] / [ — - ! / [ ] / [ ] [---] [- — ] / [ — ] / [ ] / [ > I 00 01 02 04 05 00 01 02 04 03 EN > ERROR MOTOR_CON I < B3 B3 I < - ] / [ - - — - ( L ) . + < 150 32 I Rung 32:1 I CP_3 I I . B3 I + _ _ ( L ) _ _ + I • 39 I Rung 32:2 I • +RET + I + +RETURN () +- + I I Return par B3:2 I I I . . + + | Rung 32:3 • I " I + [END OF FILE] + Fi le 32: MotorCon Program L i s t i n g Report Rung 33:0 I AUTO LSI LS2 LS3 I 1:000 1:000 1:000 1:000 + --] [-""I .[ — ] I-—] [--I 00 01 02 03 ERROR DRILLING_C I < B3 B3 , I <-] / [ (L) + < 150 48 I Rung 33:1 PLC-5/15 Addr 0 Rung 33:0 LS5 CONVEYOR CL1 D_S_P D_M D_S_B TIMER.EN 1:000 O:001 O:001 0:001 O:001 O:001 T4 :0 - ] / [ ] / [ ] [---] [---] [" — ] / [ ] / [ 05 00 01 02 03 04 EN I Rung 33:2 I I Rung 33:3 + RET -+RETURN () •I Return par - [END OP F I L E ] -CF_4 I B3 i - ( L ) - - + 55 I I File 33: Dr i l l ingCon Program L i s t i n g Report PLC-5/15 Rung 34:0 I AUTO LSI LS2 LS3 LS4 LS5 I 1:000 1:000 1:000 1:000 1:000 1:000 + --] [- — ] [---] [ — ] [- —] [-I 00 01 02 03 04 Addr 0 Rung 34:0 TIMER.EN ERROR BACKUP_CON I < T4 :0 B3 B3 I -] [-- -- ] / [ < EN 150 Rung 34:1 I I + I Rung 34:2 I ( L ) - -64 CONVEYOR CL1 D_S_F D_M D_S_B O:001 O:001 0:001 O:001 0:001 > ] / [ — — ] / [ ) [- — ] / [ — ] [- — ]/[ > 05 00 01 02 03 04 > CF_5 B3 - ( L ) - -71 I Rung 34:3 + RET -+RETURN () I Return par + I + - + B3:4I | - [END OF F I L E ] -Fi le 34: BackupCon Appendix D Executable Programs of the Drill Machine 195 Program L i s t i n g Report Rung 35:0 I AUTO LSI LS2 LS4 LS5 I 1:000 1:000 1:000 1:000 1:000 + - - ] [ — ] [---] [ — ] / [ — ] / [ -I 00 01 02 04 05 PLC-5/15 Addr 0 Rung 35:0 CONVEYOR C L l D_S_P D_M D_S_B TIMER.EN O:001 O:001 O:001 O:001 O:001 T4 :0 — ] / [ ] [- — ] / [ — -] [ — ] [ ] / [ 00 01 02 03 04 EN ERROR STOP_MOT_C < B3 B3 <-] / ( (L) < 150 80 Rung 35:1 I I I Rung 35:2 I CF_6 | B3 I - ( L ) - - + 87 | I I Rung 35:3 I + RET + I -+RETURN () +-+ I Return par B3:5 I I + + | - [END OF F I L E ] -File 35: StopMotorCon PLC-5/15 Addr 0 Program L i s t i n g Report Rung 36:0 I AUTO LSI LS3 LS4 LS5 CONVEYOR C L l D_S_F D_M D_S_B TIMER. EN I 1:000 1:000 1:000 1:000 1:000 O:001 O:001 O:001 O:001 O:001 T4 : 0 + - - ] [ " — ] [ - - - ] / [ — ] / [ — - ] / ( ] / [ •] [ — ] / [ — - ] / [ — - ] t ] / [ - — j 00 01 03 04 05 00 01 02 03 04 EN ERROR HOME_CON I < B3 B3 I <-] / [ (L) + < 150 96 I Rung 36:1 Rung 36:0 Rung 36:2 I I Rung 36:3 I + [END OF FILE] -+ RET - +RETURN () I Return par CF_7 i B3 I - ( L ) - - + 103 I B3 : 6 I I + I File 36: HomeCon Program L i s t i n g Report Rung 37:0 I AUTO LSI LS2 LS3 LS4 LS5 I 1:000 1:000 1:000 1:000 1:000 1:000 + - - ] / [ — ] / [ - — ] / [ - - ] / [ — 3 / t — l / [ -I 00 01 02 03 04 05 TIMER.EN ERROR_CON I < T4 :0 B3 I <-- ] / [ (L) + < EN 112 | Rung 37:1 I I PLC-5/15 Addr 0 Rung 37:0 CONVEYOR C L l D_S_F D_S_B D_M O:001 O:001 O:001 O:001 O:001 > — ] / [ ] / [ - - - ] / [ - - - ] / [ - — ]/'[ > 00 01 02 04 03 > I Rung 37:2 I +RET - + RETURN () . I Return pax-Rung 37:3 I CF_8 I B3 I - ( L ) - - + 119 I + I + - + B3:7 | I I - [END OF FILE] + File 37: ErrorCon 1 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0064918/manifest

Comment

Related Items