TIA Codegenerierung mit TIA Openness V15

[Shatex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich befasse mich mit meiner Abschlussarbeit mit einer Schnittstellenprogrammierung, die Elemente aus EPLAN nach TIA pflegt, sowie rückwirkend von TIA nach EPLAN mithilfe der TIA Openness Schnittstelle. Außerdem soll es möglich sein, die Anlage über die Software vorzukonfigurieren und sich alle benötigten Anlagenteile erstellen zu lassen. Ziel soll es sein, Anlagen die sich immer wieder ähneln mit vordefinierten Bausteinen mit TIA Openness zu erzeugen, sozusagen ein Grundgerüst, damit für die wirklich wichtigen Details der spezifischen Anlage mehr Zeit zur Verfügung steht. Als theoretischen Ansatz soll danach noch analysiert werden, wie sich automatisch Code generieren lässt, anhand des SCT-Verfahrens (https://en.wikipedia.org/wiki/Supervisory_control_theory) Wenn alles so realisierbar ist wie ich mir das vorstelle, kann mit dem geschrieben Programm später per Klick die Anlagenhierarchie von EPLAN importiert werden, im eigens geschriebenen Programm erweitert/geändert werden und anschließend im TIA erzeugt werden. Die Bausteine liegen im TIA vorprogrammiert in der Bibliothek.

Den Standardaustausch via AutomationML Datei zwischen EPLAN und TIA gibt es ja schon, dieser ist mir vom Umfang her aber zu wenig. Hierzu sind mir aber noch einige Dinge unklar und ich würde gern generell eure Meinung dazu hören. Der Export nach Excel bzw XML Datei gelingt mir von EPLAN aus. In der Datei stehen alle verwendeten SPS Komponenten samt Artikelnummer, E/A-Variablen und nach Bedarf noch mehr Informationen.

Für den Anfang wäre für mich jetzt erstmal die Frage, wie ich die Zuordnung zwischen der später konfigurierten Anlage im C# Programm via TIA Openness mit der Bausteinbibliothek verknüpfe. Nimmt man hier eine eindeutige GUID und vergleicht die erzeugte mit der hinterlegten in der TIA Bibliothek oder wie würdet ihr es vom Konzept her umsetzen?

Wenn ich z.B. einen Transportband habe, besteht dieses unter anderem aus Sensoren und Motor (technische Einheit), der Logikbausteine (logische Einheit) und wenn man beide kombiniert, als Teilanlage im TIA. Kann ich diesem Template jetzt eine ID zuweisen und es später heraus mit Openness "aufrufen"?

Für weitere Ideen und Vorschläge wie man am besten an dieses Thema herangeht wäre ich euch dankbar! Vielen Dank erstmal!

Grüße

 

[ducati]

Nunja...

den Ansatz der automatischen Codegenerierung für die SPS gibt es ja schon lange und wurde von verschiedenen Unternehmen mit mehr oder weniger Aufwand mehr oder weniger erfolgreich praktiziert.

Der Teufel steckt an der Stelle immer im Details und scheitert oft an der Praxis

Generell bedeutet dies erstmal eine Standardisierung der zu verwendenden Feldgeräte, der EPLAN-Makros und der SPS-Bibliothek und u.U. der Visualisierungsbibliothek. (als banales Beispiel, ein Sensor hat jetzt auf einmal nicht nur nen 4...20mA Signal sondern auch noch ne Meldung Sicherungsfall sowie nen Signal Gerätefehler. Das muss jetzt auch die SPS-Bibliothek unterstützen, sonst wird das nichts. Oder der Anlagenbauer/Endkunde darf halt nur 2-Draht-Messumformer ohne den Schnickschnack verbauen). Damit steht und fällt das ganze Vorhaben!

Den Rückimport zum EPLAN kann ich mir grad garnicht vorstellen, wie sowas in der Praxis funktionieren soll.

Also unabhängig, wie man die Geschichte jetzt umgesetzt bekommt, wichtig ist, die Praxis, d.h. den späteren Anwender nicht aus dem Blick zu verlieren. Als Student hast Du da sicherlich nicht die notwendige Erfahrung.

Weiterhin ist die Zeitersparnis durch die automatische Codegenerierung auch nicht so hoch wie man auf den ersten Blick vermuten würde. Bei Standardanlagen tippe ich meinen Code nämlich auch nicht Zeile für Zeile neu ein, sondern kopiere das von nem ähnlichen Projekt,genauso wie der EPLANER das auch macht. Grad im TIA geht auch viel über Excell, so dass man sich ewige Tipporgien eigentlich eh schon spart. . Wenn man jetzt die Zeit für Erstellung und Pflege des Codegenerators gegenrechnet, bleibt da nicht so viel übrig.

Der Codegenerator benötigt gerade für TIA ständig Anpassungen und Erweiterungen, da sich am TIA-Portal ständig was ändert...

Zum TIA-Openness gibts hier ja schon einige Threads, meist mit ernüchterndem Inhalt...


Trotzdem viel Erfolg mit der Abschlussarbeit

 

[Shatex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Siemens beschreibt seine Openness Lösung in Kooperation mit der Firma Bühler ( https://www.all-electronics.de/auto...ben-bei-der-sps-programmierung-im-tia-portal/ ) als ziemlich mächtig, müssen sie ja auch. Dieser Ansatz soll unteranderem in meiner Arbeit aufgefasst werden, und wie du schon gesagt hast, auch kritisch hinterfragt bezüglich Projektierungsvorteil (Zeit, Kosten etc).

Die ganze Thematik scheint für mich, zumindest bis jetzt (ohne wirklich viel Praxiserfahrung aufweisen zu können) sehr praktikabel, bei sich oft wiederholenden Anlagen(-teilen). Da ich aber leider kein großer Programmierer bin, fehlt mir etwas der Ansatz zur Umsetzung.

Im EPLAN Preplanning kann ich mir eine Anlagenhierarchie anlegen, diese bekomme ich auch als Excel/XML exportiert mit Herstellernummern, Beschriftungen, E/As. Im TIA hab ich mich etwas in die Openness Schnittstelle eingearbeitet, sprich via C# Projekte anlegen, Objekte wie eine SPS einfügen, Kompilieren. Die Thematik mit AutomationML finde ich auch interessant, da man im Zuge des Projekts die Daten speichern und verwalten kann, das macht die Arbeit vielleicht auch für andere Programme/Hersteller interessant, da durch das AML Format herstellerunabhängig Daten ausgetauscht werden können.

Wie würdet ihr jetzt vorgehen? Erstmal Richtlinien aufstellen für standardisierte Feldgeräte und co? Ich muss ja irgendwie die Verknüpfung herstellen zwischen meinem "Klick" im Programm und dem darauffolgenden Erstellen der benötigten Bausteine in der TIA Bibliothek. Später sollen auch Änderunen im TIA rückwirkend in der SPS Konfiguration in EPLAN aktualisiert werden. Ich bin leider zum jetztigen Zeitpunkt noch etwas unschlüssig darüber, wie ich am besten vorgehe soll. An dieser Stelle nehme ich natürlich auch gern weitern Input an um sich einzuarbeiten. Vielen Dank!

Grüße

 

[Jochen Kühner]

Wir machen das ganze bei uns nur one way. D.h. wir erstellen nur einmal Code, übernehmen aber nix zurück!

Wir haben auch unsere ganzen Bausteine in einem Standartprojekt (welches wir wiederum als export in git haben), und erzeugen nur bestimmte Bausteine!

 

[Shatex]

Danke für die Beschreibung, ich versuche mich z.Z an den Basic Funktionen von Openness. Sobald ich etwas vorzuweisen habe, melde ich mich wieder! Grüße

 

[vollmi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir machen das ganze bei uns nur one way. D.h. wir erstellen nur einmal Code, übernehmen aber nix zurück!

Same here. Allerdings wird alles was generiert wird auch wirklich nur in der Ursprungsdatenbank geändert und dann neu generiert. Am generierten Code wird nix geändert, auch nix provisorisch.
Das macht bei 2000 Verkehrssignalen durchaus Sinn. Die Fehlerquelle wird halt immer kleiner je Kompakter alles zusammengefasst ist.
In der Datenbank wird z.B. das Signal definiert in derselben zeile stehen dann Rack, slot und Pin der entsprechenden Ausgänge. Somit muss im Programm keiner stumpf die IOs an die FBs anschliessen. Ausserdem ist es in der DB einfacher zu erkennen wenn durch einen Tipfehler z.B. ein Ausgang doppelt belegt wurde.

Wir nutzen aber noch garkein Openess. Wir gehen noch komplett den herkömmlichen Weg über Quellen. Was auch heisst, alles was generiert wurde muss beim runterladen auch reinitialisiert werden, völlig egal ob sich da überhaupt was geändert hat.

Ist das wenn man über Openess z.b. einen DB verändert nicht so?

mfG René

 

[Shatex]

Bis zu welchem Detailgrad importiert ihr nach TIA? Nutzt ihr die Basisfunktion für den Export von EPLAN nach TIA via .AutomationML File? SPS Daten exportieren (EPLAN) und der Import ins TIA (CAx Daten importieren) funktioniert mit EPLAN P8 2.7.3 und TIA Portal V15 (aktuelles Update) auch ohne Openness ganz gut. Importiert ins TIA werden alle SPS Geräte, Steckplatz- und Baugruppennummern, die Netzsicht wird erstellt mit allen Verbindungen sowie IP Adressen (PN/IE), alle E/A Variablen wurden kopiert. In wie weit würdet Ihr hier mehr ins Detail gehen?

Ich denke für das geplante Ziel, Anlagen im eigenen C# Programm vorzukonfigurieren führt keim Weg an Openness vorbei. Die Frage die ich mir stelle, ist in wie weit mach es Sinn die Anlage extern zu konfigurieren, und was macht man besser direkt im TIA Portal.

Zurückzugreifen auf eine Ursprungsdatenbank macht Sinn, jetzt muss ich mal schauen in wie weit man gewisse gleichbleibende Anlagenteile am Besten kapselt.

Ist das wenn man über Openess z.b. einen DB verändert nicht so?

Zum jetzigen Zeitpunkt kann ich dir leider keine Auskunft geben. Anbei ein Video, welches die Basisfunktionen im Zusammenhang mit Openness zeigt:

https://www.youtube.com/watch?v=Ki12pLbEcxs



Grüße

 

[ducati]

Also was mir zu dem Thema noch einfällt, bei uns ist es in ca. 30-50% der Anlagen so, dass SPS-Programm und E-Plan von 2 verschiedenen Leuten mehr oder weniger parallel bearbeitet wird. Also auf Basis einer Excel-Komponentenliste und einer Excel-EA-Liste erstellt der Eplaner seinen Schaltplan und der Programmierer seine SPS-Software. Das ganze hat vor allem terminliche Gründe.
Von daher würde ich ne automatische Codegenerierung nicht auf nem EPlan export aufbauen, sondern auf einer separaten Liste/Datenbank. Also basierend auf einer Excel-Liste wird erstens das EPLAN Grundgerüst generiert und zweitens das SPS-Grundgerüst... Aber was dort wirklich Sinn macht bzw. praktikabel ist, hängt stark vom Einzelfall ab.

Gruß.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir nutzen aber noch garkein Openess. Wir gehen noch komplett den herkömmlichen Weg über Quellen.

So viel, wie sich beim Openess ständig ändert, ist der Weg über Quellen sicherlich der sicherere Weg. Da ist zumindest mal im ersten Ansatz zu vermuten, dass sich zwischen TIA V17 und TIA V18 an den Quellen weniger ändert... Aber prüfen muss man den generierten Code so oder so ausgiebig...

 

[Jochen Kühner]

So viel, wie sich beim Openess ständig ändert, ist der Weg über Quellen sicherlich der sicherere Weg. Da ist zumindest mal im ersten Ansatz zu vermuten, dass sich zwischen TIA V17 und TIA V18 an den Quellen weniger ändert... Aber prüfen muss man den generierten Code so oder so ausgiebig...

Wir generieren halt KOP/FUP das geht nicht mit Quellen!

 

[Shatex]

Hallo,

mittlerweile hab ich den kompletten Import der Hardwaredaten realisiert. Sprich es werden alle Geräte die TIA Portal existieren und steuerbar sind aus dem EPLAN Preplanning importiert und erstellt. Das ganze klappt auch mit den E/A-Daten der jeweiligen Geräte.

Jetzt würde ich gern den verschiedenen Förderern, nehmen wir an es gibt Typ A,B und C, Logik Templates zuweisen, sprich wenn ich ja weiß ich hab einen Förderer vom Typ A, dass ich mir via Bausteinimport (Format XML) die FBs,DB erzeuge und im besten Fall gleich im Main OB den Aufruf des FBs habe. Ist das die richtige Vorgehensweise? Ich müsste ja den vorhandenen Main OB bei jeder Änderung nach XML exportieren, dort mit meinem Programm bearbeiten und dann wieder ins TIA importieren, oder? Habe das Beispiel von SIemens " TIA Portal Openness Generierung einer modularen Maschine mit S7-1500" angeschaut, da wird auch mit XML Baustein import gearbeitet. Aber der Main OB lässt sich dort zwar importieren, aber zumindest mit meinem Programm, nicht exportieren (Fehlermeldung: Inconsistent blocks and PLC data types (UDT) cannot be exported).

Ich hab auch etwas über "Optionhandling" gelesen, aber dies erfordert den maximalen Ausbau der Anlage, der ist sozusagen ja unbekannt. Im späteren Verlauf würde ich noch gern die Möglichkeit realisieren über mein Programm auch A,B,C Förderer zu generieren (zusätzlich zu den EPLAN Daten).

Also was mir zu dem Thema noch einfällt, bei uns ist es in ca. 30-50% der Anlagen so, dass SPS-Programm und E-Plan von 2 verschiedenen Leuten mehr oder weniger parallel bearbeitet wird. Also auf Basis einer Excel-Komponentenliste und einer Excel-EA-Liste erstellt der Eplaner seinen Schaltplan und der Programmierer seine SPS-Software. Das ganze hat vor allem terminliche Gründe.
Von daher würde ich ne automatische Codegenerierung nicht auf nem EPlan export aufbauen, sondern auf einer separaten Liste/Datenbank. Also basierend auf einer Excel-Liste wird erstens das EPLAN Grundgerüst generiert und zweitens das SPS-Grundgerüst... Aber was dort wirklich Sinn macht bzw. praktikabel ist, hängt stark vom Einzelfall ab.

Gruß.

Der Exort aus Preplanning (Achtung ist ja noch ein Schritt vor dem normalen EPLAN) erfolgt als XML/Excel. Hierzu kann man Vorlagen erstellen, in welche das Preplanning hinein exportiert. Diese Vorlage kann man aber auch selbst mit Daten bestücken, d.h. streng genommen ists egal ob die Daten via Preplanning oder eigener Excel Tabelle vorliegen (solange man sich an gewisse Regeln beim manuellen einfügen von Daten hält)

Nachtrag:

Habe auch etwas zu Masterkopien gelesen, anscheinend kann man auch ein Objekt (PLC Baustein) aus einer Masterkopie mit

project.Devices.CreateFrom()

erzeugen. Man könnte ja auch über Masterkopien die Bausteine erzeugen, letztlich kann die Implementierung des Bausteins im Main OB bzw für die Strukturierung in anderen FBs generiert werden, sprich:

1. Aufrufe der FBs mit Instanz DBs via XML Veränderung
2. Die Erstellung der dazugehörigen Logigbausteine und DBs via Masterkopien

Die Frage ist wahrscheinlich auch die Datenhaltung. Wenn ich alles per XML mache setzt das auch voraus das jeder der damit arbeitet alle XML Bausteine besitzt. Könnte man evt über eine Datenbank Abfrage machen? Oder wird es da schon zu komplex?

Danke!

 

[Hans]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bezüglich des Exportes "Fehlermeldung: Inconsistent blocks and PLC data types (UDT) cannot be exported" --> Du musst vorher kompilieren. Zum Rest kann ich nichts sagen.

 

[Shatex]

Hallo,

wollte eine kurze Rückmeldung geben.

Aktuell ist es mir möglich, anhand eines Export via XML/Excel aus EPLAN Preplanning, alle vorhandenen Geräte anhand einer Logik zu erkennen, anschließend mit TIA Openness zu generieren , die Logikbausteine(vorher angelegt) aufzurufen und in einem weiterem FC zu instanzieren. Das ganze ist ein Mix aus fertigen Bausteinen gespeichert in einer TIA Bibliothek, XML Bausteinen als Muster und eine große Menge an C# Code. Alle Daten aus dem EPLAN Preplanning werden in einem Datenbaustein gespeichert, wo alle generierten Geräte als UDT vorliegen. Diesen UDT gebe ich jedem Logikbausteinaufruf als Eingang. Das ganze lässt sich natürlich noch beliebig ergänzen. Hier ein Beispiel, ein generiertes Netzwerk mit Bausteinaufruf:



Programmbausteingenerierung:





Als Vorlage dient dabei ein leeres Projekt, welches dann "gefüttert" wird durch mein eigenes Programm.

Das Ergebnis ist aber letztlich ein Generierung aller (Logik: soweit in meiner Datenbank vorhanden, Gerät: im TIA HW Katalog vorhanden) Geräte samt benötigten Logikbausteine, InstantzDBs und Variablentabellen. Ich vergebene eigene GUIDs die sich mit EPLAN Preplanning abgleichen lassen. Am Ende gibt es per .txt-File eine Auswertung über den Importprozess mit Auflistung von Fehlern etc. Soweit erstmal der Stand. Jetzt geht es weiter mit der automatischen Visualierung mit Siemens Sivarc.

Grüße

 

[Hans]

Jetzt geht es weiter mit der automatischen Visualierung mit Siemens Sivarc.
Grüße

Da wirst du V15.1 brauchen. Soweit ich weiß kann die Generierung per Openness erst seit V15.1 angestoßen werden.

 

[Shatex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, das stimmt. Da muss man einfach bis dahin nochmal die Maus schwingen und als Vorlagenprojekt dient ein Projekt wo das ganze Sivarc Zeug schon projektiert ist. Das müsste ja funktionieren oder?

 

[Jochen Kühner]

Also man braucht nicht unbedingt Sivarc um Bilder zu erstellen.

Wir haben einen Grafischen Technologieschemaeditor , in dem man Plätze und Bewegungen einzeichnet. Daraus erzeugen wir dann KOP & SCL Bausteine für die S7-1500.
Aber genauso erzeugen wir einfach XML Quellen von Bildern welche wir dann importieren.

 

[Jochen Kühner]

Als Tip noch, wir verwenden z.B. T4-Templates für den zu erzeugenden Code. Damit kann man sehr schön fixe Bestandteile mit Variablen mischen.
Nun für die KOP Code Generierung muss man sich eine Abstraktion schaffen, wenn man auch komplexerer Verknüpfungen dynamisch erzeugen will!

 

[gotscho]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

der letzte Eintrag ist schon eine her...ich versuch das mal wieder aufzugreifen.
Ich habe mich auch bei meinem letzten Arbeitgeber der Entwicklung eines Softwarestandards und darauf aufgesetzt einem Codegenerator für die SPS über TIA.Openess gewidmet.

Leider, wie ich hier auch schon gelesen habe wurde das Projekt als zu pflege-intensiv eingestuft und eingestampft. Das aber momentan ein E-Konstrukteur / Sofwareler mind. 3 Wochen pro Anlage für Vorbereitungen und "abtippselarbeit" vergeudet und dieser Aufwand auf wenige Stunden hätte reduziert werden können wollte keiner einsehen.

Die Projekt-Durchlaufzeit und die Qualität von Schaltplan und Software wäre sicherlich deutlich besser geworden...

Wir hatten dort das E-CAD ELTime im Einsatz. Sehr rudimentär im vergleich zu EPlan, aber immerhin mit einem Schaltplangenerator ausgestattet den ich auch noch gleich angebunden habe.

Somit konnte ich aus einer Excel-Datei (Export aus der mech. Konstruktion) Schaltplan und SPS Software auf Knopfdruck erzeugen. Also durchaus sinnvoll, aber leider verkannt. Auch bei Kollegen hatte ich teilweise den Ruf ihre Arbeitsplätze wegrationalisieren zu wollen :smile:

Ich habe mein Tool in das von Siemens zur Verfügung gestellte TIA Openess Demo integriert. Wen's interessiert, aus Youtube gibt's ein Bildschirmvideo von einer frühen, etwas rudimentären Version:

https://www.youtube.com/watch?v=f43TARWnrlk

Wer ist denn aktuell auch an solchen Themen dran?
Hallo zusammen,

der letzte Eintrag ist schon eine her...ich versuch das mal wieder aufzugreifen.
Ich habe mich auch bei meinem letzten Arbeitgeber der Entwicklung eines Softwarestandards und darauf aufgesetzt einem Codegenerator für die SPS über TIA.Openess gewidmet.

Leider, wie ich hier auch schon gelesen habe wurde das Projekt als zu pflege-intensiv eingestuft und eingestampft. Das aber momentan ein E-Konstrukteur / Sofwareler mind. 3 Wochen pro Anlage für Vorbereitungen und "abtippselarbeit" vergeudet und dieser Aufwand auf wenige Stunden hätte reduziert werden können wollte keiner einsehen.

Die Projekt-Durchlaufzeit und die Qualität von Schaltplan und Software wäre sicherlich deutlich besser geworden...

Wir hatten dort das E-CAD ELTime im Einsatz. Sehr rudimentär im vergleich zu EPlan, aber immerhin mit einem Schaltplangenerator ausgestattet den ich auch noch gleich angebunden habe.

Somit konnte ich aus einer Excel-Datei (Export aus der mech. Konstruktion) Schaltplan und SPS Software auf Knopfdruck erzeugen. Also durchaus sinnvoll, aber leider verkannt. Auch bei Kollegen hatte ich teilweise den Ruf ihre Arbeitsplätze wegrationalisieren zu wollen :smile:

Ich habe mein Tool in das von Siemens zur Verfügung gestellte TIA Openess Demo integriert. Wen's interessiert, aus Youtube gibt's ein Bildschirmvideo von einer frühen, etwas rudimentären Version:

https://www.youtube.com/watch?v=f43TARWnrlk

Wer ist denn aktuell auch an solchen Themen dran?

 

[Jochen Kühner]

Wir haben eine Codegenerierung für unsere Projekte und nutzen das ganze sehr erfolgreich.
Es steckt jedoch einiges an Arbeit darin. Wie gesagt, vor allem KOP/FUP ist einfach aufwendig und hat bei uns einiges an zeit gekostet dafür eine einfach zu nutzende Abstraktion zu schreiben.

 

[fabian.za]

Es gibt mittlerweile ein Framework von Siemens, dass sich Modular Application Creator nennt. Dieses Framework bietet folgende Vorteile ggü. einer eigenen Opennessapplikation:

• dynamische XML-Manipulation und damit Erstellung von KOP/FUP Aufrufen
• handelt die Änderungen der Opennessschnittstelle
• Komfortfunktionen für die Generierung von Technologieobjekten und deren Einstellungen
• einfache Verschaltung von Technologieobjekten mit Drive Objekten
• Möglichkeit der UI-Erstellung inkl. Validierungsfunktionen