Step 7 Daten in Ethernet-Verbindung springen

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen, entschuldigt bitte die späte Rückmeldung, ich bin im Moment sehr im Stress.

@move: Das funktioniert leider auch nicht, habe ich auch schon vorher alles probiert. Bausteine sind aus der 300er Bibliothek

Zuerst einmal Zitat vom Siemens-Support wegen der Kompatibilität:

"das von Ihnen beschriebene Verhalten kommt vermutlich daher, dass der von Ihnen verwendete CP nicht für den Einsatz mit IhrerCPU freigegeben ist (CPU 6ES7 315-2AF01-0AB0 schon seit 01.10.2008 abgekündigt)
Sie benötigen mindestens eine CPU mit einer Bestellbezeichnung > 6ES7 315-2AF03-0AB0
siehe Handbuch "S7-300 - Industrial Ethernet / PROFINET CP 343-1 Handbuch Teil B" Seite 24
https://support.industry.siemens.com/cs/de/de/view/24485272
"
Doch wie bereits erwähnt, hat auch der Einsatz einer CPU 318 nicht geholfen.

Ich bin jetzt aber auf einer heißen Fährte und denke auch die Ursache gefunden zu haben.
Ich habe Telegramme einzeln im Abstand von einer Minute geschickt, um die "Sprungweite" auf der Empfängerseite herauszufinden.
Dabei kam heraus, dass es immer genau 28 Byte Abstand sind. Daraufhin habe ich die Telegrammlänge auf 76 Byte erhöht, und siehe da, es funktioniert.
Zumindest die ersten 44 Byte. Die letzten 4 Byte sind einzelne Bits.
Da diese nicht angekommen, der Rest aber schon, vermute ich, dass auf der TDC-Seite für jedes projektierte Bit ein Byte in der Verbindung reserviert wird.
Das würde auch die Abweichung von 28 Byte erklären.
Beim nächsten Produktionsstopp werde ich auf der TDC-Seite die 32 Bits durch 2 Worte ersetzen und die Telegrammlänge in der S7 wieder auf 48 Byte reduzieren.
Ich denke/hoffe, dass es dann funktionieren sollte.
Ich gebe dann auf jeden Fall nochmal Rückmeldung.

Und Danke für euren bisherigen Tipps!!!

Gruß Micha
 
Hallo Micha.

Ich bin jetzt aber auf einer heißen Fährte und denke auch die Ursache gefunden zu haben.
Ich habe Telegramme einzeln im Abstand von einer Minute geschickt, um die "Sprungweite" auf der Empfängerseite herauszufinden.
Dabei kam heraus, dass es immer genau 28 Byte Abstand sind. Daraufhin habe ich die Telegrammlänge auf 76 Byte erhöht, und siehe da, es funktioniert.
Die heiße Fährte wurde Dir bereits seit 3 Wochen mehrfach genannt, unter anderem sogar direkt die erste Antwort:
Beim Empfänger muß die gleiche Telegrammlänge wie beim Sender parametriert werden (an den SEND- und RECEIVE-Bausteinen).
Ich würde auch stark vermuten, dass der PC mehr als 48 Byte sendet.


allerdings haben wir die Datenlänge schon mehrfach auf beiden Seiten überprüft. Werde das aber morgen noch einmal machen. Die TDC-Seite habe nicht ich persönlich überprüft.
Wie/Was habt Ihr da eigentlich überprüft?
Ihr müsst überprüfen, ob beim TDC die selbe Anzahl Bytes gesendet wird wie bei Deiner 315 mit AG_RECV empfangen werden soll ( = Zugriffsbreite des ANY an RECV). Und in der Gegenrichtung, ob das TDC die selbe Anzahl Bytes empfangen soll, wie Deine 315 mit AG_SEND sendet ( = Wert an LEN).
Was für Bausteine/Anweisungen benutzt das Simatic TDC zum Senden und Empfangen? Magst Du mal ein Bild von dem Sendeprogramm des TDC zeigen? Ich vermute die Ursache Deines Problems im Programm des TDC.


vermute ich, dass auf der TDC-Seite für jedes projektierte Bit ein Byte in der Verbindung reserviert wird.
Das würde auch die Abweichung von 28 Byte erklären.
Üblicherweise muß an Sendebausteinen angegeben werden wieviele Bytes gesendet werden sollen, der Inhalt der Sendung interessiert nicht, sprich die Sendebausteine interpretieren oder verändern den Datenstrom nicht. Für die Telegrammlänge ist es dem Sendebaustein völlig egal, ob Bools als Bit oder Byte gespeichert werden oder was überhaupt in dem Sendepuffer liegt - z.B. AG_SEND sendet exakt die am Eingang LEN angegebene Anzahl Bytes.

Wir hatten Dir auch empfohlen, mit Wireshark zu sniffen oder mit einem Terminalprogramm testweise zu empfangen - damit hättest Du die tatsächliche Telegrammlänge gesehen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das Thema ist ja schon bissl älter. Ich bin jetzt drauf gestoßen, weil ich ein ähnliches Problem habe und muss das zur Sicherheit nochmal fragen:
Habe ich das richtig verstanden, dass ich mit AG_RECV immer nur eine exakt definierte Telegrammlänge vernünftig empfangen kann?

Die Gegenseite zu der S7-300 mit CP343-1 ist bei mir ein Gerät, welches Telegramme in unterschiedlicher Länge sendet und das ist auch nicht beeinflussbar!

Roland
 
Hallo Harald,
danke für die schnelle Antwort. Bei der hier beschriebenen Lösung müssen aber wohl von der Sendeseite Informationen über die Länge mitgegeben werden. Wie ich schon geschrieben habe, ist die Gegenseite, von der ich Daten empfangen möchte, aber nicht beeinflussbar. Das einzige was sicher ist, ist dass als Endezeichen immer CR kommt ...
Ich schau mir das Programmbeispiel aber nochmal an, ob ich das (ggf. abgewandelt) trotzdem irgendwie verwenden kann.

Roland
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn Du jedes Zeichen einzeln vom CP abholst, dann muß der Sender keine Information über die Länge mitgeben. Er muß einfach nur den Nachrichten-Rahmen laut Protokoll einhalten (hier max. Nachrichtenlänge und das Endezeichen CR).
Es ist eigentlich einfach: Du als Empfänger holst immer nur 1 Zeichen vom CP ab und packst es in einen selbstverwalteten Empfangspuffer (z.B. Array of Char). Wenn das Zeichen das Endezeichen CR ist, dann kannst Du die komplette empfangene Nachricht aus dem Empfangspuffer entnehmen (Pufferzeiger wieder auf den Pufferanfang stellen) und auswerten. Achtung: möglichen Empfangspuffer-Überlauf beachten!
Falls die Empfangsnachricht sehr lang ist oder der Sender zu schnell sendet oder die SPS-Zykluszeit zu lang ist und der Empfangspuffer des CP überläuft, dann kannst Du AG_RECV nach Empfang eines Zeichens sofort nochmal aufrufen, um die Zeichen schneller abzuholen.

Harald
 
Ja, nachdem ich gestern noch paar Versuche gemacht habe, bin auch drauf gekommen: ich programmier 'ne Schleife und wenn ich ein "CR" empfange, spring ich raus.
Aktuell hab ich das Problem, wie ich die empfangenen Bytes in meine "Ausgabe" einsortiere ...

Ich empfange ein Byte in die Variable "Buffer", zähle die empfangenen Zeichen hoch und transferiere das aktuelle Ergebnis an die entsprechende Stelle in der Array-Variable "Ausgabe".
würde direkt adressiert etwa so aussehen:

L #BUFFER
T #Ausgabe[1]

soll aber eigentlich indirekt adressiert werden; wie z.B. so:

L #BUFFER
T #Ausgabe[#zeichenzaehler]

Geht das und wenn ja, wie?

... muss wahrscheinlich mit Pointer gemacht werden, oder? Da kenn mich leider nicht so gut aus. ;-(

Roland
 
Hallo Harald, ich hab deine Antwort zu meiner letzten Frage bereits in einem anderen Thema im Forum gefunden! :)
Danke!

Roland
 
Zurück
Oben