Step 7 Zeitversatz bei Kommunikation zweier S7 300 über AG Send/Recieve TCP Verbindung

[SPSKILLER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

kennt ne jemand die Lösung für folgendes Problem?

Ich tausche Daten zwischen S7 300er Steuerungen über eine TCP-Verbindung aus. (Lean 343 CPs)
In jeder Steuerung ist jeweils nur eine Verbindung für senden/empfangen projektiert.

Prinzipiell funktioniert der Datenaustausch, jedoch mit einer Verzögerung von ca. 15s.

z.B.
Wenn ich eine Sinuskurve von CPU2 nach CPU1 schicke, dann kommt diese Sinuskurve dort auch an.
Nur 15s verzögert.
In einem Diagramm erscheint die Empfangskurve quasi 15s weiter rechts als die Sendekurve auf der Zeitachse.

CPU1 kommuniziert insgesamt mit 4 Steuerungen auf diese Art.
Daten von CPU1 nach CPU 2/3/4/5 kommen dort unmittelbar an.

Falls jemand was dazu weiß, ich bin dankbar für jeden Hinweis.

 

[Larry Laffer]

Ich habe jetzt keine unmittelbare Idee - aber dafür eine Frage :
CPU1 schickt denselben Datensatz an 4 andere CPU's ...
- gibt es einen Unterschied in der Topologie des Netzwerks ?
- wie machst du das mit dem Senden ? Kontrollierst du den Ablauf der Sende-Vorgänge (also erst 1->2, dann 1->3, dann 1->4 usw.) oder läuft das nur über eine Zeitscheibe ?

Gruß
Larry

 

[Howard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,
wenn ich mich nicht irre, konnte man im Classic bei den CPs unter "Spezialdiagnose" doch vom CP aus eine IP Adresse anpingen (oder PG ins Netz hängen und von dort die CPs anpingen). Hast du mal geschaut ob dort auch schon so große Latenzen auftreten?
Darüber hinaus könntest du uns mal den Code zeigen, ob da noch was faul ist. Wie groß sind denn die Sendedaten?

 

[SPSKILLER]

CPU1 schickt denselben Datensatz an 4 andere CPU's ...

Es sind unterschiedliche Daten.
CPU1 erhält von CPU2/3/4/5 Analogwerte, führt damit Berechnungen aus, und sendet dann die Ergebnisse zurück

- gibt es einen Unterschied in der Topologie des Netzwerks ?

Nein, die Verbindungen sind aber unspezifiziert, da es unterschiedliche Projekte sind.

- wie machst du das mit dem Senden ? Kontrollierst du den Ablauf der Sende-Vorgänge (also erst 1->2, dann 1->3, dann 1->4 usw.) oder läuft das nur über eine Zeitscheibe ?

Ich starte immer mit Done oder Error eines AG Send einen neuen Sendeauftrag für eben diesen AG Send.
Die Daten von CPU1 nach 2/3/4/5 kommen ja schnell an. In diesen CPUs ist jeweils nur 1 AG Rec aufgerufen.

Die Daten, die von der CPU1 empfangen werden haben diesen Zeitversatz.
In der CPU1 ist 4x AG Rec aufgerufen. Dort vermute ich irgendwo das Problem.

 

[SPSKILLER]

Moin,
wenn ich mich nicht irre, konnte man im Classic bei den CPs unter "Spezialdiagnose" doch vom CP aus eine IP Adresse anpingen (oder PG ins Netz hängen und von dort die CPs anpingen). Hast du mal geschaut ob dort auch schon so große Latenzen auftreten?
Darüber hinaus könntest du uns mal den Code zeigen, ob da noch was faul ist. Wie groß sind denn die Sendedaten?

20 Byte hin und zurück pro Steuerung.
und 4x das Ganze bei CPU1

Gibt ja eigentlich keine Latenzen, nur diesen Zeitversatz.
Daten von CPU1 nach 2/3/4/5 sind auch sofort da.
Es geht nix verloren.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

... dann versuch doch mal an der Stelle eine sequentielle Abarbeitung der Sende- und Empfangsaufträge zu erzwingen - also eine Schrittkette dem Ganzen vorschalten (also erst Empfangen von 2, dann Empfangen von 3, dann von 4 dann von 5, dann Senden nach 2, dann nach 3, dann nach 4 und dann nach 5 ... und nun wieder von vorn).
Ich vermute, das es hier sehr häufig (einfach aufgrund der asynchronen Abarbeitung der Einzelaufträge) zu einer Benachteiligung des einen Sendevorgangs kommt - vielleicht auch weil hier mehr Daten zu übertragen sind ...

Gruß
Larry

 

[Howard]

dann zeig uns doch mal den Code von den RCV-Anweisungen

 

[SPSKILLER]

... dann versuch doch mal an der Stelle eine sequentielle Abarbeitung der Sende- und Empfangsaufträge zu erzwingen - also eine Schrittkette dem Ganzen vorschalten (also erst Empfangen von 2, dann Empfangen von 3, dann von 4 dann von 5, dann Senden nach 2, dann nach 3, dann nach 4 und dann nach 5 ... und nun wieder von vorn).
Ich vermute, das es hier sehr häufig (einfach aufgrund der asynchronen Abarbeitung der Einzelaufträge) zu einer Benachteiligung des einen Sendevorgangs kommt - vielleicht auch weil hier mehr Daten zu übertragen sind ...

Gruß
Larry

Ich habe mal nach dem ersten AG RCV in CPU1 den Baustein beendet. So, daß nur noch von CPU2 gelesen wurde.
Das müsste deinem Vorschlag in etwa entsprechen, hat aber leider auch nichts gebracht.
Heute bin ich nicht Vorort um zu testen.

Die einzelnen Anlagen dort sind schon ein paar Jahre alt, evtl. hat es auch was mit den Firmwares zu tun.
Ich frage mal bei Siemens nach.

 

[SPSKILLER]

Zuviel Werbung?
-> Hier kostenlos registrieren

dann zeig uns doch mal den Code von den RCV-Anweisungen

Ich habe frei, Mann

Was willst da sehen?
Die Daten kommen ja an, und werden in den richtigen Bereich geschrieben.
Sonst gibt es da ja nix am AG RCV wo man Fehler machen könnte.

 

[Larry Laffer]

Ich habe mal nach dem ersten AG RCV in CPU1 den Baustein beendet. So, daß nur noch von CPU2 gelesen wurde.
Das müsste deinem Vorschlag in etwa entsprechen, hat aber leider auch nichts gebracht.
Heute bin ich nicht Vorort um zu testen.

??? Sprachst du nicht von dem SEND nach 2 ...?

 

[Howard]

Ich habe frei, Mann

Was willst da sehen?
Die Daten kommen ja an, und werden in den richtigen Bereich geschrieben.
Sonst gibt es da ja nix am AG RCV wo man Fehler machen könnte.

Und woher genau soll ich jetzt wissen, dass du frei hast, Mann
Fehler gibt es offensichtlich einige - sonst würde es ja bei jedermann sofort laufen. Bedingte Aufrufe oder dynamisch beschaltete Parameter um mal zwei zu nennen.

 

[SPSKILLER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe vor der Threaderstellung gesucht, aber nix gefunden.

Jetzt grad aber durch Zufall... Genau mein Problem.
Zeitverzögerung mit TCP-Verbindung (AG SEND/RECV)

Ich werde wohl auch nach Done oder Error vom Send Baustein noch ne halbe Sekunde warten, bis ich den nächsten Auftrag anstoße.

Danke Euch beiden!

 

[SPSKILLER]

Und woher genau soll ich jetzt wissen, dass du frei hast, Mann
Fehler gibt es offensichtlich einige - sonst würde es ja bei jedermann sofort laufen. Bedingte Aufrufe oder dynamisch beschaltete Parameter um mal zwei zu nennen.

Cool bleiben, und Danke für deine Vorschläge!

Ich habe keinen größeren Emo gefunden, um durch die Blume mitzuteilen, daß ich keinen Bock hatte den ganzen FUP Scheiß hier zu posten, zumal es wirklich reine Standardbeschaltung ist.
Nix für ungut, Mann.

 

[PN/DP]

Verwendest Du für das Handling von AG_SEND/AG_RECV einen/mehrere FB? Und für jede Verbindung den/die FB als Multiinstanz? Versuche mal, die FB-Instanzen nicht als Multiinstanz sondern jeweils mit eigenem IDB zu verwenden.

Ich hatte mal ein ähnliches Problem: eine 315-2 DP mit CP343-1 kommuniziert per TCP-Verbindung mit 4 typgleichen Waagen. Also habe ich für das Senden der Abfragekommandos und das Empfangen der Antworten einen FB "WaageTYP_COMM" geschrieben und den FB viermal als Multiinstanz verwendet (je Waage/Verbindung eine Instanz): der Mutter-FB "Waagen" hat in STAT 4 Instanzen des Kommunikations-FB "WaageTYP_COMM" #Waage_1, #Waage_2 .. #Waage_4. Das lief ein Jahr lang gut so. Dann kamen noch 2 Waagen dazu und ich verwendete eine 5. und 6. Multiinstanz - nun kommt es: irgendwann nach Sekunden oder Tagen kommen die Antworten der 5. oder 6. Waage plötzlich 10..15 Sekunden verzögert im SPS-Programm an! Ich habe sehr vieles probiert ... das Problem blieb unerklärlich ... letztendlich hat nur geholfen, für jede Verbindung eine FB-Instanz mit eigenem IDB zu verwenden.

Dein CP343-1 hat die neueste Firmware drauf?

Harald

 

[SPSKILLER]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich war heute beim Kunden Vorort, und habe ein paar Versuche gemacht.

Beobachtet habe ich einen INT Wert, der in der Sendesteuerung zyklisch um 1 erhöht, und dann an die Empfangs SPS geschickt wird.

Fazit:

Wenn ich 50ms (bisschen mehr als 3 SPS Zyklen) Verzögerung zwischen zwei Sendeaufträge einbaue, dann schaffe ich eine Übertragungszeit von ca. 80ms.
Der gesendete Wert kommt direkt in den EmpfangsDB.

Wenn man die Zeit auf 0 setzt, dann kann man sehen, wie die Werte auseinanderlaufen.
Nach einigen Sekunden ist die Differenz schon auf über 1000 angestiegen.
Nach ca. 20s bleibt die Differenz konstant!?
Verloren geht nix, wird nur irgendwo gepuffert.

Wenn ich die Verzögerung wieder aktiviere, nähern sich die Werte wieder an, bis schliesslich wieder der gesendete Wert direkt in den EmpfangsDB geschrieben wird.

-> Bei mir funktioniert es nicht, wenn ich direkt mit Done oder Error des Sendebausteins das nächste Senden antriggere.
Zumindest nicht bei den Sendebausteinen, die an eine SPS senden, die auch noch Daten von anderen SPSen erhält (mehrere AG RECV enthält)
Beim Senden an eine SPS, die nur einen AG RECV enthält funktioniert es auch ohne Verzögerung einwandfrei.

Mit den Multiinstanzen hatte ich übrigens keine Probleme.
Das Verhalten das Harald beschrieben hat ist auch sehr, sehr seltsam...

Viele Grüße, und Danke nochmal an alle

Micha