TIA symbolisch auf Variablen zugreifen (per STRING)

Zuviel Werbung?
-> Hier kostenlos registrieren
Nur so rein Interesse halber.

Gibt es überhaupt ein SPS System das zur Laufzeit dynamische eine symbolische Adresse verarbeiten kann? Innerhalb der IEC 61131-3 Sprachen ?
 
Dann könnte man ja wieder mit Fremdvisusystemen auf symbolische (optimierte) DBs zugreifen, und genau das wollte ja Siemens mit dieser ganzen Geschichte verhindern... Also selbst wenns theoretisch irgendwie gehen würde, wird Siemens da sicherlich nen Riegel vorgeschoben haben...

Aber solange kein Kunde von mir unbedingt optimierte DBs für die Visukopplung vorschreibt, hab ich bisher kein Problem mit nichtoptimierten DBs...

Wie ich früher schon mal schrieb, ich bevorzuge eine klar definierte und am Anfang des Projektes abgestimmte Schnittstelle zwischen Visu und SPS. (ausser bei PCS7 bzw. CFC mit ASOS-Übersetzten, aber davon ist TIA ja noch weit entfernt.)

Also für mich eher alles politische/komerzielle Argumente, eninfacher und übersichtlicher wird dadurch garnix...

Gruß.

Das geht mit dem OPC-Server von Schneider
http://blog.wonderware.com/2016/01/siemens-direct-operations-integration.html
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich wünschte mir schon einen echt Symbolischen zugriff von HMI oder auch von anderen SPSen aus.

Dann könnte man ja wieder mit Fremdvisusystemen auf symbolische (optimierte) DBs zugreifen, und genau das wollte ja Siemens mit dieser ganzen Geschichte verhindern... Also selbst wenns theoretisch irgendwie gehen würde, wird Siemens da sicherlich nen Riegel vorgeschoben haben...

Hallo,

mit dem Schneider OPC-Server geht genau das, symbolischer Zugriff auf optimierte Bausteine.
OI-Server

Gruß Björn
 
Hi

GetSymbolName(#para_n) liefert den Namen der Variablen, die den Parameter #para_n versorgt hat. Dazu legt Siemens alle potentiell für diese Funktion in Frage kommenden Symbolnamen im Programm ab. Das Programm wird dadurch größer und langsamer.

Beispiel: Gegeben ein FC_X mit einem Parameter in1. FC_X enthält noch kein GetSymbolName. Dieser FC_X wird vom FC_Y aufgerufen. So in der Art CALL FC_X(in1:="eineVariableMitEinemGanzLangenNamen"); . Sagen wir mal in FC_Y ist sonst nix drin. Damit ergibt sich für den FC_Y ein bestimmter Arbeitsspeicherbedarf, z.B. 50 Byte (ich habe die genaue Zahl nicht mehr im Kopf).
Nun füge ich im FC_X ein GetSymbolName(#in_1) ein. Beim Übersetzen wird FC_Y ebenfalls übersetzt, obwohl ich gar nix dran verändert habe. Und was mich zu Anfangs doch sehr erschreckt hat, FC_Y ist auch noch deutlich größer geworden ... 200Bytes.
Daraus ziehe ich den Schluss, dass die von GetSymbolName erforderliche Info vom Aufrufer zur Verfügung gestellt wird. Das Einfügen von GetSymbolName bewirkt eine unsichtbare Änderung der Schnittstelle.

Wie sollte es aber auch anders sein? Wenn es auch noch einen FC_Z gibt, der ebenfalls ein CALL FC_X(in1:="eineAndereVariableMitEinemGanzLangenNamen"); enthält, dann kann man das schlecht dem FC_X aufbürden. Der weiß weder was von" eineVariableMitEinemGanzLangenNamen" noch von "eineAndereVariableMitEinemGanzLangenNamen" und muss auch nicht übersetzt werden wenn in den Aufrufern was geändert wird. So weit so gut.
GetSymbolPath arbeitet genauso, macht jedoch eine Signalverfolgung über mehrere Ebenen hinweg. D.h. der Aufrufer des Aufrufers des Aufrufers ... ist betroffen. Technisch ist dem nichts entgegen zusetzen. Symbolinformation kostet Zeit und Speicher. Aber nur, wenn man GetSymbolName auch verwendet. Sonst übersetzt TIA so wie sich das für einen Compiler gehört. Prozessoren arbeiten eben lieber mit Adressen denn mit Symbolen.

Ich frage mich wozu Siemens GetSymbol wirklich eingebaut hat.

Was hier gefragt wird, müsste dann wohl GetValueOfSymbol(#aSymbolString) heißen. Das gibt es nicht. Und überlegt mal was Siemens dann wohl machen müsste. Die Namen und Adressen aller im Programm vorhandenen Symbole müssten dem Programm zur Verfügung stehen. D.h. das alle -- immer alle! -- Symbole im Arbeitsspeicher landen. Ich schätze mal, dann braucht so ein Programm locker das doppelte an Arbeitsspeicher. Den Zugriff stelle ich mir als binäre Suche in einem sehr großen Baum vor. Das kann trotzdem dauern.

Wozu braucht man das? Und will man diese Kosten dann auch tragen?

'n schön' Tach auch
HB
 
Zuletzt bearbeitet:
Hallo,

mit dem Schneider OPC-Server geht genau das, symbolischer Zugriff auf optimierte Bausteine.
OI-Server

Gruß Björn

Naja... wenn ich das richtig verstanden habe, greifen diese Treiber nicht direkt sybolisch auf die Daten zu, sondern lesen vorher die "Symboltabelle" vorher ein* und greifen dann "nicht Symbolisch" auf die Daten zu.

* Wonderware bzw. WinCC 7.4 holt die aus der 1500er Steuerung, Deltalogic aus dem TIA Projekt...

So hab ich's zumindest verstanden:

Auto-synchronizes symbolic tag databases when tags are changed or uploaded to the controller

Gruß.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Naja... wenn ich das richtig verstanden habe, greifen diese Treiber nicht direkt sybolisch auf die Daten zu, sondern lesen vorher die "Symboltabelle" vorher ein* und greifen dann "nicht Symbolisch" auf die Daten zu.

* Wonderware bzw. WinCC 7.4 holt die aus der 1500er Steuerung, Deltalogic aus dem TIA Projekt...

So hab ich's zumindest verstanden:



Gruß.


Doch, der Zugriff funktioniert komplett symbolisch ohne das TIA-Projekt. Das einzige was benötigt wird ist die IP-Adresse der Steuerung.
Anschließend kann man im Scada (bei uns Intouch) eine Variable auf DBName.VarName projektieren und man bekommt den Wert.

Gruß Björn
 
Doch, der Zugriff funktioniert komplett symbolisch ohne das TIA-Projekt. Das einzige was benötigt wird ist die IP-Adresse der Steuerung.
Anschließend kann man im Scada (bei uns Intouch) eine Variable auf DBName.VarName projektieren und man bekommt den Wert.

Gruß Björn

So ganz kann ich das nicht glauben. Wieso muss ich dann mein WinCC Projekt nicht mehr neu Laden wenn ich den Namen einer Variable in der SPS ändere.
Auch der Programmierlaeitfaden sagt hier was anderes, siehe Anhang. Wie z.B. "Die Länger der Variable beeinflusst nicht die Kommunikationslast zwischen Steuerung und HMI"
 

Anhänge

  • ID.pdf
    281,5 KB · Aufrufe: 11
So ganz kann ich das nicht glauben. Wieso muss ich dann mein WinCC Projekt nicht mehr neu Laden wenn ich den Namen einer Variable in der SPS ändere.
Auch der Programmierlaeitfaden sagt hier was anderes, siehe Anhang. Wie z.B. "Die Länger der Variable beeinflusst nicht die Kommunikationslast zwischen Steuerung und HMI"

Weil der Wonderware-Treiber anders funktioniert als die Siemens WinCC Varianten.
Der Intouch-Treiber durchsucht den gesamten Variablenhaushalt der SPS in der SPS nach dem angegebenen Symbol, und extrahiert daraus die notwendigen IDs. Der Variablenzugriff später erfolgt dann nur über die IDs, und diese haben immer die gleiche Länge.
Theoretisch wäre es jetzt möglich, wenn der Treiber feststellt dass seine ID in der SPS ungültig ist, er die ID aus dem Variablenhaushalt online aktualisiert. Ich weiß nicht ob der von Wonderware das automatisch macht, möglich wäre es, solange Symbolname und Datentyp gleich bleiben. Normalerweise sollte sich die ID aber nicht ändern, solange du nicht an den Datentypen etwas änderst, und dann wieder auf den ursprünglichen zurückänderst. So ganz stabil scheint diese ID-Vergabe aber nicht zu sein, außerdem kommt es bei TIA auch gerne mal vor, dass das Programm abstürzt.

Die Siemens TIA-WinCC Varianten (bis auf WinCC 7.3/7.4) lesen diese IDs immer aus dem Offline-Projekt. Darum musst du selber die WinCC Version aktualisieren, d.h. das Projekt übersetzen und neu laden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Doch, der Zugriff funktioniert komplett symbolisch ohne das TIA-Projekt. Das einzige was benötigt wird ist die IP-Adresse der Steuerung.
Anschließend kann man im Scada (bei uns Intouch) eine Variable auf DBName.VarName projektieren und man bekommt den Wert.

Gruß Björn

Naja, wie Thomas schon schrieb:

Die Zuordnung Symbol-> ID holt sich Intouch aus der 1500er... der Zugriff auf die Daten erfolgt dann nicht mehr über das Symbol, sondern über die ID...

Zur Aktualisierung schreibt Intouch

Auto-synchronizes symbolic tag databases when tags are changed or uploaded to the Controller

wie auch immer das dann funktioniert, vermutlich merkt der Intouch Treiber, dass sich was geändert hat, und lädt die Zuordnung Symbol-> ID neu.

Gruß.
 
Weil der Wonderware-Treiber anders funktioniert als die Siemens WinCC Varianten.
Der Intouch-Treiber durchsucht den gesamten Variablenhaushalt der SPS in der SPS nach dem angegebenen Symbol, und extrahiert daraus die notwendigen IDs. Der Variablenzugriff später erfolgt dann nur über die IDs, und diese haben immer die gleiche Länge.

Ob man sich darauf verlassen sollte das SIEMENS das Zugriffsverfahren genau so belässt und der Treiber kompatibel bleibt. Mir wäre das zu riskant.
 
Zurück
Oben