Abbreviations

AXHLI Axis-specific High-LevelInterface

CFC Continuous Function Chart editor of TwinCAT

CM Continuous Motion (endless rotation)

DM Discrete Motion (positioning)

FB Function Block

FBSD FB-State Diagram

HLI High-Level-Interface between MC and PLC

MC Motion Controller

MCP Motion Control Platform

MCE Motion Control Engine

MC-FB Motion Controller Function Block

NL Slope Non-Linear slope

PLC Programmable Logic Control

SAI Single Axis Interpolator


Explanations of terms

Function block: internal order format of the ISG motion controller

HLI library: access to the memory interface to the ISG-MCE

ISG-MCE: this stands for the ISG NC kernel which is also referred to as the "Motion Control Engine" in connection with this documentation

MC-FB: designates the PLC function blocks that are used for issuing commands to the ISG-MC

Motion library: a PLC software application that contains function blocks for moving axes in conformity with the PLCopen specification as well as further FBs to assume motion generation tasks


What's the ISG Motion Control Platform?

TwinCAT CNC: Overview

Whats the ISG Motion Control Platform?

The ISG-MCP is a PLC library that can also be delivered in IEC 61131 source if requested by customers. It enables PLC application programmers to program motion tasks in accordance with the PLCopen standard within an IEC 61131 PLC. All functions required internally for motion generation, for example interpolation, position control, operator control of the drive interfaces, etc. are hidden from the PLC application programmer. The ISG-MCP provides the function blocks, data structures and state models defined in the PLCopen specification [1].

Figure 1-1: The PLC application programmer sees the ISG-MCP as one single programming interface.


Elements of the ISG Motion Control Platform

ISG Motion Control Platform includes different PLC user libraries. They contain function blocks and data types accordant the PLCopen specifications and others, which are defined by the motion control supplier. For easy determination which type of element it is, PLCopen specified elements of the libraries use MC_ as prefix, the motion control supplier defined elements use MCV_.

More:

button HLI library - memory interface to the ISG-MCE

button Platform library

button Motion library

button Axes group-library - PLCopen Part4

button Global variables


HLI library - memory interface to the ISG-MCE

TwinCAT CNC: Overview

HLI library  memory interface to the ISG-MCE

The user library hli.lib is one of the components of the ISG-MCP. It contains the definition of the memory interface HLI to the ISG-MCE. Through this interface, the PLCopen FB send the motion commands for their assigned axes and receive ISG-MCE messages with respect to their axis.

In the TwinCAT environment a PLC application has to call an instance of MCV_HliInterface firstly to initialize the global pointer for HLI access ( see application Frame_PLCopenP1.pro]). After successful initialization programs and function blocks of the described user libraries may be used.


Platform library

The user library McpBase.lib contains data structures that concern references in the sense of the PLCopen specification for performing motion tasks.

The variables of the references are defined as global variables within this library.

Another important part of the library is FB MCV_PlatformBase, which has to be used in every PLC application solving motion tasks with FB based on PLCopen specifications. This FB takes the task to initialise the reference structures and checks the correct definition of HLI at PLC and MCE side. Not until FB sets output Done to TRUE motion commands could be transmitted successful to the MC using FB of the motion library mentioned in the next chapter (see application Frame_PLCopenP1.pro]).


Motion library

Besides FB that conform to the PLCopen specification Part 1, FB that cover additional functionality and can be used to realize an application are also defined in the user library McpPLCopenP1.lib . This library is referred to in the rest of the text as the motion library. The contents of the provided libraries may differ between the used PLC environments.

The following figure shows the motion library's structure. This library's essential elements are then explained in detail.

Figure 1-2: Overview of the motion library McpPLCopenP1.lib in TwinCAT

More:

button PLCopen function blocks

button Function block MCV_Axis

button Function block MCV_P1_PLATFORM


PLCopen function blocks

PLCopen specification Part1 devides the defined FB according to their usage into administrative or motion FB. Within each group an additional determination is done whether one axis (single axis) is affected or multiple axes (multiple axes) are affected by the command.

Following table shows the FB defined within PLCopen specification Part1 and is organized in the same way.

FB with names printed italic and marked with * arent implemented in Motion Library Part1. But its possible that there is a FB in the library with similar functionality that is defined by the motion control supplier.

Administrative |  | Motion
Single Axis | Multiple Axes | Single Axis | Multiple Axes
MC_Power | MC_CamTableSelect | MC_MoveAbsolute | MC_CamIn
MC_ReadStatus |  | MC_MoveRelative | MC_CamOut
MC_ReadAxisError |  | MC_MoveAdditive | MC_GearIn
MC_ReadParameter |  | MC_MoveSuperimposed | MC_GearOut
MC_ReadBoolParameter* |  | MC_MoveVelocity | MC_Phasing
MC_WriteParameter |  | MC_Home | MC_GearInPos*
MC_WriteBoolParameter* |  | MC_Stop |
MC_ReadActualPosition |  | MC_PositionProfile* |
MC_Reset |  | MC_VelocityProfile* |
MC_TouchProbe |  | MC_AccelerationProfile* |
MC_AbortTrigger |  | MC_TorqueControl* |
MC_ReadDigitalInput* |  | MC_MoveContinuous* |
MC_ReadDigitalOutput* |  | MC_Halt |
MC_WriteDigitalOutput* |  |  |
MC_SetPosition |  |  |
MC_SetOverride |  |  |
MC_ReadActualVelocity* |  |  |
MC_ReadActualTorque* |  |  |
MC_DigitalCamSwitch* |  |  |

Table 1-1: Determination of PLCopen-FB Part1 into administrative and motion FB


Function block MCV_Axis

The data of an AXIS_REF structure is updated by the MCV_Axis FB that, as an input/output variable, has an AXIS_REF structure. This FB also performs the following tasks:

q Logging an axis onto the MCE via the HLI. This is done by setting the "plc_present_w" flag in the axis-specific HLI area

q Logging on the PLC via the HLI that the PLC can command spindle reset, controller enabling, feed enabling and drive ON for a specific axis to the MCE.

q During initialization, the HLI's consistency is verified by checking the version identifier and the size of the HLI.

q Acceptance of the error messages reported by the MCE for each axis

In every PLC application that uses the functionality of the ISG-MCP PLCopen function blocks, one instance of this FB must be created for each axis used and an AXIS_REF structure must be assigned to it as a VAR_IN_OUT parameter in the form g_array_axis_ref[i].

To ensure this, the ISG-MCP contains the MCV_P1_PLATFORM program (see Section 1.2.3.3), which must be instanced in the tasks of a PLC application. This ensures that the working data of one axis is updated in every PLC cycle.

Figure 1-4: Provision of AXIS_REF via the "MCV_Axis" FB

Programming example

Declaration in ST:

cam_in_1 : MC_CamIn;

Call in ST:

cam_in_1 (master:= fb_ax[0].axis_ref, slave := b_ax[1].axis_ref);


Function block MCV_P1_PLATFORM

The following has been defined for instancing and calling up the PLCopen FB:

· The generic "MCV_Axis" of the PLCopen axes are instanced and called up in the ISG-MCP. The relevant code is implemented in the MCV_P1_PLATFORM FB.

· Each PLC application using function blocks of PLCopen specification Part 1 and 2, has to call the only one instance of function block MCV_P1_PLATFORM in the project, before other function blocks for motion control are called. This ensures that one instance of the generic MCV_Axis FB is computed in each PLC cycle for each axis.

· Application programmers must ensure instancing and calling up of all PLCopen FBs serving programming of the application (e.g. motion sequence) in one application program.

· Before we call the function blocks for motion control the first time the HLI (interface to the MC) has to be initialized, and the only one instance of MCV_PlatformBase in the PLC project has to notify the successful initialisation of MCP.

Figure 1-5: Application frame for motion applications

On initialization in FB MCV_P1_PLATFORM an AXIS_REF structure is assigned to each axis, available as elements of the globally defined g_array_axis_ref array.


Axes group-library - PLCopen Part4

TwinCAT CNC: Overview

Axes group-library  PLCopen Part4

User library McpPLCopenP4.lib contains FB according PLCopen Part4 specification and FB that cover additional functionality which have to be used to build a running application. Following this library will be called axes group library. For different PLC platforms the content of the library may be different.

Following figure shows the organisation of the axes group library. Fundamental elements of the library are described afterwards.

Figure 1- 7 : Overview of axes group library McpPLCopenP4.lib in TwinCAT

More:

button Function block MCV_AxesGroup

button Function block MCV_P4_PLATFORM

button PLCopen function blocks


Function block MCV_AxesGroup

FB MCV_AxesGroup updates data of structure AXES_GROUP_REF. Therefore the FB has a IN/OUT variable of that type. Additional tasks of the FB are:

q Register an axes group at the MCE via HLI. This is done by setting flag plc_present_w at the axes group specific HLI area.

q FB checks during initialisation if axes are assigned to the axes group. In this case these axes are added to the PLC internal axes group representation without commanding a MC_AddAxisToGroup FB.

q Take over of error messages that are notified at axes group specific HLI area.

One instance of this FB must be created for each axes group that is handled by a PLC application and you have to assign the axes group reference by using an element of the array gAxesGroupRef[i].

To ensure this requirement ISG-MCP contains FB MCV_P4_PLATFORM (see chapter 1.2.4.2), this FB has to be called in a programm of a PLC application. It guarantees that data of the axes group are refreshed each PLC cycle.


Function block MCV_P4_PLATFORM

The following has been defined for instancing and calling up the PLCopen FB:

· The generic "MCV_AxesGroup" of the PLCopen axes groups are instanced and called up in the ISG-MCP. The relevant code is implemented in the MCV_P4_PLATFORM FB.

· Each PLC application using function blocks of PLCopen specification Part 4, has to call the only one instance of function block MCV_P4_PLATFORM in the project, before other function blocks for motion control are called. This ensures that one instance of the generic MCV_AxesGroup FB is computed in each PLC cycle for each axes group.

· Application programmers must ensure instancing and calling up of all PLCopen FB serving programming of the application (e.g. motion sequence) in one application program.

· Before we call the function blocks for motion control the first time the HLI (interface to the MC) has to be initialized, and the only one instance of MCV_PlatformBase in the PLC project has to notify the successful initialisation of MCP.

Bild 1-9: Application frame for axes group motion applications

In the MCV_P4_PLATFORM initialization an AXES_GROUP_REF structure is assigned to each axes group, available as elements of the globally defined gAxesGroupRef array.


PLCopen function blocks

PLCopen specification Part4 devides the defined FB according to their usage into administrative or motion FB.

Within each group an additional determination is done whether a FB is related only to an axes group (coordinated) or the FB implements a functionality that additional interacts with components out of an axes group (synchronized).

Following table shows the FB defined within PLCopen specification Part4 and is organized in the same way.

FB with names printed italic and marked with * arent implemented in Motion Library Part1. But its possible that there is a FB in the library with similar functionality that is defined by the motion control supplier.

Administrative | Motion
Coordinated | Coordinated | Synchronized
MC_AddAxisToGroup | MC_GroupHome * | MC_SyncAxisToGroup *
MC_RemoveAxisFromGroup | MC_GroupStop | MC_SyncGroupToAxis *
MC_UngroupAllAxes | MC_GroupHalt | MC_TrackConveyorBelt *
MC_GroupReadConfiguration | MC_GroupInterrupt * | MC_TrackRotaryTable *
MC_GroupEnable * | MC_GroupContinue * |
MC_GroupDisable | MC_MoveLinearAbsolute |
MC_SetKinTransform * | MC_MoveLinearRelative |
MC_SetCartesianTransform * | MC_MoveCircularAbsolute * |
MC_SetCoordinateTransform * | MC_MoveCircularRelative * |
MC_ReadKinTransform * | MC_MoveDirectAbsolute * |
MC_ReadCartesianTransform * | MC_MoveDirectRelative * |
MC_ReadCoordinateTransform * | MC_MovePath |
MC_GroupSetPosition * |  |
MC_GroupReadActualPosition |  |
MC_GroupReadActualVelocity * |  |
MC_GroupReadActualAcceleration * |  |
MC_GroupReadStatus |  |
MC_GroupReadError |  |
MC_GroupReset |  |
MC_PathSelect |  |
MC_GroupSetOverride |  |
MC_SetDynCoordTransform * |  |

Table 1-2: Classification of PLCopen-FB Part4 into administrative and motion FB


Safety concept and compliance with EN775

More:

button General details of the software safety concept

button Actual speed monitoring

button Bidirectional congruence checking of the HLI memory interface

button Priority of the MC_Stop FB

button Speed monitoring during active torque limiting

button Preventing unintentional MCFB motions in the T1 mode

button Safety low speed for non-referenced axes


General details of the software safety concept

Software safety functions in the above sense are fundamentally realized in the ISG-MCE or the MCP.

The safe state is always the default state, i.e. this default state can only be deactivated by means of special safety-relevant function blocks intended for this purpose.

The ISG delivery does not include the function blocks required for deactivation.

As the HLI is a memory-coupled interface, a realisation has been chosen for communication of safety-relevant commands that ensures that the one-time deactivation of a safety-relevant function ordered by setting a memory position does not continue to apply if the PLC no longer calls up the applicable safety function block.


Actual speed monitoring

Actual speed monitoring is realized in the ISG-MCE.

For linear axes, the limit for speed monitoring is compiled at a fixed value of 250 mm/s.

For rotary axes or spindles, parameterisation is required because of the component diameter. This is why the limit is set in the ACHSMDS list by means of the gear parameter "vb_monitor" (P-AXIS-00311). If the parameter is not in the list or is "0", the actual speed is monitored for "vb_not_referenced" (P-AXIS-00268).

q In the SAI, the error message 60241 (P-ERR-60241) "Programmed speed exceeds monitoring limit" if a high-speed motion is commanded.

q In the ISG-MCE, speed monitoring is active by default and can be deactivated with a special safety function, which must be called up cyclically.

q The actual speed is monitored cyclically in the system clock in the BF LR. If the permissible actual speed is exceeded, the error message 70225 (P-ERR-70225) "Max. actual speed exceeded during active speed monitoring" is issued and the axis is stopped by closing of the brake and removal of controller enabling.


Bidirectional congruence checking of the HLI memory interface

The ISG FBs send commands to the ISG-MCE via the so-called HLI. As this is a memory-coupled interface, congruent definition of this interface in the PLC is the prerequisite for correct functioning of the overall system. Therefore a congruence check is realised in the MCP library to ensure that the HLI interface is not operated with an incorrect HLI emulation.


Priority of the MC_Stop FB

The HLI of the ISG-MCE has, per axis, precisely one commanding and acknowledgement interface for MC commands. The commanding and acknowledgement interface are each realized as a consumption data item. Accordingly, a maximum of one FB command can be issued in each PLC cycle. If a second FB is triggered in one PLC cycle, it cannot be asserted. If (within one PLC cycle) the next command is MC_Stop, this MC_Stop overwrites the one already existing in the command memory, and so MC_Stop always has the highest priority.


Speed monitoring during active torque limiting

An additional monitoring function is realized for actual speed monitoring during active torque limiting. This can be defined in the ACHS_MDS parameter "vb_torq_limit_max" (P-AXIS-00314).

q The actual speed during active torque limiting is also monitored cyclically in the BF LR. If the permissible actual speed is exceeded, the error message "Max. actual speed exceeded during active torque monitoring" (P-ERR-70220) is issued and the axis is stopped by closing of the brake and removal of controller enabling.


Preventing unintentional MCFB motions in the T1 mode

Setting up modes

T1 mode = setting up with reduced speed

T2 mode = setting up without reduced speed

The ISG-MCE has no direct knowledge of the system's mode. The PLC programmer, to whom this information is available, can leave the safe state (= "Standstill) with the safety function blocks. The following requirement applied to compliance with EN775:

In the critical case, i.e. an operator is in the system's hazard zone and the mode T1 or T2 is active, it should only be possible to command motions by means of conscious operator actions (in the case of a robot: confirmation key + START key).

In this state, release of the start key must lead only to feed hold, but not to command aborting.

The drive's enabling signals generally disappear anyway when the mode is changed from automatic to T1 or T2.

When the confirmation key is pressed, PLCopen commands are buffered, but the motion does not yet start.

The PLC programmer can then use pressing of the start key to supply the safety function block, thus ensuring the customary functionality of the start key.


Safety low speed for non-referenced axes

If an axis is not yet referenced/adjusted or has lost the reference point/adjustment, the dimension reference to a fixed point on the machine has also been lost and so software limit switch monitoring cannot take place.

Therefore, in this state the axes cannot be absolutely positioned. Only MC_MoveRelative and MC_MoveVelocity are possible. These relative positioning methods are run at reduced speed, which can be configured in the ACHS_MDS parameter

getriebe[0].vb_not_referenced (P-AXIS-00268)


Details of realization within the ISG-MCP

The aspects of the ISG-MCP realization will be discussed in this section in the case of which the behaviour of the FB cannot be precisely forecast with the PLCopen specification 1.0 alone.

Reasons for this may be:

q Insufficient definitions in the PLCopen specification 1.0

q Characteristics of the motion control engine

More:

button Start up

button General details of the operating principle of the PLCopen FBs

button Realisation of the FBs

button Interaction of the FB with the FBSD and error handling

button Versioning

button Further general system characteristics


Start up

Various initialization processes of the ISG-MCP run through in the event of a cold start of the PLC program.

During this initialisation phase, AXSD is in the "State" 0 ("INIT_STATE").

During this phase, all FBs of the MCP behave passively, i.e. they do not have write access to the HLI. If an FB sends a command before the initialisation phase has ended, e.g. as a result of initialisation of an "Enable" input with "TRUE", the FB reports the error 16 ("FB_ERR_TNA_INIT_STATE").


General details of the operating principle of the PLCopen FBs

Internally, the PLCopen FBs do not possess any interpolation functionality. Instead, they merely serve to send motion commands to the motion control engine and to take receipt of relevant acknowledgements.


Realisation of the FBs

The PLCopen FBs internally map the following state diagram.

Figure 1-12: States within an FB

The following state automaton in IEC 61131-3 structured text shows the framework for the realisation of command issuing within an FB. The individual actions are in pseudo-code.

(*==========================================================*)

(* State automation for HLI assignment *)

(*==========================================================*)

CASE fb_state OF

(*==========================================================*)

(*==========================================================*)

FB_IDLE,

FB_ERROR:(* *)

IF ( tr_execute.Q = TRUE OR retry ) THEN

(* checking of the FB's input parameters *)

(* check whether transition is allowed *)

(* try to send the MC order. *)

(* IF (sendorder = OK) THEN fb_state := FB_ACTIVE; END_IF *)

END_IF

(*==========================================================*)

(*==========================================================*)

ACTIVE:(* *)

IF ( tr_execute.Q = TRUE OR retry) THEN

(* check whether FB's ax_ref connection has changed since idle state*)

(* checking of the FB's input parameters *)

(* check whether transition is allowed *)

(* try to send send the MC order. *)

END_IF

(* collection of Acknowledge *)

(* IF (Acknowledge = OK) THEN fb_state := FB_IDLE; END_IF *)

(*==========================================================*)

(*==========================================================*)

ELSE

(*// default: Unerlaubter Zustand *)

END_CASE;

The FBs are not aware of any reset transition and, instead, after a preceding FB_ERROR following renewed triggering of the FB an attempt is simply mad to assert the new command issued. This is why, with respect to HLI command issuing, the state distributor does not distinguish between FB_IDLE and FB_ERROR.

The FB_RETRY state does not appears as an explicit state in the state distributor, but is kept in a variable in the states FB_IDLE,FB_ERROR and FB_ACTIVE in case the FB in the corresponding state cannot asset command issuing at first go.

The unique command number is kept as a global PLC data item and incremented by the FBs only at the time after successful command issuing from the FB_IDLE and FB_ERROR states, and is noted in its instance data.

When a command is issued out of the FB_ACTIVE state, a new command with the same command number is sent to the MC and an internal counter in the FB, which counts how many commands pertaining to one command number, is incremented.

This method dispenses with complex administration of the command numbers that have been issued and the associated acknowledgements received.

When an FB is triggered, it checks whether the station transition that would be triggered by execution of the FB in the FBSD is permitted at all in the momentary state of the FBSD ("transition allowed"). If this is not the case, the command is not sent at all and, instead, the FB reports a command issuing error (= error at FB level). In such a case, the axis state never changes because no command at all has been sent. You will find further information in the next section.


Interaction of the FB with the FBSD and error handling

The "FB state behaviour" state engine described in the PLCopen specification always refers to one axis. This is why it makes sense to keep this axis state in the PLC's axis-specific working data and to make it available to all FBs via the AXIS_REF structure. The index of the corresponding Ax-HLI interface is also noted in the AXIS_REF structure.

As the axis state is kept in the axis-specific working data of the PLC, it is obvious that this FBSD can initially only contain the command issuing state.

This is also expressed in the following PLCopen rule:

The axis is always in one of the defined state (see diagram below). Any motion command is a transition that changes the state of the axis

When an FB receives a command, it must check the command's admissibility based on the FBSD's current state.

More:

button Error handling at the FBSD level

button Error handling at the FB level

button Defined errors at the FB level

button Axis errors from the motion controller


Error handling at the FBSD level

At this point, you could conclude that the FB places the FBSD in an error state in the event of an inadmissible command because it is a command issuing state automaton. According to the PLCopen specification, however, this is not the case because the following applies to the FBSD:

Note 3: The transition Error refers to errors from the axis and axis control, and not from the Function Block instances.

These axis errors may also be reflected in the output of the Function Blocks FB instances errors.

This means that a motion FB never places the FBSD in the ERROR state, but only results in an error that is reported by the motion controller. To this end, it is necessary for an axis-specific handler process to obtain the error messages from the HLI and to store them in the axis-specific work data, i.e. in the FBSD. The individual FBs then see the error state of the axis via their AXIS_REF.

Figure 1-13: Error handler supplies the axis-specific FBSD work data


Error handling at the FB level

The individual FBs' error outputs refer to errors that have occurred within the scope of command issuing to an FB instance, not to the errors of the axis. This is why incorrect command issuing sets only the commanded FB to an error state. The incorrect command itself is not even issued by the FB and so the axis (FBSD) is not even set to an error state. Therefore, other FB instances located on the same axis do not notice anything.


Defined errors at the FB level

The specific errors that can occur in the individual FBs are described in the document [3].


Axis errors from the motion controller

The motion controller uses the axis-specific interfaces of the HLI to provide messages about an axis for the PLC. The information is exchanged via a data structure of the type HLI_ERROR_SATZ.

TYPE

HLI_ERROR_SATZ :

STRUCT

error_id : UDINT; (*error identification*)

fb_zeitangabe : HLI_FB_ZEITANGABE; (*system time an error occured*)

bf_type : WORD; (*BF-type*)

behebungs_klasse : WORD; (*error trouble shooting classification*)

reaktions_klasse : WORD; (*error reaction classification*)

reserved : WORD;

END_STRUCT;

END_TYPE

Instances of the FB MCV_Axis check this axis-specific area in every PLC cycle because these are instanced in the MCV_P1_PLATFORM program and must be integrated first in the PLC task in conformity with the explanations in Section 1.2.3.3 of this program description. The MCV_Axis extracts every newly occurring message and transfers it to the AXIS_REF structure of the assigned axis, which contains one field for six data structures of the type HLI_ERROR_SATZ.

If a message has been classified as an error, the MCV_Axis instance sets the current state of the axis state diagram (AXSD) to ERROR_STOP.

All messages with value of variable behebungs_klasse > 0 are error messages.

If the value of variable behebungs_klasse = 0, the message is a warning.

The ERROR_STOP state is detected by the other PLCopen FB instances to which the same axis is assigned. Consequently, these set their "Error output variable to TRUE and the value 1 (FB_ERR_MC_AXIS, s. [3]) is indicated at the ErrorID output variable.


Versioning

Corresponding to the general conditions given by the PLC run time system and the requirement for availability even without a development system or a running PLC application, the version information is stored on the one hand in the names of the PLC libraries and, on the other hand, function blocks are implemented that check, in the application, the versions of the individual components (PLC libraries and HLI definitions at the MC or PLC end) of the ISG-MCP.

More:

button Version check by FBs


Version check by FBs

The implementation of version monitoring by FBs is based on the principle that each component of the ISG-MCP checks the version of the interfaces and PLC libraries it depends on itself. This is why some FBs are implemented in the HLI library and in the motion library. These check the components or they return the version of the library.

Generally, the user does not need to bother about this check because it is already done during start up of the PLC application by the instances of the MCV_Axis FB. These MCV_Axis instances are instanced in the MCV_P1_PLATFORM program, which is called up cyclically.

If inconsistencies occur, the other FB instances of the application are informed of them and they indicate FALSE at their "Error output and a specific error code at the ErrorID output [3].


Further general system characteristics

q Limit switch monitoring: if a travel distance limit is detected, braking takes place with the rapid traversing acceleration values (deceleration at the current limit, see P-AXIS-00004 respectively P-AXIS-00005, P-AXIS-00006), not with the standard deceleration.

q The Discrete Motion state (MC_MoveRelative) aborts the Continuous Motion state at high speed, with the result that the deceleration distance amounts to more than one modulo range. The expected behaviour does not transpire from the PLCopen specification. In the case of modulo axes, the ISG-MCP behaves as follows: the target position is noted at the moment of command aborting. The axis is braked over so many revolutions to the position as are necessary to keep to the acceleration stipulations. In the case of linear axes, the entire braking distance is run backwards because there is only one mathematical possibility of reaching the target position.


General

The PLCopen specification defines a certain behaviour of the PLCopen FB. An exact knowledge of the PLCopen specification is the basic prerequisite for successful PLC application programming using the PLCopen FB and the ISG-MCP. Confident handling of the TwinCAT PLC programming system is also required for an understanding of the details below.


Essential details in brief

More:

button Behaviour of the PLCopen FB´s "Execute" and "Done" in-\outputs

button The crux of the matter: command assertion and acknowledgement


Behaviour of the PLCopen FB´s "Execute" and "Done" in-\outputs

A PLCopen FB evaluates only the RISING EDGE of the "Execute" signal.

That is to say that, before an FB can be commanded again, it must be called up at least once with "Execute" = FALSE!

The "Done" signal of a PLCopen FB is deleted only on the basis of the FALLING EDGE of the "Execute" signal.

That is to say, if the "Done" output of an FB is connected to the "Execute" input of a second FB, for example, the following problem may arise in connection with trigger commanding:

If the first FB is triggered and "Execute" becomes FALSE before "Done" becomes TRUE, this "Done" remains at the first FB until its Execute runs through another FALLING EDGE of the "Execute" signal. As the second FB is linked directly to the first one, its Execute cannot detect a rising edge again until the first FB has undergone complete triggering. Up to then, however, it is blocked!


The crux of the matter: command assertion and acknowledgement

The HLI of the ISG-MC has, per axis, precisely one commanding and acknowledgement interface for MC commands. The commanding and acknowledgement interface are each realised as a consumption data item. Accordingly, a maximum of one FB command can be issued in each PLC cycle. If a second FB is triggered in one PLC cycle, it returns the FB-specific error: FB_ERR_MC_DID_NOT_TAKE_ORDER because the commanding interface is blocked by the previous command.

This is why the following rule applies:

No more than one PLCopen FB command may be issued per axis and PLC cycle.

Although a maximum of one command may be issued per axis and PLC cycle, from the PLC's point of view there may be several commands "en route", for which acknowledgements are expected.

Figure 2-1: State of congestion if an FB is no longer called up

Each FB instance extracts only those acknowledgements (command numbers) that is has commanded. A state of congestion arises if an FB, after having sent a command, is no longer called up before receiving its acknowledgement. The other, still active ones, can then no longer receive an acknowledgment.

Such a situation can only arise due to an error in the PLC application program or as a result of undue shutdown and start up of the PLC while the NC is running.

This is why the following further important rule applies:

After commanding, a PLCopen FB must be called up until it sets one of its "Done", "CommandAborted" or "Error" outputs.

To detect such a problem, a monitoring function can be integrated in the PLC program to check whether one and the same acknowledgement is applied to the HLI for more than two PLC cycles. This cannot be the case if the PLC program is error-free.


PLC programming tips and tricks

PLC application programming is typically done in step sequences. An unexpected behaviour of the application program may arise if the aforementioned commanding and call types are mixed.

With regard to the commanding method, a PLCopen FB can be distinguished according to:

q Trigger commanding ("Execute" TRUE only for one cycle)

q Level commanding (Execute is applied at least until "Done" = TRUE)

PLC programmers should give thought beforehand to which of the two commanding methods they wish to use and should stick to it within one project.

With regard to the call method, a PLCopen FB can be distinguished according to:

q Call within all FBs in each PLC cycle

q Call only of the relevant FB in each step

Here also, PLC programmers should give thought beforehand to which of the two call methods they wish to use and should stick to it within one project.


Tips on runtime optimization

In large applications with a large amount of axes is may be necessary to call function block instances in time optimized way. I.e. the function block instances only will be executed when theyre needed.

The following Code in StructuredText will show the technique to reduce runtime of a plc application. As an example the function block MC_MoveVelocity is used.

With the variable MC_MoveVelocity_Active the execution of the function block is being controlled. It may be set to the following values:

Value | Meaning
0 | Function block is not executed.
1 | Function block is executed, input Execute/Enable is TRUE.
2 | Function block is executed until output acknowledges are set (here: Done, CommandAborted etc.). Execute/Enable is FALSE.

In the beginning MC_MoveVelocity_Active is set to 1 depending on the input Execute/Enable. With this setting the function block MC_MoveVelocity is executed. This state is kept until the input Execute/Enable is resetted to FALSE.

IF ( Execute_MoveVelocity = TRUE ) AND

( MC_MoveVelocity_Active = 0 ) THEN

MC_MoveVelocity_Active := 1;

END_IF;

The value of MC_MoveVelocityActive changes to 2 if the input Execute/Enable is set to FALSE. Now, the function block is still executed until one of the output acknowledges (here: Done, CommandAborted, etc.) is set to TRUE. Error cases, which are not considered here, have to be handled similar.

IF MC_MoveVelocity_Active > 0 THEN

MC_MoveVelocity( Axis := AxisReference,

Execute := Execute_MoveVelocity,

Velocity := Velocity_MoveVelocity,

Acceleration := Acceleration_MoveVelocity,

Deceleration := Deceleration_MoveVelocity,

Jerk := Jerk_MoveVelocity,

Direction := Direction_MoveVelocity );

AxisReference := MC_MoveVelocity_0.Axis;

InVelocity_MoveVelocity := MC_MoveVelocity_0.InVelocity;

CommandAborted_MoveVelocity := MC_MoveVelocity_0.CommandAborted;

Error_MoveVelocity := MC_MoveVelocity_0.Error;

ErrorID_MoveVelocity := MC_MoveVelocity_0.ErrorID;

IF MC_MoveVelocity_Active = 2 AND

( InVelocity_MoveVelocity = TRUEOR

CommandAborted_MoveVelocity = TRUE ) THEN

MC_MoveVelocity_Active := 0;

ELSIF Execute_MoveVelocity = FALSE THEN

MC_MoveVelocity_Active := 2;

END_IF;

END_IF;


Programming example

Based on PLC frame application Frame_PLCopenP1.pro we show how to solve a simple motion application. In program MAIN all Function blocks are called to connect to the motion controller and for initialisation of PLCs data.

More:

button Step 1: Necessary libraries

button Step 2: : Creating the HelloWorld PLC program

button Step 3: Program HelloWorld: Instances of PLCopen FB

button Step 4: Connect axis with PLCopen FBs

button Step 5: Connect variables to FB in-/output variables

button Step 6: Insert program HelloWorld into program MAIN

button Step 7: Assignment of programs to task

button Step 8: Build application, login, run

button Step 9: Command release of axis

button Step 10: Ready, axis moved!


Step 1: Necessary libraries

To solve the motion application using PLCopen FB we have to link following PLC libraries

· STANDARD.LIB, belongs to PLC runtime system

· hli_rts_lib.lib, contains an utility FB

· hli.lib, contains layout of interface between PLC and MC

· McpBase.lib, connects to MC, contains structures and FB that are used in other PLC libraries.

· McpPLCopenP1.lib, FB based on PLCopen specification Part 1 and 2

in the application. In example Frame_PLCopenP1.pro this is already done.

Bild 3-17: Necessary libraries linked to application

Open the example application Frame_PLCopenP1.pro and save it as HelloWorld.pro, before we do additional steps to solve the application.


Step 2: : Creating the HelloWorld PLC program

Motion application is implemented in program HelloWorld using Continuous Function Chart editor (CFC). Accordant to this guideline we implement the program in the already existing folder Application:

Bild 3-18: Definition of program HelloWorld

Bild 3-19: Integration of HelloWorld program in the project tree


Step 3: Program HelloWorld: Instances of PLCopen FB

Following table shows the instances which we define to solve the motion job. They will be defined in the program HelloWorld, where the motion job will be implemented.

PLCopen-FB | Instanzname | Bemerkungen
MC_Power | MC_Power_1 | Used to activate controller and releases feed hold.
MC_ReadActualPosition | MC_ReadActualPosition_1 | Displays position of axis at output variable Position.
MC_MoveRelative | MC_MoveRelative_1 | Moves axis relative to current position. Value of distance is given at input variable Distance.

Table 3-4: Instances of FBs used in program HelloWorld

Following figure shows the definition of the applied FBs in the variable definition area of program HelloWorld and their appearance in CFC editor.

Figure 3-20: Instances of PLCopen FBs in program HelloWorld


Step 4: Connect axis with PLCopen FBs

Now we connect axis reference g_array_axis_ref[0], which refers to the first axis of the system, to the variable Axis of all instanced PLCopen FBs.

Figure 3- 21 : Connecting of first axis of system to PLCopen FBs applying g_array_axis_ref[0]


Step 5: Connect variables to FB in-/output variables

Local defined variables will be connected to the necessary and interesting in-/outputs of the PLCopen FBs. These local variables can be forced while the PLC application is running. Default values of the local variables are listed in the table below.

Variable | Data type | Default value
Instanz MC_Power_1 |  |
EnablePower | BOOL | FALSE
EnablePositive | BOOL | FALSE
EnableNegative | BOOL | FALSE
Instanz MC_ReadActualPosition_1 |  |
EnableReadActPos | BOOL | TRUE
Position | REAL |
Instanz MC_MoveRelative_1 |  |
Distance | REAL | 100000.0
Velocity | REAL | 10000.0
Acceleration | REAL | 2000.0
Deceleration | REAL | 2000.0
Jerk | REAL | 2000.0
Done | BOOL |

Table 3-5: Local variables to connect to in-/outputs of the PLCopen-FBs

Now the local variables are defined in variables definition area and some of them are initialized with a default value. Within the CFC editor the variables connected to the FBs in-/output pins are recognizable:

Figure 3- 22 : In-/output variables connected to PLCopen-FBs


Step 6: Insert program HelloWorld into program MAIN

Within example application Frame_PLCopenP1.pro program MAIN was implemented. It contains all function blocks that are necessary to drive the MCE successful. To run program HelloWorld, we add it to program MAIN after comment Insert your PLC application code after this comment.

Figure 3-23: Insert program HelloWorld into program MAIN


Step 7: Assignment of programs to task

Within example application Frame_PLCopenP1.pro program MAIN already is assigned to a task. Following figure shows the configuration of the event synchronized task:

Figure 3-24: Program MAIN is assigned to task Standard


Step 8: Build application, login, run

Now building and logging into the application follows. The default values of the variables are displayed immediately after start of the application.

Figure 3-25: Program HelloWorld after start of application


Step 9: Command release of axis

First we have to enable the controller of the axis and release feedhold to be able to move the axis. We do this by overwriting or forcing input variables Enable, Enable_Positive, Enable_Negative to TRUE at FB MC_Power_1.

Figure 3-26: : Enable controller and release feedhold by commanding MC_Power_1


Step 10: Ready, axis moved!

Motion of axis starts if value of variable StartMotion at FB MC_Move_Relative_1 is forced to value TRUE. Current position of the axis is displayed at output variable Position at FB MC_ReadActualPosition_1.

Figure below shows the state of FBs and variables at the end of the commanded motion. Value TRUE at output variable Done of FB MC_MoveRelative_1 informs us, that the motion is finished. Done remains TRUE until falling edge at input Execute is detected. We can do this by forcing value of input Execute to FALSE.

Figure 3-27: State after motion is finished