Recovery of the System State After an Axis Error

Recovery from axis errors is more complex with the addition of Coordinated Axes Groups (PLCopenClosed A vendor -and product- independent worldwide association active in Industrial Control and aiming at standardizing PLC file formats based on XML Part 4) to KAS RuntimeClosed In computer science, runtime (or run-time) describes the operation of a computer program, the duration of its execution, from beginning to termination (compare compile time). Within KAS, runtime also refers to the virtual machine that manage the program written in a computer language while it is running, This is due to additions in the operation of PLCopen Motion and Coordinated motion. This includes:

  • Addition of the Coordinated motion Boolean variable that allows the Runtime to IGNORE_AXIS_ESTOP(ID number 1000).
  • Addition of the Coordinated motion Boolean variable that allows the Application to read the state of the Runtime Axis errors: AXIS_ESTOP_ACTIVE (ID number 1001).
  • Addition of MC_GrpReadBoolPar
  • Addition of MC_GrpWriteBoolPar

When the application needs to take control of the default behavior where all axes in a group stop when any of them detect an Estop condition, and the Estop condition does not in itself stop all axes (Loss of EtherCATClosed ***EtherCAT is an open, high-performance Ethernet-based fieldbus system. The development goal of EtherCAT was to apply Ethernet to automation applications which require short data update times (also called cycle times) with low communication jitter (for synchronization purposes) and low hardware costs communication), the application can set the Group Boolean parameter IGNORE_AXIS_ESTOP (ID := 1000) using MC_GrpWriteBoolPar(). When set to true, the runtimeClosed In computer science, runtime (or run-time) describes the operation of a computer program, the duration of its execution, from beginning to termination (compare compile time). Within KAS, runtime also refers to the virtual machine that manage the program written in a computer language while it is running will try to keep axes in the same group as a faulting axis still able to be commanded. The intent is to not give up control of the commanded motion, but allow the application to substitute error handling motion that allows a group of axes to stop in a controlled manner. For example: command the remaining axes to a Home position, or a relative move away from the position of the faulted axis.

Once the IGNORE_AXIS ESTOP parameter is set TRUE, the Group of axes will not enter the ERRORSTOP state when an axis encounters an ESTOP condition but remain in STANDBY or MOVING state. Instead, the AXIS_ESTOP_ACTIVE (ID := 1001) parameter can be monitored to trigger a response that will abort the current operation and take control of the axes that can still be controlled. To determine which axis has faulted, the MC_ReadStatus() FB can be used to monitor each axis and select the appropriate single axis or Coordinated motion commands to execute to take control of the motion and recover from the error.

When the error recovery is completed and the faulting axis restored to normal operation, in order to restart Coordinated Motion, an MC_GrpSetPos() command must be issued to tell the Coordinated Motion Engine where the axes in the faulted Axes Group are then at, following restoration of the single axis fault(s). This command must be issued in order to reset the faulted axis.

Alternatively, if the MC_GrpWriteBoolPar() function is issued to set the IGNORE_AXIS_ESTOP parameter to FALSE, the Group will enter the ERRORSTOP state if an Axis error has not been reset, and the default behavior and default usage of MC_GrpResetError() function can be used to clear faults instead of the MC_GrpSetPos() function.