Direkte Adresse aus dem FB benutzen

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich möchte euch Fragen wie es bei euch auf der Firma gehandhabt wird, oder was ihr mir vorschlagen könnt.

Wir arbeiten mit FB`s (Bausteinprinzip) doch sind wir ein sehr Kundenorientiertes Unternehmen und erfüllen jeden Kundenwunsch. Aus diesem Grund gibt es häufig Änderungen in den FB's. Ändert man was in den FB's so muss man alle Adressen die direkt aus dem FB genutzt werden in allen Bausteinen ändern und Touchpanel. (weil die sich ja verschieben)

Man könnte die Direkten Adressen der FB's einem globalen DB zuweisen und diese globalen DB Adressen dann für das Panel und Bausteine verwenden. Doch in diesem Fall wird die CPU ja stärker belastet und wird langsamer. Ich habe aber keine Ahnung ob die CPU ausgelastet ist oder nicht. Im Prinzip muss diese recht schnell sein da wir mit Servomotoren arbeiten und z.B. Nocken benutzen.

Wäre dankbar für die Meinungen, Erfahrungen, Lösungen.

Gruß

Rici

 

[SCM]

Hallo!

Welche Adressen nutzt ihr den direkt aus den FB´s das hab ich nicht ganz verstanden!

Mfg

 

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

z.B. DB1.DBX1.0

Diese Adresse benutzen wir in anderen FB's, FC's und auch im Touchpanel.
-------------------------------------------------------------------------
"ein" =DB1.DBX1.0

Man könnte ja aber u "ein"
= DB100.DBX1.0 schreiben.

DB100 global

Und diesen DB100.DBX1.0 in anderen FB's, FC's und auch im Touchpanel benutzen.

ich hoffe es ist nun verständlich

 

[SCM]

Und was verändert sich dann an dem DB1.DBX1.0?
Meinst du wenn du im DB davor noch etwas hinzufügst?Oder ist dein DB1 ein Instanz DB?

Mfg

 

[ErwinLSE]

Hallo,

wir machen immer quasi Schnittstellen DB's um Informationen zwischen veschiedenen FB's und FC's zu tauschen, kann mir nicht vorstellen das das viel Taktzeit kostet.
Für Taktzeitkritische Funktionen kann man ja den OB35 verwenden, die Taktzeit für den kann man in der Hardwarekonfig festlegen.(z.B.20ms)

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der direkte Zugriff auf die IDB wird auch hier im Forum sehr gegensätzlich betrachtet.

1. Das kann man machen, über die Step7-Manager-Funktion "Bausteinkonsistenz prüfen" kann man evtl. Verschiebungen bei Einstellung auf "symbolische Adressierung" und deren konsequenter Anwendung im S7-Programm korrigieren.

2. Das geht gar nicht, IDB sind so etwas wie lokale statische Daten einer Funktion und dürfen ausschließlich von dieser genutzt werden. Datenübergaben werden ausschließlich über die Schnittstellen IN, OUT und INOUT des FB und damit über globale DB getätigt.

3. wie Variante 2, aber in Einzelfällen kann man das machen, wenn der FB ein abgeschlossener Baustein in sich ist, der kaum einmal angepaßt werden muß (z.Bsp. der FB126 von Siemens für den Profibus. Dieser FB wird von der Visu komplett über den IDB ausgelesen und auch gesteuert.

Ich selbst bin für Variante 2, besonders problematisch an Variante 1 sind Verbindungen zu HMI, möglichst noch Fremd-HMI, nicht von Siemens, da sucht man sich dann einen Wolf, wenn man am FB ändert und diese Änderungen nicht automatisch in der HMI nachgeführt werden.

 

[SCM]

Der direkte Zugriff auf die IDB wird auch hier im Forum sehr gegensätzlich betrachtet.

1. Das kann man machen, über die Step7-Manager-Funktion "Bausteinkonsistenz prüfen" kann man evtl. Verschiebungen bei Einstellung auf "symbolische Adressierung" und deren konsequenter Anwendung im S7-Programm korrigieren.

2. Das geht gar nicht, IDB sind so etwas wie lokale statische Daten einer Funktion und dürfen ausschließlich von dieser genutzt werden. Datenübergaben werden ausschließlich über die Schnittstellen IN, OUT und INOUT des FB und damit über globale DB getätigt.

3. wie Variante 2, aber in Einzelfällen kann man das machen, wenn der FB ein abgeschlossener Baustein in sich ist, der kaum einmal angepaßt werden muß (z.Bsp. der FB126 von Siemens für den Profibus. Dieser FB wird von der Visu komplett über den IDB ausgelesen und auch gesteuert.

Ich selbst bin für Variante 2, besonders problematisch an Variante 1 sind Verbindungen zu HMI, möglichst noch Fremd-HMI, nicht von Siemens, da sucht man sich dann einen Wolf, wenn man am FB ändert und diese Änderungen nicht automatisch in der HMI nachgeführt werden.

Also ich bin auch ganz klar für Variante 2!!
Mfg

 

[Ralle]

Ergänzend noch, Variante 3 ist in Ausnahmefällen auch ok, wie z.Bsp. bei dem besagten Siemens-FB. Ich selbst hab einen FB für ein PNOZ-Multi, da wäre die Schnittstelle nach außen riesig geworden und der FB wird eher selten geändert.

 

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ergänzend noch, Variante 3 ist in Ausnahmefällen auch ok, wie z.Bsp. bei dem besagten Siemens-FB. Ich selbst hab einen FB für ein PNOZ-Multi, da wäre die Schnittstelle nach außen riesig geworden und der FB wird eher selten geändert.

genau diesen Fall haben wir in der Firma.

Selten, auch wenn ich ein, zwei mal im Jahr wegen einer Änderung z.B. das Panel durchforsten muss ist es meiner Meinung nach nicht richtig.

Ich bin für einen globalen DB als Schnittstelle. Nur wird die SPS ja langsamer und ich weiß nicht ob ich es so einfach machen kann. Vor alle unser Hauptprogrammierer mag die Idee nicht wirklich.

 

[Verpolt]

Ich bin für einen globalen DB als Schnittstelle. Nur wird die SPS ja langsamer und ich weiß nicht ob ich es so einfach machen kann. Vor alle unser Hauptprogrammierer mag die Idee nicht wirklich.

Warum soll denn die SPS langsamer werden? Nur weil die Daten in einem Globalen-Container und nicht im Instanzdatenbaustein wohnen?

Wegen eventuellem Umladen?

 

[Larry Laffer]

Hallo,
wenn ich mir eine Art "Standard-FB" bauen möchte dann sehe ich das als absoluten Widerspruch, wenn hier dann eine absolute Adressierung Anwendung findet.
Die Lösung hierzu wäre dann z.B. eine festgelegte Daten-Struktur (UDT), die über die Schnittstelle übergeben wird (dann können die Daten ja wieder von überall her kommen). An dieser Stelle entsteht dann natürlich ein mehr an Zykluszeit - die Frage, die sich hier stellt ist dann aber, ob es einem das nicht wert sein sollte.

Vielleicht gibt es auch noch andere Möglichkeiten - dafür müßte aber (zumindestens) ich mehr über den konkreten Fall erfahren ...

Gruß
Larry

 

[Rici]

Zuviel Werbung?
-> Hier kostenlos registrieren

.................Hallo!..................sorry.......

 

[Rici]

ich weiß nicht wie ich es immer wieder hinkriege..

sorry noch mal

 

[Ralle]

Hallo,
wenn ich mir eine Art "Standard-FB" bauen möchte dann sehe ich das als absoluten Widerspruch, wenn hier dann eine absolute Adressierung Anwendung findet.
Die Lösung hierzu wäre dann z.B. eine festgelegte Daten-Struktur (UDT), die über die Schnittstelle übergeben wird (dann können die Daten ja wieder von überall her kommen). An dieser Stelle entsteht dann natürlich ein mehr an Zykluszeit - die Frage, die sich hier stellt ist dann aber, ob es einem das nicht wert sein sollte.

Vielleicht gibt es auch noch andere Möglichkeiten - dafür müßte aber (zumindestens) ich mehr über den konkreten Fall erfahren ...

Gruß
Larry

Hab ich was verpaßt? Wer sprach von absoluter Adressierung?

Aber davon abgesehen, ich hab tatsächlich noch ein paar alte AWL-Bausteine am Laufen, die mit "Auf DB" und nicht qualifiziertem Zugriff arbeiten. Das hat gegenüber der UDT einen großen Vorteil, man findet im Querverweis zumindest die Zugriffe. Leider ist das das ganz ganz große Manko der Siemens-Architektur, man findet per UDT oder Any übergeben Variablen nicht im Querverweis. Das betrifft natürlich auch per indirekter Adressierung umkopierte Daten. Wer schon einmal in absolut fremden Programmen SUCHEN mußte, wird diese Art der Programmierung auch verflucht haben, obwohl die Übergabe per UDT oder Any doch eigentlich eine gute Sache ist.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab ich was verpaßt? Wer sprach von absoluter Adressierung?

Siehe Beitrag #3 in diesem Thread ...