FB's statt FC's und DB's

Ulrich Klakow

Level-1
Beiträge
18
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

ich sehe leider immer wieder, dass hier für Lösungen die sich am besten mit einem FB+Instanz-DB mit FC's und DB's realisiert werden.
Ich setze seit Jahren fast nur FB's ein. Meist verwende ich Multiinstanz-FB's. Das hat vor allem den Vorteil das sich Step7 um die Adresslage der Variablen kümmert und nicht ICH mich darum kümmern muß. :wink:

Fast alle Anwendungen benötigen statische Daten, wenn man diese im Variablenteil sauber Deklariert, brauche ich mich innerhalb des FB's nicht mehr darum zu kümmern wo die Variable steht. Bei jedem einfügen oder löschen von Variablen berechnet Step7 die aktuelle Adresse der Variablen, ich muß also nicht im FB jede Adresse ändern auf die mein Baustein zugreifen muß!
Bis auf Multiinstanz-Variablen kann ich die benutzen Variablen in statischen Teil auch über einen zuvor erstellten UDT deklarieren und ansprechen, das hat den Vorteil, dass ich z.B. die Daten eines Motors (UDT) auch in anderen Bausteinen einfügen kann ohne mich ständig selbst um die Änderungen am Aufbau in mehreren Bausteinen zu kümmern.
Dies ist nur ein sehr kleiner Teil der Möglichkeiten die hierdurch möglich sind, in letzter Konsequenz kann man Step7 dazu bringen, sich um ALLE Adressberechnungen für den Variabenzugriff selbst zu kümmern. Dann gehören die dauernden SPS-Stopps durch einen Zugriff auf nicht vorhandene Adressen (DB zu kurz) oder auf eine falsche Adresse in einem DB weitgehend der Vergangenheit an. :D

Wenn jemand genaueres Wissen will schickt mir doch eine Mail an
Klakow@web.de (Privat)
ulrich.klakow@familie-klakow.de (Tagsüber)

MfG, U.Klakow

P.S. Ich arbeite mit der Version 5.2 SP1, damit läst sich viel leichter mit FB's arbeiten als mit der alten Version
 
Ok, die Instanz DB's haben sicher ihre Vorteile.

Was UDT's angeht:
Vor einige Wochen hatte ich folgendes: Von einem DP Slave bekomme ich Daten der Form
Code:
Status1 BYTE	(0)
Wert1   WORD	(1!)
Status2 BYTE	(3!)
Wert2   WORD    (4)
(unmittelbar hintereinander)
Wenn ich versuche, das als UDT oder auch nur als Deklaration im DB-Editor anzugeben, legt Step7 (V5.0, SP2) das WORD auf die nächste gerade Adresse. Habe keine Lösung dafür gefunden (auch nicht in Foren) und spreche meine Daten als DB.DBW1 oder DB.DBB3 an.
Die UDTs entsprechen in etwa structs in C oder records in Pascal, ohne jedoch wirklich deren Möglichkeiten zu erreichen.
Insgesamt wäre es mit lieber, Siemens würde einen anständigen Compiler für AWL anbieten und das Schreiben des Programms könnte mit jedem Editor erfolgen. Die Zuordnung von Variablen zu Adressen könnte dann AUTOMATISCH durch den Compiler erfolgen, sofern nicht ausdrücklich (für Ein- und Ausgänge) anders bestimmt. Wie in jeder vernünftigen Programmiersprache.
Die Zuordnung der Variablen nach Einfügen eines Parameters im FB bliebe dadurch erhalten, das man im Quelltext Formal- (im FB) und Aktualparameter (beim Aufruf) an derselebn Stelle (d.h z.B als dritten) einfügt. Verschiedene Zahl kann der Compiler immer, Vertauschungen nur bei unterschiedlichem Typ erkennen.
Auf die Steuerung würden die Änderungen aus dem letzten Compilerlauf idealerweise nur gemeinsam geladen.
Für S5 gab es einen Compiler, der aber pedantisch auf Tabs, Spaces und Spaltenposition der Anweisungsteile achtete. Mit einem normalen Editor nicht zu machen.
Instanz DB's sind aus dieser Sichtweise ein kleiner Schritt Richtung OO (objektorientierung). (Kapselung von Code und Daten). Leider hat das "Objekt" (FB +DB) nur eine Methode, den FB.
Da ich nur ein bis fünfmal im Jahr Step 7 anfasse, jedoch immer mal wieder auch andere SPS (S5, Allen Bradley, GE Fanuc), tendiere ich dazu alles so zu schreiben, wie es auf jeder Kiste geht.
Einfaches Beispiel Zeiten:
Sowas wie Einschaltverzögerung mit SE kann jede. Und in Kombination mit ein oder zwei Merkern kann man damit alles andere nachbilden.
Das einzige, dem ich nicht "widerstehen" konnte waren die Lokalvariablen in FB's.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
UDT's

Hey Zottel,

das mit dem Adressoffset ist kein spezielles S7-Problem sondern das gibt es auch in anderen Systemen (z.B. 680xx).
Was ich aber nicht verstehe wie du deine Daten von einem DP-Slave bekommst. Wenn du die Daten mit z.B.
L EB20
T zielUDT.Status1
L EB23
T zielUDT.Status2
L EW21
T zielUDT.Wert1
L EW24
T zielUDT.Wert2

Abholst dann hast du kein Problem, du must dann nur die Reihenfolge der Werte in der UDT umsortieren. Wenn du aber einen Baustein hast der die Werte direkt in deinen Instanz-DB Schreibt, hilft nur umkopieren.

Das mit der OOP ist vollständig richtig was du schreibst, es gibt aber noch mehr Möglichkeiten mit Step7 zu vernünftigen Programmen zu kommen.
Wenn du z.B. die Variablendeklaration von zwei FB's vollständig gleich hältst (deshalb UDT's) und sagen mir mal in einem FB20 mehrere Programmteile mehrmals benötigst und du willst die ganzen Parameter abeb nicht einem FC anhängen, so kannst du aus dem FB20 z.B. einen FB21 mittel
UC FB21
aufrufen. Er benutzt dann die selben Variablen mit dem selben DB wie der FB20. Nur die Lokaldaten sind nicht die gleichen wie vom FB20, der FB21 nutzt dann einen eigenen Stackframe so weit ich das getestet habe.

Gott zum Gruße, Ulrich Klakow
 
>das mit dem Adressoffset ist kein spezielles S7-Problem sondern
>das gibt es auch in anderen Systemen (z.B. 680xx).
Ich erinnere mich dunkel an 680xx assembler, da war was aber was...fehlten dem 68020 schon die unteren Adressbits ?
Ich denke es ist hier Problem der SPS, den L DBW 3 funktioniert ja klaglos. Es ist wie ein C-Compiler dem das "#pragma pack" fehlt oder eine andere Anweisung zum Alignment.
>Was ich aber nicht verstehe wie du deine Daten von einem
>DP-Slave bekommst. Wenn du die Daten mit z.B. ....
als 12-Byte-Block mit SFC14. Status und Wert müssen konsistent sein, 4 einzelne 3-Byte-Zugriffe bedeuten unnötige Aufrufe des SFC14.
>L EB20
>T zielUDT.Status1
Umladen, nur um die UDT's zu nutzen?
 
Nicht unbedingt

Wenn du die Daten aus dem Processabbild liest,
haben neuere CPU's haben meist von sich ein kostistenten
Zugriff, das Processabbild wird ja während der OB1 läuft ja nicht mehr
aktualisiert und die CPU's holen die Daten vom DP-Slave in einem
rutsch ab.
Schau mal wie lange ein SFC14/15 zur Bearbeitung braucht, du
sparst überhautnichts durch sie. Wenn du die Daten sowieso mittels
Lade/Transferbefehlen abwickeln kannst, machen UDT's ja wieder
sinn. Es geht ja auch nicht nur darum deine Daten abzuholen und
über eine UDT abzuholden, dass entscheindene ist das du ALLE Daten
die du für dein Gerät benötigst in die UDT schreibst und sich Step7 um
die Zuordnung der Symbolik zur Speicheradresse im DB kümmert und nicht mehr du. Ich glaube nicht das du für die Steuerung deines Gerätes
nur die 12-Bytes benötigst?!

Gruß, Ulrich Klakow

P.S. Der 68020 hat zwar kein A0 und A1 mehr aber für jedes Byte das an der Lade-Transferoperation teilnimmt ein Bit
(etwa /DS0, /DS1 ,/DS2, DS3)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Prozessabbild ändert sich im OB1 nicht. Ich finde gerade nicht wieder, was ich mal darüber gelesen habe, aber ich habe es so verstanden, daß Daten, die über DP transportiert werden und nicht die Größe WORD (oder DWORD?) haben, gar nicht erst zwingend konsistent ins Prozessabbild gelangen, sei es weil der Bustransfer in "Häppchen" geschieht oder weil der Slave erst durch irgendeine Besonderheit der Anforderung (mittels SFC14) dazu veranlasst wird, Teile der Daten nicht während des laufenden Transfers zu aktualisieren.

Von diesem Modul (4-Kanal-Analogeingabe) des Geräts (Beckhoff-Buskoppler) lese ich nur 12 Byte. Die HW-Konfig läßt nur die Wahl "Daten konsistent über Länge" (12byte) oder "Einheit" (byte).
Dann kommen vier FB-Aufrufe (2xFB9 und 2xFB29), die aus den Daten je eines Kanals und weiteren Daten was berechnen. (Daten wären also auf 4 Instanz-DBs zu verteilen).
Mein Analogwert stellt ein Abstandsmass dar. In C++ oder JAVA würde man eine Methode setAbstand(int) definieren. In Analogie zur OOP müsste es jetzt einen weiteren FB mit Zugriff auf denselben Instanz-DB geben, der ausschliesslich das Feld "Abstand" aktualisiert. Nun fehlt eine syntaktische Struktur als Klammer, die das alles zum Objekt zusammenfügt.

Da scheint es mir einfacher, die Datenquelle im call als DBx.DBW1, 4,7,10 anzugeben.
Eine UDT würde einzig dazu helfen, daß ein Leser des Programms bei den Parametern des calls "Abstand_Baugruppe_1" vorfinden könnte.
Das ist einfacher mit einem //Kommentar getan.

Zuletzt gehen errechnete Daten zurück zum selben Buskoppler (aber anderes Modul) und anderen Anlagenteilen.
 
Zurück
Oben