Programmstruktur Step7

Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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.
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?

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.

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:
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:
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.
Zitat von Perfektionist
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?
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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 ;)
 
Ä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.
 
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.
 
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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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!
 
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.
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
Hallo Harald,
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
 
Zuletzt bearbeitet:
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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. ...
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.
 

Anhänge

  • Test1.zip
    729,4 KB · Aufrufe: 4
  • Test2.zip
    729,4 KB · Aufrufe: 3
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.
 
Zurück
Oben