The crux of the matter: command assertion and acknowledgement
The HLI of the ISG-MC has, per axis, precisely one commanding and acknowledgement interface for MC commands. The commanding and acknowledgement interface are each realised as a consumption data item. Accordingly, a maximum of one FB command can be issued in each PLC cycle.
If a second FB is triggered in one PLC cycle, it returns the FB-specific error: 4 FB_ERR_MC_DID_NOT_TAKE_ORDER because the commanding interface is blocked by the previous command.
This is why the following rule applies:
No more than one PLCopen FB command may be issued per axis and PLC cycle. |
Although a maximum of one command may be issued per axis and PLC cycle, from the PLC's point of view there may be several commands "en route", for which acknowledgements are expected.
Each FB instance extracts only those acknowledgements (command numbers) that is has commanded. A state of congestion arises if an FB, after having sent a command, is no longer called up before receiving its acknowledgement. The other, still active ones, can then no longer receive an acknowledgment.
Such a situation can only arise due to an error in the PLC application program or as a result of undue shutdown and startup of the PLC while the NC is running.
This is why the following further important rule applies:
After commanding, a PLCopen FB must be called up until it sets one of its" done"," command_aborted" or" error" outputs. |
To detect such a problem, a monitoring function can be integrated in the PLC program to check whether one and the same acknowledgement is applied to the HLI for more than two PLC cycles. This cannot be the case if the PLC program is error-free.