Aborting a job
The following PLC function blocks are intended for the controlled abort of one or several jobs.
- MCV_GrpResetForced
- MC_GrpStop
If one of the function blocks is used on a commanding channel, all waiting and active jobs in the channel are terminated. When they are aborted, all jobs not previously completed in commanded - i.e. subordinate - channels are also aborted. The status of each aborted job (not the channel!) changes to the MC_ABORTED status.
Notice

The selective abort of single client jobs is currently not supported.
Reason for this restriction:
In general, #SIGNAL / #WAIT events between channels cannot be reset in a coordinated process. The reason for this are the combinations of the interdependent statuses of all the channels involved and this can become very large. In addition, if an abort occurs, it is usually not possible to determine the actual system status.
If there is an incorrect restart, this could result in incorrect program starts or incorrect program flows.
If the function blocks for an abort are applied to an commanded channel, all waiting and active jobs are terminated there. If one of the aborted jobs was commanded by a commanding channel, the commanding job in the commanding channel is also set to the MC_ABORTED status and blocked. All jobs previously commanded by the commanding job for other commanded channels are not aborted.
The difference between MCV_GrpResetForced and MC_GrpStop is that MCV_GrpResetForced also resets all the axes of the commanding and commanded channels to their initial statuses.
Notice

An CNC object exists for MCV_GrpResetForced as well as for MC_MovePath and MCV_GrpReadJobAck.
#MCV_GroupResetForced can also be started from a commanding CNC program. As with MC_MovePath, the user must assign a job ID in order to permit monitoring via the described synchronisation function. The abort behaviour is the same as the #MCV_GroupResetForced function triggered by the PLC on a commanded channel.