Mittlere Katastrophe mit OSCAT-Bausteinen

[megamogli]

Hallo Leuts,

heute ist eine kleine Katastrophe in meiner Haussteuerung passiert, die so wie sie ist eigentlich schon 3 Jahre fehlerfrei läuft.

System:
Haus: Beckhoff BX9000 mit 3 CAN-Slaves BK5120 und Pro-Face-Panel
Garten und Teich: BX9000 mit 3 CAN-Slaves BK5120 und Pro-Face-Panel
Die BX9000 sind über Netzwerk verbunden.

Die Trennung habe ich gemacht, damit im Garten und somit im Teich auf keinen Fall die Pumpen usw. ausfallen, wenn ich im Haus "spiele", und dann meine Kois
auf dem Rücken schwimmen.

Heute hat sich die autarke Steuerung der Aussenanlagen richtig bewährt.
Bei einem zufälligen Blick auf meine Energiebilanz auf einem meiner Pro-Face-Panels bemerkte ich, dass die Energiemessung nicht mehr funktioniert und negative Werte im Spiel sind. Anhand des Energieverbrauchsdiagramms fing das Desaster heute morgen um 04:00 Uhr an.

Im Programm lieferte ein TIME_TO_REAL-Baustein plötzlich negative Werte. Da mittlerweile auch der betreffende BX9000 3x ausgestiegen ist und vollständig vom Netz war habe ich den betreffenden Baustein deaktiviert und dies auch als Bootprojekt gespeichert.

Nach 2h Ruhe flackerte plötzlich im Flur eine Lampe die u.A. über einen Timer angesteuert wird. Beim Blick in den Sicherungskasten pumpte ebenfalls das Relais für die Kaffeemaschine (Das wäre morgen früh bei eingeschalteter Maschine abgefackelt).

Nach kurzer Analyse habe ich festgestellt, dass der Baustein RTC_2, den ich für meine Lokalzeit mit automatischer Sommerzeitumstellung nutze, fast im Sekundentakt den Lokalzeitausgang immer wieder umstellt und zwar nach dem Muster (07:40 <=> 13:40), was natürlich sämtliche meiner Zeitauswertungen überfordert. Der normale Zeitausgang UDT blieb von dem Effekt unberührt, dies fand nur bei LDT statt.

Habe schnell die Zeitauswertungen auf die PLC-Zeit gelegt und warte nun auf den Ausfall der nächsten komplexen Geschichte.

Wie bereits gesagt läuft die Anlage seit mindestens 3 Jahren fehler- und absturzfrei und ich bin mit meinem Latein am Ende.

Ich würde mich über jeden Ansatz zur Fehleranalyse sehr freuen!

Freundliche Grüße

Mick

PS: Habe gerade noch einmal kontrolliert, mittlerweile ist der UDT-Ausgang des RTC_2 ebenfalls am "tanzen".

[peewit]

hallo

du musst schon konkrete beispiele bringen, sonst kann dir niemand helfen

1. negative werte bei time_to_real
  bei was für einen time wert passiert das , und woher kommt dieser !

2. bx9000 3x ausgestiegen
    warum , was ist die fehlermeldung ?

3. rtc_2 springt +- 6 stunden hin und her
    kann ich mir gar nicht vorstellen, das das der baustein selber verursacht
   
mehr infos !

[megamogli]

Hallo und Danke für die schnelle Reaktion,

habe einmal 2 Bilder gepostet.

Der Timerwert kommt direkt aus einem TP_X und zwar soll die ET Millisekundengenau als Messzeit abgespeichert werden und geht auf einen SH.
Der negative Wert tritt in diesem Fall in jeder Sekunde einmal auf (augenscheinlich), also ständig!

Bei dem Uhrenfehler bezieht der RTC_2 nur die Zeit direkt aus dem RTC-Baustein von Beckhoff (Twincat).

Aus welchem Grund der BX9000 ausgestiegen ist weiss ich nicht. Er stand im Stop und war über Netzwerk nicht mehr ansprechbar.
Nach einem Spannungsreset konnte ich ihn wieder ansprechen.

Auf den Bildern sind die entsprechenden Änderungen zu sehen, damit die Karre erst mal weiterläuft.





Gruß

Mick

[peewit]

merkwürdig

beim RTC_2 siehst du das der baustein beim parameter udt,ldt die korrekten werte ausgibt, erst die anzeige der variablen zeigt falsche werte an
in dem fall würde ich sagen, baustein arbeitet richtig !
werden "Weltzeit" und "Lokalzeit!" irgenwo anders noch verändert ?


hast du schon mal probiert alles zu löschen und das programm komplett neu zu übertragen

[megamogli]

Alles löschen und neu übertragen bringt mir nicht die Ursache, ich möchte den gleichen Fall nicht in ein paar Tagen wieder erleben.

Mit den Ausgängen UDT und LDT hast Du Recht, aber die Variablen werden definitif nicht mehrfach beschrieben. In der gestrigen Phase, als die SPS 3x abgestürzt ist habe ich im Status aber gesehen, dass selbst die Ausgänge direkt diese Werte lieferten.

Im Moment habe ich die Zeitauswertungen noch auf der Standard-RTC und den Energieauswerter wieder aktiviert. Die SPS läuft sauber, aber die TIME_TO_REAL-Wandlung aus einem TP_X heraus macht weiterhin die Probleme mit den negativen Werten. Habe das TP_X auch mal gegen ein TOF getauscht mit dem gleichen Resultat.



Die untere blaue Kurve ist der ET des Zeitgliedes, die Rote kurve ist eine dazwischengehängte TIME-Variable zur Kontrolle und die grüne Kurve ist der REAL-Wert nach der Umwandlung. Es ist deutlich zu sehen, dass die Millisekunden seit der Triggerung mal positiv und mal negativ auflaufen.
Habe selbst die Ablaufkontrolle (Prioritäten) einmal in den unterschiedlichsten Konstellationen laufen lassen - Leider ohne Ergebnis.

Bin für jeden weiteren Tip dankbar...

Gruß

Mick

[Tom]

Da bis jetzt alles funktioniert hat und das Verhalten recht kurios ist, würde ich von einem Hardware-Problem ausgehen. Kannst du die BX mal gegeneinander tauschen?

[megamogli]

So...

Urlöschen und Alles neu aufsetzen hat nichts gebracht - Erst der Wechsel des Controllers führte zum Erfolg, Alles wieder beim Alten.

Nun macht man sich ja so seine Gedanken: Warum leitet ein solcher Controller eines namhaften Herstellers sein Ableben damit ein, dass er simple
Real-Berechnungen fehlerhaft durchführt und das auch noch in unterschiedlichen Modulen.
Bei meiner Privatanwendung wäre der schlimmste Fall das Abrauchen des Kaffemaschinenrelais oder der Defekt einiger Rolladenmotoren, weil die
Steuerung durch die Falschberechnung der Zeit 3 mal in der Minute die AUF- sowie die ZU-Zeiten berechnet.

Bei einer Anwendung in der Automobilherstellung würde er dann den Roboterarm einfach in die frischlackierte Haube der S-Klasse brettern!

Ich glaube, meine gute alte S5 hätte das noch anders abgehandelt.

Nochmals danke für Eure Ratschläge

Mick

[peewit]

schön wenn du die wirkliche ursache gefunden hast

die symptome waren ja schon sehr merkwürdig


die überschrift sollte somit nicht "Mittlere Katastrophe mit OSCAT-Bausteinen" sondern "Mittlere Katastrophe mit Beckhoff Steuerungen" lauten.

das die alte s5 bei hardware-defekt sich dabei ganz fromm verhält , das glaube ich alerdings auch nicht.

[Tom]

Bei einer Anwendung in der Automobilherstellung würde er dann den Roboterarm einfach in die frischlackierte Haube der S-Klasse brettern!

So ähnlich kommt das schon mal vor. 

Ich glaube, meine gute alte S5 hätte das noch anders abgehandelt.

Naja, ich hab noch täglich damit zu tun und die hat auch ihre Macken, erst recht, wenn die Baugruppen ins Alter kommen. Da kommen lustige Fehlerbilder zum Vorschein.

[hugo]

beim lesen deines threads ist mir noch etwas wesentliches aufgefallen:
du hattest zwei screenshots gepostet, und auf dem zten ist etwas megafaul !

deine bausteine haben rechts oben ein kleines kästenchen mit einer zahl.

uhr_setzen = 27, OR = 22, RTC = 23, Ausgänge des RTC 20 .....
diese zahlen haben eine ganz wesentliche bedeutung, sie legen die ausführungsreihenfolge der bausteine fest.
bei dir werden zuerste die werte der uhr an die ausgänge geschrieben (20) dann die oder verknüpfung ausgeführt, dann die rtc und dann uhrsetzen.

das macht nicht viel sinn, und ich denke das ist auch nicht das was du möchtest.

die ausführungsreihenfolge der bausteine kannst du geziehlt setzen unter extras reihenfolge oder mit rechte maustaste auf einen baustein und reihenfolge .....
du hkannst auch ganz einfach reihenfolge nach datenfluss anordnen auswählen.

[vicky]

Hallo megamogli,
Du schreibst Du hast einen Messimpuls am Stromzähler.
Kannst Du mir sagen was für einen Typ Du da einsetzt?

[shooter]

oder einen block wird nicht richtig beendet wodurch den memory vollauft, und es wird wieder mal passieren.