Dr. OPC
Level-1
- Beiträge
- 336
- Reaktionspunkte
- 68
-> Hier kostenlos registrieren
Nachdem ich einige Threads zu diesem Thema gelesen habe hier die Klarstellung, wie es wirklich ist:
Der Unterschied zwischen "direkten Addressen", "Alias-Namen" und "Symbol-Namen" aus Sicht des SimaticNET OPC Servers.
Nach der Installation ist der OPC Server "doof", er weiß nicht mit wem er sich verbinden soll und Tags kennt er auch keine (ausser einigen internen "Systemvariablen" zu erkennen am vorangestellem "&")
Wenn der Server mit NCM (Netpro) konfiguriert wurde, weiss er zumindest wohin er sich verbinden soll falls er irgendwann mal von einen Client gestartet wird. Hier wird also die z.B. S7-Verbindung zu einer SPS konfiguriert und der OPC Server weiss dann unter welcher z.B. IP er diese SPS erreichen kann. Dies ist sagen wir mal die "Protokoll- oder Treiberkonfiguration".
Nun weiss der OPC Server aber noch nicht welche Tags es in den SPSen gibt. Der "OPC-Addressraum" ist also leer. Trotzdem funktioniert der OPC Server aber schon und wenn man als ItemID (Tag-Name) eine direkte Addresse (in einer von Siemens für dieses Protokoll definierten Syntax) eingibt, kann man schon auf Daten in der SPS zugreifen.
Weil nun nicht jeder Client auf der Welt die Syntax von einem Item in einem x-beliebigen Server auswendig wissen kann, gibt es den Addressraum im Server. Diesen kann man als Client "erbrowsen" (durchnavigieren) und sich einen Überblick über die Items in dem Server verschaffen. Wenn man ein Item findet das einen Interessiert, fügt man es einer Gruppe hinzu und kann es dann lesen/schreiben/beobachten.
Wie der Addressraum eines Servers konfiguriert wird ist abhängig vom Hersteller. Beim SimaticNet Server kann man mit dem OPCScout AliasNamen für direkte Addressen vergeben (diese werden dann vom Server in einer txt Datei gespeichert und sind beim nächten Start oder auch für andere Clients sichtbar). Das ist ganz nett aber wenn sich in der SPS die Addresse ändert, zeigt der Alias auf den alten Wert und man muss die txt Datei aktualisieren. Deswegen sollte man hier immer von Alias sprechen und nicht von Symbolik. Dies ist sagen wir mal die "alte" Alias-Addressraumkonfiguration.
Eine Symboldatei ist eine (offline) Addressrauminformation die symbolische Namen in einer Hierarchie enthält, die der Server dann in direkte Adressen aufgelösen kann. Derartige Symboldateien (*.sti) kann man mit dem Symboldateikonfigurator selber anlegen oder bestehende Dateien bearbeiten. Auch hier besteht die Gefahr dass die Symboldatei irgendwann nicht mehr aktuell ist.
Um auch diese Problem in den Griff zu bekommen, kann die Symboldatei mit Step7 "generiert" werden. Dann ist sie immer so aktuell wie das Step7-Projekt. natürlich muss der OPC-Server in einer PC-Station zusammen mit den SPSen ein einem Projekt sein und es müssen die "S7-Verbindungen" zwischen OPC und SPS projektiert sein. In HW-Konfig kann man nun auf den OPC-Server doppeklicken und in der Lasche "S7" die Generierung der Symboldatei auswählen. Die Symboldatei enthält dann alle Symbole (aus der Step7-Symboltabelle) und alle symbolischen Namen die z.B. innerhalb von DBs vergeben wurden. Das ist dann auch konsistent zur tatsächlich verbundenen SPS (wenn man beide runterläd). Diese derart mit Step7 erzeugte Symboldatei wird beim "download" der PC Station (auch beim XDB-Datei Import) dem OPC Server übergeben. Dies ist dann sagen wir mal die Symbol-Addressraumkonfiguration.
So, und nun ist der OPC Server nicht mehr "doof" sondern bildet "exakt" die Daten der SPS in seinem Addressraum ab (reinbrowsen unter "SYM:").
Und das schöne daran ist, dass man dafür nichts extra tun muss. Auch ein schönes Feature ist, dass man selber konfigurieren kann welche Datenbausteine überhaupt in der Symboldatei erscheinen sollen (vielleicht will man den Clients nicht sein ganzes "Innenleben" preisgeben). Ausserdem kann man Zugriffsrechte (lesen/schreiben) für die Symbole vergeben.
Und nur um das nochmal klarzustellen: der OPC Server funktioniert auch ohne Addressraum, dann muss allerdings der Client die korrekte Syntax (ItemID) kennen um mit AddItem/Read/Write/DataChange arbeiten zu können (z.B. "S7:[S7Verbindung_1]DB1,B4,1" bezeichnet ein Byte im Datenbaustein 1, ab Offset 4 das in der SPS liegt, die sich hinter der "S7-Verbindung_1" verbirgt und zu der der OPC Server über das S7-Protokoll (Put/Get) kommuniziert).
Der Unterschied zwischen "direkten Addressen", "Alias-Namen" und "Symbol-Namen" aus Sicht des SimaticNET OPC Servers.
Nach der Installation ist der OPC Server "doof", er weiß nicht mit wem er sich verbinden soll und Tags kennt er auch keine (ausser einigen internen "Systemvariablen" zu erkennen am vorangestellem "&")
Wenn der Server mit NCM (Netpro) konfiguriert wurde, weiss er zumindest wohin er sich verbinden soll falls er irgendwann mal von einen Client gestartet wird. Hier wird also die z.B. S7-Verbindung zu einer SPS konfiguriert und der OPC Server weiss dann unter welcher z.B. IP er diese SPS erreichen kann. Dies ist sagen wir mal die "Protokoll- oder Treiberkonfiguration".
Nun weiss der OPC Server aber noch nicht welche Tags es in den SPSen gibt. Der "OPC-Addressraum" ist also leer. Trotzdem funktioniert der OPC Server aber schon und wenn man als ItemID (Tag-Name) eine direkte Addresse (in einer von Siemens für dieses Protokoll definierten Syntax) eingibt, kann man schon auf Daten in der SPS zugreifen.
Weil nun nicht jeder Client auf der Welt die Syntax von einem Item in einem x-beliebigen Server auswendig wissen kann, gibt es den Addressraum im Server. Diesen kann man als Client "erbrowsen" (durchnavigieren) und sich einen Überblick über die Items in dem Server verschaffen. Wenn man ein Item findet das einen Interessiert, fügt man es einer Gruppe hinzu und kann es dann lesen/schreiben/beobachten.
Wie der Addressraum eines Servers konfiguriert wird ist abhängig vom Hersteller. Beim SimaticNet Server kann man mit dem OPCScout AliasNamen für direkte Addressen vergeben (diese werden dann vom Server in einer txt Datei gespeichert und sind beim nächten Start oder auch für andere Clients sichtbar). Das ist ganz nett aber wenn sich in der SPS die Addresse ändert, zeigt der Alias auf den alten Wert und man muss die txt Datei aktualisieren. Deswegen sollte man hier immer von Alias sprechen und nicht von Symbolik. Dies ist sagen wir mal die "alte" Alias-Addressraumkonfiguration.
Eine Symboldatei ist eine (offline) Addressrauminformation die symbolische Namen in einer Hierarchie enthält, die der Server dann in direkte Adressen aufgelösen kann. Derartige Symboldateien (*.sti) kann man mit dem Symboldateikonfigurator selber anlegen oder bestehende Dateien bearbeiten. Auch hier besteht die Gefahr dass die Symboldatei irgendwann nicht mehr aktuell ist.
Um auch diese Problem in den Griff zu bekommen, kann die Symboldatei mit Step7 "generiert" werden. Dann ist sie immer so aktuell wie das Step7-Projekt. natürlich muss der OPC-Server in einer PC-Station zusammen mit den SPSen ein einem Projekt sein und es müssen die "S7-Verbindungen" zwischen OPC und SPS projektiert sein. In HW-Konfig kann man nun auf den OPC-Server doppeklicken und in der Lasche "S7" die Generierung der Symboldatei auswählen. Die Symboldatei enthält dann alle Symbole (aus der Step7-Symboltabelle) und alle symbolischen Namen die z.B. innerhalb von DBs vergeben wurden. Das ist dann auch konsistent zur tatsächlich verbundenen SPS (wenn man beide runterläd). Diese derart mit Step7 erzeugte Symboldatei wird beim "download" der PC Station (auch beim XDB-Datei Import) dem OPC Server übergeben. Dies ist dann sagen wir mal die Symbol-Addressraumkonfiguration.
So, und nun ist der OPC Server nicht mehr "doof" sondern bildet "exakt" die Daten der SPS in seinem Addressraum ab (reinbrowsen unter "SYM:").
Und das schöne daran ist, dass man dafür nichts extra tun muss. Auch ein schönes Feature ist, dass man selber konfigurieren kann welche Datenbausteine überhaupt in der Symboldatei erscheinen sollen (vielleicht will man den Clients nicht sein ganzes "Innenleben" preisgeben). Ausserdem kann man Zugriffsrechte (lesen/schreiben) für die Symbole vergeben.
Und nur um das nochmal klarzustellen: der OPC Server funktioniert auch ohne Addressraum, dann muss allerdings der Client die korrekte Syntax (ItemID) kennen um mit AddItem/Read/Write/DataChange arbeiten zu können (z.B. "S7:[S7Verbindung_1]DB1,B4,1" bezeichnet ein Byte im Datenbaustein 1, ab Offset 4 das in der SPS liegt, die sich hinter der "S7-Verbindung_1" verbirgt und zu der der OPC Server über das S7-Protokoll (Put/Get) kommuniziert).