TIA Iso on TCP Verbindung zu langsam

[Byte0815]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich arbeite derzeit mit dem TIA Portal V17 und habe eine Iso on TCP Verbindung zwischen 1515R-2PN und einer 1214C DC/DC/DC.
Die Verbindung an sich läuft wunderbar, jedoch habe ich das Problem das Analogwerte ( als Real skaliert) schnell übertragen werden (sekündliche Änderung), Bool Werte benötigen jedoch 10-15 Sekunden bis eine Wertänderung übertragen wird.

Habe schon versucht den Sende und Empfangstakt anzupassen jedoch ohne sichtbaren Erfolg.

Aktuell benutze ich zum anstoßen des TSEND_C einen 1Hz Taktmerker mit einer Und Verknüpfung wo ich auf Busy, Error und Done prüfe.

 

[Larry Laffer]

Wie überträgst du dass denn überhaupt ? Als gemischten Block ... oder jede Variable einzeln ?

 

[Byte0815]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe einen nicht Optimierten Baustein wo zunächst Bool Werte und danach Real Werte kommen.

Wenn ich an den Req des TSEND_C nur den Taktmerker anlege funktioniert es, jedoch befürchte ich das die Kommunikationslast auf Dauer zu hoch sein könnte wenn ich es weiter so mache

 

[PN/DP]

Wieviele Datenbytes werden denn übertragen? Von der 1515 zur 1214 oder umgekehrt oder in beiden Richtungen? In einem Stück? Wie werden die Daten-Werte zu einem Sende-Block zusammengestellt? Wie sieht der Sende-Datenblock aus? Wie sieht der Aufruf des TSEND_C aus? Wie sieht die Verknüpfung von Busy, Error und Done aus? Wie sieht der Aufruf des TRCV aus? Verwendest Du vielleicht TSEND_C und TRCV_C in einer SPS? Wird nach jedem Senden die Verbindung abgebaut? Gibt es Errors und Fehler-Status? Wie werden die Empfangsdaten beim Empfänger abgeholt? Woran siehst Du, daß bei Bool-Werten nur alle 10-15 Sekunden Änderungen ankommen? Ist das ein Beobachtungsproblem oder ändern sich die Ausgangsdaten so selten oder entsteht das Problem beim Empfang? Hast Du mal an allen möglichen Stellen testweise Zähler an Signale angeschlossen (BUSY, DONE, NDR, Empfangsdaten-Bits) und ändern sich die Zähler auch so langsam? Wenn Du Busy, Error und Done nicht verknüpfst, dann tritt das Problem nicht mehr auf?
Welche Firmware-Versionen haben Deine CPUs?

 

[Byte0815]

Hallo PN/DP

die Bytes Anzahl ist unterschiedlich mal nur 10 manchmal auch 100 das kommt auf den Kommunikationspartner an.
Die Kommunikation erfolgt in beide Richtungen wobei die 1515 stehts aktiv die Verbindung aufbaut.
Ich verwende immer nur TSEND_C und daran geknüpft dann TRCV.
In beiden SPSen gibt es jeweils einen TSEND_C geknüpft mit TRCV.
Ich habe die empfangen Daten in der 1515 beobachtet dabei war zu sehen das die REAL Werte im Kommabereich "gewackelt" haben.
Negiere ich jetzt in meiner 1214 eine Meldung dauert es 10 bis 15 Sekunden bis dieser Wert ankommt in der 1515, dies ist leider auch kein Beobachtungsproplem. Ich habe bereits vor Ort mal eine Sicherung ausgelöst auch das hat 10-15 Sekunden gedauert bis die Meldung auf der 1515 ankam.

Anbei mal ein Beispiel wie ich TSEND_C und TRCV Verknüpfe

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Um sicherzustellen, daß TRCV immer aufgerufen wird, würde ich TRCV in ein eigenes Netzwerk legen mit dauerhaft EN, und nicht an ENO von TSEND_C anschließen. Netzwerke kosten nichts.
Bei der Verknüpfung zum TSEND_C.REQ nimm mal vom "Clock_1Hz" nur die positive Flanke, um sicherzustellen, daß nur einmal pro Sekunde gesendet wird.
Die Verknüpfung von allen drei Signalen BUSY, DONE und ERROR ist unnötig. Kann man aber machen - dann wird die Pause nach einem Senden 1 Zyklus länger. Es reicht die Flanke vom Clock und nicht BUSY. Oder bei Flanke vom Clock Setze REQ und bei DONE oder ERROR Rücksetze REQ.

Harald

 

[Byte0815]

Okay habe das Ganze jetzt mal so umgesetzt. Jedoch hat sich an der Übertragungsgeschwindigkeit nicht wirklich etwas geändert

 

[PN/DP]

Wieviele Datenbytes werden denn übertragen? Von der 1515 zur 1214 oder umgekehrt oder in beiden Richtungen? In einem Stück? Wie werden die Daten-Werte zu einem Sende-Block zusammengestellt? Wie sieht der Sende-Datenblock aus? Wie sieht der Aufruf des TSEND_C aus? Wie sieht die Verknüpfung von Busy, Error und Done aus? Wie sieht der Aufruf des TRCV aus? Verwendest Du vielleicht TSEND_C und TRCV_C in einer SPS? Wird nach jedem Senden die Verbindung abgebaut? Gibt es Errors und Fehler-Status? Wie werden die Empfangsdaten beim Empfänger abgeholt? Woran siehst Du, daß bei Bool-Werten nur alle 10-15 Sekunden Änderungen ankommen? Ist das ein Beobachtungsproblem oder ändern sich die Ausgangsdaten so selten oder entsteht das Problem beim Empfang? Hast Du mal an allen möglichen Stellen testweise Zähler an Signale angeschlossen (BUSY, DONE, NDR, Empfangsdaten-Bits) und ändern sich die Zähler auch so langsam? Wenn Du Busy, Error und Done nicht verknüpfst, dann tritt das Problem nicht mehr auf?
Welche Firmware-Versionen haben Deine CPUs?

Passiert das Problem nur in einer Richtung? Welche?
Wann wird der Code mit dem TSEND_C/TRCV aufgerufen?

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Problem ist, daß der Empfangspuffer und/oder Sendepuffer überläuft. Da du durch das Done das senden neu auslöst wird mehrmals pro Sekunde gesendet
siehe hier

Step 7 - Datenübertragung mit Get&Put

Hallo zusammen, Ich hoffe, dass es dieses Thema auf diese Art noch nicht gibt. Ich habe wirklich sehr viel ausprobiert und auch viel gesucht und gelesen. Leider komme ich trotzdem nicht weiter. Ich versuche aktuell von der S7-400 aus, Daten auf 300/400 zu übertragen und zu lesen. Soweit...

www.sps-forum.de

und hier

TIA - TSend TRcv sehr langsam

Hallo Folgender Aufbau 1518F im Subnetz 1 315F mit cp343-1 Lean im Subnetz 1 1512F im Subnetz 2 (wird geroutet über Firmennetz) Verbindung IsoOnTcp Die 315 und die 1512 zählen im 100ms eine Variable hoch und senden diese an die 1518. Die 1518 schickt diese Variable direkt wieder zurück EN_R am...

www.sps-forum.de

 

[PN/DP]

Das Problem ist, daß der Empfangspuffer überläuft. Da du durch das Done das senden neu auslöst wird mehrmals pro Sekunde gesendet

Ich habe dem Fragesteller bereits geschrieben, daß er vom Takt nur die steigende Flanke nehmen soll, und er schreibt, daß er das so umgesetzt hat. Wenn das stimmt, dann wird garantiert höchstens einmal pro Sekunde gesendet. Und nun?

 

[volker]

Das habe ich gelesen. Ich wollte nur darauf aufmerksam machen das diese probleme existieren.
und ja, wenn er das korrekt umgesetzt hat sollte das problem nicht mehr daran liegen.

 

[Byte0815]

Zuviel Werbung?
-> Hier kostenlos registrieren

Passiert das Problem nur in einer Richtung? Welche?
Wann wird der Code mit dem TSEND_C/TRCV aufgerufen?

Nein es passiert nur in eine Richtung schicke ich ein Bit zur 1214 geschieht das quasi in Echtzeit nur andersrum dauert es extrem lange.
Ein Error oder Fehler tritt auch nicht auf.

Ich hoffe das ich es mit der Flanke richtig verstanden bzw. umgesetzt hatte.

 

[PN/DP]

Ich hoffe das ich es mit der Flanke richtig verstanden bzw. umgesetzt hatte.

Ich hätte gewohnheitsmäßig nicht -|P|- verwendet, sondern P_TRIG. Das ist an der Stelle in Deinem Programm aber egal und müsste auch funktionieren. Wo ist die Variable #P_TRIG deklariert? Sie darf nicht in TEMP deklariert sein, sondern muß in Static. Dein Code wird anscheinend in einem FB aufgerufen? Und der FB wird in einem Zyklus-OB (z.B. OB1) aufgerufen?

(P: Operand auf positive Signalflanke abfragen / P_TRIG: VKE auf positive Signalflanke abfragen)

Nein es passiert nur in eine Richtung schicke ich ein Bit zur 1214 geschieht das quasi in Echtzeit nur andersrum dauert es extrem lange.

Wenn die Programme sonst ziemlich gleich sind, dann scheint es an einer der CPUs zu liegen.

Bekommen wir nun noch eine Info, welche Firmware-Versionen Deine CPUs haben und als welche Version Du die projektiert hast, oder willst Du lieber mit dem Siemens Support mit Deiner auskunftsarmen Art und Weise kommunizieren?

Harald

 

[Byte0815]

Also die Variable #P ist derzeit als eine TEMP Variable, werde ich aber jetzt ändern nach deinem Tipp.
Der Code wird derzeit in einem FC aufgerufen und dieser im OB1.

Ja der Code ist auf beiden Seiten gleich.

Also die 1515R-2 PN hat Firmwarestand V2.9
1214C V4.5
Sie sind auch als diese projektiert.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also die Variable #P ist derzeit als eine TEMP Variable, werde ich aber jetzt ändern nach deinem Tipp.
Der Code wird derzeit in einem FC aufgerufen und dieser im OB1.

Ich vermute mal, Du meinst die Variable #P_TRIG Und diese Stümperei mit TEMP-Variable als Flankenmerker hatte ich doch auch geahnt...
Also wenn die Variable eine TEMP-Variable ist, dann müssten Deine CPUs in jedem Zyklus, wo der Taktmerker TRUE ist, eine steigende Flanke erkennen. Da wird dann auch wieder viel öfter als einmal je Sekunde gesendet.
Ein Flankenmerker muss sich seinen letzten Zustand bis zum nächsten Programmdurchlauf merken können. In einem FC gibt es keine Static Variablen, die sich etwas merken können. Da muss der Flankenmerker eine globale Variable sein (DBX in einem DB oder Merkerbit), und der FC muss direkt auf die globale Variable zugreifen oder die Variable muss an einen InOut des FC angeschaltet werden, wenn der FC parametrierbar sein soll. Alternativ und besser: den FC ändern zu FB, dann kann er eigene lokale Static Variablen haben, um sich was zu merken.

Also die 1515R-2 PN hat Firmwarestand V2.9
1214C V4.5
Sie sind auch als diese projektiert.

Falls Du wirklich online in den CPUs nachgeschaut hast, warum nennst Du hier nicht die tatsächliche Firmware-Version? Die Firmware-Versionsnummer hat 3 Stellen...
OK, schaue selber nach, ob Du in Deinen CPUs jeweils die neuste Firmware-Version hast:
Lieferfreigabe für innovierte CPU 1513R-1 PN und CPU 1515R-2 PN (V3.0.x)
Firmware-Update S7-1500 CPUs incl. Displays (V3.0.3 bzw. V2.9.7)
Firmware-Update für CPU 1214C DC/DC/DC (V4.6.0)

Hat das Problem vielleicht damit zu tun, daß Du eine redundante CPU 1515R hast? Da kenne ich mich nicht mit den Details einer korrekten Projektierung aus. Ich würde vorschlagen: kontaktiere den Siemens Support.

Harald

 

[DeltaMikeAir]

Hat das Problem vielleicht damit zu tun, daß Du eine redundante CPU 1515R hast?

Kann schon sein, es gibt auf jeden Fall Unterschiede und Einschränkungen. Siehe hier ab Seite 393:
Siemens Handbuch S7-1500 Kommunikation