Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 28 von 28

Thema: Protokoll einfangen

  1. #21
    Registriert seit
    22.11.2007
    Beiträge
    726
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    geht es mit tinyupload.com?

  2. #22
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    10.089
    Danke
    838
    Erhielt 2.971 Danke für 2.395 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. #23
    Erik10 ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    17.03.2016
    Beiträge
    12
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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
    Angehängte Dateien Angehängte Dateien

  4. #24
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    10.089
    Danke
    838
    Erhielt 2.971 Danke für 2.395 Beiträge

    Standard

    Die Ethernet-Schnittstelle ist in dem Dokument zwar nicht beschrieben, die Kommunikation scheint aber so abzulaufen:
    • 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)

    Das Auswerten der Empfangs-Nachricht mit dem Datensatz kann man so machen:
    • 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.


    Zitat Zitat von Erik10 Beitrag anzeigen
    Ich wüsste nicht warum mein Programm die String unkorrekt verarbeitet
    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. #25
    Registriert seit
    22.11.2007
    Beiträge
    726
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    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


    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
    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
    Angehängte Dateien Angehängte Dateien
    Geändert von LowLevelMahn (07.09.2016 um 08:16 Uhr)

  6. #26
    Registriert seit
    22.11.2007
    Beiträge
    726
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    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

  7. #27
    Registriert seit
    22.11.2007
    Beiträge
    726
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    Klappt es jetzt?

    Es ist immer wichtig überhaupt und schnell Feedback zu geben - so funktioniert das Internet-Frage/Antwort-Spiel

  8. #28
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.409
    Danke
    392
    Erhielt 2.342 Danke für 1.949 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. Protokoll
    Von hoT im Forum HMI
    Antworten: 0
    Letzter Beitrag: 23.02.2011, 22:15
  2. Protokoll
    Von rene im Forum HMI
    Antworten: 2
    Letzter Beitrag: 04.07.2007, 11:56
  3. AK- Protokoll
    Von borromeus im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 27.02.2007, 17:30
  4. S7-Protokoll
    Von Zapot im Forum Feldbusse
    Antworten: 8
    Letzter Beitrag: 21.08.2006, 11:17
  5. S7-Protokoll 2
    Von Zapot im Forum Feldbusse
    Antworten: 1
    Letzter Beitrag: 21.08.2006, 09:37

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •