# DB mit AUF öffnen braucht mann das heute noch?



## winnman (17 Februar 2011)

Warum kommen immer wider diese Befehle: AUF DBxy?
meines Wissens kann ich in Step7 einfach auf den DB zugreifen
zb U DB100.dbx100.0

warumm soll ich zuvor AUF DB 100 stellen?

zu S5 Zeiten war das was anderes.

klärt mich bitte auf.


----------



## Flinn (17 Februar 2011)

Ja, braucht man noch, manchmal.

Stichpunkte:
- indirekte Adressierung, Schleifen
- innerhalb von FC's mit parametrierbarem BLOCK_DB
- Zykluszeit sparen
- AUF DI100 kann man z.B. auch ganz gut brauchen
- "DB100." macht im Übrigen nichts anderes als "AUF DB100"

Wenn es geht, ziehe ich allerdings den vollqualifizierten Zugriff vor, allein aus Lesbarkeits- (Kommentare) und Referenzgründen.

Gruß
Flinn


----------



## Blockmove (17 Februar 2011)

Bei einfachen binären Verknüpfungen i(Kop - FUP) ist "Auf DBxxx" schlechter Stil.
Wenn du direkt zugreifst (U DB100.DX0.5), dann taucht das Datenbit auch korrekt im Querverweis auf.
Bei indiekten Zugriffen und Pointern ist "AUF DBxxx" nötig, da bei "einfachen" Pointern der DB nicht mit übergeben werden kann.

Gruß
Dieter


----------



## winnman (17 Februar 2011)

mann lernt immer wider dazu.

Mit Pointern hab ich normalerweise nicht´s zu tun.

Bei den Programmen an denen ich biher rumgebastelt hab ist mir das nie aufgefallen.

Bei uns steht eigentlich FUP und in "schwierigen" Fällen "einfache AWL" auf dem Vorderdrund.

Schwerpunkt ist immer: Aus dem Programmausdruck soll auch noch der einfache Betriebelektriker (da zähle ich mich auch noch dazu) die Funktion erkennen können.

Es lässt sich eigentlich alles damit lösen auch wenns Programmiertechnisch schönere Lösungen gäbe und eventuell ein bisschen aufwendiger ist.

Für Kommunikation, . . . lässt sich das alles so kapseln un d entsprechend kommentieren, dass auch das verständlich wird.


----------



## Blockmove (18 Februar 2011)

@winnman

Die "einfachen" Zeiten für Betriebselektriker neigen sich - meiner Meinung nach - dem Ende zu.
Warum:


Es wird immer mehr Funktionalität in SPS und HMI verlagert. An Anlagen an denen früher eine SPS und ein Leit-PC stand, ist jetzt eine SPS und ein Panel. Darüber laufen Berechnungen, Kommunikation und mehr.


Die Diagnosefunktionen für einfache Fehler werden immer besser. Eigentlich eine gute Geschichte aber: Der Elektriker kommt nur noch selten mit der Software in Berührung. In vielen Fällen hört es am Ein- oder Ausgang auf. Der Haken: Wenn es mal kompliziert wird, dann "kennt" der Elektriker die Anlage gar nicht.
Wenn ich mir die aktuellen Tendenzen anschaue, dann gibt es in Zukunft 2 Sorten Elektriker: Teilewechsler und Spezialisten. Drum schau dir auch mal intensiv die "gekapselten" Funktionen an.

Gruß
Dieter


----------



## winnman (18 Februar 2011)

wenns sein muss, dann komm ich schon mit den "gekapselten" zurecht, aber meine Kollegen stehen dann voll auf der Platte (meist auch schon bei ein bisschen einfacher AWL  drum bin ich auch hinter "Einfacher" Programmierung her


----------



## thomass5 (18 Februar 2011)

winnman schrieb:


> wenns sein muss, dann komm ich schon mit den "gekapselten" zurecht, aber meine Kollegen stehen dann voll auf der Platte (meist auch schon bei ein bisschen einfacher AWL  drum bin ich auch hinter "Einfacher" Programmierung her


... pass dich nur nicht zu sehr deinen Kollegen an.  ...

Thomas


----------



## vierlagig (18 Februar 2011)

thomass5 schrieb:


> ... pass dich nur nicht zu sehr deinen Kollegen an.  ...



... tendenz deutlich erkennbar ...


----------



## Perfektionist (18 Februar 2011)

ich brauche Global-DB gar nicht mehr ...


----------



## Ralle (18 Februar 2011)

Perfektionist schrieb:


> ich brauche Global-DB gar nicht mehr ...



Ich nutze Global-DB fast ausschließlich, weil ich das rumpoken in IDB für unsauber halte, mit gewissen Ausnahmen, die vom Softwaredesign abhängen. IDB sind für mich Lokaldaten, die sind auch in C# .Net und anderen Programmiersprachen nicht von außen zugänglich.


----------



## rostiger Nagel (18 Februar 2011)

dann währen wir ja wieder beim alten Thema, Pro und Kontra bzw.
Verwendung von Instanzdaten


----------



## vierlagig (18 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> dann währen wir ja wieder beim alten Thema, Pro und Kontra bzw.
> Verwendung von Instanzdaten



ging schneller als üblich


----------



## JesperMP (18 Februar 2011)

Ich verwende Global-DB sehr viel.
Der Grund ist schlussendlich das sehr viele von meine Parameter beobachtet oder geändert werden kann auf den HMI. Und wenn die Parameter mit ein HMI verknüpft sind, bin ich gewöhnt die Daten in wenige DBs zu sammeln.
Wenn erst erzeugt ändern diese Global-DBs sich sehr selten. 

Ich verwende auch Instanz-DBs, und "poken" problemlos mit die IDBs in andere Bausteine als die verknüpfte FBs. (Diese Diskussion hatten wir schon. Ich gehörte zu der Minderheit).
Die FBs und IDBs ändern sich relativ oft, und dank symbolisches programmieren wird es automatisch überall im program aktualisiert.

Zurück zum Thema.

Das low-level basteln mit DBs wird mehr oder weniger mit SCL abgelöst. In die nächste generation von STEP7 ist SCL als standard inkludiert (endlich !).
"Zykluszeit sparen" denke ich ist heute von sehr geringe bedeutung in verhältniss zu code das gut lesbar und einfach zu warten ist.


----------



## Ralle (18 Februar 2011)

vierlagig schrieb:


> ging schneller als üblich



War aber absehbar! *ROFL*


----------



## Ralle (18 Februar 2011)

JesperMP schrieb:


> Das low-level basteln mit DBs wird mehr oder weniger mit SCL abgelöst. In die nächste generation von STEP7 ist SCL als standard inkludiert (endlich !).
> "Zykluszeit sparen" denke ich ist heute von sehr geringe bedeutung in verhältniss zu code das gut lesbar und einfach zu warten ist.



Aber wenn das gut lesbar sein soll:



```
FOR I := 1 TO Anzahl DO
       Wert := DWORD_TO_DINT(WORD_TO_BLOCK_DB(INT_TO_WORD(DB_Nr)).DD[StartP+((I-1)*4)]);
...
```

Ich mein immer noch, für jedes Problem gibt es ganz sicher die jeweils besser geeignete Programmiersprache, speziell mal auf SPS abgestellt. Ich würde nie auf die Idee kommen, rel. komplexe bitorientierte Freigaben, z.Bsp. für Horizontalachsen in SCL auszuprogammieren, dafür ist dann doch KOP/FUP/AWL übersichtlicher.


----------



## rostiger Nagel (18 Februar 2011)

ähm, der Thread legt aber heute sehr schnell alle Problemme der
Automatisierung offen. Jetzt sind wir bei dem Punkt, was ist die Richtige
Programmiersprache.


----------



## vierlagig (18 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> ähm, der Thread legt aber heute sehr schnell alle Problemme der
> Automatisierung offen. Jetzt sind wir bei dem Punkt, was ist die Richtige
> Programmiersprache.



ich glaub aber, dass wir in absehbarer zeit zu "was ist die richtige hardware?" schwenken und dann geht der stellungskrieg erst richtig los...


----------



## Perfektionist (18 Februar 2011)

Ralle schrieb:


> ... rumpoken in IDB [...] unsauber ...


bei mir poked da nur die HMI (flexible) in den Instanzdaten rum. Querzugriffe gibt es nur über Schnittstelle abgewickelt oder bei global bedeutsamen Signalen über wenige Merker abgewickelt.


----------



## rostiger Nagel (18 Februar 2011)

vierlagig schrieb:


> ich glaub aber, dass wir in absehbarer zeit zu "was ist die richtige hardware?" schwenken und dann geht der stellungskrieg erst richtig los...


 
wobei ich ja finde, das in einer 400er instanzdaten besser genutzt werden
können wie in eine 300er. Die 400er hat ganz einfach die Status LED's
besser angeordnet. Dabei sollte mann beachten, das z.b. der Hans Beckhoff
bei der Entwicklung seiner Steuerung auf sämtliche DB's verzichtet hat.


----------



## JesperMP (18 Februar 2011)

Zum Thema


> Warum kommen immer wider diese Befehle: AUF DBxy?
> meines Wissens kann ich in Step7 einfach auf den DB zugreifen
> zb U DB100.dbx100.0
> warumm soll ich zuvor AUF DB 100 stellen?


Es gab bis die vorige Generation von CPUs eine merkbare Zykluszeit sparniss wenn man von DB100.DBX100.0 verzichtete. 
Mit die heutige Generation glaube ich das die Zykluszeit ist gleich oder fast gleich.

Es gibt andere Gründe dafür das man AUF verwenden wurde, aber mit SCL, UDTs und AT besteht dieser Gründe _meistens_ nicht mehr.


----------



## Perfektionist (18 Februar 2011)

Ralle schrieb:


> Ich würde nie auf die Idee kommen, rel. komplexe bitorientierte Freigaben, z.Bsp. für Horizontalachsen in SCL auszuprogammieren, dafür ist dann doch KOP/FUP/AWL übersichtlicher.


für Dich ist KOP/FUP/AWL übersichtlicher. Für Nichtelektriker ist SCL durchaus OK, die meiner Meinung nach für einen noch größeren Personenkreis verständliche Programmiersprache.


----------



## vierlagig (18 Februar 2011)

Perfektionist schrieb:


> für Dich ist KOP/FUP/AWL übersichtlicher. Für Nichtelektriker ist SCL durchaus OK, die meiner Meinung nach für einen noch größeren Personenkreis verständliche Programmiersprache.



wie groß muß denn der PK sein, der ein Programm versteht? bin ja jetzt och schon ne Weile unterwegs in Produktionsbetrieben und bisher waren es überall Elektriker (in unterschiedlichen Bildungsausprägungen) die sich um die Steuerungen und deren Software gekümmert haben und das find ich ok so. Ein reiner Programmierer sollte IMHO wenigsten die Grundkenntnisse haben um einen Schaltplan lesen zu können und wenn er das kann, dann kommt er prima mit KOP klar ...


----------



## bike (18 Februar 2011)

Ich habe bis heute noch keine vernünftig programmierte Schrittkette in SCL gesehen.

Für jede Aufgabe gibt es das richtige Werkzeug und das ist auch gut so.


bike


----------



## Perfektionist (18 Februar 2011)

vierlagig schrieb:


> ... Ein reiner Programmierer sollte IMHO wenigsten die Grundkenntnisse haben um einen Schaltplan lesen zu können und wenn er das kann, dann kommt er prima mit KOP klar ...


und ein Elektriker sollte IMHO irgendwann einmal im Leben auch drei Zeilen Basic, Pascal/Delphi und/oder C gesehen haben.

Hast Du in heutigen Stromlaufplänen ausser der Notaus-Kette (sofern nicht auf F-CPU verdrahtet) noch irgendwo was anderes gesehen als eine Hardware-Und-Verknüpfung? KOP ist tot. Genauso tot, wie einhängen und auflegen. Heute drückt man die Hörertaste, um ein Gespräch zu beginnen oder zu beenden.


----------



## vierlagig (18 Februar 2011)

Perfektionist schrieb:


> und ein Elektriker sollte IMHO irgendwann einmal im Leben auch drei Zeilen Basic, Pascal/Delphi und/oder C gesehen haben.
> 
> Hast Du in heutigen Stromlaufplänen ausser der Notaus-Kette (sofern nicht auf F-CPU verdrahtet) noch irgendwo was anderes gesehen als eine Hardware-Und-Verknüpfung? KOP ist tot. Genauso tot, wie einhängen und auflegen. Heute drückt man die Hörertaste, um ein Gespräch zu beginnen oder zu beenden.



totgesagte leben länger.
wer KOP für tot erklärt hat das wesentliche, nämlich das es für jede aufgabe das richtige werkzeug gibt, nicht verstanden.
eben durch die verlagerung der logik aus der schaltung in die steuerung ist da KOP für viele anwendungen sehr angebracht.
und beim erlernen des lesens von schaltplänen gehört das lesen lernen von und, oder und xor verknüpfungen ... jeder programmierer sollte auch eine hartverdrahtete stern-dreieck-schaltung verstehen!


----------



## thomass5 (18 Februar 2011)

Perfektionist schrieb:


> und ein Elektriker sollte IMHO irgendwann einmal im Leben auch drei Zeilen Basic, Pascal/Delphi und/oder C gesehen haben.



das eine schließt das andere noch lange nicht aus.



Perfektionist schrieb:


> KOP ist tot. Genauso tot, wie einhängen und auflegen. Heute drückt man  die Hörertaste, um ein Gespräch zu beginnen oder zu beenden.



Dein Telefon hat noch Tasten? 



Thomas


----------



## Perfektionist (18 Februar 2011)

vierlagig schrieb:


> ... jeder programmierer sollte auch eine hartverdrahtete stern-dreieck-schaltung verstehen!


nein, muss er nicht. Und er muss auch nicht einen Umrichter verstehen können.


----------



## rostiger Nagel (18 Februar 2011)

die Schlammschlacht ist im Gange 

ich denke schon, das es beim Programmieren *sehr* Hilfreich ist wenn mann
Technische Zusammenhänge versteht,  damit meine ich Verhalten von 
Technischen Einrichtungen wie Mechanisch, Elektrisch, Pneumatisch und Hydraulisch,
wenn mann sich den im Maschinenbau bewegt.

Programmiert mann in der Chemie, ist es gut zu wissen wie da die Prozesse
ablaufen. Bewegt mann sich in der Klimatechnik, ist es auch gut zu wissen
bei welcher Temperatur und Luftfeuchtigkeit es ein Mensch, dieses als Kalt
empfindet.

Der nur reine Programmierer, egal wie gut er Programmieren kann, wird
schnell an seine Grenzen kommen, wenn kein Technisches Verständnis 
da ist.


----------



## Tigerente1974 (18 Februar 2011)

Da gibt es wohl kein "schwarz oder weiss".

Vor den PGs sitzen:

1. Elektriker die mal in der Ausbildung etwas über S7 gehört haben und auch mal ein paar Zeilen geschrieben haben...

2. Elektriker die mit der Zeit mal ein paar Zeilen mehr geschrieben haben und auch schon mal einer "if-Anweisung" begegnet sind

3. Elektriker/Techniker die in einem kleinen Unternehmen arbeiten und von Verdrahtung bis zur Inbetriebnahme alles machen (müssen) <-- ICH 
	

	
	
		
		

		
			





4. Programmierer die in einem fensterlosen Raum sitzen und nichts anderes machen als Code zu schreiben 

Diese Liste kann man wohl noch beliebig verfeinern...
Typ No#1 wird wohl nicht sehr bald was mit SCL o.ä. machen
Typ No#4 wird wohl nicht sehr bald eine Stern-Dreieck-Schaltung anschließen.


----------



## vierlagig (18 Februar 2011)

Perfektionist schrieb:


> nein, muss er nicht.



muss er wohl, denn wenn er diese einfachste logik nicht kapiert, wie soll er dann komplexe zusammenhänge abbilden können?


----------



## bike (18 Februar 2011)

Perfektionist schrieb:


> nein, muss er nicht. Und er muss auch nicht einen Umrichter verstehen können.



Das verstehe ich nicht.
Also ich denke, er muss verstehen, welches Ergebnis herauskommen soll und dieses Ergebnis muss er auch kontrollieren können.
Sonst ergeht es den Steuerungen wie Win$ und ich finde es uncool, wenn  beim Werkzeugwechsel die Spindel mit Vollgas Richtung Wechsler fährt ein  Neustart notwendig wird. Abgesehen von den Kosten ist es ein echt  schlechtes Image für den Lieferanten. 
Unsere Studies oder Neuling dürfen für ca ein halbes Jahr durch die  Fertigung und Herstellung, damit sie wissen was später ihre Aufgabe sein  wird. 

In der Steuerungstechnik sind mir bisher keine reinen Theoretiker begegnet.
Eine Maschine oder Anlage so zu abstrahieren, dass ohne  Hintergrundwissen diese programmiert werden kann, ist denke ich nicht  möglich.
Das ist auch daran zu sehen, dass es für Maschinen und komplette Anlagen keine 100% Zuverlässigkeit von Simulationen gibt.


bike


----------



## vierlagig (18 Februar 2011)

bike schrieb:


> In der Steuerungstechnik sind mir bisher keine reinen Theoretiker begegnet.



mir schon, aber dementsprechend sieht zum einen die automatisierungslösung aus und arbeitet zum anderen sehr abstrakt zuverlässig...


----------



## bike (18 Februar 2011)

vierlagig schrieb:


> mir schon, aber dementsprechend sieht zum einen die automatisierungslösung aus und arbeitet zum anderen sehr abstrakt zuverlässig...



Sorry, habe vergessen zu schreiben, der eine gute, zuverlässige Anlage programmiert hat.


bike


----------



## Perfektionist (18 Februar 2011)

vierlagig schrieb:


> ... jeder programmierer sollte auch eine hartverdrahtete stern-dreieck-schaltung verstehen!


OK, ich weiß jetzt, wo unser Missverständnis liegt. Du meintest wohl:





> ]... jeder programmierer sollte BEI BEDARF auch eine hartverdrahtete stern-dreieck-schaltung verstehen KÖNNEN!


und ich meinte:





> ... muss nicht verstanden haben, bevor er das Verständnis dafür braucht.


 
So, nun schlag ich mich fluchs auf die Seite der Softwareentwickler und behaupte, dass der von Elektrik garnichts zu verstehen braucht, nichtmal, dass da Strom durchs Kabel fließt. Es reicht vollständig aus, zu wissen, dass eine Anweisung "Ausgang:=true" zu einer entsprechenden Bewegung im Prozess führt.


----------



## Paule (18 Februar 2011)

vierlagig schrieb:


> Ein reiner Programmierer sollte IMHO wenigsten die Grundkenntnisse haben um einen Schaltplan lesen zu können und wenn er das kann, dann kommt er prima mit KOP klar ...


Also UG hat es mal so auf den Punkt gebracht: 
http://sps-forum.de/showpost.php?p=79206&postcount=21


----------



## vierlagig (18 Februar 2011)

Paule schrieb:


> Also UG hat es mal so auf den Punkt gebracht:
> http://sps-forum.de/showpost.php?p=79206&postcount=21



...und globalDBs verteufeln ist für nägellackierer ...


----------



## Perfektionist (20 Februar 2011)

vierlagig schrieb:


> ...und globalDBs verteufeln ist für nägellackierer ...


mangelt es Dir an Selbstwertgefühl? Ich hoffe doch, dass Paule mit dem UG-Zitat nur darstellen wollte, dass es mehr Leute in diesem Forum gibt/gab, die KOP für entbehrlich halten. Oder fühlst Du Dich tatsächlich persönlich angepisst, wenn es da noch einen gibt, der Deine Meinung nicht teilt?

für die, die diesem Forum noch nicht lange genug beiwohnen: der Nägellackierer bin ich. Der Kollege 4L meint damit also einen bestimmten MANN, keine Frauen ...


----------



## bike (20 Februar 2011)

Perfektionist schrieb:


> mangelt es Dir an Selbstwertgefühl? Ich hoffe doch, dass Paule mit dem UG-Zitat nur darstellen wollte, dass es mehr Leute in diesem Forum gibt/gab, die KOP für entbehrlich halten. Oder fühlst Du Dich tatsächlich persönlich angepisst, wenn es da noch einen gibt, der Deine Meinung nicht teilt?



Eine Meinung ist die eine Seite, doch einfach pauschal was in Runde kippen ist etwas anderes.
Es gibt kein Einheitswerkzeug, der Schlosser und der Chirurg verwenden verschiedene Werkzeuge für ihre Aufgaben. 
So ist auch beim Programmieren, es gibt nicht die Programmiersprache für alles.

Wenn dem so ist, dann bitte informiert mich und andere und schreibt dazu auch warum dies die einzig notwendige und sinnvolle Programmiersprache ist.

Danke


bike


P.S: Und es gibt keinen vernünftigen Grund auf Global DB's zu verzichten


----------



## IBFS (20 Februar 2011)

bike schrieb:


> P.S: Und es gibt keinen vernünftigen Grund auf Global DB's zu verzichten


 
Die SIEMENS-DBs sind für mich die beste IDEE, die SIEMENS je hatte,
noch vor der E-LOK von SIEMENS & HALSKE 
[http://www.deutsches-museum.de/sammlungen/ausgewaehlte-objekte/meisterwerke-i/e-lok/]

Frank


----------



## Perfektionist (20 Februar 2011)

bike schrieb:


> Und es gibt keinen vernünftigen Grund auf Global DB's zu verzichten


doch: Kapselung.


----------



## IBFS (20 Februar 2011)

Perfektionist schrieb:


> doch: Kapselung.


...Verpuppung oder Cocooning...


----------



## MSB (20 Februar 2011)

Perfektionist schrieb:


> doch: Kapselung.



Nur weil du die Instanz-DBs als Global-DBs vergewaltigst heißt das noch gar nichts.


----------



## Perfektionist (20 Februar 2011)

MSB schrieb:


> Nur weil du die Instanz-DBs als Global-DBs vergewaltigst heißt das noch gar nichts.


aber wenn Du einen Global-DB für einen FC als Instanz vergewaltigst ist das OK?


----------



## IBFS (20 Februar 2011)

Perfektionist schrieb:


> aber wenn Du einen Global-DB für einen FC als Instanz vergewaltigst ist das OK?


 
Dann ist es  - lt. Definition - ja keine Instanz mehr, sondern schlicht MEMORY


----------



## bike (20 Februar 2011)

Perfektionist schrieb:


> doch: Kapselung.



Also kapseln ist gut, doch wo bleibt dann die Maschine?




Perfektionist schrieb:


> aber wenn Du einen Global-DB für einen FC als Instanz vergewaltigst ist das OK?



Also das versteh ich jetzt nicht. 
Was hat es mit Vergewaltigung zu tun, wenn ein Datenspeicher benutzt wird?

Kapsel weiter, denn die einzelnen Kapseln haben ja bei dir offensichtlich nichts zu tun und dümpeln so nebeneinander her.
Also in unseren Programmen müssen Daten zwischen einzelnen Teilen ausgetauscht werden und dafür gibt es Globale DB.

Also für alles das RICHTIGE Werkzeug und gut ist es.


bike


----------



## MCerv (20 Februar 2011)

Na das sind ja eine hitzige Diskussionen. Ich will auch mal meinen Senf dazugeben und aus meinen über 15 Jahren Programmier- und Inbetriebnahme-Erfahrungen von Anlagen sprechen:

Reine Progammierer ohne praktisches Hintergrundwissen der Technik haben für mich nichts an Anlagen zu suchen! Es kommt immer mal vor, das man handwerklich tätig werden muss. Nur hinterm Lappi verstecken ohne nur ansatzweise zu verstehen wie das Signal zustande kommt und welche Fehler im technischen Detail stecken. Nein Danke Theoretiker.

Dann wurde hier mal erwähnt das der "normale" Betriebselektriker ein Programm nicht mehr lesen kann, wenn es zu kompliziert wird. Da muss ich mal ehrlich sagen, wenn die Anlagen sehr komplex sind, dann kommt man immer öfter nicht um "höhere" Programmiertechniken herum. Wenn der gute Mann das Programm lesen soll (soll? ich frag mich nur warum!), dann gibt es halt Kurse und Bücher die einem das nötige Wissen vermitteln. Wenn der BE an die Anlage kommt, dann liegt ein Fehler vor, und regulär sind die Fehler in der Hardware. Oft treffe ich jedoch auf BE's, die die Anlagen so gut wie gar nicht kennen und dann wollen Diese auch noch an die Software? Das kann nur im Chaos enden! Wir "Experten" nutzen diese Techniken ja nicht ohne Grund, sondern weil wir die Anlagen effizient umsetzen wollen. Unsere Kunden, Eure Cheffs verlangen diese Anlagen.

Jetzt mal zurück zum Anfang:
Der "AUF"-Befehl ist doch legitim, klarer Anwendungsfall ist die indirekte Adressierung. Einsatzbereich: In Unterprogrammen!

Zugriff auf Instanz-DB's ist für mich ein Zeichen für unprofessionelles Programmieren. Eine Unachtsamkeit und das Chaos ist vorprogrammiert. Kurz: NEIN DANKE!

KOP/FUP/AWL/SCL/Graph: Alles schöne Darstellungsarten, für alle gibt es das optiomale Einsatzgebiet.

Und noch ein Blick in meine Kristallkugel:
Für einfache Anwendungen wird es nach wie vor den KOP/FUP geben.
Anspuchsvollere Aufgaben werden mit SCL und Graph gelöst.


----------



## vierlagig (20 Februar 2011)

Perfektionist schrieb:


> mangelt es Dir an Selbstwertgefühl? Ich hoffe doch, dass Paule mit dem UG-Zitat nur darstellen wollte, dass es mehr Leute in diesem Forum gibt/gab, die KOP für entbehrlich halten. Oder fühlst Du Dich tatsächlich persönlich angepisst, wenn es da noch einen gibt, der Deine Meinung nicht teilt?
> 
> für die, die diesem Forum noch nicht lange genug beiwohnen: der Nägellackierer bin ich. Der Kollege 4L meint damit also einen bestimmten MANN, keine Frauen ...



*ROFL**ROFL**ROFL*

lies meine signatur...  mehr ist dazu nicht zu sagen


----------



## Perfektionist (20 Februar 2011)

vierlagig schrieb:


> *ROFL**ROFL**ROFL*
> 
> lies meine signatur...  mehr ist dazu nicht zu sagen


also können wir 8266 Beiträge löschen lassen, da sie ohnehin nicht ernst gemeint waren?


----------



## Perfektionist (20 Februar 2011)

MCerv schrieb:


> Und noch ein Blick in meine Kristallkugel:
> Für einfache Anwendungen wird es nach wie vor den KOP/FUP geben.


... und der ELTAKO wird ebensolange bestehen bleiben (welcher Kranke würde denn statt dessen eine Logo einsetzen wollen?).


----------



## bike (20 Februar 2011)

Perfektionist schrieb:


> ... und der ELTAKO wird ebensolange bestehen bleiben (welcher Kranke würde denn statt dessen eine Logo einsetzen wollen?).



Dieser Vergleich der hinkt.
Wenn jemand alles in SCL und ohne Globale DB  schreiben kann, okay.
Doch wie werden zwischen den Funktionen Daten ausgetauscht?
Wie werden Abläufe programmiert?

Also ich und auch meine Kollegen können und, was noch wichtiger ist, wollen dies nicht.

bike

P.S: warum gibt es für F-Steuerungen kein SCL? Warum braucht man für den Datenaustausch Globale DB?
P.S.S: Bin wohl nicht auf dem Stand der Technik


----------



## Perfektionist (20 Februar 2011)

@IBFS und bike:
ja, wie strukturiert Ihr dann? Einen Steuerung = eine Maschine? Dann brauchts natürlich keine Lokaldaten mehr ...

und wieso antwortet da schon wieder ein IBFS auf meinen Kommentar zu MSB? Kannst Du Deine Papageien nicht mehr auseinander halten?


----------



## bike (20 Februar 2011)

Perfektionist schrieb:


> @IBFS und bike:
> ja, wie strukturiert Ihr dann? Einen Steuerung = eine Maschine? Dann brauchts natürlich keine Lokaldaten mehr ...
> 
> und wieso antwortet da schon wieder ein IBFS auf meinen Kommentar zu MSB? Kannst Du Deine Papageien nicht mehr auseinander halten?




Ich denke wir müssen uns darauf einigen was Maschinen und was Anlagen sind.

10 CNC Maschinen mit einer Steuerung geht eigentlich nicht wirklich.
Und Anlagen werden schon in sich strukturiert, doch zwischen den Teilen wird über Globale DB Daten ausgetauscht.
Es geht nicht anders. 
Außerdem, wenn mehre Menschen an einem Projekt arbeiten, müssen Nahtstellen definiert werden, wo jeder sich daran halten muss.
Dafür gibt es Globale Datenbausteine.

Aber du kannst ja alles in IDB und SCL machen, du bist ein Held.


bike


P.S:Warum persönlich angreifst, diesmal nicht mich, finde ich nicht gut. Ich würde es fachlich versuchen.


----------



## MSB (20 Februar 2011)

Ich hab ja nichts gegen Kapselung, mache ich auch, gelegentlich übertreibe ich damit sogar.

Aber es gibt irgend einen Datenbereich, den entweder alle Anlagenteile benötigen,
oder Datenbereiche von Station 1->2 ... und das sind dann eindeutig Globaldaten, und somit auch Global-DB.

Auch bin ich ein Skeptiker, mit HMI-Zugriffen, insbesondere Schreibenden, in Instanz-Daten rumzufingern.


----------



## Perfektionist (20 Februar 2011)

bike schrieb:


> Doch wie werden zwischen den Funktionen Daten ausgetauscht?


wieso - kennt SCL keine Schnittstellen?


bike schrieb:


> Warum braucht man für den Datenaustausch Globale DB?


Wer stellt diese Frage? ich dachte, ich hätte diese Frage gestellt?


----------



## Perfektionist (20 Februar 2011)

bike schrieb:


> Warum persönlich angreifst, diesmal nicht mich, finde ich nicht gut. Ich würde es fachlich versuchen.


darf ich mich dagegen verteidigen? wen, wenn nicht Dich, habe ich angegriffen?


----------



## bike (20 Februar 2011)

Wenn du zitierst, dann bitte richtig, danke.

Ich schrieb doch schon, dass du ein Held bist.
Was brauchst du noch mehr?

Danke fürs Gespräch.


bike


----------



## Perfektionist (20 Februar 2011)

MSB schrieb:


> Aber es gibt irgend einen Datenbereich, den entweder alle Anlagenteile benötigen,
> oder Datenbereiche von Station 1->2 ... und das sind dann eindeutig Globaldaten, und somit auch Global-DB.


sehr richtig ...

... und an der Stelle gehe ich den Weg, dass ich sage: diese Globaldaten befinden sich in der Instanz des aufrufenden Bausteins. Da OB1 keine Instanz hat (ausser den Merkern etc.) steht bei mir im OB1 sinngemäß: call FB1 ("Steuerung"), DB1 ("Steuerung_Instanz"). Und alle diese Globaldaten stehen in eben diesem DB1. Und werden von dort aus via Schnittstelle zu den Unterinstanzen weiterverteilt oder eben auch wieder an oberster Ebene eingesammelt.

Und jetzt? jetzt brauch ich keinerlei Global-DB mehr.


----------



## Perfektionist (20 Februar 2011)

bike schrieb:


> Wenn du zitierst, dann bitte richtig, danke.
> 
> Ich schrieb doch schon, dass du ein Held bist.
> Was brauchst du noch mehr?
> ...


entschuldige bitte, dass ich das nun überhaupt nicht nachvollziehen kann. Ich rate Rätsel, ob nun ich und/oder Du nicht neurotypisch ist/sind.


----------



## IBFS (21 Februar 2011)

Perfektionist schrieb:


> und wieso antwortet da schon wieder ein IBFS auf meinen Kommentar zu MSB? Kannst Du Deine Papageien nicht mehr auseinander halten?



@Perfektionist
Geh mal ne Woche in die Sonne oder Skifahren. Dein depressives 
Gerede ist echt zu bemitleiden, das passt zum Blick deines AVATARS.

Wäre vielleicht besser du hättest Papageien, die sind so schön bunt
und lebendig und nicht grauschwarz. 

Frank


----------



## Jochen Kühner (21 Februar 2011)

MSB schrieb:


> Auch bin ich ein Skeptiker, mit HMI-Zugriffen, insbesondere Schreibenden, in Instanz-Daten rumzufingern.



Ich hab wenn Ich das brauche ne extra Struktur im FB welche Ich so benenne das man erkennt das darauf Zugriff von der Visu aus erfolgt!


----------



## maxi (21 Februar 2011)

bike schrieb:


> Ich habe bis heute noch keine vernünftig programmierte Schrittkette in SCL gesehen.
> 
> Für jede Aufgabe gibt es das richtige Werkzeug und das ist auch gut so.
> 
> ...


 
Hallo,

ich hatte mal eine Anwendung mit einem Compiler. Glaube war von Fa. Christ.
Exceel Tabelle in SCL.

Das Ergebniss sah nicht schlecht aus.


Villeicht aber auch nur eine Ausnahme.

Grüße


----------



## MCerv (21 Februar 2011)

Diese ganze Diskussion könnte man auch mit
"*Viele Wege führen nach Rom*"
beschreiben!

Wie ich schon bereits geschrieben habe, von direkten Zugriffen auf Instand-DB's halte ich überhaupt nichts, wie jedoch ansonsten die Maschinen / Anlagen automatisiet werden, das muss der Hersteller immer im Einzelfall selbst entscheiden werden. Schließlich muss er das Projekt realisieren und garantieren!


----------



## bike (21 Februar 2011)

maxi schrieb:


> Hallo,
> 
> ich hatte mal eine Anwendung mit einem Compiler. Glaube war von Fa. Christ.
> Exceel Tabelle in SCL.
> ...



So etwas ähnliches haben wir auch einmal getestet, auch selbst entwickelt, doch an solch einem Konstrukt eine Änderung zu machen ist mehr als schwierig.
Das entstandene Programm war, zumindest bei uns, nicht lesbar ohne den Ausgangsskript.

bike


----------



## Perfektionist (21 Februar 2011)

IBFS schrieb:


> ... passt zum Blick deines AVATARS.


hast Du schon mal Deinen Avatar betrachtet? da könnte mir das Grausen kommen. Dagegen ist das Tagpfauenauge recht hübsch anzusehen.


----------



## klaly (21 Februar 2011)

Hallo Winnman, 



winnman schrieb:


> Warum kommen immer wider diese Befehle: AUF DBxy?
> meines Wissens kann ich in Step7 einfach auf den DB zugreifen
> zb U DB100.dbx100.0
> warumm soll ich zuvor AUF DB 100 stellen?
> ...



ich wollte mal wieder zum eigentlichem Thema zurück kommen.


U     DB100.DBX  100.0

// äquivalent zu

AUF   DB   100
U     DBX  100.0

Wenn du  U DB100.DBX 100.0 in den Editor schreibst, dann werden eigentlich zwei MC7 Befehle generiert, nämlich AUF DB100 und U DBX 100.0

D.h. es geht gar nicht ohne AUF DB, bzw. bei diesen Befehlen ist "immer" ein AUF DB mit dabei.

Siehe hierzu auch beigefügtes Bild mit einer Hex Ansicht des MC7 Bausteincodes. 

Im Übrigen ist S5 und S7 zieimlich verwand, das fängt schon bei der 7070 Kennung am Bausteinanfang an. Natürlich wurde beim MC7 Code noch einiges an Funktionalität dazu gebaut.

mfG. klaly


----------



## klaly (21 Februar 2011)

Uload des Hexdump hat nicht geklappt, daher hier in textform: 

MC7 Code der U DB100.DBX100.0:

Code         Befehl
2064         AUF DB   100
0040 0064  U    DBX 100.0


MC7 Code der AUF DB100 und U DBX100.0:

Code         Befehl
2064         AUF DB   100
0040 0064  U    DBX 100.0

beidesmal das gleiche.

mfG. klaly


----------



## Perfektionist (21 Februar 2011)

wofür Global-DB? jedenfalls nicht wegen der HMI ...

was spricht dagegen, direkt in der Instanz mit der HMI zuzugreifen? Dass der Zugriff von S7 aus nicht erkennbar ist, ist ein Manko, das sich seitens des Enwicklungssystems abstellen lässt. Oder man macht es eben wie Jochen und ich, also die HMI Variablen als solche kenntlich.

Für den Direktzugriff der HMI in der Instanz spricht, dass dadurch der Rangieraufwand an der Schnittstelle eines Bausteins entfällt. Letztlich bildet diese Vorgehensweise nur ab, dass in der SPS virtuell eine SPS entsteht. Hatte man in der Vergangenheit vielleicht mehrere Steuerungen, die die jeweiligen Teilprozesse kontrollierten, in der ganz klassischen Variante mit Schaltern, Lampen etc. an der EA angeschlossen, so kam irgendwann der Tag, als HMI Geräte (Coros, Protool, Flex) direkt in der SPS auf Speicherbereiche zugriffen, also der Zugriff nicht mehr über physikalische EA erfolgte. Dieser Zustand wird heute nicht mehr in Frage gestellt. Nun lassen wir einmal die SPS in der SPS entstehen. Eine virtuelle SPS eben. Bestehend aus gekapseltem FB und seiner Instanz. Klassisch würde man nun die HMI an die Schnittstelle ankoppeln wollen. Warum aber, wenn man bei einer realen SPS erlaubt, dass die HMI direkt in die internen Daten zugreift, warum aber will man der HMI nicht erlauben, in die Instanz einer virtuell erstellten SPS zuzugreifen?


----------



## bike (21 Februar 2011)

Zur Klärung:
*
Instanz* ist eine abgeschlossene Einheit

so zumindest in der allgemeine Literatur.
Und so soll es auch sein und bleiben

bike


----------



## Approx (21 Februar 2011)

Ist noch gar nicht lange her, da wurde das Theaterstück "IDB oder nicht IDB, das ist hier die Frage" schon einmal aufgeführt. Mit ähnlicher Besetzung und ähnlichem Verlauf.
Siehe http://www.sps-forum.de/showthread.php?t=41580

Also Jungs, warum ständig das selbe Heu durchkauen?


----------



## Perfektionist (21 Februar 2011)

bike schrieb:


> *Instanz* ist eine abgeschlossene Einheit


das klärt noch immer nicht, was zu einer (in sich) abgeschlossenen Einheit alles dazugehören darf.


----------



## Perfektionist (21 Februar 2011)

Approx schrieb:


> Also Jungs, warum ständig das selbe Heu durchkauen?


kannst Du auch etwas zur Sache beitragen?

EDIT: sorry, ich hätte Deinem Link folgen sollen, ich hatte hinter dem Link eine andere Diskussion erwartet.


----------



## maxi (21 Februar 2011)

bike schrieb:


> Zur Klärung:
> 
> *Instanz* ist eine abgeschlossene Einheit
> 
> ...


 

Instanz ist dass, wenn man in World of Warcraft zu mehreren in einen Dungeon geht. Da bin ich mir ganz sicher


----------



## winnman (21 Februar 2011)

Hallo klaly,

Danke für die Detailinfos.
Das ist doch genau das was ich eigentlich meinte:
Warum soll ich extra Auf. . . schreiben, wenn der Compiler das doch selbst macht?

bin mittlerweile schon ganz schön beeindruckt welche Wellen mein Thread schlägt, immerhin schon 72 Beiträge


----------



## bike (21 Februar 2011)

winnman schrieb:


> Hallo klaly,
> 
> Danke für die Detailinfos.
> Das ist doch genau das was ich eigentlich meinte:
> ...



Du solltest nicht AUF DB schreiben.
Denn im Querverweis erscheint ein Vollzugriff auf einen DBxx.DBXyy.y
bei AUF DB nicht. 

Also außer bei PointerOperationen ist es nicht notwendig mit AUF zu arbeiten.

Solch ein Threat entwickelt sich eben 

bike


----------



## Onkel Dagobert (21 Februar 2011)

winnman schrieb:


> ..Warum soll ich extra Auf. . . schreiben, wenn der Compiler das doch selbst macht?..


Wenn du zwanzig mal in einem Baustein vollqualifiziert auf Variablen eines DBs zugreifst, dann wird zwanzig mal "AUF DB" ausgeführt. Öffnest du jedoch einmal den DB am Anfang des Bausteins und greifst anschließend zwanzig mal absolut adressiert auf die Variablen zu, dann wird "AUF DB" nur ein einziges mal ausgeführt. Das ist einer der Gründe, wofür es den AUF-Befehl gibt. Wie schon weiter oben erwähnt wurde, ist diese Art der Sparsamkeit bei den heutigen CPUs nicht mehr relevant.

Ein weiterer Grund ist wahrscheinlich die Konvertierbarkeit von Step5 zu Step7.


btw:
Zu meinen Grundprinzipien gehört es, NICHT auf Instanzdaten von außen zu zu greifen. An meinen Grundprinzipien muß sich aber niemand orientieren ;-) .


----------



## bike (21 Februar 2011)

maxi schrieb:


> Instanz ist dass, wenn man in World of Warcraft zu mehreren in einen Dungeon geht. Da bin ich mir ganz sicher



Ja klar, also du gehst in eine abgeschlossene Einheit, die von außen nicht beeinflusst wird.

Den Widerspruch, wenn vorhanden,  erkenne ich jetzt nicht.


bike


----------



## Paule (21 Februar 2011)

Also so bald symbolisch Programmiert wird hat man immer ein Vollqualifizierten Zugriff.
Und alles andere ist Murks.
Wenn ich ein AUF DB ohne folgende indirekte Adressierung oder Schleife sehe, könnte ich :sb5:
Sprich folgendes geht bei Step 7 absolut nicht:

```
// [COLOR=red][B]!!! Verboten !!![/B][/COLOR] [COLOR=seagreen](persönliche Meinung)[/COLOR]
AUF DBx
L DW0
T DW2
```


----------



## Perfektionist (21 Februar 2011)

Onkel Dagobert schrieb:


> Ein weiterer Grund ist wahrscheinlich die Konvertierbarkeit von Step5 zu Step7.


da bin ich mir sogar sehr sicher ...



Onkel Dagobert schrieb:


> btw:
> Zu meinen Grundprinzipien gehört es, NICHT auf Instanzdaten von außen zu zu greifen. An meinen Grundprinzipien muß sich aber niemand orientieren ;-) .


OK, vielleicht sollte ich die hohen Ansprüche an mich selbst ebenfalls nicht an andere stellen ...
Und trotzdem empfinde ich den Zugriff der HMI auf die Instanz nicht als Zugriff von außen. Und ich komme mit einem Minimum an Globaldaten aus, so dass sich der Bedarf an Global-DB erübrigt (theoretisch könnten die von mir verwendeten Globaldaten in dem übergeordneten Koordinationsbaustein gehalten werden).


----------



## Onkel Dagobert (21 Februar 2011)

Hallo Perfektionist,

und wo speicherst du Sollwerte, Schaltzeiten? Auch in den Instanzdaten?


----------



## Perfektionist (21 Februar 2011)

Paule schrieb:


> Wenn ich ein AUF DB ohne folgende indirekte Adressierung oder Schleife sehe, könnte ich :sb5:


Hallo Paule,
die wahre Katastrophe darin sehe ich, dass es mit S7 nicht möglich ist, ein derartiges Konstrukt zu vermeiden.


----------



## Perfektionist (21 Februar 2011)

Onkel Dagobert schrieb:


> Hallo Perfektionist,
> 
> und wo speicherst du Sollwerte, Schaltzeiten? Auch in den Instanzdaten?


gemäß des Gedankens der Zusammengehörigkeit der Dinge: ja!

Wenn also eine in sich abgeschlossene Funktionseinheit (gibt es dafür ein allgemein bekanntes und verständliches Beispiel?) Parameter benötigt, so füttere ich diese nicht an der Schnittstelle damit, sondern greife mit der HMI (Flex!) direkt in der Instanz darauf zu. Ich betrachte dabei die betreffenden HMI-Bilder als zu dieser Funktionseinheit zugehörig.

Eine derartig in sich abgeschlossene Funktionseinheit könnte sein: eine Staustrecke (oder Speicherband genannt?), die eine Lichtschranke enthält, einen Antrieb, mit der nachfolgenden Anlage ein Freigabesignal austauscht, entsprechend der zuführenden Anlage signalisiert, ob die Station produktaufnahmefähig ist. Als Parameter kommt da eine Zeitdauer in Frage, die beschreibt, mit welcher Verzögerung der produktliefernden Seite das Freigabesignal erteilt wird. Also wird in der Schnittstelle des FB Aktor und Sensor auftauchen, ebenso das Handshake nach vorn und hinten. Und der Parameter dieser Verzugszeit würde bei mir in den Instanzdaten gehalten werden.


----------



## bike (21 Februar 2011)

Ich wünsche mir von Herzen, dass mir solch eine Programmierung nie unterkommt.


bike


----------



## Verpolt (21 Februar 2011)

@Perfektionist, hätte da mal 2 Fragen



Perfektionist schrieb:


> ...Und trotzdem empfinde ich den Zugriff der  HMI auf die Instanz nicht als Zugriff von außen.



Ab welcher Schnittstelle wäre bei dir der Zugriff von außen? 



> Und ich komme mit einem Minimum an Globaldaten aus, so dass sich der  Bedarf an Global-DB erübrigt (theoretisch könnten die von mir  verwendeten Globaldaten in dem übergeordneten Koordinationsbaustein  gehalten werden).


Was ist der Vorteil von "Minimum an Globaldaten" ? 


PS: zum Thema InstanzDB. Gäbe es sie nicht, gäbe es auch kein AUF DI



PSS: stunden später......


----------



## Perfektionist (21 Februar 2011)

bike schrieb:


> Ich wünsche mir von Herzen, dass mir solch eine Programmierung nie unterkommt.
> 
> 
> bike


oje, schreibst Du nicht selbst?


----------



## bike (21 Februar 2011)

Perfektionist schrieb:


> oje, schreibst Du nicht selbst?



Wenn ich daran denke, dass jemand von außen in IDB reinpfuscht, dann geht das Messer in der Tasche auf.

Bitte liebe Programmierer, lasst dies bleiben, es geht auch ohne Pfusch.

Danke


bike


----------



## Perfektionist (21 Februar 2011)

Verpolt schrieb:


> Ab welcher Schnittstelle wäre bei dir der Zugriff von außen?


von aussen ist 
	
	



```
L "Instanz".Datum
```



Verpolt schrieb:


> Was ist der Vorteil von "Minimum an Globaldaten" ?


die Kapselung fällt leichter, da die global relevanten Signale an der Schnittstelle übergeben werden können (und zwar so, dass es auf eine Bildschirmseite passt).


Verpolt schrieb:


> PS: zum Thema InstanzDB. Gäbe es sie nicht, gäbe es auch kein AUF DI


dadurch, dass ich grundsätzlich
	
	



```
call "FB","FB_Instanz"
```
schreibe, erübrigt sich auch der "AUF DI"-Befehl für mich. Im MC5-code steht der zwar drin, aber ist für mich nicht sichtbar.


----------



## Onkel Dagobert (21 Februar 2011)

Dann hast du aber für diese abgeschlossene Funktionseinheitt jeweils einen eigenen Instanz-DB, oder? Oder gibt es keine Änderungen mit Neugenerieren des Instanz-DB's? Bei meinen Anwendungen wäre es undenkbar, ständig die Aktualwerte zu verlieren. Oder wie machst du das?


----------



## Perfektionist (21 Februar 2011)

bike schrieb:


> Wenn ich daran denke, dass jemand von außen in IDB reinpfuscht, dann geht das Messer in der Tasche auf.
> 
> Bitte liebe Programmierer, lasst dies bleiben, es geht auch ohne Pfusch.
> 
> ...


ohne genaue Kenntnis Deines Programmierstils kann ich kaum nachvollziehen, was bei Dir "Pfusch" sein soll.

Innerhalb des SPS-Programms stimme ich mit Dir überein, dass Querzugriffe schlechter Stil sind. Der Zugriff der HMI auf Instanzen empfinde ich aber nicht als Querzugriff, da ich die entsprechenden HMI-Funktionen als zum jeweiligen Baustein bzw. als zur jeweiligen Instanz als zugehörig empfinde (solange nicht Steuerungsfunktionen in die HMI verlagert wurden).


----------



## Perfektionist (21 Februar 2011)

Onkel Dagobert schrieb:


> Dann hast du aber für diese abgeschlossene Funktionseinheitt jeweils einen eigenen Instanz-DB, oder?


richtig - alternativ auch eine Unterinstanz (Multiinstanz).



Onkel Dagobert schrieb:


> Oder gibt es keine Änderungen mit Neugenerieren des Instanz-DB's? Bei meinen Anwendungen wäre es undenkbar, ständig die Aktualwerte zu verlieren. Oder wie machst du das?


Damit sprichst Du eine der größten Schwächen des S7-Systems an. Leider ist S7 (noch) nicht in der Lage, die momentanen Aktualdaten einer vorhandenen Instanz in die veränderte Instanz zu übernehmen. Theoretisch denkbar wäre dies jedoch, CoDeSys kann dies, soweit mir das vom Hörensagen bekannt geworden ist, teilweise schon. Die Abhilfe bei mir sieht im Moment so aus, dass ich die Parameter und wichtige Variablen aus meinen Instanzen in der HMI in einer Rezeptur "Maschinendaten" als Rezept ablege, dann update und anschliessend die zuvor gesicherten Daten von der HMI auf die SPS wieder zurückschreibe. Für dieses Vorgehen ist es aber leider oft erforderlich, die Steuerung anzuhalten.


----------



## Onkel Dagobert (21 Februar 2011)

Perfektionist schrieb:


> ..Damit sprichst Du eine der größten Schwächen des S7-Systems an. Leider ist S7 (noch) nicht in der Lage, die momentanen Aktualdaten einer vorhandenen Instanz in die veränderte Instanz zu übernehmen. Theoretisch denkbar wäre dies jedoch, CoDeSys kann dies, soweit mir das vom Hörensagen bekannt geworden ist, teilweise schon. Die Abhilfe bei mir sieht im Moment so aus, dass ich die Parameter und wichtige Variablen aus meinen Instanzen in der HMI in einer Rezeptur "Maschinendaten" als Rezept ablege, dann update und anschliessend die zuvor gesicherten Daten von der HMI auf die SPS wieder zurückschreibe. Für dieses Vorgehen ist es aber leider oft erforderlich, die Steuerung anzuhalten.


Entschuldige Perfektionist, aber das kann's ja nun wirklich nicht sein.


----------



## Perfektionist (21 Februar 2011)

Onkel Dagobert schrieb:


> Entschuldige Perfektionist, aber das kann's ja nun wirklich nicht sein.


ja, wie denn dann? Eigentlich sollte sich ja Step uns Programmierern anpassen, also sich den Erfordernissen der Praxis stellen. Und bis dahin murxt halt jeder auf seine Weise an/um die Schwächen von Step drum herum ...

kann ja z.B. auch nicht sein, dass die HMI (Flex!) nach wie vor auf Absolutadressen in der Steuerung zugreift. So teuer ist Speicher nicht mehr, dass man nicht das Symbol in der Steuerung und der HMI zur Laufzeit hinterlegen könnte und somit es nicht mehr erforderlich wäre, HMI-Projektierung und SPS-Programm zur gleichen Zeit aktualisieren zu müssen.


----------



## Verpolt (21 Februar 2011)

Perfektionist schrieb:


> ...und somit es nicht mehr erforderlich wäre, HMI-Projektierung und SPS-Programm zur gleichen Zeit aktualisieren zu müssen.



Das kommt auf die Projektierung an.

Ich brauch das so nicht.
Verschicke ein neues TP mit dem FlexProjekt darauf und fertig


----------



## Onkel Dagobert (21 Februar 2011)

Perfektionist schrieb:


> ja, wie denn dann?..


Ganz einfach Datenablage in globalen Datenbausteinen. Um genau dieses Thema ging es doch in der Nebendiskussion?



Perfektionist schrieb:


> ..Eigentlich sollte sich ja Step uns Programmierern anpassen..


Und wo soll das enden? Step7 erlaubt schon jetzt so viele Freiheiten, dass man dadurch auch sehr viele Möglichkeiten hat, Mist zu machen. Man sollte ganz einfach ein paar einfache Grundprinzipien einhalten.



Perfektionist schrieb:


> ..Und bis dahin murxt halt jeder auf seine Weise an/um die Schwächen von Step drum herum ..


Schwächen von Step7? Jeder murxt drum herum? Diese Schwächen muß man erst einmal finden ;-) . Oh Mann, immer diese Ausflüchte. Step7 ist m.E. eine sehr leistungsfähige Software, mit der man auch sehr effektiv programmieren kann. Dabei einigermaßen sauber zu bleiben, ist allerdings schon eine kleine Kunst. Wenn ich mal etwas "artfremdes" machen muss, fällt es mir auch manchmal schwer.

Ich hatte mir eigentlich bei diesem Instanz-Thema mehr Positives erhofft, da ich in letzter Zeit schön öfter darüber gelesen habe. Helmut v.d. Rep. hatte sich ja auch schon einmal dazu bekannt.


----------



## rostiger Nagel (21 Februar 2011)

Ich....mache das doch nie  
Mein weg sind die Schmiermerker, auf die greife ich nur Indirekt und mit Pointern zu.
So muss ich wenigstens mich mit niemanden über Instanzdaten streiten. 
Wenn ich mal groß änderungen an Steuerungen habe, mit den evtl. Datenverlust
habe ich hinten am Panel immer zwei bis drei Zettel mit den Fixdaten, die muss
der Bediener dann über BCD Schalter wieder in die Steuerung eingeben.


----------



## Paule (21 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> Wenn ich mal groß änderungen an Steuerungen habe, mit den evtl. Datenverlust
> habe ich hinten am Panel immer zwei bis drei Zettel mit den Fixdaten, die muss
> der Bediener dann über BCD Schalter wieder in die Steuerung eingeben.


Na BCD Schalter sind doch mal nicht schlecht, mal besser als ein Morsetelegramm.


----------



## Onkel Dagobert (22 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> Ich....mache das doch nie
> Mein weg sind die Schmiermerker, auf die greife ich nur Indirekt und mit Pointern zu.
> So muss ich wenigstens mich mit niemanden über Instanzdaten streiten.
> Wenn ich mal groß änderungen an Steuerungen habe, mit den evtl. Datenverlust
> ...


BCD-Schalter? Und wenn's mal wieder länger dauert, Lochstreifen, Kugelschrittlaufwerk? Wollt ihr mich jetzt alle verarschen? Ich habe Steuerungen im Bereich der Haustechnik, in denen tausende Parameter gespeichert werden müssen (S7-315). Kein Scherz. An die aktuellen Remanenzprobleme der 315-er darf ich garnicht denken.


----------



## rostiger Nagel (22 Februar 2011)

Hallo Onkel,
natürlich kommt es schon mal vor das ich Rezepturen
nutze, aber nur bei den Kunden die ich nicht mag
und einfach die Montage ersparen möchte. 

PS. Sollte ich die beitrage die nicht ganz ernsthaft
gemeint sind mit [ironie] genzeichnen?

PPS. Ich weiß garnicht warum ihr so ein Wirbel um 
die Instanzdaten macht, die neuen Steuerungen ( wie von
Onkel schon erwähnt ) vergessen neben den Instanz
Daten die Globaldaten gleich mit, da kommt Freude auf.


----------



## Onkel Dagobert (22 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> ..Sollte ich die beitrage die nicht ganz ernsthaft
> gemeint sind mit [ironie] genzeichnen?..


Nein Helmut. Diese ganze Instanzdaten-Scheiße, die hier publiziert wird, gehört in in Rubrik "Liebe Kinder zu hause, bitte nicht nachmachen".


----------



## MCerv (22 Februar 2011)

Wat issn ne Instanz, da schaun wir doch mal u.a. bei Wiki vorbei:

http://de.wikipedia.org/wiki/Instanz 

hier steht z. B. *Instanz* = „*abgeschlossene Einheit*“

Also für mich ist das eindeutig, mit meinen Schulungen und Erfahrungen möchte ich dieses auch nochmals bestätigen.

_Don't touch a Instanz_


----------



## Perfektionist (22 Februar 2011)

Onkel Dagobert schrieb:


> Ganz einfach Datenablage in globalen Datenbausteinen.





Onkel Dagobert schrieb:


> Nein Helmut. Diese ganze Instanzdaten-Scheiße, die hier publiziert wird, gehört in in Rubrik "Liebe Kinder zu hause, bitte nicht nachmachen".


verstehe ich Dich richtig, dass Du keine IDB benutzt?


----------



## Perfektionist (22 Februar 2011)

Onkel Dagobert schrieb:


> Schwächen von Step7? Jeder murxt drum herum? Diese Schwächen muß man erst einmal finden ;-) . Oh Mann, immer diese Ausflüchte. Step7 ist m.E. eine sehr leistungsfähige Software, mit der man auch sehr effektiv programmieren kann. Dabei *einigermaßen* sauber zu bleiben, ist allerdings schon eine kleine Kunst.


Das klingt ja grad so, als ob ganz sauber überhaupt nicht geht 

Wegen dem "Herumgemurxe": ja, jeder! 
Ich murxe in Deinen Augen herum, weil ich die SPS anhalte und über eine Rezeptur in der HMI (behelfsweise einer Runtime auf meinem Erstellsystem) meine Aktualdaten der Instanzen rette und zurückschreibe und in meinen Augen murxt Du herum, weil Du Daten, die zu einer in sich abgeschlossenen Einheit gehören, nicht zusammen in einem m.E. dafür gedachten Instanz-Datenbaustein hältst.


----------



## bike (22 Februar 2011)

Perfektionist schrieb:


> verstehe ich Dich richtig, dass Du keine IDB benutzt?



Ich würde an dieser Stelle auf die Signatur von 4l hinweisen.



bike


----------



## rostiger Nagel (22 Februar 2011)

Diese Datensicherung in Rezepten halte ich für eine sehr nützliche sache,
das spielt es keine rolle ob es jetzt Global oder Instanzdaten sind.

Im Fall vom Onkel, wo er mehre Tausend Variabeln "nur" in den Globaldaten
sichert, finde ich nicht sehr Glücklich. Wenn mann diese wichtigen Daten,
zusätzlich in eine Rezeptur zieht, kann eigentlich nichts mehr anbrennen.
Diese Rezeptur könnte mann sogar exportieren und der Kunde könnte dann
auch gelegentlich eine Datensicherung der Aktualwerte ohne PG und
Programmierkenntnisse durchführen.


----------



## JesperMP (22 Februar 2011)

Wenn man in wiki beginnt zu "fishen" kann man viele verschiedene antworten fangen.

In computer Sprachen gehört "Instance" zu Objekt Orientierte programmieren.
STEP7 hat nichts mit eine wahre objekt orientierte sprache zu tun.
Wenn man objekt orientierte programmiersprachen anschaut sieht man das sie erlaubt eine strikse "kapselung", aber dazu auch ein verfahren die gekapselte daten per "methoden" zu bearbeiten.
In STEP7 gibt es keine "methoden" oder ähnliches.

STEP7 ist mehr wie Procedural programmieren wie Pascal.
In Procedurale programmieren ist "scope" sehr wichtig, also wie man steuert wovon daten zugänglig sind.
In EN61131-3 hat man versucht scope zu implementieren. In STEP7 fehlt es komplett.

Von diese Diskussion sieht man wieviel STEP7 mehr zu den Steinzeit (= S5) gehört als zu eine moderne computer sprache.
Es wird interessant zu sehen ob etwas passiert in v11.

Schluss von hier.


----------



## Perfektionist (22 Februar 2011)

bike schrieb:


> Ich würde an dieser Stelle auf die Signatur von 4l hinweisen.


besonders "hilfreich" ist der Teil, dass ".... etc. nicht extra ausgewiesen" sind. Und Kollege 4L klärt auch nicht mehr nachträglich drüber auf, was er nun wirklich meinte. Schreibt dann nur so einen Blödsinn wie "Du bist mein Held", aus dem man dann auch wieder alles rauslesen kann. Genauso, wie aus Deinem jetzt recht unnützen Beitrag ...



Helmut_von_der_Reparatur schrieb:


> Diese Rezeptur könnte mann sogar exportieren und der Kunde könnte dann
> auch gelegentlich eine Datensicherung der Aktualwerte ohne PG und
> Programmierkenntnisse durchführen.


manche meiner Kunden nutzen dies. Und die Export/Import-Funktion ist bei mir auch mit drin. Auf die Art und Weise können Maschinendaten wie auch Produktionsdaten von Maschine zu Maschine portiert werden oder auch mal bequem mit Office-Produkt dokumentiert werden.


----------



## bike (22 Februar 2011)

@Perfektionist:
Es geht darum, dass wer lesen kann ist stets im Vorteil.
Daher der Hinweis einfach zu lesen, dann wäre vieles leichter hier.
Mit einem Helden wird niemand versuchen zu diskutieren, da dieser ja so und so recht hat. 


bike


----------



## Perfektionist (22 Februar 2011)

JesperMP schrieb:


> STEP7 ist mehr wie Procedural programmieren wie Pascal.
> In Procedurale programmieren ist "scope" sehr wichtig, also wie man steuert wovon daten zugänglig sind.
> In EN61131-3 hat man versucht scope zu implementieren. In STEP7 fehlt es komplett.


hmmm, wenn auch scope nicht fest in Step verankert ist, kann man sich nicht trotzdem daran halten? Durch Deine für mich sehr wertvollen Stichworte habe ich folgendes gefunden:
http://www.uni-koeln.de/rrzk/kurse/unterlagen/java/javaref/funcs/index.htm#Scopes


> Blöcke und Scopes
> Der Scope oder Name Space  ist der Sichtbarkeits- bzw. Gültigkeitsbereich eines Bezeichners.
> Der kleinste Scope ist der Block. Außerhalb des Blocks sind die Bezeichner, die innerhalb des Blocks deklariert sind, nicht sichtbar. Man spricht von z.B. von lokalen Variablen. Bezeichner übergeordneter Scopes sind dagegen in eingebetten oder untergeordneten Scopes sichtbar.
> Auch eine for-Schleife mit Variablendeklaration in der for-Initialisierung bildet einen Scope.
> ...


Leider ist meine Programmierpraxis nur von Pascal geprägt, daher kann ich die Abstraktion der OOP nicht nachvollziehen.



JesperMP schrieb:


> Von diese Diskussion sieht man wieviel STEP7 mehr zu den Steinzeit (= S5) gehört als zu eine moderne computer sprache.
> Es wird interessant zu sehen ob etwas passiert in v11.


da bin ich auch sehr gespannt auf V11 und verfluche ebenso wie Du die Steinzeit.



JesperMP schrieb:


> Schluss von hier.


schade eigentlich - aber vielleicht hast Du tatsächlich schon alles gesagt, was zu dem Thema zu sagen war ...


----------



## MCerv (22 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> Diese Datensicherung in Rezepten halte ich für eine sehr nützliche sache,
> das spielt es keine rolle ob es jetzt Global oder Instanzdaten sind.
> 
> Im Fall vom Onkel, wo er mehre Tausend Variabeln "nur" in den Globaldaten
> ...



Rezeptvariablen werden bei mir in der Rezeptur über das Panel gesichert!
Notwendige Systemvariablen, die ich in unseren Serviceseiten einstelle sind in Global-Daten-DB's abgelegt (man könnte diese zur Sicherung auch in eine Rezeptur stecken!), aber *nicht* in Instanzdaten!

Instanzdaten sind nur "*interne Speicher*". Gut, bei Siemens kommt man an diese Speicher ran, aber da diese Speicherbereiche (I-DB's) a*utomatisch generiert* werden läuft man bei Änderungen Gefahr einer *falsch Adressierung*! Ja es gibt die symbolische Adressierung, aber will ich bei Änderungen immer das gesamte Programm überprüfen, compelieren und übertragen? Ich nicht!


----------



## JesperMP (22 Februar 2011)

Perfektionist schrieb:


> hmmm, wenn auch scope nicht fest in Step verankert ist, kann man sich nicht trotzdem daran halten?


Genau.
Ich habe pro "object" eine "status" bereich (nur lesen) und eine "command" bereich (lesen und schreiben). Dann gibt is im objekt weitere daten bereiche die ich von aussen nicht berühren.
Ich versuche zu programmiere als ob es wirklich scope gibt.



Perfektionist schrieb:


> - aber vielleicht hast Du tatsächlich schon alles gesagt, was zu dem Thema zu sagen war ...


Doch. Wenn die Diskussion nicht in das Religiöse tendiert.
Ich will versuchen mich zu einen Eintrag pro Tag in diesen Thema zu rationieren.

Zum "Held": Ich meine nicht das ein Held ist einer der immer recht hat, sondern einer der wagt gegen die Mehrheit zu gehen


----------



## Perfektionist (22 Februar 2011)

bike schrieb:


> ... wer lesen kann ist stets im Vorteil.


ach ja, wer darüber hinaus auch noch denkt , die Hilfe und SuFu findet ...

OK, da gibt es auch noch das BNA-Prinzip: beobachten, nachdenken, ausprobieren. Was die mir verhassten Global-DB anbetrifft, so habe ich diese zwar zunächst von S5 übernommen (habe also bereits Erfahrung damit), bei S7 aber zunehmend bemerkt, dass ich diese dank IDB nicht wirklich mehr benötige.


----------



## rostiger Nagel (22 Februar 2011)

MCerv schrieb:


> Rezeptvariablen werden bei mir in der Rezeptur über das Panel gesichert!
> Notwendige Systemvariablen, die ich in unseren Serviceseiten einstelle sind in Global-Daten-DB's abgelegt (man könnte diese zur Sicherung auch in eine Rezeptur stecken!), aber *nicht* in Instanzdaten!
> 
> Instanzdaten sind nur "*interne Speicher*". Gut, bei Siemens kommt man an diese Speicher ran, aber da diese Speicherbereiche (I-DB's) a*utomatisch generiert* werden läuft man bei Änderungen Gefahr einer *falsch Adressierung*! Ja es gibt die symbolische Adressierung, aber will ich bei Änderungen immer das gesamte Programm überprüfen, compelieren und übertragen? Ich nicht!


 
Hallo Michael,
du hast doch hoffentlich meine Ausage richtig gelesen.


Helmut_von_der_Reparatur schrieb:


> Diese Datensicherung in Rezepten halte ich für eine sehr nützliche sache,
> da spielt es keine rolle ob es jetzt Global oder Instanzdaten sind.


 
Mir ging es darum auszudrücken, das es Sinnvoll ist die Daten ruhig noch
mal in ein Rezept zu speichern, gerade du der Leidvolle erfahrung mit den
Datenverlust in der CPU gemacht hat, sollte den sinn meine Ausage
verstehen.


----------



## bike (22 Februar 2011)

Was mir so auffällt ist, dass hier auf BigS so eingedroschen wird.

Der Simatik Manager und die entsprechenden PLC sind gut.
Die Entwickler von Siemens haben sich bestimmt etwas dabei gedacht, als sowohl DB als auch IDB implementiert wurden.
Daher sollte auch das so genutzt werden, wie es die es sich damals gedacht haben.
Es machen manche den Fehler, das Werkzeug so lange zu verbiegen, bis das System nicht mehr passt.
Es ist zu prüfen ob Objekte, die in meinen Augen nur eine Modeerscheinung sind, in einer Steuerung notwendig sind. 
Mit Objekten meine ich nicht gekapselte Funktionen, sondern das was Objekte sein wollen.
So etwas habe ich schon gesehen und bin erschrocken wie man Step7 so verunstalten kann 
Das Ergebnis von Objekten sehe wir in den OS die wir leider meist nutzen müssen.

Ja, ich weiß dass WinCC und -flex Mist sind, doch ist es wo anders besser?

Wenn jemand mit Rockwell oder Bosch oder Fanuc programmieren muss, der kann dann erst schätzen was BigS gebaut hat. 


bike


----------



## Boxy (22 Februar 2011)

bike schrieb:


> Der Simatik Manager und die entsprechenden PLC sind gut.
> ...
> Wenn jemand mit Rockwell oder Bosch oder Fanuc programmieren muss, der kann dann erst schätzen was BigS gebaut hat.
> 
> bike



Da muß ich dir mal sagen: *ACK* 
Es gibt viel mehr schlechtere als bessere Programmiersysteme!


----------



## Perfektionist (22 Februar 2011)

MCerv schrieb:


> Ja es gibt die symbolische Adressierung, aber will ich bei Änderungen immer das gesamte Programm überprüfen, compelieren und übertragen? Ich nicht!


ich arbeite seit langem nur noch mit Operandenvorrang Symbol. Das gesamte Programm zu compilieren und zu übertragen ist im Übrigen nicht notwendig. Es genügt, bei der Bausteinkonsistenzprüfung nur die durch die Änderung betroffenen Bausteine neu übersetzen zu lassen. Und ein online/offline-Vergleich zeigt, welche Bausteine zum AG zu übertragen sind (hoffentlich wird das bei V11 erleichtert und/oder automatisiert).


----------



## Perfektionist (22 Februar 2011)

bike schrieb:


> Die Entwickler von Siemens haben sich bestimmt etwas dabei gedacht, ...


wo kann ich denn bitte nachlesen, ob und was sie sich dachten? Mutmaßungen über den Willen eines nicht wahrnehmbaren Wesens gehören in den Bereich der Religion.


----------



## MCerv (22 Februar 2011)

MCerv schrieb:


> ...Notwendige Systemvariablen, die ich in unseren Serviceseiten einstelle sind in Global-Daten-DB's abgelegt (*man könnte diese zur Sicherung auch in eine Rezeptur stecken!*), aber nicht in Instanzdaten!...



Helmut,
genau das hab ich doch geschrieben, aber das Thema ist ja immernoch DB-Zugriffe 

Perfektionist,
genau das mir noch ein Dorn im Auge (aua), von andreren Steuerungen z. B. Omron kenne ich das so, dass immer das Ganze Programm übertragen wird, da ist das dann letztlich egal, aber ich möchte ja auch Änderungen schnell mal einspielen und da ist mir derzeit der Aufwand mit der symbolischen Adressierung beim Kunden vor Ort zu groß. Wenn V11 das besser handhaben kann, das wäre SUPER!


----------



## MSB (22 Februar 2011)

bike schrieb:


> Der Simatik Manager und die entsprechenden PLC sind gut.
> Die Entwickler von Siemens haben sich bestimmt etwas dabei gedacht, als sowohl DB als auch IDB implementiert wurden.
> Daher sollte auch das so genutzt werden, wie es die es sich damals gedacht haben.


Tja, ich bin zwar weitgehen gegen IDB-Zugriffe von außen, einfach aus praktischen Gründen,
vor allem weil ich gelegentlich auch mal auf die quasi Instandhalter Seite wechsle, und weiß,
was passiert, wenn man irgend sowas übersieht bei einer Änderung.

Ob das damals so gedacht war, das man das so strikt trennt, wie es imho Sinn macht weiß ich nicht.
Fakt ist auf jeden Fall das Siemens in den Ausbildungsunterlagen und den anhängigen Beispielen,
auch in IDBs mit HMI und anderen rumfingert.



bike schrieb:


> Wenn jemand mit Rockwell oder Bosch oder Fanuc programmieren muss, der kann dann erst schätzen was BigS gebaut hat.


Speziell Rockwell halte ich diesbezüglich vom Grundgedanken der Tags her für wirklich gut,
auch wenn die HMI's oder vielmehr die Software RSViewME/Factory..ME ... untoll sind.

Mfg
Manuel


----------



## bike (22 Februar 2011)

Perfektionist schrieb:


> wo kann ich denn bitte nachlesen, ob und was sie sich dachten? Mutmaßungen über den Willen eines nicht wahrnehmbaren Wesens gehören in den Bereich der Religion.





Ich verweise darauf:
http://www.sps-forum.de/showpost.php?p=314595&postcount=106

Wenn du es nicht verstehst, ist das dein Problem.
Aber anderen abzusprechen sie würden bei der Entwicklung von einem Programm sich etwas dabei gedacht haben, in den Bereich der Religion abzuschieben, ist schwach.
Du tust sowohl der Religion als auch den Entwicklern unrecht.
Ich kenne Leute aus Karlsruhe und Fürth und, sein versichert, die wissen was sie tun.


bike


----------



## bike (22 Februar 2011)

MSB schrieb:


> Speziell Rockwell halte ich diesbezüglich vom Grundgedanken der Tags her für wirklich gut,
> auch wenn die HMI's oder vielmehr die Software RSViewME/Factory..ME ... untoll sind.l



Es geht nicht um die Theorie, sondern was die Software wirklich kann.
Rockwell hat seine Vorteile, doch noch? überwiegen nach meiner Erfahrung die Nachteile.

Ebenso den Schritt zwischen Codesys 2.3 und 3.0 habe ich nicht verstanden, warum bzw was brauche ich von dem neuen System um eine Maschine zu programmieren?

In Hochsprachen verwende ich Objekte wo es nach meiner Empfindung Sinn macht, aber ich versuche nicht alles in Objekte zu zwingen.


Ich verstehe es immer noch nicht, warum die Trennung zwischen DB und IDB so zwanghaft aufgelöst werden muss 


bike


----------



## Perfektionist (22 Februar 2011)

bike schrieb:


> Ich kenne Leute aus Karlsruhe und Fürth und, sein versichert, die wissen was sie tun.


http://de.wikipedia.org/wiki/Argumentum_ad_verecundiam
Dass Du vor Deinen Göttern Ehrfurcht hast, bedeutet nicht, dass ich vor Deinen Göttern ehrfürchtig bin. Wer mag, darf trotzdem gerne gen Karlsruhe und Fürth seine Danksagungen beten, meine Gebete dorthin werden wohl eher als ein Bitten zu verstehen sein.


----------



## bike (22 Februar 2011)

Perfektionist schrieb:


> http://de.wikipedia.org/wiki/Argumentum_ad_verecundiam
> Dass Du vor Deinen Göttern Ehrfurcht hast, bedeutet nicht, dass ich vor Deinen Göttern ehrfürchtig bin. Wer mag, darf trotzdem gerne gen Karlsruhe und Fürth seine Danksagungen beten, meine Gebete dorthin werden wohl eher als ein Bitten zu verstehen sein.




Geht doch nicht!

http://www.sps-forum.de/showpost.php?p=314595&postcount=106

Du bist der Einzig Wahre Erleuchtete.


bike

P.S: in der Apotheke gibt es Perenterol, das hilft deinem Gehirn.


----------



## Perfektionist (22 Februar 2011)

bike schrieb:


> Geht doch nicht!
> 
> http://www.sps-forum.de/showpost.php?p=314595&postcount=106
> 
> ...


gegen geistigen Durchfall?
http://de.wikipedia.org/wiki/Saccharomyces_boulardii


----------



## rostiger Nagel (22 Februar 2011)

Schade das ihr euch bei so einen schönen Thema, nicht auf ein vernünftigen
Nivau unterhalten könnt. Vielleicht Atmet ihr mal tief durch und dann fangt
ihr noch mal von vorne an.

Die Diskussion ob Siemens sich etwas gedacht hat oder nicht finde ich ein 
wenig daneben, das weiß nur der jenige bei Siemens. Wenn hier jemand 
mehr weiß, möchte er sagen: "Der Entwicklungsleiter Herr Dr. Dr. Plakiat hat
gesagt die Instanzdaten sind ausschließlich dafür und die Globaldaten sind
ausschließlich hierfür. Dürfen vermengt werden, aber unter bestimmten um-
ständen nicht"


----------



## Tigerente1974 (22 Februar 2011)

Bei diesem thread geht es doch nur noch darum, "wer den Längeren hat..."


----------



## bike (22 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> Die Diskussion ob Siemens sich etwas gedacht hat oder nicht finde ich ein
> wenig daneben, das weiß nur der jenige bei Siemens. Wenn hier jemand
> mehr weiß, möchte er sagen: "Der Entwicklungsleiter Herr Dr. Dr. Plakiat hat
> gesagt die Instanzdaten sind ausschließlich dafür und die Globaldaten sind
> ...



Denkst du eine Person allein hat sich Step7 ausgedacht?
Kennst du noch Step7 V1?
Da kam etwas Neues, da ging ein Aufschrei durch die Welt der Automatisierer.
Als dann später die erste, brauchbare Version kam war, so ich mir erinnere, die V2.1, gab es keinen FUP. Ein neuer Schrei.

Der Gedanke hinter den GlobalDB und IDB ist, dass Daten die allgemein  genutzt werden als Global definiert werden. 
Interne Daten die nur lokal  in einem Baustein erstellt und genutzt werden kommen in IDB. 
So zumindest wurde es uns von Siemens erklärt. Dass dies nicht immer möglich ist, sei dahingestellt.

Bei der Durchsicht von verschiedenen Programmiervorschriften von unseren  Kunden ist mir aufgefallen, dass nur BMW und VauWe zu diesem Thema  etwas geschrieben haben. 
Bei Renault hat mir deren Siemensbetreuer nach der Analyse unserer  Standardprogramme sehr direkt gesagt, dass das Verwenden von IDB global  schlechter Programmierstil sei.

Wenn jemand dies anders handhabt, ist das dessen Entscheidung, doch es  als richtig und legitim zu deklarieren, und den GlobalDB jeden Sinn   abzusprechen, ist nicht richtig.


bike


----------



## Larry Laffer (22 Februar 2011)

Hallo ihr Lieben,
ich glaube nicht (aus eigener Erfahrung in einem anderen Thread), dass es irgend jemanden hier gelingen wird den Anderen zu bekehren (außer dass der Eine für den Anderen arbeiten muß). Das Beste, was man hier also erreichen kann, ist eine Patt-Situation. Vielleicht belasst ihr es einfach dabei ... 

Grüße
Larry


----------



## Perfektionist (22 Februar 2011)

Helmut_von_der_Reparatur schrieb:


> "Der Entwicklungsleiter Herr Dr. Dr. Plakiat hat gesagt ..."


Als Siemens mir das S7 (ich glaube, Stand 3.2, vielleicht auch V2.x?) in die Hand drückte, da bekam ich als Hinweis mit, dass Leute, die Hochsprachen wie Pascal gewohnt seien, einen leichteren Einstieg damit hätten.

Von S5 her war ich, entsprechend auch so angeleitet, gewohnt, ganz anders zu arbeiten, also eigentlich nur Globaldaten zu nutzen (naja, die Schmiermerkerei war ja nur als Krücke verwendbar, um Lokaldaten zu haben). Das Übergeben von Parametern an der Schnittstelle eines FB war bei S5 irgendwie sperrig, vor allem extrem Performance raubend. Also verfiel ich damals auf so  "hübsche" Konstruktionen, dass ich also den Schmiermerkerbereich als Schnittstelle missbrauchte (wovon ich heute weiß, dass auch andere das machten). Wie ich heute auch weiß, gab es noch die Variante mit dem Zeiger auf die jeweiligen Datenbereiche.

Auf die Idee, DBs als Instanzen zu nutzen, kam ich nicht (hätte auch erheblichen Performanceverlust bedeutet). Nach Möglichkeit gab es nur einen einzigen Global-DB, um sich das ständige Aufschlagen des richtigen DB ersparen zu können. Ausserdem musste ich dann ein bestimmtes DW nicht auch noch in verschiedenen DB suchen müssen (Querverweis!) und konnte diese DW auch noch in der ZuLi dokumentieren, da ja nur ein DB vorhanden war.

Mit S7 empfand ich es zunächst nur als lästig, da ständig oben in der Deklaration etwas eintragen zu müssen. War doch so bequem bei S5, einfach Merker hinschreiben, Code ist erstmal fertig, ZuLi machen wir dann am Stück effektiver irgendwann später ...

Meine ersten S7-Programme sahen also wie S5-Programme aus.

Aber ich begann, die neuen Möglichkeiten, insbesondere die FB/IDB zu nutzen. Und lernte, Maschinen/Anlagen in Untereinheiten so zu zerlegen, dass sich dann dazu gehörige Programmteile ergaben, die nur noch sparsame Schnittstellen nach aussen benötigten.

Heute kann ich sagen, dass es mir möglich ist, eine Automatisierungsaufgabe mit der S7 und Flexible ohne Verwendung von Globaldaten (natürlich E/A  und Zeitablauf ausgenommen) zu lösen. Den Global-DB habe ich für mich ganz abgeschafft. Merker und S5-Timer benutze ich nur noch aus Bequemlichkeit.

Warum nur löst die Feststellung, dass es auch ohne Global-DB gehen könnte, derartige Reflexe aus?


----------



## MCerv (22 Februar 2011)

Larry Laffer schrieb:


> Hallo ihr Lieben,
> ich glaube nicht (aus eigener Erfahrung in einem anderen Thread), dass es irgend jemanden hier gelingen wird den Anderen zu bekehren (außer dass der Eine für den Anderen arbeiten muß). Das Beste, was man hier also erreichen kann, ist eine Patt-Situation. Vielleicht belasst ihr es einfach dabei ...
> 
> Grüße
> Larry



Und damit liegst du völlig richtig. Für mich beende ich diesen Thread. Wir sehen uns im Nächsten


----------



## Perfektionist (22 Februar 2011)

Larry Laffer schrieb:


> ... Patt-Situation.


Lieber Larry,
ein Patt ist eine Situation, die ein unterlegener Spieler anstrebt, um seine Niederlage zu vermeiden. [/Klugscheissmodus]
Ich denke mal, ich sollte an dieser Stelle "Remis" (Unentschieden) lesen?

Ansonsten, finde ich, kann man ja durchaus diskutieren. Erweitert zumindest mal meinem Blick über meinen Tellerrand hinaus. Und wenn ich dabei auch nur für mich feststelle, wie wirksam noch heute Schopenhauers Kunstgriffe sind, so lerne ich dennoch daraus. Und ich lerne Forumskollegen zu schätzen, die das auch zu sehen vermögen um dann hilfreich moderierend einzugreifen.

Hmmm, also lassen wir es mal so stehen (?). Meine These, dass Global-DB nicht mehr notwendig sind, und die andere These, dass man Global-DB sehr wohl für das Rangieren von HMI-Daten, zum Halten remanenter Daten ausserhalb von IDB und zum Vermeiden von Datenumstrukturierung benötigt. Hab ich was vergessen? Vermutlich schaufeln noch andere Leute Verwaltungsdaten durch die SPS durch, die dann eben auch nicht mehr in einfachen Strukturen verwaltbar sind.


----------



## Verpolt (22 Februar 2011)

Perfektionist schrieb:


> Lieber Larry,
> ein Patt ist eine Situation, die ein unterlegener Spieler anstrebt, um seine Niederlage zu vermeiden. [/Klugscheissmodus]
> Ich denke mal, ich sollte an dieser Stelle "Remis" (Unentschieden) lesen?



Wiki


> Ein Patt ist eine Endposition einer Schachpartie, bei der ein am Zug befindlicher Spieler keinen gültigen Zug machen kann und sein König nicht im Schach steht. Ein Patt wird als Remis, also Unentschieden gewertet und ist daher häufig ein Rettungsanker für den unterlegenen Spieler. Dieser kann eine Unachtsamkeit des überlegenen Gegners dazu nutzen, sich in eine Pattsituation zu bringen.



Das wäre jetzt ein neuer Thread. Patt oder Remis


----------



## Larry Laffer (22 Februar 2011)

Lieber Perfektionist,
ich meinte "Patt" im Sinne der von Verpolt genannten Erklärung.

Bezogen auf diesen Thread heißt das :
Solange Herr S. nicht die Voraussetzungen schafft, dass der Quer-Zugriff auf die I_DB-Daten quasi als erweiterter Globalspeicher verwehrt wird wird es immer wieder Leute geben, die das dann auch so nutzen. Ich finde es nicht gut - werde es aber auch nicht ändern können (außer im schon genannten Fall).

Gruß
Larry


----------



## IBFS (22 Februar 2011)

bike schrieb:


> Was mir so auffällt ist, dass hier auf BigS so eingedroschen wird.
> 
> Der Simatik Manager und die entsprechenden PLC sind gut.
> 
> ...



*ACK*

Nehmt doch einfach RS5000 und die Panelvisu dazu .. viel Spass damit,
kostet glatt das doppelte und Support gibt es nur wenn man SUS hat.

Es ist schon immer so gewesen, wenn eine Software einem viele 
Freiheiten läßt, dann kann man auch viel pfuschen und verbiegen
daher ist die Vielfalt der Programmierstile bei S7 so groß.

Also nehmt das 3S-Konzept und laßt euch einschnühren und
deklariert euch tot .... 

Frank


----------



## bike (22 Februar 2011)

IBFS schrieb:


> *ACK*
> 
> Nehmt doch einfach RS5000 und die Panelvisu dazu .. viel Spass damit,
> kostet glatt das doppelte und Support gibt es nur wenn man SUS hat.
> ...



Würde ich, doch ich muss Maschinen und Anlagen programmieren und da brauche ich Hard- und Software die funktioniert.

Ich habe mit Codesys versucht eine Anlage, die sehr gut kenne, zu programmieren, doch der Erfolg war nicht mit mir.
Ich konnte es nicht. 
Ob es an mir oder an der anderen Denkweise liegt, weiß ich nicht.
Eigentlich dachte ich, da ich neben verschiedenen PLC Systemen auch Hochsprachen programmiere würde ich es schaffen.


bike


----------



## IBFS (22 Februar 2011)

@bike

Mein letzter Satz war sarkastisch gemeint  

Frank


----------



## Onkel Dagobert (22 Februar 2011)

*Leute, ihr ward aber sehr fleißig heute ;-) !
*


Helmut_von_der_Reparatur schrieb:


> ..Im Fall vom Onkel, wo er mehre Tausend Variabeln "nur" in den Globaldaten
> sichert, finde ich nicht sehr Glücklich. Wenn mann diese wichtigen Daten,
> zusätzlich in eine Rezeptur zieht, kann eigentlich nichts mehr anbrennen.
> Diese Rezeptur könnte mann sogar exportieren und der Kunde könnte dann
> ...


Bezüglich der aktuellen Remanenzprobleme ist das sicherlich eine sinnvolle Maßnahme. Ich werde mal darüber nachdenken. Wieviele Daten kann man eigentlich in Rezepturen speichern? Meistens habe ich eine RT oder ein OP177B zur Verfügung, seltener ein TP/MP277.



Perfektionist schrieb:


> verstehe ich Dich richtig, dass Du keine IDB benutzt?


Selbstverständlich benutze ich Instanz-DBs. Dort sind aber keinesfalls Parameter oder Sollwerte abgelegt.



Perfektionist schrieb:


> Das klingt ja grad so, als ob ganz sauber überhaupt nicht geht ..


Doch das geht. Das nennt sich dann "Hohe Kunst" ;-) .



Perfektionist schrieb:


> ..Wegen dem "Herumgemurxe": ja, jeder!
> Ich murxe in Deinen Augen herum, weil ich die SPS anhalte und über eine Rezeptur in der HMI (behelfsweise einer Runtime auf meinem Erstellsystem) meine Aktualdaten der Instanzen rette und zurückschreibe und in meinen Augen murxt Du herum, weil Du Daten, die zu einer in sich abgeschlossenen Einheit gehören, nicht zusammen in einem m.E. dafür gedachten Instanz-Datenbaustein hältst.


Ich kann einfach nicht verstehen, warum du dir durch solch eine miese Programmierweise das Leben schwer machst? Nur, um keine Globaldatenbausteine verwenden zu müssen? Das macht doch überhaupt keinen Sinn?


Zu meinem Gemurxe.
Ich nenne es Konzept. Meine "wichtigen" Daten sind fein säuberlich in einheitlichen Strukturen (180Byte) in globalen DBs abgelegt. Diese DBs werden in der Regel nach Beginn der Programmierung auch nie wieder geändert. Sie bilden das Herz meiner Programme, oder wie du es nennst, "geschlossene Einheiten". Meine Programmbausteine sind hingegen "nur" Werkzeuge, die diese Einheiten bearbeiten. So gibt es z.Bsp. einen Baustein der die HMI-Anbindung handelt, egal ob nur eine Pumpe geschaltet wird, oder ob ein PID-Regler bedient wird. Dieser Baustein bekommt dann gleich den ganzen DB zur Bearbeitung, egal wie lang er ist. Ein Bausteinaufruf, eine Hand voll Parameter und die HMI-Anbindung ist z.Bsp. für 32 Regler Geschichte. Eine Synchronisation mit einem zweiten oder dritten HMI-Gerät ist dabei auch schon berücksichtigt. Ein anderer Baustein bearbeitet z.Bsp. die PID-Regler, 32 oder auch mehr auf einen Streich. Am HMI-Gerät gibt es dabei nur einen einzigen Datensatz. Das Wesentliche, was dieses System erst möglich macht, sind die festen Strukturen in den globalen DBs.

Für jede Anlage gibt es dann noch einen "Anlagen-FB". Das sind die einzigen Bausteine, in dem noch "frei" programmiert wird. Mal abgesehen von Störmeldungen, Analogwertverarbeitung und dergleichen. Hier werden Freigaben für die einzelnen "Einheiten" gebildet, Sollwerte berechnet, Istwerte geschrieben, MAX-Auswahlen getroffen usw. Hier greife ich auf die entsprechenden Variablen der entsprechenden Einheit im Global-DB direkt zu.


Ein kleines Beispiel aus meiner Praxis.
Vor ca. drei Jahren habe ich eine größere Kühlwasseranlage programmiert (12MW Maschinenleistung + Freie Kühlung). Unser Auftraggeber "S" hat uns erst in letzter Minute beauftragt. Am ersten Tag auf der Baustelle hatte ich das Programm gerade mal so weit fertig, dass die Handbedienungen möglich waren. Nachdem die ersten Pumpen liefen, durften diese aber auch nicht wieder abschalten! Im ganzen Werk (komletter Neubau) wurden seit diesem Zeitpunkt bereits Maschinen gekühlt. Sämtliche Automatikfunktionen und Regelungen habe ich bei laufender Anlage implementiert und in Betrieb genommen. Nach deiner Methode hätte ich garnicht erst anreisen brauchen.


Wieso siehst du nicht ein, dass deine Art zu programmieren, schlicht und ergreifend, "ungünstig" (um nicht zu sagen, Sch..) ist? Du machst dir sinnlos das Leben schwer.

* Im Grunde genommen kann es mir aber auch völlig egal sein :s17: .
*


----------



## Perfektionist (23 Februar 2011)

Onkel Dagobert schrieb:


> Bezüglich der aktuellen Remanenzprobleme ist das sicherlich eine sinnvolle Maßnahme. Ich werde mal darüber nachdenken. Wieviele Daten kann man eigentlich in Rezepturen speichern? Meistens habe ich eine RT oder ein OP177B zur Verfügung, seltener ein TP/MP277.


Ein OP177B kann 100 Rezepturen, wie viel Rezepturelemente, das finde ich auf die Schnelle nicht, ich schätze mal zwischen 250 und 500. Im Zweifel legt man mehrere Rezepturen an, wenn die Zahl der Rezepturelemente die Leistung des Panels übersteigt.



Onkel Dagobert schrieb:


> Ich kann einfach nicht verstehen, warum du dir durch solch eine miese Programmierweise das Leben schwer machst? Nur, um keine Globaldatenbausteine verwenden zu müssen? Das macht doch überhaupt keinen Sinn?


Es macht Sinn. Ich bin in der Lage, ohne Kenntnis Deines Konzepts einen Baustein in Deine Steuerung mitsamt der dazugehörigen Visubilder zu implementieren. Ich werde aber nicht in der Lage sein, einen Programmteil von Dir übernehmen zu können, da dem Anschein nach mehrere Dinge derart komplex miteinander vernetzt sind, dass es mir nicht möglich ist, das in angemessener Zeit zu durchschauen. Im Übrigen: kann mir mal jemand Feedback geben, ob bei mir im Text auch so wertende Begriffe wie "mies" vorkommen?



Onkel Dagobert schrieb:


> ... Ich nenne es Konzept. Meine "wichtigen" Daten sind fein säuberlich in einheitlichen Strukturen (180Byte) in globalen DBs abgelegt. Diese DBs werden in der Regel nach Beginn der Programmierung auch nie wieder geändert. Sie bilden das Herz meiner Programme, oder wie du es nennst, "geschlossene Einheiten".


Gut, damit hast Du Dir Deine Welt erschaffen, eine Welt, die Du verstehst, die Deinen Anforderungen gerecht wird, eine Welt, die möglicherweise veränderungsresistent ist.



Onkel Dagobert schrieb:


> Ein kleines Beispiel aus meiner Praxis.
> Vor ca. drei Jahren habe ich eine größere Kühlwasseranlage programmiert [...] Nach deiner Methode hätte ich garnicht erst anreisen brauchen.
> 
> Wieso siehst du nicht ein, dass deine Art zu programmieren, schlicht und ergreifend, "ungünstig" (um nicht zu sagen, Sch..) ist? Du machst dir sinnlos das Leben schwer.


Dazu kann ich nur schlicht feststellen, dass wir zwei in unterschiedlichen Welten leben. Während Du Anlagen programmierst, deren SPS nach dem ersten Einschalten nicht mehr still stehen dürfen, habe ich Maschinen/Automaten, bei denen es unschädlich ist, zwischendurch mal die SPS zu stoppen bzw. sich spätestens nach Produktionsende die Möglichkeit ergibt, den Hauptschalter rumzudrehen. Die Schwierigkeiten, die Du in meiner Programmierweise siehst, habe ich in Wirklichkeit gar nicht.

Wenn jetzt das große S es noch hinbekommt, dass ich Instanzen auch im laufenden Betrieb verändern kann, so wäre ich mit meiner Programmierweise in der Lage, auch derartige Anlagen unterbrechungsfrei fortschreitend in Betrieb nehmen zu können


----------



## bike (23 Februar 2011)

IBFS schrieb:


> @bike
> 
> Mein letzter Satz war sarkastisch gemeint
> 
> Frank



Das habe ich so verstanden und habe nur geschrieben wie es mir erging.




Perfektionist schrieb:


> Wenn jetzt das große S es noch hinbekommt, dass ich Instanzen auch im laufenden Betrieb verändern kann, so wäre ich mit meiner Programmierweise in der Lage, auch derartige Anlagen unterbrechungsfrei fortschreitend in Betrieb nehmen zu können



Warum soll Siemens seine Software auf dich anpassen, nur weil du nicht bereit bist an Regeln zu halten?

Ob das Forum hier repräsentativ ist weiß ich nicht.
 Doch wenn ich sehe wer hier die PLC vergewaltigt und was mir im Reallife so begegnet, könnte ich weinen.

 Das Thema des TE ist schon geklärt, denke ich einmal.
 Und über den Rest....



 bike


----------



## Perfektionist (23 Februar 2011)

Larry Laffer schrieb:


> Solange Herr S. nicht die Voraussetzungen schafft, dass der Quer-Zugriff auf die I_DB-Daten quasi als erweiterter Globalspeicher verwehrt wird ...


handelt es sich dabei nicht um diese Einstellung im Baustein-Editor:





> Querzugriffe als Fehler melden
> Hier legen Sie fest, ob globale Zugriffe auf aufrufende Instanz-Datenbausteine, die in der Symboltabelle eingetragen sind, als Fehler gemeldet werden sollen.


----------



## Perfektionist (23 Februar 2011)

bike schrieb:


> Warum soll Siemens seine Software auf dich anpassen, nur weil du nicht bereit bist an Regeln zu halten?


Ja, Siemens hat beim Übergang von S5 auf S7 tatsächlich die Software meinen Erfordernissen angepasst. Die PB wurden gestrichen, die FB wurden in FC umbenannt und der FB zwar namensgleich, aber zusammen mit der ihm zugeordneten Instanz neu erschaffen. Und ich freue mich auf den nächsten Schritt, den Siemens für mich tun kann. Durch die Nutzung neuer Regeln brauche ich alte Regeln nicht mehr zu beachten.


----------



## vollmi (23 Februar 2011)

Perfektionist schrieb:


> Wenn jetzt das große S es noch hinbekommt, dass ich Instanzen auch im laufenden Betrieb verändern kann, so wäre ich mit meiner Programmierweise in der Lage, auch derartige Anlagen unterbrechungsfrei fortschreitend in Betrieb nehmen zu können



Also mir würde es schon reichen wenn BigS einem die Möglichkeit "OutOfTheBox" geben würde Aktualdaten von DB und I_DBs als Startwerte ins offline Programm zu sichern.


----------



## bike (23 Februar 2011)

vollmi schrieb:


> Also mir würde es schon reichen wenn BigS einem die Möglichkeit "OutOfTheBox" geben würde Aktualdaten von DB und I_DBs als Startwerte ins offline Programm zu sichern.



Also IDB interessieren nicht, da es ja vom FB verändert werden.
Und Globaldaten, die wichtig sind, werden bei mir über eine Initialisierungsfunktion beim Hochlauf der richtigen Stelle zur Verfügung zu stellen.

Resümee:
Also BigS ist, wie inzwischen bemerkt, gar nicht so schlimm.


bike


----------



## vollmi (23 Februar 2011)

bike schrieb:


> Also IDB interessieren nicht, da es ja vom FB verändert werden.
> Und Globaldaten, die wichtig sind, werden bei mir über eine Initialisierungsfunktion beim Hochlauf der richtigen Stelle zur Verfügung zu stellen.
> 
> Resümee:
> Also BigS ist, wie inzwischen bemerkt, gar nicht so schlimm.



Aktualdaten können sich während der Laufzeit auch ändern. Da will ich sie ungern durch ein reinit wieder reinitialisieren.
Da könnt ich ja gleich mit Konstanten arbeiten.

Nur damit das nicht falsch rüberkommt. ich bin mit Siemens durchaus zufrieden. Nur kann man auch bei denen durchaus noch Dinge verbessern. Und andere Dinge vereinfachen.


----------



## Perfektionist (23 Februar 2011)

@vollmi
wie bike bereits bemerkte, reicht das bei FB nicht aus, da ja ein FB mit mehreren Instanzen aufgerufen werden kann.
Weiterhin ergibt sich das Problem, dass ein DB die Werte beibehalten sollte, die zum Zeitpunkt der Übertragung im alten DB standen. Wenn also ein geänderter DB übertragen wird, müsste das Laufzeitsystem die vorhandenen Variablenwerte des alten DB noch auf den frisch übertragenen rüberschreiben.

Edit: wegen Zeitablauf inzwischen hinfälliger Beitrag ...


----------



## JesperMP (23 Februar 2011)

Onkel Dagobert schrieb:


> Ein kleines Beispiel aus meiner Praxis.
> Vor ca. drei Jahren habe ich eine größere Kühlwasseranlage programmiert (12MW Maschinenleistung + Freie Kühlung). Unser Auftraggeber "S" hat uns erst in letzter Minute beauftragt. Am ersten Tag auf der Baustelle hatte ich das Programm gerade mal so weit fertig, dass die Handbedienungen möglich waren. Nachdem die ersten Pumpen liefen, durften diese aber auch nicht wieder abschalten! Im ganzen Werk (komletter Neubau) wurden seit diesem Zeitpunkt bereits Maschinen gekühlt. Sämtliche Automatikfunktionen und Regelungen habe ich bei laufender Anlage implementiert und in Betrieb genommen. Nach deiner Methode hätte ich garnicht erst anreisen brauchen.


Ich vermute das du hast ein Framework erstellt, mit standard FBs die du selbst erstallt hast, und wenn diese FB "in Ordnung" gefunden sind, hast du die festgehalten. Danach hast du keine Änderungen auf die FBs oder IDBs gemacht. Dies hat erlaubt das du das Anlage im betrieb halten konnte. Programmänderungen auf die höhere Ebene war noch möglich, nur nicht auf die FBs und IDBs.
Wenn das richtig verstanden ist, dann ist es genau wie ich es auch mache.
Aber was hat es zu tun mit ob man die IDBs von aussen beschreiben darf oder nicht ?

edit: Ich will dazu ergänzen das übergeordnete parameter und sollwerte sind in Global-DBs gespeichert. Aber Befehle wie Start, Stop, Auf, Zu, und Statuswerte schreibe und lese ich direckt in die IDBs.


----------



## smilie108 (23 Februar 2011)

*So nun muss ich mal was loswerden*

Hallo

Ich bin ein enduser wenn man so will. Bin Betriebselektriker der auch mal ganze anlegen neu schreiben darf  

Ich muss zu dieser ganzen diskusion nur eines sagen. Es gibt anlagen da kann man nicht einfach mal die sps neu starten oder riskieren das sie auf stop geht. ( haben Kraftwerke mit Strom / Wasserproduktion oder Pelletierungsanlagen usw. ) Wenn es mir da pasieren würde die anlage rauszuwerfen dan würde ich auch bald rausgeworfen  
Wenn ich änderungen oder anlagentiele dazu machen oder stillegen muss dann meistens während des laufenden Betriebes. Da helfen globale dbs undgemein da man in diesen daten weitergeben kann oder auch von einem teil auf einen neuen übergeben kann und den dazwischenliegenteil solange er exestiert mitwirken lassen kann sollte der dann wegkommen naja dann wird der wert halt nicht 3 mal sondern nur noch 2 mal bearbeitet wenn cih aber das mit instanzen machen würde und ich nehm den mittelteil raus dann stehe ich außer ich ändere dann wieder kopliziert die zugriffe untereinader aus. Wenn mir einer ein Programm mit scl bringt dann bin ich auch angefressen da ich seit pascal nix mehr gemacht habe und daher zwar das versteh ( meistens  ) aber mit ändern hab ich das dan nicht so. 
Sollte vileicht das mal wieder lernen aber das große aber ist wenn du heute fehler suchst bei großen zusammenhäängenden anlagen dann geht das halt in awl und fup/kop wesentlich schneller meiner erfahrung nach.

Deshalb mache ich es so das ich die daten die ich für mehrere sachen benötige oder hmi geschichten ind einzelnen globalen db´s zusammenfasse und dann für die einzelen maschienen und anlagenteile die selben daten zur verfügung habe ich glaube das ist nicht unwichtig

Wenn ich jedesmal alles neu starten könnte naja dann kann ich ja spielen  

So das war mal mein senf dazu


----------



## bike (23 Februar 2011)

smilie108 schrieb:


> Hallo
> 
> Ich bin ein enduser wenn man so will. Bin Betriebselektriker der auch mal ganze anlegen neu schreiben darf
> 
> ...



Kannst du bitte in verständlichem Deutsch dies noch einmal schreiben?
Beachte bitte: http://de.wikipedia.org/wiki/Großschreibung
Es tut mir leid, ich habe es nicht verstanden., was du uns mitteilen willst.
Da ich Entwickler bin, bin sehr interessiert, welche Problem Kunden haben, denn wir schreiben Programme nicht für uns.


bike


----------



## winnman (23 Februar 2011)

Danke allen Disskusionsteilnehmern;

Meine ursprüngliche Frage wurde gut erklärt und gelöst.

Mein eigener Standpunkt zu den Restlichen Punkten:

IDB sind für mich gekapselte Bereiche in denen nur die entsprechenden FB rummurksen sollen. (über entnahme von Werten für die Viso = in manchen Fällen OK aber es soll bitte niemand darin rumschreiben)

Nach meiner Meinung entält ein "sauberes" Programm entsprechende DB in denen die jeweiligen Werte stehen, es sollt eigene DB geben für Anlagenzustände, HMI, Übertragung zu anderen Bereichen, . . .

Wie diese im Detail strukturiert sind (eigener DB für Eingangs Analogwerte normiert, HMI Analogwerte, HMI RM, HMI Befehle, . . . . was auch immer) ist bei vernünftiger Namensgebung und entsprechenden Kommentaren kein Problem.
Diese Programme lassen sich in alle Richtungen relativ einfach verstehen und auch Änderungen sind einfach durchzuführen.

nochmals Danke für die Rege Teilnahme. Mittlerweile Beitrag 146, kaum zu glauben 

Den 146 hab ich während dem schreiben erhalten:

Der Verfasser schreibt mir sehr verständlich die Probleme die "normale" Instandhalter mit solchen Konstrukten von Hochsprachenprogrammierern haben (ist nicht Abwertend, sondern die Realität).
Ist ein Programm entsprechend übersichtlich und strukturiert aufgebaut, kann jederzeit ein entsprechender Teil geändert werden ohne dass es zu irgendwelchen gröberen Problemen kommt.

so hab ich das jedenfalls verstanden.


----------



## marlob (23 Februar 2011)

bike schrieb:


> Kannst du bitte in verständlichem Deutsch dies noch einmal schreiben?
> Beachte bitte: http://de.wikipedia.org/wiki/Großschreibung
> Es tut mir leid, ich habe es nicht verstanden., was du uns mitteilen willst.
> Da ich Entwickler bin, bin sehr interessiert, welche Problem Kunden haben, denn wir schreiben Programme nicht für uns.
> ...


Du willst nicht wirklich jemanden in Deutsch belehren, wenn du so schreibst wie hier


----------



## bike (23 Februar 2011)

marlob schrieb:


> Du willst nicht wirklich jemanden in Deutsch belehren, wenn du so schreibst wie hier



Ich schreibe so schlecht?
Ich habe in "ich vergessen, doch sonst?
Jetzt muss ich nachdenken.
Aber ich konnte aus dem Beitrag nichts sinnvolles herauslesen, sorry


bike


----------



## IBFS (23 Februar 2011)

Langsam wird das hier echt kindisch.
Ich dachte hier unterhalten sich 
Techniker und Ingenieure. 

Ist fast wie bei "We are Family" PRO7 

Frank


----------



## Onkel Dagobert (23 Februar 2011)

Perfektionist schrieb:


> ..Im Übrigen: kann mir mal jemand Feedback geben, ob bei mir im Text auch so wertende Begriffe wie "mies" vorkommen?..


Nein Perfektionist. Du drückst dich eigentlich immer sehr gepflegt aus, das muss man dir lassen. "Mies" ist aber auch kein Schimpfwort. Es ist eigentlich mehr eine höfliche Umschreibung für einen ganz anderen Ausdruck.




JesperMP schrieb:


> Ich vermute das du hast ein Framework erstellt, mit standard FBs die du selbst erstallt hast, und wenn diese FB "in Ordnung" gefunden sind, hast du die festgehalten. Danach hast du keine Änderungen auf die FBs oder IDBs gemacht. Dies hat erlaubt das du das Anlage im betrieb halten konnte. Programmänderungen auf die höhere Ebene war noch möglich, nur nicht auf die FBs und IDBs...


Ganz genau so ist es. IDBs werden bei mir allerdings auch geändert. Wie sollte es auch anders sein. Nur ist es so, dass sämtliche relevanten Zustände und Parameter in den Global-DBs stehen. In den Instanzdaten / Multiinstanzdaten gibt es bei mir solche Dinge wie Verzögerungszeiten und Überwachungszeit, rekursive Berechnungen (z.Bsp. Dämpfungen). Aber alles Dinge, die sich nach einem "Initialisieren" ganz schnell wieder fangen. Meistens lassen sich bei laufender Anlage geänderte Instanzdaten laden, in dem ich den FB-Aufruf auskommentiere und dann den FB und IDB lade. Der IDB kann bei Änderungen ja auch mal kleiner werden. Anschließend schalte ich den Aufruf wieder aktiv. Eigentlich geht es immer gut. Aber auch das hängt von der Anwendung und von der Software-Architektur ab (was für ein schöner Begriff ;-) ).




JesperMP schrieb:


> ..Wenn das richtig verstanden ist, dann ist es genau wie ich es auch mache. Aber was hat es zu tun mit ob man die IDBs von aussen beschreiben darf oder nicht ?
> 
> edit: Ich will dazu ergänzen das übergeordnete parameter und sollwerte sind in Global-DBs gespeichert. Aber Befehle wie Start, Stop, Auf, Zu, und Statuswerte schreibe und lese ich direckt in die IDBs.


Naja, du scheinst es ja wenigstens im Griff zu haben. Wie macht ihr das eigentlich in Flexible, wenn sich die Adressen in den IDBs ändern? Die betroffenen Variablen müssen immer wieder neu verbunden werden, oder? Und stets drann denken, die RT neu zu laden?




bike schrieb:


> Ich schreibe so schlecht?..


Ach was! Das reicht dicke für eine Doktorarbeit. Sofern ich das beurteilen kann ;-) .


----------



## JesperMP (24 Februar 2011)

Onkel Dagobert schrieb:


> IDBs werden bei mir allerdings auch geändert. Wie sollte es auch anders sein.


Dafür muss man ein Framework erstellen, die die benötigte funktionalität hat, und fehlerfrei ist. Ist nicht einfach. Aber ich simuliere dafür auch meine programme um sie weitmöglichst fehlerfrei zu haben. 
Online programmieren zum laufzeit geht auch, so lange das man den deklarationsteil nicht berührst. Erst offline simulieren und testen - wenn OK gefunden - dann der geänderte FB in SPS laden - IDB wird behalten ohne änderung. 
FBs/IDBs auszukommentieren habe ich auch gemacht, aber das war notfall.



Onkel Dagobert schrieb:


> Wie macht ihr das eigentlich in Flexible, wenn sich die Adressen in den IDBs ändern? Die betroffenen Variablen müssen immer wieder neu verbunden werden, oder? Und stets drann denken, die RT neu zu laden?


Bei mir sind alle Daten die mit der HMI ausgetauscht werden, Global-DBs.


----------



## Zefix (24 Februar 2011)

Ich les jetz hier auch schon ne Weile mit.

Vorweg mal, bin auch in der IH tätig.

Ich würd sagen die Mischung machts.

Übersichtlicher und leichter zum handeln würd ich sagen ist Onkels Variante im Bezug auf Erweiter-/Änderbarkeit.

Für gewisse HMI-Lese/Status anzeigen würd ich evtl. auch in IDBs gehen.
Und auch für die Handbedienung über HMI sogar schreibend.

Wenns aber um Datenhaltung geht, wie z.B. Produkt Sachnummern usw. die gegen gelesen werden oder Achspositionen,  das alles übers HMI gepflegt wird, dann ganz klar Global DB.

Also für ein striktes Hopp oder Topp würd ich mich nicht entscheiden.


----------



## smilie108 (24 Februar 2011)

*@bike*

@bike Die rechtschreibfehler kannst du Dir Schenken. 
Tut mir leid das  ich so manches nicht ganz Gramatikalisch ( ist das Richtig ?) richtig  habe. Aber ich bin ja auch kein "Studierter" der sein ganzes Leben den  Buchstaben und Zahlen widmet.

Außerdem habe ich diesen beitrag geschrieben da war ich schon ca 18h auf den Beinen und dabei sind die Augen schon ganz schön  schwer gewesen. Aber so ist das halt mal in der Instandhaltung da gehst  halt nicht heim wenn was nicht geht oder so.

Muss noch eines loswerden : Es ist echt super hier im forum da man hier sehr viel Fachwissen vorfindet.
Ich musste leider in der Vergangenheit schon so manchen blödsinn miterleben wie zb. das ein Programmierer eine Anlage in Betrieb nimmt und dann erst relativ langwierig und umständlich Änderungen vornehmen kann da er zuerst wiedereinmal in SCL das ändern darf und dann Übersetzen und einspielen. Des weiteren hatte ich noch nie eine inbetriebnahme bei der nicht einige FB´s und FC erweitert oder umgeschrieben werden mussten.

Komme aus der Sägeindustrie und da gibt es numal lebendes Material auf das man die Anlage immer wieder mal Optimieren muss sei es weil Antriebe umgebaut werden oder sich der Ablauf  ändert deshalb ist es mir am Liebsten wenn ich auch einstellwerte in Globalen db´s habe da sich da Änderungen relative einfach Handhaben lassen. 

Wenn ich heute eine CNC Fräße habe die immer Quasi das gleiche macht dann kann ich wenn ich einmal Fehlerfrei bin das ganze sicher in gekapselten systemen machen aber wenn man Anlagen hat ( größer 600 i/o´s) die kein Jahr so stehen wie im Vorjahr dann muss man sich wegen dem händling schön gedanken machen da meistens für die IBN nur 2 tage zeit sind und mann den rest während der Produktion machen muss.
Da kann man nicht so einfach mal cpu neu starten.

Das meinte ich eigentlich damit.

Ps. Leider habe ich bis auf ein paar kleine Ausnahmen keine guten Erfahrungen mit "Fremdprogrmierer" gemacht da diese meistens nicht wissen wie alles ineinandergreift von der Mechanischen seite her.

Pss Sollte ich wieder Recht oder Gramatikfehler haben naja war in Deutsch in der Schule schon nicht gut


----------

