SFB4 "durchreichen"

mainky

Level-1
Beiträge
20
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen...

ich möchte 2 eingesetzte SFB4 TON Bausteine durchreichen. Heißt ich habe mir einen FB entwickelt der nur mit lokalen variablen versehen ist.
Vorher hatte ich S5 Zeiten drin. Hat auch funktioniert aber ich hätte am ende 18 Zeiten vom Typ S5 gehabt... soll wohl nicht so gut sein habe ich mir sagen lassen.

Mein Problem ist.. wie deklariere ich die lokale variable für den SFB4 in meinem Bibliotheksbaustein?
Das einzige was bisher funktioniert hat ist BLOCK_DB... nur wenn ich den Baustein aufrufe kann ich einen DB angeben... nur diesen kann ich ja nicht als Instanz-DB angeben.

Was muss ich tun damit ich die SFB'S durchreichen kann?

P.S. KEINE MULTIINSTANZVORSCHLÄGE BITTE... davon bin ich ab :)

gruß
Martin
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hattest recht mit der MultiInstanz
ich komm auch nicht drum rum wenn ich nicht noch mehr DB haben möchte... :(
jetzt fügt sich alles in dem nächst höheren InstanzDB zusammen :) das is supi! :)
 
jetzt fügt sich alles in dem nächst höheren InstanzDB zusammen :) das is supi! :)

Wart's mal ab bist du da auf die ersten Tretminen drauftrittst :)
Wichtig ist, dass du deinen Instanz-DB immer schön konistent hältst. SFB4 und Kollegen haben gelegentlich ein seltsames Verhalten bei nicht passenden Daten im Instanz-DB.
Änderungen im laufenden Betrieb erfordern eine gewisse Vorsicht.

Gruß
Dieter
 
Wart's mal ab bist du da auf die ersten Tretminen drauftrittst :)
Wichtig ist, dass du deinen Instanz-DB immer schön konistent hältst. SFB4 und Kollegen haben gelegentlich ein seltsames Verhalten bei nicht passenden Daten im Instanz-DB.
Änderungen im laufenden Betrieb erfordern eine gewisse Vorsicht.

Gruß
Dieter

Stimmt, aber die Vorteile der Muliintanzen überwiegen m. E. die Nachteile bei weitem. Vorallem wenn man FB´s für gekapselte Aufgaben bastelt und dann getestet in den Anlagen nur aufrufen braucht. Dann besteht o.g. Problem gar nicht ;-)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also nach meiner Meinung überwiegen die Nachteile bei solchen Bausteinen.
Daher bin ich dafür sich die Zeiten selber zu bauen, wenn die Funktion so und so in sich gekapselt ist, dann einen Taktmerker mit der richtigen Rasterung als Eingang und gut ist es.


bike
 
@bike
Gut, ich bin gegen den SFB4 weil er für einen Timer viel zu viele Ressourcen verbraucht.

Aber auch wenn du dir Zeiten selber baust, dann hast du wenigstens den aktuellen Zeitwert irgendwo gespeichert,
bei wiederverwendbaren Bausteinen natürlich vorzugsweise im STAT-Bereich, und somit wieder exakt das gleiche Problem ... bei unvorsichtigen Änderungen.

Mfg
Manuel
 
Also nach meiner Meinung überwiegen die Nachteile bei solchen Bausteinen.
Daher bin ich dafür sich die Zeiten selber zu bauen, wenn die Funktion so und so in sich gekapselt ist, dann einen Taktmerker mit der richtigen Rasterung als Eingang und gut ist es.

Sorry, aber deine Argumentation kann ich nun gar nicht nachvollziehen.
Wenn du deine Timer selber baust, dann hast du das gleiche Problem bei Änderungen in der Muliinstanz oder Global-DB (je nach dem wo du deine Zeitwerte ablegst).

Ich verwende seit langem kaum mehr "normale" Timer. Nur wenn Änderungen im laufenden Betrieb notwendig sind, dann kommt eine normale Zeit als Provisorium zum Einsatz.
In der nächsten Produktions-Pause wird diese dann wieder durch einen SFB-Aufruf ersetzt.

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Sorry, aber deine Argumentation kann ich nun gar nicht nachvollziehen.
Wenn du deine Timer selber baust, dann hast du das gleiche Problem bei Änderungen in der Muliinstanz oder Global-DB (je nach dem wo du deine Zeitwerte ablegst).
Brauche ich Multiinstanzen, wenn ich einen in sich gekapselten Baustein habe, der das macht was notwendig ist?
Den rufe ich mit IDB auf und gut ist.
Multiinstazen sind selbst in Serien Maschinen nach unserer Erfahrung nicht das Wahre.
Ich finde immer noch keinen echten Grund, warum ich mir das antun muss.

Daher sind unsere Ansichten vermutlich so verschieden.


bike
 
Naja, wenn du einen gekapselten Baustein hast, und irgendwelche Variablen darin hast,
dann spielt es im Endeffekt absolut keine Rolle, ob du jetzt schreibst Zeitwert1 : INT oder Timer_1 : TON.
Du hängst in beiden Fällen auf Gedei und Verderb an der Instanz, insbesondere bei Programmänderung während RUN.

Insofern bist du, konsequent zu Ende gedacht, dann also gegen FB und Instanzen, weil ansonsten ändert sich nichts an der potentiellen Problematik.
Ganz besonders nicht bei der Verwendung von 08/15 Bausteinen, welche jede CPU hat, wie die IEC-Timer.

Natürlich kann man das ganze auch Gnadenlos übertreiben, aber die Timer gehören sicher nicht zu den potentiellen Kandidaten füs Übertreiben.

Mfg
Manuel
 
Naja, wenn du einen gekapselten Baustein hast, und irgendwelche Variablen darin hast,
dann spielt es im Endeffekt absolut keine Rolle, ob du jetzt schreibst Zeitwert1 : INT oder Timer_1 : TON.
Du hängst in beiden Fällen auf Gedei und Verderb an der Instanz, insbesondere bei Programmänderung während RUN.

Insofern bist du, konsequent zu Ende gedacht, dann also gegen FB und Instanzen, weil ansonsten ändert sich nichts an der potentiellen Problematik.
Ganz besonders nicht bei der Verwendung von 08/15 Bausteinen, welche jede CPU hat, wie die IEC-Timer.

Natürlich kann man das ganze auch Gnadenlos übertreiben, aber die Timer gehören sicher nicht zu den potentiellen Kandidaten füs Übertreiben.

Mfg
Manuel

In Endeffekt?
Der ist für mich, dass es funktioniert.
Ich bin eigentlich gegen gar nichts.
Die Erfahrung sagt mir jedoch, dass es einfacher und sicherer ist, sich seine Zeiten und Zähler selbst zu bauen.
Zur Zeit habe ich das Problem, dass verwendete IEC Timer mit Wert 0 betrieben werden sollen.
Und das geht nicht.
Daher selber bauen, gut dokumentieren und dann weiß jeder wie mit den Funktionen zu verfahren ist.

Wenn heute noch jemand sagt, Multiinstanz ist gut und soll verwendet werden, dann spricht der bestimmt nicht von und über Siemens.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zur Zeit habe ich das Problem, dass verwendete IEC Timer mit Wert 0 betrieben werden sollen.
Bislang war bei den von mir verwendeten IEC Timern die Werteingabe am Display auf einen sinnvollen Bereich
eingeschränkt und ich bin über dieses Phänomen noch nicht "gestolpert".
Hätte ich das jetzt nicht mehr oder minder zufällig gelesen dann wäre ich vielleicht sogar mal "gestürzt"...
Bin eigentlich ein Freund von Multiinstanzen, aber in diesem Zusammenhang wackelt meine Einstellung nun ein wenig.
@Bike, kannst du mal ein Beispiel hier einstellen wie dein selbst gebauter Timer aussieht?
Alle verwendeten IEC Timer vorher auf 0 zu vergleichen o.ä. ist mir zu aufwendig.

Gruß
Toki
 
Das "Problem" mit der Gültigkeit / Konsistenz von Daten bei Online-Änderungen haben alle mir bekannten SPSen in der ein oder anderen Form. Bei Siemens hast du vielleicht sogar noch den größten Einfluß darauf.

Einen IEC-Timer mit Wert 0 zu verwenden ist doch ein prima Beispiel für die Verwendung von Multiinstanzen. Pack den SFB mit einem Vergleicher in FB und ruf diesen Anstelle des SFB im restlichen Programm auf. Bei Operantenvorrang "Symbolisch" die Symboltabelle ändern und Bausteinkonsistenz prüfen sind schon die halbe Miete.
 
Einen IEC-Timer mit Wert 0 zu verwenden ist doch ein prima Beispiel für die Verwendung von Multiinstanzen. Pack den SFB mit einem Vergleicher in FB und ruf diesen Anstelle des SFB im restlichen Programm auf. Bei Operantenvorrang "Symbolisch" die Symboltabelle ändern und Bausteinkonsistenz prüfen sind schon die halbe Miete.

Warum soll bzw muss ich alles immer vergleichen?
Wenn ich eine Funktion verwende, dann soll diese fehlerhafte bzw falsche Werte selbst abweisen.
Macht es echt Sinn, einmal in der Visualisierung und dann in der PLC und das nächstemal wenn Daten über Netz kommen, zu überprüfen?
Ich erwarte, dass eine Funktion auch Exception handlen kann.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Warum soll bzw muss ich alles immer vergleichen?
Wenn ich eine Funktion verwende, dann soll diese fehlerhafte bzw falsche Werte selbst abweisen.
Macht es echt Sinn, einmal in der Visualisierung und dann in der PLC und das nächstemal wenn Daten über Netz kommen, zu überprüfen?
Ich erwarte, dass eine Funktion auch Exception handlen kann.

Das Verhalten der IEC-Timer bei 0 als Zeitwert ist definiert. Es entspricht nur nicht deinem "gewünschten" Verhalten. Ich kann hier keine Exception erkennen. Das einzige Problem das ich (zur Zeit) bei S7 mit Exception kenne ist der leidige BCT->Int-Wandler.

Gruß
Dieter
 
Ich kann hier keine Exception erkennen.

Für mich ist eine Exception auch ein fehlerhaftes Verhalten der Software, die nicht als ebensolche angezeigt wird.
Und wenn es so definiert ist, dann sollen sich die "klugen" Köpfe auch Gedanken machen wie dies in der Praxis zu verwenden ist.

Schau ich bin da sehr tolerant. Nimm die IEC Timer oder lass es, doch bei S5timern kenne ich solche Einschränkungen nicht.


bike
 
Zurück
Oben