Overview: MC3 types

MC3 function blocks use typed axis references to define the required capabilities of an axis. Each type represents a specific motion ability. This capability could, for example, be the ability to act as a coupling master or the axis's ability to receive a position setpoint. Each motion object (AXIS_REF, ENCODER_AXIS_REF) implements only the capabilities that it actually supports.

The compiler checks whether the motion object implements the types required by the function block. If this is not the case, the program cannot be compiled. This prevents operations from being called on motion objects that do not support them. The function block only queries skills, not the motion object itself. The compiler checks whether the motion objects implement this capability.

The diagram outlines the dependencies and origins of the types (Type_*) and motion objects (AXIS_REF, ENCODER_AXIS_REF). The key levels can be seen in the center:

• Types: Type_Master1D, etc., which define what a motion object can do.
• Motion objects: AXIS_REF and ENCODER_AXIS_REF, which are declared in the PLC program.

The MC3 function blocks use the specialized motion objects or the types directly.

Use

The function blocks Tc3_Mc3Base, Tc3_Mc3Ptp, Tc3_Mc3Camming, and Tc3_Mc3FluidPower require parameterization using specialized types (Type_*) or more general motion objects (AXIS_REF). The diagram above shows that the more general motion objects implement selected types.

Using these types - for example, with coupling function blocks - allows the function blocks to be reused with different Motion objects. For a function block input of type Type_Camming1D, it is clear that this parameter requires an object that can act as a slave object for cam plates. Incorrect use of motion objects is detected during compilation, not just at runtime of the user program.

The table shows a choice of function blocks and the motion objects or types used.

Example

Declaration:

VAR
    myAxis1        : AXIS_REF;
    myAxis2        : AXIS_REF;
    myEncoder      : ENCODER_AXIS_REF;
    myGearIn       : MC_GearIn;
    myTypeInstance : Type_Master1D;
END_VAR

Implementation:

// valid call
myGearIn(
    Master:= myAxis1,
    Slave:= myAxis2,
    Execute:= TRUE);

// valid call
myGearIn(
    Master:= myEncoder,
    Slave:= myAxis2,
    Execute:= TRUE);

myGearIn(
    Master:= myAxis1,
    Slave:= myEncoder, // Compiler error
    Execute:= TRUE);

myGearIn(
    Master:= myTypeInstance, // FB runtime error 16#8145
    Slave:= myAxis2,
    Execute:= TRUE);

The MC_GearIn command expects an object of type AXIS_REF at the Slave input. Therefore, it is not possible to use an encoder axis of the type ENCODER_AXIS_REF; doing so will result in a compiler error. The same applies, for example, to the command MC_CamIn, since ENCODER_AXIS_REF does not offer the type Type_Camming1D.

MC3 types do not contain any implementation code. They are not available in Solution Explorer for creating a link between an MC3 axis and an instance in the PLC. In the last example, an instance of the type Type_Master1D is assigned to the Master input. This does not result in a compiler error, since the type is essentially correct. However, the function block's logic detects that a link to an axis is missing and reports this with error 16#8145.

Migrating from NC2 to MC3