TIA S7-1500 CPU nur als OPC Client

Marcelh.

Level-1
Beiträge
3
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

meine Anlage soll mit einem OPC Server kommunizieren.
Dafür habe ich einen eigenen DB angelegt, über denn kommunieziert werden soll.
Als Steuerung habe ich eine CPU 1515F-2PN verbaut mit einem KTP600 Basic color PN als Visualisierung.

Folgende Fragen habe ich nun:

1. Kann ich meine CPU auch nur als Client deklarieren oder geht generell nur als Server?
2. Wie kann ich meine restlichen DBs für den OPC-Server sperren, ohne das HMI auch nicht mehr darauf zugreifen kann?

mfg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
1. Kann ich meine CPU auch nur als Client deklarieren oder geht generell nur als Server?
2. Wie kann ich meine restlichen DBs für den OPC-Server sperren, ohne das HMI auch nicht mehr darauf zugreifen kann?

Ab FW 2.6 kann man auch OPC Client sein, dazu muss man nicht zwingend OPC Server aktivieren.
Grundsätzlich wird ein OPC Server nie auf einen Client zugreifen, dann ist es nämlich ein Server.
Wenn du aber deinen Server aktivierst dann kannst du DBs im ganzen für OPC UA Clienten unsichtbar machen (Rechtsklick auf DB -> Eigenschaften -> Attribute)
Du kannst aber nicht einzelne Teile des DBs für HMI Sichtbar und für OPC unsichtbar machen.
 
meine Anlage soll mit einem OPC Server kommunizieren.
Dafür habe ich einen eigenen DB angelegt, über denn kommunieziert werden soll.

1. Kann ich meine CPU auch nur als Client deklarieren oder geht generell nur als Server?
2. Wie kann ich meine restlichen DBs für den OPC-Server sperren, ohne das HMI auch nicht mehr darauf zugreifen kann?

Also zuerst mal OPC <> OPC-UA.
Brauchst du für die Anwendung überhaupt OPC-UA?
Herkömmliche OPC-Server holen die Daten aus dem Datenbaustein über das S7-Protokoll.
OPC-UA Client ist eigentlich auf der SPS-Seite (noch) ungewöhnlich.
Also vielleicht solltest du erst mal die Details abklären.

Gruß
Blockmove
 
Hallo,

unabhängig ob es gebraucht wird oder nicht - ich habe auch einen Anwendungsfall von OPC UA mit einer 1500er als Client (mit FW 2.6 und TIA V15.1).

Soweit alles konfigurierbar. Ich kann den OPC Server mit einem Client unter Windows erreichen (UAExpert), jedoch nicht mit der CPU (Fehlermeldung: Es wurde keine Anwendung für OPC UA-Server gefunden).

Hat da jemand vielleicht Erfahrung was da nicht stimmt?


Sollte ich damit weiterkommen werde ich meine weiteren Erkenntnisse hier einbringen :)



Gruß
tric
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke du gibst die IP Addresse im "TIA Client" ein. Der Server meldet sich wahrscheinlich mit einem Namen zurück. Check mal mit UA Expert die Endpoint URL dort steht dann wahrscheinlich etwas wie opc.tcp://meinservername:port
D.h. du musst in tia statt der IP diese URL eintragen, dann gehts.
Für die Steuerung als Client brauchst du in diesem Fall allerdings ein DNS Server im Netz...
 
Ich denke du gibst die IP Addresse im "TIA Client" ein. Der Server meldet sich wahrscheinlich mit einem Namen zurück. Check mal mit UA Expert die Endpoint URL dort steht dann wahrscheinlich etwas wie opc.tcp://meinservername:port
D.h. du musst in tia statt der IP diese URL eintragen, dann gehts.
Für die Steuerung als Client brauchst du in diesem Fall allerdings ein DNS Server im Netz...

Ob das
Code:
opc.tcp://meinservername:port
oder
Code:
 opc.tcp://192.168.0.1:port
ist absolut egal. Meistens hat man im lokalen Netz sowieso keine Namensauflösung und deshalb ist die Variante mit der IP Adresse die beste.

Mach mal ein Printscreen son der Konfiguration der SPS und des OPC Servers.
 
Nein das ist nicht egal, kannst du gerne testen ;) TIA kommt damit nicht klar, wenn statt der IP der Name zurück gegeben wird. Du bekommst dann genau den Fehler den Marcel beschreibt.
Ich bin auch für die IP Variante, aber viele Server melden sich nunmal mit Namen zurück. In dem Fall brauchst du dann einen DNS Server und muss diesen in der Client Steuerung auch angeben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein das ist nicht egal, kannst du gerne testen ;) TIA kommt damit nicht klar, wenn statt der IP der Name zurück gegeben wird. Du bekommst dann genau den Fehler den Marcel beschreibt.
Ich bin auch für die IP Variante, aber viele Server melden sich nunmal mit Namen zurück. In dem Fall brauchst du dann einen DNS Server und muss diesen in der Client Steuerung auch angeben.

Oje... Also ein weiteres mal nicht brauchbar bei Siemens...
 
Hallo,

also ich habe bereits beide Varianten versucht, IP-Adresse oder Name macht dabei keinen Unterschied.

Hier mal der Screenshot:
Capture.PNG

Zur Info: Mir steht keine XML zur Verfügung, ich möchte die Server-Schnittstelle online ermitteln. Dabei kommt es zu dem beschriebenen Fehler.
Außerdem ist mir aufgefallen, dass wenn ich z.B.
Code:
opc.tcp://0.0.0.0:62548/test/DataAccessServer
tippe, es zum gleichen Fehler kommt - TIA scheint nicht zu erkennen, dass 192.168.4.54 ein OPC UA-Server ist...?

Gruß
tric
 
Hallo,

also UAExpert verbindet nur mit dem Server, wenn ich die IP-Adresse statt des Namens verwende.
Deshalb hab ich im TIA-Portal auch die IP-Adresse verwendet. Aber wie schon erwähnt, ich habe auch den Namen verwendet, gleiches Ergebnis.

Gruß
tric
 
Dann hilft eigentlich nur ein Wireshark vom Verbindungsversuch. Dabei musst du darauf achten, dass in Wireshark der verwendete Port mit dem OPCUA Protokoll verknüpft ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wo kommt denn die Portnummer her? Laut Wikipedia:
Code:
Wie schon erwähnt gibt es zwei Protokolle. Als Anwendungsentwickler bemerkt man das nur an der zu übergebenden URL: [I]opc.tcp://Server[/I]/ für Binärprotokoll und [I]http://Server[/I] für Webservice. Ansonsten funktioniert OPC UA völlig transparent an der API. 
 
[LIST=1]
[*]Binärprotokoll
[LIST]
[*]beste Performance, am wenigsten Overhead
[*]Verbraucht am wenigsten Ressourcen (kein XML-Parser, SOAP und HTTP notwendig → wichtig für Embedded-Geräte)
[*]beste Interoperabilität (binär ist genau spezifiziert, nicht so viele Freiheitsgrade wie mit XML)
[*]Ein einziger TCP-Port (4840) wird für die Kommunikation verwendet  und kann auch leicht getunnelt oder in einer Firewall freigeschaltet  werden.
[/LIST]

[*]Webservice ([URL="https://de.wikipedia.org/wiki/SOAP"]SOAP[/URL])
[LIST]
[*]beste Tool-Unterstützung. Kann z. B. auch leicht aus [URL="https://de.wikipedia.org/wiki/Java_(Programmiersprache)"]Java[/URL] und [URL="https://de.wikipedia.org/wiki/Dot_Net"].net[/URL] verwendet werden.
[*]Firewall-freundlich. Port 80 (http) und 443 (https) funktionieren meistens ohne weitere Konfiguration.
[/LIST]
[/LIST]
 Da der zur Verfügung gestellte ANSI-C-Stack beide Protokolle  beherrscht, wird erwartet, dass die meisten Produkte mit dem effizienten  Binärprotokoll kommunizieren werden. 

 [h=2][/h]
 
Hallo,

danke für den Tip. Hab ich gemacht:
Capture.PNG

Kommunizieren tun sie ja anscheinend...
Ich kann mir aber nicht erklären warum die Verbindung wieder beendet wird...


Gruß
tric
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der CloseSecureChannel ist normal. Interessant ist die URL in FindServerRequest und Response.
 

Anhänge

  • Wire.jpg
    Wire.jpg
    85 KB · Aufrufe: 94
Zuletzt bearbeitet:
OK, ich glaube nun kommen wir der Sache näher:
request.PNGresponse.PNG


Ist mein Problem die Rückmeldung als Servername statt der IP-Adresse? Und wenn ja, was kann ich machen?


Gruß
tric
 
Da wird doch versucht eine sichere verbindung aufzubauen, oder ? Das geht dann nur per Name, nicht per IP.

Ist das Zertifikat auf er CPU hinterlegt und stimmt die UHRZEIT der CPU ?
 
Zurück
Oben