Guten Tag zusammen,
im Rahmen meines Technikerprojekts versuche ich eine S7-1512C-1PN (Firmware 2.6, TIA Portal v15.1) über OPC UA mit einer Codesys Visualisierung zu verbinden. Codesys stellt den OPC-UA-Server zur Verfügung und die S7 fungiert als Client.
Ich nutze den OPC_UA_Connect Baustein, doch leider scheitert es bereits an der Verbindungsherstellung. Der Ausgang busy springt kurz auf TRUE, schaltet sich aber direkt wieder ab und nichts weiter passiert.

Die Variablen sind über die Client Schnittstelle erreichbar.

Ich hoffe ihr habt anregende Ideen für mich, mfg Henning.

Hi,

Relevant ist hier der Status. Speichere dir den Status bei Änderung ab und dann kannst du prüfen, was der Baustein getan hat.

Hi HenningVpl,

die gängigsten Fehlerquellen:

• CPU-Zeit nicht eingestellt (1970...).
• Vergessen, ein Zertifikat für den Client zu erstellen.

Ansonsten evtl. einen Screenshot vom Bausteinaufruf und der Client-Schnittstelle liefern. Und wie der Vorposter schon erwähnte: Den Bausteinstatus.

Wir finden sicher eine Lösung

Danke erstmal für eure schnellen Antworten.

• Der Status wechselt von 16#0070_0000 auf 16#0070_0200 sobald und solange er auf busy steht und springt dann wieder auf 16#0070_0000 zurück.

• Beim Client-Zertifikat ist der Haken bei "Server Zertifikate zur Laufzeit automatisch akzeptieren" gesetzt.

Evtl. noch Screenshots nachliefern, die "Eigenschaften > Konfiguration" der Client-Schnittstelle liefern, damit wir die projektierten Verbindungseinstellungen sehen.

Allerdings kommt mir das Verhalten bekannt vor: Hast du in der Hardwarekonfiguration der CPU den OPC UA-Client aktiviert (unter "Gerätekonfiguration > Eigenschaften > OPC UA > Client")?

Ja, der Client ist aktiviert.

Puh, schwer zu diagnostizieren. Eventuell kannst du dir ja mal eine Logic basten, die überprüft, ob ein Fehler anliegt und falls ja, den Status des Bausteins in eine andere Variable kopiert.

So nach dem Motto:

"If ERROR then
STATUSBUFF := STATUS
End_If;"

Danach mal kucken, ob evtl. kurz ein Fehlerstatus ausgegeben wird.

Jap, in der TIA-Hilfe (Baustein markieren und F1 drücken).

Na, damit kommen wir weiter.

"8005_0000"
Verbindungsaufbau gescheitert.
Mögliche Ursachen:

• Die Server-Adresse (ServerEndpointURL) ist falsch oder unvollständig.
• Der Server akzeptiert die vom Client beim Verbindungsaufbau übermittelte Puffergröße nicht.
• Die für den Verbindungsaufbau benötigten Verbindungsressourcen des Clients sind erschöpft.

Abhilfen:

• Prüfen und korrigieren Sie die ServerEndpointURL
• Überprüfen Sie die zulässige Puffergröße. Der Client der S7-1500 CPU stellt 8192 Bytes zur Verfügung. Diesen Wert muss der Server akzeptieren.
• Bei einem Auf- und Abbau der Verbindung in schneller Folge ist die Frequenz zu verringern.

Kann es sein, dass Codesys und TIA Portal auf der selben Maschine laufen? Dort klappt ja die Verbindung. Möglicherweise blockt die Windows-Firewall den OPC UA-Verbindungsaufbau von außerhalb. Zum Test mal die Firewall ausschalten.

Die EndpointURL kann es eigentlich nicht sein, dort haben wir sehr viel probiert.

TIA Portal scheint ausschließlich IP-Adressen zu verwenden und Codesys ausschließlich Domain-Namen, ich vermute aktuell irgendwo nen Bock in unserem DNS Server oder den dazugehörigen Einstellungen.

Das mit der Puffergröße werde ich morgen direkt mal ausprobieren, davon hatte ich bis dato noch nicht gehört. Könnte also auch möglich sein.

Unser Netzwerk besteht aus diversen Laptops an denen ich und meine Kollegen TIA nutzen, der S7-1500, einem NUC auf dem die Codesys Visualisierung via Touch-Display und der OPC-Server läuft und seit kurzem auch eine FritzBox, die den DNS-Server stellen soll.

Update:
Nach dem Einstellen der Puffergröße auf dem Server schlug die Verbindung nachwievor fehl.
Die Statusmeldung änderte sich allerdings auf: 800A_0000. Als mögliche Ursache wird gesagt es kann keine Verbindung zum Server hergestellt werden, was mich wieder zum DNS Server bringt.

Bis hierhin erstmal vielen Dank.

Wir haben heute einen neuen DNS Server über eine FritzBox eingerichtet und das ganze nochmal probiert.

Hierbei kam der Statuscode: 80B7_0000  -  BadMaxConnections Reached

Jemand Ideen wie man mit dem Fehler verfahren soll?

Zum Thema DNS hilft evtl. folgender FAQ:
https://support.industry.siemens.com/cs/ww/de/view/109771693

Zum Thema "BadMaxConnections Reached":
Der Fehler tritt auf, wenn zu viele OPC UA-Connections vom Client aufgebaut wurden. Bei einer 1512 sind das, glaube ich, 4 Verbindungen.

I have the same problem.

I dont know how to fix it. 

At least u solve it?

I have one S7-1500 like a Client and one S7-1200 like a server. 

This guidance is strictly for entertainment purposes only and should not be considered advice of any kind. By reading this content you agree I am not liable for any damages that may arise as a result of you reading this content.

Hello.

I was battling this kind of issue for quite a while and stumbled on to what might be a solution.

I have an S7-1500 series PLC acting as an OPC UA client, and an industrial PC acting as an OPC UA server. I had a lot of trouble with OPC_UA_Connect returning #830D_0000 and #8500_0000 errors. During this time my server endpoint was "ocp.tcp://exampleServer:48010", and the server was connected to the PLC via ethernet with the ethernet adapter on the server PC IP locked/set to 192.168.0.50. I was able to connect another pc to the system and see the server using UaExpert, using both the named address (ocp.tcp://exampleServer:48010) and the IP based address (ocp.tcp://192.168.0.50:48010). Yet my PLC would not connect using either address type.

Only after forcing my server endpoint to be IP based only, and contain the IP address of the ethernet port connecting it to the PLC, i.e. "ocp.tcp://192.168.0.50:48010" would the plc connect using that same endpoint in the client configuration. I recommend disabling all firewalls on your server pc and all security for both the client and server until you make contact.

Hope this helps someone.