- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Und woher weiß ich das wenn ich in den Programm reinschauen würde, dass die HMI genau auf diesen DB schreibt?
Vermeiden von Globaldaten
- Ersteller miasma
- Erstellt am
-> Hier kostenlos registrieren
MSB
Level-3
- Beiträge
- 7.191
- Reaktionspunkte
- 1.651
Ich würds mal anders rum formulieren, welchen Vorteil habe ich wenn ich das ganze in den IDB packe?
Ich weiß noch weniger auf den ersten Blick "wo" das HMI überall rumpfuscht.
Wenn ich am FB was ändere, MUSS ich zu einer vergleichsweise großen Wahrscheinlichkeit die Visu(s) auch ändern bzw. neu übersetzen und laden.
Sollte ich irgendwelche spezifischen Parameter haben, z.B. Zeiten für die Laufzeitüberwachung, Betriebsstunden etc. muss ich den kompletten IDB vorher sichern,
obwohl ich an Sachen die die Visu eigentlich beträfen gar nichts geändert habe.
Kurzum, ich bau noch ein paar Abhängigkeiten mehr mit ein, die man bei einer Änderung "bedenken" muss.
Der Gerechtigkeit wegen muss man aber sagen, das Siemens selbst das ganze auch eher so handhabt mit Visu oder ähnlichem im IDB rumzuschreiben.
Mfg
Manuel
Ich weiß noch weniger auf den ersten Blick "wo" das HMI überall rumpfuscht.
Wenn ich am FB was ändere, MUSS ich zu einer vergleichsweise großen Wahrscheinlichkeit die Visu(s) auch ändern bzw. neu übersetzen und laden.
Sollte ich irgendwelche spezifischen Parameter haben, z.B. Zeiten für die Laufzeitüberwachung, Betriebsstunden etc. muss ich den kompletten IDB vorher sichern,
obwohl ich an Sachen die die Visu eigentlich beträfen gar nichts geändert habe.
Kurzum, ich bau noch ein paar Abhängigkeiten mehr mit ein, die man bei einer Änderung "bedenken" muss.
Der Gerechtigkeit wegen muss man aber sagen, das Siemens selbst das ganze auch eher so handhabt mit Visu oder ähnlichem im IDB rumzuschreiben.
Mfg
Manuel
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Es macht die Bausteinschnittstelle schlanker. Außerdem gibt es nur eine Stelle die alle Daten für beispielsweise Antriebsbausteine hält, nämlich der Datenbereich dem dieser Antrieb zugehört (Instanz-DB).
Aber das ist eine philosophische Frage, ob die Daten der HMI einen HMI-Bereich gehören, oder ob alles was zu einem Antrieb dazugehört (und wenn eine HMI-Bedienung gewünscht ist, ist diese im Antriebs-FB auch programmiert) auch in die Daten des Antriebs gehören.
Wenn man das Prinzip mit den Zugriffen auf Instanz-DBs verstanden hat weiß man es aber auch. Bei den Global-DB Leuten gilt es auch darauf zu vertrauen dass in der Visu wirklich nur auf den einen DB geschrieben wird, man sieht es ja nicht.
Wenn man den Global DB ändern muss hat man aber das gleiche Problem. Wenn man die Schnittstelle erweitern muss und man nicht unendlich Reserven vorgesehen hat verschieben sich alle Adressen, und man hat bei beiden Vorgehensweisen das gleiche Problem, nämlich dass die Visu komplett angepasst werden muss.
Bei der Instanz-DB Variante habe ich sogar den Vorteil, dass wenn ich nur einen Typ (z.B. Motor mit FU) ändere, ich nur diese Adressen anpassen muss. Bei den Global-DBs verschiebt sich unter Umständen alles.
Außerdem ist das mit den Adressen ein Siemens spezifisches Problem. Wenn man über Namen auf Variablen zugreifen könnte wäre das ganze Problem hinfällig.
Ich sehe es so: beide Varianten haben Vor- und Nachteile. Wenn die Variante mit den Global DBs aber die "einzig wahre" ist so wie es einige hier verkaufen möchten, müssten die Argumente hierfür einen doch geradezu erschlagen. Das sehe ich aber bisher nicht. Aber vielleicht kommt das Killer-Argument ja noch...
- Beiträge
- 16.444
- Reaktionspunkte
- 6.044
Um diesen Umstand zu umgehen nutze ich zb eine Rezeptur, das würde ich selbst bei der Verwendung
eines GDB so machen. Einfach relevante Werte in die Rezeptur, so können diese bei jeder Situation, wieder
hergestellt werden.
Das mache ich grundsätzlich und ist in Fleisch und Blut übergegangen, erst SPS Programm Bausteinkonsitänz
Prüfung durchführen, dann HMI neu generieren, dann alles neu übertragen. Sollte eigentlich immer bei jeder
Änderung gemacht werden, sehe ich auch nicht als Problemm, soviel Aufwand ist das auch nicht.
Ich verstehe schon worauf der TE hinaus will, er möchte einfach alles was zur einer Funtionseinheit gehört
in einen FB packen und nur einen dazugehörigen DB nutzen, den IDB. So besteht für ihn die Möglichkeit
Biblotheken zu erstellen und seine Programme später einfacher zusammen zu klicken.
Die IDB bezwecken eigentlich nicht mehr den eigentlichen Sinn des Instanz DB sondern eher den eines
Global DB's, der im FB verwaltet wird.
Es geht ihn wahrscheinlich weniger darum um zb einen Regelbaustein zu erstellen, der dann in seiner Art
zig mal im Programm mit einer anderen Instanz oder als Multiinstanz aufgerufen wird.
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
Also um es vielleicht noch einmal deutlicher zu machen ich plane es wie folgt.
Die Bereiche IN und OUT des FB werden nur noch mit Peripherieadressen verbunden (E,A,PEW,PAW, etc.).Es sind also nur noch physikalisch wirklich vorhanden Adressen erlaubt.
Dies schließt natürlich auch Merker aus, die habe ich aber eh noch nie benutzt da sie meiner Meinung nach mit Schmierzetteln gleichzusetzen sind.
Den Bereich IN_OUT nutze ich auch nicht da dieser meiner Meinung nach nur Sinnvoll für FC's ist um Daten Über den Zyklus hinaus zu sichern. Quasi dazu dient einen pseudo-FB zu erzeugen. Stichwort Datenablage.
Der Bereich STAT wird aufgegliedert in drei Strukturen.
Die erste Struktur enthält alle Daten mit denen der FB arbeitet. Muss auch nicht zwingend eine Struktur sein.
Die zweite Struktur heißt VISU_OUT hier kommen alle Daten von der Visu an. Auf der Visu gibt es also ein Faceplate mit genau der selben Struktur das genau in diesen Bereich des IDB's schreibt.
Die dritte Struktur heißt VISU_IN hier liest ein weiteres Faceplate die Daten aus dem FB aus bzw. stellt sie da.
Lesen und schreiben sind also strikt getrennt.
Den Bereich TEMP nutze ich eigentlich nie höchstens bei komplexen Berechnungen mit mehreren Zwischenergebnissen. Dürfte mit dem neuen CALCULATE Befehl aus TIA aber auch hinfällig werden.
Da ich nur noch Lokaldaten nutzen will bin ich wie gesagt auf Querverweise nicht angewiesen.
Mir reicht es dann dann Ctrl+Shift+B oder Ctrl+Shift+F ob dann ein Schreibzugriff oder Lesezugriff erfolgt sehe ich dann ja auf den ersten Blick.
Da ich eine extrem strenge Syntax Pflege ergibt sich mein Querverweis zur Visu von selbst.
IDB+POS_NR+Antrieb+Struktur
IDB_4011_CC".VISU_IN.STK
Die Bereiche IN und OUT des FB werden nur noch mit Peripherieadressen verbunden (E,A,PEW,PAW, etc.).Es sind also nur noch physikalisch wirklich vorhanden Adressen erlaubt.
Dies schließt natürlich auch Merker aus, die habe ich aber eh noch nie benutzt da sie meiner Meinung nach mit Schmierzetteln gleichzusetzen sind.
Den Bereich IN_OUT nutze ich auch nicht da dieser meiner Meinung nach nur Sinnvoll für FC's ist um Daten Über den Zyklus hinaus zu sichern. Quasi dazu dient einen pseudo-FB zu erzeugen. Stichwort Datenablage.
Der Bereich STAT wird aufgegliedert in drei Strukturen.
Die erste Struktur enthält alle Daten mit denen der FB arbeitet. Muss auch nicht zwingend eine Struktur sein.
Die zweite Struktur heißt VISU_OUT hier kommen alle Daten von der Visu an. Auf der Visu gibt es also ein Faceplate mit genau der selben Struktur das genau in diesen Bereich des IDB's schreibt.
Die dritte Struktur heißt VISU_IN hier liest ein weiteres Faceplate die Daten aus dem FB aus bzw. stellt sie da.
Lesen und schreiben sind also strikt getrennt.
Den Bereich TEMP nutze ich eigentlich nie höchstens bei komplexen Berechnungen mit mehreren Zwischenergebnissen. Dürfte mit dem neuen CALCULATE Befehl aus TIA aber auch hinfällig werden.
Da ich nur noch Lokaldaten nutzen will bin ich wie gesagt auf Querverweise nicht angewiesen.
Mir reicht es dann dann Ctrl+Shift+B oder Ctrl+Shift+F ob dann ein Schreibzugriff oder Lesezugriff erfolgt sehe ich dann ja auf den ersten Blick.
Da ich eine extrem strenge Syntax Pflege ergibt sich mein Querverweis zur Visu von selbst.
IDB+POS_NR+Antrieb+Struktur
IDB_4011_CC".VISU_IN.STK
Paule
Level-1
- Beiträge
- 3.058
- Reaktionspunkte
- 869
-> Hier kostenlos registrieren
Und das ist doch das Hauptproblem, du kannst einen IDB nicht sichern und wenn dann nur sehr, sehr umständlich und mit erheblichem Aufwand!
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
Dein Verfahren mit VISU_IN und VISU_OUT schließt dann aber zum Beispiel die Verwendung von Textfeldern mit Ein- und Ausgabe aus. Für diese würdest du dann ja VISU_IN_OUT benötigen.
Gruß
Dieter
- Beiträge
- 15.414
- Reaktionspunkte
- 4.043
-> Hier kostenlos registrieren
Geht aber nur bei WinCCFlex, bei WinCC oder InTouch etc. hast du da schon schlechte Karten. Und wehe, ein Kunde will kein WinCCFlex, dann gehts richtig los.
- Beiträge
- 16.444
- Reaktionspunkte
- 6.044
Wie der Kunde will etwas anderes, was soll das den :?:
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Und wenn ich das mit den Daten im FB genauso mache, indem ich die Daten in eine entsprechende Struktur mit passender Symbolik und Kommentar packe?
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
-> Hier kostenlos registrieren
Ich verstehe nicht was du mit einem Textfeld mit EA Funktion meinst.
- Beiträge
- 11.607
- Reaktionspunkte
- 3.866
Wenn du als Visu WinCC (flex) nimmst, dann hast du Testfelder mit Nur-Eingabe, Nur-Ausgabe und Ein-UND-Ausgabe.
Diese zeigen dir den aktuellen Wert der Variable an (Ausgabe) und diesen kannst du dann ändern (Eingabe). Es wird also lesend und schreibend auf die gleiche Variable zugegriffen. Bei WinCC flex. ist dies die Voreinstellung.
Gruß
Dieter
MSB
Level-3
- Beiträge
- 7.191
- Reaktionspunkte
- 1.651
Also alles was von der Visu an den FB kommt habe ich in einem IN_OUT welcher mit einem Stations oder Aggregatsspezifischen UDT versorgt wird,
die etwas komplexere aber erheblich Zykluszeitsparende Variante wäre dann ein Any-Pointer an einem IN-Parameter welcher dann Intern in den STAT-Bereich kopiert wird.
Es gibt von der Visu-Seite definitiv etliche Parameter die gelesen UND geschrieben werden können sollten.
Also ich bin einfach für eins:
Eine ganz klare und weitgehend strikte Trennung aus DATEN und irgendwelchen internen Geschichten wie Timer, Zähler, etc.
Einziger Nachteil:
Ich hab genau einen IN oder IN_OUT Parameter mehr, und muss dann auf viel weniger aufpassen, bei der vergleichbaren Palette an Vorteilen.
Und dafür lohnt der ganze Workflow, den ich bei JEDEM übertragen des IDB bedenken und durchführen muss absolut nicht.
Erheblicher Vorteil:
Die Variante funktioniert mit jedem x-beliebigem VISU und HMI-System, da nicht Siemens Geschichten ja quasi nie oder nur extrem umständlich integriert sind.
Mfg
Manuel
die etwas komplexere aber erheblich Zykluszeitsparende Variante wäre dann ein Any-Pointer an einem IN-Parameter welcher dann Intern in den STAT-Bereich kopiert wird.
Es gibt von der Visu-Seite definitiv etliche Parameter die gelesen UND geschrieben werden können sollten.
Also ich bin einfach für eins:
Eine ganz klare und weitgehend strikte Trennung aus DATEN und irgendwelchen internen Geschichten wie Timer, Zähler, etc.
Einziger Nachteil:
Ich hab genau einen IN oder IN_OUT Parameter mehr, und muss dann auf viel weniger aufpassen, bei der vergleichbaren Palette an Vorteilen.
Und dafür lohnt der ganze Workflow, den ich bei JEDEM übertragen des IDB bedenken und durchführen muss absolut nicht.
Erheblicher Vorteil:
Die Variante funktioniert mit jedem x-beliebigem VISU und HMI-System, da nicht Siemens Geschichten ja quasi nie oder nur extrem umständlich integriert sind.
Mfg
Manuel
Zuletzt bearbeitet:
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
-> Hier kostenlos registrieren
Dann habe ich es doch richtig verstanden.
Aber schreiben und lesen bzw. ein und ausgeben setzt doch kein IN_OUT voraus.
Wenn ich z.B. auf der VISU_IN Seite Parameter übergebe wie Grenzwerte. Nutze ich dafür ein EA Feld.
Die Visu schreibt den Wert und stellt ihn danach da. Der FB liest diesen Wert nur.
Aber ich glaube es liegt eher daran das viele Leute eine verschiedene Auffassung von IN_OUT haben.
Wenn Du in WinFlex ein EA Feld anlegst legst Du also in der Bausteinschnittstelle immer ein IN_OUT dafür fest ?
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
So mache ich es normalerweise auch. Ein Nachteil ist dass wenn auf viele Daten des UDTs zugegriffen wird, der Baustein extrem groß wird, und entsprechend langsam. Für eine kleine Steuerung habe es schonmal gemacht dass ich die Daten auf die gleiche Struktur im Temp-Bereich kopiere, und am Ende wieder zurückschreibe.
Und was wenn die UDT um einen Wert erweitert werden soll? Dann funktioniert nämlich auch kein gesicherter Global-DB.
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
Genau hier liegt eines der Hauptprobleme von Globalen Daten. Kleinste Änderungen haben sehr große Wechselwirkungen auf das Programm im ganzen. Da meistens mehrere Baustein bzw. Antriebe betroffen sind.
MSB
Level-3
- Beiträge
- 7.191
- Reaktionspunkte
- 1.651
-> Hier kostenlos registrieren
Sicherlich, aber den Zeitpunkt und auch die Art und Weise kann ich mir erheblich besser aussuchen als in einem IDB, zumal ich in meinem UDTs meisten noch ca. 50% Platzreserve habe,
muss ich den Global-DB zunächst gar nicht ändern, und kann das auch Tage-Wochen später mal in einer ruhigen Minute machen.
Das Argument ist im Gesamtzusammenhang Käse, weil sich an dem Potentiellen Problem mit deiner IDB Variante auch 0,garnix ändert.miasma schrieb:
Mfg
Manuel
OP
miasma
Level-2
- Beiträge
- 368
- Reaktionspunkte
- 114
- IDB Online Kopieren ins Offline Projekt einfügen unter einer anderen Baustein Nummer.
- Änderung am FB ausführen und mit neuen IDB einspielen.
- Per Blockmove die Daten zurück in den erneuten IDB spielen.
- Falls der neue IDB mittendrin geändert worden ist müssen 2 Blockmoves ausgeführt werden einer bis zum neuen Datenpunkt einer hinter dem neuen Datenpunkt.
MSB
Level-3
- Beiträge
- 7.191
- Reaktionspunkte
- 1.651
1. FB und IDB übertragen
2. Fertig.
Ich halte das zwar für machbar, aber speziell für "fremde" Leute schlicht und einfach unpraktikabel bis gefährlich.
Zumal ich mitleichten NIE davon ausgehen würde, das ich das Prozedere mit einem IDB machen muss.
In meinen Programmen kannst du zu 90% den IDB ohne Nachdenken übertragen, ohne das das die Maschine juckt,
und das trifft auf die meisten mir geläufigen Programme zu.
Mfg
Manuel
2. Fertig.
Ich halte das zwar für machbar, aber speziell für "fremde" Leute schlicht und einfach unpraktikabel bis gefährlich.
Zumal ich mitleichten NIE davon ausgehen würde, das ich das Prozedere mit einem IDB machen muss.
In meinen Programmen kannst du zu 90% den IDB ohne Nachdenken übertragen, ohne das das die Maschine juckt,
und das trifft auf die meisten mir geläufigen Programme zu.
Mfg
Manuel
Similar threads
WinCC Unified
Rezepturverwaltung
