TCP-Verbindung Byteweise parsen

CDeml

Level-1
Beiträge
1
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus,

ich hätte ein kleines Problem an einer nativen TCP-Verbindung.

Folgender Aufbau:
Von einer Vipa 315-NET ist eine TCP-Verbindung zu einem M-Bus Pegelwandler aufgebaut.
Über diesen Pegelwandler wird mit n M-Bus Slaves kommuniziert.
Der Pegelwandler packt dabei lediglich das M-Bus Protokoll aus dem TCP-Frame aus und sendet das blanke M-Bus Telegramm auf dem M-Bus. Antworten von den Slaves werden in entgegengesetzter Richtung umgesetzt.
Bisher habe ich diese Kommunikation an einer kleinen IM 151-8 mit den Siemens TSEND/TRECIEVE-Bausteinen betrieben - ohne Probleme.

Mit den Projekten sind auch die Anforderungen an den Speicher gewachsen.
In Zukunft soll der beschriebene Aufbau an einer Vipa 315-4NE12 betrieben werden.
Mein Problem an der Geschichte ist, dass die Nutzdaten in den Antworten der M-Bus Slaves oft nur aus einem Quitt-Byte bestehen.
Der FC6-Recieve-Baustein liefert aber sein NDR nur wenn der CP-Puffer voll ist. Mit definierten Steuerzeichen und dem FB103 kann ich auch nicht arbeiten, da der Pegelwandler nur das blanke M-Bus Protokoll zurückliefert.

Daher meine Frage:
Hat jemand eine Idee wie komme ich an die Daten im CP rankomme wenn nur ein Byte Nutzdaten darin liegt?

Mir ist keine Funktion bekannt, die meine Anforderungen abdecken würde.


Christian
 
Soweit ich weiß, können nur die neueren PN-CPU von Siemens mit variablen Telegrammlängen arbeiten (0 bei LEN eintragen), die Speed7, kann es definitiv im Moment nicht, ich hab das selbst gerade erlebt, hatte aber zum Glück eine Ende-Kennung zur Verfügung, um festzustellen, wo die neu empfangenen Daten zu Ende sind. Interessanter Weise konnte ich aber dauernd Daten empfangen, die an die SPS gesendet wurden (recv_req auf True) nur NDR kommt erst, wenn der Buffer voll ist, ich hatte einen 100-Byte-Buffer in der SPS (ein DB) angelegt, die Daten trudelten quasi ununterbrochen ein, wenn der Buffer voll ist werden die Daten einfach von vorn an überschrieben. Das Problem ist, zu erkennen, wie viele Daten man denn nun bekam. Das ging bei mit über die Endekennung. In deinem Falle würde ich eine PN-CPU vorn Siemens (315-PN, 317-PN, 319-PN) einsetzen.
 
Zurück
Oben