General rules for motion control function blocks

With Execute: The parameters are used with the rising edge of the execute input. To modify any parameter, change the input parameter(s) and trigger the motion again.

If an instance of a function block receives a new Execute before it finishes (as a series of commands on the same instance), the new Execute is ignored, and the previously issued instruction continues with its execution.

With Enable: The parameters are used with the rising edge of the enable input and can be modified continuously.

Missing input is captured during User Application compilation. There is no missing input error handling at the controller level.

If a function block is commanded with parameters that result in a violation of application limits, the instance of the function block generates an error. In this case, the Error output is flagged On, and error information is indicated by the output ErrorID. The controller, in most cases, remains in Run mode, and there is no Motion Error reported as a major controller fault.

The Acceleration, Deceleration, and Jerk inputs are always positive values. Velocity, Position and Distance inputs can have positive and negative values.

Position is a value defined within a coordinate system. Distance is a relative measure related to technical units. Distance is the difference between two positions.

Only linear motion is supported on Micro800 controllers. For MC_MoveAbsolute function block, the position input is the absolute location to be commanded to the axis. For MC_MoveRelative, the distance input is the relative location (considering current axis position is 0) from current position.

Velocity can be a signed value, but it can also use Direction input to define the sign of the velocity (negative velocity x negative direction = positive velocity). The E parameter "Direction" refers to the velocity input and output for compatibility reasons.

For distance (position) motion, with the target position (either absolute, or relative) defined, the motion direction is unique. The direction input for distance move is ignored.

For velocity motion, direction input value can be 1 (positive direction), 0 (current direction), or -1 (negative direction). For any other value, only the sign is considered. For example, -3 denotes negative direction, +2 denotes positive direction, and so on.

For velocity move (MC_MoveVelocity), the sign (velocity x direction) determines the actual motion direction if the value is not 0. For example, if velocity x direction = +300, then direction is positive.

With Execute: When Execute is TRUE, one of the Busy, Done, Error, or CommandAborted outputs must also be TRUE. The outputs are mutually exclusive: only one output on one function block can be TRUE.

Only one of the outputs Active, Error, Done and CommandAborted is set at one time.

With Enable: The Valid and Error outputs are mutually exclusive: only one output on one function block can be TRUE.

With Execute: The Done, Error, ErrorID and CommandAborted outputs are reset with the falling edge of Execute instruction. However, the falling edge of Execute does not stop or influence the execution of the actual function block. Even if Execute is reset before the function block completes, the corresponding outputs are set for at least one cycle.

If an instance of a function block receives a new Execute command before it completes (as a series of commands on the same instance), the new Execute command is ignored, and the previously issued instruction continues with execution.

With Enable: Valid, Enabled, Busy, Error, and ErrorID outputs are reset with the falling edge of Enable as soon as possible.

The Done output is set when the commanded action has successfully completed.

When multiple function blocks are working on the same axis in a sequence, the following applies:

When one movement on an axis is interrupted with another movement on the same axis without having reached the final goal, Done on the first function block will not be set.

Every function block can have a Busy output, indicating the function block is not finished (for function blocks with an Execute input) or is not working and new output values can be expected (in case of Enable input).

Busy is set at the rising edge of Execute and reset when one of the outputs Done, Aborted, or Error is set. The function block should be kept in the active loop of the application program for at least as long as Busy is TRUE because the outputs might change.

Function blocks with the same instance that are busy cannot execute until it is no longer busy. Function blocks with different instances can override the currently executing function block.

The CommandAborted output is set when a commanded motion is interrupted by another motion command.

The reset behavior of CommandAborted output is similar to Done output. When CommandAborted occurs, other output signals such as InVelocity are reset.

The Active output is required on buffered function blocks, and is set at the moment the function block takes control of the motion of the according axis.

For unbuffered mode, the Active and Busy outputs can have the same value.

The Enable input is coupled to a Valid output. Enable is level sensitive, and Valid shows that a valid set of outputs is available at the function block.

The Valid output is TRUE as long as a valid output value is available and the Enable input is TRUE. The relevant output value can be refreshed as long as the input Enable is TRUE.

If there is a function block error, the output is not valid (Valid set to FALSE). When the error condition disappears, the values reappear and Valid output is set again.

Outputs used to define errors:

All blocks have the following two outputs that are used for errors that occur during execution:

Done and InVelocity outputs are used for successful completion so they are logically exclusive to Error.

Instance errors do not always result in an axis error (bringing the axis to Error Stop).

Due to the naming constraints in the IEC standard on the uniqueness of variable names, the "mc" reference to the PLCopen Motion Control namespace is used for the ENUMs.

In this way we avoid the conflict that using the ENUM types "positive" and "negative" for instance with variables with these names throughout the rest of the project since they are called mcPositive and mcNegative respectively.