TIA TCP/IP Verbindungsprobleme S7-1500

[RosiBro]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey,

ich bin gerade dabei eine TCP/IP Modbus Kommunikation zwischen einem
SIMATIC ET 200SP Open Controller, CPU 1515SP PC als Client und einem Arduino als Server herzustellen.
Die Funktion ist bei mir folgendermaßen eingebunden:



Meine Einstellparameter sehen folgendermaßen aus:


Die OR Verknüpfung am Eingang ist nicht so sinnvoll denke ich (weil er dann die ganze Zeit neue Requests bekommt), aber auch ohne dieser, kann meine SPS keine Verbindung zu meinem Arduino herstellen. Die Modbus Implementierung auf dem Arduino ist ausreichend getestet und funktioniert.
REQ ist TRUE und DISCONNECT ist FALSE.

Die IP der SPS ist 192.168.1.1.
Was mich auch verwundert ist, dass ich mir DONE, BUSY und ERROR über die HMI ausgeben lasse, aber nur ERROR richtig zu funktionieren scheint.

Wenn ich erstmalig auf senden gehen, bekomme ich 7001 als Status ("Verbindungsaufbau angestoßen."), versuche ich noch einmal zu klicken kommt 7002 ("Zwischenaufruf. Verbindung wird aufgebaut." bzw. "Zwischenaufruf (REQ irrelevant). Der aktivierte Auftrag ist noch in Bearbeitung; BUSY hat den Wert "1"."), allerdings wird mein BUSY Bit nicht gesetzt. Nach einer Weile bekomme ich dann auch eine Fehlermeldung: 80C6 ("PROFINET: Vom Anwender noch nicht abgeholte Aufträge werden durch Wiederanlauf verworfen"). Und mein ERROR Bit wird gesetzt.

Eine Verbindung bekomme ich nicht hin. Habt ihr eine Idee, woran das liegen könnte?
Bin gerade mit meinem Latein am Ende.

Besten Dank,

Olaf.

 

[Thomas_v2.1]

Der FB wird über den REQ (oder auch DISCONNECT) Eingang gesteuert, du darfst diesen nicht bedingt aufrufen, was du mit deiner Logik an EN machst.

 

[RosiBro]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke dir. Das ergibt Sinn. Ich werde das Montag mal ausprobieren.
Heißt das, dass es auch keinen Sinn ergibt, den FB in einen anderen FB zu werfen und jenen bedingt aufzurufen?

 

[Thomas_v2.1]

Die interne Verarbeitung in dem Baustein läuft über mehrere Zyklen. Ich würde den auf jeden Fall immer in jedem Zyklus aufrufen.
Nicht aufrufen höchstens wenn du wirklich Disconnected hast und dann erst bis dir der FB diesen Zustand eindeutig zurückgemeldet hat. Aber wozu willst du das mit dem bedingten Aufrufen denn machen?

 

[RosiBro]

Das war eher eine theoretische Frage. Ich dachte vielleicht bringt es Laufzeitverbesserung, wenn ich ihn nur dann aufrufe, wenn ich ihn auch wirklich benötige.

 

[escride1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das war eher eine theoretische Frage. Ich dachte vielleicht bringt es Laufzeitverbesserung, wenn ich ihn nur dann aufrufe, wenn ich ihn auch wirklich benötige.

Wenn beim MB_Client kein REQ ansteht und er nichts zu tun hat, dann springt er in den ersten Zeilen intern sofort aus dem Baustein zurück ohne ihn weiter abzuarbeiten. Seine Aufrufzeit ist daher zu vernachlässigen, es sei denn Du hast dutzende davon und gleichzeitig Zykluszeitprobleme.

Als Hinweis: Da Du dem Baustein das EN genommen hast solltest Du nach Deiner Änderung einen CPU-Neustart ausführen und dann weiter testen. Der Baustein ist da etwas empfindlich im Verbindungs-auf und -abbau.

 

[RosiBro]

Hey,

ich habe das jetzt ausprobiert und ENBL unbedingt verknüpft. REQ wird von mir von einer positiven Flanke auf HMI-Knopfdruck getriggert. Trotzdem wird keine Verbindung hergestellt. Der Status verbleibt bei 7002. BUSY wird weiterhin nicht gesetzt.
Da es sich um einen open Controller handelt frage ich mich, ob das Windows OS die Verbindung evtl blockiert. Aber die Firewall habe ich auch ausgemacht und auch nach einem Neustart kein anderes Ergebnis.
Das Netzwerk wird mir bei Windows auch angezeigt, allerdings sagt es mir, dass keine Verbindung möglich ist.

Habt ihr noch eine Idee?

 

[escride1]

Eventuell localhost als Verbindungspartner angeben und einen MB-Server als Softwarelösung auf dem gleichen Rechner starten. Gucken, ob es dann klappt, dann siehst zumindest ob Deine Konfig in der CPU OK ist.

Das Netzwerk wird mir bei Windows auch angezeigt, allerdings sagt es mir, dass keine Verbindung möglich ist.

So sieht das meistens aus wenn das Netzwerk auf öffentlich steht. Ist es das?


Da wir keinerlei Software-CPUs nutzen würden haben wir uns mit der Thematik nie beschäftigt. Aber anpingen konntest den Teilnehmer!?

Der aktivierte Auftrag ist noch in Bearbeitung; BUSY hat den Wert "1"."), allerdings wird mein BUSY Bit nicht gesetzt.

Kann es sein das Busy nochmal woanders im Programm auftaucht, z.B. in kopierten Netzwerken oder so?
Ist ziemlich unwahrscheinlich das im Baustein-DB Busy 1 hat aber der DB am Ausgang den Wert nicht.
Ich würde erst nach diesem Problem suchen.

 

[RosiBro]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke dir.
Ich habe jetzt noch einmal tabula rasa gemacht und nur die MB_Client Funktion im OB1. REQ trigger ich weiterhin über die HMI.

Eventuell localhost als Verbindungspartner angeben und einen MB-Server als Softwarelösung auf dem gleichen Rechner starten. Gucken, ob es dann klappt, dann siehst zumindest ob Deine Konfig in der CPU OK ist.

Wenn ich localhost (127.0.0.1) als Verbindungspartner angebe, bekomme ich eine Fehlermeldung, eben, dass ich gerade versuche sie mit sich selbst zu verbinden (Fehlercode habe ich jetzt nicht im Kopf, aber werde ich hier bei Gelegenheit ergänzen). Aber vielleciht muss ich da noch die Ports anpassen. Ich mache mich mal weiter schlau.

So sieht das meistens aus wenn das Netzwerk auf öffentlich steht. Ist es das?
Da wir keinerlei Software-CPUs nutzen würden haben wir uns mit der Thematik nie beschäftigt. Aber anpingen konntest den Teilnehmer!?

Ich habe es jetzt als Arbeitsnetzwerk und nach dem Anpingen des Servers, was funktioniert hat, ist der Status bei Windows jetzt auch als Netzwerkverbindung und connected angezeigt (aber erst, nachdem ich den Server angepingt habe).

Jetzt bekomme ich abwechselnd 7001 und 80C4 (Temporary communications error. The specified connection is temporarily down.) als Status.
DISCONNECT=FALSE und REQ=FALSE.
Dazu gibt es allerdings ein paar Beiträge im Forum und da werde ich erst mal ein bisschen schauen und mich dann wieder melden, wenn es etwas neues gibt.

Danke noch einmal für eure Hilfe!

 

[RosiBro]

Ok, hatte die falsche Schnittstelle verwendet

Bei den Open Controllern sind die Ethernet-Schnittstellen ENTWEDER der PLC ODER dem Windows OS zugeordnet. Ich hatte die falsche verwendet, auf die die PLC gar kein Zugriff hat.

Danke euch noch einmal für eure Mühen!