CP342-5 DP_SEND DP_RECV Fehler Datenlänge

S

Steve38

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

ich habe ein Ähnliches Problem.
Meine ETs (in Teilen) kann ich einlesen, meine FUs leider nicht mehr.

Bei der ET mit der DP12, kann ich allerdings auch meine AIs nicht einlesen.

Die Fehlermeldung lautet:
Das die Eingangsdatenlänge mit 300Bytes kleiner ist als die im DP-Master erwartete.

Siehe hierzu die Screenshots im Anhang.
 
Zuletzt bearbeitet:
Wie groß ist denn der Sende- bzw. Empfangsdatenbereich, den du jeweils am FC angetragen hast.
Sieht so aus, als ob du da genau 300 Byte bereitstellst. Ändere mal die Größe, wie angegeben auf 352.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ralle schrieb:
Wie groß ist denn der Sende- bzw. Empfangsdatenbereich, den du jeweils am FC angetragen hast.
Sieht so aus, als ob du da genau 300 Byte bereitstellst. Ändere mal die Größe, wie angegeben auf 352.
Zum Vergrößern anklicken....

Denke der liegt bei 300, siehe Netzwerk

NW1:
CALL FB 7 , DB110
EN_R :=TRUE
R :=FALSE
LADDR :=316
DB_NO :=
DBB_NO :=
L_TYP :=
L_NO :=
L_OFFSET:=
L_CF_BYT:=
L_CF_BIT:=
NDR :=
ERROR :=
LEN :=
STATUS :=





NW2:
CALL FC 600
CPLADDR:=W#16#12C
SEND :=P#DB2.DBX0.0 BYTE 300
DONE :=#DP_Send_Done
ERROR :=#DP_Send_Error
STATUS :=#DP_Send_Status

CALL FC 602
CPLADDR :=W#16#12C
RECV :=P#DB1.DBX0.0 BYTE 300
NDR :=#DP_Recv_NDR
ERROR :=#DP_Recv_Error
STATUS :=#DP_Recv_Status
DPSTATUS:=#DP_Recv_DP_Status
 

Anhänge

  • Fehler_CP_große.JPG
    Fehler_CP_große.JPG
    61,6 KB · Aufrufe: 24
Code:
Ob dein Problem mit den ursprünglichen Thema zu tun hat ist nicht sicher. Ist dafür besser ein neuen Thema zu starten als ein alten zu wiederbeleben.

Aber zu dein Problem.
Es steht in Diagnosepuffer das die Länge von Empfangsdaten (352 Bytes) nicht mit den Datenlänge passt was eingestellt bei DP_RECV ist (300 Bytes).

Ein Tip:
Der CP342-5 hat ein eingenständiges Prozessabbild der nichts mit den Prozessabbild von der S7 CPU zu tun hat.
Es bedeutet das du für die Slaves die auf den CP342-5 hängen die E/A Addressen nicht nach die Addressen einstellen muss von die E/A die direkt an den S7 CPU angeschlossen sind.
Also, du kannst für die Slaves die auf den CP342-5 hängen ab byte 0 starten.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Konstellation:
CP342-5 -> IM153 -> CP340 wird auch nicht funktionieren können.

Zitat von:
https://support.industry.siemens.com/cs/ww/de/view/24708615

In einem SIMATIC S7-300 System können Sie die PtP-CPs CP340 und CP341, sowie das ET 200S 1SI Modul, nur an das unterlagerte DP-Mastersystem der integrierte DP-Schnittstelle einer S7-300 CPU anbinden.
Der Betrieb der PtP-CPs am DP-Mastersystem eines CP342-5 ist nicht möglich. Der Betrieb des ET 200S SI Moduls am DP-Mastersystem eines CP342-5 ist eingeschränkt möglich, d.h. es ist kein Firmware-Update und keine Nutzung der I&M-Funktionalität möglich, da hierfür DPV1 Support benötigt wird. Der CP342-5 unterstützt kein DPV1.
Zum Vergrößern anklicken....

.... EDIT .... Vergiss es, da bin ich wohl mit den Bildchen am Handyfon ein wenig durcheinander gekommen ...

Mfg
Manuel
 
Zuletzt bearbeitet:
CPLADDR:=W#16#12C _ ist in dez. auch 300 _ nicht unmöglich ,aber das beide gleich sind ist doch selten.
SEND :=P#DB2.DBX0.0 BYTE 300


Mach mal ein Foto von HWkonfig/eigenschaften/cp342-5/ Tab Adressen


MfG
 
Zuletzt bearbeitet:
Hallo,

ich habe den Wert al geändert, sieht nun anders aus mein Fehler. ;-)

Fehler.JPG

Unbenannt.JPG



Hab auch noch das Problem, dass ich meine EW um den Breich 200 nicht einlesen kann und ich eine entsprechende Störung in der CPU angezeigt bekommen.


Unbenannt4.JPG
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Die E/A-Adressen der DP-Slaves belegen keine E/A-Adressen in der CPU sondern nur im CP 342-5.
siehe in HW Konfig: Ansicht > Adressübersicht Ctrl+U > Adressen von: CP 342-5
Die FC DP_SEND und DP_RECV kopieren die Daten zwischen den E/A-Adressen im CP und Deinem DB1 und DB2. Um auf die Daten der DP-Slaves zuzugreifen mußt Du die Daten in den DB ansprechen, und nicht PEW... im Adressraum der CPU.

Siehe mal zu, daß Du die E/A-Adressen der DP-Slaves im CP342-5 möglichst lückenlos von 0 an anordnest --> desto weniger unnütze Bytes müssen jeden Zyklus sinnloserweise zwischen der CPU und dem CP hin- und hergeschaufelt werden, weil das kopieren mit DP_SEND/DP_RECV immer von 0 bis zur jeweils höchsten belegten Adresse stattfindet.

Komisch daß Dein Diagnosepuffer für den Eintrag "Ereignis-ID: 16# F9C1:2776" keinen Klartext anzeigt, das sollte kein Fehler sein, sondern müßte die normale Statusmeldung sein, daß der CP nun den zyklischen Datenverkehr mit den DP-Slaves aufgenommen hat. ("The DP master is switching to Run/Operate (polling of the DP slave with user data).")
Hast Du Dir schon mal die CP-Spezialdiagnose angeschaut?

Welchen Status liefern denn DP_SEND und DP_RECV?
Sind Deine DB1 und DB2 groß genug in der CPU?

Harald
 
PN/DP schrieb:
Die E/A-Adressen der DP-Slaves belegen keine E/A-Adressen in der CPU sondern nur im CP 342-5.
siehe in HW Konfig: Ansicht > Adressübersicht Ctrl+U > Adressen von: CP 342-5
Die FC DP_SEND und DP_RECV kopieren die Daten zwischen den E/A-Adressen im CP und Deinem DB1 und DB2. Um auf die Daten der DP-Slaves zuzugreifen mußt Du die Daten in den DB ansprechen, und nicht PEW... im Adressraum der CPU.
Zum Vergrößern anklicken....

Soll bedeutet das ich mir die Daten einmal über den CP einlesen muss und im DB zwischenspeichern?!


PN/DP schrieb:
Siehe mal zu, daß Du die E/A-Adressen der DP-Slaves im CP342-5 möglichst lückenlos von 0 an anordnest --> desto weniger unnütze Bytes müssen jeden Zyklus sinnloserweise zwischen der CPU und dem CP hin- und hergeschaufelt werden, weil das kopieren mit DP_SEND/DP_RECV immer von 0 bis zur jeweils höchsten belegten Adresse stattfindet.
Zum Vergrößern anklicken....

Zeit ist hier ein Problem, würde die Struktur gerne so bebehalten.
Hinter der SPS steht noch eine Leitwarte, die dierekt auf die DBs zugrift.


PN/DP schrieb:
Komisch daß Dein Diagnosepuffer für den Eintrag "Ereignis-ID: 16# F9C1:2776" keinen Klartext anzeigt, das sollte kein Fehler sein, sondern müßte die normale Statusmeldung sein, daß der CP nun den zyklischen Datenverkehr mit den DP-Slaves aufgenommen hat. ("The DP master is switching to Run/Operate (polling of the DP slave with user data).")
Hast Du Dir schon mal die CP-Spezialdiagnose angeschaut?
Zum Vergrößern anklicken....

Nein, habe ich noch nicht gemacht, mangels wissen.




PN/DP schrieb:
Welchen Status liefern denn DP_SEND und DP_RECV?
Sind Deine DB1 und DB2 groß genug in der CPU?
Zum Vergrößern anklicken....


Sind beide 352Byte groß.
 
Nächstes Problem ist, was ich jetzt schon sehe ist das einlesen der FUs.
Die CPU sagt mir, wenn ich den FB Aufrufe "FU Ein/Auslesen", das meine SFCs nicht vorhanden sind. (SFC14/15) geht das mit der CPU bzw. dem CP gar nicht?!

Unbenannt5.JPG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da die CPU keine PN oder DP Schnittstelle hat, gibts auch diese SFCs nicht, hätten sowieso keinen Sinn.

Auch hier musst du deinen DB1/DB2 verwenden.

Mfg
Manuel

Gesendet von Mobilgerät
 
Das sagt die Diagnose

Unbenannt6.JPG
Unbenannt7.JPG
Unbenannt8.JPG

Den FB zur Kommuniktion habe ich auch einmal geändert:

Netzwerk 1:
CALL FB 7 , DB110
EN_R :=TRUE
R :=FALSE
LADDR :=352
DB_NO :=
DBB_NO :=
L_TYP :=
L_NO :=
L_OFFSET:=
L_CF_BYT:=
L_CF_BIT:=
NDR :=
ERROR :=
LEN :=
STATUS :=





Netzwerk 2:

CALL FC 600
CPLADDR:=W#16#160
SEND :=P#DB2.DBX0.0 BYTE 352
DONE :=#DP_Send_Done
ERROR :=#DP_Send_Error
STATUS :=#DP_Send_Status

CALL FC 602
CPLADDR :=W#16#160
RECV :=P#DB1.DBX0.0 BYTE 352
NDR :=#DP_Recv_NDR
ERROR :=#DP_Recv_Error
STATUS :=#DP_Recv_Status
DPSTATUS:=#DP_Recv_DP_Status
 
Zuletzt bearbeitet:
Wie kommst du jetzt auf CPLaddr 16#160 = 352?
Laut deinen Bildern war 16#12C doch richtig.

Desweiteren hast du laut deinen letzten Bild offensichtlich nur ein Problem mit Slave 12.

Mfg
Manuel

Gesendet von Mobilgerät
 
Bist Du schon mal auf die Idee gekommen, in der Spezialdiagnose die Zeile "DP Slave Adr. 12" (und die darunterliegenden Zeilen) zu markieren?
Dann werden Dir ziemlich sicher rechts Detailinformationen angezeigt, was das Problem mit dem Slave 12 ist.
Da ein Teilnehmer 12 im Profibus vorhanden ist, wird das vermutlich sein:
- der Teilnehmer 12 ist keine IM153-1
- oder an der IM153-1 sind keine oder andere Baugruppen gesteckt als projektiert (Rückwandbusverbinder OK?)
- oder die IM153-1 ist defekt
- oder ?

Harald
 
Wegen den komischen/unbekannten Diagnosepuffereinträgen ohne Erläuterungstext:
Könntest Du uns mal aufklären, welche Step7-Version Du verwendest und welchen CP342-5 (Bestellnummer + Firmwareversion) (und welche CPU 314)?

Harald
 
Warum hast Du jetzt die Bilder aus Deinem Eröffnungspost gelöscht? Besonders das Bild von der HW Konfig? Das ist kontraproduktiv...

Dein Bild im Beitrag #18 deute ich so, daß da ein Profibusteilnehmer mit der Profibus-Adresse 12 mit der Profibus Ident Nummer 801D (eine ET200M IM153-1) gefunden wurde, in HW Konfig aber ein anderer Teilnehmer oder ein IM153-1 mit anderem Modulaufbau projektiert wurde und deshalb der CP342-5 den zyklischen Betrieb mit dem Slave nicht aufnimmt. Gehe also hin zu dem Teilnehmer und vergleiche genau die Baugruppen und Bestellnummern zwischen HW Konfig und real vorhanden. Checke auch mal die Rückwandbusverbinder zwischen den Baugruppen.

Harald
 

Similar threads

M
TIA IEC 60870-5, redundante Verbindung zu je zwei Master, CP 1542SP-1 IRC
Antworten
12
Aufrufe
2K
MaxW
M
A
Step 7 dp_send und CP342-5 PLCSIM
Antworten
8
Aufrufe
3K
Abdabd789
A
D
TIA CP342-5 mit ET200SP
Antworten
6
Aufrufe
3K
darkdonald
D
J
Step 7 CP342-5 an VIPA313SC
Antworten
14
Aufrufe
3K
Jacke
J
B
TIA TIA CM 1242-5 Profibus Slave
Antworten
4
Aufrufe
3K
baciarka_hej
B
Zurück
Oben