# Strukturprobleme Multiinstanz ...



## rs-plc-aa (9 Februar 2007)

Hallo,

ich möchte ein ziemlich umfangreiches Programm so umbauen daß alle "Kernkomponenten" multiinstanzfähig werden...

Mein Ausgangspunkt ist nicht gerade günstig - alles direkt adressiert, FC calls im FB, direkte Global DB zugriffe usw.

Das Problem: Die ganze Sache neu machen is nich weil es ganz einfach viel zu lange dauern würde und weil ich die Logik als solches lassen möchte da das Programm ausgiebig getestet wurde und prima läuft (so lange es alleine auf einer CPU ist)

Nun sollen davon aber mehrere (variabel) Instanzen auf einer CPU laufen - und das möglichst schon gestern.

Am einfachsten wäre es natürlich die Bausteine unter anderen Nummern einzufügen und als solches zu lassen - wobei hier auch schon die ganzen Adressen von Hand nachgepflegt werden müssten und es eine absolute "Notkrücke" bleiben würde.

Die Idee der Multiinstanz ist zwar nicht neu aber die Umsetzung für mich schon ein wenig -> daher hoffe ich daß ihr mich nicht hängen lasst.

Es dreht sich im wesentlichen um ein Hauptprogramm das wie ein Tintenfisch aufgebaut ist (ich war jung und... ) und nun eine Schnittstelle verpasst bekommen soll die es mit der Aussenwelt verbindet.

Hier müssen digitale IOs, skalierte und rohe Messwerte, Meldebits, Merker und Störungsbits untergebracht werden.

Das mit der Peripherie ist kein Problem nur mit den Bits und den Unterprogrammen haperts noch.

Die Bits müssen aus der SymTabelle raus und in GDBs rein, ok.

Wie mache ich jetzt aber z.B einen Gesamtzugriff auf z.B. 32 Bits ?

Vorher habe ich eben das Doppelwort aus dem Adressbereich mit 0 überschrieben - aber wie geht das beim DB mit Symbolischem zugriff ?

Ich wollte Arrays definieren welche immer 32 Bits einer Sorte enthalten um entweder einzeln oder eben auf alle zugreifen zu können aber irgendwie schaff ich das nicht.

In der Hilfe steht nichts konkretes und hier habe ich zu Arrays zwar was gefunden aber das half mir jetzt so auch nicht weiter.

Das zweite ist das mit den Unterprogrammen.

Sehe ich das richtig daß alles was an die Schnittstelle des Unterprogramms übergeben werden soll auch in der Schnittstelle des Hauptprogramms enthalten sein muss ? Wird das nicht sehr aufgebläht ?

Und ist das überhaupt zu empfehlen ?

Wäre für Anregungen jeglicher Art sehr dankbar.


----------



## HeizDuese (9 Februar 2007)

rs-plc-aa schrieb:


> ...
> 
> Es dreht sich im wesentlichen um ein Hauptprogramm das wie ein Tintenfisch aufgebaut ist




????


rs-plc-aa schrieb:


> ...
> Die Bits müssen aus der SymTabelle raus und in GDBs rein, ok.



Kann, man, muss man aber nicht - kommt immer drarauf an, was man wie machen möchte - hat aber nix mit Multiinstanzen zu tun und ist auch nicht Vorraussetzung für diese.




rs-plc-aa schrieb:


> ...
> 
> Wie mache ich jetzt aber z.B einen Gesamtzugriff auf z.B. 32 Bits ?
> 
> ...



Hier könnten wir denke ich mal besser helfen, wenn Du mal ein paar Code-Ausschnitte postest (Multiinstanz, oder nicht) und beschreibst, wann konkret klemmt.



rs-plc-aa schrieb:


> ...
> Das zweite ist das mit den Unterprogrammen.
> 
> Sehe ich das richtig daß alles was an die Schnittstelle des Unterprogramms übergeben werden soll auch in der Schnittstelle des Hauptprogramms enthalten sein muss ? Wird das nicht sehr aufgebläht ?



So ganz habe ich es nicht verstanden. Vielleicht ist aber das gemeint:
Also beim Aufruf müssen nicht alle IN, INOUTs, oder OUTs beschrieben werden - die INs werden halt beim ersten Mal mit ihren Initalwerten beschrieben und die bleiben auch so, bis sie überschrieben werden.

Du kannst Dir auch mal hier ansehen, wie so eine Multiinstanzaufruf aussieht: http://www.automatisierungsprofi.de/TON/index.htm



rs-plc-aa schrieb:


> ...
> Und ist das überhaupt zu empfehlen ?



Auch das kommt wieder daruf an, was man haben möchte. Es gibt auf dieser Welt leider nichts, was nur Vorteile hat oder bringt. Der Vorteil ist halt, dass man Multiinstanzen, wenn man sie ordentlich programmiert gut wiederverwenden kann - wenn man keine globalen Variablen (Symboltabelle) beenutzt hat, sondern nur mit Lokalen- und Instanzdaten auskommt.

Für die Erstellung eine Biblitohek (das sind ja meistens Bausteine drin, die universell einsetzbar sein sollen), macht es schon Sinn Instanzbausteine zu erzeugen.


----------



## rs-plc-aa (9 Februar 2007)

HeizDuese schrieb:


> ????
> Der Vorteil ist halt, dass man Multiinstanzen, wenn man sie ordentlich programmiert gut wiederverwenden kann - wenn man keine globalen Variablen (Symboltabelle) beenutzt hat, sondern nur mit Lokalen- und Instanzdaten auskommt.
> 
> Für die Erstellung eine Biblitohek (das sind ja meistens Bausteine drin, die universell einsetzbar sein sollen), macht es schon Sinn Instanzbausteine zu erzeugen.


 
Genau hierum geht es...

Das mit dem Tintenfisch war übrigens als Metapher gemeint um die Verzweigung in andere Bausteine hinein zu umschreiben...

Vielleicht bin ich auch nicht genau genug auf den Punkt gekommen aber ich möchte hier noch mal die Frage neu stellen:

Wenn ich jetzt das stehen habe:


```
U DB100.dbx0.0
= A0.0
 
und z.B.
 
L 0
T DB100.DBD0
```
 
Und nachher möchte ich das haben:


```
U #Bits.Bit0
= ...
 
oder
 
L 0
T #Bits.erste32Bits
```
 
Also z.B. die Nummer des DB als VARINPUT und die einzelnen Bits beim Namen nennen oder auch beim Rücksetzen alle Bits auf einmal löschen mit einem Lade/Transferierbefehl.

Frage: Brauche ich hierfür im DB100 ein Array of BOOL oder geht das auch ohne ?
Der syb. Zugriff auf die Bits geht ohne Array auch - nur der Gesamte nicht da ich ja im DB die verwendete Adresse nur ein mal vergeben kann.

Die zweite Frage hat sich erledigt da es ja nicht anders gehen wird als die Parameter die das Unterprogramm benötigt über die Schnittstelle des Hauptprogramms zu übergeben...


----------



## Ralle (9 Februar 2007)

"Symbolisch" über # wird das wohl nicht gehen, denke ich.

Du könntest mit 

AUF DB[DB_Nr]
U DBX0.0 
...

arbeiten, aber das ist auch nicht immer fein.

Wenn die Daten im Instanz-DB liegen kannst du auch auf die Instanzdaten zugreifen

L 0
T DIW 0

Dazu muß dir bekannt sein, wo die Daten im Instanz-DB denn genau liegen.


----------



## rs-plc-aa (9 Februar 2007)

OK, noch mal eine Korrektur:

Der Code den ich schrieb war falsch.

Ich habe im Instanz DB (also in der Schnittstelle des FB) Variablen deklariert.

Zum einen eine ganze Reihe von Bits die im FB mit #Bit0 angesprochen werden und für diese Bits jeweils für 32 Stück eine DWORD Variable die im Falle eines Tranferierens einer 0 alle ihr zugeordneten Bits "löschen" soll.

Beim Aufruf der Instanz im OB1 muss die Schnittstelle ja versorgt werden -> hier kommt ja eigentlich erst der DB ins Spiel der die Bits enthält...

Also gebe ich dort an daß #Bit0 := DB100.DBX0.0 ist bzw. sein soll.

Soweit schon klar aber das DWORD aus dem FB kann ich eben nur "absolut" also mit DB100.DBD0 zuweisen da im DB100 unter der Adresse 0* eben die BOOL Variablen stehen und es gleichzeitig keine Variable vom Typ DWORD mit der Anfangsadresse 0 geben kann.

Hier war meine Frage ob es geht wenn ich ein Array definiere das dann meine DWORD Variable ist und Ihm untergeordnet im gleichen Adressbereich die Bits zu finden sind.

Da ich 0 Ahnung von Arrays habe weiss ich nicht wie ich das sonst noch formulieren soll...


----------



## Ralle (9 Februar 2007)

Mit dem Array, das geht so nicht, glaube ich jedenfalls  .

Alle INPUT, OUTPUT etc. sind doch im Instanz-DB enthalten.

Du kannst einmal auf die definierten Variablen über #... zugreifen und ebenso direkt auf das DIW zugreifen. Wenn also deine Bits im Instanz-DB die Bits 100.0, 100.1, 100.2 .... belegen solltest du sie alle mit L 0 T DIW 100 loschen können. Hab das auch noch nie so gemacht, probiers doch mal aus.


----------



## Unregistrierter gast (9 Februar 2007)

Ralle schrieb:


> Mit dem Array, das geht so nicht, glaube ich jedenfalls  .
> 
> Alle INPUT, OUTPUT etc. sind doch im Instanz-DB enthalten.
> 
> Du kannst einmal auf die definierten Variablen über #... zugreifen und ebenso direkt auf das DIW zugreifen. Wenn also deine Bits im Instanz-DB die Bits 100.0, 100.1, 100.2 .... belegen solltest du sie alle mit L 0 T DIW 100 loschen können. Hab das auch noch nie so gemacht, probiers doch mal aus.



Bei direktem Zugriff auf Instanzdaten gibts aber den unschönen Effekt, das bei Änderungen des FB (z.B. neuer Eingangsoperand) sich alle darauf folgenden Adressen verschieben...

Das sind dann die direkten Zugriffe auch alle falsch...


----------



## Ralle (9 Februar 2007)

@ug

Richtig, man kann ebend nicht alles haben.  Gibt ja vielleicht noch eine schönere Methode, kenne aber im Moment nichts anderes.

Ich mag Instanz-DB genau aus diesem Grund überhaupt nicht. Auch eine Fehlersuche in Multiinstanzen mit mehreren FB-Aufrufen (möglichst noch die gleichen FB) ist ein super Katastrophen-Szenario.
Man könnte natürlich die betreffenden Daten in einem extra DB ablegen, jeder Aufruf des FB bekommt noch zusätzlich diesen DB mit. In dem kann man dann ohne Angst vor Verschiebungen arbeiten.


----------



## rs-plc-aa (9 Februar 2007)

Genau um das zu verhindern möchte ich es ja so machen...

Der DB100 ist nicht mein InstanzDB sondern ein Global DB der quasi ein Abbild der Struktur enthält.

Im FB selbst wird nur auf die in der Schnittstelle deklarierten Variablen zugegriffen. Diese Variablen werden von aussen beim Aufruf im OB versorgt.

Wenn an der Schnittstelle des FB was geändert wird so hat das keine Auswirkung aud den GlobalDB da im OB bei der Deklaration "nur" eine Lücke entsteht die dann wieder versorgt werden muss.

Auch möchte ich von anderen Bausteinen aus auf diese Daten zugreifen daher halte ich es für besser sie neutral zu speichern.

Bei Lese+Schreibzugriff sind das natürlich Durchgangsparameter.

Worauf ich also hinaus möchte ist wie ich den GlobalDB strukturiere.

Hier können z.B. sehr wohl Lücken mit Dummys belegt werden um später an einer bestimmten Stelle was einfügen zu können.

Zur besseren Übersicht habe ich schon Unterstrukturen erstellt aber immer bleibt das Problemchen übrig daß es keine Möglichkeit gibt eine "Gruppe" von Bits noch mal mit einer übergeordneten DWORD-Variable zu definieren --> ausser eben vielleicht mit einem Array - und das weiss ich nicht wie man eines erstellt das so aussieht:


```
+0.0 Array1 DWORD [adressiert von 0.0-3.7]
 +0.0 Bit0 BOOL
 +0.1 Bit1 BOOL
...
 +3.7 Bit32 BOOL
 
+4.0 Array2 DWORD [adressiert von 4.0-7.7]
 +4.0 Bit33 BOOL
...
```


----------



## Unregistrierter gast (9 Februar 2007)

rs-plc-aa schrieb:


> Auch möchte ich von anderen Bausteinen aus auf diese Daten zugreifen daher halte ich es für besser sie neutral zu speichern.



Das ist IMHO ein vernünftiger Gedanke.




rs-plc-aa schrieb:


> Worauf ich also hinaus möchte ist wie ich den GlobalDB strukturiere.



Knapp gesagt: gar nicht !
Welche Struktur sollte er denn haben ?
Die der FB ist doch unnötige Arbeit.

Setzt die Struktur des Global DB so, wie es für das Programmverständniss am sinnvollsten ist, eigendlich "frei Schnautze".

Wenn du deine Parameter über Globalen DB (oder auch Merkerbereich...) anbindest, dann hast du ja den Vorteil der "wilkürlichen" Variablenbelegung.

Du kannst z.B. einen DB-Bereich für einen Anlagenteil nehmen.

Lass etwas Reserve zwischendrinn, und die Sache passt.

Die Globalstruktur an die FB - Struktur anzupassen macht IMHO keinen Sinn!
Dann kann man den GlobalDB ja gleich weg lassen....


----------



## rs-plc-aa (9 Februar 2007)

Ja, hast wohl recht...

Den GlobalDB erzeuge ich aus Excel heraus ziemlich komfortabel daher ist auch ruck zuck was geändert.

Auch kann ich eigentlich alles machen - ich habe mich vielleicht auch nur zu sehr an dem einen Detail aufgehalten den Zugriff auf die Einzelbits per Alias zu erledigen.

Jetzt steht halt im OB so was in der Art:


```
CALL  "Hauptprogramm" , "DI_FB410_M1"
...
       PrgControl_1            :=DB611.DBD12
       PrgControl_2            :=DB611.DBD16
       Merker_NotAus           :="Merkerbits_M1".PrgControl_1.Merker_NotAus
       Merker_NormalAus        :="Merkerbits_M1".PrgControl_1.Merker_NormalAus
...
```
 
... und anstatt DB611.DBD12 wollte ich eben so was wie "Merkerbits_M1".PrgControl_1 da dran stehen haben.

Und ausserdem hätte mich eben generell interessiert ob das mit einem Array gegengen wäre...


----------



## Unregistrierter gast (9 Februar 2007)

rs-plc-aa schrieb:


> ... und anstatt DB611.DBD12 wollte ich eben so was wie "Merkerbits_M1".PrgControl_1 da dran stehen haben.
> 
> Und ausserdem hätte mich eben generell interessiert ob das mit einem Array gegengen wäre...



Die Symbolische Adresse kann nicht überlappen.
Da helfen leider auch Tricks mit Arrays oder structs nicht.

Vielleicht in einer der nächsten S7 - Versionen.
Ist nur ein S7Manager - Problem, hat mit dem eigendlichen Programm ja nichts zu tun.


----------



## Onkel Dagobert (9 Februar 2007)

rs-plc-aa schrieb:


> ... und anstatt DB611.DBD12 wollte ich eben so was wie "Merkerbits_M1".PrgControl_1 da dran stehen haben.
> 
> Und ausserdem hätte mich eben generell interessiert ob das mit einem Array gegengen wäre...


Mit einem ARRAY geht das so nicht. Aber versuche es mal mit dem Datentyp UDT, das sollte gehen!


Gruß, Onkel


----------



## rs-plc-aa (9 Februar 2007)

schade...

hätte dann nämlich noch den Vorteil gehabt daß wenn im global DB was eingefügt wird die Zuordnung immer noch primär über den Alias anstatt der Adresse stattgefunden hätte...

Aber wie schon gesagt wurde es gibt halt keine Lösung die nur Vorteile bietet.

Wobei ich es hier wiederum ja gar nicht mit einem "echten" Nachteil zu tun habe da ja das was ich machen wollte in der anderen Variante auch nicht geht


----------



## Unregistrierter gast (9 Februar 2007)

Onkel Dagobert schrieb:


> Mit einem ARRAY geht das so nicht. Aber versuche es mal mit dem Datentyp UDT, das sollte gehen!
> 
> 
> Gruß, Onkel



Geht auch mit UDT nicht.


----------



## rs-plc-aa (9 Februar 2007)

Onkel Dagobert schrieb:


> ... Aber versuche es mal mit dem Datentyp UDT, das sollte gehen!


 
Zitat UG:


> Geht auch mit UDT nicht.


 
Ich gebs auf


----------



## Onkel Dagobert (9 Februar 2007)

Unregistrierter gast schrieb:


> Geht auch mit UDT nicht.


Ich meinte auch nur das hier:



rs-plc-aa schrieb:


> ...
> 
> 
> 
> ...


Mit dem "symbolischen Überlappen heht es nicht. Jedoch könnte man eventuell zum Überschreiben die SFC "Fill" verwenden.


Gruß, Onkel


----------



## rs-plc-aa (9 Februar 2007)

Onkel Dagobert schrieb:


> Ich meinte auch nur das hier:
> 
> Mit dem "symbolischen Überlappen heht es nicht. Jedoch könnte man eventuell zum Überschreiben die SFC "Fill" verwenden.
> 
> ...


 
Aber der SFC "Fill" muß ich ja auch wieder sagen was sie "fillen" soll --> also DB611.DBD12 z.B. kommt ja dann aufs gleiche raus...


----------



## Onkel Dagobert (9 Februar 2007)

rs-plc-aa schrieb:


> Aber der SFC "Fill" muß ich ja auch wieder sagen was sie "fillen" soll --> also DB611.DBD12 z.B. kommt ja dann aufs gleiche raus...


Verstehe ich nicht so ganz. Du kannst doch die Parameter symbolisch verwenden. So etwa:


```
//*** TESTARRAY ist IN-Parameter
      U     #TESTARRAY[1]
      =     A      0.0
      L     0
      T     #TEMP_BYTE
      CALL  SFC   21
       BVAL   :=#TEMP_BYTE
       RET_VAL:=#TEMP_INT
       BLK    :=#TESTARRAY
 
//*** TESTUDT ist IN-Parameter
      U     #TESTUDT.Bit_0
      =     A      0.0
      L     0
      T     #TEMP_BYTE
      CALL  SFC   21
       BVAL   :=#TEMP_BYTE
       RET_VAL:=#TEMP_INT
       BLK    :=#TESTUDT
```
 
Wahrscheinlich ist es aber ohnehin besser, du baust dein Programm vollkommen neu auf.


Gruß, Onkel


----------



## Unregistrierter gast (9 Februar 2007)

Onkel Dagobert schrieb:


> Verstehe ich nicht so ganz. Du kannst doch die Parameter symbolisch verwenden. So etwa:
> 
> 
> ```
> ...



Das wäre aber doch etwas viel Aufwand für ein "bischen Symbolik" oder ?


----------



## Onkel Dagobert (9 Februar 2007)

Unregistrierter gast schrieb:


> Das wäre aber doch etwas viel Aufwand für ein "bischen Symbolik" oder ?


Allerdings! Und dann kommen ja wahrscheinlich noch andere Dinge wie S5-Timer usw. hinzu.


----------



## rs-plc-aa (9 Februar 2007)

Das Programm baue ich ja neu auf - Logik bleibt (da ja getestet); Struktur wird neu...

Den geposteten Code musst du mal genauer erklären.

Ich gehe davon aus daß er sich im FB befindet.

Wo ist Testarray bzw. TestUDT definiert ?

Ich mache das gerade so dass im FB eine DWORD Variable existiert die ich mit 0 überschreibe (bei Bedarf). Die Verbindung zwischen der DWORD Var und den tatsächlich betroffen 32 Bits (die ich mit der Aktion clearen möchte) stellt der Aufruf im OB her --> Siehe Beitrag mit Auszug vom Aufruf...

Die DWORD Variable ist dann zwar zusätzlich (und unnötig) im Instanzdatenbaustein vorhanden (verbraucht Speicherplatz) ist aber dafür ohne was umbiegen zu müssen für jede Instanz des FB verwendbar (da der Bezug ja beim Aufruf hergestellt wird).

Wenn du [@Onkel D bzw. alle anderen natürlich auch] mir jetzt erklären kannst wie ich in meinem Global DB ein Array bzw. einen UDT definieren kann den ich von aussen als 32-bit Variable ansprechen kann und gleichzeitig die selbe Startadresse hat wie die 32 Bits die ich damit bei Bedarf löschen will dann habe ich ganau das gefunden was ich suche.


----------



## Onkel Dagobert (9 Februar 2007)

Sieh dir dazu bitte den folgenden link an. Er führt zu einem ausführlichen Beispiel zur Verwendung eines UDT als Bausteinparameter.

http://support.automation.siemens.com/WW/view/de/11302987


Gruß, Onkel


----------



## Ralle (9 Februar 2007)

Das mit den UDT ist schon gut, aber dann kann er trotzdem nicht Bits und Word eines Adressbereiches symbolisch nutzen.


----------



## Unregistrierter gast (9 Februar 2007)

Ralle schrieb:


> Das mit den UDT ist schon gut, aber dann kann er trotzdem nicht Bits und Word eines Adressbereiches symbolisch nutzen.



Er kann aber den ganzen UDT symbolisch an eine Funktion übergeben und gleichzeitig auf die einzelnen Elemente Symbolisch zugreifen.


----------



## Ralle (9 Februar 2007)

@ug

Klar kann er das, aber ich hatte das so verstanden, daß er auf einzelne Bits zugreifen will und dann alle Bits mit einem Mal löschen, indem er das Word mit 0 beschreibt. Da hilft ihm auch die schick anparametrierte UDT nicht weiter.


----------



## rs-plc-aa (9 Februar 2007)

Ok, ich hab grad gesehen dass ich dann auch den Komfort verlieren würde mir den GlobalDB aus Excel heraus erstellen zu können da hier keine UDTs möglich sind...

Des weiteren würde es die Sache (nach dem ich den Siemens Beitrag gelesen habe) noch mehr verkomplizieren -> dann lieber im OB die direkte Adresse hinschreiben (kommt pro Aufruf 8 mal vor - geht schon...)

Ich bin aber gerade auf ein ganz anderes Problem gestossen.

Ich habe im FB diverse Timer als IN-Parameter definiert wovon ein paar an Unterprogramme weitergegeben werden müssen.

Ich würde ja nicht so dumm fragen aber mit der "alten" Struktur ging das dass der Timer als z.B. T 37 im Haupt- sowie im Unterprogramm angegeben wurde.

Nun habe ich im ersten Unterprogramm ebenfalls einen IN-Parameter definiert an den dann der ehemalige T 37 weitergereicht werden soll --> geht nicht !

"Unzulässige Parameterversorgung" sagt mir Step7.

Und jetzt ? Direkt geht indirekt nicht 

Auf SFB-Timer "umbauen" kommt jedenfalls nicht gleich in Frage
(schwierig zum Testen in dem Zustand - dann lieber das wo schon funktioniert hat)

Edit:
In der Hilfe zur Meldung steht:
-------------------------------------------------------------------------------------------------
Beschreibung:
Obwohl kein Typkonflikt zwischen Aktualparameter (rechte Seite) und Formalparameter (linke Seite) vorliegt, kann diese Parameterzuweisung nicht zugelassen werden. Folgende Gründe können vorliegen:

· Die Zuweisung ist aus technischen Gründen nicht möglich, z.B. kann keine STRING- oder DATE_AND_TIME-Konstante als Aktualparameter verwendet werden (zu viele Einzelbefehle).

· Das Maschinenmodell STEP 7 erlaubt die Zuweisung nicht, z.B. kann ein STRUCT/ARRAY/ANY/UDT/STRING - INPUT/OUTPUT/IN_OUT - Parameter eines FCs nicht an einen darin aufgerufenen Baustein weitergereicht werden.

· Ihr Formalparameter trägt ein S7_server Attribut und läßt daher die entsprechende Versorgung nicht zu, da z.B. der Aktual Parameter vom Server selbst vergeben werden muß oder lokal versorgt werden soll.

Behebung:

Bitte passen Sie Ihren Bausteinaufruf entsprechend diesen Regeln an.

--------------------------------------------------------------------------------------------
Anmerkung: Das "Durchreichen" hat aber mit allem anderen einschließlich #S5Time bis jetzt geklappt...


----------



## Ralle (9 Februar 2007)

Man könnte das so machen:


```
L     10  //die Timernummer kann man natürlich per INPUT übergeben
      T     MW     2

      U     E      0.0  //nur zum Testen
      L     S5T#20MS
      SE    T [MW 2]
```
Du könntest dann evtl. darauf verzichten Timer anzuparametrieren, sonder nur die Timernummer übergeben.
Leider nimmt er nur MW/DBW keine FC/FB-Parameter, vielleicht weiß jemand dafür auch noch etwas?


----------



## rs-plc-aa (10 Februar 2007)

Es funktioniert !

habe es sogar noch relativ elegant hinbekommen...

Ich versorge am Eingang des FB den Timer (da muss ich die Nummer sowieso hinschreiben) und zusätzlich die Nummer noch mal extra (eine Zeile weiter unten = übersichtlich).

Dann übergebe ich dem Unterprogramm nur die Nummervariable.

Im Unterprogramm (FC) selbst sieht das dann so aus daß die Eingangsvariable in den Temp-Bereich zwischengespeichert wird da ja, wie Ralle schon erkannt hat, keine direkte zuordnung möglich ist.


```
// Timer Nummern versorgen
      L     #tNr_GasvDichthPruef_In  // IN
      T     #tNr_Intervall                // Temp
      L     #tNr_GasvDichthPruef_Pr
      T     #tNr_Pruefung
...
 
      SE    T [#tNr_Pruefung]           // #tNr_GasvDichthPruef_Pr
...
```
 
sieht doch gut aus oder ?

Jetzt kann ich diese Vorgehnsweise für die restlichen Unterprogramme ebenfalls übernehmen und habe ein Problem weniger...

Danke euch !


----------



## Ralle (10 Februar 2007)

Die Temp-Var kann man also ohne Probleme  in die eckigen Klammen des Timers eintragen? Warum das wohl nicht mit in Input-Var geht, weiß wohl nur Siemens.


----------



## rs-plc-aa (10 Februar 2007)

... anscheinend ja


----------

