英文翻译内容.doc

重构控制的机器人制造单元外文文献翻译、中英文翻译

收藏

压缩包内文档预览:(预览前20页/共23页)
预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图 预览图
编号:91868992    类型:共享资源    大小:2.02MB    格式:ZIP    上传时间:2020-08-10 上传人:QQ14****9609 IP属地:陕西
12
积分
关 键 词:
控制 机器人 制造 单元 外文 文献 翻译 中英文
资源描述:
重构控制的机器人制造单元外文文献翻译、中英文翻译,控制,机器人,制造,单元,外文,文献,翻译,中英文
内容简介:
Robotics and Computer-Integrated Manufacturing 23 (2007) 94106Reconfigurable control of robotized manufacturing cellsManfredi Bruccoleri?aDepartment of Manufacturing, Production and Management Engineering, Universita di Palermo, Viale delle Scienze, 90128, Palermo, ItalyReceived 11 December 2003; received in revised form 19 July 2005; accepted 6 August 2005AbstractThis paper investigates the field of manufacturing system control. The addressed subject is indeed very fascinating, due to theimportance that it has reached in the last decades both at research and industrial level. On the other hand, it seems to the author thatmost of the complexity intrinsic to the subject itself relies on the different meanings or levels of abstraction that both the termsmanufacturing system and control may symbolize. The presented research aims to face the topic in a concrete fashion, i.e., bydeveloping a control software system for a specific, although easy to be generalized, robotized manufacturing cell. Two differentdevelopment methodologies, from the conceptual design to the actual implementation, of a cell control system are presented andcompared. The former, based on ladder logic diagrams, for a PLC controlled manufacturing cell; the latter, based on object-orientedmodeling and programming techniques, for a PC controlled manufacturing cell. The analysis has been conducted considering the internaland external requirements of the manufacturing system, mostly driven by the contemporary industrial need of reconfigurable controlsystems, largely acknowledged as the critical key to succeed in the new era of mass customization.r 2005 Elsevier Ltd. All rights reserved.Keywords: Object-oriented modeling; Reconfigurable control; Interlocking logic; PLC-based control; PC-based control1. IntroductionMonitoring and controlling computer integrated manu-facturing (CIM) systems is a complex but crucial task.Modern computerized manufacturing systems have laggedfar behind what could be achieved with existing technol-ogy. The cost of such systems is often too high and itshould be justified by a return on investment, which can begained only if the required system flexibility is assured.Although flexibility is mainly gained by the utilization ofshop floor control software modules for planning, schedul-ing,dispatching,coordination,anddatamonitoring-analysis activities, from a low-level control perspectivethe utilization of programmable devices that controlmachines, robots, and material handling systems is alsorequired. At this level, the control system has to performmainly low-level coordination activities (task planningactivities) such as synchronization of shop-floor deviceslikeactuatorsandsensors.Consideringarobotizedmanufacturing cell, the control issues concern the coordi-nation of the cell hardware components in order to achievea given task plan. In most cases, the planner is a sequencecontroller that controls I/O variables by using simplealgorithms or programs. These sequence and synchroniza-tion controllers are usually programmed in the PLClanguage or in a common general purpose programminglanguage (if the task plan is run by a PC). Ladder diagrams(LD) are the most utilized modeling and programminglanguage for PLC-based controller. They are very easy-to-use and relatively familiar to the shop floor personnel.Also, Petri nets (PN), state-charts, and finite state machinediagrams have been extensively applied for preliminaryphasesofthecontrolsystemdevelopmentsuchasspecification, design, verification, and performance evalua-tion of discrete event control systems, despite they employa process-based model, which does not fully correspond tothe control programming behavior 1,2. As far as the mainrequirement is to develop reconfigurable cell-level controlsoftware that is reconfigurable in its basic components,object oriented (OO) modeling techniques are widelyproposed in the scientific literature for the conceptualARTICLE IN PRESS/locate/rcim0736-5845/$-see front matter r 2005 Elsevier Ltd. All rights reserved.doi:10.1016/j.rcim.2005.08.005?Tel.: +390916657036; fax: +390916657039.E-mail address: manbrudtpm.unipa.it.modeling phase of the control software developmentbecause of their well recognized features related to softwaremodularity, rapid prototyping, and re-use. Two mainconcerns arise yet.?The first is related to the significant gap which existsbetween the object oriented conceptual model or designof the control software and its actual implementation.While general purpose programming languages, for PC-based control software, encapsulating object orientedfeature are surely available (e.g. C+), concerning aPLCbasedcontrolsystem,ladderdiagrams,forinstance, do not include object oriented features.?The second concern regards the unconditional need of asimulation environment where to test the effectiveoperation of the new or the reconfigured controlsoftware. Indeed, an incorrect synchronization betweentwo cell components (a robot arm and a machine toolworking table) could damage the cell unrecoverably.Thus, a simulation environment where to test themodeled and programmed control software is strictlyrequired to avoid such unwanted effects.The aim of the research presented in this paper is mainlyfocused on proposing an integrated methodology whichadopts an object-oriented approach for modeling, design-ing, simulating and, finally programming the controlsoftware of a robotized manufacturing cell in bothPLC and PC-based embedded control systems. Specificattention has been given to the two concerns abovementioned.The author proposes the unified modeling language(UML) as tool for the design and modeling of the controlsystem itself, while LD and C+ for its implementation,respectively, in PLC and PC-based embedded controlsystems. Also, it is shown how the use of UML and itsactivity diagrams makes easier the trade off between thedesign and the programming phases both in a PLC and PCenvironments. Furthermore, the paper shows the develop-ment of a discrete event simulation platform for testingreconfigurable control software.The paper is structured as follows: Section 2 gives anoverview of discrete control of robotized manufacturingcells, focusing specifically on the most used design andimplementation tools. Section 3 presents the problemstatementwhiletheproposedcontrolsystemdesignmethodology is illustrated in Section 4. Section 5 presentsthe development and implementation methodologies forboth the PLC-oriented LD-based control system and thePC-oriented C+ based control system. Conclusions andfurther remarks are drawn in the last section.2. Discrete control of robotized manufacturing cellThe term manufacturing cell, also referred to asgroup technology cell, usually connotes a collection ofmanufacturing, material handling, control, and auxiliaryequipments that are needed to manufacture a specific parttype or, more generally, a part family. A robotizedmanufacturing cell is usually a typical manufacturingsystem of this type and, depending on the manufacturinggoal, on the required flexibility, automation, and produc-tivity, it can consist of different numbers and differentkinds of manufacturing equipments (machining stations),auxiliary fixtures, material handling systems (robots andtransportation systems), and control systems (relays, PLCs,PCs, etc.). In particular, the cell control system architecturemainly depends on the structure and configuration ofthe cell itself. As an example, if the manufacturing cellconsists of many and different kinds of equipments, itscontrol system probably needs to include several hardwaredevises like PLCs or PCs. Also, depending on thefunctionality requirements of the cell governance policy,the control software could consist of various kinds ofmodules. For instance, if the only requirement is thesynchronization of actuators and sensors for running agiven task plan, then a simple program can be loaded intothe PLC, which controls both the input signals origina-ting from the cell sensors and the output signals whichtrigger the cell actuators. On the other hand, if the controlsystem is required to automatically download the NCpart processing program from a database according totheinformationoriginatedbyanautomaticvisionsystem which detects the part type entering the system, orsome error recovery functionality is required, then it isobvious that the control system needs to include differenthardware devices and different software modules. Usually,the control system software architecture complexity isrelated to its hardware configuration even if this is notalways true.Given such considerations, the scientific literature doesnot lack of studies and proposals of assorted controlarchitectures (both hardware and software) whose chal-lenge relies on the proposal of generic control systems forgeneric manufacturing cells. Essentially, two main classesof approaches proposed for cell control system develop-ment can be recognized into literature.?The former deals with the problem of modeling andanalysis of the control system software and hardwarearchitectures. Usually, starting from a requirementanalysis, authors propose control system architecturesbased on modeling tools and standards. Object orientedtechniques 3,4, IDEF methods, pattern languages 5,and Petri nets 6 are doubtless the most utilizedmodelingstandardsforcentralizedcontrolsystemarchitectures, while multi agent systems 7 and IECstandards, like IEC614999 8, are widely used fordecentralized control architectures.?The latter class of approaches to manufacturing cellcontrol development concerns its low level program-ming. Even in this case, the programming approachesare numerous and mainly depend on the control systemhardware configuration as illustrated in what follows.ARTICLE IN PRESSM. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 94106952.1. PLC-based embedded control systemsAveryconventionalwaytocontrolarobotizedmanufacturing cell is by a PLC device, which interactswith every other element by exchanging electrical signals.As an example, it can trigger or stop discrete eventsequences on a machine tool according to the ladder logic itis executing. In other words, the PLC not only controlsbasic actuators but also the synchronization of productionprocessesamongmanymanufacturingandauxiliaryelements, which can also be programmable. The mostcommon programming language for PLC is ladder logic.Ladder logic differs from the most common general-purpose languages such as C+ or Visual Basic, being adevice-oriented programming language. In its essentialform, the ladder logic is a graphical representation ofBoolean switching functions based on an analogy tophysical relay systems.As far as PLC-based embedded control systems areconcerned, the topic of the limited and inflexible capabilityof their programming languages is largely treated inliterature. Following these directions authors propose Petrinet models 1,9, object oriented models 10, state-chartdiagrams 11,12 that, afterward, need to be, automaticallyor manually, converted in ladder logic. This pre-program-ming phase is needed in order to have a higher level modelof the control program, which is easier to understand andeasier to design, due to its process oriented nature whichreproduces the discrete event functioning of the manufac-turing cell. Lee et al. 13 by using object oriented modelsand state charts developed a virtual prototyping environ-ment to reduce the risks involved in PLC-based controlprograms, such as deadlock problems. Also, expert systemsmodules 14 and layered Petri nets 15 are used whenadditional features are required to the control program ofthe cell task plan, such as error handling capabilities.2.2. PC-based embedded control systemsOn the other hand, in the very recent years researchersare facing the problem of cell control programming directlybypassing the limited capabilities of the PLC with a PC-based control approach. PC-based control environmentsbring indisputable advantages respect to PLC-environ-ments especially concerning their networking predisposi-tion, real-time monitoring and visualization capabilities,and flexibility related to the great number of programminglanguages that could implement the real control software.However, in these environments the main problem is todeal with the software and hardware incompatibilityarising from various vendors. The Open Modular Archi-tecture Controller (OMAC), instigated by GM and Ford,the Open Systems Environment for Control (OSEC),developed within the machine tool Industry, and the OpenSystem Architecture for Controls in Automation systems(OSACA), developed within the ESPRIT III Europeanproject, are signals of strong interest in these fields.Following these directions, Apte and Zeid propose aJava-based control model by using PC standard parallelports for asynchronous I/O such as IEEE 1284-A, orperipheral driver integrated circuits, such as Intels 8255-A,which allows the design of a multiplexed I/O bus 16.Hong et al., propose a UML modeling tool, C+programming language, and TCP/IP communication pro-tocol for PC-programming of a robot within a robotizedcell according to the OSACA reference platform 17.Martinez and Garcia developed a visual tool based onsequential function charts, called SFC+, to bridge thegap between object-oriented model and implementationprogramming for a PC-based distributed industrial controlsystem 2.3. Problem statementIn order to approach the development of a cell controlsystem, given a desired level of abstraction from theconceptual design, to the modeling, simulation, testing,until its real implementation, four main requirements needto be well defined. This is what here is called problemstatement.The first requirement concerns the identification ofthe boundaries of the problem, i.e., the specification ofthe manufacturing system to be controlled, in this case thespecific robotized cell.The second requirement is related to the functionalrequisites that the control system should provide, such assimple task plan running, or monitoring, or error handling,or supervising, or scheduling, or part quality visioning, or,also, all of these.The third main requirement concerns the specification ofthe basic properties that the control system should have.This last requirement depends, of course, on the secondrequirement and involves decisions on the system hardwareconfiguration, such as centralized/distributed or hierarch-ical/heterarchical architecture, and on its software features,such as device/process/object orientation or synchronous/asynchronous procedural implementation.The fourth main requirement regards the possibility totest the control system before its real implementation.Indeed, depending on the first two requirements, it couldbe strictly necessary to test the correct functioning of thecontrol software in order to avoid critical damages in themanufacturing system.Not specifying these requirements before developing acontrol system could lead to the formulation of one of themany generic methodologies which the scientific literaturedoes not certainly lack of. Thus, in what follows, theserequirements are specified and described. In such a way,the proposed approach for reconfigurable control softwaredevelopment could reveal more practical and useful foractual circumstances. Also, such specific requirements canbe easily generalized besides being quite typical in the shopfloor reality.ARTICLE IN PRESSM. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 94106963.1. The system to be controlledThe manufacturing system test-bed considered in thispaper is a robotized cell, which consists of the followingcomponents:?parts to be processed,?machines to perform processing,?input and output stations,?material handling devices and transporters for transfer-ring parts into and out of the robotized cell,?one control device, such as PLC or PC, to perform thecontrol activities,In particular the considered manufacturing cell, picturedin Fig. 1, is a STAUDINGER physical toy model, which isinstalled at the Department of Manufacturing, Production,andManagementEngineeringoftheUniversityofPalermo. The toy mainly consists of three machines, threeconveyors (one for each machine), one 3 axis-portal robot,one input station and one output station, and a number ofelectricalandmechanicalsensorsandactuators.Inparticular, the three machines are configured in a linelayout and the first is a vertical milling machine (VMM),the second is a multi-spindle milling machine (MSMM),and the third is a horizontal milling machine (HMM).Basically, a mechanical pusher pushes the work-pieceplaced into the input station to the processing line, as soonas it receives a start signal from the control system. Threesensors detect the piece position in front of the threeprocessing machines and depending on the piece work-planthe conveyor stops its run exactly when the piece is in frontof the right machine where it needs to be processed.A number of sensors and actuators are associated to everymachine. For instance the multi-spindle milling machineincludes three actuators. The first rotates the tool changerin order to set the requested mill up. The second rotates theworking axis in order to execute the real processingoperation. The third moves the mill up and down in orderto position the mill in contact with the piece to beprocessed. In the same way, such a machine includes anumber of sensors necessary to make the process correctlywork. Two sensors detect the vertical position of the milland one sensor detects the correct direction of the spindleafter the tool changer has rotated.When the work-piece finishes to be processed by the lastmachine, it is sent to the output station. Because of themono-directional run of the conveyors, if a work-pieceneeds to visit two processing machines in a different orderthen that of the layout configuration, the 3-axis portalrobot grips the part in the output station and re-loads it inthe input station for a second run. Let us assume that awork-piece should visit first the third machine (i.e., HMM)and then the first one (i.e., VMM). In this case, after havingbeen processed by the HMM, the piece must go to theoutput station and wait for the robot to load and transfer itagain to the input station. In this second run the conveyorwill stop the piece in front of the VMM where it will beprocessed.3.2. Control functional requirementsThe aim of the control system, in this case, is simply torun procedural programs for ordinary task plan executionsof a couple of part types of the same group technologyfamily. No integration with other supervising controlsystem, no error handling, no data collection functionsarerequired.Theabstractionleveloftherequiredautomation is very low, as far as the operation of eachcell component is driven by a number of actuators while anumber of sensors identify its status. Both actuators andsensors exchange digital signals (ON/OFF) with thecontrol system by means of electromechanical relays. Onlythe robot exchanges with the control system analogicalsignals by means of an analogical encoder needed inorder to correctly define the 3D robot positioning. Thecoordination of every component for executing the taskplan is driven by an asynchronous control mechanism,i.e. an interlocking based control. An interlock is amechanism for coordinating the activities of two or moredevices in order to ensure that the actions of one device arecompleted before the next device begins its activities.Interlock-based control, in contrast with time-based con-trol, works by regulating the flow of control signals backand forth between the controller and the controlleddevices.For these purposes, two different approaches has beendeveloped and compared. The former is oriented to a PLC-based control, the latter to a PC-based control. In otherwords, the abstraction level of the required control system,coincides with a stand-alone PLC/PC-based control systemfor the above mentioned robotized cell toy.ARTICLE IN PRESSFig. 1. The robotized manufacturing cell test-bed.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 94106973.3. Control properties: reconfigurable controlDespite the sequence co-ordination capability is theprimary required control property, the control systemshould also be reconfigurable. Indeed, using hardware andsoftware rigid configurations could be an easy solution toperform a specific manufacturing application. However,theredefinitionofsuchapplicationswhichincludesremoving/adding one or more hardware subsystem (suchas processing machines) or software subsystem (such aserror handling modules) would involve significant efforts inreengineering the system. The control system, even if itperforms very low-level control activities such as equip-ments coordination, must be able to re-define the presenceof the hardware devices it controls and the governancefunctions it performs in an easy way by being hierarchicallystructured and modularly designed. OO technologies arethe paradigm mainly proposed and used for softwaredevelopment in general but also in the specific field ofmanufacturing system control applications. The character-istics of such a paradigm are perfectly suited for softwareapplicationsthatrequirereusability,scalability,andreconfigurability of the software components.However, it is a matter of fact that OO methodologiesare widely used during the phase of modeling the controlsystem architecture but quite rarely adopted when it comesto the control software implementation. Indeed, as far as acomplex control system is concerned, such as a largecontrol system for a CIM system, then the OO approachallows the definition of its hierarchical architecture and therelationships among its many software modules (such asdependencies, aggregations, and so on) 18. On the otherhand, concerning the low-level control software implemen-tation it is easy to comprehend that as far as mostmanufacturing equipments are controlled by PLC devicesand PLC can be programmed with specific programminglanguages (such as ladder logic or sequential function chartor instruction list) OO programming is not practical andeasy to implement. That is the reason why in this paper twodifferent control systems are proposed for the governanceof the robotized cell. Besides the PLC-based one, whichcannot include an object-oriented programming phase, thePC-based control system has been developed in OO fashionfrom the modeling to the real implementation performedby C+ program that is, of course, PC compatible.Nevertheless, concerning the PLC environment, the paperproposes a methodology for easily translating the OOsoftware design into the LD program.3.4. Testing the control systemAs already mentioned in the introduction of this paper,duringthecontrolsystemdevelopmentthereisanunconditional need of a simulation environment where totest the effective operation of the new or the reconfiguredcontrol software. This is even more important for low-levelcontrol systems, such as task planners and sequencers, thanfor high level control modules that control part sequencingor resource allocation to jobs. It is not reasonable, indeed,to imagine testing a new task plan for a specific partprocessingsequencebydirectlyloadingthecontrolprogram in the PLC or the PC and running it into therobotized manufacturing cell. An incorrect synchroniza-tion between two cell components (a robot arm and amachine tool working table) could damage the cellunrecoverably. Thus, a simulation environment where totest the modeled and programmed control software isstrictly required to avoid such unwanted effects. Severalcommercial discrete event software platforms, even specificfor shop floor simulation such as Arenasby RockwellSoftware, Inc., and eM-Plantsby Tecnomatix, Inc., offerhigh level simulation languages and environment to modelmanufacturing systems operation and to test manufactur-ing control policies. Nevertheless, their simulation lan-guages or graphical notations are obviously different fromthose used for the real control and then, it is not easy tomodel without a given level of imprecision, the controlsoftware that has to be tested.On the contrary, the paper shows how, starting from theconceptual design of the control software, a simulationenvironment can be developed in order to test exactly thecontrol software that should be then programmed into thePLC or PC for the actual control of the robotized cell.4. Control system designInthissectiontheOOcontrolarchitectureofthe robotized cell is presented. While the modelingprinciple guidelines can be applied in a variety of scenarios,the actual design and development are driven by theARTICLE IN PRESSFig. 2. The real objects and their software classes machine andHMM.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 9410698requirements of specific control system, as described in theprevious section. Thus, the proposed architecture shouldthen be put into practice by developing the real controlsoftware as it is shown in the next section. For the softwaresystem design, the UML (standard OO modeling tool forsoftware development) has been used. The UML enclosesthe advantages of a high level modeling tool (such as PN)and the capability of easy translation from modeling toimplementation (such as LD or C+). Furthermore, dueto its object-oriented nature, modularity, reusability, andreconfigurability are assured in the software design phaseand in the real-time control phase 19. In the design phasethe property of inheritance and instantiation allow easyreuse of software objects. In the real-time control themodularity of the software allows to easy reconfigure thecontrol software itself in order to manage, at a low levelcontrol, hardware reconfigurations which are necessary togain a given level of reactiveness 20.According to the OO paradigm, in the UML notation, aclass of objects is characterized by a set of attributes, whosevalues represent its status, and a set of operations, whichrepresent the tasks the class is able to perform. Fig. 2 depictthe real objects machine and HMM and their relatedsoftware class. Notice that, as the HMM is a specific caseof the class machine, it inherits all of the attributes andoperations of the upper class machine. Thus the UMLrepresentation of the HMM class shows only its additionalattributes and operations plus the generalization/speciali-zation relationship between it and its upper class ma-chine. So, for instance, the HMM can go in front andgo at the back in addition to the standard machineoperations go to the top, go to the bottom, andprocess workpiece.After having modeled all of the classes participating thesystem, the next step is to build up the network of classesby representing their hierarchical dependencies and theirassociations. Such a network of classes and their relation-ships, called class diagram, embodies the system architec-ture. As far as the robotized cell test-bed is concerned, itscontrol architecture is represented in the class diagramreported in Fig. 3. In darker color the classes of objectsARTICLE IN PRESSVertical millingmachineMulti spindlemilling machineHorizontal millingmachineRobot3-axis portalMachineConveyorManufacturing cellProcessingStationOutputstationInput stationProcess lineFig. 3. The control system class diagram.PLC/PCInput StationConveyorV_M_MVMMConveyor M_S_M_MConveyorH_M_MHMMoutputstationRobotMSMMMove pusher to the right( )Move ( )Move ( )Move ( )Process workpiece( )Move the conveyor H_M_M to unload workpiece( )Move Pusher to the right( )Move the conveyor V_M_M to load workpiece( )Process workpiece( )Move the conveyor V_M_M to unload workpiece( )Move the conveyor M_S_M_M( )Move the conveyor H_M_M( )Robot go to the left( )Fig. 4. Sequence diagram for task planning execution.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 9410699which actively participate in whatever processing task plan,are reported.In such an environment, each object is responsible for aspecific set of tasks and when an object requires theexecution of a task, which is not within its responsibilities,it sends a request, in the form of a message, to anotherobject designed to accomplish that specific task.Consider the task plan for processing a work-piece whoseprocess plan requires the piece to be processed first in theHMM and then in the VMM, as described in the lastparagraph of Section 3.1. In Fig. 4, the flow of messages thatare necessary for such specific task plan execution is reportedin a UML sequence diagram. The diagram shows themessage exchange that is necessary to make the manufactur-ing cell automatically process that specific part type. Notethat every message sent corresponds to the execution of aspecific operation (i.e., C+ + method or LD action) of therecipient object. Although the sequence diagram showsclearly the sequences of operations needed for the processaccomplishment, the interlocking logic of the discrete controlsystem could not be implemented without the design of thecorrect synchronization of events, activities, and states thatcharacterize such a process. In other words, what still needsto be designed is the sequence of activities triggered bycertain events and changing objects states.Fig.5reportstheUMLactivitydiagram,whichrepresents the interlocking synchronization among theactivities (and states) performed by the input station, theconveyor VMM, and the VMM classes when a work-pieceenters the system and needs to be processed in theVMM itself. Note that every state corresponds to aspecificconfigurationoftheclassattributes,i.e.,aconfiguration of ON/OFFconditions of the sensorsbelonging to the physical object; on the other hand, everyactivity matches with a specific class operation, i.e., withthe activation of a specific actuator belonging again to thephysical object.A specific state of an object triggers the execution of aspecific activity whose fulfillment brings the object to a newstate, which will stop the execution of that activity andtrigger another one. Alternatively, a timer could stop theactivity itself as it happens for the activity depicted in darkcolor (see Fig. 4). In fact, the VMM keeps processing theworkpiece for a specified duration without involving anysensor for detecting its stop. Such an activity is time-basedand interlock-free.ARTICLE IN PRESSS1: WorkpiecepresentA1: Move pusher tothe rightS2: Workpiece outto the systemA2: Move pusherto the leftS3: Wait forworkpieceA1: Move to load theworkpiece in the machineS2: Workpiecein positionS1: Readyto moveA2: Move to unload theworkpiece from the machineA1: Setup thespindleS1: Readyto set upS2: Readyto processA2: Process theworkpieceA3: Go back to theready to setup positionVMMCONVEYOR VMMINPUT STATIONFig. 5. Activity diagram representing the interlocking logic.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 941061005. Control system implementationAs already mentioned in the previous sections, besidesthe manufacturing system itself, the main drivers of controlsoftware development are the control functional require-ments, its properties, and the control system hardwareconfiguration. Depending on this last factor, very differentcontrol software could be developed. Because of the verysimple function the control system must perform in theapplication presented here, a single PLC or PC can be usedfor controlling the manufacturing system. The PLC, or PC,isconnectedtoeverysensorandactuatorofthemanufacturing system (through electro-mechanical relays)and makes the task plan running by a sequence of signalON/OFF exchanged with these components. In whatfollows it is illustrated how the control software systemhas been implemented for both the hardware configura-tions.5.1. PLC-based control system implementationThe PLC is usually programmed with specific purposelanguages or notations. The PLC used in this application isa SIEMENS S7200 and its programming language Step 7 isbased on the classical ladder logic diagrams. The controllogic that governs the execution of a given task plan,should hence be translated from the UML activity diagraminto the Step 7 notation. Fig. 6 reports a partial view of theStep 7 program that has been written for executing the taskplan of Fig. 5 UML activity diagram.The design of the interlocking logic by using the UMLactivity diagram surely supports the PLC programmer inunderstanding and writing the LD code. Indeed, byassociating:?every object to hardware components (machines, robots,etc.),?every condition related to a specific state of that object(note that, on the UML side, a state corresponds to aspecific configuration of the object attributes) to theinput conditions connected to that real object (in the LDlogic, the input conditions, also referred to as contacts,represent ON/OFF devices such as switches or relays),and?every object activity (note that, in UML an activity isassociated with the execution of one specific or a groupof object operations) to the output actions (in LD logic,the output actions, also referred to as loads, representmotors, lamps, alarm, etc.),the shop-floor control operator can program the PLC, bysimply interpreting the UML activity diagram into theladder logic diagram.In particular, Fig. 5 shows that the activity A1 movepusher to the right is performed by the object inputstation only when the state S1 workpiece present of thisobject is activated. This is represented in the network 1 ofthe Step 7 program sketch (Fig. 6) where the contactS1_Input_Station represents the condition for the loadA1_Input_Station. Of course the contact S1_Input_ARTICLE IN PRESSNetwork 1condition for move pusher to the rightS1_Input_StationA1_Input_StationS1Network 2condition for pusher stop, pusher move to the right, and Conveyor move to load the workpiece in the machineS2_Input_StaionA1_Input_StationR1A2_Input_StationS1S1_Conveyor_VMA1_Conveyor_VMS1Network 3condition for pusher stopS3_Input_StaionA2_Input_StationR1Fig. 6. Partial view of the LD-based Step 7 program.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 94106101Station is physically connected with the sensor whichdetects the presence of the workpiece into the input station,and the load A1_Input_Station is physically connectedwith the electric motor of the pusher.Despite this simple procedure represents an easy way totranslate UML activity diagrams into LD (Step 7, in thiscase)programs,itcannot besaidthatduringthistranslation the object-oriented features of the controlsystem design keeps being in the implemented code. Thisis the authors opinion, the biggest drawback of such kindof control software implementation and, then, of the PLC-based control system hardware configuration. Neverthe-less, PLC-based embedded control systems still remain themost used solution for shop floor control, probablybecause LD are very familiar to shop personnel who mustconstruct, test, maintain, and repair the discrete controlsystem 21. This is why, it is very important to keep theresearch efforts exploring this field, although from manyaspects a PC-based solution could reveal to be much morepromising.5.2. PC-based control system implementationWhile the implementation of the control code within thePLC involves dealing with LD, when it comes to theimplementation of the control code within a PC (equippedwith I/O card and related hardware to provide thenecessary devices to connect to the manufacturing cellequipments), a general-purpose programming language canbe selected depending on the preferences (in this applica-tion C+ has been chosen). In the simple case in whichthe controlled variables, i.e., input conditions and outputactions, are digital (ON/OFF) variables, then the controlprogram should simply synchronize and interlock binaryvariables according to activity diagrams such as the one ofFig. 5. Also, the programming phase of the controlsoftware is largely simplified by using Rose C+ Analyzer(Rose Enterprise package by Rational), a software toolthat allows the designer to obtain software code generationfrom the UML model.The final control software consists of two C+ files, aheader file and a body file. The former includes the libraryof all the created classes, their attributes, operations, andrelationships. The latter contains all the classes instancesand the exchanged messages that implement the pro-grammed task plans. The C+ generator produces theappropriate C+ class for each class in the UML model.For standard and user-defined operation the generatorproduces skeletal member functions that must be filled upwith member function bodies. Fig. 7 shows the skeletoncode generated for the class machine.As far as the reconfigurable control requirement (Section3.3) is concerned, of course, a C+ implementation of thecontrol software surely maintains the OO features of itsUML design, making preferable a PC-based control systemrespecttoPLC-basedonefromthereconfigurationrequirement perspective. The property of inheritance andthe modularity of the control program (the actual code)allow easy re-definition of the hardware configuration ofthe cell (e.g. adding or removing workstations). Also, givena control procedure for running a specific task plan, letssuppose that a new part requiring a new task plan needs tobe processed into the robotized cell. In the control systemdesign, the new task plan will imply only the definition of anew activity diagram which uses classes attributes andoperations already defined. On the contrary, from theprogramming perspective, if the program is run in the PLCusing the LD language the entire program must be re-written, while if the program is written in C+ languageand is run by a PC only the C+ version of the activitydiagram must be re-written. All of the classes declarationsand definitions can be re-used.However, the real difference between the two presentedapproaches (PLC and PC-based) concerns the differentfunctional requirements that the two approaches are ableto accomplish. Indeed, besides the coordination of binaryvariables which make possible the simple task planningexecution, the PC-based implementationcould easilyinclude some other functional features typical of this kindof control system approach. In particular, they are the real-time visualization/monitoring capability, some exceptionhandling features, and the possibility to test the controlsystem by simulating it before real implementation.ARTICLE IN PRESSFig. 7. Skeleton code for the class machine.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 941061025.2.1. Real-time visualization/monitoring capabilitiesUsing the commercial Borland, Inc. tool C+ + Builders,a typical windows application has been developed startingfrom the control software design. Specifically, standardgraphical attributes and operations have been added to thesoftware classes of the control system and have beenassociated to their real control attributes and operations.In this way, every object state or operation also activatessome graphical visualization on the computer monitor.Fig. 8 shows the main window of the control system.The window visualizes, in a real-time fashion, the statusof all of the objects of the system and their activities duringthe execution of a given task plan. For instance, Fig. 9shows an instantaneous sketch of the vertical millingmachine (VMM) status and activities. In particular, theVMM status is represented by the values of its attributes(Machine at the top and Machine at the bottom) andthe VMM activities are represented by the operation whichis temporarily executing. In the specific instant when thesketch has been taken, its status was Machine at thebottom and the operation that it was performing wasMachine is working.5.2.2. Networking and exception handling capabilitiesAnother important functional requirement of the PC-based control system here presented is its ability to reactagainst unexpected events such as out of orders. It is wellknown that, in control system hardware and softwarehierarchical architectures, the exception handling phases,such as error detection, diagnosis, and recovery, are usuallyperformed by software modules of the high levels of thecontrol architecture. Also, generally, the error handlingstrategies are related to the possibility to change the partprocess routings in order to avoid block states due to theout-of-order manufacturing resource and its temporaryunavailability. Such strategies, which are put into opera-tion by control software modules usually called reactivescheduling systems, require the manufacturing system toallowacertainroutingflexibilityorreconfigurationflexibility 22. Once the reactive scheduling system findsARTICLE IN PRESSFig. 8. Main window of the control program.Fig. 9. Monitoring the vertical milling machine.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 94106103a temporary solution against the occurred out-of-order,then a new task plan should be implemented for executingthe new part process plan. Real time networking andcommunication with high level control modules and realtime loading of the new task plans proposed by the reactivescheduling system are the two exception handling concernsthat involve the low-level control modules responsible ofthe task plan execution as those considered in this paper.Of course, such functional requirements could not beperformed in a PLC-based control environment while canbe implemented in a PC based environment as in the onepresented in this paper. As an example, Fig. 10 shows amonitor warning due to the occurrence of an error duringVMM operation.The manufacturing cell will stop is run until the operatordo not check on the REPAIR VMM checkbox whichwill make the system recover his operation. Meanwhile, ifan error handling procedure is ordered by a high-levelcontrol module of the control system (such a change in thecurrent part process plan) then the low level control systemshould adapt to this new status by changing the currenttask plan. Fig. 11 depicts the control software form whichallows the operator selecting the new task plan by simplychecking the appropriate checkboxes.5.2.3. Control system testingGiven the requirements already mentioned in Section3.4, concerning the simulation/testing phase of the controlsystem development, a mixed interlock-based and time-based control program has been realized. In few words,given the interlock-based control software written in C+described so far, the input and output variables which wereconnected to the physical relays of the system has been nowconnected with software classes simulating the physicalsensors and motors and governed by C+ timer classeswhich implement the time advancement mechanism. In thisARTICLE IN PRESSFig. 11. The control software form create new sequence.Fig. 10. Error occurrence during VMM operation.M. Bruccoleri / Robotics and Computer-Integrated Manufacturing 23 (2007) 94106104way by running such a virtual control system, its correctoperation can be visualized and tested in the graphicalinterface already described.6. ConclusionsThis paper describes a study that has been conducted forthe development of a control system for a robotizedmanufacturing cell toy installed at the Department ofManufacturing, Production, and Management Engineeringat the University of Palermo. After a preliminary require-ment analysis, the study involved the hardware and thesoftware design of the control system and then itsimplementation aspects. Two different solutions have beenproposed and implemented, one PLC-based and the otherPC-based.Regarding the PLC-based solution, although the studyshowed that the object-oriented design surely facilitates theLD programming phase (typically a shop floor activity),unluckily it takes a considerable effort and time and thus itis not really recommended unless the manufacturing cell isrequired to process different part type. In this case, itscontrol system, fixed in its hardware configuration, is calledfor running different task plans and writing many activitydiagrams and then translating them into LD is easier thanwriting directly all the LD programs.On the other hand, when it comes to the PC-basedcontrol system, the author believes that the object-orienteddesign phase is somewhat crucial because of the possibilityto also implement the control software in an object-oriented fashion by utilizing a whatever OO programminglanguage. This feature brings a considerable advantagerespect to PLC-based solution. Indeed the control softwareOO features, both at the design and the programming level,allow, as variously demonstrated in the literature, an easyreconfiguration of the control software 23,24. Thisreconfiguration, which can be thought of as the possibilityto add, subtract, and reuse software objects, becomescrucial for two main issues. The first c
温馨提示:
1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
2: 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
3.本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
提示  人人文库网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
关于本文
本文标题:重构控制的机器人制造单元外文文献翻译、中英文翻译
链接地址:https://www.renrendoc.com/paper/91868992.html

官方联系方式

2:不支持迅雷下载,请使用浏览器下载   
3:不支持QQ浏览器下载,请用其他浏览器   
4:下载后的文档和图纸-无水印   
5:文档经过压缩,下载后原文更清晰   
关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

网站客服QQ:2881952447     

copyright@ 2020-2024  renrendoc.com 人人文库版权所有   联系电话:400-852-1180

备案号:蜀ICP备2022000484号-2       经营许可证: 川B2-20220663       公网安备川公网安备: 51019002004831号

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知人人文库网,我们立即给予删除!