CP343-1 Advance / Libnodave Puffer voll?

Hand

Level-1
Beiträge
35
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo, ich lese und schreibe mit Libnodave alle 200ms 4 Datenbausteine mit jeweils 50Bytes nach einiger Zeit kommen lauter Timeouts und über MPI kann ich mit dem PG auch nichts mehr laden.

Nach dem abziehen des Ethernetkabels blinkt die TX/RX led noch paar mal jede Sekunde auf und dass gehts wieder.

Ich vermute dass irgendein Puffer im CP bzw. in der CPU überläuft.

Kann man das mit Libnodave irgendwie abfragen so dass ich die DB's nur polle wenn der letzte Pollvorgang bearbeitet wurde?

Habe vorher mit Fetch/Write gearbeitet da hatte ich das selbe Problem.

Mir fällt jetzt nur noch UDP bzw TCP ein, damit läuft eine andere Anlage seit 3 Jahren problemlos. Hat allerdings den Nachteil dass ich dann Code in der CPU benötige

mfg Andreas
 
ich lese und schreibe mit Libnodave alle 200ms 4 Datenbausteine mit jeweils 50Bytes
Das sollte ohne Probleme funktionieren. Beschreib mal etwas genauer, wie du das machst: schließt Du die Verbindung zu CPU immer wieder, oder läßt Du sie offen, schreibst bzw. ließt Du die 50 Bytes am Stück, oder einzelne Bytes usw. ?

Gruß Axel

PS: Puh, geschafft ... mit Ralle gleichzeitig online und trotzdem schneller ... ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich lese die DB's am Stück d.h. ein Kommando pro DB

Es ist übrigens eine alte 315-2 DP vielleicht liegts ja daran?

Die Verbindung lasse ich offen, ausser bei einem lese/schreibfehler schliese ich die Verbindung und connecte neu
 
Ob da was abzufragen geht, kann ich nicht sagen, das wird sicher Zottel beantworten können.

Selbst hatte ich die Probleme noch nicht, aber ich lese auch mehr aus der Steuerung und schreibe nur ein paar Quittierungsbytes.

Eine Möglichkeit wäre auch hier, ein Toggelbyte (oder Bit) mitzuschicken, in der SPS zu toggeln (oder hochzuzählen, was auch immer) und dann im Programm die Antwort auszuwerten. Hat die SPS das Byte (Bit) geändert, kann man das nächste Paket abschicken.

@afk

Will dir ja auch ma ne Chance geben :ROFLMAO:, obwohl...
 
Ich lese die DB's am Stück d.h. ein Kommando pro DB
Eine Leseanforderung nach der nächsten ? Dann wäre das soweit OK, die 4 Leseanforderungen müßten dann so um die 40ms dauern ...

Schreibst Du auch ?

Die Verbindung lasse ich offen, ausser bei einem lese/schreibfehler schliese ich die Verbindung und connecte neu
Das ist bestens, so mache ich das auch.

Ich kann immer noch keinen Grund für das beschriebene Verhalten erkennen. Bist Du der einzige, der auf der SPS herumackert ?


Gruß Axel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So habe das Problem gelöst.

Es war die CPU, eine alte 315-2DP habe ich durch eine neue schmale 315-2DP ersetzt und jetzt funktioniert es einwandfrei auch mit Pollraten von 250ms

Ich kann es mir nur so erklären dass die Firmware der alten CPU eine Bug in der Kommunikation hat.

mfg Andreas
 
@Hand @afk

Eine Frage noch, wie lange wartet ihr mit dem neu connecten oder schließt ihr das sofort an?
 
Wenn ein Verbindungsfehler bzw. -abbruch erkannt wird, dann stößt meinem Programm sofort einen neuen Verbindungsaufbau an. Der Timeout vom TCP/IP-Stack in Windows nimmt ja schon einige Zeit in Anspruch, da empfinde ich eine weitere Wartezeit als überflüssig.


Gruß Axel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
So habe das Problem gelöst.

Es war die CPU, eine alte 315-2DP habe ich durch eine neue schmale 315-2DP ersetzt und jetzt funktioniert es einwandfrei auch mit Pollraten von 250ms

Ich kann es mir nur so erklären dass die Firmware der alten CPU eine Bug in der Kommunikation hat.

mfg Andreas
Gib doch mal Bestellnummern und Firmwarestand der CPUs an. Libnodave wurde überwiegend auf einer "alten" (doppeltbreiten) 315er getestet.
 
Zurück
Oben