Step 7 Ethernet-Kommunikation S7<-->PNOZ

Ralle

Super-Moderator , User des Jahres 2006-2007
Teammitglied
Beiträge
15.404
Reaktionspunkte
4.039
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir haben ein PILZ PNOZ-Mini mit einem Ethernetmodul.
Diese Pilz lesen wir mit einer S7 über Ethernet aus, dazu bauen wir manuell mit der S7 die Verbindung auf und nutzen die FB63/63 (TSend/TRCV).
Prinzipiell läuft die Kommunikation, aber sporadisch (oft bei Auslösen von Aktionen des PNOZ) kommt es zu Fehlern.

1. Die Kommunikation läuft korrekt weiter.
2. Die Kommunikation läuft weiter (FB63/63 werden gestartet und bringen korrekt das Done), aber es kommen keine Datenänderungen vom PNOZ.
3. Das Send geht korrekt ab, auf dem Empfang wird aber "ewig" gewartet.

Weder das PNOZ noch die FB63/64 geben in Fall 2 und 3 eine Fehlermeldung aus, so dass wir davon ausgehen, dass die Aufträge korrekt rausgegangen sind.

Wir lassen das ganze in einer "Endlosschleife" laufen:

1. Send +Receive an FB63/64 auf True, wenn Send=False und Receive=False.
2.1. Wenn Send.Done = True, dann Send auf False.
2.2 Wenn RCV.Done = True, dann Receive auf False.
3. empfangene Daten umrangieren
4. wieder zu 1.

Kenn jemand das Problem?
Gibt es Wartezeiten, die man einhalten muß, bevor man dem PNOZ wieder per Send eine Anforderung schicken darf.
Kann es sein, dass wir u. bestimmten Umständen mehr als einmal Daten empfangen nach einem Send und daher Probleme haben?
Ist das PNOZ bei eigenen Aktionen mit der Kommunikation überlastet?
Sind die Done-Signale der FB63/64 zuverlässig, was das senden betrifft oder kann auch hier ein Fehler auftreten?
 
ARGH, wir haben das Problem offensichtlich gefunden.

Der Receive-Baustein hatte noch in alter Tradition eine feste Empfangslänge eingetragen. (30)
Dazu kam ein Programmierfehler bei der CRC-Prüfsumme.
Wenn dann ein solcher CRC-Fehler vom PNOZ bemerkt wurde, kam ein "Fehlertelegramm", das eine andere Länge hatte und dieses Telegramm und alle folgenden landeten dann natürlich versetzt im Empfangsbuffer. Die folgende Auswertung in der SPS lieferte also nicht die erwarteten Rückmeldungen und das Ganze "hing".
Empfangsbuffer auf 0 und das ganze funzt nun seit einigen Stunden durchgängig.

PS. Was ich nicht verstehe, Pilz hat ein kleines Step7-Beispiel geliefert, das nutzt den OB35!!!!!!! Darin werden dann die TSend/TRCV-Bausteine aufgerufen. Die Bausteine arbeiten doch asynchron, da finde ich die Nutzung im OB35 eher ungewöhnlich. Außerdem ist der OB35 u.U. für Regelungen ausgelastet. Ich hab das Ganze nun normal in einem FB, wie oben beschrieben und finde zudem, dass Pilz mit einem ordentlichen Baustein, den man seinen Kunden zur Verfügung stellt, wesentlich besser fahren würde, als mit diesem Beispiel, das eher einem Funktions-Konzept ähnelt. Eigentlich schade, Pilz könnte da mit einfachen Mitteln einen noch besseren Service leisten.
 
Zurück
Oben