SPS-API
Die TwinCAT3 Condition Monitoring Library bietet Analysemöglichkeiten in einer TwinCAT SPS Anwendung. Lesen Sie bitte hierzu unsere Produktbeschreibung und die technischen Einführungen, um sich einen Überblick zu verschaffen und wichtiges Hintergrundwissen über das Produkt anzueignen.
Die SPS API setzt sich aus drei SPS Bibliotheken zusammen. Diese Bibliotheken müssen in einem Condition Monitoring SPS Projekt eingebunden werden:
- Tc3_CM
- Tc3_CM_Base
- Tc3_MultiArray
Condition Monitoring Analyse
Neben der Programmierung, welche die Aufnahme der Messdaten, die Verarbeitung mittels unterschiedlichster Algorithmen und die Auswertung der Ergebnisse umfasst, nimmt bei jeder Signalverarbeitung eine den Anforderungen entsprechende Analysekette einen großen Stellenwert ein. Deshalb unterstützt die TwinCAT 3 Condition Monitoring Library Sie mit Funktionsbausteinen, welche die Implementierung der geplanten Analysekette nahezu zu reiner Parametrierungsarbeit machen.
Analysekette als Diagramm
Es ist sinnvoll, ein Diagramm (Beispiel siehe unten) bezüglich der Analyseschritte zu erstellen, bevor die Condition-Monitoring-Anwendung programmiert wird!
Es umfasst eine Darstellung von jedem SPS-Funktionsbaustein. In der Regel werden mindestens zwei Tasks verwendet, eine Task für das reguläre Steuerungsprogramm und eine weitere (langsamere und niederpriore) Task für die rechenintensiven Operationen des Condition Monitoring.
Jeder Analysefunktionsbaustein verwendet eine besondere Art für die Kommunikation untereinander. Diese interne Implementierung ermöglicht auch eine Kreuzkommunikation über mehrere Tasks. Intern werden ein TransferTray Objekt und mehrere MultiArrays verwendet (siehe Kapitel Parallelverarbeitung). Ein Baustein oder dessen Methoden dürfen jedoch nur aus einem Task-Kontext in der Applikation aufgerufen werden!
Die Analysefunktionsbausteine können in verschiedenen Task-Kontexten platziert werden. Die Reihenfolge der Analyseschritte wird mittels Transfer-IDs (grüne Werte in Abbildung unten) zugewiesen. Jeder Baustein erhält seine eigene beliebige ID und die Ziel-ID(s), an welche die Ergebnisse zu senden sind. Am besten werden die Transfer-IDs als Aufzählung/Enumeration definiert.
Die Abbildung unten zeigt vier verschiedene Datenpuffer: grau, orange, blau und rot. Die Form aller entsprechenden Puffer (SPS-Arrays, MultiArrays) und die Algorithmusparameter müssen zu diesen Puffergrößen passen.
 | Zyklischer Aufruf Solange die Funktionalität von FB_CMA_Source aufgerufen und Signaldaten an einen Zielbaustein übermittelt werden, müssen alle anderen Bausteine der Analysekette zyklisch aufgerufen werden. Siehe Beschreibung des internen Kommunikationsprinzips in Kapitel Parallelverarbeitung. Wenn nicht alle Zielbausteine während einer bestimmten Phase abgearbeitet werden sollen, ist ihr Aufruf zwar dennoch notwendig, aber es kann die PassInputs() Methode dazu verwendet werden, lediglich die Eingangspuffer zu übergeben, ohne dass Ergebnisse erzeugt werden. |
| Folgefehler beachten Ein zyklisch wiederkehrender Fehler bei einem Analysebaustein kann Folgefehler in der Analysekette verursachen. |
Online View
Die Funktionsbausteine der Condition Monitoring Bibliothek halten die signifikanten Informationen über den aktuellen Zustand des Bausteins im Online View bereit. Diese können für die Programmierung der Applikation (Initialisierung und Konfiguration der Bausteine, Anpassung der Puffergrößen in der Analysekette, etc.) sowie zur Analyse und Auswertung (Fehleranalyse, grafische Darstellung) verwendet werden.
Die nachfolgende Grafik zeigt den Online View des Funktionsbausteins FB_CMA_MagnitudeSpectrum. Im Folgenden werden einige Knoten und deren Verwendungsmöglichkeiten näher erläutert.
Rückgabewerte
Im Fehlerfall wird bError := TRUE gesetzt und der Rückgabewert hrErrorCode enthält den Fehlercode, siehe hierzu Fehlercodes Übersicht.
Bei der Verarbeitung mehrerer Kanäle (nChannels > 1) besteht die Möglichkeit unterschiedlicher Rückgabewerte je Kanal. In diesem Fall können gesonderte Rückgabewerte am Funktionsbaustein abgefragt werden. Sind die Ergebnisse von einem oder mehreren Kanälen unzulässig, jedoch nicht alle Kanäle, dann entspricht der Wert am Baustein eCM_InfRTime_AmbiguousChannelResults. Sind die Ergebnisse aller Kanäle unzulässig, dann entspricht der Wert am Baustein eCM_ErrRTime_ErrornousChannelResults.
Das Auslesen der Fehlerliste und eine exemplarische Behandlung ist im Beispiel Mehrkanal-Magnitudenspektrum zu finden.
Fehlerbeschreibung und Information
Unter ipErrorMessage befinden sich nähere Informationen zum aktuellen Rückgabewert. Der sEventText zeigt die textuelle Beschreibung eines aufgetretenen Fehlers. Diese Nachricht wird, je nach eingestellter TcEventSeverity (Initialparameter eTraceLevel, siehe auch Einstellung Param), über den TC3 EventLogger ausgegeben.
Initialparameter
Die Initialparameter des Bausteins, welche im Zuge der Initialisierungsphase der SPS übernommen werden, werden unter dem Knoten stInitPars abgelegt.
Für alle Funktionsbausteine, die über eine einstellbare Überlappung (Parameter nOverlap) verfügen, kann der berechnete empfohlene Wert (im Fall nOverlap := cCM_OverlapRecommended) nach dem Einloggen der SPS im genannten Knoten ausgelesen werden. Dieser kann anschließend für die Anpassung der Datenpuffer (Input/Output Shape) in der Analysekette verwendet werden. Ein Starten der Applikation ist hierfür nicht erforderlich.
ADS-Zugriff auf Ergebnisdaten
Jeder Analyse-Funktionsbaustein besitzt den Unterknoten pResultData, welcher nur im TwinCAT Target Browser sichtbar ist. Damit können die versendeten Ergebnisse (MultiArrays) zwischen verschiedenen Bausteinen einer Analysekette über ADS ausgelesen werden. Dies ermöglicht die einfache grafische Darstellung der Ergebnisse eines Bausteins mittels TwinCAT 3 Scope View ohne die Ergebnisdaten zuerst über einen Sink-Baustein von einem Multi-Array in ein SPS-Array zu überführen.
| Die beschriebene Funktionalität erfordert TC3 Scope View ab Version 1.4.3141 (verfügbar unter anderem mit TwinCAT ab Version 3.1.4024.7). |
