LowLevelMahn
Level-2
- Beiträge
- 767
- Reaktionspunkte
- 90
-> Hier kostenlos registrieren
geht es mit tinyupload.com?
TIA Protokoll einfangen
- Ersteller Erik10
- Erstellt am
-> Hier kostenlos registrieren
- Beiträge
- 24.663
- Reaktionspunkte
- 7.900
Mit welcher SPS kommunizierst Du nun mit der Waage?
Wie holst Du die empfangenen Zeichen von der PN-Schnittstelle in Dein Programm? Die Nachricht von der Waage sollte immer konstant die selbe Länge haben. Eventuell streut die Waage zusätzliche Zeichen oder Nachrichten in die erwarteten Nachrichten ein? - das sollte man anhand der Start- und -Endezeichen oder an festen Zeichen in der Nachricht erkennen können.
Anstatt rumzurätseln welche unsichtbaren Steuerzeichen eventuell in dem Empfangstelegramm enthalten sein könnten, wäre es wohl besser, sich an die Dokumentation des Waage-Kommunikationsprotokolls zu halten und alles zu verwerfen was sich nicht exakt daran hält. Damit hier helfende Forumsmitglieder das Kommunikationsprotokoll kennen, wäre es vorteilhaft, wenn Du uns einen Downloadlink oder Auszüge der Protokollbeschreibung geben würdest. (die Frage nach einer Kommunikations-Doku steht schon seit 1 Woche unbeantwortet)
Allgemeine Tips:
Du darfst den Empfangspuffer nur auswerten, wenn der Empfangsbaustein (TRCV?) den Empfang der angeforderten Anzahl Zeichen meldet.
Der Empfangspuffer am Empfangsbaustein sollte nicht in TEMP liegen, für den Fall, daß der Empfangsbaustein die empfangenen Zeichen über mehrere Programmzyklen in den Empfangspuffer kopiert.
Löschen des Empfangsspeichers ist eigentlich nicht nötig, weil der Empfangsbaustein jedes empfangene Zeichen nur einmal liefert und automatisch aus dem Empfangsspeicher der PN-Schnittstelle löscht.
Wenn die Zeichen der Nachricht mit String-Funktionen (z.B. CONCAT) verarbeitet werden sollen, dann muß die Nachricht (und jede zu verarbeitende Teil-Nachricht) das S7-String-Format haben - üblicherweise senden fremde Kommunikationspartner nicht im S7-String-Format und man muß selber geeignete String-Header dem Zeichenstrom hinzufügen oder die Zeichen in Strings mit korrektem Header kopieren.
Wenn die Nachricht im Empfangspuffer so verschoben ist - was machst Du dann? Verschwindet die Verschiebung von alleine wieder?
Deine Beispiele sehen nicht nur verschoben aus, sondern auch zerstört (falsche Zeichen) - schreibt vielleicht Dein Programm (ungewollt?) in den Empfangspuffer? Oder liegt das an unkorrekter Stringverarbeitung?
Harald
Wie holst Du die empfangenen Zeichen von der PN-Schnittstelle in Dein Programm? Die Nachricht von der Waage sollte immer konstant die selbe Länge haben. Eventuell streut die Waage zusätzliche Zeichen oder Nachrichten in die erwarteten Nachrichten ein? - das sollte man anhand der Start- und -Endezeichen oder an festen Zeichen in der Nachricht erkennen können.
Anstatt rumzurätseln welche unsichtbaren Steuerzeichen eventuell in dem Empfangstelegramm enthalten sein könnten, wäre es wohl besser, sich an die Dokumentation des Waage-Kommunikationsprotokolls zu halten und alles zu verwerfen was sich nicht exakt daran hält. Damit hier helfende Forumsmitglieder das Kommunikationsprotokoll kennen, wäre es vorteilhaft, wenn Du uns einen Downloadlink oder Auszüge der Protokollbeschreibung geben würdest. (die Frage nach einer Kommunikations-Doku steht schon seit 1 Woche unbeantwortet)
Allgemeine Tips:
Du darfst den Empfangspuffer nur auswerten, wenn der Empfangsbaustein (TRCV?) den Empfang der angeforderten Anzahl Zeichen meldet.
Der Empfangspuffer am Empfangsbaustein sollte nicht in TEMP liegen, für den Fall, daß der Empfangsbaustein die empfangenen Zeichen über mehrere Programmzyklen in den Empfangspuffer kopiert.
Löschen des Empfangsspeichers ist eigentlich nicht nötig, weil der Empfangsbaustein jedes empfangene Zeichen nur einmal liefert und automatisch aus dem Empfangsspeicher der PN-Schnittstelle löscht.
Wenn die Zeichen der Nachricht mit String-Funktionen (z.B. CONCAT) verarbeitet werden sollen, dann muß die Nachricht (und jede zu verarbeitende Teil-Nachricht) das S7-String-Format haben - üblicherweise senden fremde Kommunikationspartner nicht im S7-String-Format und man muß selber geeignete String-Header dem Zeichenstrom hinzufügen oder die Zeichen in Strings mit korrektem Header kopieren.
Wenn die Nachricht im Empfangspuffer so verschoben ist - was machst Du dann? Verschwindet die Verschiebung von alleine wieder?
Deine Beispiele sehen nicht nur verschoben aus, sondern auch zerstört (falsche Zeichen) - schreibt vielleicht Dein Programm (ungewollt?) in den Empfangspuffer? Oder liegt das an unkorrekter Stringverarbeitung?
Harald
-> Hier kostenlos registrieren
ich nutze die 1214 DC/DC/DC
das einige Protkolle zerstört sind, ist auch meine Vermutung. Ich wüsste nicht warum mein Programm die String unkorrekt verarbeitet
Im Anhang befinet sich nun endlich die Hex-Darstellung von Whireshark und das Dokument zur Datenschnittstelle
Wenn ihr wollt kann ich mein Programm hochladen (ist zwar bisschen wild programmiert) , vielleicht findet ihr was
das einige Protkolle zerstört sind, ist auch meine Vermutung. Ich wüsste nicht warum mein Programm die String unkorrekt verarbeitet
Im Anhang befinet sich nun endlich die Hex-Darstellung von Whireshark und das Dokument zur Datenschnittstelle
Wenn ihr wollt kann ich mein Programm hochladen (ist zwar bisschen wild programmiert) , vielleicht findet ihr was
- Beiträge
- 24.663
- Reaktionspunkte
- 7.900
Die Ethernet-Schnittstelle ist in dem Dokument zwar nicht beschrieben, die Kommunikation scheint aber so abzulaufen:
Eventuell weitere Zeichen vom Status prüfen, z.B. wenn erstes Zeichen DS[1]='1' (16#31) --> Unterlast --> Gewicht als 0.0 zurückgeben.
Wenn die "Rahmen"-Prüfung fehlschlägt, dann könnte man suchen, ob ein Versatz um so-und-so-viele Zeichen vorliegt ('N' oder 'kg' suchen) und beim nächsten TRCV entsprechend weniger Zeichen lesen, damit beim übernächsten TRCV der Empfangsdatensatz an die richtige Position in DS[] kommt.
Harald
- man sendet (mit TSEND oder TSEND_C) eine 3 Zeichen lange Datensatz-Anforderung zur Waage: "<A>" (16#3C 16#41 16#3E)
("<F>" geht wohl auch bzw. ist einfacher zu handlen) - die Waage sendet daraufhin einen 22 Zeichen langen Standard Datensatz, der etwa so aussieht:
Code:"000101N -1000.0 kg " (16#: 30 30 30 31 30 31 4E 20 20 20 20 2D 31 30 30 30 2E 30 20 6B 67 20)
- mit TRCV holt man 22 Zeichen von der Ethernet-Schnittstelle in einen Empfangsspeicher (DS : ARRAY [1..22] OF CHAR)
- wenn 22 Zeichen empfangen, dann "Rahmen" prüfen:
wenn DS[7]='N' und DS[19]=' ' und DS[20]='k' und DS[21]='g' und DS[22]=' '
dann Zahlenwert von DS[8] bis DS[18] von ASCII nach REAL wandeln (" -1000.0" --> -1000.0)
Eventuell weitere Zeichen vom Status prüfen, z.B. wenn erstes Zeichen DS[1]='1' (16#31) --> Unterlast --> Gewicht als 0.0 zurückgeben.
Wenn die "Rahmen"-Prüfung fehlschlägt, dann könnte man suchen, ob ein Versatz um so-und-so-viele Zeichen vorliegt ('N' oder 'kg' suchen) und beim nächsten TRCV entsprechend weniger Zeichen lesen, damit beim übernächsten TRCV der Empfangsdatensatz an die richtige Position in DS[] kommt.
Weil die Waage keine S7-Strings sendet und man sich die Strings inkl. korrektem Header erst selber zusammenbauen muß. Machst Du das? (siehe TIA Hilfe zum Aufbau des Datentyps STRING)
Harald
LowLevelMahn
Level-2
- Beiträge
- 767
- Reaktionspunkte
- 90
Ich hänge mal die TCP/IP Kommunikation als HTML-Dump (mache ich mit einem kleinen Tool von mir) hier mit rein - dann kann man schöner sehen welcher Teilnehmer was sendet
ansonsten sieht das ja alles relativ einfach aus - die verarbeiten wie PN/DP Beschrieben hat sollte so funktionieren
Frage @Erik10
das gesendete "<A>" ist ja laut Doku "Sende Wert einmalig sofort" - aber was sind diese beiden Pakete {FF FA 2C 32 00 FF F0} die 2x am Anfang an die Waage gesendet werden? und zwischendurch kommen noch so y Y usw.
auf Seite 8 der Dokumentation sieht man den Aufbau ganz gut
ich würde bei Abweichung von diesem Schema erstmal einen Fehler melden
"Die Datensätze können über unser Service- Software angepasst, Steuercodes ergänzt und
verschiedenen Übertragungsmodi zugeordnet werden."
hast du die Service-Software? - ich würde die Defaulteinstellung belassen
ansonsten sieht das ja alles relativ einfach aus - die verarbeiten wie PN/DP Beschrieben hat sollte so funktionieren
Frage @Erik10
das gesendete "<A>" ist ja laut Doku "Sende Wert einmalig sofort" - aber was sind diese beiden Pakete {FF FA 2C 32 00 FF F0} die 2x am Anfang an die Waage gesendet werden? und zwischendurch kommen noch so y Y usw.
auf Seite 8 der Dokumentation sieht man den Aufbau ganz gut
Code:
[30 30 31 30 30 31 4E 20 20 20 20 20 20 37 37 33 2C 36 20 67 20 20} = "001001N 773,6 g "
1. 4 Zeichen mit "0" oder "1"
"0010" -> Status
x Unterlast
x Überlast
x Waagenstillstand
x Leermeldung
2. 2 Zeichen mit "0" oder "1"
"01" -> Waage - keine Ahnung was der Inhalt ist
3. "N" = Netto
4. 0-n Leerzeichen
5. Fließkommawert mit Komma und optionalem "-" davor
6. 1 Leerzeichen
7. "g" oder "kg" => Dimension
8. 2 Leerzeichen"Die Datensätze können über unser Service- Software angepasst, Steuercodes ergänzt und
verschiedenen Übertragungsmodi zugeordnet werden."
hast du die Service-Software? - ich würde die Defaulteinstellung belassen
Zuletzt bearbeitet:
LowLevelMahn
Level-2
- Beiträge
- 767
- Reaktionspunkte
- 90
-> Hier kostenlos registrieren
senden "<A>"
-->jetzt auf 22 Zeichen warten
... so könnten die 22 Bytes reintröpfeln - und das muss deine Verarbeitung auch können (wegen TCP/IP) - leicht zu testen wenn du mit Hercules einen TCP-Server aufmachst und so tust als wärst du eine Waage
empfangen "00"
empfangen "100"
empfangen "1N "
empfangen " 773,6 "
empfangen "g "
-->fertig!! 22 Bytes empfangen - Paket ist vollständig
im Puffer steht jetzt "001001N 773,6 g " - also genau 22 Zeichen
jetzt nur noch Prüfen ob alles stimmt und die 773,6 in ein REAL wandeln
-->jetzt auf 22 Zeichen warten
... so könnten die 22 Bytes reintröpfeln - und das muss deine Verarbeitung auch können (wegen TCP/IP) - leicht zu testen wenn du mit Hercules einen TCP-Server aufmachst und so tust als wärst du eine Waage
empfangen "00"
empfangen "100"
empfangen "1N "
empfangen " 773,6 "
empfangen "g "
-->fertig!! 22 Bytes empfangen - Paket ist vollständig
im Puffer steht jetzt "001001N 773,6 g " - also genau 22 Zeichen
jetzt nur noch Prüfen ob alles stimmt und die 773,6 in ein REAL wandeln
LowLevelMahn
Level-2
- Beiträge
- 767
- Reaktionspunkte
- 90
Klappt es jetzt?
Es ist immer wichtig überhaupt und schnell Feedback zu geben - so funktioniert das Internet-Frage/Antwort-Spiel
Es ist immer wichtig überhaupt und schnell Feedback zu geben - so funktioniert das Internet-Frage/Antwort-Spiel
- Beiträge
- 15.150
- Reaktionspunkte
- 3.631
Was LowLevelMahn sehr schön verdeutlicht hat ist :
Du mußt dir eine Art StateMachine um deine Kommunikation herum bauen. Nicht einfach gnadenlos etwas anfordern und dann darauf vertrauen, dass alles schon so passt, sondern :
- Schritt 1 : Anforderung senden
- Schritt 2 : warten bis alle benötigten Zeichen empfangen worden sind
- Schritt 3 : empfangene Daten kontrollieren und dann ggf. auswerten.
-> zurück zu Schritt 1 (oder irgendwann einmal dann "Abbruch des Ganzen"
vor Schritt 1 (beim ersten Mal) könnte noch ein genereller Receive stehen, der einfach nur ausliesst was ggf. schon/noch so im Port drinsteht ohne es zur Auswertung zu bringen ...
Gruß
Larry
Du mußt dir eine Art StateMachine um deine Kommunikation herum bauen. Nicht einfach gnadenlos etwas anfordern und dann darauf vertrauen, dass alles schon so passt, sondern :
- Schritt 1 : Anforderung senden
- Schritt 2 : warten bis alle benötigten Zeichen empfangen worden sind
- Schritt 3 : empfangene Daten kontrollieren und dann ggf. auswerten.
-> zurück zu Schritt 1 (oder irgendwann einmal dann "Abbruch des Ganzen"
vor Schritt 1 (beim ersten Mal) könnte noch ein genereller Receive stehen, der einfach nur ausliesst was ggf. schon/noch so im Port drinsteht ohne es zur Auswertung zu bringen ...
Gruß
Larry
Similar threads
