Größere Änderungen für Langzeitstabilität in TIA Portal Openness V17 - TIAPortal

TIA Portal Openness: API für die Automatisierung von Engineering-Workflows

ft:publication_title
TIA Portal Openness: API für die Automatisierung von Engineering-Workflows
Product
TIAPortal
Version
V20
Publication date
01/2025
Language
de-DE
Größere Änderungen für Langzeitstabilität in TIA Portal Openness V17

Änderungen

Wenn Sie die Hinweise zur versionsübergreifenden Programmierung beachtet haben und Ihre Openness-Anwendung nicht auf V17 aufbauen, laufen Ihre Anwendungen ohne jede Einschränkung auf jedem Rechner, auch wenn nur ein TIA Portal V17 installiert ist.

Wenn Sie Ihre Openness-Anwendung auf V17 aufbauen, ist es notwendig, Ihre Anwendung mit der SiemensEngineering.dll von V17 neu zu übersetzen. In manchen Fällen kann es erforderlich sein, den Code Ihrer Anwendung anzupassen.

Änderung bei der Implementierung von GetAttribute

Bis TIA Portal Openness V16 war die Sichtbarkeit der Implementierung von GetAttribute/SetAttribute/GetAttributeInfos davon abhängig, ob für den Typ "Unterstützt dynamisches Attribut" deklariert wurde. Für den Zugriff auf Methoden wie GetAttribute/SetAttribute/GetAttributeInfos sollte der Typ dynamische Attribute unterstützen. Wenn der Typ keine dynamischen Attribute unterstützt, müssen Sie explizit an IEngineeringObject übertragen, um die Anzeige der Methoden GetAttribute/SetAttribute/GetAttributeInfos zu sehen.

Das folgende Beispiel zeigt, wie der Code bis TIA Portal Openness V16 ausgeführt wird:

Kopiert den nachfolgenden Programmcode in die Zwischenablage.

var projectAttributeInfos = ((IEngineeringObject) project).GetAttributeInfos();

In TIA Portal Openness V17 werden alle Methoden von IEngineeringObject implizit in allen Typen implementiert, die IEngineeringObject implementieren, der explizite Aufruf ist somit nicht mehr erforderlich und alle Methoden werden angezeigt. Die Änderung steht für alle früheren Engineering-dlls wie V15, V15.1 & V16 zur Verfügung, die in V17 unterstützt werden.

Für die folgenden Methoden ist eine Typumwandlung nicht erforderlich:

  • object GetAttribute(string name) – ruft ein Attribut mit dem angegebenen Namen ab.

  • IList<EngineeringAttributeInfo> GetAttributeInfos() – gibt eine Sammlung von EngineeringAttributeInfo-Objekten zurück, die die verschiedenen Attribute zu diesem Objekt beschreiben.

  • IList<object> GetAttributes(IEnumerable<string> names) – ruft eine Liste von Attributen für die angegebenen Namen ab.

  • void SetAttribute(string name, object value) – legt ein Attribut mit dem angegebenen Namen auf den angegebenen Wert fest.

  • void SetAttributes(IEnumerable<KeyValuePair<string, object>> attributes) – legt die Attribute mit den angegebenen Namen auf die angegebenen Werte wie in den Attributen angegeben fest.

Mit dieser Änderung verbunden ist ein geringfügig verändertes Verhalten beim erneuten Kompilieren des Codes, der unter der Methode Extension verwendet wird. Wurde beispielsweise die Methode Extension verwendet und der Code wird in die V17 Engineering-dll kompiliert, wird ein Aufruf aus Extension nicht ausgeführt. Sie müssten in diesem Fall den Code so ändern, dass er mit dem Verhalten kompatibel bleibt. Es würde dann auch kein Compiler-Fehler auftreten.

Der folgende Code zeigt den Fall, in dem die Methode GetAttribute nicht ausgeführt wird:

Kopiert den nachfolgenden Programmcode in die Zwischenablage.

static class CustomerExtension

{

public static object GetAttribute(this Project project, string name)

{

// Customer Logic

return ((IEngineeringObject)project);

}

}

Änderungen in AssignInterface API

Vor TIA Portal Openness V17 kann AssignInterface API nicht in Transaktionen in TIA Portal Openness verwendet werden. Ab TIA Portal Openness V17 ändert sich dies und AssignInterface API kann jetzt in Transaktionen verwendet werden.

Einstellung der Mastersystem-Nummer

Ab TIA Portal Openness V17 kann die Nummer des Mastersystems beim Importieren einer API eingestellt werden.

Entfernung der Methode ExternalSourceCreate

Vor TIA Portal Openness V17 wurde die Erstellung aus einer externen Quelle mit "Nicht unterstützte Ausnahme" in TIA Portal Openness unterstützt. Ab TIA Portal Openness V17 wird das Erstellen aus externen Quellen entfernt.

Entfernung von Attribut SyncRole

Vor TIA Portal Openness V17 war das Attribut "SyncRole" für das Gerät IPC627D schreibgeschützt. Ab TIA Portal Openness V17 wird das Attribut "SyncRole" von Geräten entfernt, wo das Attribut keinen Zweck erfüllt.

Geändertes Verhalten von Safety Compile

Vor TIA Portal Openness V17 wird Failsafe mit einem festgelegten Passwort und ohne angemeldeten Benutzer nicht unterstützt und gibt einen Übersetzungsfehler zurück. Ab TIA Portal Openness V17 ändert sich dies und statt eines Übersetzungsfehlers wird eine Ausnahme zurückgegeben.

Entfernung der Ladekonfiguration

Ab TIA Portal Openness V17 sind STEP 7-spezifische Ladekonfigurationen nicht mehr in TIA Portal Openness verfügbar, wenn STEP 7 nicht installiert ist.

Einschränkung beim Attribut "SecondaryType" beim Import von OB MC-Transformation

Bei TIA Portal Openness V17 muss beim Import des OB MC-Transformation das Attribut "SecondaryType" den exakten Zeichenkettenwert "Transformation" haben (das ist auch der Wert, der exportiert wird).

ProDiag-Informationen exportieren

Ab TIA Portal Openness V17 können Sie ProDiag-Meldungen mit einem ProDiag-FB über die öffentliche Openness API in das CSV-Format exportieren.

Die Ausgabe kann in Microsoft Excel angesehen werden.

Änderungen im Verhalten der Methoden ExportInstanceTextsToXlsx und ExportToXlsx in PlcAlarmTextProvider

Vor TIA Portal Openness V17 wird die Datei beim Exportieren überschrieben, wenn sie (als Pfadparameter) bereits existiert. Ab TIA Portal Openness V17 ändert sich dies und dem Benutzer wird eine Ausnahme UserException ausgelöst, wenn die Datei (als Pfadparameter) bereits existiert.

Änderungen im Verhalten der Export API für die Übernahme eines spezifischen Pfads

Vor TIA Portal Openness V17 sind spezifische Pfade in der Export API nicht erlaubt.  Wenn ein spezifischer Pfad angegeben wird, wird die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException ausgelöst.

Ab TIA Portal Openness V17 ändert sich dies und spezifische Pfade werden erlaubt.

In den folgenden Fällen erlaubt TIA Portal Openness API einen spezifischen Pfad.

Eingangspfad

TIA Portal Openness V17

D:SampleDirectory\Sample

Es wird keine Ausnahme ausgelöst

D:\SampleDirectory/Sample

Es wird keine Ausnahme ausgelöst

D:\SampleDirectory\Sample

Es wird keine Ausnahme ausgelöst

D:\\SampleDirectory\Sample

Es wird keine Ausnahme ausgelöst

D:\\\SampleDirectory\Sample

Es wird keine Ausnahme ausgelöst

D:\\SampleDirectory\\Sample

Es wird keine Ausnahme ausgelöst

D:\\\\\\SampleDirectory\\\Sample

Es wird keine Ausnahme ausgelöst

D:\\SampleDirectory\\\Sample

Es wird keine Ausnahme ausgelöst

\\SampleDirectory\Sample

Es wird keine Ausnahme ausgelöst

\\SampleDirectory\\Sample

Es wird keine Ausnahme ausgelöst

\\\\SampleDirectory\\\\Sample

Es wird keine Ausnahme ausgelöst

\\\\SampleDirectory\\\\Sample

Es wird keine Ausnahme ausgelöst

//SampleDirectory/Sample

Es wird keine Ausnahme ausgelöst

"SampleDirectory"

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

"//SampleDirectory"

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

"D:\SampleDirectory\Sample\..\otherSample"

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

"SampleDirectory\Sample"

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

"..\Sample", "SampleName"

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

"D:\ SampleDirectory\Sample"

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

D:\SampleDirectory\ \Sample

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

D:\SampleDirectory\Sample 

Die Ausnahme EngineeringTargetInvocationDetailException.SpecificPathException wird beim Exportieren von Openness API ausgelöst.

Geänderter Datentyp des Attributs ScreenNumber

Ab der TIA Portal Openness V17 Siemens.Engineering.dll ändert sich der Datentyp des Attributs ScreenNumber von Byte nach UInt16.

Geändertes Verhalten beim CAx-Export/Import

Ab TIA Portal Openness V17 werden die folgenden Änderungen für den CAx-Export/Import vorgenommen:

  • Unterstützung für benutzerspezifische Attribute auf GSD/GSDML-Geräten.

  • Ein Benutzer kann CAx-Daten in Multiuser-Projekten und UMAC-geschützten Projekten austauschen.

  • Unterstützung beim Austausch von CAx-Daten mit normiertem TypeIdentifier. Diese Funktion wird über die CAx-Benutzeroberfläche gesteuert.

  • Die Struktur des PN-PN-Kopplers in einer AML-Datei wurde verändert. Damit sollen interne Strukturunterschiede in den am Austausch beteiligten Tools (TIAP und ECAD-Systeme) verhindert und eine gemeinsame Struktur für den Austausch bereitgestellt werden.

  • Der Export/Import von Plus PC-Stationen wird unterstützt. Anmerkung: Der Austausch mit EPLAN- und anderen Tools funktioniert nicht, da die definierten zusätzlichen Attribute in AR APC nicht definiert sind.

  • Beim Importieren erfolgt eine Benachrichtigung des Benutzers über die Neuzuweisung der Startadresse/Netzwerkadresse, wenn diese sich durch interne Vorgänge in TIA Portal geändert hat. Beispiel: Ausfälle von Subnetz-/Peripheriesystemverbindungen, überlappende Adressen usw. Diese Funktion wird über die Einstellungen der CAx-Benutzeroberfläche gesteuert.

  • Benachrichtigung mit einer Warnmeldung für den Benutzer, wenn dieser eine AML-Datei mit OMS und PLCs mit aktivierter Sicherheit importiert.

  • Ein neues Attribut 'ProfinetDeviceName' für alle Ethernet-Teilnehmer wird eingeführt.

  • Ein Gerät mit steckbarem Profinet/Profibus Schnittstellen-Geräteelement wird immer mit getrennten Rollen exportiert. Ein steckbares Schnittstellen-Geräteelement im TIA-Projekt wird als steckbares Geräteelement mit der Rolle DeviceItem exportiert (mit einem 'neuen' untergeordneten Geräteelement mit der Rolle CommunicationInterface). Der Import älterer AML-Dateien muss jedoch immer unterstützt werden.

  • Unterstützung eines toleranteren Imports der Startadresse (unabhängig von der IoType-Reihenfolge in DeviceItem).

  • Der Import kompakter Module mit Hilfe von ‘TemplateReference’ wird mit einigen Einschränkungen unterstützt.

Unterstützung für Bausteine der neuen Programmiersprache CEM

Mit TIA Portal Openness V17 wurde die neue Programmiersprache CEM (Cause Effect Matrix) eingeführt. Wenn Sie auf eine Instanz eines solchen Bausteins treffen, löst der Zugriff auf das Attribut zur Programmiersprache in jeder Siemens.Engineering.dll < V17 eine Ausnahme aus. Bei Engineering.dll V17 wird die richtige Programmiersprache ausgegeben. Bausteine der Programmiersprache CEM unterstützen nicht die Exportmethode irgendeiner Siemens.Engineering.dll.

Unterstützung der neuen Bibliothekstypen "Unified Faceplate" und "Unified Graphic"

Mit TIA Portal Openness V17 wurden die neuen Bibliothekstypen "Unified Faceplate" und "Unified Graphic" eingeführt. Diese Typen werden in Openness nicht unterstützt. Wenn Sie auf Instanzen dieser Typen treffen, lösen alle Siemens.Engineering.dll eine Ausnahme aus.