TIA Zeiger auf UDT

[Road Runner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen

Ich möchte für meine Antriebe an der Anlage ein PopUp im WinCC erstellen. Das PopUp soll immer das gleiche sein. Je nachdem, von welchem Antriebssymbol (diese sind auf der Visu verteilt) man es öffnet, stehen die ensprechenden Daten (z.B. Soll- und Ist-Geschwindigkeit) im PopUp zur Verfügung. Ist-Geschwindigkeit wird angezeigt, Sol-Geschwindigkeit soll aber auch verändert werden können.
Ich kann das Ganze so machen, dass ich ein DB mit einem Array meiner Struktur/UDT mache und im WinCC beim Öffnen des PopUp den entsprechenden Array-Index auswähle. Dann funktioniert es grundsätzlich.
Nun suche ich aber nach einer Möglichkeit, um die Struktur bzw. UDT wie in C als Zeiger zu übergeben. So kann ich sowohl Daten lesen als auch schreiben und kann die Daten in mehrere DB's verteilen. Denn da ich sehr viele Antriebe auf der Anlage habe, möchte ich nicht einfach einen grossen DB, sondern mehrere DB's für die verschiedenen Anlagenteile. Die Zuweisung welchen DB und welche Struktur mache ich dann auf der SPS.
Welchen Ansatz habt ihr zu meiner Problemstellung?

Ich hoffe ihr habt die Frage verstanden und bin gespannt auf eure Ansätze...

Gruss
RR

 

[ducati]

welches WinCC?

 

[Road Runner]

Zuviel Werbung?
-> Hier kostenlos registrieren

TIA-Portal V15.1 mit WinCC Advanced V15.1

 

[ducati]

probier mal Adress-Multiplexen

 

[Road Runner]

Danke für den Input. Weisst du wieviel verschiedene Variabeln ich so adressieren kann? Im entsprechenden Dialog sehe ich 9 Felder. Ist danach schluss oder wie weit geht das?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für den Input. Weisst du wieviel verschiedene Variabeln ich so adressieren kann? Im entsprechenden Dialog sehe ich 9 Felder. Ist danach schluss oder wie weit geht das?

Dein Screenshot zeigt "normales" Multiplexen.

Ich mein aber Adress-Multiplexen. Das ist was anderes:

Einleitung

Beim Adress-Multiplexen können Sie mit einer einzigen Variablen eine Vielzahl an Speicherplätzen im Adressbereich der Steuerung ansprechen. Sie können auf die Adressen schreibend und lesend zugreifen, ohne für jede einzelne Adresse eine Variable zu definieren.

Multiplexen mit absoluter Adressierung

Beim Multiplexen mit absoluten Adressen projektieren Sie Variablen als Platzhalter für die anzusprechende Adresse in der Steuerung.

Wenn Sie z. B. auf eine Adresse des Formats "%DBx.DBWy" zugreifen wollen, sieht der Ausdruck für das Multiplexen folgendermaßen aus:

"%DB[HMITag1].DBW[HMITag2]"

Die Variable "HMITag1" versorgen Sie in Runtime mit dem gewünschten Wert für den Datenbaustein, den Sie adressieren wollen.

Die Variable "HMITag2" versorgen Sie in Runtime mit der gewünschten Adresse aus dem Datenbaustein.

Die Versorgung der Variablen geschieht z. B. mithilfe von Werten aus der Steuerung oder über ein Skript.

Das Multiplexen mit absoluten Adressen wird für folgende Steuerungen und Kommunikationstreiber unterstützt.

SIMATIC S7 300/400

SIMATIC S7 1200

SIMATIC S7 1500

Das Multiplexen mit absoluten Adressen steht für Datenbausteine mit optimiertem Zugriff nicht zur Verfügung.

Multiplexen mit symbolischer Adressierung

Beim Multiplexen mit symbolischer Adressierung greifen Sie mithilfe einer Multiplexvariable und einer Indexvariable auf ein Arrayelement einer Arrayvariable in einem Datenbaustein der verbundenen Steuerung zu. Die Multiplexvariable enthält die symbolische Adresse des Datenbausteins, auf den Sie zugreifen wollen. Die symbolische Adresse enthält außerdem die Indexvariable, über die Sie auf den Index der Arrayvariable zugreifen.

Wenn Sie z. B. auf die Arrayvariable "Arraytag_1" im Datenbaustein "Datablock_1" zugreifen wollen, sieht der Ausdruck für die symbolische Adressierung folgendermaßen aus:

"Datablock_1.Arraytag_1["HMITag_1"]

Mit der HMI-Variable "HMITag_1" steuern Sie den Zugriff auf den Index der Arrayelemente. Die Variable versorgen Sie in Runtime mit dem Index des Arrayelements, auf das Sie jeweils zugreifen wollen.

Das Multiplexen mit symbolischer Adressierung ist nur verfügbar, wenn folgende Komponenten die symbolische Adressierung unterstützen:

das HMI-Bediengerät

die Steuerung

der Kommunikationstreiber

Die symbolische Adressierung wird von Kommunikationstreibern unterstützt:

SIMATIC S7-1200

SIMATIC S7-1500

 

[Road Runner]

Aber so müssen alle Struct/UDT im gleichen DB sein oder gibt es eine Möglichkeit dies DB übergreifend zu machen?

 

[ducati]

Aber so müssen alle Struct/UDT im gleichen DB sein oder gibt es eine Möglichkeit dies DB übergreifend zu machen?

nöö, geht auch DB übergreifend:

Wenn Sie z. B. auf eine Adresse des Formats "%DBx.DBWy" zugreifen wollen, sieht der Ausdruck für das Multiplexen folgendermaßen aus:

"%DB[HMITag1].DBW[HMITag2]"

Die Variable "HMITag1" versorgen Sie in Runtime mit dem gewünschten Wert für den Datenbaustein, den Sie adressieren wollen.

Die Variable "HMITag2" versorgen Sie in Runtime mit der gewünschten Adresse aus dem Datenbaustein.

 

[Road Runner]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sorry, hab ich unterschlagen, ich bin symbolisch unterwegs (keine Absoluten Adressen)

 

[de vliegende hollander]

Interessehalber, Um wieviele popup geht es? 10, 20 , 30 stück?
Ich finde das Multiplexen nicht übersichtlich. Für fremden slecht nachvollziehbar. HMI-UDT is eine gute Wahl. Jede popup 1 Adresse. So mach ich es. Die Adresse ist für das Prozessbild und für Popup.

 

[ducati]

Sorry, hab ich unterschlagen, ich bin symbolisch unterwegs (keine Absoluten Adressen)

man kann nicht alles haben. Ich persönlich finde die optimierten DBs Humbug. Von daher weiss ich nicht, was bei optimierten DBs alles nicht geht...

Aber jeder wie er mag. Man kann auch mit nichtoptimierten DBs symbolisch programmieren, sogar mit S7-300...

Gruß.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Interessehalber, Um wieviele popup geht es? 10, 20 , 30 stück?
Ich finde das Multiplexen nicht übersichtlich. Für fremden slecht nachvollziehbar. HMI-UDT is eine gute Wahl. Jede popup 1 Adresse. So mach ich es. Die Adresse ist für das Prozessbild und für Popup.

bei 700 Popups ist das multiplexen übersichtlicher, bei mir zumindest. Und es spart jede Menge Gesamtübersetzungszeit.

Aber die HMI-UDTs brauch ich trotzdem für das Prozessbild, also HMI-Variablen spart man damit nicht. Aber die kosten ja bei Comfort/Advanced auch nix...

 

[Road Runner]

Interessehalber, Um wieviele popup geht es? 10, 20 , 30 stück?
Ich finde das Multiplexen nicht übersichtlich. Für fremden slecht nachvollziehbar. HMI-UDT is eine gute Wahl. Jede popup 1 Adresse. So mach ich es. Die Adresse ist für das Prozessbild und für Popup.

Ich möchte das PopUp eigenltich einmal machen, es soll aber auf ca. 40 Antriebe zugreifen. Somit habe ich die Daten in 40 UDTs verteil, welche ich in verschiedenen DB's haben möchte. 1 DB pro Anlagenteil (Es wird wahrschinlich etwa 8 Anlagenteile geben, somit auch 8 DB's)

 

[ducati]

naja, bei nur 40 würd ich auch 40 Popups erstellen... Da drin dann aber ein "Bildbaustein"

 

[de vliegende hollander]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich möchte das PopUp eigenltich einmal machen, es soll aber auf ca. 40 Antriebe zugreifen. Somit habe ich die Daten in 40 UDTs verteil, welche ich in verschiedenen DB's haben möchte. 1 DB pro Anlagenteil (Es wird wahrschinlich etwa 8 Anlagenteile geben, somit auch 8 DB's)

Wenn du Texte im Bildbaustein hast, musst du die auch übergeben.

 

[Thomas_v2.1]

Wenn ich das richtig in Erinnerung habe, macht Siemens das in einer Bibliothek mit Antriebsbausteinen und Faceplates die sie frei zu Verfügung stellen, mit Multiplexen innerhalb des SPS Programms. Das spart ggf. natürlich auch einige Tags, wenn man die gesamten Parametrierdatendätze nur einmal anlegen muss. Da muss man nur aufpassen, dass man sich nicht verzettelt wenn mal weitere Bedienplätze hinzukommen sollten. Und generell ist das von der Nachvollziehbarkeit nicht so eindeutig wie wenn alles im HMI geschieht.

 

[ducati]

Wenn ich das richtig in Erinnerung habe, macht Siemens das in einer Bibliothek mit Antriebsbausteinen und Faceplates die sie frei zu Verfügung stellen, mit Multiplexen innerhalb des SPS Programms. Das spart ggf. natürlich auch einige Tags, wenn man die gesamten Parametrierdatendätze nur einmal anlegen muss. Da muss man nur aufpassen, dass man sich nicht verzettelt wenn mal weitere Bedienplätze hinzukommen sollten. Und generell ist das von der Nachvollziehbarkeit nicht so eindeutig wie wenn alles im HMI geschieht.

Spätestens, wenn man mehr als 1 HMI-Station hat, wirds aber damit wirklich unübersichtlich...

Ich kenn das Multiplexen in der SPS eigentlich nur von winzigen Anlagen mit Basic-Panel.

Grundsätzlich halte ich nix davon, HMI-Funktionen in die SPS auszulagern.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Spätestens, wenn man mehr als 1 HMI-Station hat, wirds aber damit wirklich unübersichtlich...

Das würde ich so nicht sagen. Mit einem guten Konzept kann man schon viele Standard-Routinen steuerungsseitig multiplexen, ohne Aufwand, ohne großartige Recourcen und sogar gänzlich ohne Fehlermöglichkeit. Ein einziger Bausteinaufruf und schon hat man ein zweites HMI mit allen Bedienmöglichkeiten aller Anlagenteile. Das ist jedenfalls meine Vision .

 

[ThomWag]

Das würde ich so nicht sagen. Mit einem guten Konzept kann man schon viele Standard-Routinen steuerungsseitig multiplexen, ohne Aufwand, ohne großartige Recourcen und sogar gänzlich ohne Fehlermöglichkeit. Ein einziger Bausteinaufruf und schon hat man ein zweites HMI mit allen Bedienmöglichkeiten aller Anlagenteile. Das ist jedenfalls meine Vision .

Ja, da bin deiner Meinung, ich habe diese Vision bereits umgesetzt, Multipanel und im HMI ein Symbol mit einer Adresse und damit alle Bedienungen Betriebsarten, Meldungen und Konfigurationen zu einem Device (Ventil, Motor, Messwert,..). Pro Device Typ sind die Daten in einem DB abgelegt. (Anlagen mit mehr als 1500 Objekten realisiert, eine Beispiel UDT anbei. Auch einen Antriebsbaustein mit Teachen, Joggen, .. ist so realisiert.)
Der Grundsätzliche Gedanke ist folgender: Alle Daten die aus einer Instanz in der Visu benötigt werden liegen nicht in den Instanz-Daten sondern in einer ausgelagerten Datenstruktur. Es ist wie immer Philosophie welcher Weg der besserer ist. Siemens hat ein eine Bibliothek die für WinCC Professional ausgelegt ist die richtig auf die Instanz-Daten zugreifen kann, und bei Verwendung mit WinCC Advance Schaufel sie die Daten für das aktive Objekt um.
Natürlich ist das Argument das so etwas auch schnell unübersichtlich wird nicht ganz von der Hand zu weisen, aber wenn es gut Strukturiert ist inkl. der Objekte, Typen und Bezeichnungen, muss der Programmierer nicht mehr jedes Detail verstehen. Der gesamte Baukasten muss dafür aber vernünftig strukturiert und verwaltet sein. So verwalten wir die Objekte in Excel und generieren eine großen Teil der Umgebung Variablen und Konfigurationsdaten.
Damit wird die Erstellung ins besonderer der Visu deutlich schneller. Fange ich dagegen einfach erstmal an und meine Objekte wachsen ständig während der Erstellung und ich muss dann im Code manuell immer alles anpassen und erweitern und stecke nicht so tief im Konzept wird es auch schnell zur Bremse.
Also mein Fazit die Idee ist gut und Funktional, aber alle beteiligten müssen gewillt sein strukturierter und mit mehr Planung bei der Erstellung zu arbeiten.
Die Aussage "keine HMI Funktionen auf der SPS zu programmieren" kann ich nicht teilen, da in der Regel Bedienbarkeit und Benutzerfreundlichkeit in der Regel mehr Programmieraufwand ist als die reine Automations-Funktionalität und das zu realisieren ohne davon Aufgaben auf der SPS zu realisieren heute unmöglich ist wenn es eine klassische HMI / SPS Lösung ist.
Anbei noch ein Dokument um mal grob das HMI Konzept meiner Bausteine zu sehen. Für technische Details würde ein bisschen mehr Zeit notwendig sein, wäre aber auch möglich.

 

[PN/DP]

Wie bekommt man mehrere unabhängig funktionierende HMI realisiert, wenn das Multiplexen der Objekte in der SPS-CPU gemacht wird??

Harald