Step 7 Zwei CP 343-1 Lean, eine mit „komischem“ Gehabe

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Heinileini,

TEMP, also Lokalvariablen, sind an dieser Stelle eigentlich genau richtig, da das Sende-Start-Bit und die Ausgaben der Siemens-FCs nur einen Zyklus lang anstehen und abgefragt werden. Das worauf Harald vermutlich hinaus will, ist die Beziehung von CPs mit unterschiedlich alten HW-Ständen, zu CPUs mit eben solchen. Gar nicht dumm, was er da geschrieben hat.

@Harald

Die Firmware ist aktuell.

CP#1: HW = V2.5, FW = V3.1.3, GSD = V3.0
CP#2: HW = V2.0, FW = V3.1.3, GSD = V3.0 (das ist der CP mit dem Empfangsproblem)

Ich hatte heute morgen keine Zeit und fange jetzt mal an, eure Vorschläge abzuarbeiten ... :s12:

Gruß Kai
 
Zuletzt bearbeitet:
CP#1: HW = V2.5, FW = V3.1.3, GSD = V3.0
CP#2: HW = V2.0, FW = V3.1.3, GSD = V3.0 (das ist der CP mit dem Empfangsproblem)
Bist Du sicher mit den HW-Versionen, z.B. "2.5"? Üblicherweise ist die Hardwareversion eine ganze Zahl. Die ist auf der Baugruppe aufgedruckt als "E-Stand:" oder "FS:". Bei "Zielsystem > Baugruppenzustand" heißt die Angabe "Hardware Ausgabestand" und eine Zahl ohne "V", und bei "Spezialdiagnose" wird die Hardwareversion als "HW-Ausgabestand" angezeigt.

PS: Warum führst Du immer wieder die "GSD-Version" an? Die GSD-Datei brauchst Du gar nicht für Deine Verbindung. Wofür brauchst Du die GSD?

Harald
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Sodele ... :)

@Thomas_v2.1

Wenn z.B dein Any-Pointer 10 Bytes groß ist, der Partner aber nur 2 Bytes sendet, dann kommt solange nichts im Programm an bis in Summe 10 Bytes gesendet wurden. Vielleicht ist das dann auch für den Status in der NCM-Diagnose verantwortlich: Der CP puffert die Daten so lange zwischen bis dein Programm die Anzahl an Bytes voll hat und sie dann abholt.

Da ich permanent sende, dürfte es, nach meinem Verständnis, selbst dann nicht mehrere Minuten dauern, bis ein eventuell zu langer Empfangspuffer im CP voll wäre.

Ich würde auch mal den AG_RECV direkt aufrufen um einen Fehler in deiner Umkopiererei auszuschließen.

Ich hatte eben beide (Ursprungs-) Any-Pointer direkt an die Siemens-FCs geschrieben. Dadurch hatte sich nichts geändert.

Dein FB ist so auch nicht Multiinstanzfähig.

Jetzt schon ... :cool:

@Onkel_Dagobert

Haben die CPUs noch weitere Kommunikationen zu bewältigen? Wie sind die Einstellungen "Zyklusbelastung durch Kommunikation" in der HW-Konfig der CPUs? Ich weiß nicht, ob es was bringt, diese Werte mal zu erhöhen.

Den Zykluszeitwert in der HW Konfig kann man doch verändern. 20% (Default-Wert) ist dort jeweils eingestellt.

Sonst gibt es übrigens keine weitere Kommunikation; das ist ja zunächst nur ein Test.

@PN/DP (Harald)

Wie sieht der Aufruf des FB aus, speziell: wie sind die Inputs "Sendefach" und "Empfangsfach" beschaltet? Sind die Aufrufe in beiden CPUs gleich? Werden jeweils gleich viele Bytes gesendet und empfangen?

CALL "Kommunikation" , "Daten Kommunikation" (
Sendefach := "Kommunikation CPU 2".Sendefach,
Laenge_Sendefach := 2,
Empfangsfach := "Kommunikation CPU 2".Empfangsfach);
Reset :=
ERR_CP_343_Datensendung :=
ERR_CP_343_Datenempfang :=

"Kommunikation CPU 2".Sendefach = P#DB101.DBX0.0 Byte 2
"Kommunikation CPU 2".Empfangsfach = P#DB101.DBX2.0 Byte 2

Rufst Du den FB mit einem eigenen IDB auf oder als Multiinstanz?
"LAR1 P##Sendefach" und "LAR1 P##Empfangsfach" liefern bei "multiinstanzfähig"-FB nicht die Adresse im IDB sondern die Adresse in der Instanz. Für indirekte Adressierung in den IDB muß noch der Multiinstanz-Offset aus AR2 addiert werden.

Das war mir schon bekannt, aber soweit war ich noch nicht. Die Funktion sollte ja erst mal „nur“ funktionieren und läuft momentan nur mit einfacher Instanz. Habe es aber trotzdem geändert; danke für den Code!

Der Fehler hat auch gar nichts mit den indirekten Any-Zeigern zu tun, da ich eben auch direkte probiert hatte.

Bei der Auswertung auf Sendefehler oder Empfangsfehler laß mal jeweils das "UN ...Fertigmeldung" weg

Bringt nichts.

Ändert sich was wenn die STRUCTs "Daten_senden" und "Daten_empfangen" nicht in TEMP sondern in STAT liegen?

Nein.

Was ist unterschiedlich bei den CPs? Verschiedene Hardware-Stände? Du könntest die CPUs auf die aktuellen Firmwarestände updaten und/oder den Siemens Support befragen.

Benötige ich für den CP mit der HW V2.0 eventuell ältere Siemens-FCs? Zu den Versionsnummern siehe auch mein Vorpost.

Gruß Kai

Der aktuelle Code (ich hatte auch noch zwei Kleinigkeiten geändert):

FUNCTION_BLOCK "Kommunikation"
TITLE =Kommunikation
// // Dieser Funktionsbaustein steuert die Kommunikation via Ethernet.
AUTHOR : Schulz
FAMILY : FUNKTION
NAME : COM
VERSION : 1.0

VAR_INPUT
Sendefach : ANY ; //Eingang: "Sendefach [ANY-Pointer]"
Laenge_Sendefach : INT ; //Eingang: "Länge Sendefach [n]"
Empfangsfach : ANY ; //Eingang: "Empfangsfach [ANY-Pointer]"
Reset : BOOL ; //Eingang: "Reset (TRUE = ein)"
END_VAR

VAR_IN_OUT
ERR_CP_343_Datensendung : BOOL ; //Ausgang: "Fehler CP 343 Datensendung (TRUE = Fehler)"
ERR_CP_343_Datenempfang : BOOL ; //Ausgang: "Fehler CP 343 Datenempfang (TRUE = Fehler)"
END_VAR

VAR
Flanke_positiv_Reset : BOOL ; //Speicher: "Flanke positiv Reset (TRUE = ein)"
Daten_senden_laeuft : BOOL ; //Speicher: "Daten senden läuft (TRUE = ein)"
Status_Daten_senden : WORD ; //Speicher: "Status Daten senden [n]"
Status_Daten_empfangen : WORD ; //Speicher: "Status Daten empfangen [n]"
END_VAR

VAR_TEMP
Logisch_0 : BOOL ; //Tempspeicher: "Logisch 0 (FALSE)"
Logisch_1 : BOOL ; //Tempspeicher: "Logisch 1 (TRUE)"
Impuls_positiv_Reset : BOOL ; //Tempspeicher: "Impuls positiv Reset (TRUE = ein)"
Inhalt_Adressregister_2 : DWORD ; //Tempspeicher: "Inhalt Adressregister 2 [x.y]"
Zeiger_Sendefach : ANY ; //Tempspeicher: "Zeiger Sendefach [ANY-Pointer]"
Zeiger_Empfangsfach : ANY ; //Tempspeicher: "Zeiger Empfangsfach [ANY-Pointer]"
Daten_senden : STRUCT //Tempspeicher: "Senden"
Start : BOOL ; //Senden: "Start (TRUE = ein)"
Fertigmeldung : BOOL ; //Senden: "Fertigmeldung (TRUE = ein)"
Fehler : BOOL ; //Senden: "Fehler (TRUE = ein)"
Status : WORD ; //Senden: "Status (TRUE = ein)"
END_STRUCT ;
Daten_empfangen : STRUCT //Tempspeicher: "Empfangen"
Fertigmeldung : BOOL ; //Empfangen: "Fertigmeldung (TRUE = ein)"
Fehler : BOOL ; //Empfangen: "Fehler (TRUE = ein)"
Status : WORD ; //Empfangen: "Status [n]"
Laenge : INT ; //Empfangen: "Länge [n]"
END_STRUCT ;
Zwischenspeicher : WORD ; //Tempspeicher: "Zwischenspeicher"
Funktionsstatus : INT ; //Tempspeicher: "Funktionsstatus [n]"
END_VAR

BEGIN

NETWORK
TITLE =Interne Fixmerker initialisieren.
// Fixmerker "Logisch 0" und "Logisch 1" zur internen Verarbeitung.
CLR ;
= #Logisch_0;
SET ;
= #Logisch_1;

NETWORK
TITLE =
TAR2 #Inhalt_Adressregister_2;
L #Inhalt_Adressregister_2;
UD DW#16#FFFFFF;
L P##Sendefach;
+D ;
LAR1 ;
LAR2 P##Zeiger_Sendefach;
L DID [AR1,P#0.0];
T LD [AR2,P#0.0];
L DIW [AR1,P#4.0];
T LW [AR2,P#4.0];
L DID [AR1,P#6.0];
T LD [AR2,P#6.0];
L #Inhalt_Adressregister_2;
UD DW#16#FFFFFF;
L P##Empfangsfach;
+D ;
LAR1 ;
LAR2 P##Zeiger_Empfangsfach;
L DID [AR1,P#0.0];
T LD [AR2,P#0.0];
L DIW [AR1,P#4.0];
T LW [AR2,P#4.0];
L DID [AR1,P#6.0];
T LD [AR2,P#6.0];
LAR2 #Inhalt_Adressregister_2;

NETWORK
TITLE =
U #Reset;
U( ;
U #ERR_CP_343_Datensendung;
O #ERR_CP_343_Datenempfang;
) ;
FP #Flanke_positiv_Reset;
= #Impuls_positiv_Reset;
U #Impuls_positiv_Reset;
R #ERR_CP_343_Datensendung;
R #ERR_CP_343_Datenempfang;
R #Daten_senden_laeuft;
SPBN M040;
L W#16#0;
T #Status_Daten_empfangen;
T #Status_Daten_senden;

NETWORK
TITLE =
M040: U #ERR_CP_343_Datensendung;
O #ERR_CP_343_Datenempfang;
SPBN M050;
L W#16#0;
T #Zwischenspeicher;
CALL "Datenbereich füllen" (
BVAL := #Zwischenspeicher,
RET_VAL := #Funktionsstatus,
BLK := #Zeiger_Empfangsfach);
SPA M120;

NETWORK
TITLE =
M050: UN #Daten_senden_laeuft;
= #Daten_senden.Start;
S #Daten_senden_laeuft;

NETWORK
TITLE =
CALL "TCP-Daten senden" (
ACT := #Daten_senden.Start,
ID := 1,
LADDR := W#16#110,
SEND := #Zeiger_Sendefach,
LEN := #Laenge_Sendefach,
DONE := #Daten_senden.Fertigmeldung,
ERROR := #Daten_senden.Fehler,
STATUS := #Daten_senden.Status);
NETWORK

TITLE =
U #Daten_senden.Fertigmeldung;
U #Daten_senden_laeuft;
R #Daten_senden_laeuft;

NETWORK
TITLE =
UN #Daten_senden.Fertigmeldung;
U #Daten_senden.Fehler;
R #Daten_senden_laeuft;
SPBN M090;
SET ;
S #ERR_CP_343_Datensendung;
L #Daten_senden.Status;
T #Status_Daten_senden;
SPA M120;

NETWORK
TITLE =
M090: CALL "TCP-Daten empfangen" (
ID := 1,
LADDR := W#16#110,
RECV := #Zeiger_Empfangsfach,
NDR := #Daten_empfangen.Fertigmeldung,
ERROR := #Daten_empfangen.Fehler,
STATUS := #Daten_empfangen.Status,
LEN := #Daten_empfangen.Laenge);

NETWORK
TITLE =
UN #Daten_empfangen.Fertigmeldung;
U #Daten_empfangen.Fehler;
SPBN M110;
SET ;
S #ERR_CP_343_Datenempfang;
L #Daten_empfangen.Status;
T #Status_Daten_empfangen;

NETWORK
TITLE =
M110: U #Daten_empfangen.Fertigmeldung;
UN #Daten_empfangen.Fehler;
R #Daten_empfangen.Fertigmeldung;

NETWORK
TITLE =Bausteinende...
// Bausteinende...
M120: U #Logisch_1;
SAVE ;
BEB ;
END_FUNCTION_BLOCK
 
Zuletzt bearbeitet:
CPU 313C-2DP V2.0.10 & CP 343-1 Lean V2.0 & FC5 V4.2 & FC6 V4.7
CPU 314C-2DP V2.6.11 & CP 343-1 Lean V2.5 & FC5 V4.2 & FC6 V4.7
Deine CPU 313C hat nicht die neueste Firmware. Aktuelle Firmwarestände wären:
- 313C-2DP 313-6CE01 : V2.0.12
- 313C-2DP 313-6CF03 : V2.6.11
- 313C-2DP 313-6CG04 : V3.3.12

- 314C-2DP 314-6CG03 : V2.6.11
- 314C-2DP 314-6CH04 : V3.3.12

Die Versionsstände von FC5 und FC6 sind OK.

Harald
 
Ob es eventuell Kompatibilitätsprobleme des CP 343-1 LEAN (343-1CX10) mit den CPUs gibt befrage mal den Siemens Support. Eventuell stellen die das mal nach.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bist Du sicher mit den HW-Versionen, z.B. "2.5"? Üblicherweise ist die Hardwareversion eine ganze Zahl. Die ist auf der Baugruppe aufgedruckt als "E-Stand:" oder "FS:". Bei "Zielsystem > Baugruppenzustand" heißt die Angabe "Hardware Ausgabestand" und eine Zahl ohne "V", und bei "Spezialdiagnose" wird die Hardwareversion als "HW-Ausgabestand" angezeigt.

PS: Warum führst Du immer wieder die "GSD-Version" an? Die GSD-Datei brauchst Du gar nicht für Deine Verbindung. Wofür brauchst Du die GSD?

Harald

Ouups, sorry!

HW-Version 3 und HW-Version 6 ist richtig.

Die GSD-Datei brauche ich, um die Hardware zusammenzubauen ... :?

Möglicherweise heißen die Dinger auch anders, aber wie auch immer: Es gibt im HW-Katalog verschiedene CP 343-1 Lean-Baugruppen.

Gruß Kai
 
GSD-Dateien braucht man für Profibus-Slaves und Profinet-Devices.
Damit eine Baugruppe im Hardware-Katalog unter "SIMATIC 300" erscheint braucht man HSP (Hardware Support Package) falls die Baugruppe in der Step7-Version nicht schon integriert ist.
Welche Step7-Version hast Du? Unter welchem Windows läuft Dein Step7?

Du könntest die CP mal testweise bei beiden Stationen in HW Konfig als 343-1CX10 V2.2 projektieren.

Harald
 
GSD-Dateien braucht man für Profibus-Slaves und Profinet-Devices.
Damit eine Baugruppe im Hardware-Katalog unter "SIMATIC 300" erscheint braucht man HSP (Hardware Support Package) falls die Baugruppe in der Step7-Version nicht schon integriert ist.
Welche Step7-Version hast Du? Unter welchem Windows läuft Dein Step7?

Du könntest die CP mal testweise bei beiden Stationen in HW Konfig als 343-1CX10 V2.2 projektieren.

Harald

Ich hatte die zuvor schon als V2.2 bzw. V2.0 projektiert, bevor ich das FW-Update eingespielt hatte. Ich nutze STEP 7 Professional 5.6 auf Windows 7 Professional.

Neue Erkenntnis:

Ich habe die Baugruppen gerade nochmal untereinander getauscht und diverse andere Patchkabel ausprobiert. Dabei hat sich gezeigt, dass der Fehler bei Weitem nicht so trivial ist, wie ich dachte. Es ist nicht unbedingt der ältere CP der muckt, sondern mal der eine; mal der andere. Ich glaube die Reihenfolge, in der ich die Fehler quittiere bestimmt, welcher CP zuerst anfängt zu senden. Dann baut sich das Fehlerbild langsam auf. Anfangs ist die Verzögerung beider Empfangspartner noch ziemlich kurz; danach wird die Wartezeit auf einer der beiden Seiten immer länger, wobei sie auf der anderen Seite irgendwann nicht mehr wahrzunehmen ist.

Ich vermute, dass das „Dauerfeuer“ beim Senden, im Zusammenspiel mit verschiedenen Zykluszeiten der CPUs (7 ms und 9 ms), das eigentliche Problem sein könnte. Die Daten müssen ja zeitnah „abgeholt“ werden und so könnte sich ein „Datenstau“ bilden; oder? Ich teste und berichte!

Gruß Kai
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Einfach in Dauerfeuer zu senden ohne auf irgendentwas zu warten ist bestimmt keine gute Idee.
Entweder so langsam senden, dass du weitestgehend sicher sein kannst, dass deine gesendeten Daten immer verarbeitet werden können (z.B. alle 5 Sekunden), oder du musst dir ein Handshake programmieren, oder ein Protokoll auswählen wo alles schon fertig ist, wie S7-Kommunikation oder Iso-On-TCP.

Ich würde ja auch zur Fehleranalyse die Siemens Bausteine direkt aufrufen, aber das habe ich schon einmal geschrieben.
 
Es funktioniert!

Ich muss entweder auswerten, ob sich im Datenfach etwas geändert hat und nur bei Bedarf senden oder die ganze Chose in einem festen Zeittakt ablaufen lassen.

Gruß Kai
 
Zurück
Oben