Verwendung von Templates

Der folgende Artikel beschreibt, wie Vorlagen verwendet werden, statt jede einzelne Einstellung separat über das Automation Interface zu konfigurieren. Die Verwendung von Vorlagen bietet viele Vorteile: Sie sind einfacher zu pflegen, einfacher durch neue Vorlagen auszutauschen und sie bieten mehr Möglichkeiten, wenn mit mehreren Teams an einem TwinCAT-Projekt gearbeitet wird. Dieses Dokument beschreibt die Nutzung von Vorlagen und behandelt die folgenden Themen:

• Die allgemeine Idee hinter Vorlagen und ihren verschiedenen Ebenen
• Arbeit mit I/O Vorlagen
• Arbeit mit Bewegungsvorlagen (Achsen)
• Arbeit mit SPS-Vorlagen

Die allgemeine Idee hinter Vorlagen und ihren verschiedenen Ebenen

Die Idee hinter der Nutzung von Vorlagen ist so einfach wie der Code des Automation Interface und die Anwendung des Automation Interface selbst. Den meisten Benutzern ist nicht bekannt, dass Vorlagen in einer TwinCAT-Konfiguration auf verschiedenen Ebenen existieren können. Hierzu zählen:

• Vorlagen auf „Konfigurationsebene“:
  
  Vorlagen auf Konfigurationsebene können als verschiedene TwinCAT-Konfigurationen existieren (*.sln oder *.tszip Datei). Jede Konfiguration kann unterschiedlichen Inhalt umfassen und durch den Code des Automation Interface geöffnet und aktiviert werden.
• Vorlagen auf „(SPS) Projektebene“:
  
  Vorlage auf (SPS) Projektebene können als mehrere TwinCAT SPS-Projekte existieren, entweder als ungepackte Ordnerstruktur (*.plcproj Datei) oder als Containerdatei (*.tpzip). Diese SPS-Projekte können dann bei Bedarf über den Code des Automation Interface importiert werden.
• Vorlagen auf „Strukturelementebene“:
  
  Vorlagen auf Strukturelementebene können als sogenannte TwinCAT Exportdateien (*.xti) existieren. Diese Dateien können bei Bedarf über den Code des Automation Interface importiert werden und enthalten alle Einstellungen, die für ein EtherCAT Master I/O Gerät vorgenommen wurden.

Wie die vorstehende Beschreibung nahelegt, haben alle verschiedenen Vorlagenebenen eine Sache gemeinsam: die Vorlagen existieren als Dateien im Dateisystem. Es gilt als Best Practice, dass zu Beginn der Implementierung einer eigenen Anwendung des Automation Interface eindeutig definiert wird, welche Art von „Vorlagenpool“ verwendet wird. Ein Vorlagenpool beschreibt ein Repository, in dem alle Vorlagendateien (die ebenfalls eine Mischung verschiedener Vorlagenebenen sein können) gespeichert werden. Dies könnte einfach das lokale (oder ferne) Dateisystem sein oder ebenfalls ein Source-Control-System (z. B. Team Foundation Server), von dem aus Vorlagedateien automatisch abgerufen, ausgecheckt und zu einer neuen TwinCAT-Konfiguration zusammengesetzt werden. Zur besseren Übersicht und zur Vereinfachung der ersten Schritte haben wir einen separaten Dokumentationsartikel erstellt, der aufzeigt, wie das Visual Studio Object Model (DTE) zur Verbindung an einen Team Foundation Server (TFS) verwendet wird und wie diese Vorgänge über den Programmcode ausgeführt werden. Sie erhalten jedoch weitere Informationen über die Verwendung von TFS über den Code des Automation Interface, wobei wir sehr empfehlen, die entsprechenden Artikel des Microsoft Developer Network (MSDN) zu lesen.

Die folgenden Themen beschreiben, wie jede Vorlagenebene in des Automation Interface für einen unterschiedlichen TwinCAT- Bereich (I/O, SPS usw.) verwendet werden kann.

Arbeit mit Konfigurationsvorlagen

Vorlagen auf Konfigurationsebene bieten die grundlegendste Möglichkeit der Verwendung von Vorlagen. In diesem Szenario enthält ein Vorlagenpool zwei oder mehr vorkonfigurierte TwinCAT-Konfigurationen und bietet sie als TwinCAT Lösungsdateien (*.sln oder *.tszip) an. Diese Dateien können über das Automation Interface durch Verwendung der Visual Studio Methode AddFromTemplate() geöffnet werden.

Code-Ausschnitt (C#):

project = solution.AddFromTemplate(@"C:\TwinCAT Project.tszip", destination, projectName);

Code-Ausschnitt (Powershell):

$project = $solution.AddFromTemplate(@"C:\TwinCAT Project.tszip", $destination, $projectName)

OR

Code-Ausschnitt (C#):

project = solution.Open(@"C:\TwinCAT Project 1.sln");

Code-Ausschnitt (Powershell):

$project = $solution.Open(@"C:\TwinCAT Project 1.sln")

Arbeit mit I/O Vorlagen

Bei der Arbeit mit I/O Geräten erhalten Benutzer häufig dieselben Aufgaben auf den I/O Geräten immer wieder. Dies bedeutet dieselben Einstellungen an den I/O Geräten mit jeder TwinCAT-Konfiguration machen. TwinCAT bietet einen Mechanismus, der alle diese Einstellungen in einem speziellen Dateiformat speichert, der sogenannten XTI Datei (*.xti). Dieses Dateiformat kann von dem Code des Automation Interface verwendet werden, um eine neue Konfiguration unter Verwendung der Methode ImportChild() zu importieren, die in der Schnittstelle ITcSmTreeItem definiert ist.

Code-Ausschnitt (C#):

ITcSmTreeItem io = systemManager.LookupTreeItem("TIID");
ITcSmTreeItem newIo = io.ImportChild(@"C:\IoTemplate.xti", "", true, "SomeName");

Code-Ausschnitt (Powershell):

$io = $systemManager.LookupTreeItem("TIID")
$newIo = $io.ImportChild(@"C:\IoTemplate.xti", "", true, "SomeName")

Dabei ist es wichtig darauf hinzuweisen dass bei einem Export eines I/O Geräts innerhalb von TwinCAT XAE alle Teilgeräte automatisch exportiert werden und in der Exportdatei ebenfalls enthalten sind. Der folgende Screenshot zeigt, wie I/O Geräte in eine Exportdatei exportiert werden.

Denken Sie daran, dass Sie ebenfalls das Automation Interface verwenden können, um ein I/O Gerät in eine XTI Datei zu exportieren. Hierfür steht die Methode ExportChild() aus der ITcSmTreeItem Schnittstelle zur Verfügung.

Arbeit mit Bewegungsvorlagen (Achsen)

Die Verwendung von Bewegungsachsenvorlagen ist sehr ähnlich zu der von I/O Geräten. Achsen können ebenfalls in eine XTI-Datei exportiert werden, entweder über TwinCAT XAE oder über den Code des Automation Interface unter Verwendung von ExportChild().

Durch Verwendung von ImportChild() können diese Exportdateien später wieder importiert werden.

Code-Ausschnitt (C#):

ITcSmTreeItem motionAxes = systemManager.LookupTreeItem("TINC^NC-Task^Axes");
motionAxes.ImportChild(@"C:\AxisTemplates.xti", "", true, "Axis 1");

Code-Ausschnitt (Powershell):

$motionAxes = $systemManager.LookupTreeItem("TINC^NC-Task^Axes")
$motionAxes.ImportChild(@"C:\AxisTemplates.xti", "", true, "Axis 1")

Arbeit mit SPS-Vorlagen

SPS-Vorlagen sind auf zwei Arten verfügbar: Sie können entweder die kompletten SPS-Projekte als Ganzes verwenden oder jede POU einzeln als Vorlage. Zur Integration in ein bestehendes TwinCAT-Projekt verwenden Sie einfach die CreateChild() Methode der ITcSmTreeItem Schnittstelle.

Code-Ausschnitt (C#):

ITcSmTreeItem plc = systemManager.LookupTreeItem("TIPC");
plc.CreateChild("NewPlcProject", 0, null, pathToTpzipOrTcProjFile);

Code-Ausschnitt (Powershell):

$plc = $systemManager.LookupTreeItem("TIPC")
$plc.CreateChild("NewPlcProject", 0, $null, $pathToTpzipOrTcProjFile)

Weitere Optionen zum Import bestehender SPS-Projekte erhalten Sie in dem Best Practice Artikel über „Zugriff auf, Erstellung von und Umgang mit SPS-Projekten.“

Die nächste Granularitätsebene zum Import von Vorlagendateien für die SPS ist der Import von bestehenden POUs, wie z. B. Funktionsblöcke, Strukturen, Aufzählungen, globale Variablenliste usw. Einer der Gründe dafür, warum sich ein Entwickler für einzelne POUs als Vorlagen entscheiden kann, besteht darin, dass es einfacher ist, einen Pool von bestehenden Funktionalitäten aufzubauen und in separaten POUs zusammenzufassen, z. B. verschiedene Funktionsblöcke, die verschiedene Sortieralgorithmen abdecken. Bei der Projekterstellung wählt der Entwickler einfach die Funktionalität aus, die er in seinem TwinCAT-Projekt benötigt und greift auf das Vorlagetool zu, um die entsprechende POU abzurufen und diese in das SPS-Projekt zu importieren.

Code-Ausschnitt (C#):

ITcSmTreeItem plcProject = systemManager.LookupTreeItem(“TIPC^Name^Name Project”);
plcProject.CreateChild(“NameOfPou”, 58, null, pathToPouFile);
plcProject.CreateChild(null, 58, null, stringArrayWithPathsToPouFiles);

Code-Ausschnitt (Powershell):

$plcProject = $systemManager.LookupTreeItem("TIPC^Name^Name Project")
$plcProject.CreateChild("NameOfPou", 58, $null, $pathToPouFile)
$plcProject.CreateChild($null, 58, $null, $stringArrayWithPathsToPouFiles)