Step 7 ET200SP PtP Module Fehler W#16#81E7

[Hagen]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

 

[vollmi]

Ich nutze diesen ptp nur mit den 1500 cpus. Ich hatte den Fehler noch nicht. Aber ein Schuss ins Blaue. Wartest du vor einem erneuten Anstoss done/error ab?

 

[Hagen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich nutze diesen ptp nur mit den 1500 cpus. Ich hatte den Fehler noch nicht. Aber ein Schuss ins Blaue. Wartest du vor einem erneuten Anstoss done/error ab?

Ja, das mache ich. Was mich am meisten irritiert, ist die Tatsache das es nach einem Start der CPU funktioniert und anschliessend mit einem erneuten antriggern nicht. Kann es sein, das ich den COM_RST Trigger der Bausteine nur einmal benutzen darf? Hatte eigentlich gedacht ich könnte damit die Kommunikation auch ohne Neustart initialisieren. Mache ich da einen Gedankenfehler?

Die Frage ist darf man COM_RST mehrmals antriggern oder ist das nur einmal erlaubt, weil damit eine neue "Kommunikationsinstanz" aufgemacht wird.

 

[TP-Inc]

Hat der Receive_P2P im Instanz-DB eine Variable die y_sequence oder so ähnlich heisst? Versuch mal die auf 0 zu setzen wenn der Fehler auftritt.

 

[MSB]

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.

Um ehrlich zu sein, halte ich das bereits für den primären Fehler.

Die Bausteine werden genau 1x, zyklisch und ohne Bedingungen aufgerufen (großer).
Alles was du außen rum brauchst, kannst du ja gerne in eine Schrittkette packen, aber nicht die eigentlichen FB-Aufrufe.

 

[Hagen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat der Receive_P2P im Instanz-DB eine Variable die y_sequence oder so ähnlich heisst? Versuch mal die auf 0 zu setzen wenn der Fehler auftritt.

Muss ich Montag schauen.

 

[Hagen]

Um ehrlich zu sein, halte ich das bereits für den primären Fehler.

Die Bausteine werden genau 1x, zyklisch und ohne Bedingungen aufgerufen (großer).
Alles was du außen rum brauchst, kannst du ja gerne in eine Schrittkette packen, aber nicht die eigentlichen FB-Aufrufe.

Tatsächlich rufe ich die gleiche Instanz immer wieder in verschiedenen Schritten aber nicht im gleichen Zyklus mit verschiedenen Parametern auf. Wenn Du recht hast, müsste ich den Aufruf "zentralisieren" und in den Schritten nur die Aufrufparameter für diesen Aufruf mit Werten beladen. Könnte sein, Ausgänge darf ich ja auch nur einmal ansteuern. Ich werde schauen wie ich das umsetzen kann. Wird nicht so einfach, der Code ist recht komplex.

 

[vollmi]

Tatsächlich rufe ich die gleiche Instanz immer wieder in verschiedenen Schritten aber nicht im gleichen Zyklus mit verschiedenen Parametern auf. Wenn Du recht hast, müsste ich den Aufruf "zentralisieren" und in den Schritten nur die Aufrufparameter für diesen Aufruf mit Werten beladen. Könnte sein, Ausgänge darf ich ja auch nur einmal ansteuern. Ich werde schauen wie ich das umsetzen kann. Wird nicht so einfach, der Code ist recht komplex.

So als kleiner Tip wie ich die Bausteine normalerweise baue für solcher art Treiber.
Ich baue einen FB in dem Sich SEND_PTP und RECEIVE_PTP befinden. Dieser Baustein wird Zyklisch unbedingt aufgerufen. Zu diesem Baustein geht ein KoppelUDT in dem sich sowohl Sende wie auch Empfangsarray befinden, sowie Done, Error, Req für fürs restliche Programm welche dann SEnd und receive anstossen bzw deren Status ans restliche Programm weitergeben. Du kannst natürlich den Config benutzen, ich konfiguriere lieber direkt in der Hardware.

Die Nutzung eines FBs der sich nicht um den Treiber sondern nur um die SEND Receive und Config Bausteine kümmert hat einen sehr netten Vorteil. Das ist ein sehr einfaches Programm, wohingegen die Treiberstufe recht komplex ist. Aber den SEND/RECV Baustein kann man sich dann gleich kopieren und auch gleich einen Baustein machen der SEND/RECV auf z.B. einen SerialServer im TCP Netz macht. Treiberstufe bleibt gleich. Damit bist du so flexibel, sowohl die PTP Karten von Siemens als auch z.B. Moxa NPorts verwenden zu können.

Die Treiber-stufe kann dann völlig azyklisch arbeiten solange sie erst wieder ein Telegramm abfüllt wenn kein Sendebaustein mehr beschäftigt ist.

 

[Hagen]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo vollmi,

noch Mal Danke für die Erläuterung. Ist nachvollziehbar und macht Sinn Hätte ich selbst draufkommen sollen. Werde es aber jetzt so umsetzen.

Hatte gerade noch ein Gespräch mit einem Kollegen, der die Kommunikation auf einer anderen Plattform hat realisieren lassen. Er hat den Eindruck, das der Transmitter manchmal Teile der Telegramme verschluckt. So das meine Ende Erkennung versagt. Ich bräuchte dann eigentlich noch einen Reset des Empfangspuffer um den "Müll" zu entfernen. Aber das ist eher der zweite Schritt.

 

[Hagen]

Habe noch eine Frage. Die Bausteine FB610 - FB617 für das PtP-Module besitzen ja alle den COM_RST um sie nach dem Start der CPU zu initialisieren. Stellt sich die Frage, was passiert, wenn ich dies auf Grund von Kommunikationsproblemen erneut mache. Bringt das irgendwas? Ist es kontraproduktiv oder einfach nur nutzlos? Ich vermute fast letzteres, aber weiss jemand etwas genaueres?

 

[Hagen]

Habe noch eine Frage. Die Bausteine FB610 - FB617 für das PtP-Module besitzen ja alle den COM_RST um sie nach dem Start der CPU zu initialisieren. Stellt sich die Frage, was passiert, wenn ich dies auf Grund von Kommunikationsproblemen erneut mache. Bringt das irgendwas? Ist es kontraproduktiv oder einfach nur nutzlos? Ich vermute fast letzteres, aber weiss jemand etwas genaueres?

So kann jetzt meine Frage selbst beantworten. Habe zum einen in der Doku einen Hinweis gefunden, dass es ist nicht sinnvoll ist den COM_RST ein zweites Mal mit True zu belegen. Zum anderen haben auch meine Versuche mit dem Treiber dies bestätigt. Meine Initialisierungskette brach beim dann immer mit einem Fehler ab. Ist also nicht zu empfehlen.

Gruß Hagen