Verhalten von MC_TouchProbe und MC_AbortTrigger

• Eine Retriggerung einer MC_TouchProbe- bzw. MC_AbortTrigger-Instanz führt, im Gegensatz zu den Motion-Aufträgen, nicht zum Überschreiben des bisherigen Auftrags, vielmehr wird der neue Auftrag durch die FB verworfen und kein neuer Auftrag abgesetzt. Die retriggerte FB-Instanz zeigt einen FB-spezifischen Fehler an und bleibt ACTIVE. An den FB-Ausgängen „Error“ und „ErrorID“ wird für einen SPS-Zyklus ein Signal ausgegeben, mit dem sich der Vorgang der Retriggerung detektieren lässt. Hat sich zum Zeitpunkt der Retriggerung entweder die AXIS_REF oder die TRIGGER_REF geändert, wird dies als Fehler an den oben genannten FB-Ausgängen angezeigt und der Auftrag ebenfalls verworfen.
• Der Output „CommandAborted“ kann nur gesetzt werden, wenn die Beauftragung von einem MC_AbortTrigger explizit abgebrochen wird. Dieser muss dazu in TRIGGER_REF die identische Messkanalnummer und Mode verwenden, weil ein Messauftrag ausschließlich anhand der Übereinstimmung aller Parameter der TRIGGER_REF identifiziert wird.
• Im Gegensatz zu den Motion-Beauftragungen führt eine Messbeauftragung nicht zu einer Änderung des Achszustandes. Da PLCopen keine Angaben macht in welchen Zuständen ein MC_TouchProbe zulässig ist, wird festgelegt, dass dieser in allen Zuständen außer „ERROR_STOP“ und „HOMING“ zulässig ist.
• Für einen Messkanal wird ein separater Zustandsgraph implementiert. Der aktuelle Zustand des Messkanals wird in „tp_state“ in der AXIS_REF der Achse verwaltet, über die der Messauftrag abgesetzt wurde.

Abb.2: Zustandsgraph des Messkanals

• Somit sind maximal so viele Messaufträge gleichzeitig möglich, wie es Achsen gibt.