# Programmstruktur Step7



## mariob (17 August 2010)

Hallo,
als Umsteiger von Step5 nach Step7 stehe ich vor dem Problem der Grobstrukturierung der Software für ein Transportsystem. OB1 wollte ich als Sprungverteiler für die FBs/FCs nutzen. Soweitsogut. Es sind im wesentlichen 3 Antriebe, einer geregelt, also einen Antriebsbaustein, einer HMI (vielleicht auch zwei), mehrere Bausteine für das übrige logistische Drumherum (Weichen und solcher Kram). Und ein wenig mit arlarmgesteuerter Bearbeitung für die zeitkritischen Dinge. Nix wirklich großes.
Ich bin noch fleißig beim Handbücherlesen, und übe schonmal ein wenig mit dem Programmiersystem klarkommen. Am besten mit der praktischen Aufgabenstellung. In Unkenntnis der Besonderheiten, wie ist das mit dem FB1, bei der S5 hatte der die Besonderheit auch standalone zu arbeiten, ist das noch so, nimmt man den dann überhaupt für triviale Dinge?
Was schlagen die Profis vor? Fragen über Fragen......

Gruß
Mario


----------



## jabba (17 August 2010)

Hallo Mario,

also vom Prinzip her ist es gleich wie bei der S5, nur das die PB's jetzt FC's heissen.

Natürlich gibt es einiges neues bei der S7, was man vieleicht nutzen sollte aber nicht muß.

Du brauchst den OB1 prinzipiell um die Bausteine aufzurufen (Sonder OB's mal ausser acht gelassen)
Von da springst du in deine Bausteine
z.B.
FC1 Antrieb1
FC2 Antrieb2 
...
usw.

Für die Visualisierung solltest du einen DB anlegen, in dem die Kommunikation stattfindet. Dort können dann die Tasten für die Bedienung sowie die Variablen für die Anzeigen rein.

Weiterhin einen DB für z.B. die Störmeldungen.

Was gibt das denn für eine CPU und Panel ?

Was du mit dem FB1 meinst ist mir unklar oder meinst Du OB1 oder den DB1 ?


----------



## mariob (17 August 2010)

Danke für die Antwort Jabba,
also, bei den "großen" S5 wird bei Nichtvorhandensein des OB1 ersatzweise der FB1 abgearbeitet.
Zur SPS, Vipa 317 als Net und Speed7 Version in dieser Station, Proface AGP 3400 als buntes ist HMI, Kommunikation über Ethernet. Programmierung mit WINSPS, so beim Handbuchlesen ist das genüber Step5 schon ein Quantensprung, ich habe heute auch schonmal ein wenig mit der Demo gespielt. Eine Menge Eindrücke in zwei Tagen, trotzdem genial.
Ja, mit den DBs dachte ich das auch so ähnlich, bei FBs kann man ja dann eine Art hauseigenen DB parametrieren. 
Frage 1: Ist der Zugriff innerhalb des FBs dann schneller?
Frage 2: Kann man einen solchen Instanzen DB in anderen Bausteinen, also mit A DBschlagmichtot aufrufen und bearbeiten, ohne das einem da irgendwas um die Ohren fliegt? Ich lasse jetzt mal Flankenerkennungen außen vor.

Gruß
Mario


----------



## Perfektionist (17 August 2010)

Instanzdaten eines FB ist eine Sache, die in Richtung objektorientierte Programmierung geht. Manche Programmierer haben dies zu S5-Zeiten so nachgebildet, dass sie zu einem FB oder PB grundsätzlich einen dazugehörigen DB benutzt haben oder den DB vor Aufruf des FB oder PB geöffnet haben, um Bausteine zu instanzieren. Andere haben Schmiermerker benutzt, wobei die zu bearbeitenden Daten zunächst häufig aus DB dorthin und nach Abarbeitung des Codes zurück in den DB kopiert wurden.

Diese Umständlichkeiten haben nun mit S7 in Form des Instanz-DB bzw. der Multiinstanz ein Ende gefunden. Jeder FB bekommt automatisch eine zugehörige (Daten-)Instanz. Die Kommunikation zu anderen Methoden (Funktionen und Prozeduren) erfolgt vorzugsweise über die Schnittstelle des Bausteins (Kapselung).

Selbstverständlich kann man die S7 so programmieren, wie man es aus S5-Zeiten gewohnt ist. Dabei ersetzt der FC den alten PB und auch den alten S5-FB. Der S7-FB ist nicht wirklich mit dem S5-FB vergleichbar, da dem S5-FB die Instanzierbarkeit fehlt.


----------



## Paule (18 August 2010)

Also wie Jabba schon sagt, entspricht der S5 PB dem S7 FC.
Aber auch der selbst parametrierte S5 FB mit Ein-/Ausgangsparametern entspricht einem FC da er keine eigenen Daten verwalten kann, sonder immer auf einen Globalen Datenbaustein angewiesen war (Auf DB oder B =DB).
Ein FB in der S7 kann für folgende Funktionen genommen werden:
- Als normaler Baustein für triviale Operationen
- Als Baustein der Berechnungen ausführt und die Zwischenergebnisse in seinem eigenen Datenbaustein speichert
- Als Mutterinstanz für andere Funktionsbausteine

Merkmal eines S7 FB's ist, dass er immer einen Datenbaustein braucht, entweder einen eigenen oder wenn er als Multiinstanz aufgerufen wird, den des "Mutter FB".


----------



## mariob (18 August 2010)

Ja, das ist schon soweit klar,
ich erkenne auch den Vorteil dieses Instanzdatenkonstrukts. Meine Frage zielt in die Richtung, ob ich diesen FBDB in - jetzt mal weit hergeholt - in einem OB aufrufen darf und da reinschreiben. Im übrigen kann man sich ja auch mal im Programmierstil etwas umgewöhnen, insbesondere dann wenn es eine Verbesserung ist. Ansonsten ist man tot.
Und die andere Frage, ist der Zugriff auf den DB schneller?
Wie gesagt, ich setze mich auch recht intensiv mit der Literatur dazu auseinander, aber an den Stellen bin ich noch nicht. Dazu kommt das Problem, das ich als Perfektionist, entschuldige Perfektionist, hier einen Schnellstart hinlegen muß, wie immer in dieser Gesellschaft. Das kennen aber hier sicherlich viele.

Gruß
Mario


----------



## bike (18 August 2010)

mariob schrieb:


> Meine Frage zielt in die Richtung, ob ich diesen FBDB in - jetzt mal weit hergeholt - in einem OB aufrufen darf und da reinschreiben.


Also dürfen tust du, doch ist es schlechter Stil, in einen IDB irgendwo im Programm zu schreiben. 
Auf einmal hast du Effekte, die nicht zu erklären sind, wenn zur Laufzeit dein IDB geändert wurde und dann dein FB darauf reagiert.
Beim Lesen aus einem IDB ist es Geschmacksache, es geht, doch ich z.B. mache es nicht.

Wenn du in einem FB mit dem AR2 arbeitest, dann denk daran, zuerst zu sichern und wieder zurückzuschreiben.

bike


----------



## Perfektionist (19 August 2010)

bike sagte es schon: in einen IDB von anderer Stelle als von seinen FB zugehörigen aus zuzugreifen ist zwar möglich aber verpönt. Der Grund liegt darin, dass man ja kapseln möchte.

Der Zugriff auf einen IDB (von seinem FB aus) ist schneller, als man es von S5 her bei DB-Zugriffen gewohnt ist. Da die S7-CPUs mal grundsätzlich schneller sind und auch jüngst noch schneller geworden sind, stellt sich die Frage, ob man performanter auf Globaldaten zugreift, kaum mehr. Ich persönlich schreibe grundsätzlich bis auf ganz wenige Ausnahmen, wo ein Baustein wirklich kein Gedächtnis braucht, nur noch FB. Dabei beschränkt sich die Verwendung von Globaldaten darauf, wirklich nur globale Signale zu verwenden. So, wie die Zykluszeit oder den Anlauf der CPU. Oder die Bitmeldungen der HMI, die dann allerdings ein Fehlerverwaltungs-FB letztlich dann doch in seiner Instanz verwaltet. D.h., im Programm wird ein Merker für einen Fehler gesetzt, der FB übernimmt dann das weiterreichen an die HMI und das Quittieren.


----------



## mariob (19 August 2010)

Hmm Perfektionist,
also, ich stimme da erstmal zu 100 Prozent überein, sofern man kapseln kann. In meinem Fall habe ich aber viele, wirklich winzige Teilabschnitte. Bei den ersten Gehversuchen heute für mich kam ich zur Erkenntnis, das das Schreiben von FBs sehr schnell einen Wust auch an nicht benötigten DBs mit sich bringt. Das ist dann nicht wirklich übersichtlich (obwohl ich auch dachte, ich mache alles mit FBs).
Insofern hat der FC auch seine Vorteile, zumal andere Programmiersprachen aus der Nichtautomatisierungstechnik solcherlei lokale und trotzdem "remanente" Speicherbereiche gar nicht kennen. Will heißen, wenn ich eine globale Definition vornehme, die dann nur lokal verwendet wird, habe ich auch kein Problem damit. Ist aber Geschmackssache.
Du sprachst von HMI, ich hatte mir das im Kopf auch so zurechtgebastelt, einen FB für das Panel, sowohl der FB oder FC schreiben/lesen in einen Nicht Instanz DB und gut. Wenn FB, dann hat er halt einen InstanzDB, dieser bleibt dann aber auch ein solcher, auch wenn ich ganz am Anfang schon darüber nachgedacht habe, in diesen mit dem Panel herumzufummeln.
Naja, effektiv bei Tag 4 bin ich schon zufrieden mit dem Erkenntnisgewinn in Anbetracht der vielen, unbekannten noch zu beackernden Dinge (also was das richtige Step 7 betrifft, ich habe noch keinen blassen Dunst, wie ich dieses Proface via Ethernet an die Kiste kriege). 

Gruß
Mario


----------



## Perfektionist (20 August 2010)

mariob schrieb:


> ... kam ich zur Erkenntnis, das das Schreiben von FBs sehr schnell einen Wust auch an nicht benötigten DBs mit sich bringt.


nicht benötigter DB = leerer DB? Um den Wust (Menge) zu reduzieren gibts die Multiinstanz. Um den DB einen Sinn zu geben lege ich dort z.B. Timerwerte und sonstige Parameter ab. Und Instanzen von IEC-Timern lassen sich dort auch unterbringen.



mariob schrieb:


> ... zumal andere Programmiersprachen aus der Nichtautomatisierungstechnik solcherlei lokale und trotzdem "remanente" Speicherbereiche gar nicht kennen.


Ich hoffe, ein Betriebsstundenzähler ist ein einfaches Beispiel, das aufzeigt, dass die Nichtautomatisierungssprachen sich auch für den Zweck nicht besonders eignen.



mariob schrieb:


> Wenn FB, dann hat er halt einen InstanzDB, dieser bleibt dann aber auch ein solcher, auch wenn ich ganz am Anfang schon darüber nachgedacht habe, in diesen mit dem Panel herumzufummeln.


Formal darf es nicht sein, dass die HMI auf einen gekapselten Baustein ohne definierte Schnittstelle zugreift. Leider definiert Siemens neben der In/Out-Deklaration keinen besonders ausgezeichneten HMI-Schnittstellenbereich. Ich persönlich betrachte einen FB als eine virtuelle SPS für sich. und in die Instanz dessen greife ich mit der HMI so zu, als ob es eine physikalische Steuerung wäre.


----------



## rostiger Nagel (20 August 2010)

Perfektionist schrieb:


> Formal darf es nicht sein, dass die HMI auf einen gekapselten Baustein ohne definierte Schnittstelle zugreift. Leider definiert Siemens neben der In/Out-Deklaration keinen besonders ausgezeichneten HMI-Schnittstellenbereich. Ich persönlich betrachte einen FB als eine virtuelle SPS für sich. und *in die Instanz dessen greife ich mit der HMI so zu, als ob es eine physikalische Steuerung wäre.*


 
Hallo Perfekter wie meinst du das jetzt, du greifst also zu?


----------



## Matze001 (20 August 2010)

Ich denke er meint er macht es über Variablen die er als In bzw. Out Parameter gekennzeichnet hat.

MfG

Marcel


----------



## Perfektionist (20 August 2010)

Helmut_von_der_Reparatur schrieb:


> Hallo Perfekter wie meinst du das jetzt, du greifst also zu?


Ja, ich greife zu. Ich greife in einer Instanz mit der HMI so ungeniert zu, wie in einer SPS im Merkerbereich.


----------



## rostiger Nagel (20 August 2010)

Perfektionist schrieb:


> Ja, ich greife zu. Ich greife in einer Instanz mit der HMI so ungeniert zu, wie in einer SPS im Merkerbereich.


 
Das mach ich auch, wir sind schon zwei Halunken


----------



## Aventinus (20 August 2010)

Ich finde diese Varinate sogar sehr sinnvoll. Für solche Fälle lege ich in der Instanz eine Struktur für die HMI an und rangiere darüber den ganzen Zauber.
Diese Struktur bilde ich in WinCCflex auch ab und bastle einen Bildbaustein. Schon ist für einen FB-Aufruf auch die Visu schon fast fertig.


----------



## rostiger Nagel (20 August 2010)

Aventinus schrieb:


> Ich finde diese Varinate sogar sehr sinnvoll. Für solche Fälle lege ich in der Instanz eine Struktur für die HMI an und rangiere darüber den ganzen Zauber.
> Diese Struktur bilde ich in WinCCflex auch ab und bastle einen Bildbaustein. Schon ist für einen FB-Aufruf auch die Visu schon fast fertig.


 
du bist auch ein Verbrecher, wie der perfekte und ich


----------



## crash (20 August 2010)

Helmut_von_der_Reparatur schrieb:


> du bist auch ein Verbrecher, wie der perfekte und ich


Was ist hier los?
So viel "kriminelle Energie" auf einem Haufen.


----------



## IBFS (20 August 2010)

Perfektionist schrieb:


> Ich persönlich betrachte einen FB als eine virtuelle SPS für sich. und in die Instanz dessen greife ich mit der HMI so zu, als ob es eine physikalische Steuerung wäre.


 
In den Anfangszeiten habe ich das auch mal gemacht, weil ich es  fand.

Aber irgendwer hat mich dann wieder davon abgebracht, weils angeblich
keine sauberer Programmierstil wäre.  

Scheiß darauf  bleibt .

S7 rules.


Frank


----------



## Aventinus (20 August 2010)

Helmut_von_der_Reparatur schrieb:


> du bist auch ein Verbrecher, wie der perfekte und ich



Na und?

Ich finds praktisch, und schnell ist das auf jeden Fall


----------



## Perfektionist (21 August 2010)

Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet. einen leisen Hinweis hab ich in folgendem Thread gefunden. Aber im groß und ganzen einiges, das die Verwendung von FB und Zugriff durch HMI rechtfertigt.
http://www.sps-forum.de/showthread.php?t=28321
.


----------



## Paule (21 August 2010)

Perfektionist schrieb:


> Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet.


Lesen aus der Instanz, klar warum nicht.
Schreiben absolutes "no go", da die Daten nicht richtig gesichert werden können.
Sprich wird der Instanzdatenbaustein frisch generiert, da der FB erweitert wurde, müssen am Panel die Daten neu eingegeben werden. 
Das geht ja wohl überhaupt nicht.

So jetzt könnt ihr mal loslegen und mich verhauen.


----------



## rostiger Nagel (21 August 2010)

Paule schrieb:


> Lesen aus der Instanz, klar warum nicht.
> Schreiben absolutes "no go", da die Daten nicht richtig gesichert werden können.
> Sprich wird der Instanzdatenbaustein frisch generiert, da der FB erweitert wurde, müssen am Panel die Daten neu eingegeben werden.
> Das geht ja wohl überhaupt nicht.
> ...


 
jetzt gibt es Dresche 

,

Paule, scheiß auf Kappselung. Ich knalle alles in FB's und Deklariere
meine Variabeln Lokal im Kopf. Dazu gehören dann auch zB. IEC Timer.
Da habe ich gar keinen Bock drauf, die Zeitwerte von den PT Eingang
noch mal Global zu schreiben. Auf solche sachen greif ich einfach aus
der HMI zu und beschreibe die sogar.
Daten im Panel neu eingeben fällt mir in soweit leicht, das ich diese
Fixdaten einfach in ein Rezept speicher und nach dem Hochfahren dieses
Rezept lade, das hat sogar den Vorteil wenn der Maschinenbediener
mal gespielt hat, kann ich die Daten wieder Restaurieren.

Wo war noch mal das Problemm


----------



## Paule (21 August 2010)

Helmut_von_der_Reparatur schrieb:


> Daten im Panel neu eingeben fällt mir in soweit leicht, das ich diese
> Fixdaten einfach in ein Rezept speicher und nach dem Hochfahren dieses
> Rezept lade,


Das ist aber auch die einzige Ausnahme die ich gelten lasse. 
Alles andere ist Schlamperei.


----------



## Perfektionist (21 August 2010)

Helmut_von_der_Reparatur schrieb:


> Daten im Panel neu eingeben fällt mir ... leicht, ...


mach ich genauso. Ich hab sogar mal ein Flex-Panel nur zu diesem Zweck als Simulation für meinen Erstellrechner gebastelt, weil an der Maschine kein rezepturtaugliches Gerät dranhing. Und richtig geil ists, wenn man dann nach der IBN seine Parameter über die Export-Funktion mit einem Fingerschnipp dokumentieren kann.


----------



## rostiger Nagel (21 August 2010)

Siehste Paule, der Perfekte und ich sind keine Schlampen


----------



## bike (22 August 2010)

Klar, es ist jedem selbst überlassen wie er oder sie programmieren.
Mir erschließt sich aber nicht, warum ich in einem IDB rumschreiben muss.
Nicht alles was möglich ist, ist auch gut und richtig.
Da die Frage von jemand kam, der mit Step7 anfängt stellt sich mir die Frage:
Warum nicht gleich richtig lernen?
Ich behaupte Siemens hat sich etwas überlegt, wenn es die Unterscheidung Global und Instanz gibt.

bike


----------



## IBFS (22 August 2010)

bike schrieb:


> Mir erschließt sich aber nicht, warum ich in einem IDB rumschreiben muss.


 
1. Nicht DU sondern die VISU schreibt drin rum.

2. Das PID-Tool: --> C:\Siemens\Step7\S7WRI\S7wriapx.exe <<-- schreibt die Werte -so man will - auch direkt in die STATs hinein

3. Ein "losgelöster" DB, ist auch nicht gerade vor "(un)beabsichtigten" veränderungen sicher.

4. Es bischen iMAP-Gedanke steckt dahinter, die SPS ist ja da auch ein Stellvertreterobjekt, hier bei "HvdR" ist es die VISU-Anbindung

5. Von der SPS direkt in einen IDB zu schreiben, davon halte ich hingegen nichts!



> *KOP/FUP/AWL*
> 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.


 
Bei machen Fremdprogrammen muß ich echt den Haken rausmachen, sonst gehts nicht 

Frank


----------



## Perfektionist (22 August 2010)

bike schrieb:


> Warum nicht gleich richtig lernen?


Kannst Du uns auch sagen, was Du für richtig findest? was man falsch machen kann, hast Du ja bereits gesagt - aber was ist in Deinen Augen richtig?



bike schrieb:


> Ich behaupte Siemens hat sich etwas überlegt, wenn es die Unterscheidung Global und Instanz gibt.


Lass uns an den Gedanken teilhaben!


----------



## Perfektionist (22 August 2010)

IBFS schrieb:


> Das PID-Tool: ...


ist das DB-Param?


----------



## IBFS (22 August 2010)

Perfektionist schrieb:


> ist das DB-Param?


 
nene DB-Param ist fürn FB58 - ist aber fast das gleiche.

"PID Control parametrieren"  ist eine eigenständige SW für den FB41

Da schreibt man direkt in den IDB für den Regler-FB41 hinein.




OT-ON:
Damit kann man sich wunderbar eine Art VAT-Schreiber bauen.
Einfach IDB-erzeugen - FB wegschmeißen und dann 
z.B. Sollwert und Istwert mit den zu beobachtenden Werten belegen
- muss nix mit PID zu tun haben - und schon hat man für STEP7 einen
Online-Mini-Kurvenschreiber   
OT-OFF:


Frank


----------



## IBFS (22 August 2010)

Helmut_von_der_Reparatur schrieb:


> jetzt gibt es Dresche
> 
> ,


 
wenn schon Krieg dann aber so --> 



Haha

Frank


----------



## Paule (22 August 2010)

IBFS schrieb:


> wenn schon Krieg dann aber so -->


Mann, Du fährst ja Geschütze auf! 



IBFS schrieb:


> "PID Control parametrieren" ist eine eigenständige SW für den FB41
> 
> Da schreibt man direkt in den IDB für den Regler-FB41 hinein.


Also klar kann man aus jedem (Entschuldigung) Murks einen Vorteil entdecken.


----------



## IBFS (22 August 2010)

Paule schrieb:


> Also klar kann man aus jedem (Entschuldigung) Murks einen Vorteil entdecken.


 
Sei doch froh, 
.
.
...dass du bei einem FB nicht alle Ein- und Ausgänge mit Variablen beschalten musst.

Wenn du z.B. den SETPOINT nur in der VISU und in REZEPTEN (VISU!) verwendest,
dann reicht doch, die im IDB schon intern verwendete Variable.

Da muss man doch nicht noch aussen eine zusätzliche Variable 
"anknüppern" zumal wenn man solche TOOLS wie Selftuning oder das
o.g. PID-TOOL nimmt. Wenn du da von aussen ein Variable anträgst,
dann ist es Essig mit solchen TOOLS, weil deine IDB-VAR ständig
von aussen überschreiben wird (logisch).

Frank


----------



## bike (22 August 2010)

Perfektionist schrieb:


> Kannst Du uns auch sagen, was Du für richtig findest? was man falsch machen kann, hast Du ja bereits gesagt - aber was ist in Deinen Augen richtig?
> 
> Lass uns an den Gedanken teilhaben!


Schreibe ich nicht deutsch?
Ich kann es dir, wenn notwendig gern in eine andere Sprache übersetzen.

Es ist Mist, wenn bei Projekten, an denen mehrere Leute schreiben, IDB willkürlich beschrieben werden. Es werden Nahtstellen definiert und an die hält sich jeder, dann klappt es auch mit dem Kollgen.

Dass du es besser weißt und die Unterscheidung global und lokal nicht richtig findest ist dein Ding, Siemens hat sich etwas dabei gedacht.
Dies ist nicht nur bei PLC Programmierung so, sondern auch in anderen Programmiersprachen normal.

Du kannst es ja bestimmt besser und daher lass es gut sein.


bike


P.S: Sachlich sind die Beiträge nicht mehr und einen Glaubenskrieg darüber ist mir zu schwach, daher schreib weiter und werde glücklich.


----------



## IBFS (22 August 2010)

bike schrieb:


> Schreibe ich nicht deutsch?
> Ich kann es dir, wenn notwendig gern in eine andere Sprache übersetzen.
> 
> Es ist Mist, wenn bei Projekten, an denen mehrere Leute schreiben, IDB willkürlich beschrieben werden. Es werden Nahtstellen definiert und an die hält sich jeder, dann klappt es auch mit dem Kollgen.
> ...


 
@bike 
Findest du nicht das du etwas überreagierst? 



Ich finde schon, das es ein Unterschied ist, ob man einen IDB nur als VISU-Anbindung nimmt, was ich durchaus OK finde.

oder

ob man vom SPS-Programm aus in einen IDB-schreibt oder von ihm ließt. Das kansch auch nich leiden!

*KOP/FUP/AWL-->  *Querzugriffe als Fehler melden


Frank


----------



## rostiger Nagel (22 August 2010)

das schöne an diesen Thread ist, das wir es endlich schaffen das Sommerloch zu füllen


----------



## IBFS (22 August 2010)

Helmut_von_der_Reparatur schrieb:


> das schöne an diesen Thread ist, das wir es endlich schaffen das Sommerloch zu füllen


----------



## Perfektionist (22 August 2010)

bike schrieb:


> Schreibe ich nicht deutsch?


nein, les doch bitte nochmal den Scheiss, den Du geschrieben hast:


bike schrieb:


> Klar, es ist jedem selbst überlasen wie er oder sie programmieren.


Das ist nicht Deine wahre Einstellung, Du regst Dich auf.


bike schrieb:


> Mir erschließt sich aber nicht, warum ich in einem IDB rumschreiben muss.


siehe:





> Klar, es ist jedem selbst überlasen wie er oder sie programmieren.


Erkläre, warum man es nicht tun soll und tu nicht so, als ob Du schlicht zu dumm wärst, nachzuvollziehen, warum andere das tun, was Du verachtest. Du differenzierst nichtmal danach, ob der Zugriff quer oder per Visu verachtenswert ist. Stelle bitte dar, warum nicht nur der Querzugriff Scheisse ist, sondern auch der Visu-Zugriff.


bike schrieb:


> Es ist Mist, wenn bei Projekten, an denen mehrere Leute schreiben, IDB willkürlich beschrieben werden. Es werden Nahtstellen definiert und an die hält sich jeder, dann klappt es auch mit dem Kollgen.


Auch zu S5-Zeiten konnte man miit seinen Kollegen Schnittstellen vereinbaren, da gabs noch nichtmal IDBs.


bike schrieb:


> Dass du es besser weißt und die *Unterscheidung global und lokal nicht richtig* findest ist dein Ding, Siemens hat sich etwas dabei gedacht.
> Dies ist nicht nur bei PLC Programmierung so, sondern auch in anderen Programmiersprachen normal.


Was schiebst Du mir da unter? Zitier mich mal korrekt! 


bike schrieb:


> P.S: Sachlich sind die Beiträge nicht mehr und einen Glaubenskrieg darüber ist mir zu schwach, daher schreib weiter und werde glücklich.


Schopenhauer, ick hör dir trapsen ...


----------



## bike (22 August 2010)

Perfektionist schrieb:


> nein, les doch bitte nochmal den Scheiss, den Du geschrieben hast:
> Das ist nicht Deine wahre Einstellung, Du regst Dich auf.
> siehe:Erkläre, warum man es nicht tun soll und tu nicht so, als ob Du schlicht zu dumm wärst, nachzuvollziehen, warum andere das tun, was Du verachtest. Du differenzierst nichtmal danach, ob der Zugriff quer oder per Visu verachtenswert ist. Stelle bitte dar, warum nicht nur der Querzugriff Scheisse ist, sondern auch der Visu-Zugriff.
> Auch zu S5-Zeiten konnte man miit seinen Kollegen Schnittstellen vereinbaren, da gabs noch nichtmal IDBs.
> ...


Entschuldigung ich habe vergessen, dass du das Programmieren von PLC erfunden hast.
Was soll ich da noch differenzieren?
Ich mich über deine Beiträge aufregen? Das ist es mir nicht wert.

Eines noch:
Ich bin zu dumm, um deine Art zu programmieren zu verstehen?
So etwas sage ich nicht einmal über Programmierer die ich kenne und deren Programme ich zum Laufen gebracht habe. 
Und machst das so, obwohl du nicht eine Programmzeile von mir jemals gesehen hast?
Langsam solltest du einmal in dich gehen, bevor du andere persönlich angreifst. 

bike


----------



## rostiger Nagel (22 August 2010)

Darf mann eigentlich IDB's bzw. FB's mit entsprechenden IDB's rein zur
Kappselungszwecken schreiben. Oder kann bzw. darf mann Sie auch
anders nutzen?

Sind eigentlich immer an jeder Anlage zig Programmierer mit allen erdenk-
lichen Schnittstellen nach außen oder gibt es den Fall auch das nur einer
daran Arbeitet, ohne Schnittstellen. Ich denke da so an überschauliche
Maschinen, nicht immer Atomkraftwerke.

Wo hat Siemens eigentlich derfiniert, das IDB nur gekappselt verwendet
werden dürfen. Warum haben Sie andere zugriffe im Editor nicht einfach
gesperrt.


----------



## Paule (22 August 2010)

Perfektionist schrieb:


> Du differenzierst nichtmal danach, ob der Zugriff quer oder per Visu verachtenswert ist. Stelle bitte dar, warum nicht nur der Querzugriff Scheisse ist, sondern auch der Visu-Zugriff.


Das habe ich doch schon getan:


Paule schrieb:


> Lesen aus der Instanz, klar warum nicht.
> Schreiben absolutes "no go", da die Daten nicht richtig gesichert werden können.
> Sprich wird der Instanzdatenbaustein frisch generiert, da der FB erweitert wurde, müssen am Panel die Daten neu eingegeben werden.
> Das geht ja wohl überhaupt nicht.


Hallo Perfektionist, das was du hier schreibst macht deinem Namen nicht alle Ehre.
Mit so einem Namen erwartet jeder absolut perfekte unantastbare Programmierung. 


Helmut_von_der_Reparatur schrieb:


> Sind eigentlich immer an jeder Anlage zig Programmierer mit allen erdenk-
> lichen Schnittstellen nach außen oder gibt es den Fall auch das nur einer
> daran Arbeitet, ohne Schnittstellen. Ich denke da so an überschauliche
> Maschinen, nicht immer Atomkraftwerke.


Sollte an dieser Stelle nicht kommen: "Auch die Instandhalter müssen mit der Anlage klar kommen." 
OK, als nicht genanntes Argument lasse ich gelten das nicht gleich jeder Instandhalter FB's erweitert.
Aber gut das wir mal darüber gesprochen haben.


----------



## rostiger Nagel (23 August 2010)

Paule schrieb:


> Sollte an dieser Stelle nicht kommen: "Auch die Instandhalter müssen mit der Anlage klar kommen."
> OK, als nicht genanntes Argument lasse ich gelten das nicht gleich jeder Instandhalter FB's erweitert.
> Aber gut das wir mal darüber gesprochen haben.



aber instandhalter können doch erweitern bzw
warten. Irgendwann kommst du auch dahin, 
ich habe auf jeden Fall Geduld mit dir


----------



## PN/DP (23 August 2010)

Perfektionist schrieb:


> Ja, ich greife zu. Ich greife in einer Instanz mit der HMI so ungeniert zu, wie in einer SPS im Merkerbereich.


Das überrascht mich dann doch gehörig, wo Du doch so oft von Kapselung schreibst und Querzugriffe auch ablehnst.
Fast möchte ich Dir vorschlagen, unsere Nicknames zu tauschen. Mir deucht, Deiner passt besser zu mir 

Schließt man das Kabel vom Start/Stop-Taster samt Leuchtmelder direkt am Hauptschütz des Antriebs an oder benutzt 
man Hilfskontakte und setzt im Schaltschrank eine extra Klemmleiste?
Warum soll man nicht in der Elektrik bewährte Prinzipien auch für die Programmierung anwenden, auch wenn man nicht 
weiß, warum etwas heute so-und-so gemacht wird?



Perfektionist schrieb:


> Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet.


*Ich finde Zugriffe der HMI auf Instanz-DB als absolutes No-Go*, und zwar aus praktischen Erfahrungen.
Ich hatte in meinem Programmiererleben auch mal die Phase, wo ich HMI-Zugriffe auf IDB in Ordnung fand (ist doch 
so quick und easy), doch spätestens bei nachträglichen Änderungen an diesen Programmen wurde ich dafür mit teils 
erheblicher Mehrarbeit bestraft.

Gründe für meine Meinung:
* die Problematik der Initialisierung von IDB bei deren Neu-Generierung wurde schon von Paule genannt
* manchmal kann das HMI-Projekt nicht geändert werden oder die Änderung ist sehr aufwendig
* ich möchte bei Programmänderungen nur eine (zusammenhängende) Schnittstelle zur HMI beachten müssen
* mein Steuerungsprogramm soll Vorrang vor Eingriffen der HMI haben
* keine Eingaben/Bedienungen der HMI werden ungeprüft oder unverknüpft im Steurungsprogramm verarbeitet
* die HMI und die HMI-Animationen sind leichter testbar, wenn sie nicht auf die original-Variablen zugreifen

Es kommt öfter vor als gedacht, daß Hersteller einer Anlage wegen schlechtem Projektmanagement nicht mehr wissen, 
welche HMI-Projektversion aktuell in der Anlage ist oder das aktuelle HMI-Projekt garnicht mehr besitzen. Und noch 
öfter, daß sie für ein paar simple Adress-Anpassungen exorbitante Preise verlangen.
In diesen Fällen dürfen also Programmänderungen auf keinen Fall Einflüsse auf die HMI haben.
Wenn ich dann IDB nicht ändern darf, weil die HMI wahrscheinlich direkt darauf zugreift, dann möchte ich regelmäßig 
jemanden würgen ...

Doch auch wenn das HMI-Projekt vorhanden ist, kann eine notwendige Änderung an IDB (besonders bei Multi-Instanzen) 
erhebliche Arbeit am HMI-Projekt nach sich ziehen. Oft ist das HMI-Projekt nicht im Steuerungsprojekt integriert. 
Dann müssen alle nötigen Adressänderungen per Hand ausgeführt werden. Und nicht jede HMI-Software ist so einfach 
aufgebaut wie ProTool.
Immer ist aber zumindest eine Neu-Generierung des HMI-Projektes nötig und es muß (meist im laufenden Betrieb) auf 
alle betroffenen Panele und Visualisierungen aufgespielt werden. Das können auch mal 10 OP7 sein, wo man mit dem 
Notebook zu jedem einzelnen OP hinlaufen muß, um das Projekt aufzuspielen. Dazu kommt der Organisationsaufwand, 
weil die noch nicht upgedateten Panele auf keinen Fall benutzt werden dürfen oder die Panele müssen gar vorab alle 
ausgeschaltet werden.

Diese viele Arbeit ist nicht nötig, wenn die HMI ausschließlich über wenige Schnittstellen-DB auf die Steuerung 
zugreift und niemals über IDB. Ich betrachte die HMI-Schnittstellen-DB als Rangier-Klemmleiste zur HMI.

Bei mir erhält die HMI fast nie Zugriff auf die original-Steuerungsvariablen, sondern regelmäßig nur auf Kopien 
oder Zwischenvariablen in den Schnittstellen-DB. So ist es unerheblich, wenn die HMI durch Projektierungsfehler 
oder Compilierfehler auf diese Variablen schreibt. In den meisten HMI-ES die ich kenne, kann man Prozessvariablen 
nicht als read-only deklarieren. Nur in Wonderware Intouch kann man ein entsprechendes Häkchen setzen, doch auch 
da wird dieses Feature sogut wie nie von anderen Programmierern genutzt, weil das zusätzliche Arbeit macht.

(Hier muß ich allerdings erwähnen, daß man bei Simatic-CPU alle Variablen generell nicht vor Schreibzugriffen von 
außen schützen kann. Einziger sicherer Schutz: nicht vernetzen!)

Eingabewerte von der HMI lasse ich nicht ungeprüft auf Steuerungsvariablen schreiben. Ich möchte nicht, daß meine 
CPU in Stop geht oder das Steuerungsprogramm ins schleudern gerät, nur weil die HMI oder ein anderer vernetzter 
Teilnehmer einen ungeeigneten Wert oder im ungünstigen Moment in eine Variable schreibt. 

Auch Rezepturen lasse ich nicht direkt in die Zielvariablen schreiben, sondern immer nur in einen Datensatz-Puffer. 
Bei mir bestimmt das Steuerungsprogramm, ob und wann es die neuen Rezepturwerte übernimmt. 

Tastenbits von der HMI werden immer wie normale Hardware-Taster im Programm verknüpft und zusätzlich zu Beginn des 
ersten OB1-Zyklus und am Ende des OB1 gelöscht, weil nicht sicher ist, daß auch der Tasten-Release-Code von der HMI 
in der Steuerung ankommt.

Ausnahmen von diesen Prinzipien kommen vor, haben dann spezielle Gründe, bestätigen aber die Regel.

Weil ich nicht bei jedem Projekt von vornherein sagen kann, ob die Einhaltung meiner Prinzipien nun für dieses 
spezielle Projekt essentiell ist und was später noch draus wird, halte ich es eben immer so.
Ich sehe diese Prinzipien als einen wesentlichen Baustein dafür, daß die von mir programmierten Anlagen in aller 
Regel jahrelang ohne Steuerungsprobleme und immer berechenbar funktionieren.

Ach ja:
Die HMI und die HMI-Animationen sind viel leichter testbar, wenn sie nicht auf die original-Variablen zugreifen, 
sondern auf Variablen-Kopien im Schnittstellen-DB, besonders im laufenden Betrieb.
Die Variablen-Kopie im Schnittstellen-DB läßt sich ohne Auswirkungen auf das Steuerungsprogramm gut manipulieren.

Gruß
Harald


----------



## rostiger Nagel (23 August 2010)

Harald, ist mal wieder der einzigste der es so erklären kann, das ich es einsehen


----------



## bike (23 August 2010)

Der Erklärung von Harald ist nichts mehr hinzu zufügen.
Es ist nicht hoch genug anzurechnen, dass sich jemand soviel Zeit nimmt, um dies so ausführlich zu erklären.




bike


----------



## Paule (23 August 2010)

Helmut_von_der_Reparatur schrieb:


> Harald, ist mal wieder der einzigste der es so erklären kann, das ich es einsehen


Ja, mir hast es ja wieder mal nicht geglaubt. 
Aber wie bike auch schon sagt, Harald hat es auch echt ausführlich erläutert.


----------



## Perfektionist (23 August 2010)

PN/DP schrieb:


> Warum soll man nicht in der Elektrik bewährte Prinzipien auch für die Programmierung anwenden, auch wenn man nicht
> weiß, warum etwas heute so-und-so gemacht wird?


Erstensmal sollte man jederzeit wissen was man tut. Und Prinzipien aus dem Bereich der Elektrik müssen nicht zwangsläufig auf den Bereich Programmierung übertragbar sein.

Nun steht die These im Raum, man müsse (bzw. solle besser) die Ein- und Ausgaben der HMI über definierte Schnittstellen abwickeln. D.h., die Visu-Daten eines IDB müssen an dessen Bausteinschnittstelle als IN- und OUT-Parameter gelegt werden (da Siemens dafür keinen eigenen Bereich dediziert). Im Schrank nennt sich dieses Vorgehen "Rangieren". In der SPS stehen für diesen Zweck Merker und/oder Global-DB zur Verfügung. Die HMI soll demnach mit diesen Global-Daten kommunizieren und diese Globaldaten werden an die Bausteinschnittstellen verschaltet. Man korrigiere mich, falls diese Darstellung unzutreffend sein sollte.

Vorteil: es ist absolute (was auch immer nun "absolut" heissen soll) - also, es ist absolute Kapselung gegeben.

Das bringt mit sich: man ist nicht festgelegt auf eine bestimmte Visu, die symbolische Verbindung zum IDB fällt weg, die Methode ist das, was sie sein soll: eine BlackBox, die von ihren inneren Abläufen/Strukturen nichts preis gibt (bzw. nichts preis zu geben braucht).

Probleme, die dieses Vorgehen nicht löst: die Datenrichtung ist festgelegt. Eine Eingabe ist eine Eingabe, eine Ausgabe eine Ausgabe. Die Änderung an einem IN/OUT-Parameter kann zu unerwarteten Ergebnissen führen, wenn der Visu-Zugriff nicht am Zykluskontrollpunkt stattfindet. Ich kann es zur Zeit nicht belegen,bin jedoch der Meinung, dass der Zugriff der Visu vollständig asynchron zum SPS-Zyklus abläuft (mal s7-300 und ein WinCE5-Panel mit DP-Kommunikation vorausgesetzt).

Ein weiterer Nachteil ist, dass nicht auf den ersten Blick erkennbar ist, welche Koppelvariable zu welcher Methode gehört. Das Symbol in der (Flex-)Visu lautet dann nicht "Anlage_Instanz".Klappe_Instanz.Umschaltparameter, sondern eben nur "MW200". Oder "A_Kl_UmschP". Oder "KoppelDB".Anlage_Instanz.Klappe_Instanz.Umschaltparameter. Inclusive Datenverlust, wenn ich den Koppel-DB umstrukturiere.

Ich möchte mal Haralds Text nun durchgehen:


> ...
> * manchmal kann das HMI-Projekt nicht geändert werden oder die Änderung ist sehr aufwendig
> ...
> Es kommt öfter vor als gedacht, daß Hersteller einer Anlage wegen schlechtem Projektmanagement nicht mehr wissen, welche HMI-Projektversion aktuell in der Anlage ist oder das aktuelle HMI-Projekt garnicht mehr besitzen. ... In diesen Fällen dürfen also Programmänderungen auf keinen Fall Einflüsse auf die HMI haben.
> Wenn ich dann IDB nicht ändern darf, weil die HMI wahrscheinlich direkt darauf zugreift, dann möchte ich regelmäßig jemanden würgen ...


Mein lieber Harald, da ist ja die Ursache für Deinen Würgereiz ja nicht schlechter Programmierstil. Aber wer schlechtes Projektmanagement pflegt wird wohl auch eher zufällig seine Anlage zum Laufen gebracht haben. Oder mit voller Absicht dieses Zustand herbeigeführt haben, um dann bei einer Pipifax-Änderung reichlich zulangen zu könen.



> * ich möchte bei Programmänderungen nur eine (zusammenhängende) Schnittstelle zur HMI beachten müssen


Meinst Du einen Programmbaustein oder ein Gesamtprogramm (also den gesamten Ablauf in einer SPS)?



> * mein Steuerungsprogramm soll Vorrang vor Eingriffen der HMI haben
> * keine Eingaben/Bedienungen der HMI werden ungeprüft oder unverknüpft im Steurungsprogramm verarbeitet


Dazu ist keine Schnittstelle nötig. bestenfalls hilfreich.



> * die HMI und die HMI-Animationen sind leichter testbar, wenn sie nicht auf die original-Variablen zugreifen


ich behaupte jetzt ganz frech das Gegenteil: ich kann einen FB mitsamt seinem IDB und der für ihn erstellten Visu-Seite völlig losgelöst von irgendwelcher Rangiererei testen.



> Oft ist das HMI-Projekt nicht im Steuerungsprojekt integriert.


Ich bin davon ausgegangen, dass keiner so arbeiten will. Wenn es so ist, dass jemand die Möglichkeiten, die seit Protool 6.0 zuverlässig funktionieren, nicht nutzen will, dann kann ich nachvollziehen, dass jemand nicht nur rangieren will, sondern sogar dazu weitgehend gezwungen ist.



> Immer ist aber zumindest eine Neu-Generierung des HMI-Projektes nötig und es muß (meist im laufenden Betrieb) auf alle betroffenen Panele und Visualisierungen aufgespielt werden. Das können auch mal 10 OP7 sein, wo man mit dem Notebook zu jedem einzelnen OP hinlaufen muß, um das Projekt aufzuspielen. Dazu kommt der Organisationsaufwand, weil die noch nicht upgedateten Panele auf keinen Fall benutzt werden dürfen oder die Panele müssen gar vorab alle ausgeschaltet werden.


Auch das ist kein spezifisches Problem, das durch den direkten Zugriff auf Instanzdaten entsteht. Erstens ist mal nach Änderung einer Instanz grundsätzlich ein CPU-Stopp (oder mindestens mal ein Neuanlauf des betroffenen Prozesses) notwendig, da S7 nicht in der Lage ist, die aktuellen Werte einer Instanz in die geänderte Instanz zu übernehmen. Wäre S7 in der Lage, so wären auch entsprechende Mechanismen denkbar, die die Visu nutzen könnte, sich auf sich verändernde Adresslisten einzustellen. Die zehn OP7 sind wohl heute kein stichhaltiger Grund mehr. Ein einziges TP277, das temporär nicht korrekt arbeitet, jedoch schon.



> Bei mir erhält die HMI fast nie Zugriff auf die original-Steuerungsvariablen, sondern regelmäßig nur auf Kopien oder Zwischenvariablen in den Schnittstellen-DB. So ist es unerheblich, wenn die HMI durch Projektierungsfehler oder Compilierfehler auf diese Variablen schreibt.


Sorry - also, wenn die HMI auf die falsche Variable zugreift, spielt es dann noch eine Rolle, ob rangiert oder nicht? Aber der Prozess flippt trotzdem aus, das falsche Ventil reagiert auf den Tastendruck oder gar auf eine Sollwertänderung. Da ist die Rangiererei nur eine zusätzliche Fehlerquelle. Projektierungsfehler kann ich mit Rangiererei nicht abfangen. Compilerfehler auch nicht.



> Nur in Wonderware Intouch kann man ein entsprechendes Häkchen setzen,


Zugegeben: mein Erfahrungshorizont ist Protool V2 bis V6 und Flexible. Und bei Flex funktionierte die Symbolanbindung zugegebenermaßen auch nicht vom ersten Tag an so, wie es zuletzt in PT funktionierte.



> Eingabewerte von der HMI lasse ich nicht ungeprüft auf Steuerungsvariablen schreiben. Ich möchte nicht, daß meine CPU in Stop geht oder das Steuerungsprogramm ins schleudern gerät, nur weil die HMI oder ein anderer vernetzter Teilnehmer einen ungeeigneten Wert oder im ungünstigen Moment in eine Variable schreibt.


Du schreibst hier zwar viele Wahrheiten - nur hat das mit der Rangiererei auch in diesem Fall hier überhaupt nichts zu tun. Der ungünstige Moment hat was mit Datenkonsistenz zu tun, Wertebereiche kann das Programm prüfen, rangiert oder auch nicht rangiert. Und Wertebereichsgrenzen kann man sogar bereits in der Visu parametrieren. Zumindest bei Flex.



> Auch Rezepturen lasse ich nicht direkt in die Zielvariablen schreiben, sondern immer nur in einen Datensatz-Puffer. Bei mir bestimmt das Steuerungsprogramm, ob und wann es die neuen Rezepturwerte übernimmt.


Ich hatte bis jetzt noch nicht den Fall, dass ich sämtliche Parameter auf einmal in die Steuerung, sprich: "konsistent", laden musste. Das kann notwendig sein. Ist es jedoch (bei mir) in aller Regel nicht. Da meine Maschinen in der Rüstphase stehen, könnte genausogut jemand einen Zettel mit den neuen Parametern nehmen und diesen in die Steuerung (Visu) reinhacken.



> Tastenbits von der HMI werden immer wie normale Hardware-Taster im Programm verknüpft und zusätzlich zu Beginn des ersten OB1-Zyklus und am Ende des OB1 gelöscht, weil nicht sicher ist, daß auch der Tasten-Release-Code von der HMI in der Steuerung ankommt.


Ich verwende hierzu vorzugsweise Merker, da diese die meiste Ähnlichkeit zum PAE besitzen. Da ich mir aber nicht sicher bin, ob die Daten wirklich am Zykluskontrollpunkt von der Visu in die SPS geschrieben werden, verwende ich gerne eine Flankenauswertung. Ganz sicher ist jedoch, dass der Release-Code nie ankommt, wenn man während des Tastendrucks einen Stecker vom Panel abzieht. Aber auch hierfür brauche ich nicht zu rangieren. Wenn ich den Befehlsmerker jedoch an den Eingang eines FB parametriere, so kann ich wenigstens für die Instanz sicher sein, dass sich der Befehl während der Abarbeitung des FB nicht ändert.


----------



## Perfektionist (23 August 2010)

*Fortsetzung*



> Ach ja:
> Die HMI und die HMI-Animationen sind viel leichter testbar, wenn sie nicht auf die original-Variablen zugreifen, sondern auf Variablen-Kopien im Schnittstellen-DB, besonders im laufenden Betrieb. Die Variablen-Kopie im Schnittstellen-DB läßt sich ohne Auswirkungen auf das Steuerungsprogramm gut manipulieren.


Du wiederholst Dich. Das hatten wir weiter oben schonmal. Diesmal klingt es ein wenig so, als ob Du zunächst den FB entwickelst (oder was auch immer bei Dir das Programm ist) und dann danach die Visu machst. Bei mir geht das mehr Hand in Hand. Als Beispiel mag da mal ein Kartonierer dienen: der zerfällt z.B. in einen FB Einleger, der in drei Instanzen aufgerufen wird, in einen FB Produktabruf und -verfolgung, in einen FB Leimung, der auch zwei bis vier Instanzen hat. Jede der drei Instanzen der Einleger hat eine Gruppe von Bildern, die diese visualisieren. Die Produktverfolgung ebenso, und jede Leimdüse auch. Die Programmentwicklung erfolgt also: FB schreiben, Instanzen festlegen, Visubilder machen. Nächsten FB schreiben, IDB machen und Visu dazu. uswusf.

Noch ein weiterer Einleger gefällig?
geht so: Projekt kopieren. IDB auf freie Nummer schieben. Visu mit den/der verschobenen DB-Adressen/-Nr. generieren. Der Instanz einen weiteren (neuen) Namen geben. Jetzt die Visu nochmals neu generieren. Dann die geschobenen Objekte ins Ursprungsprojekt reinkopieren. Rangieren ist da nur lästig. Und wenn es unbedingt sein muss, dann kann man ja doch noch die Visu in den IN/OUT-Bereich legen.



> Ich sehe diese Prinzipien als einen wesentlichen Baustein dafür, daß die von mir programmierten Anlagen in aller Regel jahrelang ohne Steuerungsprobleme und immer berechenbar funktionieren.


Dann geb ich halt meinem Erfolg auch noch recht: gerade erst habe ich eine zehn Jahre alte Steuerung (von mir) umgeändert. Mit so ekelhaften Dingern wie zwei OP7 drin. Ich musste doch tatsächlich zu jedem persönlich hinlaufen und hatte schon einen Riesenschreck bekommen, ob ich denn überhaupt diese RS232-Datenleitung dafür dabei hätte. Protool6 hat erstmal eine neue Firmware übertragen. Bei einem zwei Jahre alten Flex-Projekt hätte mir das Schweissperlen in die Stirn getrieben. Aber die Hochrüstung von PT5 auf PT6 war schon immer problemlos. Ich hab nichtmal zuvor Prosave angeworfen (Rückbau wäre eh nicht möglich gewesen). Damals vor zehn Jahren hab ich auch noch ein wenig anders programmiert. Da gab es tatsächlich noch einen Globaldatenbaustein für die Servicebedienung, die vom OP7 ausgeht. Das war damals gut ausgedacht - in Anlehnung an S5-Zeiten. Ist heute besser ausgedacht. Will sagen: auch ich kann auf Erfolge zurückblicken. Allerdings: wenn ich lese:





> ... auch wenn man nicht weiß, warum etwas heute so-und-so gemacht wird?


dann muss ich sagen: man sollte wissen, warum man gestern etwas so und heute anders macht. Und wer eine Sache schon immer soundso gemacht hat sollte dennoch andere Möglichkeiten gelten lassen. denn:


> Ausnahmen von diesen Prinzipien kommen vor, haben dann spezielle Gründe, bestätigen aber die Regel.


Und


> Weil ich nicht bei jedem Projekt von vornherein sagen kann, ob die Einhaltung meiner Prinzipien nun für dieses spezielle Projekt essentiell ist und was später noch draus wird, halte ich es eben immer so.


So, ich machs halt anders. Jeder kann es für seinen Teil rechtfertigen. Dem TE wird es nicht viel nutzen.


----------



## Paule (24 August 2010)

Da ich der erste war der für die andere Fraktion eintrat, möchte ich mich kurz zur Sache melden 


Perfektionist schrieb:


> Ich war jetzt auf der Suche nach der Fraktion, die den Zugriff der HMI auf Instanzen verachtenswert findet.


 


Perfektionist schrieb:


> Ein weiterer Nachteil ist, dass nicht auf den ersten Blick erkennbar ist, welche Koppelvariable zu welcher Methode gehört.


Warum denn das? Auch in einem Global DB kann man Strukturieren.


Perfektionist schrieb:


> Das Symbol in der (Flex-)Visu lautet dann nicht "Anlage_Instanz".Klappe_Instanz.Umschaltparameter, sondern eben nur "MW200".


Das macht ja hoffentlich niemand, macht ja auch keinen Sinn.


Perfektionist schrieb:


> Oder "A_Kl_UmschP". Oder "KoppelDB".Anlage_Instanz.Klappe_Instanz.Umschaltparameter. Inclusive Datenverlust, wenn ich den Koppel-DB umstrukturiere.


Datenverlust durch Umstrukturierung, in Zeiten der symbolischen Programmierung und der Verwendung von UDT's?
Wohl kaum!


Perfektionist schrieb:


> Erstens ist mal nach Änderung einer Instanz grundsätzlich ein CPU-Stopp (oder mindestens mal ein Neuanlauf des betroffenen Prozesses) notwendig


Falsch, wenn du die Reihenfolge einhältst ist es im laufenden Prozess möglich.
Instanz-DB > FB > aufrufender Baustein.
In dieser Reihenfolge markieren und übertragen.


----------



## Perfektionist (24 August 2010)

Paule schrieb:


> Datenverlust durch Umstrukturierung, in Zeiten der symbolischen Programmierung und der Verwendung von UDT's?
> Wohl kaum!


Ändere Deinen UDT und schau mal, was mit den Aktualdaten in Deinem DB passiert.



Paule schrieb:


> Falsch, wenn du die Reihenfolge einhältst ist es im laufenden Prozess möglich.
> Instanz-DB > FB > aufrufender Baustein.
> In dieser Reihenfolge markieren und übertragen.


Ändere in Deinen Deklarationen einen Datentyp und es hat sich ausgereihenfolgt. Füge einen IN-Parameter hinzu und es hat sich ausgereihenfolgt. Ändre die Deklaration eines FB, den Du im FB als Multiinstanz aufrufst und es hat sich ausgereihenfolgt.

Tu bitte nicht so, als ob etwas, was gelegentlich funktioniert, immer funktionieren würde. Ich geb jetzt auch zu, dass ein Baustein, der einen FB als Multiinstanz verwendet, nicht gekapselt ist. Falls Du das überhaupt bemerkt hättest :?


----------



## rostiger Nagel (24 August 2010)

Perfektionist schrieb:


> Ich geb jetzt auch zu, dass ein Baustein, der einen FB als Multiinstanz verwendet, nicht gekapselt ist. Falls Du das überhaupt bemerkt hättest :?


 
ich glaube das ist das zauberwort, "FB nicht gekapselt".
Der FB wird nur mit Instanzdaten erzeugt um aus den Daten des Lokaldatenbereiches einen DB
zu erstellen. Das ist in diesen fall halt der Instanzdatenbaustein. Im Programm wird er quasi als
Globaldatenbaustein verwendet bzw. Missbraucht.

Ziel kann es z.b. sein das bei verwendung von IEC Timern nicht für jeden Timer ein eigener Daten-
baustein erzeugt werden muß, diese stehen dann als Multiinstanz im Lokalbereich des FB's, das
ganze hilft bei der Strukturrierung des Programmes.


----------



## PN/DP (30 August 2010)

*Dokumentation HMI-Zugriffe*

Hallo Perfektionist,

Danke für Deine ausführlichen Statements zu meinem Beitrag. Ich möchte aber nicht jedes Einzelne beantworten, dann würde diese Antwort auch für meine Begriffe viel zu lang werden.  Ich werde mir aber ein paar Deiner Aussagen herauspicken.

Nach mehrmaligem Durchlesen meine ich, daß Deine und meine Meinung zu dem Thema eigentlich gar nicht soweit auseinander liegen. Auch Du hast viele Wahrheiten geschrieben. Auch Dir sind die meisten möglichen Probleme beim Zusammenspiel Steuerungsprogramm und HMI bekannt und bewußt. Und doch sind Deine Schlußfolgerungen auf die Erkenntnisse andere als meine. Du willst durch besonders cleveres Vorgehen beweisen, daß Du die Probleme innerhalb der Siemens-Welt vollkommen im Griff hast. Ich will die Probleme lieber umgehen bzw. von vornherein vermeiden, und das auf eine Weise, die auch bei Steuerungen und HMI anderer Fabrikate funktioniert. (zugegeben: auch da, wo im speziellen Fall vielleicht gar kein Problem wäre - doch wie ich schon schrieb, ich halte mich immer an die angeführten Prinzipien, egal ob speziell nötig oder nicht. Ich will das nicht jedes Mal neu entscheiden.)



Perfektionist schrieb:


> > Oft ist das HMI-Projekt nicht im Steuerungsprojekt integriert.
> 
> 
> Ich bin davon ausgegangen, dass keiner so arbeiten will. Wenn es so ist, dass jemand die Möglichkeiten, die seit Protool 6.0 zuverlässig funktionieren, nicht nutzen will, dann kann ich nachvollziehen, dass jemand nicht nur rangieren will, sondern sogar dazu weitgehend gezwungen ist.


Man muß mal über den Tellerrand schauen. Die Steuerungswelt besteht nicht nur aus total integrierten Siemens-Komponenten. Da gibt es auch andere HMI-Fabrikate, z.B. Exor/UniOp, Beijer, InTouch ... oder gar komplett selbstprogrammierte PC-Visu ohne jeglichen Quelltext. Die Generiersoftware dieser Fremd-Fabrikate kann garnicht in Step7 integriert werden. Ich kann mich auch nicht erinnern, jemals das richtige Siemens-WinCC komplett in ein Step7-Projekt integriert gesehen zu haben. Die Steuerung muß ebenfalls keine Siemens S7 sein.

Spätestens, wenn man keine Lizenz für die spezielle HMI-Generiersoftware hat oder das aktuelle HMI-Quellprojekt einfach nicht vorhanden ist, dann ist die HMI eine Blackbox und hat sich gefälligst an *dokumentierte* Schnittstellen zum Steuerungsprogramm zu halten.

Meine strikte Abneigung gegen Zugriffe der HMI direkt auf Objekte außerhalb der Schnittstellen-DB (z.B. Instanz-DB, globale Merker, Timer, ...) begründet sich daher, daß diese Zugriffe nur im HMI-Projekt dokumentiert sind und im Steuerungsprojekt nur in Form der Schnittstellen-DB sichtbar sind. Jegliche Zugriffe der HMI außerhalb der Schnittstellen-DB sind im Steuerungsprojekt ohne HMI-Projekt nur dann bekannt, wenn der Programmierer dies in einer extra erstellten Dokumentation erwähnt, die vorhanden und ohne das HMI-Projekt lesbar sein muß.

Alle mir bekannten Reengineering-Methoden können die HMI-Zugriffs-Dokumentation nur unvollständig rekonstruieren und nicht beweisen, daß die HMI nicht auf bestimmte Objekte zugreift. Zusätzlich ist eine solche Rekonstruktion arbeitsaufwändig, ist aber oft notwendig, nur weil der original-Programmierer das Rangieren und das Dokumentieren als lästige und unnötige Zusatz-Arbeit empfand.

Ohne die HMI-Zugriffs-Dokumentation ist jedes Ändern von Variablen-Adressen im Steuerungsprogramm und selbst die Nutzung vermeintlich ungenutzter Variablen ein Glücksspiel. Deshalb meine Meinung, HMI-Zugriffe generell nur über Schnittstellen-DB abzuwickeln.



PN/DP schrieb:


> Warum soll man nicht in der Elektrik bewährte Prinzipien auch für die Programmierung anwenden, auch wenn man nicht
> weiß, warum etwas heute so-und-so gemacht wird?


Ich hoffe, Du fühltest Dich nicht persönlich angegriffen (Du hast es gleich zweimal zitiert). 

Das mit dem nicht-Wissen war nicht speziell auf Dich gemünzt. Ich meinte damit einfach nur Regeln, die man irgendwann gelernt hat und anwendet, ohne den genauen ursächlichen Grund dafür (noch) zu wissen. Solche Regeln gibt es mehr als man denkt.

Wer kann schon genau erklären, wie und warum sich die heute üblichen Taster- und Leuchtenfarben entwickelt haben, hält sich aber daran, weil es so üblich und teilweise sogar vorgeschrieben ist? Warum darf man auf der Autobahn nicht rechts überholen? Warum haben wir überhaupt Rechtsverkehr, wo doch der Linksverkehr viel früher üblich war, weil das die "natürliche" Variante ist?
Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird. Hauptsache, man hält sich daran.

Gruß
Harald


----------



## PN/DP (30 August 2010)

*asynchrone HMI-Zugriffe, Daten-Konsistenz im Zyklus*



Perfektionist schrieb:


> Im Schrank nennt sich dieses Vorgehen "Rangieren". […]
> Probleme, die dieses Vorgehen nicht löst: die Datenrichtung ist festgelegt. Eine Eingabe ist eine Eingabe, eine Ausgabe eine Ausgabe.


Eine HMI-Variable im Schnittstellen-DB (als Kopie einer Prozeß-Variable) kann auch als IN/OUT-Variable von der HMI benutzt werden. Das muß man nur zusätzlich programmieren. Es kann sogar festgestellt werden, wann sich die HMI-Variable durch einen Zugriff von außen ändert und ggf. eine BeiÄnderung-Ereignisroutine aufgerufen werden.




Perfektionist schrieb:


> > Eingabewerte von der HMI lasse ich nicht ungeprüft auf Steuerungsvariablen schreiben. Ich möchte nicht, daß meine CPU in Stop geht oder das Steuerungsprogramm ins schleudern gerät, nur weil die HMI oder ein anderer vernetzter Teilnehmer einen ungeeigneten Wert oder im ungünstigen Moment in eine Variable schreibt.
> 
> 
> Du schreibst hier zwar viele Wahrheiten - nur hat das mit der Rangiererei auch in diesem Fall hier überhaupt nichts zu tun. Der ungünstige Moment hat was mit Datenkonsistenz zu tun, Wertebereiche kann das Programm prüfen, rangiert oder auch nicht rangiert. Und Wertebereichsgrenzen kann man sogar bereits in der Visu parametrieren. Zumindest bei Flex.


Mit “ungünstiger Moment“ meine ich nicht Übertragungs-Konsistenz-Probleme, sondern wenn z.B. der Bediener ein Rezept in die Steuerung überträgt, die Bearbeitung des aktuellen Produkts aber noch nicht beendet ist oder wenn er Drehzahlen von Antrieben ändert, die nur gleichzeitig oder nur im Stillstand geändert werden sollen.
Gut, man kann das auch einfach als Bediener-Fehler abtun. Ich versuche solche Bediener-Fehler abzufangen.

Wertebereiche prüfen:
In Zeiten von Vernetzung, HMI, Visu, MES, ERP, LibNodave, Fernwartung ... verlasse ich mich nicht darauf, daß nur zulässige Werte in der Steuerung ankommen. Selbst dann nicht, wenn ich die Wertebereichsprüfung an allen Datenquellen durchführen könnte. Nur die Prüfung im Steuerungsprogramm vor der Verwendung garantiert mir zulässige Werte. Und nur, wenn die vernetzte Anwendung nicht auf die original-Zielvariable schreibt sondern auf eine Zwischenvariable. Nur dann kann das Steuerungsprogramm entscheiden, ob und wann es den Wert übernimmt.




Perfektionist schrieb:


> > Bei mir erhält die HMI fast nie Zugriff auf die original-Steuerungsvariablen, sondern regelmäßig nur auf Kopien oder Zwischenvariablen in den Schnittstellen-DB. So ist es unerheblich, wenn die HMI durch Projektierungsfehler oder Compilierfehler auf diese Variablen schreibt.
> 
> 
> Sorry - also, wenn die HMI auf die falsche Variable zugreift, spielt es dann noch eine Rolle, ob rangiert oder nicht? Aber der Prozess flippt trotzdem aus, das falsche Ventil reagiert auf den Tastendruck oder gar auf eine Sollwertänderung. Da ist die Rangiererei nur eine zusätzliche Fehlerquelle. Projektierungsfehler kann ich mit Rangiererei nicht abfangen. Compilerfehler auch nicht.


Da muß ich Dir 100% Recht geben. Da war meine Begründung allerdings zu einseitig.

Die Benutzung von Variablen-Kopien hat bei mir noch weitere Gründe, was ich in meinem Beitrag wohl nicht ausführlich genug erwähnt habe:
* Überprüfung/Ablehnung der Eingabewerte durch das Steuerungsprogramm
* Übernahme der Eingabewerte zu einem der Steuerung angenehmen Zeitpunkt (z.B. bei Rezepturen)
* *Daten-Konsistenz im OB1-Zyklus trotz asynchroner HMI-Zugriffe*




Perfektionist schrieb:


> Da ich mir aber nicht sicher bin, ob die Daten wirklich am Zykluskontrollpunkt von der Visu in die SPS geschrieben werden


Ich bin mir auch nicht ganz sicher, meine aber, daß die S7-400 schon immer B&B-Empfangsdaten nicht nur im Zykluskontrollpunkt in CPU-Variablen schreibt. Und ab der nächsten S7-300-Firmware-Generation V3.2 plant Siemens zur Erhöhung der Kommunikationsperformance (B&B) dies auch für S7-300 zu realisieren (projektierbares “Zeitscheibenverfahren“).
Siemens: Neues von der Hannover Messe 2010 (pdf) (Seite 7, Danke an IBFS für den Link)

Wenn man nun für den ganzen OB1-Zyklus gleichbleibende HMI-Variablen braucht und vor allem garantieren will, daß sich eine HMI-Variable zwischen der Prüfung und der Verwendung nicht ändert, dann muß man quasi ein eigenes Prozeßabbild der HMI-Eingabevariablen erstellen. Das geht nur, wenn die HMI nicht direkt auf die Prozeßvariable schreibt, sondern auf eine Zwischenvariable (und die hat sich in einem Schnittstellen-DB zu befinden  ).

Gruß
Harald


----------



## PN/DP (30 August 2010)

*Visu manipuliert testen im laufenden Betrieb*



Perfektionist schrieb:


> > Ach ja:
> > Die HMI und die HMI-Animationen sind viel leichter testbar, wenn sie nicht auf die original-Variablen zugreifen, sondern auf Variablen-Kopien im Schnittstellen-DB, besonders im laufenden Betrieb. Die Variablen-Kopie im Schnittstellen-DB läßt sich ohne Auswirkungen auf das Steuerungsprogramm gut manipulieren.
> 
> 
> Du wiederholst Dich. Das hatten wir weiter oben schonmal. Diesmal klingt es ein wenig so, als ob Du zunächst den FB entwickelst (oder was auch immer bei Dir das Programm ist) und dann danach die Visu machst.


Am Anfang meines Beitrages hatte ich meine Prinzipien stichpunktartig aufgelistet und dann im Verlauf des Beitrags versucht, die einzelnen Punkte ausführlich zu erläutern. Die Erläuterung für den Punkt mit der Testbarkeit ist da wirklich zu kurz geraten. Hier also ein Beispiel:

Ich habe oft mit Siloanlagen und Verteilung von Produkten über verschiedene Wege zu tun. Die Rohrleitungs/Wege-Animation mache ich meistens erst zum Schluß, damit sie perfekt wird. Erst wenn die Aufteilung des Anlagenbildes fertig ist. Fast immer läuft die Anlage dann schon und ich kann dann nicht mehr alle Wege in echt einstellen, um die Animation zu testen. Nicht alle HMI kann man simulieren und außerdem will ich die Animation pixelgenau auf dem echten Panel oder Visu-PC sehen.

Dadurch, daß meine HMI-Variablen nur Kopien der Prozess-Variablen sind, kann ich sehr einfach die Verbindung der HMI-Variable zur Prozess-Variable im Schnittstellen-DB unterbrechen und statt dessen beliebige Werte in die HMI-Variable schreiben, ohne den laufenden Prozess zu beeinflussen und ohne das HMI-Projekt zu ändern.



Perfektionist schrieb:


> ich behaupte jetzt ganz frech das Gegenteil: ich kann einen FB mitsamt seinem IDB und der für ihn erstellten Visu-Seite völlig losgelöst von irgendwelcher Rangiererei testen.


Kannst Du das auch im laufenden Betrieb, wenn Du das, was Du in der Visu testen willst, an der Anlage nicht schalten darfst?

Gruß
Harald


----------



## SPSKILLER (30 August 2010)

Moin,

meiner Meinung nach ist es selbstverständlich, dass die Siemens Visu auf die Siemens FB-Instanzen zugreift. 

Das ist Siemens Philosophie!

WinCC und auch PCS7 sind auf der Visualisierung von Instanzen aufgebaut.
Siemens unterstützt das durch zahlreiche Funktionen innerhalb der S7 und WinCC.

Ich würde mal gerne so nen "von Hand angelegten Koppel-DB" sehen, der 30000 Variablen enthält und noch irgendwie übersichtlich ist...
Das geht doch gar nicht.

Ebenso die Animationen im Visualisierungssystem.
Wer verknüpft 30000 Variablen von Hand??? 
Das ist doch die Konsequenz von so nem Koppel-DB, oder habe ich das falsch verstanden?

Micha


----------



## IBFS (30 August 2010)

SPSKILLER schrieb:


> meiner Meinung nach ist es selbstverständlich, dass die Siemens Visu auf die Siemens FB-Instanzen zugreift.
> 
> Das ist Siemens Philosophie!
> 
> ...


 
Leider wurde bisher zu wenig auf den Unterschied zwischen

händisch angelegten VISU-Kopplungen (STEP7-ProTool-Flex)

und

mittels wizzards angelegten VISU-Kopplungen (PCS7)

eingegangen.



Alles, was per Hand angelegt und modifiziert wird und es keine Synchronisation 
in PCS7 Manier gibt sollten schon ordentlich dokumentiert sein. 
Da gibt es im S7-Projekt in den FC/FBs oder im Quellordner genug Kommentarfelder. 
Nur die muss man auch nutzen.

Sobald man mit WinCC arbeitet (noch nicht ganz PCS7) dann hat man zumindest, 
wenn man AS-OS-Transfer nutzt, die schönen "grünen Wimpel" . 
Daran erkennt man, ob eine VISU-Anbindung einer Variablen vorhanden ist.

Beim "richtigen" PCS7 ist dann alles automatisert, und da ist der 
Zugriff - z.B. auf Instanzen eines Motorbausteins ein normaler Weg.
Da sit man dann den PCS7-Mechanismen "ausgeliefert" 

.

Das schöne an STEP7 ist, es gibt mind. 1000 verschiedene Programmierstile.

zwischen unnntöig aufwändig und genial einfach bis schwachsinnig ist alles dabei.

Dadurch wird es einfach nicht langweilig  

Frank


----------



## mariob (30 August 2010)

Öhm,
ich lese immer noch mit, obwohl nicht ganz einfach für mich, da ich die Siemens eigenen Visualisierungen nicht kenne. Ich hätte gern soetwas, stattdessen habe ich zum Beispiel hier eine Siclimat ZLT stehen, man stößt dort sehr schnell an unüberwindbare Grenzen, wo wahrscheinlich ein Wincc gerade erst mal warmläuft.
Wie schon beschrieben, werde ich ein Proface zur Visualisierung einsetzen, von daher ist es für mich übersichtlicher einen eigenen DB einzusetzen. Auch die Synchronisation im OB1 ist ein sehr wichtiger Aspekt, von daher gehöre ich momentan der Fraktion der GetrenntDBler an.
Für den Fall das ich irgendwas nicht mitgekriegt haben sollte, ob nun IDB mit seinen Besonderheiten oder einem DB, der diese nicht hat, es ist für mich eigentlich nur Speicherplatz. Aus dieser Sicht ist es doch zumindest erst einmal für die Symbolik der Variable im Programm gleichgültig wo diese steht. Ich muß doch nur wissen wie ich die Speicherstelle finde, wenn ich keine Symbolik zur Verfügung habe und dann halt auch noch richtig darauf zugreifen (z.B. mit dem Proface).
Von daher erstmal danke an alle diskutierenden, war bis hierher sehr lehrreich.

Gruß
Mario


----------



## IBFS (30 August 2010)

mariob schrieb:


> ....Aus dieser Sicht ist es doch zumindest erst einmal für die Symbolik der Variable im Programm gleichgültig wo diese steht.
> Ich muß doch nur wissen wie ich die Speicherstelle finde, wenn ich keine Symbolik zur Verfügung habe und
> dann halt auch noch richtig darauf zugreifen (z.B. mit dem Proface).
> ...


 
Das Problem speziell bei IDBs ist ja gerade foglendes:

Wenn es eine Adressenverbindung von der VISU zu einem IDB gibt und
irgend eine Schnachnase den zugehörigen FB des IDBs ändert, dann
verschieben sich innerhalb des IDB alle Adressen. Das wird u.U. bei
WinCC und PCS7 abgefangen aber nicht bei "handgemachten" VISU-
Anbindungen. Das ist der oben ofter zitierte Totalschaden. 

Frank


----------



## bike (30 August 2010)

IBFS schrieb:


> Das Problem speziell bei IDBs ist ja gerade foglendes:
> 
> Wenn es eine Adressenverbindung von der VISU zu einem IDB gibt und
> irgend eine Schnachnase den zugehörigen FB des IDBs ändert, dann
> ...



Das ist die eine Seite, doch die zweite ist, dass ich in der PLC prüfen will und muss, dass kein Mist von der VISU kommt.
Es werden die Werte von der VISU gelesen und geprüft, dann ggF skaliert und dann im Programm weiter verarbeitet. 
Dann kann auch eine externe Datenbank oder Überwachungssystem oder das PLC Programm mit den Daten etwas sinnvolles anfangen.
Das ist etwas mehr Aufwand, aber der rechnet sich.


bike


----------



## Perfektionist (30 August 2010)

PN/DP schrieb:


> > ... auch wenn man nicht
> > weiß, warum etwas heute so-und-so gemacht wird?
> 
> 
> ...


Da fühle ich mich nicht persönlich angegriffen, das empfinde ich als Angriff auf die gesamte Menschheit. Allerdings muss ich eingestehen, dass etwa 99% aller Menschen besser sich nach Deiner Leitlinie "tu es so, wie man es schon immer gemacht hat" richten sollten. Vielleicht sind es sogar 99,99%. Manchmal kommt es mir so vor.

Wie ich schonmal in diesem Forum erwähnte (das ist aber - glaube ich - in den Giftschrank gewandert), wie ich also schonmal erwähnte, gehöre ich zu den Menschen, die ziemlich alles kritisch unter die Lupe nehmen und hinterfragen. Und eben davon überzeugt sind, dass es nicht nur einen Weg nach Rom gibt. Sondern derer bewährte, aber auch neuere existieren. Oder sich sogar noch neuere finden lassen. Da tue ich mir naturgemäß mit





> Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird. Hauptsache, man hält sich daran.


sehr, sehr schwer.

Wenn jemand also sagt: auf der Autobahn überholt man nicht rechts, so ist das Eine Regel mit Ausnahmen. Geltungsbereich: z.B. Deutschland. Nicht generell in den USA gültig (wo? keine Ahnung - die Rechtsüberholbefürworter behaupten, dass es Länder gibt, in denen auf der Autobahn rechts überholt werden darf). Ausnahme in Deutschland? Ja, gibt es: auf Autobahnen in Deutschland darf auf einer separaten Fahrspur (abgetrennt durch die dicken Fahrbahnmarkierungen) rechts überholt werden. Wobei: ob das eine Ausnahme ist, empfindet jeder anders. Wer diese Ausnahmeregel kennt, wird es nicht als Ausnahme empfinden.

Auch den Rechtsverkehr kann oder sollte man sogar hinterfragen. Falls mal jemand auf die Idee kommt, die Verkehrsregeln weltweit zu harmonisieren. Da ist es vielleicht ganz hilfreich zu wissen, dass der Einbauort des Lenkrades (mein Großvater legte viel Wert darauf, dass das Ding nicht als Steuer bezeichnet wurde) mit einer sachlichen Begründung überhaupt nichts zu tun hat. Sondern damit, wo die Herrschaften sitzen. Wer also mit der Heuristik "der, der den Lenker links eingebaut hat, wird sich dabei schon was gedacht haben" zu Werke geht, begeht in meinen Augen ein Verbrechen.

Zur Sache: mein Horizont ist ganz klar auf Protool, Flexible und 300er beschränkt. In dieser kleinen, feinen Welt erlaube ich mir (kann ich mir erlauben?) ohne zu rangieren direkt mit der HMI in Instanzen zuzugreifen. Ausnahmen bestätigen auch hier die Regel: selbstverständlich muss auch ich mir Gedanken über Datenkonsistenz machen, also ggf. mal eine Visu-Variable zwischenparken, bevor ich sie im Programm weiterverwende. Allerdings muss die dann (bei mir) nicht extra in einem Global-DB stehen. Eine Welt, so wie Du sie schilderst, wo nichts festgelegt ist, nichtmal, dass mit S7 gearbeitet wird, verlangt wie selbstverständlich nach bestens dokumentierten Schnittstellen, nicht nur zwischen HMI und Steuerung.


----------



## Perfektionist (30 August 2010)

*Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird.*



> Man muß also nicht immer wissen, warum etwas so-und-so gemacht wird. Hauptsache, man hält sich daran.


Ach, da muss ich den hier noch dazufügen, da er so herrlich in mein Weltbild passt:
http://de.wikipedia.org/wiki/Semmelweis


> Der „Semmelweis-Reflex“, demzufolge Innovationen in der Wissenschaft eher eine Bestrafung als eine entsprechende Honorierung zur Folge haben, *weil etablierte Paradigmen und Verhaltensmuster entgegenstehen*, wurde von Robert Anton Wilson geprägt und nach Semmelweis benannt.


----------



## Perfektionist (30 August 2010)

Hallo Harald,

heute mittag hab ich mich zunächst damit auseinandergesetzt, wie ich dazu stehe, wenn man etwas soundso tun solle, weil man es schon immer soundso gemacht habe. Wegen der angeführten Beispiele aus der alltäglichen Welt der Autofahrer fiel mir eine spontane Antwort darauf leicht. Ich ergänze nun noch ein paar meiner Gedanken zu den fachbezogenen Dingen - natürlich insbesondere dort, wo sich bei mir Widerspruchsbedürfnis entwickelt.


PN/DP schrieb:


> Spätestens, wenn man keine Lizenz für die spezielle HMI-Generiersoftware hat oder das aktuelle HMI-Quellprojekt einfach nicht vorhanden ist, dann ist die HMI eine Blackbox und hat sich gefälligst an *dokumentierte* Schnittstellen zum Steuerungsprogramm zu halten.


Hmmm, kann sein, dass ich mich wiederhole, aber das ist für mich der Supergau. Bei meinen Maschinen ist der Vollzugriff auf alle Komponenten Grundvorraussetzung, Änderungen vornehmen zu können. Änderungen bedeuten i.d.R. bei mir, der Kunde will nicht nur eine geänderte, sondern eine zusätzliche Funktionalität. Das bedeutet oft einen zusätzlichen FB oder mindestens mal zusätzliche Parameter und damit verbunden zusätzliche Visualisierungsseiten oder -einträge. Ich habe bisweilen auch Änderungen, die mehr in den Bereich Fehlerbereinigung fallen, die ohne Visu-Änderung auskommen. Aber weitergehende Änderungen, da besteht doch meist (?) der Wunsch, auch in der Visu was dazuzutun? oder eben anzupassen?



PN/DP schrieb:


> Eine HMI-Variable im Schnittstellen-DB (als Kopie einer Prozeß-Variable) kann auch als IN/OUT-Variable von der HMI benutzt werden. Das muß man nur zusätzlich programmieren.


Bei Flexible ist ein Ein-/Ausgabefeld der Standard-Fall. Es ist vielleicht nicht der schönste Programmierstil, aber bei einem Stückzähler, bei dem es nicht auf jedes Teil ankommt, kann ja durchaus ein Zugriff sowohl von der CPU wie auch der HMI auf die gleiche Variable erfolgen. Trennt man nun diese einzige Variable in den Teil, auf den das HMI zugreifen soll und den Teil, auf den das Programm zugreifen soll, so ist in der Steuerung eine Abgleichsroutine notwendig. Ändert sich also der Inhalt eine der beiden Variablen, so muss diese Änderung auf die jeweils andere Variable rüberkopiert werden. Der Vorzug dieser Vorgehensweise liegt dabei auf der Hand: es kann klar ein Vorrang festgelegt werden, sollten sich beide Werte gleichzeitig ändern. Nachteil: es ist nicht unerheblich Code dafür notwendig.



PN/DP schrieb:


> Nur die Prüfung im Steuerungsprogramm vor der Verwendung garantiert mir zulässige Werte. Und nur, wenn die vernetzte Anwendung nicht auf die original-Zielvariable schreibt sondern auf eine Zwischenvariable. Nur dann kann das Steuerungsprogramm entscheiden, ob und wann es den Wert übernimmt.


Das schrieb auch ich heute mittag, dass ich sowas auch mache. Ich schrieb auch, dass ich diese Puffervariable nicht in einen Extra-DB lege. Ich gehe hier nochmals darauf ein, da ich mit Dir übereinstimme, dass zwischen der Prüfung und der Verwendung des Wertes einer Variablen ja zwischendurch noch ein HMI-Zugriff liegen könnte. Um also den zwischenzeitlichen Zugriff seitens der HMI zu verhindern, muss man also zunächst den Wert kopieren und dann anhand der Kopie überprüfen. Der Satz "Nur dann kann das Steuerungsprogramm entscheiden, ob und wann es den Wert übernimmt" bekommt dann allerdings in meinen Augen eine etwas abweichende Bedeutung. Die Prüfroutine muss zunächst den Wert holen und mindestens mal in eine Zwischenschublade schieben. Sollte also die Prüfroutine mehr seitens der HMI-Ein/Ausgabe angesiedelt sein, so ist dort eine besondere Sorgfalt durch eine weitere Puffervariable erforderlich. Ist die Prüfroutine mehr der Verarbeitungsseite zugeordnet, so kann direkt an der Kopie manipuliert werden oder ggf. die Verarbeitung ausgesetzt werden. Naja, wenn ich bei Dir weiterlese:


PN/DP schrieb:


> Wenn man nun für den ganzen OB1-Zyklus gleichbleibende HMI-Variablen braucht und vor allem garantieren will, daß sich eine HMI-Variable zwischen der Prüfung und der Verwendung nicht ändert, dann muß man quasi ein eigenes Prozeßabbild der HMI-Eingabevariablen erstellen. Das geht nur, wenn die HMI nicht direkt auf die Prozeßvariable schreibt, sondern auf eine Zwischenvariable (und die hat sich in einem Schnittstellen-DB zu befinden  ).


dann sind wir uns doch eigentlich - vom Schnittstellen-DB mal abgesehen - doch eigentlich einig.

Dann war da noch die Sache mit dem Test der Visualisierung:


PN/DP schrieb:


> Dadurch, daß meine HMI-Variablen nur Kopien der Prozess-Variablen sind, kann ich sehr einfach die Verbindung der HMI-Variable zur Prozess-Variable im Schnittstellen-DB unterbrechen und statt dessen beliebige Werte in die HMI-Variable schreiben, ohne den laufenden Prozess zu beeinflussen und ohne das HMI-Projekt zu ändern.
> 
> 
> 
> ...


An dieser Stelle haben wir, wie ich nun feststelle, vollständig aneinander vorbeigeredet. Ich bin von S7 und Flexible ausgegangen, Du offenbar von allem, was es auf dieser Welt so gibt. Und das muss ja nicht Flexible sein. Bei Flex sieht es so aus, dass da eigentlich nichtmal S7 installiert sein muss und ich auch keine lebende Steuerung brauch, um eine Visu testen zu können. Da kann man in der Manier einer Variablentabelle direkt in einem Testbetrieb am Erstellsystem die Variablen der Steuerung simulieren. Es ist also so, dass ich gar nicht das dringende Bedürfnis habe, im laufenden Betrieb testen zu können, da es alternative Möglichkeiten (bei Flex!) gibt.


----------



## PN/DP (10 September 2010)

Zwei weitere Argumente FÜR den Schnittstellen-DB möchte ich noch erwähnen, weil sie hier in diesem Thread noch nicht genannt wurden:
* Erhöhung der Kommunikations-Performance zwischen HMI und Steuerung
* Möglichkeit zur Einsparung von PowerTags

Wenn die HMI-Variablen im SSDB günstig angelegt werden (die Variablen hintereinander, die im selben Bild benötigt werden), dann kann der HMI-Kommunikationstreiber die Zugriffe zur Steuerung optimieren und größere Variablenblöcke lesen, als sich die Einzel-Variablen aus den IDB zu holen. Das ist z.B. der Grund, warum bei ProTool und WCCflex die Bitmeldungen ein Array of Word sind. Das Lesen von gleich mehreren Variablen kann man auch forcieren, wenn die HMI Bit-Zusammenfassung in (D)Words, Variablen-Arrays und/oder Rohvariablen unterstützt. Netter Nebeneffekt dabei ist die Verringerung der Anzahl an PowerTags.

Harald


----------



## Perfektionist (10 September 2010)

ich könnte aber auch die HMI-Variablen innerhalb des IDB als Array zusammenfassen. Dann hab ich ebenfalls Kommunikationslast eingespart und auch weniger Powertags. Es gibt mehrere Möglichkeiten, den gleichen Effekt zu erreichen


----------



## geza (14 September 2010)

Perfektionist schrieb:


> Ändere Deinen UDT und schau mal, was mit den Aktualdaten in Deinem DB passiert.
> 
> Ändere in Deinen Deklarationen einen Datentyp und es hat sich ausgereihenfolgt. Füge einen IN-Parameter hinzu und es hat sich ausgereihenfolgt. Ändre die Deklaration eines FB, den Du im FB als Multiinstanz aufrufst und es hat sich ausgereihenfolgt.
> 
> Tu bitte nicht so, als ob etwas, was gelegentlich funktioniert, immer funktionieren würde. Ich geb jetzt auch zu, dass ein Baustein, der einen FB als Multiinstanz verwendet, nicht gekapselt ist. Falls Du das überhaupt bemerkt hättest :?


Es ist natürlich völliger Quatsch! Wenn man weiß was man tut, bleibt ein SPS niemals stehen! Egal ob UDT oder Multiinstanz. Man darf alles nach Lust und Laune ändern. Es müssen lediglich alle Zugriffe *"Rückwerts" aktualisiert* werden und *alle betroffenen Bausteine gleichzeitig in den Ladespeicher verschoben werden.* Eventuell sollten die Aktualwerte der IDB´s für einen definierten Weiterlauf, vor dem Aufspielen, eingestellt werden. Ist aber so gut wie nie erforderlich. Ich arbeite seit zehn Jahren an Anlagen die nicht stehenbleiben dürfen und hatte bislang einen Chrash. Habe eine Aktualisierung übersehen.


----------



## Perfektionist (14 September 2010)

geza schrieb:


> *alle betroffenen Bausteine gleichzeitig in den Ladespeicher *


bei welchen S7-Steuerungen geht das?


----------



## geza (14 September 2010)

Perfektionist schrieb:


> bei welchen S7-Steuerungen geht das?


315-2DP, 316-2DP und 412-2DP mit sicherheit. Bei den anderen kann ich es  nicht mit sicherheit behaupten, weil wir nur die drei Typen einsetzen.  Ich vermute aber, dass es mit anderen Steuerungen genauso funktionieren  sollte. 

Notfalls das Programm auf konsistenz prüfen, neu übersetzen und komplett neu aufspielen.


----------



## Flinn (14 September 2010)

geza schrieb:


> 315-2DP, 316-2DP und 412-2DP mit sicherheit. Bei den anderen kann ich es nicht mit sicherheit behaupten, weil wir nur die drei Typen einsetzen. Ich vermute aber, dass es mit anderen Steuerungen genauso funktionieren sollte.
> 
> *Notfalls das Programm auf konsistenz prüfen, neu übersetzen und komplett neu aufspielen.*


 
Und das alles ohne Verlust der Aktualwerte?? Im laufenden Anlagenbetrieb?
Worin speicherst Du Sollwerte, Grenzwerte, Parameter, Anwahlen, Speicher etc.?
Aus Interesse, welche Art von Anlagen bearbeitest du?

Gruß, Flinn

PS: Ich ziehe die Global-DB-Variante für o.g. Daten und für die HMI-Schnittstelle vor.


----------



## Paule (14 September 2010)

Flinn schrieb:


> PS: Ich ziehe die Global-DB-Variante für o.g. Daten und für die HMI-Schnittstelle vor.


Hi Flinn,
Willkommen auf unsere Seite. 
http://sps-forum.de/showpost.php?p=279418&postcount=6

Vielleicht sollte ich eine Umfrage starten, so was habe ich hier noch gar nicht gemacht.


----------



## Perfektionist (14 September 2010)

geza schrieb:


> 315-2DP, 316-2DP und 412-2DP mit sicherheit.


Die 400er entzieht sich meiner Erfahrung. Bei den benannten 300ern bekomme ich vom Simatic-Manager den freundlichen Hinweis, die Reihenfolge bei der Übertragung zu prüfen. Und das aus gutem Grund, wie mir schon so mancher SPS-Stopp seit Jahrzehnten zeigt (nicht dass ich den Stopp toll find - aber manchmal ist es einfach der faule Weg, die CPU in Stopp zu zwingen statt ordnungsgemäß anzuhalten).

Das andere Problem sind z.B. Schrittketten, die einen bestimmten Zustand zum Zeitpunkt der Übertragung eingenommen haben und deren Zustand ich zum Zeitpunkt der Übertragung meist nicht abpasssen kann. Da kann ich lange Aktualdaten vorbereiten - wenn ich das stoßfrei hinbekommen will, da hab ich dann meist schon eine Aufgabe, die allermeistens (bei meinen Maschinen) nicht lösbar ist. Allerdings kann ich erfreulicherweise meist den Betrieb fürs Programmupdate unterbrechen.


----------



## Perfektionist (14 September 2010)

Paule schrieb:


> Vielleicht sollte ich eine Umfrage starten, ...


für mich bitte folgende Antwortmöglichkeit vorsehen: ich verwende / meine Kunden fordern ausschließlich Protool/Flexible und durch die integrierte Arbeitsweise mit Symbolanbindung kann ich auf Koppel-DB verzichten.


----------



## geza (15 September 2010)

Flinn schrieb:


> PS: Ich ziehe die Global-DB-Variante für o.g. Daten und für die HMI-Schnittstelle vor.



Ich auch, und das ausschließlich. Ablaufrelevante Daten und Parameter, HMI-Kommunikation gehören in Globale DB´s. 

*Es ging aber dabei um die Frage, ob der SPS in STOP geht wenn man umfangreiche Änderungen vornimmt.* Wenn die Konsistez korrekt ist, definitiv nein.



> Aus Interesse, welche Art von Anlagen bearbeitest du?


Produktionslinie für Flüssigkristallanzeigen (LCD).



> Und das alles ohne Verlust der Aktualwerte?? Im laufenden Anlagenbetrieb?


Weitgehend. Je nach dem was geändert wurde. Wird das gesamte Programm neu geladen, gescheit es meist in einem Zeitfenster von ca. eine Minute zwischen zwei Chargen, also wenn die Anlage eine definierte Ruhestellung hat. Meist sind es aber lediglich geänderte FB´s und IDB´s oder Multiinstanzen. Eventuel kritische Aktualparameter in den IDB´s werden per Hand eingestellt.

Mann sollte aber jederzeit genau wissen, was man tut, sonst kann es böse Überraschungen geben.:sw19: Hatte ich auch einige. Jedoch nur einen wirklichen absturz der SPS und es war mein Fehler!


----------



## geza (15 September 2010)

Perfektionist schrieb:


> Das andere Problem sind z.B. Schrittketten, die einen bestimmten Zustand zum Zeitpunkt der Übertragung eingenommen haben und deren Zustand ich zum Zeitpunkt der Übertragung meist nicht abpasssen kann. Da kann ich lange Aktualdaten vorbereiten - wenn ich das stoßfrei hinbekommen will, da hab ich dann meist schon eine Aufgabe, die allermeistens (bei meinen Maschinen) nicht lösbar ist. Allerdings kann ich erfreulicherweise meist den Betrieb fürs Programmupdate unterbrechen.



Da stimme ich natürlich zu. 


> Bei den benannten 300ern bekomme ich vom Simatic-Manager den  freundlichen Hinweis, die Reihenfolge bei der Übertragung zu prüfen.



Siemens verwirrt die Leute, meiner Meinung nach, mit Absicht. *Nichts mit "Reienfolge" sondern Gleichzeitig sonst knallt es.*:sm18: Zb. OB1 ruft FB1 mit DB1 auf. FB1 enthält FB2 und FB3 als Multiinstanz. Schnittstelle des FB3 wird geändert. Aktualisierungen rückwerts durführen und OB1, DB1, FB1 und FB3 Gleichzeitig laden.


----------



## PN/DP (15 September 2010)

Hallo geza,

da hast Du ja zum Glück gerade noch die Kurve gekriegt. Deine mit starken Worten formulierte 
Antwort #65 passte eigentlich überhaupt nicht zu den zitierten Aussagen vom Perfektionist.
Kein CPU-Stop und Aktualdaten beibehalten sind zwei völlig verschiedene Themen.

Einen geänderten FB mit Regler-Funktion samt Instanz-DB oder geänderte Multiinstanzen bekommt 
man nicht auf einfache Weise stoßfrei in die CPU geladen. Ohne CPU-Stop ist dagegen kein Problem
(wenn man genug Zeit für die Vorbereitung und Durchführung hat).

Bausteine gleichzeitig markieren und einspielen und denken, die werden in der CPU gleichzeitig 
aktiviert - über diese Brücke gehe ich nicht.

Vor etwa 10 Jahren habe ich mal mit einer CPU 315-2DP ausgiebige Tests mit dem Einspielen von 
mehreren Bausteinen auf einmal gemacht und sicher festgestellt, daß die gemeinsam eingespielten 
Bausteine NICHT im selben OB1-Zyklus aktiviert wurden. (Der Ladespeicher(RAM) war dabei mehr als 
doppelt so groß wie nötig und vorher komprimiert.)
Weil ich ein vorsichtiger Mensch bin und ständig nur an laufenden Anlagen Programmänderungen 
vornehmen muß, habe ich solche Glücksspiele nie wieder versucht und überlege mir vorher ein 
gestaffeltes Vorgehen. Dabei hilft mir ungemein, daß ich Parameter und Einstelldaten in Global-DB 
und nicht in Instanz-DB ablege.

Harald


----------



## Perfektionist (15 September 2010)

PN/DP schrieb:


> Bausteine gleichzeitig markieren und einspielen und denken, die werden in der CPU gleichzeitig aktiviert - über diese Brücke gehe ich nicht.
> 
> Vor etwa 10 Jahren habe ich mal mit einer CPU 315-2DP ausgiebige Tests mit dem Einspielen von mehreren Bausteinen auf einmal gemacht und sicher festgestellt, daß die gemeinsam eingespielten Bausteine NICHT im selben OB1-Zyklus aktiviert wurden.


Das Gerücht, man könne mehrere Bausteine gleichzeitig übertragen, hält sich hartnäckig. So hartnäckig, dass ich bisweilen an mir selbst zweifle. Danke, Harald, dass Du das hier nochmal deutlich für die 300er klar gestellt hast. Bei der 400er bin ich mir aber nach wie vor nicht sicher - leider hab ich keine 318er mehr (und auch kein PLC-SIM), um das mal zu überprüfen.


----------



## geza (15 September 2010)

Hallo Harald, 


PN/DP schrieb:


> Vor etwa 10 Jahren habe ich mal mit einer CPU 315-2DP ausgiebige Tests mit dem Einspielen von
> mehreren Bausteinen auf einmal gemacht und sicher festgestellt, daß die gemeinsam eingespielten
> Bausteine NICHT im selben OB1-Zyklus aktiviert wurden. (Der Ladespeicher(RAM) war dabei mehr als
> doppelt so groß wie nötig und vorher komprimiert.)


Kann ich leider nicht nachvollziehen. Eigentlich sollten alle geladenen Bausteine konsistent nach Zyklusende vom Ladespeicher zum Arbeitsspeicher übertragen werden. Der nächste Zyklus läuft dann mit den neuen Bausteinen. Soweit die Theorie. In der Praxis konnte ich bislang nichts gegenteiliges feststellen. 


> Bausteine gleichzeitig markieren und einspielen und denken, die werden in der CPU gleichzeitig
> aktiviert - über diese Brücke gehe ich nicht.


Wenn es nicht anderst geht? Ein mulmiges Gefühl bleibt aber immmer.


> Weil ich ein vorsichtiger Mensch bin und ständig nur an laufenden Anlagen Programmänderungen
> vornehmen muß, habe ich solche Glücksspiele nie wieder versucht und überlege mir vorher ein
> gestaffeltes Vorgehen. Dabei hilft mir ungemein, daß ich Parameter und Einstelldaten in Global-DB
> und nicht in Instanz-DB ablege.


Entspricht vollkommen meiner Meinung.

Gruß: Geza


----------



## PN/DP (15 September 2010)

geza schrieb:


> Eigentlich sollten alle geladenen Bausteine konsistent nach Zyklusende vom Ladespeicher zum Arbeitsspeicher übertragen werden. Der nächste Zyklus läuft dann mit den neuen Bausteinen. Soweit die Theorie.


Ich bin auch der Meinung, daß das gleichzeitige Laden mehrerer Bausteine so ablaufen müßte. Doch damals habe ich festgestellt, daß das eben nicht immer so ist.
Ich könnte aber diesen Test nochmals mit neueren CPU mit neuerer Firmware wiederholen. Doch selbst wenn die Tests 100% wie die Theorie funktionieren würden, hätte ich aufgrund meiner damaligen Versuche kein Vertrauen in dieses Verhalten, weil ich nicht weiß, unter welchen Bedingungen das doch schiefgehen kann.

Harald


----------



## Perfektionist (15 September 2010)

Perfektionist schrieb:


> Das Gerücht, man könne mehrere Bausteine gleichzeitig übertragen, hält sich hartnäckig. So hartnäckig, dass ich bisweilen an mir selbst zweifle. ...





geza schrieb:


> Kann ich leider nicht nachvollziehen. Eigentlich sollten alle geladenen Bausteine konsistent nach Zyklusende vom Ladespeicher zum Arbeitsspeicher übertragen werden. Der nächste Zyklus läuft dann mit den neuen Bausteinen. Soweit die Theorie. In der Praxis konnte ich bislang nichts gegenteiliges feststellen.


Es hat mich nicht in Ruhe gelassen. Und ich war mir 100% sicher, genau die Erfahrung von Harald ebenfalls vor zehn Jahren gemacht zu haben.

Interessanter Weise habe ich im Schrank zweierlei 315-2DP rumliegen. Einmal eine 315-2AG10-0AB0 V2.6.9, einmal eine 315-2AF03-0AB0 V1.1.0.

Markiere ich DB1, FB1 und OB1, so werden bei beiden CPUs die Bausteine in dieser Reihenfolge übertragen. Bei dem Überschreiben-Dialog kann ich entweder alle oder einzeln Ja antworten. Erst wenn alles übertragen ist, wird auch alles erst scharfgeschaltet (gilt jetzt für diese drei Bausteine). Wenn ich für den DB1 ja antworte, dann aber für die Übertragung von FB1 abbrechen befehle, so wird tatsächlich auch der bereits übertragenen DB1 verworfen. Nur wenn ich aus dem Programm "Test2", wo ja der kürzere DB drin ist, den DB einzeln auf das in der CPU vorhandene Programm "Test1" übertrage, dann geht es so, wie es sich gehört, schief, und die CPU steht wegen Bereichslängenfehler.

Also: auch die uralte 2DP kann das, was ich persönlich für unmöglich hielt. Jetzt gehe ich mal auf Jagd nach alten 312 und 313ern. Leider hab ich keine in Griffweite, um das Verhalten mal dort zu testen.


----------



## Thomas_v2.1 (15 September 2010)

Bezüglich des Einbindens von mehreren Bausteinen habe ich hier schonmal was geschrieben:

http://www.sps-forum.de/showthread.php?t=28174

Und Perfektionist war damals schon der merkwürdigen Ansicht es könne nur ein Baustein gleichzeitig eingebunden werden.


----------



## Perfektionist (15 September 2010)

Thomas_v2.1 schrieb:


> Bezüglich des Einbindens von mehreren Bausteinen habe ich hier schonmal was geschrieben:
> 
> http://www.sps-forum.de/showthread.php?t=28174
> 
> Und Perfektionist war damals schon der merkwürdigen Ansicht es könne nur ein Baustein gleichzeitig eingebunden werden.


Danke für den Link zum Thread, den hatte ich auch noch so im Hinterkopf. Nur nicht mehr gefunden.

Aber es beruhigt mich, dass ich nicht der Einzige mit dieser "merkwürdigen" Ansicht bin. Es muss für diese Ansicht ein Grund existieren.


----------



## Thomas_v2.1 (15 September 2010)

Perfektionist schrieb:


> Aber es beruhigt mich, dass ich nicht der Einzige mit dieser "merkwürdigen" Ansicht bin. Es muss für diese Ansicht ein Grund existieren.



Vielleicht liegt es an einer falschen Lademethode?

Ansonsten haben sich meine Vermutungen aus dem anderen Thread über die PDU-Größe in einigen Tests bestätigt.
Wenn keine andere Begrenzung vorliegt, liegt die maximale Anzahl der gleichzeitig einbindbaren Bausteine im S7-Protokoll begründet.

Als Formel gilt:

Anzahl = (PDU_Size - 10 - 12 - 6) / 8

Der Wert wird auf die ganze Zahl abgerundet.
Bei einer PDU von 240 Byte (die meisten S7-300) wären das 26 Bausteine, bei einer PDU von 480 Byte (S7-400, WinAC) sind das 56 Bausteine.

Wenn die CPU die Anzahl nicht in anderer Weise begrenzen kann, ist dies imho der Maximalwert.


----------



## Perfektionist (15 September 2010)

Thomas_v2.1 schrieb:


> Vielleicht liegt es an einer falschen Lademethode?


Damals: http://www.sps-forum.de/showpost.php?p=201455&postcount=27 lag es an "Überprüfen Sie die für die korrekte Funktion erforderliche Reihenfolge der Bausteine". Heute hat mir S7 diese Meldung nicht gezeigt. Damals war es V5.4, heute V5.5. Damals mutmaßte ich, dass eventuell ein Unterschied zwischen Prof und unProf existieren könnte. Nun müsste ich annehmen, dass sich eventuell mit V5.5 was geändert hat. Ich habe mir vorgemerkt, wenn ich Zeit habe, das mal nachzustellen zu versuchen (der Harald und ich sind doch nicht blöd ).


----------



## Perfektionist (15 September 2010)

mir fällt grad was anderes siedend heiss ein: die Standardparametrierung einer CPU ist doch Testbetrieb. Oder? Dann habe ich heute in Testbetrieb getestet. Normalerweise arbeite ich aber in der Betriebsart Prozessbetrieb. Ob das des Rätsels Lösung ist? heut abend kann ich es leider nicht mehr klären ...


----------



## Perfektionist (16 September 2010)

... das wars: stell Die CPU auf Prozessbetrieb, und es hat sich ausgereihenfolgt. Sprich: es kommt die "Prüfen Sie die Reihenfolge"-Meldung und die Bausteine werden einzeln in der CPU aktiviert, nicht mehr am Stück/im gemeinsamen Block.


----------



## geza (16 September 2010)

Perfektionist schrieb:


> ... das wars: stell Die CPU auf Prozessbetrieb, und es hat sich ausgereihenfolgt. Sprich: es kommt die "Prüfen Sie die Reihenfolge"-Meldung und die Bausteine werden einzeln in der CPU aktiviert, nicht mehr am Stück/im gemeinsamen Block.


Hallo Perfektionist,
erst mal vielen Dank für die Info. Habe etwas wichtiges dazu gelernt. Ich habe es in HW Konfig nachgeprüft, meine 300-er CPU´s sind alle in "Testbetrieb", was ich aber nicht schlecht finde. Bei der 400-er gibt es dagegen keine Auswahlmöglichkeit. In der Siemens Hilfe findet man Folgendes:


> Betrieb
> Nicht relevant für S7-400, CPU 318-2, alle S7-300 CPUs mit einem Firmwarestand ab V3.0 und für den Sicherheitsbetrieb einer F-CPU mit Sicherheitsprogramm.
> Im Prozeßbetrieb werden die Testfunktionen wie Programmstatus oder Variable beobachten/steuern so eingeschränkt, daß die eingestellte zulässige Zykluszeiterhöhung nicht überschritten wird. Das Testen mit Haltepunkten und schrittweise Programmausführung können nicht ausgeführt werden.
> Im Testbetrieb sind alle Testfunktionen über PG/PC ohne Einschränkung nutzbar, die auch größere Verlängerungen der Zykluszeit bewirken können.
> ...


 
Also, wenn ich das richtig verstehe, die neuen 300-er sollten es auch nicht mehr haben.


----------



## Shiva (30 September 2010)

mal noch ein kleiner Nachsatz von einem einfachen Instandhalter:

Für mich in der Praxis ist es ein himmelweiter Unterschied, ob ein Programm schön strukturiert aufgebaut ist, oder ob eine "wilde Sau" ein - funktionell genauso gutes - Programm zusammengefeuert hat.
Die saubere Programmierung kostet in der Regel bei Kauf mehr - spart letztendlich aber jede Menge Zeit und Nerven - nämlich meine (stellvertretend für alle Instandhalter ) 

Probleme treten mit der "Wildsau"-Methode - man verzeihe mir den Ausdruck - zum Beispiel dann auf, wenn hochintelligente Verwaltungsangestellte Ideen generieren, die kein logisch denkender Mensch nachvollziehen kann und will.

Als Beispiel sei hier nur die Einsparung der Inbetriebnahme einer Anlage zugunsten Eigeninbetriebnahme, ohne Kenntniss einer einzigen Programmzeile, der "Inbetriebnehmer" (->Instandhalter) aufgeführt.

Spätestens hier bringt dann ein guter Programmierstil die entscheidenden Vorteile.


----------



## Perfektionist (30 September 2010)

so, liebe(r) Shiva, solln wir uns nun nochmal die Köppe zerschlagen, was denn nun guter Programmierstil ist? Ich versuche mal, Kinsey auf unser Problem zu übertragen. 





> Was Alfred Charles Kinsey (1894-1956) 1953 im Kinsey-Report ironisch über die Nymphomanie sagte, gilt entsprechend abgewandelt auch für die Hypersexualität: Eine Hypersexualität kann bei einer Person festgestellt werden, die mehr Sex hat als Sie


Quelle:
http://de.wikipedia.org/wiki/Hypersexualität

Übertragen auf unser Problem: jeder, der anders programmiert als ich, ist eine Wildsau.


----------



## Shiva (30 September 2010)

Perfektionist schrieb:


> so, liebe(r) Shiva, solln wir uns nun nochmal die Köppe zerschlagen, was denn nun guter Programmierstil ist?


 
Um Gottes willen nein!
Ich wollte nur meine Sicht der Dinge dazu kundtun, keinesfalls irgendwen animieren zu streiten.
Der Thread hat mir wieder gezeigt wie unterschiedlich verschiedene Menschen das selbe Problem angehen/lösen, also auch sehen.
Es gibt bekanntlich ja nie nur eine Lösung für ein Problem.

Wie geschrieben, ich wollte nur meine Sicht kundtun 

Das mit der "Wildsau" bezog sich speziell auf den einen Fall, in dem jemand chaotisch, völlig ohne Struktur (nicht nur meine Meinung) ein Problem "gelöst" hat. 

Wolfgang


----------



## Shiva (30 September 2010)

Perfektionist schrieb:


> Damals war es V5.4, heute V5.5. Damals mutmaßte ich, dass eventuell ein Unterschied zwischen Prof und unProf existieren könnte.


 
Soweit mir bekannt ist, sind Professionell und normal nur unterschiedlich in den Zusatzprogrammen im Paket, sprich SCL, Graph.


----------



## vierlagig (30 September 2010)

Shiva schrieb:


> Soweit mir bekannt ist, sind Professionell und normal nur unterschiedlich in den Zusatzprogrammen im Paket, sprich SCL, Graph.



auch aber nicht nur, das key-feature ist, dass mit professionell strukturierter, sauberer und gut dokumentierter quellcode quasi automatisch erstellt wird!


----------



## Question_mark (30 September 2010)

*Kleine Rückfrage*

Hallo,



			
				Perfektionist schrieb:
			
		

> Übertragen auf unser Problem: jeder, der anders programmiert als ich, ist eine Wildsau.



Ist denn nun auch jeder, der seine Fingernägel eben nicht rosa lackiert, auch eine Wildsau 

Gruß

Question_mark


----------



## Shiva (1 Oktober 2010)

vierlagig schrieb:


> auch aber nicht nur, das key-feature ist, dass mit professionell strukturierter, sauberer und gut dokumentierter quellcode quasi automatisch erstellt wird!


also Anti-Wildsau-Version *ROFL*


----------



## Perfektionist (1 Oktober 2010)

Question_mark schrieb:


> eben nicht rosa


Über meine Farben hatte ich, glaube ich, in dem Fettschriftthread mal geschrieben. Der ist aber meiner Kenntnis nach nicht mehr öffentlich einsehbar. Rosa trägt übrigens nichtmal meine Tochter - auch nicht, als sie noch unter zwölf war.

Da Du das "ich", das ich da hingeschrieben habe, ein wenig so interpretierst, als ob ich mich damit selbst gemeint hätte, fühle ich, dass es not tut, diese Aussage "jeder, der anders programmiert als ich, ist eine Wildsau" nochmals zu zerpflücken.

Wolfgang schrieb:





> Spätestens hier bringt dann ein guter Programmierstil die entscheidenden Vorteile.


worauf ich dann bei mir dachte: was meint _der_ denn nun, was guter Programmierstil sei. Guter Programmierstil ist doch immer der, in dem ich mich zurechtfinde. Also, wenn jemand anders so codet, wie ich es selbst auch coden würde. Dabei fiel mir halt der Kinsey wieder ein. Den man auch so übersetzen könnte: Alles, was Du (Sie) an anderen als anders empfindest, kann man auch abnormal finden. Und dann hab ich halt noch das Personalpronomen ausgetauscht. Ich fand, zu sagen, "wer anders ist als ich, ist eine Wildsau", läd stärker und mehr Leute zum Nachdenken ein, als zu schreiben: "Alle, die also anders programmieren als Du, sind also Wildsäue?".


----------



## Shiva (1 Oktober 2010)

Jemand anders löst ein Problem FAST IMMER anders als man selbst es tun würde, daher reicht für guten Programmierstil, daß ein Fremder sich - dank Struktur und Dokumentation - relativ einfach reinlesen kann, den Sinn einzelner Programmteile in kurzer Zeit nachvollziehen kann.
Ich will hier keine Grundsatzdiskussion über Programmierstil vom Stapel brechen, die gibt es an anderer Stelle schon zuhauf.


----------



## Perfektionist (1 Oktober 2010)

Shiva schrieb:


> Jemand anders löst ein Problem FAST IMMER anders als man selbst es tun würde, ...


Ich selbst löse heute Probleme anders, als ich es vor zehn Jahren getan habe. Ich selbst schreibe Schrittketten mit drei Schritten anders, als Schrittketten mit dreissig Schritten. Und entsprechend ist es eine individuelle und sehr willkürliche Festlegung, was guter Stil, gute Dokumentation und gute Struktur ist.

Wenn jemand schreibt: "guter Programmierstil ist, daß sich ein Fremder relativ einfach reinlesen kann", dann entspricht dies in etwa dem Wahrheits- und Informationsgehalt von "der Himmel ist blau". Jeder wird mir (ohne aus dem Fenster zu sehen) zustimmen, dass der Himmel blau ist. Und jeder wird mir (hoffentlich) widersprechen können, dass der Himmel blau ist.


----------



## Shiva (1 Oktober 2010)

teilweise war unser Himmel heute blau 

Ansonsten hinkt Dein Vergleich heftig, aber das ist wiederum Ansichtssache, und Deine Ansichten muss ich ja nicht teilen, genauso wenig wie Du meine ;-)
Lassen wir es für diese Woche gut sein.


----------



## Perfektionist (1 Oktober 2010)

Shiva schrieb:


> Lassen wir es für diese Woche gut sein.


ich freue mich auf Montag ...


----------

