Registerindirekte Adrerssierung Funktionsbaustein

Jan85

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

für verschiedene Anwendungen nutze ich die registerindirekte Adressierung. Diese FBs haben den Vorteil, dass sie auch in einem FC aufgerufen werden können und
dennoch nur ein Instanz DB verwendet werden muss.
Zur Eindeutigkeit muss am FB eine Nr.angelegt werden (z.Bsp1-16)

Da ich diesen FB jetzt an verschiedensten Stellen im TIA bzw. Classic aufrufe,suche ich nach einer Variante, um zu merken, dass eine Nummer doppelt angelegt wurde.

Gibt es da Erfahrungen? Vielen Dank vorab,

Gruß
 
Kopierst du die Daten am Anfang und am Ende komplett in einen anderen "Container-DB" um oder wo hältst du die Daten, die dann exclusiv dem jeweiligen FB gehören?
Ich würde am Anfang des IDB, den jeder FB aufruft einen Kopfbereich (STAT) einrichten, in dem dann Daten liegen, welche nicht mit umkopiert werden. Dort könnte auch ein Bitfeld oder Array of INT liegen, in das jeder FB seine Nummer einträgt, zw. sein Bit setzt. Jeder FB prüft, ob seine Nummer schon eingetragen ist. Wenn ja --> Fehler, wenn nein --> Eintragen der eigenen Nummer an entsprechender Stelle. (Bitfeld würde reichen, INT wäre doppelte Info, geht aber auch :) ). Das Bitfeld/Array wird irgenwo im Programm zentral je Zyklus ein Mal gelöscht, z.Bsp. am Anfang des OB1 oder auch am Anfang des 1.FC, der die FB aufruft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du rufst einen FB mehrmals auf, aber jedesmal mit dem selben IDB? Warum ist das ein FB? - dann könnte es doch auch als FC realisiert werden, was noch den Vorteil hätte, das man AR2 und das DB2-Register sorglos verwenden kann.

Harald
 
Hallo,

es werden keine Daten umkopiert. Jeder Nummer (Eingang am FB) wird ein betimmter statischer Datenbereich im IDB zugeordnet.

Nr1 --> DWORD 1
Nr2 --> DWORD 2
...

Ich habe jetzt auch eine Plausibilitätsfrage bezüglich der Nummer integriert und dafür eine Kopfstruktur "Eindeutigkeit" am Anfang angelegt.

Ich benutze FBs , da Werte speichernd realisiert werden müssen. Ist das zu umständlich oder nicht sonderlich elegant?

Eindeutigkeit.jpg
 
Ich benutze FBs , da Werte speichernd realisiert werden müssen. Ist das zu umständlich oder nicht sonderlich elegant?

Na ja, man könnte auch einen FC nutzen und an eine INOUT eine Struktur mit den gewünschten Daten anlegen. Ein Global-DB enthält dann die Strukturen für X FC.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das stimmt.

Ich arbeite nur mit AR1 und frage mich nun, welche die elegantere Wahl ist? FC oder FB, bzw. ob die FB Variante Nachteile hat. Außer dem 3-Zeiler des AR-Rettens.

Gruß
 
Ich benutze FBs , da Werte speichernd realisiert werden müssen. Ist das zu umständlich oder nicht sonderlich elegant?
Dann ruft man üblicherweise den FB jedesmal mit einem anderen Instanz-DB auf und muß sich dadurch innerhalb des FB nicht mehr darum kümmern, herauszubekommen welche Instanz das gerade ist um auf jeweils andere Speicherbereiche umzuschalten. Dadurch kann man auch beliebig viele Instanzen erzeugen und aufrufen, ohne vorher Speicherplatz für eine maximal mögliche Instanzanzahl festzulegen. Falls das einem dann zu viele DB werden kann man die Instanzen in einem Mutter-FB/IDB als Multiinstanz anlegen - Vorsicht: dann muß man bei indirekter Adressierung in die Instanz den Multiinstanz-Offset aus AR2 addieren.

Harald
 
Ich habe die "Nr" Variante gewählt um die Übersichtlichkeit zu gewährleisten und nur einen IDB nutzen zu müssen.
Bei der Multiinstanz-Variante müsste ich wieder einen zusätzlichen Mutter-FB anlegen.

Die Bausteine sollen für alle Mitarbeiter leicht einsetzbar sein und es ist im Vorfeld klar, dass dieser zum Beispiel nicht mehr als 32 mal aufgerufen werden muss, also 32 Doppelworte als statischer Speicherbereich.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Bausteine sollen für alle Mitarbeiter leicht einsetzbar sein
Deshalb entwickelt Ihr dann Bausteine in einer weltweit einzigartigen umständlichen Un-Art, damit ja kein fremder oder neu eingestellter Programmierer das System auf Anhieb durchschaut. ;)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PS: wie findet Ihr z.B. zur Diagnose in Euren Programmen eine bestimmte Instanz? Indem Ihr Euch im Durchschnitt die Hälfte (*) aller FB-Aufrufe im Code ansehen müßt? Habt Ihr nur so Mini-Programme?

(*) laut Murphy findet man die gesuchte Instanz meistens erst nachdem man "max - 1" Aufrufe angesehen hat

Harald
 
Das sind nur sehr kurze, widerkehrende Funktionen, die einmal geprüft und dann für alle Zeiten fertig sein sollen.
Zum Beispiel für das Überwachen einer Bremse, Türen etc.

Es sind kleine Bausteine als Hilfe, die nicht mehr verändert werden müssen und auch keine Diagnose durchgeführt werden muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also mal ein Beispiel:
Ich habe einen FC in dem es grundsätzlich um Bremsen geht.
Hier brauche ich für 6 Antriebe 6 Überwachungs-FBs, die ich mit den Nummern hinterlege.
Sollte den FB aus irgendeinem Grund mal aus einem anderen Baustein aufrufen, möchte ich darauf hingewiesen werden, dass es den Speicherbereich schon gibt.

Ist das wirklich so untypisch?
 
... das ist eine philosophische Frage, die du dir selbst beantworten mußt.
Es gibt bestimmt viele Beispiele, wo ein solcher FB Sinn macht - ich habe z.B. für Rundschalttisch-Anwendungen so etwas gebaut hier kann der FB die am Tisch vorhandenen Station verwalten und steuern).
Für Antriebe würde ICH es nicht so machen, wie geschildert. Einen FB für einen Antrieb zu haben ist gut, wenn ich den Antrieb als Typ dann 6 mal im Projekt habe dann hätte ich entweder 6 Instanzen des FB's oder sie als Multi-Instanz in die verwaltende Baugruppe (z.B.) mit eingefügt.
Aber wie schon geschrieben - das ist meine Ansicht ...

Gruß
Larry
 
Hallo Larry,

es geht z. Bsp. um die Überwachung einer Bremse. Der Motor wird komplett über Schütze angesteuert, kein FU.
Meine FBs haben ca. 30 Zeilen Code und es werden lediglich ein paar Zustände verarbeitet und wieder ausgegeben, zum Beispiel wenn die Bremse nach 2 sek nicht öffnet.
Also kleine Funktionalität ein paar mal angewendet, gepackt in einem IDB :)

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das sind so typische Beispiele, wenn einige, wenngleich auch nicht untalentierte, doch von der Außenwelt abgekapselte Progammierer, die seit XY Jahren in der gleichen Firma arbeiten, dann in ihrer freien Zeit anfangen, sich Gedanken über "Standartisierung" zu machen.

Ich habe schon viele von diesen Standardisierungs-Erzeugnissen gesehen. Leider allesamt wenig erfreulich. Bausteine in der Regel nicht bibliotheksfähig, nicht objektorientiert, respektive denn migrierbar auf andere Systeme. Und wenn man als Freelancer mal ein Projekt in der Firma bekommt, dann muss man entweder diesen Mummenschanz und Eiertanz exact so mitmachen und so umsetzen, oder man kriegt zu hören, daß man sich nicht an die Vorgaben hält.

Wie lange arbeitest Du schon in der selben Firma ? Hast Du mal irgendwelche Seminare von Siemens zu den Produkten besucht, die ihr einsetzt ? Hast Du Dir schon andere Vorgehensweisen und Corporate Standards angeguckt ? Ich komme mittlerweile zu der Erkenntnis, das man das Thema "Standardisierung" ausschließlich externen Beratern überlassen muss, die eine entsprechende Erfahrung und Sachkunde mitbringen und das hauptberuflich tun.
 
Zuletzt bearbeitet:
Es geht um Standartanlagen und immer die gleiche Funktionalität. Um kleine Hilfen, damit nicht wieder 20 Netzwerke vollgeschrieben werden müssen.
Und hier ging es lediglich darum, ob man eine Nummer außen anlegt oder doch lieber 6 DBs erzeugt.
Mir geht es nach 2,5 Jahren im Betrieb nicht um die große "Standardisierung" ;)
 
Wie gesagt. Zukunftsfähigkeit, Objektorientierung, Migrierbarkeit. Ob das auf ner 1511 CPU mit L DINO, TAD und L LB 6.0 alles so funktionieren wird wie zu alten guten S5 Zeiten, halte ich für ein Gerücht.
 
Zurück
Oben