TIA 1500er -> 1200er: ISO-on-TCP Verbindung ist elend langsam

Paul

Level-2
Beiträge
929
Reaktionspunkte
239
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen

Ich habe folgendes Problem:
Ich habe eine Verbindung zwischen einer 1500er und einer 1200er projektiert. Und zwar mit:
TCON
TSEND
TRCV
Verbindungstyp ist ISO-on-TCP
Pro Sende-/Lesevorgang werden ca. 150 Byte hin und her geschaufelt.
Die Verbindung als solches funktioniert auch.
Nur ist sie eben ELEND langsam

Beispiel:
1200er schickt "Teil abholbereit" zur 1500er
1500er sagt "Teil abgeholt" zur 1200er
Allein dieser Handshake dauert ca. 2-3 Sekunden.
Solche Handshakes sind aber einige pro Bearbeitungszyklus nötig.
Für die Taktzeit natürlich untragbar.

Momentan mache ich es so:
Sobald SENDEN nicht Busy meldet wird mit dem 100ms Takt das Senden neu angestoßen
offenbar ist das Busy Signal (zu) lange aktiv.

Könnte ein anderer Verbindungstyp (z. B. nur TCP - ohne das ISO) Abhilfe schaffen?
Was für eine Rolle spielt die Menge der Bytes, könnte man das evtl. in
zeitkritische und weniger zeitkritische Signale splitten, die dann in separaten Verbindungen laufen?

Könnte man eigentlich auch mit der einen CPU direkt auf (virtuelle) Ein-/Ausgänge der anderen schauen?


Ich bin nicht der größte Vernetzungsspezialist, vielleicht kann mir jemand Tipps geben.
Vielen Dank schon mal im Voraus
 
Könnte man eigentlich auch mit der einen CPU direkt auf (virtuelle) Ein-/Ausgänge der anderen schauen?

Du könntest die eine CPU zu einem I-Device der Anderen machen. Hier wäre deine Kommunikation dann etwa im Bereich der Kommunikation mit dez. Perepherie.

Die jetzt aktuelle Kommunikation kann tatsächlich recht langsam sein. Nach meinem Gefühl triggerst du den SEND aber auch zu schnell zu oft an. Du solltest hier erst warten, bis er abgearbeitet ist, dann zusätzlich noch etwas Zeit vergehen lassen (z.B. 100 ms) und ihn dann erneut Triggern. Manchmal ist weniger dann doch mehr ...

Gruß
Larry
 
Also ich nutze das mit TCP und habe einen Sende und -Empfangstakt von 10ms stabil.
Verbindung 1507 zu WinAC RTX.

Bei 1200 nach WinAC RTX habe ich 1 sekunde aber noch nicht probiert ob es schneller geht da mir das vollkommen ausreicht.

Du musst einen Zyklus warten wenn busy weg ist sonst geht es nicht.

Gruß

Jens
 
wieviele Verbindungen kann I-Device ?

Bsp. von einer S7 400 zu 3 separaten 1500er geht gar nicht. nur zu EINER 1500er .
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also:
Ich bin einen Großen Schritt weiter.

Code:
//Lahme Verbindung
UN #Send_busy
U    Taktmerker 100ms
=   #Anforderung senden


//So geht's richtig flott
UN #Send_busy
U(
U    Taktmerker 100ms
[B]FP   #FP_xy[/B]
)
=   #Anforderung senden
 
wieviele Verbindungen kann I-Device ?

Bsp. von einer S7 400 zu 3 separaten 1500er geht gar nicht. nur zu EINER 1500er .

Das kann ich jetzt ehrlich gesagt auch nicht sagen. Ich würde das aber so sehen :
Deine S7-400 wäre dann der "Master" - also die SPS bei der die GSD-Dateien der I-Devices eingefügt werden. Ich denke, da gäbe es dann erstmal keine Restriktionen.
Jede deiner 1500er wäre dann ein I-Device von denen zu dann eine GSD-Datei generierst.
Wie das ist, wenn jeder quasi jeden "kennt" habe ich nie gebraucht ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das hat mich eigentlich drauf gebracht es mal mit FP zu probieren, DANKE

Naja ... was hatte ich da noch gleich geschrieben ...

Nach meinem Gefühl triggerst du den SEND aber auch zu schnell zu oft an. Du solltest hier erst warten, bis er abgearbeitet ist, dann zusätzlich noch etwas Zeit vergehen lassen (z.B. 100 ms) und ihn dann erneut Triggern. Manchmal ist weniger dann doch mehr ...
 
Hallo Leute,
ich habe ein Problem mit TSend_C. Die Daten kamen scheinbar sehr langsam an und ich dachte, die kurze Wartezeit vor dem erneuten Triggern, wie in diesem Thread vorgeschlagen, würde helfen, doch das tat es nicht und jetzt ist mir erst das Problem aufgefallen.

Ich sende ein Prüfbit, welches die Gegenseite registriert und zurücksetzt. Das Senden geht so fix, dass kein Timeout in der Gegenseite festgestellt wird (da wird einfach die Zeit bis zum Setzen des Bits überprüft). Dieses Bit ist das letzte Bit der Sende-Struktur. Aber: Die Zeit bis der Flankenwechsel eines anderen Bits, welches an erster Stelle der Sende-Struktur steht, auch in der Gegenseite ankommt dauert sehr lange. Teilweise 10 Sekunden und länger.
Ich verstehe im Moment nicht, warum das erste, verspätete Bit scheinbar nur manchmal übertragen wird bzw. die Aktualisierung so lange dauert.
Hat jemand vielleicht einen Lösungsvorschlag parat?

Ich arbeite mit dem TIA Portal V15.1 und habe eine TCP Verbindung zwischen zwei 1500er CPUs erstellt.
Meine Sende- und Empfangsstrukturen sind in einem DB mit optimierten Zugriff angelegt.
Ich habe die Anweisungen in der Hilfe, wie z.B. den Parameter Länge auf "0" befolgt und ich sende mit einer Verzögerung nach dem Abfallen des Busy-Bits.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hat jemand vielleicht einen Lösungsvorschlag parat?

Mach mal einen Trace vom Status des Send und Recv.
Zudem vielleicht auch noch die empfangene Byteanzahl vom Recv.
Vielleicht kamm man da etwas erkennen.
Ansonsten gibt es von den Bausteinen verschiedene Versionen, die zur Firmware auch passen müssen.
Damit hatte ich mal seltsames Verhalten bei einer 1500.
Bei richtiger Parametrierung und Aufruf ist 1500 <> 1500 eigentlich problemlos.

Gruß
Blockmove
 
Was meinst du?
TSend_C baut eine Verbindung auf und hält sie und sendet darüber. Daher benutze ich TSend_C.
TSend benötigt eine bestehende Verbindung, so wie ich es aus der Hilfe entnehme.
 
Zurück
Oben