Library Kinematics Control. Siemens Industry Online Support

Transcription

1 Library Kinematics Control Library Kinematics Control Siemens Industry Online Support

2 Legal information Legal information Use of application examples Application examples illustrate the solution of automation tasks through an interaction of several components in the form of text, graphics and/or software modules. The application examples are a free service by Siemens AG and/or a subsidiary of Siemens AG ( Siemens ). They are nonbinding and make no claim to completeness or functionality regarding configuration and equipment. The application examples merely offer help with typical tasks; they do not constitute customer-specific solutions. You yourself are responsible for the proper and safe operation of the products in accordance with applicable regulations and must also check the function of the respective application example and customize it for your system. Siemens grants you the non-exclusive, non-sublicensable and non-transferable right to have the application examples used by technically trained personnel. Any change to the application examples is your responsibility. Sharing the application examples with third parties or copying the application examples or excerpts thereof is permitted only in combination with your own products. The application examples are not required to undergo the customary tests and quality inspections of a chargeable product; they may have functional and performance defects as well as errors. It is your responsibility to use them in such a manner that any malfunctions that may occur do not result in property damage or injury to persons. Disclaimer of liability Siemens shall not assume any liability, for any legal reason whatsoever, including, without limitation, liability for the usability, availability, completeness and freedom from defects of the application examples as well as for related information, configuration and performance data and any damage caused thereby. This shall not apply in cases of mandatory liability, for example under the German Product Liability Act, or in cases of intent, gross negligence, or culpable loss of life, bodily injury or damage to health, non-compliance with a guarantee, fraudulent non-disclosure of a defect, or culpable breach of material contractual obligations. Claims for damages arising from a breach of material contractual obligations shall however be limited to the foreseeable damage typical of the type of agreement, unless liability arises from intent or gross negligence or is based on loss of life, bodily injury or damage to health. The foregoing provisions do not imply any change in the burden of proof to your detriment. You shall indemnify Siemens against existing or future claims of third parties in this connection except where Siemens is mandatorily liable. By using the application examples you acknowledge that Siemens cannot be held liable for any damage beyond the liability provisions described. Other information Siemens reserves the right to make changes to the application examples at any time without notice. In case of discrepancies between the suggestions in the application examples and other Siemens publications such as catalogs, the content of the other documentation shall have precedence. The Siemens terms of use ( shall also apply. Security information Siemens provides products and solutions with industrial security functions that support the secure operation of plants, systems, machines and networks. In order to protect plants, systems, machines and networks against cyber threats, it is necessary to implement and continuously maintain a holistic, state-of-the-art industrial security concept. Siemens products and solutions constitute one element of such a concept. Customers are responsible for preventing unauthorized access to their plants, systems, machines and networks. Such systems, machines and components should only be connected to an enterprise network or the internet if and to the extent such a connection is necessary and only when appropriate security measures (e.g. firewalls and/or network segmentation) are in place. For additional information on industrial security measures that may be implemented, please visit Siemens products and solutions undergo continuous development to make them more secure. Siemens strongly recommends that product updates are applied as soon as they are available and that the latest product versions are used. Use of product versions that are no longer supported, and failure to apply the latest updates may increase customer s exposure to cyber threats. To stay informed about product updates, subscribe to the Siemens Industrial Security RSS Feed at: Entry-ID: , V1.0, 04/2018 2

3 Table of contents Table of contents Legal information Introduction Overview Mode of operation Objective Architecture and concept Components used Description of interface FB _MC_MovePath (FB 35000) FB _MC_JogFrame (FB 35010) PathData structure PLC data types PLC Tags Internal function blocks Additional function blocks Project integration Requirements Import of application Configuration of PathData Call _MovePath Operation General functionalities Operating modes Flags Error handling Application examples Example project Scenario 1: Contour - Traversing a predefined path Control of example project Scenario 2: Pick and place Control of example project Scenario 3: GCode2MovePath Control of example project Additional information GCode2MovePath Tool Appendix Service and Support Application Support Links and Literature Change documentation Entry-ID: , V1.0, 04/2018 3

4 1 Introduction 1 Introduction 1.1 Overview The library provides functionalities for TO Kinematics to easily program and control granular path motions in a command list. Figure 1-1: Kinematics Control MC_MovePath The Library Kinematics Control enables the user to easily control a kinematics to run predefined path motions using the technology object Kinematics. Instead of executing and handling several single motion commands in a user program only one core function block controls the TO Kinematics. Path information is being provided by a list of commands. Supported motion command types are linear and circular each absolute and relative including path transitions. Path motions can be stopped, interrupted and continued during execution just by inputs. Detailed information on the path execution status as well as error diagnostics information is provided. Following benefits are provided with this library: Comfortable path definition in a command list Execution of motion commands according to the command list Single step / automatic mode for path execution Diagnostic interface Flags for actuator control depending on path status Familiar interface behavior of motion commands Memory and runtime optimized function blocks Entry-ID: , V1.0, 04/2018 4

5 1 Introduction MC_JogFrame The function block MC_JogFrame provides all the functionality to jog a kinematics in Cartesian directions X, Y, Z including the orientation axis continuously, incrementally and to a specified target position. GCode2MovePath tool The additional Windows tool GCode2MovePath enables the automation generation of a command list containing the path specification for a given vector graphics or CAD file. The application can run on all 1500T CPU types with FW Mode of operation Objective The standard application enables the user to easily run predefined path motions using the technology object Kinematics. Instead of executing and handling several single motion commands in a user program the TO Kinematics is controlled by only one core function block executing a list of commands. Figure 1-1 shows the schematic application workflow. Figure 1-2: General application workflow Architecture and concept The path motion is defined by parametrizing a command list. This command list, called PathData, is provided as a library data type. The parametrization of the PathData follows the parametrization of the system functions and includes all available system motion commands for TO Kinematics. The PathData length can be adapted to the use case by a library internal user constant (LKINCTRL_NO_OF_PATHDATA_ELEMENTS). The path definition serves as an InOut parameter for the application s core FB _MC_MovePath. This function block controls the TO Kinematics and internally executes the motion commands as defined in the PathData. Furthermore, the function block can interrupt, continue and execute the path motion and offers detailed diagnostics information in its interface. Entry-ID: , V1.0, 04/2018 5

6 1 Introduction The MC_MovePath also manages to steadily keep the TO s job sequence full, but not to overload it. Therefore, a maximum look ahead in terms of dynamic planning is achieved. 1.3 Components used This application example has been created with the following hardware and software components: Table 1-1 Component Number Article number Note CPU 1515T-2 PN 1 6ES TM01-0AB0 Or other S7-1500T CPU with FW 2.5 This application example consists of the following components: Table 1-2 Component File name Note library _V1_0.zip example project _Example_V1_0.zip manual _V1_0_en.pdf Entry-ID: , V1.0, 04/2018 6

7 2.1 Description of interface List of blocks Table 2-1: List of blocks The interfaces and the controlling of the function blocks in the library are based on the PLCopen standard with taking into account of execute and enable inputs. The function blocks are implemented in Structured Control Language (SCL). They are programmed for use in a cyclic task. Block Symbol Classification FB _MC_MovePath Inhouse development FB _PreBuffer Inhouse development FB _CmdHandler Inhouse development FB _ExecuteKinMotionCmd Inhouse development FB _GetKinematicsStatusWord Inhouse development FB _MC_MovePath (FB 35000) Figure 2-1: Block diagram of _MC_MovePath _MC_MovePath execute done stop busy interrupt active reset commandaborted Int sequencemode error DInt pathtransition errorid Word DInt buffermode diagnostics Array[1..5] of LReal transitionparameter activepathdata String[10] "_typemovepathdi agnostics" TO_Kinematics "_typepathdata" Array[0.."LKINCTRL_NO_ OF_LAST_FLAG"] of activecmdno remainingdistance readyfornextpath axesgroup pathdata flags DInt LReal TO_Kinematics "_typepathdata" Array[0.."LKINCTRL_NO_ OF_LAST_FLAG"] of Principle of operation The _MC_MovePath function block is organizing and operating the complete functionality of this application. Including its internal FBs (described in the following) it controls Entry-ID: , V1.0, 04/2018 7

8 the TO Kinematic to run the user defined motion commands and return diagnostic information regarding the state of the path motion execution. Furthermore, it implements functionalities to control actuators depending on the path motion status. Supported general functionalities Start / continue path motion execution Stop / interrupt path motion execution Reset errors at the function block (not technology object errors) Selection of operating mode (automatic / sequential mode) Control of actuators via flags Supported diagnostics information Motion status information similar to PLCOpen Error and status information Function block internal Motion command error Technology object error Path motion status Active PathData (name) Active PathData command (number) Remaining distance single motion Interface parameters Table 2-2: Parameter of _MC_MovePath Name P-Type Data Type Comment execute IN execute path motion / continue path motion stop IN abort path motion interrupt IN interrupt path motion reset IN reset FB / acknowledge errors sequencemode IN Int activate sequence mode (0) / single step mode (1) pathtransition IN DInt initial transition configuration for new path motion (1: use buffermode and transitionparameter) buffermode IN DInt initial buffermode for new path motion transitionparameter IN Array[1..5] of LReal initial transitionparameter for new path motion done OUT commanded end positions reached for all axes busy OUT FB in execution / not finished active OUT FB in control of axesgroup / kinematic in motion commandaborted OUT command is aborted by another command error OUT error occurred within function block errorid OUT Word error identification diagnostics OUT "_typemovepath general diagnostics type Entry-ID: , V1.0, 04/2018 8

9 Name P-Type Data Type Comment Diagnostics" activepathdata OUT String[10] name of actual PathData activecmdno OUT DInt number of actual PathData set number remainingdistance OUT LReal all commands executed / queued in MotionQueue readyfornextpath OUT Last command entry in buffer axesgroup IN_OUT TO_Kinematics reference to the axesgroup pathdata IN_OUT "_typepathdata" reference to the PathData flags IN_OUT Array[0.."LKINCTRL_NO _OF_LAST_FLAG"] of condition for M function / additional function Status constants Table 2-3: status constants of _MC_MovePath Name Data Type Value Comment ERR_UNDEFINED_STATE Word 16#9200 error due to an undefined state in state machine ERR_EXECUTE_PATH_MOTION Word 16#9201 error due to error in FB_ExecutePathMotion ERR_RESET_TO_ACKNOWLEDGE_ERROR Word 16#9202 error on TO_Kinematics needs to be acknowledged ERR_WRONG_SEQUENCEMODE Word 16#9203 error due to invalid sequencemode on input ERR_PATHDATA_PARAMETERS Word 16#9204 error due to error in programmed motion command ERR_TO_KINEMATIC Word 16#9205 error due to TO_Kinematics error ERR_INPUT_COMBINATION_EXECUTE_STOP Word 16#9206 error due to input combination execute and stop WARN_TO_KINEMATIC Word 16#9400 warning of TO_Kinematic STATUS_EXECUTION_FINISHED Word 16#0000 execution finished without errors STATUS_NO_CALL Word 16#7000 no call of FB STATUS_FIRST_CALL Word 16#7001 first call of FB after enabling STATUS_NEXT_PATHDATA_CALL Word 16#7003 call of next PathData STATUS_SUBSEQUENT_CALL Word 16#7002 subsequent call of FB STATUS_MOVEPATH_RESET Word 16#7010 status FB is being reset STATUS_COMMAND_ABORTED Word 16#7FFF commanded functionality has been aborted by another command STATUS_CMD_LIN_ACTIVE Word 16#7301 status linear motion command active at axesgroup STATUS_CMD_CIRC_ACTIVE Word 16#7302 status circular motion command active at axesgroup STATUS_PATHMOTION_INTERRUPTED Word 16#7303 status path motion interrupted STATUS_LKINCTRL_PATHMOTION_STOPPING Word 16#7304 status path motion stopping STATUS_READY_FOR_NEXT_PATH Word 16#7306 status ready to execute next Entry-ID: , V1.0, 04/2018 9

10 Name Data Type Value path data now Comment STATUS_NOT_READY_FOR_NEXT_PATH Word 16#7305 status not ready to execute next path data FB _MC_JogFrame (FB 35010) Figure 2-2: _MC_JogFrame _MC_JogFrame jogforward done jogbackward busy jogtopositio n active USInt jogdirection error jogmodeinc status Word LReal "_typecartesianposition" DInt DInt jogincrement targetpositio n coordsyste m tool remainingdi stance diagnostics LReal "_typejogframediagnos tics" "_typedynamics" TO_Kinematics dynamics axesgroup TO_Kinematics Principle of operation The function block _MC_JogFrame provides all the functionality to jog a kinematics object in Cartesian directions X, Y, Z as well as to jog the orientation axis of the kinematics. Furthermore the positioning of the kinematics in the Cartesian space to a target position including the orientation axis is supported. The function block has been created with execute inputs for the jog commands jogforward, jogbackward and jogtoposition. As soon as a rising edge is applied to these inputs, the function block begins with the jog operation. With a falling edge at the input, the movement is stopped with a stop command. It is possible to jog the kinematics in different coordinate systems. To do this, the corresponding selection of the coordinate system must be made at the "coordsystem" input. The same applies to the selection of the tool to be used for jogging. This is selected at the "tool" input. The dynamic parameters for jogging can be defined at the "dynamics" input. If the input is not configured with parameters, the default dynamics of the kinematics technology object are used. When the function block is called, the "busy" output will be set. An active movement of the kinematics is indicated at output active. The successfully completed jog command is displayed at output "done". An error while jogging is indicated at the "error" output as long as a jog command is set but at least for one program cycle. Further details on the error can be found in the "diagnostics" output structure. The current status of the function block is displayed at output "status". Entry-ID: , V1.0, 04/

11 Continuous jog mode The kinematic movement is started in continuous mode with an edge at the "jogforward" or "jogbackward" inputs. The movement is only stopped by a falling edge at the same input or by an error at the technology object. Incremental jog mode Incremental jog mode can be selected at the "jogmodeinc" input. The distance to be traversed must be defined at the "jogincrement" input. The movement can then be started with a positive edge at the "jogforward" or "jogbackward" inputs. After reaching the defined distance, the movement will be stopped. A falling edge at the jog input stops the movement with a stop command, even if the increment has not been completed. Jog to a target position To jog the kinematics to a target position, the "jogtoposition" input must be set. A target position must first be defined at the "targetposition" input. For moving, the input must remain set and the kinematics will stop when the target position is reached. With a falling edge, the movement is stopped even if the target position has not yet been reached. Supported functionalities: Jog kinematics in X, Y, Z and A direction (incremental / continuously ) Jog kinematics to a target position Specification of the tool (tool1 3) Specification of the jog coordinate system (WCS, OCS1 3) Specification of the jog velocity (path / orientation) NOTICE Simultaneous setting of several jog inputs If more than one input is set simultaneously, no movement command is executed and an ongoing movement will be stopped. Interface parameters Table 2-4: Input parameter of _MC_JogFrame Name P-Type Data Type Comment jogforward IN Jog the kinematics forward in the selected jog direction jogbackward IN Jog the kinematics backward in the selected jog direction jogtoposition IN Jog the kinematics to the specified target position Entry-ID: , V1.0, 04/

12 Name P-Type Data Type Comment jogdirection IN USInt 1=x-direction, 2=ydirection, 3=z-direction, 4=adirection. jogmodeinc IN 1=incremental jog mode, 0=continuous jog mode. jogincrement IN LReal Specification of the jog increment targetposition IN _typecartesianposition Specification of the target position coordsystem IN DInt 0=WCS, 1= OCS1, 2=OCS2, 3=OCS3. tool IN DInt 1= tool1, 2=tool2, 3=tool3. dynamics IN _typedynamics Specification of the jog dynamics done OUT TRUE: Commanded functionality has been completed successfully busy OUT TRUE: FB is not finished and new output values can be expected active OUT TRUE: The setpoints are calculated error OUT TRUE: An error occurred during the execution of the FB status OUT Word 16# #7FFF: Status of the FB, 16# #FFFF: Error identification remainingdistance OUT LReal Distance-to-go of the current job diagnostics OUT "_typejogframediagnostics" Diagnostics information axesgroup TO_Kinematics Kinematics technology object axesgroup PathData structure Principle of operation The PathData structure represents the command list for the path definition. Provided as a library data type, the PathData is meant to be initialized in a global data block. Its length can be adapted using the internal library constant LKINCTRL_NO_OF_PATHDATA_ELEMENTS depending on the use case. All available system commands for TO Kinematics path motion (MoveLinear & MoveCircular, both absolute & relative) are supported and are listed in the PathData to define a path. The user Entry-ID: , V1.0, 04/

13 defines the specific command type and parametrizes the motion command analog to the system commands within the structure. Parameters Table 2-5: Parameter of _typepathdata Name Type Value Comment pathdataname String["LKINCTRL_LENGTH_OF_PATHDATA_NAME"] name of PathData commands Array[1.."LKINCTRL_NO_OF_PATHDATA_ELEMENTS"] of "_typepathdataelement" command list of PathData entries Additionally, flags can be set to control actuators depending on the path motion status. These are defined individually for every command entry in the list. For further information on flags see chapter NOTE See included substructures of the PathData in the following chapter PLC data types _typepathdataelement Table 2-6: Parameter of _typepathdataelement Name Type Value Comment cmdtype Int -1 1: MoveLinAbs; 2: MoveLinRel; 3: MoveCircAbs; 4: MoveCircRel; -1: End of List cmdname String[4] name of command cmdcoordinates cmdparameters "_typepointcoordinates" "_typepointparameter" flags "_typesetflag" flags to control actuators _typepointcoordinates Table 2-7: Parameter of _typepointcoordinates Name Type Value Comment cartesianposition "_typecartesianposition" coordsystem DInt 0 0: WCS; 1: OCS[1]; 2: OCS[2]; 3: OCS[3] Entry-ID: , V1.0, 04/

14 _typecartesianposition Table 2-8: Parameter of _typecartesianposition Name Type Value Comment x LReal 0.0 X y LReal 0.0 Y z LReal 0.0 Z a LReal 0.0 A _typepointparameter Table 2-9: Parameter of _typepointparameter pathdynamics Name Type Value Comment "_typepathdynamics" orientationdirection DInt 3 1: positive direction; 2: negative direction; 3: shortest distance buffermode DInt 1 1: standstill between commands, 2: blending with lower speed; 5: blending with higher speed transitionparameters Array[1..5] of LReal -1.0 blending parameters dynamicadaption DInt -1 <0.0: default TO setting used; 0: no dynamic adaption; 1: with variable limits; 2: with constant limits circleparameters "_typecircleparameters" _typepathdynamics Table 2-10: Parameter of _typepathdynamics Name Type Value Comment velocity LReal -1.0 >0.0: configured value used; <0.0: default TO setting used acceleration LReal -1.0 >0.0: configured value used; <0.0: default TO setting used deceleration LReal -1.0 >0.0: configured value used; <0.0: default TO setting used jerk LReal -1.0 >0.0: configured value used; <0.0: default TO setting used _typecircleparameters Table 2-11: Parameter of _typecircleparameters Name Type Value Comment circmode DInt 0 0: auxpoint defines point on circle line; 1: auxpoint defines circle center; 2: radius and endpoint define circle segment auxpoint endpoint Array[1..3] of LReal Array[1..4] of LReal auxiliary point for circle definition end point for circle definition pathchoice DInt 0 circmode(0): not relevant; circmode(1): 0: pos direction; 1: neg direction; circmode(2): 0: short pos segment; 1: short neg segment; 2: long pos segment; 3: long neg segment circleplane DInt 0 circmode(0): not relevant; circmode(1+2): 0: XZ; 1: YZ; 2: XY Entry-ID: , V1.0, 04/

15 Name Type Value Comment radius LReal 0.0 only in combination with circmode(2): radius arc LReal 0.0 only in combination with circmode(1): arc _typesetflag Table 2-12: Parameter of _typesetflag Name Type Value Comment setflags Array[1.."LKINCTRL_NO_OF_CMD_SETFLAGS"] of Int flags to control actuators _typemovepathdiagnostics Table 2-13: Parameter of _typemovepathdiagnostics Name Type Value Comment status Word 16#0 status of the FB pathdataname String[4] name of PathData an error occurred in cmdnumber DInt 0 command number (in PathData) an error occurred in statemovepath DInt 0 state machine status FB statussubfunction Word 16#0 status of _ExecuteKinMotionCmd motionfbnumber DInt 0 motion FB number (internal) an error occurred in motionfbstatus DWord 16#0 status of motion FB (internal) an error occurred in kinematicsstatusword DWord 16#0 statusword TO kinematics kinematicserrorword DWord 16#0 errorword TO kinematics _typejogframediagnostics Table 2-14: Parameter of _typejogframediagnostics Name Type Comment timestamp Date_And_Time Time stamp at which the error occurred status Word Status of FB when error occurred statenumber DInt State in the state machine of the FB when the error occurred _typedynamics Table 2-15: Parameter of _typedynamics Name Type Comment path "_typepathdynamics" Specification of the path dynamics orientation "_typepathdynamics" Specification of the orientations dynamics dynamicadaption DInt <0.0: default TO setting used; 0: no dynamic adaption; 1: with variable limits; 2: with constant limits Entry-ID: , V1.0, 04/

16 2.1.5 PLC Tags Table 2-16 shows the library internal PLC tag table. As there are no tags included, the table shows library constants only. The use of the single constants is explained in the chapters of their corresponding use case. Table 2-16: Parameters of _PLCTags Name Type Value LKINCTRL_MC_MOVELINEARABS Int 1 LKINCTRL_MC_MOVELINEARREL Int 2 LKINCTRL_MC_MOVECIRCULARABS Int 3 LKINCTRL_MC_MOVECIRCULARREL Int 4 LKINCTRL_NO_OF_PATHDATA_PREBUFFER_ELEMENTS Int 5 LKINCTRL_NO_OF_START_EXECUTE_CMDS Int 5 LKINCTRL_NO_OF_SEQ_EXECUTE_CMDS Int 3 LKINCTRL_PI LReal LKINCTRL_NO_OF_CMD_SETFLAGS Int 3 LKINCTRL_NO_OF_PATHDATA_ELEMENTS Int 10 LKINCTRL_NO_OF_LAST_FLAG Int 5 LKINCTRL_LENGTH_OF_PATHDATA_NAME Int 10 Entry-ID: , V1.0, 04/

17 2.1.6 Internal function blocks FB ExecuteKinMotionCmd (FB 35003) Figure 2-3: Block diagram of _ExecuteKinMotionCmd _ExecuteKinMotionCmd execute done Int mode busy interrupt active continuemotion error stop errorid Word reset status Word commandaborted faultfbnumber faultsetnumber faultpathdataname activepathdataname sendnextcmd activecmdno cmdexecuted DInt DInt String[10] String[10] Int "_typepathdataele ment_prebuf" TO_Kinematics remainingdistancesingle pathdataelementprebuf to_kinematic LReal "_typepathdatael ement_prebuf" TO_Kinematics Principle of Operation The function block _ExecuteKinMotionCmd executes the single motion commands listed in the PathData and handles the single function block instances for all internal motion commands. It manages to keep the job sequence as full as possible to achieve a maximum look ahead for dynamic path planning. It also returns status and error information regarding the execution status. NOTE The function block can be used as a standalone block as well, when setting the corresponding mode input parameter (set to 1). Entry-ID: , V1.0, 04/

18 Interface parameters Table 2-17: Parameter of _ExecuteKinMotionCmd Name P-Type Data Type Comment execute IN trigger GroupContinue / single step mode [execute input of FB_MovePath] mode IN Int FB_Mode: 0: Use in FB_MovePath (seq: interrupt, execute 5 cmds, continue); 1: use standalone interrupt IN trigger GroupInterrupt [interrupt input of FB_MovePath] continuemotion IN trigger GroupContinue [no use in FB_MovePath] (used for FB_ExecutePathMotion standalone) stop IN trigger GroupStop [stop input of FB_MovePath] reset IN reset FB / acknowledge errors [reset input of FB_MovePath] done OUT commanded end positions reached for all axes busy OUT FB in execution / not finished active OUT FB in control of axesgroup / kinematic in motion error OUT error occurred within function block errorid OUT Word error identification status OUT Word status overview FB commandaborted OUT command is aborted by another command faultfbnumber OUT DInt number of motioncommand FB with occurring error faultsetnumber OUT DInt number of PathData set with occurring error faultpathdataname OUT String[10] number of PathData with occurring error in PathData set activepathdataname OUT String[10] name of actual PathData sendnextcmd OUT flag for FB_CmdHandler: send next command activecmdno OUT Int number of actual PathData set number cmdexecuted OUT actual pathdata cmd executed to MotionQueue remainingdistancesingle OUT LReal remainingdistance of active motioncommand pathdataelementprebuf IN_OUT "_typepathdata Element_PreBuf" reference to the PathData element to be executed by FB_ExecuteKinMotionCmd to_kinematic IN_OUT TO_Kinematics reference to the axesgroup FB _CmdHandler (FB 35002) Figure 2-4: Block diagram of _CmdHandler _CmdHandler enable pathdataelementprebuf "_typepathdatael ement_prebuf" Entry-ID: , V1.0, 04/

19 sendnextcmd reloadprebuffer Int "_typepathdata_ PreBuf" firstcycle reset sequencemode pathdataprebuf startbufferexecuted Principle of Operation The FB _CmdHandler provides the FB _ExecuteKinMotionCmd with the single command entries of the PathData on request. Interface parameters Table 2-18: Parameter of _CmdHandler Name P-Type Data Type Comment enable IN enable commandhandler FB sendnextcmd IN request for new command from FB_ExecuteKinMotionCmd firstcycle IN firstcycle bit from MC_MovePath reset IN reset input from MC_MovePath sequencemode IN Int sequencemode from MC_MovePath pathdataprebuf IN "_typepathdata_ PreBuf" pathdataelementprebuf OUT "_typepathdata Element_PreBuf" pathdataprebuf to be separated into single pathdataprebufferedelements single pathdataprebufferedelement sent to FB_ExecuteKinMotionCmd reloadprebuffer OUT reload signal for FB_PreBuffer startbufferexecuted IN_OUT entries to be buffered at start executed FB _PreBuffer (FB 35001) Figure 2-5: Block diagram of _PreBuffer _PreBuffer enable done reloadprebuffer busy firstcycle error reset status Word DInt initpathtransition pathdataprebuffere d DInt initbuffermode lastcmdidpathdata Int Entry-ID: , V1.0, 04/

20 Array[1..5] of LReal "_typepathdata" inittransitionparamet er pathdata setflags Array[1.."LKINCTRL_NO_O F_PATHDATA_ELEMENTS" ] of "_typesetflag" "_typepathdata" "_typepathdata_ PreBuf" Variant pathdataprebuf pathdatalist "_typepathdata_pre Buf" Variant Principle of operation The FB _PreBuffer copies a specified number of commands from the external PathData structure to an internal structure (called PathData_preBuffered) to provide them for the FB _CmdHandler. Whilst reading the commands from the external list, the FB checks all command parameters to be valid and returns detailed error information in case of invalid parameters to avoid TO Kinematics errors. Therefore, faulty inputs during PathData configuring will be caught. Interface parameters Table 2-19: Parameter of _PreBuffer Name P-Type Data Type Comment enable IN enable PreBuffer reloadprebuffer IN signal to reload PreBuffer firstcycle IN firstcycle bit from MC_MovePath reset IN reset input from MC_MovePath initpathtransition IN DInt initpathtransition from MC_MovePath initbuffermode IN DInt initbuffermode from MC_MovePath inittransitionparamet er IN Array[1..5] of LReal inittransitionparameter from MC_MovePath done OUT FB done busy OUT FB busy error OUT error occurred status OUT Word FB status pathdataprebuffered OUT complete PathData buffered lastcmdidpathdata OUT Int last commands set number in path data setflags OUT Array[1.."LKINCTRL_NO _OF_PATHDATA_ELEM ENTS"] of "_typesetflag" array list for assignment of Flags of PathPoint to cmdids (set numbers in PathData) pathdata IN_OUT "_typepathdata" pathdata from MC_MovePath pathdataprebuf IN_OUT "_typepathdata_ PreBuf" part of PathData being pre buffered pathdatalist IN_OUT Variant variant to determine length of PathData Entry-ID: , V1.0, 04/

21 FB _GetKinematicsStatusWord (FB 35004) Figure 2-6: Block diagram of _GetKinematicsStatusWord _GetKinematicsStatusWord TO_Kinematics axesgroup error restartactive onlinestartvalues Changed controlpanelactive done linearcommand circularcommand constantvelocity accelerating decelerating orientationmotion stopping interrupted blending Principle of operation The FB _GetKinematicsStatusWord reads and analyzes the TO Kinematics status word and returns detailed and readable status information. Interface parameters Table 2-20: Parameter of _GetKinematicsStatusWord Name P- Type Data Type Comment axesgroup IN TO_Kinematics reference to the axesgroup error OUT error axesgroup restartactive OUT restart of TO Kinematic active onlinestartvalueschanged OUT change of start values TO Kinematic controlpanelactive OUT control panel TO Kinematic activated done OUT no motion command active / control panel deactivated linearcommand OUT linear command active circularcommand OUT circular command active constantvelocity OUT TO Kinematic at constant velocity accelerating OUT acceleration progress active decelerating OUT deceleration progress active orientationmotion OUT orientation motion active stopping OUT MC_GroupStop is active interrupted OUT motion interrupted Entry-ID: , V1.0, 04/

22 Name P- Type Data Type Comment blending OUT no blending segment active 2.2 Additional function blocks FB _GetKinematicsErrorWord (FB 35005) Figure 2-7: _GetKinematicsErrorWord _GetKinematicsErrorWord TO_Kinematics axesgroup systemfault configfault userfault commandnot Accepted transformatio nfault dynamicerror Principle of operation The FB _GetKinematicsErrorWord reads and analyzes the TO Kinematics error word and returns detailed and readable error information. Table 2-21: Parameter of _GetKinematicsErrorWord Name P- Type Data Type Comment axesgroup IN TO_Kinematics reference to the axesgroup systemfault OUT system-internal error has occured configfault OUT one or more configuration parameters are inconsistent or invalid userfault OUT error in the user program with a Motion Control instructioc or its use commandnotaccepted OUT command cannot be accepted transformationfault OUT error in the kinematics transformation dynamicerror OUT specified dynamic values are limited to permissible values FB _GetKinematicsWarningWord (FB 35006) Figure 2-8: _GetKinematicsWarningWord _GetKinematicsWarningWord TO_Kinematics axesgroup systemfault configfault userfault Entry-ID: , V1.0, 04/

23 commandnot Accepted dynamicwarn ing Principle of operation The FB _GetKinematicsWarningWord reads and analyzes the TO Kinematics warning word and returns detailed and readable warning information. Table 2-22: Parameter of _GetKinematicsWarningWord Name P- Type Data Type Comment axesgroup IN TO_Kinematics reference to the axesgroup systemfault OUT system-internal error has occured configfault OUT one or more configuration parameters are inconsistent or invalid userfault OUT error in the user program with a Motion Control instructioc or its use commandnotaccepted OUT command cannot be accepted dynamicwarning OUT specified dynamic values are limited to permissible values 2.3 Project integration Requirements To run the application a basic TIA portal V15 project with TO Kinematics and the corresponding number of TO PositioningAxis needs to be set up. The TO Kinematics has to be configured and a basic commissioning to run the kinematics with the control panel should be completed. NOTE Prior to execute a path motion with the FB _MC_MovePath the axes need to be enabled, eventually reset and homed by the basic motion control functions MC_POWER, MC_RESET and MC_HOME as usual Import of application The table below lists the steps for integrating the blocks of the library into your STEP 7 program. Entry-ID: , V1.0, 04/

24 Figure 2-9: Integrating the library blocks into TIA Portal NOTE Please follow the sequence of inserting the folders. Table 2-23: Integrating the library blocks into STEP 7 No. Action 1. Copy the folder _Tags with Drag & Drop into the PLC tags in the PLC. 2. Copy the folder _Types with Drag & Drop into the PLC data types in the PLC. 3. Copy the folder _Blocks with Drag & Drop into the Program blocks in the PLC. 4. Now the blocks can be configured and called in the user program Configuration of PathData In order to define a user specific path for a kinematics the path needs to be configured in the PathData structure. This structure is provided as a UDT in the library and has to be defined in a global data block by creating a variable of the type _typepathdata. NOTE By default the length of the PathData is set to 10 commands. According to the use case the length can be adapted by setting the library constant LKINCTRL_NO_OF_PATHDATA_ELEMENTS to the necessary number of elements. Entry-ID: , V1.0, 04/

25 Path definition in global DB Figure 2-10: PathData configuration in global DB Figure 2-10 shows the first command in a PathData structure configured in the DB view. The top level structure of the PathData contains the name of the PathData defined by a string and an array of commands. The string s length can also be adapted by a library constant called LKINCTRL_LENGTH_OF_PATHDATA_NAME. Default setting is a string of 10 chars. Each command entry in the list represents one system motion command (linear or circular) to be executed by the TO Kinematics. The type of command is defined by setting the variable cmdtype according to the following assignment: Entry-ID: , V1.0, 04/

26 Table 2-24: PathData configuration assignment: cmdtype TO Kinematics motion command MC_MoveLinearAbsolute 1 MC_MoveLinearRelative 2 MC_MoveCircularAbsolute 3 MC_MoveCircularRelative 4 cmdtype NOTE Default value for cmdtype = -1 indicates the command to be deactivated and the PathData to be ending before that command. A string of four chars defines an optional name for each command (or path point). The substructures cmdcoordinates and cmdparameters contain the basic parameters as used to configure the system motion commands. Minimum configuration (e.g. for linear commands) would be the definition of either a target position or a relative distance to move in the structure cartesianposition. Further parameters such as dynamic settings, blending and parameters to configure circular motions are listed at substructure cmdparameters. All named parameters equal the system commands parameters regarding name and values. Therefore, TIA help and the TO Kinematics manual serve (see literature in chapter 5.3) as information sources. Additionally, the substructure flags provides the function of setting eans at an output array of FB _MovePath. By setting integer values in the setflags array in the flags structure, the corresponding index elements of the FBs output array can be set to TRUE. For detailed information on flag functionality see chapter Path definition in SCL When not configuring the path within the PathData DB, it is recommended to realize the path definition in SCL networks. These can be inserted prior to the FB call. The image below (as well as the example project) shows a comfortable possibility to define a path in SCL. The following figure shows an exemplary setting of a path definition using SCL networks. Entry-ID: , V1.0, 04/

27 Figure 2-11: PathData definition in SCL networks In the first network a command counter variable is initialized with value 1 as the first array index of the command list in the PathData. It is continuously increased after every command definition. Therefore, the user can easily apply changes to the command order by drag and drop of networks. To minimize system load by defining a motion path, all definition network s code should only be executed once triggered by an event (e.g. upon PLC startup). Entry-ID: , V1.0, 04/

28 2.3.4 Call _MovePath After creating a PathData structure within a DB the FB _MovePath has to be called cyclically. An example for the block call with minimum signal connection is shown in the project and image below: Figure 2-12: Call of _MovePath Necessarily, the InOut parameters axesgroup, pathdata and flags need to be connected to the corresponding objects. The execute signal to start the path motion can either be set by connections to the input pin or in the code of an SCL block. Functionality descriptions for the other input pins can be found in Table 2-2. CAUTION Only trigger one instance at a time When triggering multiple instances of the function block controlling the same TO Kinematics at the same time, both instances try to execute commands which results in a mixed order in the MotionQueue. This might lead to unexpected path motion of the kinematics. Triggering multiple instances at the same time is not at all necessary, as one instance can handle multiple PathData structures subsequently in an optimized period of time (see chapter 3.4). Entry-ID: , V1.0, 04/

29 2.4 Operation General functionalities Interface controls Based on the PLCOpen Part4 behavior, the execute input of the FB _MC_MovePath is detecting rising edges to start. The input stop internally triggers the system functions MC_GroupStop. Therefore, a path motion is being aborted and all executed commands are deleted from the MotionQueue upon detection of a rising edge at stop input. According to the function of an MC_GroupInterrupt, a rising edge detected at input pin interrupt only interrupts the path motion. Actual path motion status and all executed commands stay in the MotionQueue and the motion can be continued. After interruption, another rising edge at the execute input pin continues an interrupted path motion. Error acknowledgement or general reset of the function block is being processed after a detected rising edge on reset. NOTE Reset of the function block respectively acknowledging errors is only possible when execute = FALSE and the kinematics is not in motion. Using the input sequencemode the function block can be executed in automatic or single step mode. Detailed information on operation modes follow in chapter Diagnostics & Status The diagnostic output information separates in two sections. First section is the PLCOpen based outputs done, busy, active, commandaborted, error and errorid. Their timing behavior is based on the PLCOpen conform system motion commands. The output word errorid returns detailed error information of the function block in general. In the first section further information is being provided to analyze path motion state and error information in the output structure diagnostics. Path motion status While executing a path motion the outputs activepathdata and activecmdno return information on the running command number and the corresponding PathData name. The output remainingdistance returns the remaining distance of a single active motion command. NOTE The outputs activecmdno and activepathdata return to 0 respectively after completion of the path motion (done = TRUE). The ean readyfornextpath signalizes that all commands in a PathData have been internally executed to the MotionQueue. This does not mean that the commands have already been finished, but that they can be waiting in the MotionQueue. Upon change of the readyfornextpath bit to TRUE, the FB can be executed again with the next PathData. Therefore, the MotionQueue is kept filled and a maximum look ahead for dynamic planning is possible. Diagnostics structure Detailed information on the diagnostics structure can also be found in chapter 2.5. Besides the FB status information the diagnostics structure contains detailed information that is written when an error occurs. Entry-ID: , V1.0, 04/

30 These include the concrete command number and the corresponding PathData name to identify the command possibly causing the error as well as state machine states of FBs _MC_MovePath and _ExecuteKinMotionCmd. Furthermore, the diagnostics information provides information on the TO Kinematics by providing the status and error words in case of error Operating modes Automatic mode 0 To run the FB in automatic mode the input sequencemode has to be set to 0, which is also the default value. In automatic mode the FB executes the complete PathData and returns a done signal after finishing the last defined command in the PathData. Retriggering of the FB is possible either after completion of a path motion (done = TRUE) or when the output readyfornextpath signalizes the execution of all PathData commands to the MotionQueue (explanation see below). Retriggering MovePath during kinematics driving executed PathData The output bit readyfornextpath signalizes that all commands of a PathData transferred to the FB _MC_MovePath have been registered in the MotionQueue. At that state it is possible to retrigger the FB again with a new PathData for a following path motion. That way, the MotionQueue remains completely filled and the path continues immediately after the end of the first PathData. Possibly desired transitions of the two path motions can either be configured in the following PathData s first command entry or by using the FB inputs pathtransition, buffermode and transitionparameter[1..5]. Setting the parameter pathtransition to 1 overwrites the subsequent PathData command s first entries with the blending parameters set at the FB interface. NOTE pathtransition = 1 enables the blending parameters buffermode and transitionparameter[1..5] for the transition of two PathData structures. Single step 1 To run the FB in single step mode the input sequencemode has to be set to 1. In single step mode the FB executes each command separately. Every rising edge at the input execute triggers one command in the PathData. CAUTION buffermode ignored When operating the function block in single step mode every single command in the PathData is executed separately. Therefore, no motion transitions have an effect and there is no blending between the commands. The resulting path can differ from the path driven in automatic mode, due to the missing blending segments. All programmed target position will be reached completely. Entry-ID: , V1.0, 04/

31 In case of using the FB_ExecuteKinMotionCmd as a standalone FB the sequencemode has to be set to 1 as well Flags Principle of operation Flags provide the possibility to control actuators according to the active PathData command. The configuration of flags takes place in the PathData structure. Every command entry in the PathData enables the individual setting of flags. Therefore, ean InOut signals at the _MC_MovePath interface can be set according to the command that is active at TO Kinematics. NOTE Flags will be set to TRUE as soon as the defining command is active. Configuration of Flags Figure 2-13: setflags in PathData define flags in MovePath interface to be set The setflags structure shown left in the upper figure is available for every command entry in the PathData. Within the setflags array Integer values refer to the array index of the flags InOut parameter of the FB. The referred array entry in the flags array is set to TRUE. According to the example in the figure above, the flags [1], [3] and [5] change to TRUE state once the command including the setflags definition above is active. Resetting of flags (InOut parameter) is only possible by the user program. The default value for all setflags is set to -1. This default value does not trigger any changes to the flags. It also does not reset any flags. Therefore, all once activated flags remain TRUE until being reset by the user. Also by default, the number of available setflags to define for each command is set to 3. Therefore 3 flags can be set at the same time, once a specific command gets active. Depending on the use case, this number can be changed by the library constant LKINCTRL_NO_OF_CMD_SETFLAGS. If more flags at the InOut parameter of _MC_MovePath are needed, the default number of 6 flags can be changed in the same way by adapting the library constant LKINCTRL_NO_OF_LAST_FLAG. NOTICE Number of flags[0 n] is LKINCTRL_NO_OF_LAST_FLAG+1 Due to the flags array beginning with the index count 0 the number of flags available is one count higher than the constants value. Entry-ID: , V1.0, 04/

32 Controls The flags can be connected to outputs to use them as actuator controls. Figure 2-14: flags[0 n] connected to actuators In the example shown in the figure above the flags[1] and [3] are used to close and open the gripper. As setflags only set flags[0 n] at the MC_MovePath interface to TRUE, the activation or deactivation of them has to reset the other one and vice versa. The figure below shows an example of how to use two flags to set and reset a ean actuator. Figure 2-15: Logic for setting and resetting actuators via flags The example code in the figure above shows how two setflags control a ean output signal. In this case the static variable statflags[0 n] is attached to the flags Entry-ID: , V1.0, 04/

33 InOut parameter of the _MC_MovePath interface and contains the flag signals. To use two flags for setting and resetting one actuator ean the flags need to set and reset as well the actuator itself as the corresponding flag. 2.5 Error handling Errors of the blocks are signalized at the ean output error. The output errorid contains detailed error information. Table 2-25 lists the error constants of the MC_MovePath. Table 2-25: Error constants of _MC_MovePath Name Data Type Value Comment ERR_UNDEFINED_STATE Word 16#9200 error due to an undefined state in state machine ERR_EXECUTE_PATH_MOTION Word 16#9201 error due to error in FB_ExecutePathMotion ERR_RESET_TO_ACKNOWLEDGE_ERROR Word 16#9202 error on TO_Kinematics needs to be acknowledged ERR_WRONG_SEQUENCEMODE Word 16#9203 error due to invalid sequencemode on input ERR_PATHDATA_PARAMETERS Word 16#9204 error due to error in programmed motion command ERR_TO_KINEMATIC Word 16#9205 error due to TO_Kinematics error More detailed information is given in the diagnostics structure of the FB interface described below. _typemovepathdiagnostics Table 2-26: Parameter of _typemovepathdiagnostics Name Type Value Comment status Word 16#0 status of the FB pathdataname String[4] name of PathData an error occurred in cmdnumber DInt 0 command number (in PathData) an error occurred in statemovepath DInt 0 state machine status FB statussubfunction Word 16#0 status of _ExecuteKinMotionCmd motionfbnumber DInt 0 motion FB number (internal) an error occurred in motionfbstatus DWord 16#0 status of motion FB (internal) an error occurred in kinematicsstatusword DWord 16#0 statusword TO kinematics kinematicserrorword DWord 16#0 errorword TO kinematics The parameter status is updated in every cycle and contains the FB status including error information and general status information on the FB operation. All other parameters only serve as information for error diagnostics. Update on these parameters is only performed in case of an occurring error. Entry-ID: , V1.0, 04/

34 For example, in case of an occurred error in the FB execution during driving a specified path the diagnostics structure provides detailed information on the specific path and command number the error occurred at. Furthermore, error information on which specific motion FB instance failed and an error specification are provided as well as TO_Kinematics status and error words. These help to indicate errors by analyzing the corresponding data block. The motionfbstatus parameter provides the system TO_Kinematics motion commands output errorid, in case of an error occurring during motion. Therefore also the TIA system help provides information on the specific error codes. In case of invalid inputs to the PathData structure (meaning parameters not supported by the system s MC commands) the diagnostics parameters motionfbstatus, pathdataname and cmdnumber contain the specific PathData element that is not configured correctly. The FB status provides information on the specific parameter that is invalid. Below, the error constants of the main FB s sub blocks are listed and explained in their comments. Table 2-27: Error constants of _ExecuteKinMotionCmd Name Data Type Value Comment ERR_INPUT_COMBINATION_EXECUTE_INTERRUPT Word 16#9240 error inputs execute and interrupt at the same time ERR_INPUT_COMBINATION_EXECUTE_STOP Word 16#9241 error inputs execute and stop at the same time ERR_GROUPINTERRUPT_FAILED Word 16#9242 error MC_GroupInterrupt failed ERR_GROUPCONTINUE_FAILED Word 16#9243 error MC_GroupContinue failed ERR_GROUPSTOP_FAILED Word 16#9244 error MC_GroupStop failed ERR_TO_KINEMATIC_ERROR Word 16#9245 error in TO_Kinematic The error constants of _PreBuffer include error constants to identify errors in PathData configuration. The error information is transferred to the diagnostics structure in case of invalid input values in the PathData. In case of a faulty parameter in the PathData the diagnostics parameter diagnostics.motionfbstatus will contain one of the values below identifying the invalid parameter. Additionally, diagnostics.motionfbnumber contains the command number of the faulty PathData entry. Entry-ID: , V1.0, 04/

35 Table 2-28: Error constants of _PreBuffer Name Data Type Value Comment ERR_PATHDATA_CMDTYPE Word 16#92A0 error due to invalid cmdtype in PathData ERR_PATHDATA_COORDSYSTEM Word 16#80B1 Illegal specification of the coordinate system ERR_PATHDATA_ORIENTATIONDIRECTION Word 16#8007 Illegal specification of the orientation direction ERR_PATHDATA_BUFFERMODE Word 16#80B2 Illegal specification of the motion transition ERR_PATHDATA_DYNAMICADAPTION Word 16#80B5 Illegal specification of the dynamic adaptation ERR_PATHDATA_CIRCMODE Word 16#80B6 Illegal specification for the definition of the circular path ERR_PATHDATA_PATHCHOICE Word 16#80B9 Illegal specification of the orientation of the circular path ERR_PATHDATA_CIRCLEPLANE Word 16#80BA Illegal specification for the main plane of the circular path ERR_PATHDATA_RADIUS Word 16#80BB Illegal radius specification ERR_PATHDATA_ARC Word 16#80BC Illegal angle specification Entry-ID: , V1.0, 04/

36 3 Application examples 3 Application examples 3.1 Example project Structure The example project presents three use case scenarios of the library functionality realized in two projected PLCs. PLC_1 contains the scenarios 1 and 2. PLC_2 contains scenario 3. Each scenario s FBs and DBs are stored in a corresponding folder in the Program blocks section. Each scenario consists of a separate OB which calls the scenario s FB implementing the functionality. Therefore, the scenarios can easily be transferred to other projects by copying the complete folder. Basic setup Basic setup consists of 4 technology objects PositioningAxis configured as virtual axes. These are connected to a technology object kinematics which is defined as a 3D Rollpicker with orientation. 3.2 Scenario 1: Contour - Traversing a predefined path Figure 3-1: Predefined path (contour) to be traversed by kinematics In this example the kinematics traverses a predefined path. The scenario refers to glue / print or cutting applications where a kinematics has to follow a predefined Entry-ID: , V1.0, 04/

37 3 Application examples path precisely. Figure 3-1 shows the contour of an S and its circumference which will be conducted by the kinematics TCP. Principle of operation 1. The path is defined in the DB PathData_Contour containing the PathData structure 2. The FB Contour contains the call of _MC_MovePath using the predefined PathData and the control of flags. NOTE This example can be seen and tested in the example project using PLC_1. Configuration of the PathData The path describing the contour in Figure 3-1 needs to be defined in a PathData structure. Therefore, the global data block PathData_Contour is used and the static variable contour of the user defined data type _typepathdata is inserted. The single motion commands describing the predefined path are defined within this structure Control of example project The watch table Scenario 1: Contour contains all necessary variables to control and monitor the example in scenario 1. NOTE Each scenario s example project contains a specific watch table named as the scenario. Within the General Controls section of each watch table some basic requirements to run the project need to be set. Each scenario has a variable to enable the corresponding example (first variable in each table). Furthermore, the axes need to be enabled, homed (and reset if necessary). In the MovePath Controls section of the watch table all necessary interface variables of the called _MC_MovePath block can be controlled and / or monitored. A rising edge at the execute input (see below) starts the path motion in this example. The following interface variables serve to control the path motion. Figure 3-2: Controls in watch table contour NOTE The path motion can be monitored with the kinematics trace to check for the path following the predefined contour (as in Figure 3-3). Setting the kinematics trace to start recording triggered by the execute input is useful. Entry-ID: , V1.0, 04/

38 3 Application examples Figure 3-3: Kinematics trace of contour path 3.3 Scenario 2: Pick and place Figure 3-4: Pick and place application example Entry-ID: , V1.0, 04/

39 3 Application examples In this example separated brownies arrive at one specific position on conveyor one and need to be packed in a box of four brownies on conveyor two. Principle of operation 1. The brownies are continuously provided on conveyor one and stop at a light beam. This defines the pick position. 2. Rollpicker grabs the brownies from the pick position 3. Rollpicker transports brownies to four different place positions in the box on conveyor two. Within the transportation the orientation of the product is rotated by 90 degrees. In this example the path definition and the call of the _MC_MovePath are realized in the SCL function block called PickAndPlace. NOTE This example can be seen and tested in the example project using PLC_1. Configuration of the PathData As well as in the example before, the PathData structures are stored in the global data block PathData_PickAndPlace. For the scenario s application four PathData structures will be defined. These represent the path from the pick to each of the four place positions. The configuration of the path is realized in the function block itself this time. At the beginning of the function block the path definition is realized in the region PATH_DEFINITION. Detecting a positive edge at the enable variable for the scenario s function block (enablepickandplacedemo) the code is only executed once to reduce cycle time. Figure 3-5 shows an example for defining a single command within the PathData using SCL. Entry-ID: , V1.0, 04/

40 3 Application examples Figure 3-5: Path definition in SCL code As the four place positions refer to the position of the box on conveyor two the use of an object coordinate system is helpful in this scenario. For this reason the OCS is configured in TO Kinematics configuration as shown in Figure 3-6. The OCS frame defines the distance from pick position to the box. Figure 3-6: Use of object coordinate system to define box Usage of _MC_MovePath The SCL function block PickAndPlace is based on a template for PLCOpen like behaving execute-fbs. Therefore, the block itself has an execute input which triggers the implemented functionality inside the block. The application s functionality is implemented within a simple state machine inside the function block. To perform the desired path motions only one instance of the Entry-ID: , V1.0, 04/

41 3 Application examples _MC_MovePath is necessary. This instance can be called multiple times with various PathData structures once the previous path is done or even executed to the TO Kinematics MotionQueue. The output signal readyfornextpathdata signalizes that all commands from the attached PathData have been executed to the MotionQueue. Therefore, the next PathData can be attached and the _MC_MovePath can be retriggered while finishing the last commands of the previous PathData. The usage of the bit readyfornextpathdata is shown in the example. Actuator control using the flags of _MC_MovePath is realized below the FB call as shown in Figure 3-7. The code implements the same functionality as described in Figure 2-15 using function block diagram programming language. Figure 3-7: Flag control realized in SCL Control of example project The watch table Scenario 2: PickAndPlace contains all necessary variables to control and monitor the example in scenario 2. NOTE Each scenario s example project contains a specific watch table named as the scenario. Within the General Controls section of each watch table some basic requirements for running the project need to be set. Each scenario has a variable to enable the corresponding example (first variable in each table). Furthermore, the axes need to be enabled, homed (and reset if necessary). In the MovePath Controls section of the watch table all necessary interface variables of the _MC_MovePath block can be controlled and / or monitored. A rising edge at the Controls.StartPath variable starts the application. After completion of the pick and place cycle the application can be restarted. Entry-ID: , V1.0, 04/

42 3 Application examples Figure 3-8 shows the kinematics trace of the four paths from pick position to the four place positions within the box. Figure 3-8: Kinematics trace of pick and place paths 3.4 Scenario 3: GCode2MovePath Figure 3-9: GCode2MovePath application example In this example a complex predefined path given by a vector graphic has to be traversed. Entry-ID: , V1.0, 04/

43 3 Application examples Principle of operation 1. The contour / path is given as a vector graphics. CAM (computer aided manufacturing) software (many freeware tools available) creates GCode defining the contour from the given source. 2. GCode2MovePath (see GCode2MovePath Tool) generates a PathData source containing the path information from GCode. 3. The FB Logo contains the call of _MC_MovePath using the imported PathData. NOTE This example can be seen and tested in the example project using PLC_2. NOTE To run the example using the GCode2MovePath tool adaptions to the length of the PathData and the import of a new path are necessary. These steps are described in the following and are already completed in the example project in PLC_2. Configuration of To run the subsequent example project a PathData structure with more than 10 elements (default setting) is needed. The complex structure is defined by about commands, so the PathData length has to be adapted. The library constant LKINCTRL_NO_OF_PATHDATA_ELEMENTS within in the library tag table _Tags enables to change the length of the PathData structure as shown in Figure Figure 3-10: Adaption of PathData length in library tags After adapting the PathData length the project needs to be recompiled. Entry-ID: , V1.0, 04/

44 3 Application examples Import of generated PathData The GCode2MovePath tool creates a file ending on the suffix.db such as an exported SCL source from TIA Portal. Therefore, the generated PathData can be imported as an external file. Figure 3-11: Import of external file Afterwards the blocks can be generated from the imported source file by right clicking the imported external source file (see SiemensLogo in the figure above) and choosing Generate blocks from source. NOTE To generate the blocks from source the online connection to the controller has to be terminated. After generating the blocks the project needs to be recompiled and downloaded to the PLC. Scenario 3 can be tested after performing the previous steps Control of example project The watch table Scenario 3: GCode2MovePath contains all necessary variables to control and monitor the example in scenario 1. NOTE Each scenario s example project contains a specific watch table named as the scenario. Within the General Controls section of each watch table some basic requirements for running the project need to be set. Each scenario has a variable to enable the corresponding example (first variable in each table). Furthermore, the axes need to be enabled, homed (and reset if necessary). In the MovePath Controls section of the watch table all necessary interface variables of the called _MC_MovePath block can be controlled and / or monitored. A rising edge at execute input starts the path motion in this example. The following interface variables serve control the path motion. NOTE The path motion can be monitored with the kinematics trace to check for the path following the predefined contour (as in Figure 3-12). Setting the kinematics trace to start recording triggered by the execute input is useful. Entry-ID: , V1.0, 04/

45 3 Application examples Figure 3-12: Kinematics trace of imported path Entry-ID: , V1.0, 04/

46 4 Additional information 4 Additional information 4.1 GCode2MovePath Tool The GCode2MovePath tool enables to automatically generate a command list containing the path for a given vector graphics or CAD file. Figure 4-1 shows a schematic view of the tools workflow. Figure 4-1: GCode2MovePath work flow Based on a vector graphics or (computer-aided-design) CAD model file (computeraided-manufacturing) CAM software can be used to create a GCode program defining the contour of the given object. NOTE For GCode generation several freeware tools are available online when searching for GCode to dxf tools. The GCode2MovePath tool itself works with the created GCode file and generates a PathData file by converting GCode commands to PathData commands. Used commands are MC_MoveLinearAbsolute and MC_MoveCircularAbsolute. Optional blending in between the commands can be activated while generation. The use of the GCode2MovePath tool is described in the following figures. Generation of PathData Execution of the tool is started by double clicking the file G- Code2MovePathVxx.xlsm. In the Start section of the tool the created GCode file ending on suffix.nc needs to be chosen as shown in Figure 4-2. Entry-ID: , V1.0, 04/

47 4 Additional information Figure 4-2: GCode2MovePath tool selection of GCode program file After selection of the GCode file the generation can be started. The file including the PathData DB will be created at the same directory as the GCode source. It will be named as the source file ending on the suffix.db. The example shown above creates an output file Test.db. Optional configuration for the generated file is possible in the Configuration section of the tool. The name of the exported DB and the PathData structure s name in it can be adapted as shown in Figure 4-3. The displayed data shows the default values. Furthermore, the path transitions can be adapted by setting blending mode and transition parameter for transition of all commands in the generated PathData. Figure 4-3: GCode2MovePath configuration settings The Info / Disclaimer section in Figure 4-4 lists the supported GCode commands to be converted. Circle definitions need to follow the format of G2 or G3 with parameters XYZ (end point of circle) and IJK (center of circle). Entry-ID: , V1.0, 04/

48 4 Additional information Figure 4-4: GCode2MovePath information supported G-Code commands After generation of the PathData the file needs to be imported to the PLC as shown below. Import of generated PathData The generated PathData can be imported as an external file as shown in Figure 4-5. Figure 4-5: Import of external file Afterwards the blocks can be generated from the imported source file by right clicking the imported external source file (result: see SiemensLogo in the figure above) and choosing Generate blocks from source. NOTE To generate the blocks from source the online connection to the controller has to be terminated. Finally, the PathData structure in the imported DB can be executed using the _MC_MovePath as shown in the examples. Entry-ID: , V1.0, 04/