CP342-5 Protokollfehler im Miniprotokoll

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aufbau:

CPU 315-2DP (6ES7 315-2AH14-0AB0 FW V3.0)
CP 342-5 (6GK7 342-5DA01-0XE0 V3.0)
CP 342-5 (6GK7 342-5DA01-0XE0 V3.0)
(SM ...)
(FM 357-2)

Vor kurzem habe ich die CPU durch oben genannte ersetzt (von 316-2DP ALT auf 315-2DP NEU) dadurch wurde nicht nur der Speicher erweitert sondern auch die Zykluszeit drastisch verkürzt (von 130ms auf 9ms) - an sich positive und gewünschte Effekte.

Problem bei Taktung der FM war auch recht schnell behoben, aber ein Problem bleibt. Der zweite Profibus CP spuckt seit dem

"Protokollfehler im Miniprotokoll 0xF9C1:0x0702 / 0x2202 0080"
"Protokollfehler im Miniprotokoll 0xF9C1:0x0702 / 0x2202 0090"

anfangs zyklisch, mittlerweile habe ich den Aufruf der Kommunikation nur noch alle 20 Zyklen zugelassen, dadurch wurde der Fehler sporadischer aber er ist immer noch da!

Eine Erhöhung der Aufrufzyklen möchte ich nur im Notfall akzeptieren - suche gerade einen neuen Ansatz (der nicht im Austausch der relativ alten CP342-5 mündet!) - Ideen?

 

[HaDi]

Also, ich hab 2 Stellen gefunden, die evtl. zu deinem Problem passen:

Link1
Link2

Demnach könnte es, je nachdem wie der CP betrieben wird, einen Versuch wert sein

-andere Bausteinversionen zu verwenden
oder
-bei DP-Slave-Betrieb das Pollintervall im Master zu verlängern.

Bemerkenswert finde ich den 2. link, wo dieses Verhalten in Verbindung mit den "neuen" CPUs 316-2DP und 318-2DP beschrieben wird ...

Grüße von HaDi

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

für mich ist link1 interessanter

die Kommunikation ist mit FC1 und FC2 gebaut, also mit der richtigen Version, wenn ich das richtig sehe. Was jetzt aber interessant ist, ist die Fussnote

1)
temporärer Status = 80C4h ignorieren (Eintrag im Diagnosepuffer: "Fehler im Miniprotokoll")

das ist das, was ich tue, denn die Kommunikation funktioniert ja. Aber ich will eben auch die ScheißFehler-Lampe aus haben.

Ferner gibt es mir noch Rätsel auf, warum der Fehler nur beim zweiten CP auftritt (Datenmenge gleich - und durch Fehlinterpretation des Errichters auch gering <240Byte/CP)

die CPs arbeiten im Masterbetrieb und wenn ich die Tabelle in Link1 betrachte, kann ich keinen anderen Baustein verwenden.

Einzige Idee die ich jetzt noch habe ist die beiden Busse zusammen legen, da sie durch aus die größere Datenmenge unterstützen (und am besten auf die DP-Schnittstellle der CPU hängen, Kommunikation zum übergeordneten System dann auf Ethernet... ) aber das ist ein größerer Umbau.

Bemerkenswert finde ich den 2. link, wo dieses Verhalten in Verbindung mit den "neuen" CPUs 316-2DP und 318-2DP beschrieben wird ...

ja, 2000 waren die auch noch "neu"
die ausgebaute 316er war von 1999 - V1.2.1

und ich hab noch zwei gleiche Anlagen ähnlich umzubauen... argh.

 

[HaDi]

die CPs arbeiten im Masterbetrieb und wenn ich die Tabelle in Link1 betrachte, kann ich keinen anderen Baustein verwenden.

Ich verstehe die Tabelle so, dass FC1/FC2 in der Version V3.0 das Fehlverhalten mit den CPs 5DA00 und 5DA01 haben und ab 5DA02 nicht mehr.
Umgekehrt haben FC1/FC2 in der Version 1.11 das Fehlverhalten erst ab 5DA02.
Demnach müssten bei dir die V3.0-Bausteine laufen und die V1.11 wären zu testen.
Ansonsten würd ich rein aus Spieltrieb z.B. mal testweise die Steckplätze tauschen oder die MPI-Adressen ändern.
Das Zusammenlegen halte ich auch für eine gute Idee, das spart ja auch Energie und generiert (möglicherweise eines Tages gefragte) Ersatzteile.

Grüße von HaDi

 

[vierlagig]

die Version bezieht sich also auf die Baustein Version, nicht auf die CP-Version?
zuviele Versionen...

also die Baustein-Version ist 1.11, was heißen würde, dass die Fußnote nicht gilt - es also wieder in den kritischen Bereich rückt.

Umbau auf FC5/6 ist ja mindestens so umständlich wie ein Umbau des gesamten Netzes - da bereite ich doch lieber diese finale Lösung vor, da weiß ich, dass es am Ende funktioniert

(auch wenn mich die Sache mit dem Spieltrieb reizt - leider muß die Anlage produzieren, produzieren, produzieren ... für den CPU-tausch gab man mir ein 30min-Zeitfenster ... )

also komplett-Umbau - danke HaDi

 

[HaDi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also, ich bin ja von Natur aus faul. Deshalb würd ich vor dem "großen" Umbau (der es für mich wäre!), folgendes machen:
Ich würd die CPU komplett auf die ursprünglichen 130ms einbremsen und wenn der Fehler dann weg wäre, die beiden CPs gegen einen aktuellen austauschen und die Bremse wieder lösen. Damit wär alles wieder gut und das ließe sich auch in einem 30min-Fenster bewerkstelligen.
Es sind aber natürlich noch eine Menge anderer Gründe denkbar, die auch mich für die große Lösung stimmen ließen, ging mir nur grad so durch´n Kopf.

Grüße von HaDi

 

[vierlagig]

Ich würd die CPU komplett auf die ursprünglichen 130ms einbremsen

die 315-2DP unterstützt keine "Mindestzykluszeit" *grummel*

 

[HaDi]

Sowas nutze ich eigentlich nie , ich hab das zu S5-Zeiten schon mit einem eigenen "FB-Brems" gemacht ...

Grüße von HaDi

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

die 315-2DP unterstützt keine "Mindestzykluszeit" *grummel*

Ja, das ist manchmal durchaus sinnvoll. Ich habe das im Moment auf 10 ms. Hat auch den Vorteil, das es keine Zykluszeitschwankungen gibt.

 

[vierlagig]

Sowas nutze ich eigentlich nie , ich hab das zu S5-Zeiten schon mit einem eigenen "FB-Brems" gemacht ...

Grüße von HaDi

was macht der? regelt die zykluszeit durch eine dynamische schleife? in abhängigkeit der zykluszeit des vorherigen zyklusses?

 

[HaDi]

Nein, nein, so was ausgefeiltes darfst du von mir nicht erwarten.
Es ist einfach nur eine Schleife und den Vergleichswert für die Anzahl der Durchläufe ermittle ich per "Steuern Variable" bzw. VAT händisch unter Beobachtung der aktuellen Zykluszeit.
Ist mal unter Produktionsdruck nach CPU-Tausch von 946/947 auf 948 an einer 155U entstanden und hat seither noch 2-3 Mal geholfen.
Zugegeben, das Ganze Baustein zu nennen, ist wohl etwas übertrieben ...

Grüße von HaDi

 

[SoftMachine]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo !

habe hier:
http://support.automation.siemens.c...kollfehler+cp342-5&ID=16714814&ehbid=16714814

folgendes gefunden:

Bei Einsatz des CP342-5 (6GK7 342-5DA00-0XE0 und 6GK7 342-5DA01-0XE0) bzw. CP343-5 (6GK7 343-5FA00-0XE0) mit CPUs der neuen Generation (CPUs mit Micro MemoryCard-Schacht) kann es sporadisch zu Fehlermeldungen an den Kommunikationsbausteinen kommen. Das Erscheinungsbild kann beispielsweise bei Tausch der S7-300 CPU auftreten


Einsatzrandbedingung für den CP342-5 (6GK7 342-5DA00/01-0XE0)

Erscheinungsbild:

- an den Kommunikationsbausteinen FC1...6 (aus der SIMATIC_NET_CP Bibliothek) werden folgende STATUS-Meldungen sporadisch angezeigt
- 80C3: Betriebsmittel (Speicher) belegt
- 80C4: temporärer Kommunikationsfehler
- 80B0: Baugruppe kennt den Datensatz nicht
- im NCM-Diagnosepuffer des CPs werden Miniprotokoll-Fehlermeldungen eingetragen

Umgehung:
- Wiederholen der fehlerhaften Aufträge
oder
- Verwenden eines CP342-5 (ab Bestellnummer 6GK7 342-5DA02-0XE0) bzw. CP343-5 (ab 6GK7 343-5FA01-0XE0).


Vielleicht hilft dies ...

Grüsse

 

[vierlagig]

oder
- Verwenden eines CP342-5 (ab Bestellnummer 6GK7 342-5DA02-0XE0) bzw. CP343-5 (ab 6GK7 343-5FA01-0XE0).

kenn ich, deswegen:

suche gerade einen neuen Ansatz (der nicht im Austausch der relativ alten CP342-5 mündet!)

 

[Jochen Kühner]

Wird den der SFC47 von der Cpu unterstützt?

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wird den der SFC47 von der Cpu unterstützt?

schafft doch bei einmaligen aufruf auch nur 32,767 ms ...
ich möchte ehrlich gesagt nicht weiter rum pfuschen.
das wird jetzt umgebaut. ethernet-cp ist bestellt. größerer switch auch. geht los...