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

K

Kai Schulz

Level-2
Beiträge
139
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
GELÖST: Zwei CP 343-1 Lean, eine mit „komischem“ Gehabe

Hallo Zusammen,

ich habe zwei CPUs via CP 343-1 Lean und TCP-Verbindung gekoppelt. Sende ich von CPU 1 zu CPU 2 ist alles fein. Umgekehrt dauert es mehrere Minuten, bis die Bits ankommen. Sehr merkwürdig!

Hier ist der Code:

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]"
Empfangsfach : ANY ; //Eingang: "Empfangsfach [ANY-Pointer]"
Reset : BOOL ; //Eingang: "Reset (TRUE = ein)"
END_VAR

VAR_OUTPUT
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;
LAR1 P##Sendefach;
LAR2 P##Zeiger_Sendefach;
L D [AR1,P#0.0];
T D [AR2,P#0.0];
L W [AR1,P#4.0];
T W [AR2,P#4.0];
L D [AR1,P#6.0];
T D [AR2,P#6.0];
LAR1 P##Empfangsfach;
LAR2 P##Zeiger_Empfangsfach;
L D [AR1,P#0.0];
T D [AR2,P#0.0];
L W [AR1,P#4.0];
T W [AR2,P#4.0];
L D [AR1,P#6.0];
T D [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 := 2,
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;

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
Zum Vergrößern anklicken....

Gruß Kai
 
Zuletzt bearbeitet:
Ich habe mir dein Programm jetzt nicht durchgelesen, welchen FW-Stand haben denn die CP´s und die CPU´s.
Evtl. würde ein FW-Update schon mal weiter helfen.

Lief das ganze denn schon einmal vernünftig? Was für CPU´s sind verbaut?
 
Es sind beides 1CX10. Das komische ist, dass beide Baugruppen laut FB-Status durchgehend und schnell arbeiten (Senden und Empfangen). Irgendwo werden die Daten von CPU 2 zwischengespeichert und verzögert an CPU 1 weitergegeben. Ich tausche beide CPs mal und gucke ob der Fehler „mitwandert“.

Gruß Kai
 
Ja, der Fehler „wandert“ mit. Nun kommen die Signale von CPU 1 verzögert an CPU 2 an.

Ich schau Montag mal, ob ich noch irgendwo einen dritten, neueren CP finde und tausche den älteren (V2.0) dann testweise aus. Oder ich mache direkt ein Firmware-Update; mal schauen.

Dankeschön, Gruß Kai
 
Hallo Mike,

habe beide CPs erfolgreich auf den neusten Stand gebracht, was aber leider in Bezug auf mein Problem gar nichts geholfen hat.

Mir ist aber gerade aufgefallen, dass in der NCM-Diagnose des „verspäteten“ CPs, die ganze Zeit folgendes bei „Empfangszustand“ geschrieben steht: „Datenübergabe an Anwenderprogramm“

Das passt frappieren gut zu meinem Problem!

Gruß Kai
 
Kai Schulz schrieb:
Mir ist aber gerade aufgefallen, dass in der NCM-Diagnose des „verspäteten“ CPs, die ganze Zeit folgendes bei „Empfangszustand“ geschrieben steht: „Datenübergabe an Anwenderprogramm“

Das passt frappierend gut zu meinem Problem!
Zum Vergrößern anklicken....
Da verstehe ich nicht - die AnwenderProgramme (und ggfs die System-SW) hast Du doch nicht getauscht, sondern nur die CP-Baugruppen!?

Müssen denn die CP's noch vom "Anwender" konfiguriert werden und sind unterschiedlich konfiguriert und sind EmpfangsRichtung und SendeRichtung unterschiedlich konfigurierbar?

PS:
Es gab mal Empfänger, die sich automatisch auf das Gesendete (z.B. BaudRate) einstellen.
Kann das Problem darin liegen, das einer der Empfänger Mühe hat, in dem Empfangenen etwas sinnvolles zu erkennen?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Heinileini,

ich habe heute in beide CPs die aktuellste Firmware (>> 3.1.3) eingespielt sowie die GSD-Dateien ausgetauscht (>> V3.0). Das Problem ist, so glaube ich, dass die empfangenen Daten im zweiten CP „hängenbleiben“ und erst verspätet (nach mehreren Minuten; kein Scherz!) in die zweite CPU „geschoben“ werden. Das dachte ich mir zwar vorher schon, aber seit eben weiß ich, dass es die NCM-Diagnose wohl genauso sieht.

Das Anwenderprogramm (Code auf Seite 1) ist gleich geblieben. Wenn ich die CPs untereinander tausche, wandert der Fehler mit. Die S7-Programme sind beide gleich.

Gruß Kai
 
Wie groß ist bei dir denn der Any-Pointer der letztenendes auf dem AG_RECV landet? Das lässt sich aus deinem gezeigten Programm nämlich nicht entnehmen.

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.
 
Hallo Thomas,

die beiden gegenseitigen Any-Pointer sind gleich groß eingetragen (das wird auch später so sein), in diesem Fall zwei Byte. Der Ansatz ist aber ganz gut. Ich kann ja morgen mal simulieren, ob die Folgen zu so einer Ursache passen. Die indirekten Any-Pointer will ich als Fehlerquelle nicht ausschließen. Blöderweise habe ich gerade keine dritte Baugruppe da, um einen HW-Defekt auszuschließen.

Gruß Kai
 
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.
 
Thomas, das werde ich morgen auch tun.

Onkel Dagobert, ich glaube, das kann man nicht einstellen, da es via HW-Projektierung vorgegeben ist.

Gruß Kai
 
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?

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. Versuche mal so:
Code: 
TAR2 #Inhalt_Adressregister_2; [COLOR="#008000"]//AR2 sichern[/COLOR]

L    #Inhalt_Adressregister_2; [COLOR="#008000"]//Multiinstanzoffset aus AR2[/COLOR]
UD    DW#16#FFFFFF;            [COLOR="#008000"]//Bereichskennung (DB) entfernen[/COLOR]
L     P##Sendefach;            [COLOR="#008000"]//Adresse/Offset #Sendefach in dieser Instanz mit Bereichskennung (DI)[/COLOR]
+D;                            [COLOR="#008000"]//dazu addieren --> Adresse #Sendefach im IDB mit Bereichskennung (DI)[/COLOR]
LAR1;                          [COLOR="#008000"]//AR1 zeigt in IDB[/COLOR]

LAR2  P##Zeiger_Sendefach;     [COLOR="#008000"]//AR2 zeigt in TEMP[/COLOR]

L DID [AR1,P#0.0];             [COLOR="#008000"]//es gab CPU/Firmwarestände mit Problemen bei bereichsüberschreitender[/COLOR]
T LD  [AR2,P#0.0];             [COLOR="#008000"]//indirekter Adressierung, deshalb testweise bereichsinterne indirekte[/COLOR]
L DIW [AR1,P#4.0];             [COLOR="#008000"]//Adressierung mit Bereichskennung in der Anweisung probieren (DID, LD)[/COLOR]
T LW  [AR2,P#4.0];
L DID [AR1,P#6.0];
T LD  [AR2,P#6.0];
Bei der Auswertung auf Sendefehler oder Empfangsfehler laß mal jeweils das "UN ...Fertigmeldung" weg:
Code: 
[COLOR="#008000"]//UN #Daten_senden.Fertigmeldung;[/COLOR]
U #Daten_senden.Fehler;
R #Daten_senden_laeuft;
SPBN M090;
...
[COLOR="#008000"]//UN #Daten_empfangen.Fertigmeldung;[/COLOR]
U #Daten_empfangen.Fehler;
SPBN M110;
...
M110: SET [COLOR="#008000"]//U #Daten_empfangen.Fertigmeldung;[/COLOR]
UN #Daten_empfangen.Fehler;
R #Daten_empfangen.Fertigmeldung;

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

Kai Schulz schrieb:
Das Anwenderprogramm (Code auf Seite 1) ist gleich geblieben. Wenn ich die CPs untereinander tausche, wandert der Fehler mit. Die S7-Programme sind beide gleich.
Zum Vergrößern anklicken....
Mit "CPs untereinander tauschen" ist gemeint: SPS- und CP-Versorgungsspannung ausschalten - CPs tauschen - wieder einschalten - Fehler ist nun bei der anderen CPU?
Wenn in beiden Richtungen gleich viel gesendet und empfangen wird, dann sollte es eigentlich nicht an einer nicht 100% pefekten Realisierung liegen. Allerdings: tauschen der CPs an den CPUs entspricht auch einem tauschen der CPUs an den CPs - die Problem-Ursache kann auch in einer oder beiden CPU liegen.
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.

Harald
 
Moin Harald!

PN/DP schrieb:
Ändert sich was wenn die STRUCTs "Daten_senden" und "Daten_empfangen" nicht in TEMP sondern in STAT liegen?
Zum Vergrößern anklicken....
Mit TEMP hätte ich es wahrscheinlich gar nicht erst versucht - habe den Code aber nur überflogen und mir noch keine intensiven Gedanken darüber gemacht.

PN/DP schrieb:
Allerdings: tauschen der CPs an den CPUs entspricht auch einem tauschen der CPUs an den CPs - die Problem-Ursache kann auch in einer oder beiden CPU liegen.
Zum Vergrößern anklicken....
Interessante BetrachtungsWeise! Bin immer dafür, auch mal "das Pferd von hinten aufzuzäumen", sprich, ein Problem auch mal ganz "unkonventionell" anzugehen.
Aber, bezogen auf diesen Fall, kann ich Deinem GedankenGang noch nicht so ganz folgen. Bin schon gespannt, was sich als Ursache erweisen wird.

Gruss, Heinileini​
 

Similar threads

T
Step 7 FB funktioniert nicht wenn er das 2. mal aufgerufen wird
Antworten
18
Aufrufe
28K
tommylik
T
R
Step 7 FM 450-1, Counter, Frequenzmessung, Drehzahlmessung, Geschwindigkeitsmessung
Antworten
17
Aufrufe
31K
PN/DP
PN/DP
F
Step 7 AG_SEND mit Fehler 0x7000
Antworten
8
Aufrufe
4K
FrankF67
F
L
Step 7 Vorschlag für Error-Handling mit WinCC-Fehlerauswertung/-anzeige & Einzelquitt.
Antworten
0
Aufrufe
3K
logo78
L
M
DBs auf MMC kopieren VIPA
Antworten
0
Aufrufe
4K
Maagic7
M
Zurück
Oben