Step 7 AG_RECV (FC6) für Modbus TCP Verbindung

D

DerMatze

Level-1
Beiträge
525
Reaktionspunkte
21
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

ich komme beim Datenempfangen einfach nicht mehr weiter.

Eine 315-2DP mit CP343-1 (V3.0) soll via TCP Verbindung Daten aus einem Sentron PAC3200 (7KM2112-0BA00-3AA0) empfangen.
Die Verbindung ist konfiguriert und ist aufgebaut.

CP_Status.JPG

Programm ist anhand des Beispiels (Beitrag: 19033929) aufgebaut, jedoch nur der Empfangsteil, da ich zum Sentron nichts senden möchte.

Wie muss der FC6 beschaltet werden damit die Daten korrekt in den entsprechenden DB abgelegt werden?
Die Messwerte sollen als Float (REAL) im PAC zur Verfügung stehen, aber der FC6 kann ja nur Byteweise empfangen?
Im Anhang das S7 Projekt.

Ich hoffe hier Tipps/Hilfe/Lösungen zu bekommen.

Gruß
Matze
 

Anhänge

  • 315_2dp.zip
    989,6 KB · Aufrufe: 37
Zuletzt bearbeitet:
DerMatze schrieb:
Programm ist anhand des Beispiels (Beitrag: 19033929) aufgebaut, jedoch nur der Empfangsteil, da ich zum Sentron nichts senden möchte.
Zum Vergrößern anklicken....
Kann es sein, daß der Sentron gar nicht von alleine sendet sondern zum senden erst aufgefordert werden muß?


DerMatze schrieb:
Wie muss der FC6 beschaltet werden damit die Daten korrekt in den entsprechenden DB abgelegt werden?
Die Messwerte sollen als Float (REAL) im PAC zur Verfügung stehen, aber der FC6 kann ja nur Byteweise empfangen?
Zum Vergrößern anklicken....
Der FC6 interpretiert die Bytes nicht. Der Datentyp ist belanglos. Der ANY am Input RECV gibt an, wieviele Bytes und wo die vom CP empfangenen Bytes abgelegt werden sollen. Angenommen ein Datentelegramm vom Sentron enthält 25 REALs dann erstelle in einem DB eine Struktur mit 25 REALs und lege diese Struktur an RECV von AG_RECV: "P#DB82.DBX0.0 BYTE 100"
Die ANY-Zugriffsbreite "BYTE 100" sollte der Länge des Datentelegramms vom Sentron entsprechen. Wenn das nicht der Fall ist, dann "wandert" oder "springt" die Lage der Telegrammteilstücke im Empfangsbereich.

Genaugenommen mußt Du aus Konsistenzgründen die Empfangsbytes vom AG_RECV zunächst in einen Empfangspuffer schreiben lassen und bei NDR=1 in Deinen eigentlichen Datenbereich umkopieren, ich kann mich aber nicht an Probleme erinnern, wenn man direkt den endgültigen Datenbereich angibt.

Ansonsten sehen Deine Bilder erstmal nicht schlecht aus. Das Step7-Projekt habe ich mir allerdings nicht angesehen.


PS: von den 4 Anhängen in #2 läßt sich nur der Erste ansehen.

Harald
 
PN/DP schrieb:
Kann es sein, daß der Sentron gar nicht von alleine sendet sondern zum senden erst aufgefordert werden muß?
Zum Vergrößern anklicken....

OK, das habe ich noch gar nicht in Betracht gezogen. Werde mal nachsehen ob die Unterlagen des Sentron dazu etwas hergeben:confused:
Am FC6 ist der Status 8180(hex), das spricht lt. der Hilfe auch dafür...
FC6_online.JPG

PN/DP schrieb:
Der FC6 interpretiert die Bytes nicht. Der Datentyp ist belanglos. Der ANY am Input RECV gibt an, wieviele Bytes und wo die vom CP empfangenen Bytes abgelegt werden sollen. Angenommen ein Datentelegramm vom Sentron enthält 25 REALs dann erstelle in einem DB eine Struktur mit 25 REALs und lege diese Struktur an RECV von AG_RECV: "P#DB82.DBX0.0 BYTE 100"
Die ANY-Zugriffsbreite "BYTE 100" sollte der Länge des Datentelegramms vom Sentron entsprechen. Wenn das nicht der Fall ist, dann "wandert" oder "springt" die Lage der Telegrammteilstücke im Empfangsbereich.
Zum Vergrößern anklicken....
Danke für die ausführliche Erklärung, somit kann ich schonmal den Aufbau der Datenablage als Fehlermöglichkeit ausschließen.

PN/DP schrieb:
Das Step7-Projekt habe ich mir allerdings nicht angesehen.
Zum Vergrößern anklicken....
Das dachte ich mir im nachhionein dann auch "Warum soll ich mir ein Projekt runterladen was sowieso nicht funktioniert" :ROFLMAO:
Deswegen habe ich dann die Screenshots gemacht.

#2 ist nun eh nicht mehr der "aktuelle Bearbeitungsstand"

Kann ich, ausser im CP (Weboberfläche), sehen ob die Verbindung tatsächlich aufgebaut wurde?
CP_online.JPG

Gruß
Matze
 
Hallo Lars,
danke für den Tipp.
Anhand dieses Beitrages hatte ich es inzwischen versucht. Da geht meine CPU in stopp, da der SFC133 & SFC134 nicht vorhanden ist.

Kannst du mir noch den Hinweis geben was genau in dem Projekt das 'Komandotelegramm' ist?
Danke schonmal.

Gruß
Matze
 
Zuletzt bearbeitet:
Lars Weiß schrieb:
Hier findest du was für CPU´s mit PN-Schnittstelle, das brauchst du nur adaptieren:

http://www.sps-forum.de/simatic/401...on-sentron-pac3200-post291106.html#post291106
Zum Vergrößern anklicken....

Hallo Lars,

in dem Beispiel von dir habe ich im FB100 alles gefunden was ich benötige - sofern mich meine wenigen SCL Kenntnisse nicht täuschen.
Einige Fragen habe ich aber noch dazu:
1. Ist es richtig, dass via TCON / TDISCON die Verbindungen auf bzw. abgebaut werden? Kann ich diese Bausteine auch für einen CP 343-1 verwenden?
2. die Bausteine TSEND / TRECV funktionieren ja leider nur bei einer CPU mit integrierter PN Schnittstelle. KAnn ich im FB100 den AG_SEND / AG_RECV vom CP eintragen?
Das müssten aus momentaner Sicht die Änderungen sein, um mit einem CP343-1 das PAC anzusprechen bzw. die Messwerte einzulesen, oder wie siehst du das?

Nachtrag:
leider klappt das nicht so einfach :-(
SCL_FB80_origin._FB100.JPG


Gruß
Matze
 
Zuletzt bearbeitet:
TCON kann man nicht mit CP343-1 verwenden. Dessen Funktion wird bereits durch die Projektierung in NetPro erfüllt.

TSEND/TRCV kann man nicht mit CP343-1 verwenden. Diese Bausteine mußt Du durch AG_SEND/AG_RECV ersetzen. Das geht nicht so einfach indem man die TSEND/TRCV-Instanzen als AG_SEND/AG_RECV deklariert, weil AG_SEND/AG_RECV sind FC, die können gar nicht instanziert werden. Außerdem ist die Bausteinschnittstelle anders als bei TSEND/TRCV. Du mußt die TSEND/TRCV-Aufrufe komplett durch neu geschriebene AG_SEND/AG_RECV-Aufrufe ersetzen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und noch eins musst du tun: Im Header steht im letzten Byte die Anzahl noch Bytes die noch folgen. Den Wert musst du am 2ten Aufruf von AG_RECV als Länge angeben. Der AG_RECV unterstützt keine variable Telegrammlänge.
 
PN/DP schrieb:
TCON kann man nicht mit CP343-1 verwenden. Dessen Funktion wird bereits durch die Projektierung in NetPro erfüllt.

TSEND/TRCV kann man nicht mit CP343-1 verwenden. Diese Bausteine mußt Du durch AG_SEND/AG_RECV ersetzen. Das geht nicht so einfach indem man die TSEND/TRCV-Instanzen als AG_SEND/AG_RECV deklariert, weil AG_SEND/AG_RECV sind FC, die können gar nicht instanziert werden. Außerdem ist die Bausteinschnittstelle anders als bei TSEND/TRCV. Du mußt die TSEND/TRCV-Aufrufe komplett durch neu geschriebene AG_SEND/AG_RECV-Aufrufe ersetzen.

Harald
Zum Vergrößern anklicken....

Danke für die ausführliche Erklärung!
 
Lars Weiß schrieb:
Und noch eins musst du tun: Im Header steht im letzten Byte die Anzahl noch Bytes die noch folgen. Den Wert musst du am 2ten Aufruf von AG_RECV als Länge angeben. Der AG_RECV unterstützt keine variable Telegrammlänge.
Zum Vergrößern anklicken....


Mein Ansatz ist nun folgender:

Grundlage Beispiel aus #1 da hier schon ein AG_SEND / AG_RECV mittels zwei 315er mit CP realisiert wurde.
1. ertselle mir einen DB der den Header gem. Struktur aus deinem FB100 enthält
2. Komandotelegramm via AG_SEND an das PAC schicken
3. erster AG_RECV Aufruf erwartet die Antwort vom PAC
4. zweiter AG_RECV Auftruf erst wenn Antwort vom PAC "komplett" dann die Messwerte empfangen

Den Verbindungsauf- bzw. abbau berücksichtige ersteinmal nicht, sobald die CPU einen Neustart macht wird die Verbindung aufgebaut (OB100). Ich müsste mir nur etwas überlegen wenn die Verbindung doch mal getrennt werden sollte...

Das wäre jetzt mein Ansatz den ich realisieren würde, wenn ich es richtig verstanden habe.
Danke für alle Tipps und Hinweise!

Gruß
Matze
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Update:

1. Realisierungsansatz nach Beitrag ID 17853532 (Beispiel zu AG_SEND / AG_RECV)
2. Header DB gebaut
DB Header.JPG
3. via AG_SEND den Header zum PAC senden
FB80_FC5.JPG

4. PAC Antwort - nicht umgesetzt

5. via AG_RECV die Messwerte empfangen
FB80_FC6.JPG

--> Es kommen Werte, allerdings irgendwie versetzt, zumindest kann ich damit nix anfangen...
Was habe ich falsch gemacht.
DB81 Messwerte.JPG
 
Zuletzt bearbeitet:
DerMatze schrieb:
--> Es kommen Werte, allerdings irgendwie versetzt, zumindest kann ich damit nix anfangen...
Was habe ich falsch gemacht.
Zum Vergrößern anklicken....
"Irgendwie versetzt" ist schon richtig.

Du bekommst im Antwort-Telegramm auch einen ModBus-Header zurückgeschickt.
Dieser belegt Byte 0-8 und sieht folgendermaßen aus:
ModBusTCP_RxHead.jpg

Ab Byte 9 beginnen dann deine Nutzdaten.

EDIT: Sehe grade dass du den empfangenen Header über ein vorausgegangenes AG_RECV behandelst....
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Kenne den PAC selber nicht wirklich aber für ein UMG96 hab ich das mit den AG_RECV schon mal gemacht. Allerdings ohne variable Telegrammlängen.

Ich hab damals einfach den Header samt Payload (122 Register) mit einem AG_RECV entgegen genommen und mit einem 11Byte Offset in den DB geschrieben damit
der Header auf Byte 11-19 und die Nutzdaten ab Byte 20 zum liegen kamen.

Hat eigentlich problemlos funktioniert. Den Header vorher getrennt auszuwerten ist aber wahrscheinlich eleganter.
 
PN/DP schrieb:
Kann es sein, daß der PAC LREAL (64 Bit) liefert?

Und Lars schrieb was von variabler Telegrammlänge bei der Antwort. Falls das von Belang ist dann schau mal dieses Beispiel:
Übertragung von Daten (mit FC5 "AG_SEND" und FC6 "AG_RECV") mit variabler Telegrammlänge über das TCP Protokoll

Harald
Zum Vergrößern anklicken....

Den Tipp verfolge ich wenn das mit dem Header Empfangen nicht zum Erfolg führte. Der Beitrag liest sich aber vielversprechend :D
In dem Beispiel von Lars ist der DB für die Messwerte (fast)komplett mit REAL projektiert, lediglich ein Paar 64Bit sind enthalten
DB101.JPG
Seine CPU kommuniziert ja auch mit einem PAC3200.
 
Zuletzt bearbeitet:

Similar threads

T
Step 7 Mit CP343-1 lean eine TCP-Verbindung zu einem PC/Server aufbauen
Antworten
9
Aufrufe
8K
trabajador73
T
M
Sonstiges PAC 3200 über Modubus mit WinCC verbinden
Antworten
2
Aufrufe
3K
MatzePe
M
S
Step 7 S7-300 : TCP-Verbindung zu Handscanner
Antworten
11
Aufrufe
5K
Ingmar64
I
N
TCP-Verbindung SPS <-> Leitrechner mit TIA; Problem mit AG_RECV
Antworten
11
Aufrufe
4K
Nibble
N
D
FC6 AG_RECV Probleme beim Datenempfang
Antworten
11
Aufrufe
4K
danielplp
D
Zurück
Oben