Hallo,
arbeite seit geraumer Zeit an einem Treiber, der einen Messtransmitter beschreibt und ausliest. Verwende eine S7-317PN/DP und programmiere mit Step7 V5.6 und SCL.
Nach dem Start der CPU wird eine Init-Sequenz ausgelöst, die die Bausteine FB613 "Send_P2P" und FB614 "Receive_P2P" initialisiert, ein paar Parameter an den Transmitter sendet und zum Schluss noch einige andere Parameter vom Transmitter anfordert und empfängt. Dies funktioniert nach einem Warmstart auch alles problemlos und zuverlässig. Anschliessend können dann auch Messdaten angefordert und empfangen werden, was der Normalbetrieb ist.
Nach einiger Zeit kommt es aber manchmal vor, das sich die Kommunikation aufhängt. Bisher hilft es dann das PtP-Module zu entfernen und die Initialisierungssequenz per Software-Trigger auszulösen. Auch das funktioniert erfolgreich. Allerdings ist das entfernen der Hardware mehr als unpraktisch. Wenn ich die Initialisierung ohne Hardwaredemontage durchführe, bleibt die Schrittkette in dem Schritt hängen, wo sie das erste Mal Daten empfangen soll und der Receive_P2P Baustein meldet den Status Code W#16#81E7 zurück. Laut Doku bedeutet das, das mehrere Instanzen des Bausteins auf das gleiche Module zugreifen. Das kann ich aber eigentlich ausschliessen und erklärt auch nicht, warum es nach einem "Hardeware-Reset" funktioniert. Ich habe mittlerweile auch den FB610 "Port_Config" in die Schrittkette integriert, weil ich hoffte durch diesen den "Hardware-Reset" nachbilden zu können. Leider ohne Erfolg.
Für die Schrittkette habe ich mir einen FB gebaut, den ich in jedem Schritt mit verschiedenen Parametern aufrufe und in dem die eigentlichen Send- und Receive-Kommandos aufgerufen werden. Da dies aber immer die gleiche Instanz ist, sollte eigentlich das kein Problem sein.
Insgesamt eine Herausforderung, zu der es vermutlich keine einfache Lösung gibt, zu der ich aber auf eure Hinweise hoffe, mit denen ich eine Lösung erarbeiten kann.
Gruà Hagen