Programmstruktur Step7

mariob

Level-3
Beiträge
2.052
Reaktionspunkte
276
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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 ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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:p.
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
 
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.
 
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".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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:ROFLMAO:, entschuldige Perfektionist, hier einen Schnellstart hinlegen muß, wie immer in dieser Gesellschaft. Das kennen aber hier sicherlich viele.

Gruß
Mario
 
Zuletzt bearbeitet:
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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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:cool: (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
 
... 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.

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

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.
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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 ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 :cool: fand.

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

Scheiß darauf :cool: bleibt :cool:.

S7 rules.


Frank
 
Zurück
Oben