Motion Control

Motion

PLCOpen is a core technology that implements a well understand and stable state machine. It handles accepting and rejecting commands that are invalid and indicates to the calling function block that a command was accepted, completed, errored or aborted.

In most cases, state that a developer builds around commanding PLCOpen is redundant and cause code to be bloated and unmaintainable. In general, Loupe recommends avoiding building state machines around PLCOpen with few exceptions. At a driver level state is typically used for initialization and homing. Aside from the basic functionality where state is wrapped, other PLCOpen commands are generally passed through and always callable. Attempting to execute a command that is not allowed by PLCOpen should throw standard Axis errors, as these contain detailed information about what was wrong.

There are cases in which an application might require some sort of statefulness of the driver to implement inhibiting or similar functions, but this should be a light wrapper, and ideally not implement a state machine

Motion Systems

There are 3 levels of tasks that we use: Drivers, Application, Process

Drivers

Drivers handle all the low level drive functions. MpAxisBasic would be an example of a driver. These include things like:

  1. Initialization
  2. Homing
  3. Power On/Off
  4. User interaction ( tuning / jogging )
  5. Error reporting and acknowledgement

The application code would typically not interface directly with the driver except for reading status information (powered, homed, position.. ).

The driver should not be application specific. Applications may require drivers to have specific functions available, but this should be transferable between projects. It is typical that an commands that cause motion on the driver are User interface optimized. Motion commands should be momentary and preferable have timeouts implemented.

Application

The application logic should handle application, but not process, specific functions. This code might be functions like gearing 2 axes of a gantry. This level of abstraction should bridge the gap between the driver and the process, enabling the process to focus on what is specific to the process

The application tasks typically require that the axis is nominally homed and powered before it can perform functions.

An application task will generally contain some minimum level of state machine and possibly sequencing.

Process

The process tasks should only implement the process functions. For a gantry system, the process task should NOT handle the geared follower axis of the gantry system, with the exception that is has functions specific to the process.

From the perspective of the process task, it should not matter what hardware is used.

The process task typically requires the Driver or Application to be ready before it can accept commands

Motion Functions

Machine specific functions should be contained in a task that is specific to that functionality. One example is a task for probing routines that require PLCOpen, as opposed to G-Code. The process task and application tasks should use local PLCopen function blocks, as opposed to interfacing directly to each other and the driver commands. This allows the proper use of the function blocks’ ‘Done’, ‘Busy’, ‘Error’ and ‘CommandAborted’ outputs.