TIA TSend_C /TRCV_C hängt sich auf

Byte0815

Level-2
Beiträge
149
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

Ich habe derzeit eine Verbindung zwischen einer 1515-2PN und einer 1214C über ISO on TCP am laufen.
Zwischen den beiden SPSßsen werden derzeit 54Byte bewegt . Denn Senden und Empfangen Auftrag stoße ich jeweils mit einem Taktmerker M0.0 10Hz an.

Jetzt stellen sich mir jedoch 2 Fragen ich habe vermehrt das Problem wenn ich etwas im Programm oder in den DB´s die versendet werden ändere dass, meine Verbindung sich aufhängt versetze ich beide SPS´sen in STOP und Run funktioniert es meist gleich wieder ist das normal oder liegt es wohl an einem Programmierfehler ?

Als ich letztens die 1515er vom Datennetz getrennt habe um einen Kommunikationsausfall zu testen lief die Verbindung danach auch nicht wieder selbstständig an (war bis jetzt aber erst einmal).

Kann ich das irgendwie verhindern das ich aus der ferne erst beide SPS´sen "Neustarten" muss ??


Danke schonmal im vorraus
 
Vielleicht sind die 10Hz zu schnell als Takt, hast du es mal mit 2 Hz versucht? Nur zum testen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jetzt stellen sich mir jedoch 2 Fragen ich habe vermehrt das Problem wenn ich etwas im Programm oder in den DB´s die versendet werden ändere dass, meine Verbindung sich aufhängt versetze ich beide SPS´sen in STOP und Run funktioniert es meist gleich wieder ist das normal oder liegt es wohl an einem Programmierfehler ?

Als ich letztens die 1515er vom Datennetz getrennt habe um einen Kommunikationsausfall zu testen lief die Verbindung danach auch nicht wieder selbstständig an (war bis jetzt aber erst einmal).

Kann ich das irgendwie verhindern das ich aus der ferne erst beide SPS´sen "Neustarten" muss ??

Sicher das du die Instanz der Verbindungsbausteine nicht neu geladen hast? Das mögen diese nämlich nicht.
Ausserdem sit 10Hz schon recht sportlich. Wenn du möglichst schnell senden willst. Mach das nicht mit nem Taktmerker sondern warte Done/Error ab um einen neuen Auftrag anzustossen.
 
10Hz Sendetakt sind wirklich sehr sportlich! Gerade auch mit einer 1200er CPU als Gegenstelle. Allgemein gilt: Erst nach Done/Error darf neu getriggert werden und du brauchst mindestens 2 Zyklen zum Senden/Empfangen. (Einen zum Triggern und mindestens einen, um auf Done/Error zu warten) Das heißt die Zykluszeit muß auf beiden Seiten deutlich unter 50ms besser unter 30ms liegen, damit es funktionieren kann. Bei sehr kurzen Zykluszeiten hilft eine günstig eingestellte Mindestzykluszeit der Datenübertragung Zeit zu verschaffen, denn die Übertragung selbst findet in den Zykluspausen statt.
Ansonsten wäre meine Frage nach der Firmware. Mit den Versionen <2.5 auf der 1500er hatte ich Probleme mit Abstürzen, mit Version 1.8.x sogar reproduzierbar.

Normalerweise baut die SPS eine aktive aber abgebrochene Verbindung selbst wieder auf. Prüfe mal das Verhalten deines Programms im Fehlerfall.
 
Sicher das du die Instanz der Verbindungsbausteine nicht neu geladen hast? Das mögen diese nämlich nicht.
Ausserdem sit 10Hz schon recht sportlich. Wenn du möglichst schnell senden willst. Mach das nicht mit nem Taktmerker sondern warte Done/Error ab um einen neuen Auftrag anzustossen.

Ich lade meistens die Software komplett da will ich nicht ausschließen das ich die Instanzen mit lade.


Meine 1214C besitzt die Version 4.2 und die 1515-2PN die Version 2.6

Ich werde erst einmal versuchen den Taktmerker zu verlangsamen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe jetzt mal den Taktmerker auf 2 Hz geändert.

Hab es in beide SPS´sen geladen jedoch ging das Programm nicht los, erst nachdem ich in beiden SPS´sen die Speicherreserve zurückgesetzt habe und sie von Run auf Stop geschalten habe lief es wieder.




Also ich habe gerade noch mehrere male kurz die Ethernetverbindung getrennt. Irgendwann hatte ich wieder den Fall das die SPS´sen keine Verbindung wieder aufbauten. Der Send Baustein hatte den Status 16#7004 und RCV 16#7006. Nachdem ich beide SPS´sen von Run in Stop gesetzt hatte lief es irgendwann wieder.
 
Zuletzt bearbeitet:
766C2675-BECE-4562-AEA7-10E4BFC90B7B.jpgA9321200-352F-4486-82F7-5235CB95258C.jpgJeweils senden hat eine Gemeinsame ID und empfangen
also 1515 Send ID1 —— 1214C RCV ID 1
1515 RCV ID 2 —— 1214C Send ID 2

Die 1500er baut jeweils Aktiv die Verbindung auf
 
Wie lautet denn der genaue Fehlercode der FBs wenn die Kommunikation nicht mehr funktioniert?
Wenn du einfach einen Taktmerker auf den REQ schaltest ohne irgendwelche Zustände zu beachten, musst du eben damit rechnen dass nicht jeder Aufruf funktioniert. So wird das auch eigentlich nicht gemacht.
 
@Thomas_v2.1 Was im FB steht weiß ich ehrlich gesagt nicht ich habe immer nur auf den TRCV oder TSend geschaut.

Ich dachte immer man man muss die Verbindung mit einem Taktmerker anstoßen ?.

@Stefan1994 Ich werde den REQ bei Gelegenheit mal mit Busy oder Done verriegeln.

@Ralle Ich habe mir den Post mal durchgelesen wusste ich bis jetzt nicht das es reicht einen C Baustein zu haben. Muss ich mal testen.


aber das die aktive Verbindung von einer CPU ausgeht ist richtig oder ?
 
Am Empfangsbaustein brauchts auch keinen Trigger. Der kann permanent auf TRUE stehen. Dann werden die Daten auch immer geholt.
Beim zu schnellen senden ist das Problem das irgendwann der Puffer im CP voll läuft und die Werte die von einer Steuerung zur anderen geschickt werden anfangen zu "laggen" also die Übertragung fast einzufrieren scheint. Deswegen auf jeden Fall das DONE-Bit abwarten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So jetzt habe ich das ganze noch einmal überarbeitet. Ich habe in jeder SPS nur noch einen Baustein mit C zur Verbindungsherstellung. Außerdem habe ich versucht mein Sende Signal zu verriegeln.
Falls sich doch mal was aufhängt wollte ich das ganze mit einem T_Reset neu aufbauen lassen. Ich überwache Quasi ein Lebensbit und wenn sich das ganze 10 Sekunden lang nicht ändert wird die Verbindung resettet bzw. kann über ein Touch Panel manuell resettet werden.
Sind jetzt immer noch grobe Fehler im Programm oder ist es so umsetzungsfähig ?Übertragung.jpg
 
Sei nicht so "sparsam" und spendiere dem TRCV ein eigenes Netzwerk.
Dein symbolischer Name für die Verbindungsbeschreibung (an TSEND_C.CONNECT) ist irreführend.

Harald
 
Es wird so grundsätzlich funktionieren.
Ich persönlich ziehe den TRECV_C dem TSEND_C vor. Das hat keinen Funktionellen Hintergrund. Aber der Recv ist für sich eh immer aktiv am hören. Dann kann man ihm auch grad die Aufgabe überlassen die Verbindung zu überwachen.
TSEND macht dann die zu sendenden Telegramme auf trigger. Und wie gesagt. den Req würde ich nicht per takt antriggern sondern entweder auf Ereignis (üblicherweise bei Treibern angebracht) oder nur auf done/error (üblicherweise bei stehender Kommunikation). Done/Error würde ich immer zum rücksetzen des Req nutzen.

mfG René
 
Zurück
Oben