Hinzufügen der Codesys Bibliothek für die Verwendung der CMS in Brightlayer
Funktionsbeschreibung
Kurzer Überblick über die CMS
- Die Connected Motor Solution (CMS) ist eine virtuelle Darstellung eines Motorstarters.
- In 5 Schritten können Sie das Gerät in die Cloud einbinden.
- Der erste Schritt ist die Verdrahtung der Hardware, hier sind die Pushin-Geräte die schnellste und komfortabelste Lösung.
- Der zweite Schritt ist das Auslesen der von Ihnen gewünschten Informationen aus der Hardware. In diesem Schritt hilft Ihnen die EA_CMS.library dabei, die Werte auf einfache Weise zu erhalten.
- Der dritte Schritt ist die Konfiguration des Gateways, denn die vorkonfigurierten Importdateien und Nachrichten machen die Integration einfach, da die Schnittstelle und die Form der Werte vereinheitlicht sind
- Der vierte Schritt ist das Hinzufügen eines Widgets auf einem Dashboard in Ihrem Cloud-Konto. Die Konfiguration ist mit einem Klick erledigt, da Sie nur Ihr Gerät zum Widget hinzufügen müssen.
- Im letzten Schritt können Sie das Widget nach Ihren eigenen Bedürfnissen konfigurieren.
Arbeitsprinzip
Die folgende Abbildung gibt Ihnen einen Überblick über das Arbeitsprinzip und beschreibt alle Schritte detailliert:
Für jedes Eaton HW-Gerät, das für einen Motor verwendet werden kann, existiert ein separater FB, der auch als einzelner FB verwendet werden kann.
Schritt 1: Unterstützte Hardware
Die Idee des CMS ist es, alle möglichen Lösungen für die Kombination zum Starten eines Motors zu unterstützen. Das heißt, das Gerät für den Start und das Gerät für den Schutz. Es ist auch möglich, Geräte von Drittanbietern zu verwenden, aber für Eaton Hardware bieten wir einige Hilfen an, um einen einfachen Anschluss zu ermöglichen.
Einfache Geräte wie ein Schütz und ein PKZ haben nur digitale Werte und um diese Werte in eine SPS zu bekommen, braucht man normalerweise ein lokales oder globales IO-Gerät. Mit Eaton ist es möglich, diese Geräte auf einfache Weise über SWD mit der SPS zu verbinden. SWD gibt Ihnen darüberhinaus ein wenig mehr Informationen über das angeschlossene Gerät und ist einfach zu handhaben.
Geräte mit mehr Informationen wie ein PKE oder Antriebe bieten auch die Möglichkeit, alle Informationen über Feldbus zu erhalten. Die Hardware, die der Kunde verwendet, ist unabhängig von der CMS, aber wenn Sie Eaton Hardware und SPS verwenden, bieten wir eine Bibliothek für Codesys, die es einfach macht, alle benötigten Informationen zu erhalten und sie in einer fertigen Struktur zu kombinieren, um sie in die Cloud zu senden.
Schritt 2: Konfiguration in der SPS
Um das Gerät über den Feldbus zu steuern und Informationen von ihm zu lesen, unterstützt die Bibliothek verschiedene FBs für jede Hardware.
FB_BasicMotor
Der einfachste FB ist der FB_BasicMotor. Dieser FB unterstützt nur digitale Werte und kann für alle Geräte verwendet werden, von denen Sie nur einige digitale Informationen als IO haben.
Die benötigte Information ist der xRight Main und bedeutet den Ausgang zum Starten des Motors in rechter Richtung, der refxLeft ist der Ausgang zum Starten des Motors in linker Richtung. Wenn Sie beide Ausgänge verbinden, wird der FB Ihnen die Möglichkeit geben, die Richtung zu wechseln.
FB_DIL
Dieser FB ist auch für ein Schütz über SWD vorgesehen, das einfacher zuzuordnen ist und Ihnen mehr Informationen vom Gerät gibt.
Das Mapping muss in der Deklaration vorgenommen werden und ist für alle anderen FBs gleich. Für das Mapping benötigt der FB die Informationen aus dem Geräte-Baum.
Die benötigten Informationen sind der Name im Geräte-Baum und die erste Eingangs- und Ausgangsadresse.
DIL_SWD_32 : EA_CMS.FB_DIL(itfHW_Node:= DIL_SWD_32_002, InputAdress:= ADR(%IB17), OutputAdress := ADR(%QB7)); //Instanz für DIL-FB mit SWD
FB_PKE
Dieser FB ist für einen PKE, welcher Ihnen mehr Informationen über das Motorschutzgerät bereitstellt. Beispielsweise beeinhaltet er Informationen zu dem Strom und dem definierten Auslösestromwert. Er kann mit SWD, aber auch mit Modbus RTU verwendet werden.
Wenn Sie den PKE mit SWD verwenden, ist es notwendig, Profil3 zu wählen, damit alle Informationen verfügbar sind.
Das Mapping muss hier in der Deklaration vorgenommen werden und ist für alle anderen FBs gleich. Für das Mapping benötigt der FB die Informationen aus dem Geräte-Baum.
Die benötigten Informationen sind der Name im Geräte-Baum und die erste Eingangs- und Ausgangsadresse.
PKE : FB_PKE(itfHW_Node:= PKE_SWD_32_Profile_3, InputAdress:= ADR(%IB18), OutputAdress := ADR(%QB8)); //Instanz für PKE-Starterkombination
Wenn Sie Modbus RTU verwenden, ist es notwendig, den Kanal manuell zu konfigurieren, bitte beachten Sie dazu die folgende Konfiguration.
FB_Drive
Dieser FB ist für alle Frequenzumrichter der Serien DA1, DC1 und DE1. Sie können ihn für alle Feldbusse auf die gleiche Weise verwenden.
Das Mapping muss in der Deklaration vorgenommen werden und erfolgt auf die gleiche Weise wie bei den anderen FBs. Für das Mapping benötigt der FB die Informationen aus dem Geräte-Baum.
//FB für den Umgang mit einem Eaton-Antrieb in diesem Beispiel ein DE1 mit Modbus RTU MyDrive : FB_Drive(itfHW_Node := Modbus_Slave_COM_Port, InputAdress := ADR(%IW2), OutputAdress := ADR(%QW2));
Wenn Sie Modbus RTU verwenden, ist es notwendig, den Kanal für die zyklischen Werte manuell zu konfigurieren, sehen Sie dazu die folgende Konfiguration.
FB_CmsAnalytics
Dieser FB dient dazu, einige Werte aus dem Antrieb zu berechnen, die für die Analyse nützlich sind, wie z.B. Idletime, Errortime und Runtime, oder die Anzahl der Starts.
Alle Hardware-Instanzen aus dem FB für die Hardware können mit dem Eingang itfMotorHW verbunden werden. Der Ausgang stellt alle Werte in einer Schnittstellenstruktur dar, die für das Widget in der Cloud definiert ist. Diese Werte können aber auch in der Software verwendet werden, um eine Standardschnittstelle für andere Teile der Software zu haben.
Hier ein Beispiel wie man einen HW FB mit dem FB_CmsAnalytics verbindet:
Die Struktur enthält einige Geräteinformationen, die verwendet werden können, um alle benötigten Informationen von Ihrer Motorstarterkombination zu erhalten. Die verschiedenen FBs lesen standardmäßig alle Informationen, die auf der Feldbusschnittstelle verfügbar sind, und der CMS-FB liest sie und schreibt sie in die Struktur. Wenn Sie jedoch mehr Informationen als standardmäßig lesbar benötigen, können Sie optional die drei verschiedenen Eingänge der Komponenten Ihrer Lösung verwenden, und diese Informationen werden dann in der Ausgangsstruktur angezeigt.
Hier die Definition der verschiedenen Strukturen:
tsProtectionDeviceInfo
ts_StarterDeviceInfo
ts3rdPartyDevice
Details: Fehlerinformationen in errorCode
Die Ouput-Struktur ist wie folgt aufgebaut und stellt die Schnittstelle für das Widget in der Cloud dar.
Die ersten 7 definierten Fehlercodes sind die folgenden für die Variable: wErrorCode:
0 = kein Alarm
1 = Overload (kritisch)
2 = ShortCircuit (kritisch)
3 = PhaseFailure (kritisch)
4 = TestPosition (kritisch)
5 = OverloadWithZMR (kritisch)
6 = RemoteTripping (kritisch)
7 = FieldbusComError (kritisch)