TIA Daten von einem Server/TCP mit TIA auslesen

[Marcel89]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich möchte mit einer S7-1200 von einem Server über das TCP Protokoll Daten auslesen.
Nun habe ich schon mit dem Baustein TRCV_C die Daten ausgelesen. Bekomme aber nur Müll dabei raus.
Habe als Vergleich mit dem Tool Sockettester mal die Daten ausgelesen, die von dem Datenserver kommen.



Weiß wer was ich tun kann, damit ich die Daten lesen kann?
Der Header scheint sich nicht zu verändern(SAEMY9z).

Gruß

 

[oliver.tonn]

Die Frage wäre, wie muss es richtig aussehen?
Die Daten in Deinem Thread sind eine Mischung aus binären Daten und ASCII Daten, was aber durchaus in Ordnung sein kann.
Dann wäre auch die Frage, was Du schickst, um diese Daten zu erhalten? Zeig hier vielleicht auch mal einen Code Ausschnitt.

 

[Marcel89]

Zuviel Werbung?
-> Hier kostenlos registrieren

2 Sensoren ermitteln eine Dicke eines Bauteils. Daraus errechnet eine Weboberfläche von einem Hersteller eine Dicke und diese soll per Ethernet Server/TCP abrufbar sein.
Das ist die Anleitung vom Hersteller zu diesem Daten Senden:

Bei mir ändern sich die Daten/Zeichen aber sekündlich. In der SPS steht auch nie in einem Datenword immer der selbe Kram.
Ziel war es eigentlich die errechnete Dicke des Bauteils über TCP einzulesen und diese dann weiter zuverarbeiten.

 

[PN/DP]

Bei mir ändern sich die Daten/Zeichen aber sekündlich. In der SPS steht auch nie in einem Datenword immer der selbe Kram.

Vielleicht rufst du nicht die richtige Datensatzgröße ab und erhältst eine andere Menge an Daten? Oder rufst du verschiedene Datensätze ab, die unterschiedlich groß sind?
Dann verschiebt sich die Lage der Empfangsdaten im Empfangspuffer.
Wie forderst du die Daten an? Zeige mal etwas Code.

 

[oliver.tonn]

Auf den ersten Blick würde ich mal sagen, dass die Antwort, mal abgesehen von der Präambel, die immer der String MEAS ist, der Rest keine ASCII Zeichen sind, sondern Binärdaten. Statt in einem String müsstest Du das Ganze in ein Byte Array ablegen und in einen UDT.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wo die empfangenen Zeichen abgelegt werden, ist im Grunde egal, die Empfangsdaten werden ja nicht konvertiert. Erst wenn man die Daten aus dem Empfangspuffer in Variablen umkopiert, muss man den Datentyp beachten und evtl. konvertieren.
Den Empfangspuffer als Struct/UDT anlegen ist aber meist hilfreich für das anschliessende umkopieren.

 

[Marcel89]

Programm ist nicht viel:


ich wollte das Ganze erst mit dem LCom_Communication Baustein machen. damit ging es aber irgendwie gar nicht.

 

[Marcel89]

Als Bereichslänge hab ich 100Byte genommen. Bei der Herstelleranleitung war weniger definiert.

 

[Marcel89]

Zuviel Werbung?
-> Hier kostenlos registrieren

Unabhängig von der SPS kommt im Sockettester ja das selbe an Datenmüll an.
Deswegen würde ich vermuten, dass meine Datenabfrage nicht so ganz falsch ist.

 

[PN/DP]

Als Bereichslänge hab ich 100Byte genommen. Bei der Herstelleranleitung war weniger definiert.

Die Bereichslänge soll genau soviele Zeichen lang sein, wie das Antwort-Telegramm/Messwertframe lang ist. Wenn zu lang, dann gibt TRCV erst dann die angeforderte Zeichenanzahl zurück, wenn genügend Zeichen vom nächsten Frame empfangen wurden, und die Lage der Frames im Empfangspuffer verschiebt sich mit jedem Zeichen-abholen.

Unabhängig von der SPS kommt im Sockettester ja das selbe an Datenmüll an.

Das ist kein Müll, sondern du Mensch verstehst die Zeichen nicht, weil sie binär codiert sind.

 

[oliver.tonn]

Unabhängig von der SPS kommt im Sockettester ja das selbe an Datenmüll an.Anhang anzeigen 75080
Deswegen würde ich vermuten, dass meine Datenabfrage nicht so ganz falsch ist.

Das ist kein Datenmüll, nur der Header wird als ASCII übertragen, alles andere sind binäre Werte und wenn diese nicht gerade im Bereich eines druckbaren Zeichens liegen, wird in einem String nur ein Ersatzzeichen angezeigt und beim Rest halt das dem ASCII Wert entsprechende Zeichen..

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Bereichslänge soll genau soviele Zeichen lang sein, wie das Antwort-Telegramm/Messwertframe lang ist. Wenn zu lang, dann gibt TRCV erst dann die angeforderte Zeichenanzahl zurück, wenn genügend Zeichen vom nächsten Frame empfangen wurden, und die Lage der Frames im Empfangspuffer verschiebt sich mit jedem Zeichen-abholen.

Das stimmt nicht ganz. Wenn Ad-hoc true ist geht der baustein davon aus, das mit dem empfangenen Frame alles komplett übertragen wurde und fängt beim nächsten wieder vorne an

TRCV: Daten über Kommunikationsverbindung empfangen (S7-1200, S7-1500)
TCP (Ad-hoc-Modus)
Den Ad-hoc-Modus gibt es nur bei der Protokollvariante TCP. Den Ad-hoc-Modus verwenden Sie, um mit der Anweisung "TRCV" Daten mit dynamischen Längen zu empfangen.
Den Ad-hoc-Modus stellen Sie ein, indem Sie dem Parameter ADHOC den Wert "1" zuweisen. Ist der Ad-hoc-Modus aktiviert, wird der Datenempfang schon nach einem empfangenen Byte am Parameter NDR gemeldet. Bei Verwendung des Ad-hoc-Modus können für Datenbausteine mit Standardzugriff alle Datentypen verwendet werden. Für Datenbausteine mit optimiertem Zugriff können als Datentypen nur ARRAY of BYTE oder Datentypen mit einer Länge von 8 Bit verwendet werden (z. B. CHAR, USINT, SINT, etc.).

TCP (Datenempfang mit angegebener Länge)
Für einen Datenempfang mit angegebener Länge weisen Sie dem Parameter ADHOC den Wert "0" zu. Ist der Ad-hoc-Modus deaktiviert, wird der Datenempfang erst abgeschlossen, wenn die am Parameter LEN angegebene Länge der Daten vollständig empfangen wurde. Erst danach sind die Daten im Empfangsbereich (Parameter DATA) verfügbar. Der erfolgreiche Datenempfang wird durch den Ausgangsparameter NDR gemeldet. Die tatsächlich empfangene Datenlänge in Bytes am Parameter RCVD_LEN entspricht nach dem Empfang der Datenlänge am Parameter LEN.

wo kommt 'readData Lengh' her? das scheint mir ungewöhnlich hoch mit 4294967295

 

[PN/DP]

Das stimmt nicht ganz. Wenn Ad-hoc true ist geht der baustein davon aus, das mit dem empfangenen Frame alles komplett übertragen wurde und fängt beim nächsten wieder vorne an

TRCV: Daten über Kommunikationsverbindung empfangen (S7-1200, S7-1500)
TCP (Ad-hoc-Modus)
Den Ad-hoc-Modus gibt es nur bei der Protokollvariante TCP. Den Ad-hoc-Modus verwenden Sie, um mit der Anweisung "TRCV" Daten mit dynamischen Längen zu empfangen.
Den Ad-hoc-Modus stellen Sie ein, indem Sie dem Parameter ADHOC den Wert "1" zuweisen. Ist der Ad-hoc-Modus aktiviert, wird der Datenempfang schon nach einem empfangenen Byte am Parameter NDR gemeldet.

Aha... das lese ich da aber nicht so raus. Ich lese da eher, dass unbedingt auch noch RCVD_LEN ausgewertet werden muss, um das empfangene Telegramm in einem zweiten Puffer zusammenzusetzen oder die Lage im Empfangspuffer festzustellen. Woher soll TRCV die Frame-Länge wissen? Von Sendepausen zwischen Frames?

 

[volker]

Ich kann da nur aus Erfahrung sprechen. Ich mache das bei einer Verbindung mit einem PC der auch über TCP sendet und die Datenlänge nicht immer gleich ist. Auch ich habe bei Len 0 angegeben.
Schalte ich AdHoc auf false kommt Datenmüll zustande.
Und solange die maximale Länge des TCP-Segments (1500 Byte inkl. Header) nicht überschritten wird sollte das auch funktionieren.
Die gesendete Länge gibt der Baustein ja raus

 

[Marcel89]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das stimmt nicht ganz. Wenn Ad-hoc true ist geht der baustein davon aus, das mit dem empfangenen Frame alles komplett übertragen wurde und fängt beim nächsten wieder vorne an

wo kommt 'readData Lengh' her? das scheint mir ungewöhnlich hoch mit 4294967295

das kam von dem Baustein aus einer Bibliothek. Den hab ich ja gar nicht erst ans laufen gebracht. Die Zahl ist irreführend. hat keine Bedeutung zur Zeit.

 

[Marcel89]

Hab auch schon RCVD_LEN abgelesen und bei LEN eingetragen und Optimierter Zugriff abgewählt. Alles Leider das selbe Ergebnis

 

[Olli_BS]

Ich kann da nur aus Erfahrung sprechen. Ich mache das bei einer Verbindung mit einem PC der auch über TCP sendet und die Datenlänge nicht immer gleich ist. Auch ich habe bei Len 0 angegeben.
Schalte ich AdHoc auf false kommt Datenmüll zustande.
Und solange die maximale Länge des TCP-Segments (1500 Byte inkl. Header) nicht überschritten wird sollte das auch funktionieren.
Die gesendete Länge gibt der Baustein ja raus

Kann ich auch so aus meinen kleinen Welt bestätigen.
TCP nur mit Adhoc, weil sonst bei einmal Versatz >> Assynchron Busdaten <> Daten von Receive Baustein
(Oder man schreibt das ISOonTCP-Protokoll noch mal selber....)
Eigentlich ist TCP für SPS Anwendungen doof.

 

[volker]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hab auch schon RCVD_LEN abgelesen und bei LEN eingetragen und Optimierter Zugriff abgewählt. Alles Leider das selbe Ergebnis

Wie groß ist den die empfangene Datenlänge?

 

[Marcel89]

Unterschiedlich mal hat er 12 mal 18 gerade 64

 

[PN/DP]

Stell die Soll-Länge so ein, wie das Empfangsprotokoll laut Hersteller-Doku lang ist und kein Adhoc und werde glücklich.