# Vermeiden von Globaldaten



## miasma (1 September 2012)

Hallo, 

ich beschäftige mich gerade konzeptionell mit der Umstellung meiner eigenen Programmierweise. 
Ziel ist es Modulare Bausteine zu entwickeln die einfach wiederverwendet werden können.Ihre Daten sollen über eine Strukturschnittstelle (ein und ausgangsseitig) an die HMI, an ein Faceplate übergeben  bzw. gelesen werden.

Mir schwebt wirklich vor vollkommen auf Globale Daten zu verzichten um möglichst keine Probleme beim wiederverwenden zu bekommen. 

Hintergrund ist folgender. Ich möchte gerne das die Bausteine im Aufruf eine schlanke Schnittstelle haben. Im Grunde genommen sollen nur noch Daten aus der Peripherie in der Schnittstelle adressiert werden.Gerade auf der IN Seite der Schnittstelle werden meiner Meinung nach Bausteine oftmals mit überflüssigen Daten versorgt die genauso gut intern erzeugt werden können oder als Struktur anstelle von Einzeldaten übergeben werden können.

*Intern erzeugt werden können:*

Taktbits
Logisch 0 & 1
Timer Nummern
etc.
*Strukturen sollen Einzeldaten ersetzen wie:*

Eingangsvariablen die eine Skalierung beschreiben. HiLim, LoLim, ZA++, A+, A-, ZA--, Ersatzwert etc. Da man die Struktur sowieso nicht beobachten kann sollen Daten dieser Art aus der Visu direkt in einen Struktur in den STAT Bereich eines FB's übergeben werden.
Ausgangsvariablen wie z.b Rohwert, Skalierter Wert und Normsignal.
etc.
Sicherlich ist das hier nur eine sehr grobe Beschreibung meiner Vorstellung. Aber mich würde es interessieren wie IHR einen solchen Ansatz bewertet.

Gibt es hier Leute die so arbeiten und von Vorteilen und Nachteilen berichten können ? Oder Leute die einen solchen Ansatz im allgemeinen begründet mit Nachteilen ablehnen ?


----------



## Blockmove (1 September 2012)

Ich persönlich bin kein Freund des vollkommenen Verzichts auf Globaldaten.
Bei der Fehlersuche musst du dich durch die ganze Aufrufhierachie hangeln. Querverweis bzw. "Gehe zu Verwendungstelle" funktionieren nicht.
Ich verwende Stationsbezogene Global-DB mit Strukturen.

Gruß
Dieter


----------



## miasma (1 September 2012)

Aber beobachten mit Aufrufpfad und Ctrl+Shift+F und Ctrl+Shift+B (lokale Verwendungsstelle) funktionieren doch um zur nächsten bzw. vorherigen Verwendungsstelle zu springen.

Ein Querverweis ist doch auch gar nicht mehr möglich bzw. nötig weil der Datenpunkt nur noch lokal in der Instanz verwendet wird. 
Ein Querverweis funktioniert doch im Grunde genommen nur bei Globaldaten.


----------



## Matze001 (1 September 2012)

Du widersprichst dir.

Du sagst ein Datenpunkt wird nur Lokal genutzt, willst aber aus der Visu, und von sonst wo noch von Extern drauf "rumpfuschen"...

Ich habe alles in gekapselten FBs, und schmeisse da eine Struktur dran, die dann in Global-DBs liegt!

Grüße

Marcel


----------



## miasma (1 September 2012)

Ja lokal auf der Steuerung im Baustein der den Datenpunkt bearbeitet. Die Visu beschreibt nur die Variable der Instanzdaten. Weitere Zugriffe soll und wird es nicht geben. Das ist kein Wiederspruch oder ich verstehe nicht was Du meinst. Der Zugriff der Visu auf einen Datenpunkt stellt meiner Meinung nach nur ein beschreiben einer Variable da und somit bleibt der Datenpunkt lokal.

Genau das will ich vermeiden. Eine FB aufrufen und dann noch einen DB erzeugen der den FB versorgt.
Dann habe ich einen FB mit Instanzdatenbaustein und Datenbaustein.


----------



## Matze001 (1 September 2012)

Naja du siehst aber nicht das die Visu in deinem Lokaldaten rumpfuscht!

Ich habe z.B. einen Baustein der mir Daten zur Visu hoch schießt, der heißt dann auch VISU_KOPPEL_DB!

Und das Argument mit ein FB und einen GDB ist auch käse, ich habe z.B. einen GDB mit 20 Zylinder-UDTs, auf den ich sauber aus dem Programm und aus der Visu zugreifen kann, ohne auch nur eine Lokale Variable genutzt zu haben!

Grüße

Marcel


----------



## miasma (1 September 2012)

Das verstehe ich nicht wieso soll ich einen extra DB zur Visu anlegen wenn ich im Instanzdatenbaustein unter STAT eine Struktur zum Senden an die Visu und eine zum empfangen von der Visu anlegen kann. 
Ich müsste diesen DB jedes mal wieder neu erzeugen wenn ich eine neue Anlage mit anderer Konfiguration Programmieren will.

Ist es denn wirklich so gängige Praxis,das Daten die nur an einer einzigen Stelle in einem Programm genutzt werden Global zur Verfügung gestellt werden in einem DB oder gar noch schlimmer in einem Merker ?


----------



## Matze001 (1 September 2012)

Also ich versuch es mal etwas detailierter zu machen....


Ich habe einen GDB für Zylinder.

Dort ist dann 30mal die Zylinderstruktur drin. Vereinfacht ist das mal:

IN
Auto_in_GS
Auto_in_AS
Hand_in_GS
Hand_in_AS
OUT
POS_IN_GS
POS_IN_AS

Das ganze hab ich da drin wie gesagt 30 mal, die nennen wir dann mal Zylinder1, Zylinder2, ZylinderN...

Wenn ich im Handbetrieb Zylinder 1 verfahren muss schreibe ich also GLOBAL_DB.Zylinder1.IN.Hand_nach_GS
und fahre Zylinder 1 damit per Hand in GS. Automatisch ist das natürlich gleich.

An meinen Zylinder FB welchem ich keinen IDB gebe, sondern in dem STAT bereich des ANALGE_ALLGEMEIN FB aufrufe, übergebe ich GLOBAL_DB.Zylinder1, und binde an den Endschalter, Ventile, u.ä. direkt an.

Die Visu greift auch auf die Struktur im Globalen DB zu!

Somit habe ich für meine Aufgaben:

einen Aufruf FB mit den Instanzen der Zylinder im STAT bereich
einen GLOBAL DB mit den Schnittstellendaten
und beliebige Zugriffe über den Global DB

Ich spare mir auf diese Art einen riesen Arsch voll IDBs, habe eine immer identische Aufrufstruktur, die sich nur in dem Zylindernamen unterscheidet, habe volle "Gehe zu verwendungsgelle" Funktionalität und kann sogar noch den Vorteil nutzen das ich bei dem Zylinder FB die IN Variablen "ignorieren" bzw. ENABLEn kann, und somit auch einen Zylinder ohne großen Aufwand deaktivieren könnte.

Das hat sich für mich und meine Kollegen als eine gute und gängige Praxis bewährt!

Grüße

Marcel


Edit: Ach ja der Globale DB sollte so ausgelegt sein, dass man immer ReserveStrukturen hat... aber auch das nachträgliche Anfügen ist kein Problem...


----------



## Blockmove (1 September 2012)

@Matze

Ich mache es ebenfalls in dieser Art und Weise.
Dazu noch stationsbezogene DBs mit Betriebsarten und Typdaten und Gut is.

Mir ist Querverweis und volle Gehezu-Funktionalität auch extrem wichtig.

Gruß
Dieter


----------



## miasma (1 September 2012)

@Matze
Wozu nutzt man dann überhaupt einen FB wenn man die Daten aus einem externen Datenbaustein liest und schreibt ? 

@Blockmove

Wozu sollte ein Querverweis bei lokaldaten dienen ?


----------



## PN/DP (2 September 2012)

miasma schrieb:


> Wozu sollte ein Querverweis bei lokaldaten dienen ?


Nur "gehe zur vorherigen Verwendung" + "gehe zur nächsten Verwendung" ist einfach zu wenig. Ich brauche eine Liste aller Verwendungsstellen inklusive Kennzeichnung Schreibzugriff/Lesezugriff.


Die Nutzung von Strukturen als Übergabeparameter kann ich bei Siemens S7 nicht empfehlen, weil:
Das erzeugt unheimlich aufgeblähten Code um die Variablenadressen zur Laufzeit zu berechnen (je Variablen-Zugriff ca. 40 Byte extra).
Außerdem kann der aufgerufene Baustein auch INPUT(!)-Strukturen nach Belieben beschreiben und das ist nicht in den Referenzdaten zu sehen. Wie überhaupt jeder Strukturvariablen-Zugriff nicht zu sehen ist. Außerdem unterstützen die Referenzdaten keine Strukturen, d.h. Variablen einer Struktur lassen sich in den Referenzdaten nicht zusammenfassen.

Und imho sollte jeder PLC-Programmierer davon ausgehen, daß eines Tages ein anderer Programmierer den Code zügig verstehen können muß. Das wird bei "schlanken Schnittstellen" verdammt schwer ...

Harald


----------



## Matze001 (2 September 2012)

Ich nutze einen FB weil ich nicht meine ganzen Internen Zustände in den GlobalDB packen will.
Ich könnte das so machen, keine Frage! Aber ich habe lieber eine Schlanke Schnittstelle im Globalen DB!

Zu den Querverweisen bei Lokaldaten:

Sie heißen zwar bei dir Lokaldaten, aber wenn du von jeder stelle darauf schreiben willst vergewaltigst du sie als Globaldaten!

Grüße

Marcel


----------



## bike (2 September 2012)

Wenn man ein Programm von einem Fremden in Hände bekommt, dort Fehler suchen oder Änderungen machen muss, dann erübrigt sich doch die Frage des TE.

Mit den Zugriffen von irgendwoher auf IDB und dann dort Fehler zu suchen, wenn es einmal knallt?
Ein IDB gehört dem dazugehörigen FB und sonst niemand.
Wer seine Schnittstelle in einem Globalen DB zur HMI sauber aufbaut, der hat viel weniger Arbeit und Ärger, wenn ein neues Projekt ansteht.

Daher versteh ich die Frage nicht wirklich.
Ich programmiere nicht für mich, sondern für den Kunden und die Nachfolger, die das Programm am Leben erhalten.


bike


----------



## Matze001 (2 September 2012)

Ich glaube mein erstes Danke für Bike 

Grüße

Marcel


----------



## Rudi (2 September 2012)

bike schrieb:


> Daher versteh ich die Frage nicht wirklich.
> Ich programmiere nicht für mich, sondern für den Kunden und die Nachfolger, die das Programm am Leben erhalten.
> bike



Genau so soll es sein !!


----------



## Thomas_v2.1 (2 September 2012)

bike schrieb:


> Mit den Zugriffen von irgendwoher auf IDB und dann dort Fehler zu suchen, wenn es einmal knallt?
> Ein IDB gehört dem dazugehörigen FB und sonst niemand.
> Wer seine Schnittstelle in einem Globalen DB zur HMI sauber aufbaut, der hat viel weniger Arbeit und Ärger, wenn ein neues Projekt ansteht.


Woran kann man denn erkennen dass eine Visualisierung oder eine andere Station auf einen globalen DB schreibt? Nur an dem Namen? Was ist wenn ich im den statischen Daten des FB eine Struktur HMI anlege und die Visu nur auf diese Daten zugreifen darf, gilt das dann auch als OK?

Wenn man es wirklich sauber machen wollte müsste man einen Dummy FC mit meinetwegen Namen "HMI-Schnittstelle" schreiben, an dessen In-Out Parameter alle Werte die von der Visu geschrieben werden parametriert werden. Nur dann finde ich Zugriffe auch in der Querverweisliste wieder.


----------



## Matze001 (2 September 2012)

Klar kann man das machen, aber ob es dadurch sauberer ist bezweifel ich mal 

Ich finde einen Global-DB eindeutig! Wie stellst du dir das mit dem FC vor? Direkt in den IN-Bereich schreiben? Nen Global-DB an den IN-Bereich anknüpfen? Damit drehen wir uns wieder im Kreis.

Irgendwie hat meiner Meinung nach alles außer nem GDB kein Hand und Fuß!

Grüße

Marcel


----------



## Thomas_v2.1 (2 September 2012)

Matze001 schrieb:


> Klar kann man das machen, aber ob es dadurch sauberer ist bezweifel ich mal
> 
> Ich finde einen Global-DB eindeutig! Wie stellst du dir das mit dem FC vor? Direkt in den IN-Bereich schreiben? Nen Global-DB an den IN-Bereich anknüpfen? Damit drehen wir uns wieder im Kreis.


Nein, einfach nur durch einen FC durchleiten, damit man es in der Querverweisliste wiederfindet.


Matze001 schrieb:


> Irgendwie hat meiner Meinung nach alles außer nem GDB kein Hand und Fuß!


Nur wer hat denn festgelegt dass von außen auf einem bestimmten global-DB geschrieben werden kann?
Wenn man in der SPS den Zugriff von außen auf einen einzigen DB beschränken könnte, würde ich das noch als schlüssig hinnehmen. Da es das aber nicht gibt, kann ich im Programm auch bei global DBs nicht nachvollziehen auf welche DBs die Visualisierung denn jetzt schreibt.

Ich bin jetzt nicht generell nur für das eine oder andere (ich habe beides gemacht und es gibt bei beiden Wegen Vor- und Nachteile), aber die Argumentationskette von den pro Global-DB Leuten ist meiner Meinung nach sehr dünn.


----------



## Matze001 (2 September 2012)

Ich mache es mir persönlich immer recht leicht!

Ich habe folgende GDBs:

VISU_ALLGEMEIN -> Hier sind ein Paar Bool, Byte, INT, REAL, ... die die Visu allgmein austauscht
ZYLINDER -> Hier ist alles was mit den Zylindern zu tun hat, mit nem bereich für die Visu
KOMMNUNIKATION_MASCHINE1 -> Hier landen Daten per S7-Verbindung von Maschine1
...

Somit ist für mich beim Überblicken des Programms schnell ersichtlich was wo passiert.
Außerdem kann ich hier mit Reserven arbeiten, und z.B. die Vorbereitung für 20 Zylinder schaffen, 
die dann halt im Programm "totlaufen" und nicht aufgerufen werden. Wenn ich direkt auf den IDB gehe
dann MUSS ich diesen im Programm haben, also auch aufrufen!

Das ist mein Vorgehen, ich möchte es keinen Aufzwingen! 

Grüße

Marcel


----------



## bike (2 September 2012)

Thomas_v2.1 schrieb:


> Da es das aber nicht gibt, kann ich im Programm auch bei global DBs nicht nachvollziehen auf welche DBs die Visualisierung denn jetzt schreibt.



Vielleicht versteh ich jetzt etwas falsch.
Meine HMI schreibt und liest aus einem eigenen Global DB.
Wenn etwas nicht passt, dann kann erkannt werden, ob der Fehler aus dem GlobalDB kommt oder nicht. 
Wenn ein IDB von anderen Funktionen umgeschrieben wird, dann ist das schwer zu finden.
Es kann einen blöden Effekt geben, wenn der FB einen Wert ändert, dann ändert die HMI diesen ebenso in selben Zyklus 

Jeder so wie er oder sie will. Meine Erfahrung zeigt, dass diese Art nicht ganz so falsch sein kann.
Bisher kamen noch keine Reklamationen von anderen.


bike


----------



## Thomas_v2.1 (2 September 2012)

bike schrieb:


> Vielleicht versteh ich jetzt etwas falsch.
> Meine HMI schreibt und liest aus einem eigenen Global DB.


Und woher weiß ich das wenn ich in den Programm reinschauen würde, dass die HMI genau auf diesen DB schreibt?


----------



## MSB (2 September 2012)

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


----------



## Thomas_v2.1 (2 September 2012)

MSB schrieb:


> Ich würds mal anders rum formulieren, welchen Vorteil habe ich wenn ich das ganze in den IDB packe?


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.



MSB schrieb:


> Ich weiß noch weniger auf den ersten Blick "wo" das HMI überall rumpfuscht.


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.


MSB schrieb:


> 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.


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...


----------



## rostiger Nagel (2 September 2012)

MSB schrieb:


> Sollte ich irgendwelche spezifischen Parameter haben, z.B. Zeiten für die Laufzeitüberwachung, Betriebsstunden etc. muss ich den kompletten IDB vorher sichern.



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. 





MSB schrieb:


> 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.



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.


----------



## miasma (2 September 2012)

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


----------



## Paule (2 September 2012)

MSB schrieb:


> 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.


Und das ist doch das Hauptproblem, du kannst einen IDB nicht sichern und wenn dann nur sehr, sehr umständlich und mit erheblichem Aufwand!


----------



## Blockmove (2 September 2012)

miasma schrieb:


> 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.



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


----------



## bike (2 September 2012)

Thomas_v2.1 schrieb:


> Und woher weiß ich das wenn ich in den Programm reinschauen würde, dass die HMI genau auf diesen DB schreibt?



Aus der Symbolik und dem dazugehörenden Kommentar vielleicht?


bike


----------



## Ralle (2 September 2012)

rostiger Nagel schrieb:


> 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.



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.


----------



## rostiger Nagel (2 September 2012)

Ralle schrieb:


> 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.



Wie der Kunde will etwas anderes, was soll das den :?:


----------



## Thomas_v2.1 (2 September 2012)

bike schrieb:


> Aus der Symbolik und dem dazugehörenden Kommentar vielleicht?



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?


----------



## miasma (2 September 2012)

Blockmove schrieb:


> 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



Ich verstehe nicht was du mit einem Textfeld mit EA Funktion meinst.


----------



## Blockmove (2 September 2012)

miasma schrieb:


> Ich verstehe nicht was du mit einem Textfeld mit EA Funktion meinst.



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 (2 September 2012)

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


----------



## miasma (2 September 2012)

Blockmove schrieb:


> 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



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 ?


----------



## Thomas_v2.1 (2 September 2012)

MSB schrieb:


> 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.


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.



MSB schrieb:


> 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.


Und was wenn die UDT um einen Wert erweitert werden soll? Dann funktioniert nämlich auch kein gesicherter Global-DB.


----------



## miasma (2 September 2012)

Thomas_v2.1 schrieb:


> 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.



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 (2 September 2012)

Thomas_v2.1 schrieb:


> Und was wenn die UDT um einen Wert erweitert werden soll? Dann funktioniert nämlich auch kein gesicherter Global-DB.


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.



			
				miasma schrieb:
			
		

> 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.


Das Argument ist im Gesamtzusammenhang Käse, weil sich an dem Potentiellen Problem mit deiner IDB Variante auch 0,garnix ändert.

Mfg
Manuel


----------



## miasma (2 September 2012)

MSB schrieb:


> 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.
> Mfg
> Manuel



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.
Das dauert nicht länger als eine Konsistenzprüfung mit Übersetzung und neu einspielen.


----------



## MSB (2 September 2012)

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


----------



## Thomas_v2.1 (2 September 2012)

MSB schrieb:


> 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.



Genauso kann ich in meinen Instanz-DBs 50% Reserven lassen, und nun?


----------



## MSB (2 September 2012)

Thomas_v2.1 schrieb:


> Genauso kann ich in meinen Instanz-DBs 50% Reserven lassen, und nun?


Müsstest du dann halt bei IN / OUT / IN/OUT und last but not least STAT-Parametern lassen.

Schlussendlich ist die Diskussion doch ohnehin wie üblich fürn Arsch, weil rein Philosophisch.
Erstens machts eh jeder wies ihm in den Kram passt, zweitens gibts eh für alles und jedes für und wider,
also weiß ich gar nicht warum der TE überhaupt nach "anderen" Meinungen fragt, soll er halt machen wie er denkt, wobei ich diese künstlerische Freiheit auch für mich beanspruche.

Die Frage wird sogar noch Philosophischer, weil sich die Frage in dem Maße von Haus aus nur bei Siemens und einer Handvoll anderen Steuerungen überhaupt stellt.
Bei Codesys, PCWorx etc. stellt sich die Frage in dem Maß dann eigentlich gar nicht mehr, weils schlicht und einfach nicht funktioniert, das man in Instanzen rumpfuscht.
Bei der S7-1200 mit den "komprimierten" Datenbausteinen, weiß man noch nicht mal mehr, welche Adresse der jeweilige Datenpunkt überhaupt hat,
Blockmove ist hier dann ohnehin kaum mehr sinnvoll nutzbar, bzw. in der 1200er ja im Sinne der 300/400er auch gar nicht implementiert.

Mfg
Manuel


----------



## miasma (2 September 2012)

Thomas_v2.1 schrieb:


> Genauso kann ich in meinen Instanz-DBs 50% Reserven lassen, und nun?



Reserven sind für mich unakzeptabel. Ich will nur real existierende Daten im Programm.
Ich will schlanke Strukturen die einfach zu beobachten sind.

Spätestens hier wird das ganze aber zu einer Philosophie Frage und ist kein technisches Problem mehr.
Da beides funktioniert.


----------



## JOHKU (2 September 2012)

Hallo Kollegen,
darf ich auch ein wenig mitschwätzen?
Ich verfolge den Ansatz dass für jedes Verfahrenstechnische Objekt zB. Ventil, Motor, Messung mit Z+,A+,A-Z-, etc. ein entsprechender FB mit seinem IDB  angelegt wird. Der IDB ist im Prinzip nichts anderes als eine UDT die automatisch angelegt wird. In den FB´s verwende ich die SFC´s 107/108 die aus dem FB heraus CPU Alarme mit Zeitstempel auslösen. Das bedeutet wenn ein Motor eine Störung hat sorgt der Motor-FB dass diese auch entsprechend alarmiert wird.
Im IN oder IN/OUT Bereich des FB´s gibt es Parameter die nicht verschaltet werden sondern für die Bedienung über OP bzw.  WinCC  reserviert sind. Im OUT Bereich gibt es eine oder mehrere Statusvariablen die für die Steuerung von Zustandsanzeigen verwendet wird.
Auf den Zugriff direkt auf statische Variablen habe ich nach einiger Zeit verzichtet. Der Grund ist der dass, bei Versionsänderungen der FB´s meistens auch eine Verschiebung im STAT Bereich erfolgt.
Habe durchaus gute Erfahrungen mit standardisierten Symbolen und Faceplates gemacht denen man nur noch die Nummer des IDB übergeben muss.

Gruß
Johannes


----------



## Thomas_v2.1 (2 September 2012)

MSB schrieb:


> Müsstest du dann halt bei IN / OUT / IN/OUT und last but not least STAT-Parametern lassen.
> 
> Schlussendlich ist die Diskussion doch ohnehin wie üblich fürn Arsch, weil rein Philosophisch.
> Erstens machts eh jeder wies ihm in den Kram passt, zweitens gibts eh für alles und jedes für und wider,
> also weiß ich gar nicht warum der TE überhaupt nach "anderen" Meinungen fragt, soll er halt machen wie er denkt, wobei ich diese künstlerische Freiheit auch für mich beanspruche.



Nur werden hier alle von der Global-DB abweichenden Varianten als Verbrechen hingestellt (Zitat LL: "Jage ich vom Hof" - er selber macht es aber in bestimmten Fällen wo es einfacher ist dann doch).

Ich mache das mit den Instanz-DB Zugriffen aus historisch gewachsenen Gründen nur so wenn ich Intouch-Leitsysteme habe, da ich dort a) eine Excel Tabelle habe die mir automatisch die Adressen generiert, und b) habe ich im Leitsystem eine Speicherfunktion für alle eingestellten Sollwerte. In der Verwendung hat das schon Vorteile: wenn ein Antrieb hinzukommt rufe ich den Antriebs-FB auf, IDB generieren, hochladen, Visu Variablen generieren, fertig. Warum soll ich nochmal was in einem Global-DB dazu anlegen? Ein überflüssiger Arbeitsschritt.


----------



## Ralle (2 September 2012)

miasma schrieb:


> 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.
> Das dauert nicht länger als eine Konsistenzprüfung mit Übersetzung und neu einspielen.



Danke, das geht, ist aber vollkommen schwachsinnig, wirklich.
IDB gehören nur dem FB, Alles andere ist Pfusch, auch wenn es gehen mag, schick ist und dem Anschein nach weniger Arbeit macht.
Lege eine vernünftige Schnittstelle nach außen fest und bediene damit das HMI, aber schreibe nicht vom HMI im IDB herum. Fang damit besser gar nicht erst an.


----------



## miasma (2 September 2012)

Ralle schrieb:


> Lege eine vernünftige Schnittstelle nach außen fest und bediene damit das HMI, aber schreibe nicht vom HMI im IDB herum. Fang damit besser gar nicht erst an.



Ich verstehe nicht was an meiner Art Schnittstelle nicht vernünftig ist ?
Sie ist eindeutig, strukturiert und einfach zu beobachten.
Im Gegensatz zu einem Global-DB der viele Antriebe enthält und wohl möglich auch noch verschiedene, die dann auch noch alle zu 50% aus Reserve bestehen.

Ist die Idee von vollständiger Kapselung so exotisch ?


----------



## Blockmove (2 September 2012)

miasma schrieb:


> Wenn Du in WinFlex ein EA Feld anlegst legst Du also in der Bausteinschnittstelle immer ein IN_OUT dafür fest ?



Nein, denn ich verwende keine Instanz-DBs für Visu-Aufgaben.


----------



## bike (2 September 2012)

miasma schrieb:


> Ist die Idee von vollständiger Kapselung so exotisch ?



Eigentlich ja.
Wenn du jemals richtig programmiert hast und verschiedene Programmen schon ändern und dort ggF Fehler gesucht hättest, wäre deine Fragen hinfällig.

Bei uns gibt es komplett gekapselte Funktionen, aber nur in der Serie und wenn diese ausreichend ausgetestet sind.
Im Sondermaschinen- und Anlagenbau wird dir das nie gelingen.

Und bis jetzt habe ich immer noch nicht verstanden, was du willst.
Zu lesen deine Ansicht ist richtig?
Versuche solch ein Prgramm in der Autoindustrie zu verkaufen und du wärst für immer kuriert.

Aber wenn man frisch von der UNI kommt, dann hat man solche Ideen, das ist eben so.


bike


----------



## MSB (2 September 2012)

miasma schrieb:


> Ist die Idee von vollständiger Kapselung so exotisch ?


Ist dir doch ohnehin egal, das ist eine Frage die man in allerletzter Konsequenz nur Digital sprich mit Ja oder Nein beantworten kann,
so gesehen, mach das doch einfach ... du wirst dich sowieso nicht aufhalten lassen.

Ich finds Siemens-Spezifisch, HMI-Abhängig und  alleine deshalb ist es abzulehnen.

Mfg
Manuel


----------



## sps-concept (2 September 2012)

miasma schrieb:


> Ist die Idee von vollständiger Kapselung so exotisch ?



Es gibt Kundenstandards wo das genauso realisiert wird. Die Visuanbindung erfolgt da ausschliesslich per IDB. Im STAT-Bereich gibt es einen bereich für Visuwerte. Alles eine Sache der Bausteinbeschreibung bzw der des ganzen Standards. Einen guten Programmierer macht auch aus, dass er sich anpassen kann und nicht nur stur nach gleichem Schema programmiert.

André


----------



## Blockmove (2 September 2012)

Mein persönliches Fazit:
Die Ideen des TE sind alle machbar und auch umsetzbar. Die Ansätze gehen in Richtung Objektorientierung.

Das Problem an der Sache ist nur, dass keine aktuelle SPS-Entwicklungsumgebung hierfür die notwendige Funktionalität liefert um:
a) die Daten konsistent in SPS und HMI zu halten und einen Online-Change zu ermöglichen
b) vernüntige Querverweise / Referenzen zur Fehlersuche zu liefern

Und deshalb gilt einfach - meines Erachtens - auch hier der alte Spruch:
Das Werkzeug muß zur Aufgabe passen.

Gruß
Dieter


----------



## Thomas_v2.1 (2 September 2012)

bike schrieb:


> Bei uns gibt es komplett gekapselte Funktionen, aber nur in der Serie und wenn diese ausreichend ausgetestet sind.
> Im Sondermaschinen- und Anlagenbau wird dir das nie gelingen.


Wie, jetzt macht ihr das doch, das ist doch Pfusch?
Bei mir sind immer alle Funktionen in Standardbausteinen ausreichend getestet. Bei euch nicht?



bike schrieb:


> Versuche solch ein Prgramm in der Autoindustrie zu verkaufen und du wärst für immer kuriert.


Wenn der Kunde spezifische Vorstellungen hat soll er diese vorher kundtun. Außer wenn eine Visualisierung besondere Anforderungen stellt, lässt sich technisch gesehen kaum ein Grund finden der gegen Zugriff auf Instanz-DBs spricht. 
Außer Pauschalaussagen wie "macht man nicht" kommt von euch bisher ja nicht viel, das Killer-Argument lässt noch auf sich warten.


----------



## miasma (2 September 2012)

bike schrieb:


> Und bis jetzt habe ich immer noch nicht verstanden, was du willst.
> Zu lesen deine Ansicht ist richtig?
> bike



Zu erfahren ob es leute gibt die so arbeiten oder so gearbeitet haben.
Wo die evtl. Vor und Nachteile liegen. 
Im Grunde genommen genau das was jetzt passiert. 
Mich wundert nur das dieses Thema anscheinend sehr emotional diskutiert wird.
Ich habe so ein wenig das Gefühl das jeder für sich beansprucht die perfekte Methode zu haben ein Programm zu erstellen.


----------



## sps-concept (2 September 2012)

bike schrieb:


> Versuche solch ein Prgramm in der Autoindustrie zu verkaufen und du wärst für immer kuriert.bike



Hallo bike,

ich weiss ja nicht aus welchem Jahr(tausend) deine diesbezügliche Erkenntnis stammt.. In diesem Thread hast du so getan als wenn du dich da auskennst:

http://www.sps-forum.de/showthread.php/52941

Mir fallen 3 Automobilisten ein wo das so ist.

André


----------



## rostiger Nagel (2 September 2012)

miasma schrieb:


> Mich wundert nur das dieses Thema anscheinend sehr emotional diskutiert wird.



Meistens wird dieses Thema sehr hochgekocht, erst wird diskutiert, etwas später virtuell angeschrien,
ein bisschen später angespuckt und dann schiebt ein moderator es in den SV. 

Aber es ist immer wieder schön


----------



## Thomas_v2.1 (2 September 2012)

MSB schrieb:


> Bei Codesys, PCWorx etc. stellt sich die Frage in dem Maß dann eigentlich gar nicht mehr, weils schlicht und einfach nicht funktioniert, das man in Instanzen rumpfuscht.


Also bei Twincat 2 kann ich über ADS auf die Instanzdaten zugreifen.


MSB schrieb:


> Bei der S7-1200 mit den "komprimierten" Datenbausteinen, weiß man noch nicht mal mehr, welche Adresse der jeweilige Datenpunkt überhaupt hat,


Bei der 1200er kann ich symbolisch auf die Daten zugreifen, also fällt hier wie auch bei Twincat mit ADS das ganze Adressproblem bei Verschiebungen komplett weg. Bei Twincat gibt es auch kein Problem mit dem Behalten von Variablenwerten bei Änderungen (im Normalfall ;-) ).


----------



## bike (2 September 2012)

Thomas_v2.1 schrieb:


> Wie, jetzt macht ihr das doch, das ist doch Pfusch?.



Es ging um komplett gekapselte Funktionen, nicht um Zugriff von aussen auf IDB.




Thomas_v2.1 schrieb:


> Bei mir sind immer alle Funktionen in Standardbausteinen ausreichend getestet. Bei euch nicht?.


Du kannst jede Funktion so austesten, dass du dafür garantieren kannst, dass es keinerlei Quereinflüsse gibt? 
Respekt, die Zeit haben wir nicht immer.



Thomas_v2.1 schrieb:


> Wenn der Kunde spezifische Vorstellungen hat soll er diese vorher kundtun. Außer wenn eine Visualisierung besondere Anforderungen stellt, lässt sich technisch gesehen kaum ein Grund finden der gegen Zugriff auf Instanz-DBs spricht.



Es gibt keine Visualisierung die es unumgänglich macht,  auf IDB zu zugreifen.
Es geht auch bei Intouch oder WInCC ohne IDB Zugriffe.
Die einzige Ausnahme kann sein, wenn PCS7 verwendet wird, da kommt es beim Kompilieren, wenn man den Code genauer anschaut, zu Zugriffen auf IDB.
Aber auch das sit meiner Meinung nach falsch. Aber eben BigS eben.




Thomas_v2.1 schrieb:


> Außer Pauschalaussagen wie "macht man nicht" kommt von euch bisher ja  nicht viel, das Killer-Argument lässt noch auf sich warten.


Warum muss das kommen?
Pauschal? Vielleicht solltest du noch einmal genauer lesen.
Es wurden einige Hinweise gegeben, warum es Mist ist eine IDB zu vergewaltigen.

Aber jeder soll das machen was er oder sie für richtig hält.


bike

@sps-concept. ich verstehe nicht was dein Hinweis soll. Ich kann dort keinen Hinweis auf IDB oder erkennen.


----------



## miasma (2 September 2012)

Blockmove schrieb:


> Mein persönliches Fazit:
> Die Ideen des TE sind alle machbar und auch umsetzbar. Die Ansätze gehen in Richtung Objektorientierung.
> 
> Das Problem an der Sache ist nur, dass keine aktuelle SPS-Entwicklungsumgebung hierfür die notwendige Funktionalität liefert um:
> ...



Was es "a)" angeht muss ich dir recht geben. Aber auf Seiten SPS und HMI sollen Faceplates mit Strukturen arbeiten. Somit muss ich "nur" die Startvariable im Auge behalten und dies im Grunde genommen auch nur auf Seite der Visu.

Was es "b)" angeht kann ich nur sagen einen Querverweis in einem FB der nur Lokaldaten enthält brauche ich nicht. Es gibt ja nur Verwendungsstellen.


----------



## bike (2 September 2012)

miasma schrieb:


> Ich habe so ein wenig das Gefühl das jeder für sich beansprucht die perfekte Methode zu haben ein Programm zu erstellen.



Ich bestimmt nicht.
Doch wir haben jedes Jahr mehrere Studis, die ihre Master- oder Diplomarbeit bei uns machen und diese Diskussion kommt bei fast jedem neu auf.
Deine Ansicht hat aber leider mit PLC Programmierung nicht so echt viel zu tun, denn C, mit den entsprechenden Zusatzzeichen, ist ein völlig andere Welt.

bike


----------



## Thomas_v2.1 (2 September 2012)

bike schrieb:


> Pauschal? Vielleicht solltest du noch einmal genauer lesen.
> Es wurden einige Hinweise gegeben, warum es Mist ist eine IDB zu vergewaltigen.
> 
> Aber jeder soll das machen was er oder sie für richtig hält.


Diese Hinweise konnte ich glaub ich größtenteils auch widerlegen.
Ich muss ja gestehen dass ich in 90% meiner Anlagen auch Global-DBs für die Visu habe. Aber ich bin der Meinung dass man durchaus ein konsistentes System aufsetzen kann bei dem die Visu auf Instanz-DBs (zumindest bei Standard-Bausteinen) zugreift. Wichtig ist für mich dass es schlüssig ist. Und ich denke mir, wenn die Vorteile die Nachteile überwiegen, warum nicht?


----------



## bike (2 September 2012)

Unser Programmierrichtlinie beginnt mit dem Satz:

Jedes Programm, das die Aufgabe erfüllt für das erstellt wurde, ist ein gutes Prgramm.


bike


----------



## miasma (2 September 2012)

bike schrieb:


> Ich bestimmt nicht.
> Doch wir haben jedes Jahr mehrere Studis, die ihre Master- oder Diplomarbeit bei uns machen und diese Diskussion kommt bei fast jedem neu auf.
> Deine Ansicht hat aber leider mit PLC Programmierung nicht so echt viel zu tun, denn C, mit den entsprechenden Zusatzzeichen, ist ein völlig andere Welt.
> 
> bike



Ich für mich auch nicht. Aber stehen bleiben will ich auch nicht. Seinen eigenen Standard in regelmäßigen Abständen zu überprüfen ob er noch allen Anforderungen gerecht wird halte ich jetzt nicht für besonders ungewöhnlich.
Keine Sorge ich bin schon länger kein Studi mehr.


----------



## SoftMachine (2 September 2012)

Matze001 schrieb:


> Ich glaube mein erstes Danke für Bike
> 
> Grüße
> 
> Marcel



Oha, verwöhn ihn aber nicht zu sehr !  :s10:

gruss


----------



## Larry Laffer (3 September 2012)

miasma schrieb:


> Ich verstehe nicht was an meiner Art Schnittstelle nicht vernünftig ist ?
> Sie ist eindeutig, strukturiert und einfach zu beobachten.
> Im Gegensatz zu einem Global-DB der viele Antriebe enthält und wohl möglich auch noch verschiedene, die dann auch noch alle zu 50% aus Reserve bestehen.
> 
> ...




Hallo,
da ich ja schon aus dem zusammenhang heraus zitiert wurde ... hier nun mein Statement dazu :
Die von dir genannte Vorgehensweise ist für die meißten SPS-Programmierer mehr als exotisch. Auf solche Ideen kommt man nur, wenn man sich mit OOP oder Dot-Net beschäftigt / beschäftigt hat.
Natürlich ist in SPS-Programmen jede Form von Strukturierung verpöhnt und nicht erwünscht. Ein Programm ist dann wirklich gut, wenn die Variablen davon überall verstreut sind ... 8)

Nein ... im Ernst.
Das von dir genannte Verfahren wird von mir (und meinen Kollegen) in ähnlicher Weise praktiziert.
Eine Station hat auf den Schnittstelle ihre E/A' und den koppelbereich, den sie nun mal nach "Aussen" braucht. Alles andere hat sie in der Instanz. Dazu gehören z.B. Parameter, Istwerte, Hand-Steuerbits, Fehler-Meldungen.
Ich muss hier aber auch sagen, dass sich diese Vorgehensweise bei uns aufgrund unserer Anlagen geradezu anbietet - Es sind Rundschalttische mit einzelnen Bearbeitungsstationen. Jede dieser Stationen hat mit einer Anderen i.d.R. gar nichts zu tun. Die einzige Kopplung, die es hier gibt ist die Befehls-Melde-Ebene zum ansteuernden Tisch und der Schiebespeicher, der den Abarbeitungs-Status und ggf. auch die Messwerte der Bauteile verwaltet.

Selbstverständlich habe ich die von mir (für mich !!!) aufgestellten Reglen auch schon das eine oder andere Mal ein wenig aufgeweicht - *keine* Regel ohne Ausnahme. Ist aber deswegen der Ansatz falsch ?
Ein Querzugriff auf die Instanz (außer von der Visu, die das bei mir aus mehreren Gründen ausdrücklich darf) ist bei uns kein Thema - außer der einzige Daseinszweck dieser Instanz ist es, genau dafür da zu sein.
Das ist dann aber halt meine Philosophie und soll ausdrücklich nicht irgendwem als Leitfaden (und ganz sicher nicht Thomas_V2.1) dienen. Jeder nach seiner Fasson.

Aus jeden Fall - als Fazit :
Ich finde die Idee grundsätzlich gut, wie du es vorhast. An den Details kann man immer noch feilen ...

Gruß
Larry


----------



## miasma (3 September 2012)

Larry Laffer schrieb:


> Larry Laffer schrieb:
> 
> 
> > Die von dir genannte Vorgehensweise ist für die meißten SPS-Programmierer mehr als exotisch. Auf solche Ideen kommt man nur, wenn man sich mit OOP oder Dot-Net beschäftigt / beschäftigt hat.
> ...


----------



## rostiger Nagel (3 September 2012)

ich hab mich garnicht richtig getraut es zu sagen, aber ich mache es genauso wie LL und habe noch keine Probleme gesehen bzw. gehabt.


----------



## Ralle (3 September 2012)

miasma schrieb:


> Larry Laffer schrieb:
> 
> 
> > Ja genau ich beschäftige mich auch viel mit OOP und probiere den Denkansatz auf S7 zu Übertragen.
> ...


----------



## Aventinus (3 September 2012)

miasma schrieb:


> Larry Laffer schrieb:
> 
> 
> > Ja genau ich beschäftige mich auch viel mit OOP und probiere den Denkansatz auf S7 zu Übertragen.
> ...


----------



## Perfektionist (3 September 2012)

Hallo miasma,

ich kann Dir bestätigen, dass ich seit Jahren so arbeite, wie Du arbeiten möchtest. Und nicht viel Bestätigung dafür aus dem Forum erhalten habe.

Es gibt eine Sache, die bei TIA (soweit ich mich an den kurzen Zeitraum richtig zurückerinnere, als ich es nutzen durfte) lästig ist: das CTRL-SHIFT-F und ...B funktioniert dort (noch?) nicht.

Was bei TIA gut ist: die Querverweise funktionieren rundrum vorwärts und rückwärts von Visu zu SPS und eben zurück, also dieser "Pfusch der Visu in den Lokaldaten" kann man als Pfusch sehen oder auch nicht.

...tja, dann gibs noch bei TIA das Thema optimierte Datenablage. Ich konnte mit diesem Feature noch nicht experimentieren, da ich mit TIA leider nur Classic-CPUs bearbeitet habe. Ich vermute jedoch, dass diese neue Datenstrukturierung viele der Classic-Probleme lösen wird.


----------



## miasma (3 September 2012)

Perfektionist schrieb:


> Hallo miasma,
> 
> ...tja, dann gibs noch bei TIA das Thema optimierte Datenablage. Ich konnte mit diesem Feature noch nicht experimentieren, da ich mit TIA leider nur Classic-CPUs bearbeitet habe. Ich vermute jedoch, dass diese neue Datenstrukturierung viele der Classic-Probleme lösen wird.



Du meinst vermutlich die Funktion das Datenbausteine nur noch Symbolisch Adressierbar sind ? 
Das wäre eine feine Sache und würde auch gleichzeitig bedeuten das Siemens die Möglichkeiten seines Systems ausbaut.


----------



## MSB (3 September 2012)

miasma schrieb:


> Du meinst vermutlich die Funktion das Datenbausteine nur noch Symbolisch Adressierbar sind ?
> Das wäre eine feine Sache und würde auch gleichzeitig bedeuten das Siemens die Möglichkeiten seines Systems ausbaut.



Jein, in erster Linie bedeutet das, das ein Datenpunkt keine bekannte Adresse mehr hat, also du auch mit SFC20 nichts mehr sichern kannst,
wie du mir das oben ja so schön (umständlich) beschrieben hast.

P.S.
@Ralle, es scheint, das wir uns mal auf eine Hopfenkaltschale treffen sollten, offensichtlich haben wir beide ein Talent, immer Negativ-Beispiele zu erwischen ...

Mfg
Manuel


----------



## miasma (3 September 2012)

MSB schrieb:


> Jein, in erster Linie bedeutet das, das ein Datenpunkt keine bekannte Adresse mehr hat, also du auch mit SFC20 nichts mehr sichern kannst,
> wie du mir das oben ja so schön (umständlich) beschrieben hast.



Bei gleich bleibenden Symbolen ja auch unnötig. Da alle Adressen dann immer eindeutig (der String ändert sich ja nicht) sind kann ich alle in eine Liste schreiben.
Von dort aus kann ich sie einzeln und gruppenweise (ihre Strukturzugehörigkeit lässt sich aus dem String auslesen) wieder herstellen.


----------



## MSB (3 September 2012)

miasma schrieb:


> Bei gleich bleibenden Symbolen ja auch unnötig. Da alle Adressen dann immer eindeutig (der String ändert sich ja nicht) sind kann ich alle in eine Liste schreiben.
> Von dort aus kann ich sie einzeln und gruppenweise (ihre Strukturzugehörigkeit lässt sich aus dem String auslesen) wieder herstellen.



Klar, und das machst du wenn 10 Leute hinter dir stehen, um 3 Uhr Nachts weils mal wieder pressiert, sprich die Kiste steht, und du eigentlich nur schnell ne Kleinigkeit ändern wolltest.
Wobei sich am Grundproblem, das der DB initialisiert wird bzw. mit den Aktualwerten des Offline-Projektes überschrieben wird ja vom Verhalten her auch beim optimierten DB nichts geändert hat.

Mfg
Manuel


----------



## miasma (3 September 2012)

MSB schrieb:


> Klar, und das machst du wenn 10 Leute hinter dir stehen, um 3 Uhr Nachts weils mal wieder pressiert, sprich die Kiste steht, und du eigentlich nur schnell ne Kleinigkeit ändern wolltest.
> Wobei sich am Grundproblem, das der DB initialisiert wird bzw. mit den Aktualwerten des Offline-Projektes überschrieben wird ja vom Verhalten her auch beim optimierten DB nichts geändert hat.
> 
> Mfg
> Manuel



Dazu kann ich nichts sagen. Ich bin noch nie in die Situation gekommen, nachts um drei "mal wieder" mein Programm "nur schnell" zu ändern weil "die Kiste" nicht läuft. 

 Dies liegt wahrscheinlich daran das ich der Auffassung bin das nichts "schnell" gemacht werden sollte.
Außerdem bin ich jedes mal ein kleines bisschen stolz wenn ich die Baustelle verlasse und sich der Kunde freut das unsere Maschine wie am Schnürchen läuft während nebenan die "Kiste" von der Konkurrenz mal wieder steht, aus der Reihe tanzt oder gar einen Crash gefahren hat. 

Deshalb betreibe ich ja den ganzen Aufwand mit der Modularität. Ich habe keine Lust in die Verlegenheit zu kommen nachts um drei mein Programm ändern zu müssen weil ich es versäumt habe meine Lösungen den stetig steigenden Anforderungen an die Steuerung und das Qualitätsbewusstsein der Kunden anzupassen.


----------



## Ralle (4 September 2012)

miasma schrieb:


> Dazu kann ich nichts sagen. Ich bin noch nie in die Situation gekommen, nachts um drei "mal wieder" mein Programm "nur schnell" zu ändern weil "die Kiste" nicht läuft.
> 
> Dies liegt wahrscheinlich daran das ich der Auffassung bin das nichts "schnell" gemacht werden sollte.
> Außerdem bin ich jedes mal ein kleines bisschen stolz wenn ich die Baustelle verlasse und sich der Kunde freut das unsere Maschine wie am Schnürchen läuft während nebenan die "Kiste" von der Konkurrenz mal wieder steht, aus der Reihe tanzt oder gar einen Crash gefahren hat.
> ...



Deine Sprüche dazu passen zu Siemens, fang doch da an! 

Mal im Ernst, das Ziel haben ja wohl (fast alle) und ich behaupte mal, meine Anlagen laufen auch entsprechend gut und das komplett ohne OOP-Ansätze. Ansonsten hätte ich schon lange keine Aufträge mehr.

PS: Niemand strickt schnell eine komplette Anlage um, man sucht aber doch auch mal Fehler. Und ich will den sehen, der ohne Fehler programmiert, aber in dir haben wir ja nun zumindest einen Programmierer, der das von sich behaupten kann...
Deine Äußerungen zeugen aber zumindest von einer gewissen Arroganz anderen Kollegen oder Firmen gegenüber.


----------



## Larry Laffer (4 September 2012)

@Ralle:
das mit der Arroganz habe ich so in den bisherigen Beiträgen (außer bei meinem) nicht realisiert.
Die Idee des TE, da ich sie ja auch selber verfolge und die von dir erwähnten Probleme gerade wegen der Kapselung nicht kenne, finde ich aber gut, wenn sie auch gut gemacht wird / ist.
Was spricht dagegen, Dinge, die zusammen gehören, auch zusammen zu packen ?

Gruß
Larry


----------



## Ralle (4 September 2012)

Larry Laffer schrieb:


> @Ralle:
> das mit der Arroganz habe ich so in den bisherigen Beiträgen (außer bei meinem) nicht realisiert.
> Die Idee des TE, da ich sie ja auch selber verfolge und die von dir erwähnten Probleme gerade wegen der Kapselung nicht kenne, finde ich aber gut, wenn sie auch gut gemacht wird / ist.
> Was spricht dagegen, Dinge, die zusammen gehören, auch zusammen zu packen ?
> ...



Ich meinte ausschließlich den zitierten #75 Thread.

Was ich problematisch finde, ist, das in den FB/FC die rel. große (alle) Datenmengen hin- und herkopiert werden, zusätzlich noch aus der HMI heraus damit gearbeitet wird und dann am Besten auch noch Querzugriffe aus anderen Bausteinen erfolgen (denn das wird dann auch noch kommen). Das kann man machen, wer das System kennt, findet sich wahrscheinlich auch zurecht, zumindest am Anfang. Wenn aber ein "nicht eingeweihter" dort irgend etwas sucht, dann wird er Schwierigkeiten haben. Außerdem ist jede kleine Änderung von einer Orgie an roten Bausteinaufrufen, neu zu erzeugenden und zu übertragenden FB/DB usw. begleitet. Das mag in der Erstellungsphase der Software noch ok sein, wenn aber vor Ort eine kleine Änderung nötig ist, anschließend aber jede Menge Bausteine übersetzt und in die SPS übertragen werden müssen und schlußendlich die HMI nicht mehr korrekt arbeitet, weil dort nicht alle Änderungen mitgelaufen sind, dann wird es wirklich interessant. Ähnliches hat man ja auch bei Graph7, jede kleine Änderung zieht einen Rattenschwanz hinter sich her, aber da ist das noch recht übersichtlich, weil wirklich komplett gekapselt.
Ist nicht so lange her, da habe ich mit einem solchen Konzept gearbeitet. Wirkliche Probleme traten erst ganz am Schluß richtig zutage, man hatte es einfach unglaublich schwer die Stelle zu finden, an der das Programm irgendein Bit schlußendlich beeinflußt hat. Wenn das so ist, dann pfeife ich auf eine schnelle und einfache Projektierungsphase und mache mir lieber da 10 Mal soviel (Hand) Arbeit mit einzeln korrekt ausprogrammierten Bausteinen, als später in dem Wust von IDB-, HIM-, FB-, Umkopierabhängikeiten nach Fehlern zu suchen. Ich bin an der Stelle tatsächlich absolut konservativ und halte die neunen Ideen nicht unbedingt immer für die besten Ideen, dafür habe ich schon zu oft im (mal gut gedachten) Mist anderer rumrühren dürfen.

PS: Ich packe natürlich auch das zusammen, was zusammengehört, aber das muß nicht alles in einen IDB, der dann von 5 Seiten aus befummelt wird.


----------



## JOHKU (4 September 2012)

@Alle,

Meine Herren,
dieses Thema ist wieder ein Typisches Beispiel wie hier in diesem Forum diskutiert wird und es ehrt uns nicht. 
Fakt ist dass, die Siemens Steuerungen durchaus über ein eingebautes und vom System unterstütztes Meldeverfahren, Variablenarchivierung und Beobachtungskonzept verfügen.
Zum Beispiel: Simatic Manager->Extras->CPU Meldungen  oder HW-Konfig ->Systemfehler Melden.
Da wundert man sich welche Meldungen automatisch über ALARM-S generiert werden und von Zauberhand an einem Panel erscheinen können.
Dass es Keine Tools gibt gehört auch mehr zu den Legenden die sich hartnäckig halten.
Nutzt man CFC in Kombination mit WinCC werden alle Variablen, und jetzt kommt es, aus den IDB´s angelegt. Der Begriff nennt sich AS-OS Engineering und kommt von PCS7, ist jedoch im Standard auch vorhanden.
Hierfür müssen jedoch die IN/OUT Variablen der FB’s über entsprechende Attribute gekennzeichnet werden. (FB Öffnen, Rechte Maustaste auf einen IN oder OUT Parameter, Objekteigenschaften-> Reiter Attribute;  dies geht selbst mit Know-How geschützten FB´s dritter)
Das Thema ist nicht trivial aber lohnend und kann mit etwas Arbeit aus den Hilfetexten entnommen werden.
Gruß
Johannes


----------



## Ralle (4 September 2012)

@JOHKU

???? Das soll heißen ???


----------



## miasma (4 September 2012)

JOHKU schrieb:


> @Alle,
> 
> Meine Herren,
> dieses Thema ist wieder ein Typisches Beispiel wie hier in diesem Forum diskutiert wird und es ehrt uns nicht.
> ...



Vielen Dank für diesen Hinweis. An CFC habe ich auch schon gedacht aber wir nutzen kein PCS7. 
Ich weiß zwar das ich CFC auch ohne PCS7 nutzen kann. Aber nicht in welchen Umfang und ob ich dann auch alle Vorteile nutzen kann.


----------



## Larry Laffer (4 September 2012)

@Ralle:
hier mal ein Beispiel, was ich so meinte.
Das hat mit Zertreuung und Hin- und Herkopieren von Daten ziemlich wenig zu tun.
Der dargestellte FB201 kapselt komplett alles, was mit dem Zuführ-Handling zu tun hat. Bei diesem Beispiel ist allerdings die Schnittstelle auch noch relativ schlank. Es gibt schon auch Aggregate, die mehr an E/A's haben.
Die Schnittstelle ist deshalb noch nicht ausgefüllt, da der baustein aus einem in Entstehen begriffenen Programm stammt.

Anhang anzeigen 18224
Anhang anzeigen 18225


@Johku:
Ich würde sagen, dass die bislang Wenigsten geführten Diskussionen uns und das Forum entehren - Sorry ... und diese m.E. schon mal gar nicht ...

Gruß
Larry


----------



## Ralle (4 September 2012)

@Larry

Wohin gehen deine Fehlermeldungen?
Wenn SK_Main noch Schritte dazubekommen muß, verschiebt sich die SK_Handling. Wenn du nun das HMI daraufgesetzt hast, paßt das u.U. nicht mehr. Noch schlimmer, wenn ein IN dazukommt, dann verschiebt sich alles, auch der Stat-Bereich. Ohne Zugriffe von außen passiert ja nichts, genau dafür nutze ich einen FB ja auch. Wie löst du das?


----------



## Aventinus (4 September 2012)

Wo ist denn das Problem wenn sich alles Verschiebt. Da kommt dann wieder die symbolische Programmierung ins Spiel. Da wird alles automatisch nachgezogen - vorausgesetzt die Visu bindet die Varaiblen symbolisch an. Und genau das ist der Grund warum ich mit gegen absolute Zugriffe - auch in Ausnahmefällen - bis aufs Äusserste wehre.
Wenn es nach mir ginge hätte TIA keine Merker und keine Datenbausteine mehr. Es gäbe nur Variablen - global und lokal - mit Symbol, Datentyp und Kommentar.


----------



## Larry Laffer (4 September 2012)

Hallo Ralle,
die Fehlermeldungen gehen als Bit-Meldungen zur Zeit noch nach WinCCFlexibel.
Wenn ich in der SK_Main (oder anderen Schrittketten) noch Schritte dazu bekomme (was allerdings nur sehr selten passiert) dann verschiebt sich alles - klar. Genauso eine Erweiterung bei IN, OUT oder STAT. Das ist innerhalb des FB aber erstmal nicht von Relevanz, da ich ja von außen davon nichts benutze (außer über die Schnittstelle).
Die Visu zieht i.d.R. schon beim Aufrufen die Verbindungen glatt. Es muss aber dann neu übertragen (und generiert) werden - das ist nun mal so. Das wäre aber auf bei einer Änderung eines Global-DB ein Thema. Somit werte ich das nicht. Nachteile ergeben sich aus meiner Sicht (und das mache ich nicht erst seit Gestern so) nicht.

Bei dem gezeigten Beispiel ist das noch harmlos. Es gibt auch noch Stationen, die Parameter und Messwerte haben. Auch das sind vom Grundsatz her Visu-Variablen.

Das Schöne (für mich) bei diesem Konstrukt ist, das wir (3 Programmierer und 2 Elektriker) es verstehen und leben können - bei völlig unterschiedlichem "Skill".

Gruß
Larry

Nachsatz:
Ich lese gerade den Beitrag von Aventinus. das stimmt natürlich. Alle meine Variablen im FB werden natürlich nur sysmbolisch verwendet und auch die Anbindung der Visu erfolgt so - klar !!!


----------



## Aventinus (4 September 2012)

Larry Laffer schrieb:


> Nachsatz:
> Ich lese gerade den Beitrag von Aventinus. das stimmt natürlich. Alle meine Variablen im FB werden natürlich nur sysmbolisch verwendet und auch die Anbindung der Visu erfolgt so - klar !!!



Das sehen leider viele nicht so konsequent wie ich mir das wünschen würde.... hatte da auch schon ab und an böse Erfahrungen machen dürfen


----------



## rostiger Nagel (4 September 2012)

Wie gesagt mache ich es genauso wie LL und verstehe das ganze Geschrei nicht, 
>Das Programm ist nicht mehr zu warten<, das ist einfach Hysterie. In diesen Thread
ist noch kein aber absolut kein Argument geliefert, was dagegen sprechen würde. 

Mann muß halt mit einer andere Vorgehensweise an die Steuerung herangehen. 
Die Art der Kappelung, von der hier immer geredet wird trifft doch garnicht auf diese 
Beispiele zu und ist doch eher für Biblotheksbausteine gedacht, die zigmal in ihrer Art
im gleichen Programm verwendet werden, nicht für den FB der Individuell, für eine Funktion
erstellt wird. 

Ich bin eher der Ansicht dieses Hin und Herschaufeln von HMI Daten von Global in die
Instanz, macht das ganze noch eher unübersichtlicher. Wenn in der Instanz steht das die 
Daten der HMI gehören und auch nur von da gefüttert werden, was im Teufels Namen ist
den da nicht zu begreifen?

Wie LL schon beschrieben hat, wenn ein Global DB mit seinen Reserven mal an sein Grenzen 
gekommen ist und erweitert wird, muß die HMI sowieso neu übertragen werden. Wenn die 
Relervanten Maschinendaten, sinnvoller Weise, wie es sich eigentlich gehören tut, zusätzlich durch
eine Rezeptur gesichert werden, so macht es auch keine Probleme, den ganzen Bausteinordner
mal eben anzuklicken und in 3-10 sec. Arbeitsaufwand als ganzes rüber zu schubsen. Und danach
über die Rezeptur Verwaltung die Einstellwerte die Daten wieder herzustellen.


----------



## Perfektionist (4 September 2012)

miasma schrieb:


> Du meinst vermutlich die Funktion das Datenbausteine nur noch Symbolisch Adressierbar sind ?
> Das wäre eine feine Sache und würde auch gleichzeitig bedeuten das Siemens die Möglichkeiten seines Systems ausbaut.


Davon gehe ich aus. Entweder wird zu jedem Symbol ein feststehender Zeiger für die Visu und die Variable dann an einem festen Platz in der SPS gelegt und belassen, wobei hoffendlich im SPS-Zielspeicherbereich dann auch der Datentyp für die Visu vermerkt steht, oder die Visu sucht in der SPS das etsprechende Symbol mit dem dort stehenden Zeiger. mal schaun, wies wird, aber irgendeinen vernünftigen Sinn muss ja diese bereits bei der 1200er mögliche "optimierte Datenablage" haben.


----------



## Perfektionist (4 September 2012)

Ralle schrieb:


> Deine Äußerungen zeugen aber zumindest von einer gewissen Arroganz anderen Kollegen oder Firmen gegenüber.


@Ralle: also sowas muss doch nun wirklich nicht sein?

Ich kann das Ziel, das der TE verfolgt durchaus verstehen, bei mir hat sich diese Vorgehensweise bewährt. Wenngleich mir das Werkzeug dazu (S7 V5.5) noch nicht alle Möglichkeiten zur Verfügung stellt. Wenn ich es zum tausendsten mal hier wiederholen muss: bei mir ist der FC gestorben, Global-DB auch. Das sind Relikte aus S5-Zeiten. Wer dran festhält, hält an S5 fest. Da wird natürlich der Übergang zu V11 immer schwierig sein, für den, für den das morgen heute ein Übermorgen ist, weil er im gestern stehen geblieben ist.


----------



## Perfektionist (4 September 2012)

JOHKU schrieb:


> Fakt ist dass, die Siemens Steuerungen durchaus über ein eingebautes und vom System unterstütztes Meldeverfahren, Variablenarchivierung und Beobachtungskonzept verfügen.


Himmel, das suche ich schon geraume Zeit händeringend, ich bin leider beim Bitmeldeverfahren hängen geblieben und hatte nie Zeit, mich mit dieser Sache zu befassen.


PS:
@LL, RN und Aventinus: 100% Zustimmung


----------



## miasma (4 September 2012)

rostiger Nagel schrieb:


> Ich bin eher der Ansicht dieses Hin und Herschaufeln von HMI Daten von Global in die
> Instanz, macht das ganze noch eher unübersichtlicher. Wenn in der Instanz steht das die
> Daten der HMI gehören und auch nur von da gefüttert werden, was im Teufels Namen ist
> den da nicht zu begreifen?



Mein Reden. Wenn in einem STAT Bereich zwei Strukturen existieren die VISU_IN und VISU_OUT heißen ist das meiner Meinung nach wie ein Querverweis bzw. genauso Aussagekräftig.


----------



## Ralle (5 September 2012)

Ok, ich gebe es dann mal auf. LL und ich, wir reden offensichtlich aneinander vorbei und ich hab einfach keinen Bock mehr, immer wieder das Selbe durchzukauen. Es geht nicht um die Verteufelung von IDB, es geht einfach um einen vernünftigen Umgang damit. Ich wollte es noch einmal versuchen, aber ich habs nun einfach satt und das dusselige "political korrektness" Geschwafel von Perfektionist, das man in jedem zweiten Beitrag um die Ohren gewischt bekommt, geht mir so langsam tierisch auf den S... . Mir ist es eh wurscht, ich schmeiß gern mal die Software von megacleveren OOP's weg und schreib dafür ein Stück alten, primitiven, völlig uncoolen Code. Auch davon lebe ich nun mal.

Noch ein letzter Rat an miasma, "FB möglichst tief verschachteln, dann hat man nur einen einzigen IDB in der gesamten SPS. Auf diesen einen IDB, kann dann die HMI zugreifen lassen. Bei einer Änderung zieht die HMI automatisch nach (oder auch nicht). Und wer mal was sucht, der braucht ja nur in den einen IDB zu schauen.


----------



## Perfektionist (5 September 2012)

Ralle schrieb:


> ... und das dusselige "political korrektness" Geschwafel von Perfektionist, das man in jedem zweiten Beitrag um die Ohren gewischt bekommt, geht mir so langsam tierisch auf den S...


sorry, aber wenn jemand etwas anders macht (oder nur anders ist) meine ich, dies hinterfragen zu können (müssen?). Ihn dann statt in der Sache mit einem ad personam anzugehen ("du bist arrogant") halte ich nicht für zielführend.



Ralle schrieb:


> Noch ein letzter Rat an miasma, "FB möglichst tief verschachteln, dann hat man nur einen einzigen IDB in der gesamten SPS. Auf diesen einen IDB, kann dann die HMI zugreifen lassen. Bei einer Änderung zieht die HMI automatisch nach (oder auch nicht). Und wer mal was sucht, der braucht ja nur in den einen IDB zu schauen.


ich verstehe das nun als Ironie. Nur kann ich ihr leider nicht ganz folgen, da ich diesen Weg (zwar nicht konsequent und intensivstdogmatisch) folge. Leider kann mich Classic bei diesem Weg nur unzureichend unterstützen.

PS: @Ralle
auf der anderen Seite bin ich durchaus Deiner Meinung, dass so mancher OOP-Progammierer im Bereich Automatisierung über sein Ziel hinausschießt.


----------



## miasma (5 September 2012)

Im Endeffekt bin ich nur auf der suche nach einer Lösung die mir meine Arbeit erleichtert. Ich bin mir ziemlich sicher das mein Lösungsansatz für meine Probleme optimal ist aber auch gleichzeitig bewusst das meine Lösung in vielen Bereichen nicht funktioniert.  

Im Endeffekt habe ich ja das erfahren was ich wollte, es gibt Leute die ~genau so arbeiten und das anscheinend schon über einen längeren Zeitraum und damit sehr zufrieden sind.
Alle die anders,klassisch oder wie auch immer programmieren haben sicher auch für ihre Aufgaben die optimale Lösung gefunden und machen damit bestimmt auch einen sehr guten Job.

Das es zwei Meinungen zu dem Thema gibt war mir ja auch klar, aber nicht das es spaltet. Trotzdem Danke an alle.


----------



## JOHKU (5 September 2012)

miasma schrieb:


> Vielen Dank für diesen Hinweis. An CFC habe ich auch schon gedacht aber wir nutzen kein PCS7.
> Ich weiß zwar das ich CFC auch ohne PCS7 nutzen kann. Aber nicht in welchen Umfang und ob ich dann auch alle Vorteile nutzen kann.



CFC kann man auch ohne PCS7 nutzen. Ich nutze mittlerweile nur noch CFC. Im standard S7 ist sehr viel von der PCS7 Grundfunktionalität vorhanden und man kann sich ein sehr gutes "PCS 6,5" (nicht ganz PCS7) zusammenstellen. 

Gruß
Johannes


----------



## miasma (11 März 2013)

Als Nachtrag.

Bei der Umsetzung meines Vorhabens bin ich auf folgende Unterlagen von Siemens gestoßen 

http://support.automation.siemens.c...lib.csinfo&lang=de&objid=36435784&caller=view 

Eine direkte Verbindung zwischen S7  und VISU wird auch von Siemens praktiziert, wobei die Visu direkt in einen eigenen Bereich in die Instanz schreibt.
Die Handbücher und vor allem die Codebeispiele zeigen genau wie dies funktioniert.


----------

