Need4Speed
Level-1
- Beiträge
- 31
- Reaktionspunkte
- 0
-> Hier kostenlos registrieren
Hallo zusammen,
ich möchte gerne im OB35 (aktuell auf 10ms eingestellt) mit BSEND 960 Bytes (die PDU wurde mit 240 ausgehandelt, also sind es 4x PDU). Als Gegenstelle verwende ich einen Linux PC mit der Snap7 Bibliothek, der hält also sehr gut mit.
Soweit funktioniert das auch, allerdings arbeitet BSEND ja asynchron und kann lt. Dokumentation mehrere Zyklen brauchen, bis er wieder bereit ist, die nächsten Daten zu senden - leider tut er das auch. Ich habe es so programmiert, dass in meinem "Header" der Zeitstempel vom Aufruf des SFC 1/READ_CLK steht, und zusätzlich zähle ich die Sequenz / Counter hoch, so dass ich auf dem Linux PC sehen kann, ob ich Daten von jedem OB35 Aufruf bekomme, oder ob eben Daten fehlen bzw. ausgelassen werden.
Was ich nun sehe ist, dass ich vom BSEND nur alle 20ms neue Daten bekomme, was auch zur Sequenznummer passt, da sehe ich auch nur jede zweite. D.h. ich bin mir ziemlich sicher, dass der BSEND nicht schnell genug übertragen kann.
Zuerst hatte ich das Phänomen auf einer 315 PN/DP gesehen, da habe ich dann in der HW Konfiguration den Anteil der "Kommunikation" auf 50% der Zykluszeit gestellt - damit hat es dann wirklich funktioniert, so dass nur alle Datenblöcke angekommen sind.
Leider hat das bei einer CPU 317F-3 PN/DP, welche als Bestandteil einer Sinumerik 840d läuft, nicht funktioniert; diese liefert trotz der 50% Kommunikationsanteil immer nur jeden zweiten Datenblock.
Der Unterschied ist natürlich auch, dass in dem Projekt der CPU 317F-3 PN/DP in der Sinumerik ca. 10 PROFINET Teilnehmer sind - da ist also ohnehin mehr auf dem Ethernet/PROFINET los, sozusagen.
Jetzt meine Frage: habt ihr noch einen Tipp, wie ich der CPU 317F-3 PN/DP Kommunikation Beine machen kann? Bringt es was, den BSEND auf zwei Verbindungen "aufzuteilen" oder die Daten im OB35 zu puffern, und dann statt 960 Bytes pro Aufruf, 1920 Bytes zu übertragen? Erste schnelle Tests deuten nicht darauf hin.
Wäre USEND (UDP, ungesicherte Kommunikation) eine Alternative? Aber dazu finde ich extrem wenig Dokumentation, auch nicht, was der Unterschied zwischen USEND und USEND_E ist.
Aber eigentlich wäre es am besten, dem BSEND einfach mehr Kommunikationskapazität einzuräumen, falls das irgendwie geht.
Die Linkliste von Harald habe ich schon ausführlich studiert Linkliste SIMATIC-Kommunikation über Ethernet aber auch keine echte Idee gefunden, an welchen Stellen man noch drehen könnte.
Hat jemand einen Tipp?
Vielen Dank vorab und viele Grüße, Jürgen
ich möchte gerne im OB35 (aktuell auf 10ms eingestellt) mit BSEND 960 Bytes (die PDU wurde mit 240 ausgehandelt, also sind es 4x PDU). Als Gegenstelle verwende ich einen Linux PC mit der Snap7 Bibliothek, der hält also sehr gut mit.
Soweit funktioniert das auch, allerdings arbeitet BSEND ja asynchron und kann lt. Dokumentation mehrere Zyklen brauchen, bis er wieder bereit ist, die nächsten Daten zu senden - leider tut er das auch. Ich habe es so programmiert, dass in meinem "Header" der Zeitstempel vom Aufruf des SFC 1/READ_CLK steht, und zusätzlich zähle ich die Sequenz / Counter hoch, so dass ich auf dem Linux PC sehen kann, ob ich Daten von jedem OB35 Aufruf bekomme, oder ob eben Daten fehlen bzw. ausgelassen werden.
Was ich nun sehe ist, dass ich vom BSEND nur alle 20ms neue Daten bekomme, was auch zur Sequenznummer passt, da sehe ich auch nur jede zweite. D.h. ich bin mir ziemlich sicher, dass der BSEND nicht schnell genug übertragen kann.
Zuerst hatte ich das Phänomen auf einer 315 PN/DP gesehen, da habe ich dann in der HW Konfiguration den Anteil der "Kommunikation" auf 50% der Zykluszeit gestellt - damit hat es dann wirklich funktioniert, so dass nur alle Datenblöcke angekommen sind.
Leider hat das bei einer CPU 317F-3 PN/DP, welche als Bestandteil einer Sinumerik 840d läuft, nicht funktioniert; diese liefert trotz der 50% Kommunikationsanteil immer nur jeden zweiten Datenblock.
Der Unterschied ist natürlich auch, dass in dem Projekt der CPU 317F-3 PN/DP in der Sinumerik ca. 10 PROFINET Teilnehmer sind - da ist also ohnehin mehr auf dem Ethernet/PROFINET los, sozusagen.
Jetzt meine Frage: habt ihr noch einen Tipp, wie ich der CPU 317F-3 PN/DP Kommunikation Beine machen kann? Bringt es was, den BSEND auf zwei Verbindungen "aufzuteilen" oder die Daten im OB35 zu puffern, und dann statt 960 Bytes pro Aufruf, 1920 Bytes zu übertragen? Erste schnelle Tests deuten nicht darauf hin.
Wäre USEND (UDP, ungesicherte Kommunikation) eine Alternative? Aber dazu finde ich extrem wenig Dokumentation, auch nicht, was der Unterschied zwischen USEND und USEND_E ist.
Aber eigentlich wäre es am besten, dem BSEND einfach mehr Kommunikationskapazität einzuräumen, falls das irgendwie geht.
Die Linkliste von Harald habe ich schon ausführlich studiert Linkliste SIMATIC-Kommunikation über Ethernet aber auch keine echte Idee gefunden, an welchen Stellen man noch drehen könnte.
Hat jemand einen Tipp?
Vielen Dank vorab und viele Grüße, Jürgen
Zuletzt bearbeitet:
