TIA UC Aufruf in SCL?

[Black_Eagle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich stehe vor dem Problem das in einer 1500er keine UC Aufrufe mehr machen kann wie ich es in einer 300er konnte.
Folgendes Szenario habe ich:
In der 300er gibt es von uns Bausteine die eine TCP Verbindung aufgebaut haben und an bestimmten Punkten (Verbindung wurde aufgebaut/abgebaut oder Daten wurden empfangen) einen UC Aufruf ausgeführt haben um zu diesem Zeitpunkt irgendwelche Aktionen auszuführen.
Beispielsweise wurde beim Empfang von Daten ein FC aufgerufen der dann den Empfangspuffer ausgewertet und verschiedene weitere Aktionen erledigt hat. (Bild 1)

Die Nummer des FCs der beim Eingang von Daten ausgeführt werden sollte konnte von außen per INT angelegt werden. Somit hatten wir eine hohe Flexibilität (wenn ich Daten von einem Scanner bekomme habe ich einen anderen FC der mir die auswerten soll wie wenn ich Daten von einem Leitrechner bekomme etc.)

Dies ist so nun nicht mehr möglich. Ich kann den UC Aufruf zwar immer noch ausführen nur müssen dann die Bausteine die damit aufgerufen werden immer in AWL sein und das ist was uns angeht nicht praktikabel (die meisten Baustein die bei einem Event aufgerufen werden sind FCs die in SCL geschrieben sind)

Nun meine Frage. Gibt es eine Möglichkeit einen UC Befehl (oder einen irgendwie gearteten) in SCL zu integrieren, damit wir weiterhin von außen ein INT anlegen können und dieser FC dann beim erfolgen des Event aufgerufen wird?

 

[Mediator]

So etwas kann man z.B. mit einer CASE-Anweisung programmieren: http://de.wikipedia.org/wiki/Strukturierter_Text

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Programmiere eine FC ("Test_UC_AWL") in AWL, der enthält:

L     #Nummer    //Input-Var
T     #Nummer_Temp    //Temp-Var Word
UC FC [ #Nummer_Temp]

Diesen kannsz du dann in SCL aufrufen:

"Test_UC_AWL"(#MyNummer);

Was das gemeint?

 

[Black_Eagle]

Hallo,

Programmiere eine FC ("Test_UC_AWL") in AWL, der enthält:

L     #Nummer    //Input-Var
T     #Nummer_Temp    //Temp-Var Word
UC FC [ #Nummer_Temp]

Diesen kannsz du dann in SCL aufrufen:

"Test_UC_AWL"(#MyNummer);

Was das gemeint?

Das geht leider nur wenn es durchgängig AWL Bausteine sind. Weil nur bei denen kann man in der 1500er das Attribut "Parameterversorgung über Register" aktivieren. Wenn der aufzurufende Baustein aber in SCL ist (was bei uns zu 90% der Fall ist) geht es nicht.
Habe ich dann auch in der Doku für die Migration von AWL gefunden.

Die Case Anweisung ist prinzipell eine gute Idee nur muß ich diese dann jedes Mal wenn ein neuer Baustein dazukommt erweitern. Das wollte ich mir ersparen.

 

[Ralle]

Ah, ich hab das eh bei einer 300-er getestet, aber da geht das ja alles.
Bei der 1500-er ist das wieder anders ... oh Mann.
Deshalb hätte ich gerne, daß man sich die Variablen zur Laufzeit (auch für FC) zusammensetzen kann, dann erst kann man vernünftig durchgängig symbolisch programmieren.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Muß das dann bis zur untersten Verschachtelungsebene AWL sein oder nur der durch UC aufgerufene Bausteine?
Falls letzteres, macht Euch doch einfach einen "Wrapper"-Baustein: AWL, der nichts anderes macht, als einen bestimmten Baustein aufzurufen.
Also bspw. FC1000 willst Du aufrufen und FC2000 ruft den als AWL auf. Dann hast Du zwar für jeden Aufruf zwei Bausteine, es würde aber funktionieren...

 

[Black_Eagle]

Ja das muß bis ganz runter AWL sein. Das ist das Problem.
Weil nur bei AWL Bausteinen das nötige Attribut des Bausteins aktiviert werden kann damit es geht

 

[JSEngineering]

Bist Du ganz sicher?

Laut Siemens-Dokument http://support.automation.siemens.c...1500_d.pdf?func=cslib.csFetch&nodeid=68181316

Die Werte aus Registern, Akkumulatoren und dem Statuswort werden grundsätzlich
nicht an aufgerufene Bausteine übergeben. Eine Ausnahme besteht nur bei den
Anweisungen "CC" und "UC". Wenn Sie "UC" oder "CC" verwenden und dem
aufgerufenen Baustein Parameter über Register, Statuswort oder Akkumulatoren
übergeben möchten, müssen Sie in den Eigenschaften des aufgerufenen Bausteins die
Option "Parameterversorgung über Register" aktivieren. Beachten Sie, dass diese
Option nur für AWL-Bausteine mit Standardzugriff zur Verfügung steht und der Baustein
keine Formalparameter haben darf. Wenn die Option aktiviert ist, können Sie
Registerinhalte zwischen Bausteinen übergeben.

muß ich die Option nur aktivieren, wenn ich Parameter übergeben möchte - und die kann man ja notfalls über einen DB austauschen!?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Deshalb hätte ich gerne, daß man sich die Variablen zur Laufzeit (auch für FC) zusammensetzen kann, dann erst kann man vernünftig durchgängig symbolisch programmieren.

Bei der 1500 ist das leider in Ansätzen möglich. Meiner Meinung nach ist so eine Funktion das was man NICHT in einem SPS-Programm haben will. Mal angenommen du setzt einen Variablennamen aus einzelnen Strings zusammen:
wasauchimmer := INT_TO_STRING(intVar);
varname := CONCAT(IN1:='MeinDBfuer', wasauchimmer);

Dann wird bei einer Namensänderung nichts an der Symbolik automatisch korrigiert, bei jedem Zugriff musst du eine Fehlerprüfung machen ob der Name überhaupt vorhanden ist. Und sowas ist Ressourcenverschwendung hoch 100. In einem SPS-Programm ist das eine größere Schmiererei als die S5-Schmiermerker.
C, C++, Pascal und Konsorten kommen auch ohne Reflektion aus. Nur weil Siemens der 1500 keine vernünftigen Zeiger spendiert muss man zu so einem Unfug greifen.

 

[Ralle]

Bei der 1500 ist das leider in Ansätzen möglich. Meiner Meinung nach ist so eine Funktion das was man NICHT in einem SPS-Programm haben will. Mal angenommen du setzt einen Variablennamen aus einzelnen Strings zusammen:
wasauchimmer := INT_TO_STRING(intVar);
varname := CONCAT(IN1:='MeinDBfuer', wasauchimmer);

Dann wird bei einer Namensänderung nichts an der Symbolik automatisch korrigiert, bei jedem Zugriff musst du eine Fehlerprüfung machen ob der Name überhaupt vorhanden ist. Und sowas ist Ressourcenverschwendung hoch 100. In einem SPS-Programm ist das eine größere Schmiererei als die S5-Schmiermerker.
C, C++, Pascal und Konsorten kommen auch ohne Reflektion aus. Nur weil Siemens der 1500 keine vernünftigen Zeiger spendiert muss man zu so einem Unfug greifen.

Ja da hast du Recht, aber wenn man unbedingt ausschließlich vollsymbolisch programmieren will, dann eben richtig und nicht nur halb. Oder man läßt eben eine vernünftige ind. Adressierung zu, aber wie geht das dann?

 

[Thomas_v2.1]

Ja da hast du Recht, aber wenn man unbedingt ausschließlich vollsymbolisch programmieren will, dann eben richtig und nicht nur halb. Oder man läßt eben eine vernünftige ind. Adressierung zu, aber wie geht das dann?

Symbolnamen zur Laufzeit aus Strings zusammenzusetzen hat mit symbolischer Programmierung aber nicht viel zu tun.
Die neuen Steuerungen bei Siemens sind irgendwie konzeptlos. Man vermeidet Zeiger wie der Teufel das Weihwasser, stellt dann fest dass man in der Realität bei Low-Level Programmierung mit Bitgeschiebe wie es in der SPS vorkommt ohne etwas ähnliches nicht auskommt, und muss dann halbgare andere Lösungen nachschieben.

In diversen anderen Sprachen, sogar in einigen Pascal Versionen (Lazarus), gibt es dafür Funktionszeiger. Das Prinzip ist einfach aber leistungsfähig. Der Parametertyp BLOCK_FC bei der S7-300/400 ist so etwas, nur war damit keine Parameterübergabe möglich und nur in AWL verwendbar. Und eine Funktion ohne Parameter ist nicht wirklich sinnvoll nutzbar.