Step 7 Flankenmerker Auswertung Fehlerhaft / Impulse fehlen

Crack123

Level-2
Beiträge
361
Reaktionspunkte
27
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!


Wir hatten seid einiger Zeit nun Probleme an einer Anlage, CPU war eine 315 - 2AF03 - 0AB0 MPI/DP also sehr altes Gerät.
Speicher war zu 90% ausgelastet und Zykluszeit schwankte zwischen 80 und 112 MS, jetzt war es lt. Bedienpersonal so das seid ein paar Monaten ein Fehler sporadisch auftritt (lt. Bedienpersonal...könnte auch schon seid Anfang an sein) das die Maschine eine bewegung nicht immer ausführt, sagen wir von 50x gibts 10x das Problem.

Nach einigem einarbeiten landete ich in diesem Netzwerk :

netzwerk.jpg

also in dem Oder Glied wird M150.7 gesetzt und über die Flanke M95.0 werden die 4 nachfolgenden Elemente angesteuert,
nun ist es so das M91.5 Jedes mal gesetzt wird jedoch werden bei DB91.DBX100.2 ( gewicht erreicht ) scheinbar einige Flanken nicht ausgewertet bzw. getriggert.
Habe in einem anderen Baustein (FC) Zähler auf beide Elemente gemacht und siehe da bei 50 Abläufen 50 x M91.5 gesetzt und nur 40x DB91.DBX100.2 gesetzt
( die 2 anderen Ausgänge *R* werden schon im vorigen Netzwerk Rückgesetzt...das Programm ist sehr wirr-.-)

DB91.DBX100.2 ist aus einem Instanzdatenbaustein von einem FB heraus ...und wird dort drin weiter verwendet unter anderem,
alle Elemente in diesem Netzwerk werden nirgends anders gesetzt bzw. Manipuliert wonach ich das erklären könnte.


Da dieses Problem auch mit einer Neuen CPU (315 - 2EH14 - 0AB0 V3.2) mit Zyklus 2-3MS auftritt gehe ich mal nicht von einem Hardwareproblem aus,
wäre super wenn mir kurz jemand sagen kann was da schief läuft oder auf welchem Schlauch ich gerade stehe....
denn im Programm ist eigentlich alles mit Lokalvariablen programmiert und dreht sich quasi im Kreis und ist extrem undurchsichtig was die ganze Sache extrem erschwert.


schon mal danke! :)

lg
 
Vollkommen unklar was Du da willst.

nun ist es so das M91.5 Jedes mal gesetzt wird jedoch werden bei DB91.DBX100.2 ( gewicht erreicht ) scheinbar einige Flanken nicht ausgewertet bzw. getriggert.
Wenn der M91.5 kommt kommt der Flankenhilfsmerker M95.0 nie!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also SOLL M150.7 kommt > Positive Flanke an M95.0 > M91.5 Setzen und DB91.DBX100.2 ebenfalls 1 für einen Zyklus

Da das Programm so schon Jahre gelaufen ist muss das so irgendwie ja Funktioniert haben, das Programm ist sehr undurchsichtig und damit eine Katastrophe zur Fehlersuche.



Da dieses Konstrukt nicht auf meinem Mist gewachsen ist bin ich mir keiner Schuld bewusst! :)
 
Zuletzt bearbeitet:
Hallo ,
es hört sich danach an das das Bit DB91.dbx100.2 aus dem InstanzDB von dem dazu gehörigen FB wieder überschrieben wird. Nun müsste man die Aufrufumgebung kennen um zu sehen ob meine Vermutung stimmt. Wenn du deine Zähler FC im OB1 letztes Netzwerk aufgerufen hast wäre das eine Erklärung. Dies kannst du testen indem du einen Zähler direkt unter dem Netzwerk das du im Bild beschrieben hast programmierst und einen weiteren Zähler im letzen Netzwerk vom OB1 programmierts. Beide Zähler mit den selben Signalen beschalten(natürlich unterschiedliche Zähler verwenden) und sehen ob die Zählwerte sich unterscheiden. Wenn ja gehe ich davon aus das der FB das Datenbit überschreibt.
 
Ahhh muss kurz Zurückrudern, der DB gehört nicht zu einem FB, das ist der einzige Normale Datenbaustein in dem Programm...der rest besteht nur aus InstanzDB!

Dieses Netzwerk ist trozdem der einzige Aufruf dieses Bits, wird sonst nirgendwo Rückgesetzt/Gesetzt nur weiterverarbeitet als Input.

Das mit dem OB1 muss ich Morgen nochmal schauen, habe den Letztstand des OBs nicht hier.
 
Hallo ,
es hört sich danach an das das Bit DB91.dbx100.2 aus dem InstanzDB von dem dazu gehörigen FB wieder überschrieben wird. Nun müsste man die Aufrufumgebung kennen um zu sehen ob meine Vermutung stimmt. Wenn du deine Zähler FC im OB1 letztes Netzwerk aufgerufen hast wäre das eine Erklärung. Dies kannst du testen indem du einen Zähler direkt unter dem Netzwerk das du im Bild beschrieben hast programmierst und einen weiteren Zähler im letzen Netzwerk vom OB1 programmierts. Beide Zähler mit den selben Signalen beschalten(natürlich unterschiedliche Zähler verwenden) und sehen ob die Zählwerte sich unterscheiden. Wenn ja gehe ich davon aus das der FB das Datenbit überschreibt.
Der DB91.DBX100.2 kommt sowieso nur eine Zyklus lang.
 
Im Grund hieße das meine Zähler arbeiten nicht korrekt weil Sie irgendwo im Programm verteilt sind und das Netzwerk funktioniert eigentlich ?

Alleine be dem Gedanken das Prog nochmal durchzustöbern um rauszufinden was los is lässt mir die Nackenhaare zu Berge stehen :p


Ich sehe nicht wo der M91.5 gesetzt wird.... da musst Du uns schon mehr Code schicken.


Hu?

Da ist ein dickes großes S in dem M91.5 :)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo!

ich habe mal Testhalber eine Ausschaltverzögerung mit 30 MS (Zykluszeit ca 20MS ) vor diesen DB91.DBX100.2 gemacht,
dieser kommt jetzt jedes mal mit und der Sporadische Fehler bzw. Aussetzer der Anlage ist so erstmal weg ( Bedienleute können erstmal etwas entspannen....)

Das ist natürlich absolut keine Richtige Lösung...schon klar....was mich aber immer noch stutzig macht was läuft in diesem Programm schief ?

Falls jemand Einsicht in das ganze Programm haben will gerne Bereit.

lg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das in diesem Programm irgendwas NICHT zweifelhaft ist würde mich sowieso wundern....aber inwiefern würdest du sagen erzeugt der Aufruf das Problem?

Als Beispiel war die Zykluszeit der Steuerung vorher zw. 75-105 MS mit den selben Problemen, was halt echt komisch ist wieso es scheinbar seid einiger Zeit Funktionierte bzw. ich hoffe das mich die Bedienmenschen nicht anflunkern....!
 
Die FC90, in der deine Flanke gebildet wird, wird im FB90 aufgerufen. Der FB90 wird im OB1 und im OB35 aufgerufen und auch fast komplett abgearbeitet. So ganz genau habe ich es mir nicht mehr angesehen. Der OB35 unterbricht den OB1. Wenn jetzt im OB1-Zyklus die Flanke gesetzt wird, wird sie an undefinierter Stelle des OB1 durch den OB35 zurückgesetzt. Der Impuls steht also nicht über einen vollen OB1-Zyklus an. Somit kann er auch nicht konsistent über einen Zyklus abgefragt werden. Das erklärt deine unterschiedlichen Zählerstände.

Zu dem Programm an sich möchte ich mich mal besser nicht äußern :ROFLMAO: .
 
Der ob35 wird hier alle 100ms aufgerufen. Das heisst. Sämtliche Datenpunkte (auch solche die aus der Hardware kommen) können sich mitten im OB1 Zyklus ändern. Bei OB1 Zyklen länger als 100ms sogar öfter als einmal. Das führt einerseits zu Inkonsistenten Daten im Programm.

Und ausserdem führt es sehr schnell mal dazu, dass ein und dasselbe Programm sich auf verschieden leistungsstarken CPUs auch anders verhält.

Ich hab jetzt aber nur mal kurz drübergeschaut.

mfG René

Edit: Hardware von aussen wird konsistent eingelesen. Da im OB35 nicht auf die Peripherie zugegriffen wird sondern aufs Prozessabbild. Trotzdem unschön diese verschachtelung. Auch im Simulator natürlich entsprechend schwer nachzuvollziehen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu dem Programm an sich möchte ich mich mal besser nicht äußern :ROFLMAO: .

Das beste ist, daneben steht eine Anlage selben Herstellers wo das ganze genauso nochmal aussieht.... :neutral:



Das mit dem doppelten Aufruf hatte ich noch garnicht gesehen....Gott :confused:

EDIT: Dieser doppelaufruf ist definitiv schon seid Anlagen erst IBN vorhanden, im Stand von 2011 ist das ganze auch schon da.


Die Frage für mich ist warum fängt das jetzt erst an zu spinnen, vorallem kann ich mich nicht erinnern das solche Probleme in der Häufigkeit früher vorgekommen sind,
wir reden Aktuell von 10x Anlage Automatik fahrt 6x Problem teilweise,
nach CPU tausch waren die ersten 2 fahrten gleich mal Fehlerhaft, sowas fällt jedem auf.
 
Zuletzt bearbeitet:
Das beste ist, daneben steht eine Anlage selben Herstellers wo das ganze genauso nochmal aussieht.... :neutral:...
Ist das der Hersteller, der im Bausteinkommentar des OB1 genannt ist..:ROFLMAO: ?


..Das mit dem doppelten Aufruf hatte ich noch garnicht gesehen...
Das habe ich mir gedacht. So etwas übersieht man normalerweise immer. Ich bin auch nur über die Referenzdaten darauf gestoßen.
 
Da wollte wohl jemand nicht von außen auf IDB-Variablen zugreifen und hat kurzerhand den "Eigentümer"-FB selber aufgerufen. Allerdings ändert der vom OB35 eingeschobene Aufruf nicht nur die Zeitzähler sondern bearbeitet den kompletten FB90 und FC90 - diese sind aber gar nicht reentrant-fähig geschrieben. Es kann und wird allerdings vorkommen, daß der OB35 den FB90 oder FC90 unterbricht und dann kommt es zu solchen Phänomenen, wenn die Unterbrechung an "ungünstigen" Stellen stattfindet.

Weiters: Variablen die multitasking-mäßig von verschiedenen Tasks beschrieben werden, dürfen in jeder Task (bzw. der niederprioren Task) nur genau einmal gelesen werden, weil sie sich zwischen den Lesezugriffen geändert haben können.

Du solltest die 3 Zeitzähler-Variablen außerhalb der FB90-Instanz in einem globalen DB in einer zusammenhängenden Struktur unterbringen und am Anfang des FB90 mit SFC81 UBLKMOV in einem Stück in FB90-lokale Kopien umkopieren.
Der OB35 darf dann nur direkt die globalen Zeitzähler-Variablen inkrementieren (und auf keinen Fall Bausteine aufrufen, die auch in anderen OB-Ebenen aufgerufen werden).


Wie genau muß die Zeitmessung sein? Vielleicht läßt sich das Ganze mit der nun viel schnelleren CPU auch ohne Multitasking durch normale Timer oder SFC64 TIME_TCK oder Addition von OB1_PREV_CYCLE lösen?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nachtrag:
Es geht sogar viel einfacher: Der OB35 setzt nur ein Bit daß er aufgerufen wurde (im einfachsten Fall direkt das Input-Bit #OB35_Aufruf = DB90.DBX20.0 (*)). Im FB90 Netzwerk 2 wird das Bit abgefragt, und wenn gesetzt dann zurückgesetzt und die Zeitzähler incrementiert.
Also eine minimale Änderung nur im OB35 sollte das Problem beseitigen.

Nachtrag (*) in dem Fall darf natürlich im OB1 beim FB90-Aufruf der Eingang "OB35_Aufruf" nicht beschaltet werden.

Harald
 
Zuletzt bearbeitet:
Ist das der Hersteller, der im Bausteinkommentar des OB1 genannt ist..:ROFLMAO: ?

Natürlich, ich kann mich bei einer anderen änderung anno 2005 erinnern das selbst der Programmierer dieser Firma etwas 3 Tage brauchte um *Ihr* Programm zu verstehen bzw. sich durchzuwinden....:rolleyes:


@PN/DP

Wir sprechen hier von einem Dosierofen der mit 950°C flüssiges Messing per Servohydraulischem Ventilstopfen durch ein Loch in eine Rohrschleudergießanlage abgießt ( wir reden von Abgüßen zwischen 80 und 800kg) ,
im Normalfall wird dies über eine Waage gesteuert (Funktioniert auf +-1KG genau),
dann gibt es da noch diesen Zeitbetrieb wo man nach eingegebener Zeit Quasi den Abguß steuert (2 Stufig Grob/Fein) , das dies sowieso nicht besonders genau ist sollte klar sein, ist eher so eine Art Notbetrieb.

Auch angemerkt sehr viele Teile des Programms werden auch nicht mehr wirklich verwendet, es wurde die externe Waage durch die Interne ( Siwarex ) ersetzt, wurde halt Quick and Dirty *reingebastelt*....


Es gibt genügend externe IDB zugriffe in dem Programm was wie schonmal geschrieben bei der Suche im Prog. ein eher schlechter Witz ist.

Mein Problem hat ja auch eher nichts mit dem Abgußvorgang zu tun sondern mit dem wegfahren des Ofens nach dem der Abgußvorgang beendet wurde ( M91.5 gesetzt und DB91.DBX100.2 Flanke..)



Nebenbei dieser OB35 Quatsch da ist mir sowieso etwas to much, klar ich verstehe das die Zeitmessung damit genauer wird aber wozu dann trozdem noch OB1 aufruf, ich mein die Zykluszeit war sowieso schon fast 100MS
 
Zuletzt bearbeitet:
@Crack,

bei so einem Programm wäre ich mit Änderungen sehr vorsichtig. Selbst wenn man einen mutmaßlich Fehler beseitigt, kann man nie wissen was es so alles nach sich zieht. So schräg kann man manchmal gar nicht denken.

Ist jetzt eigentlich die neue, schnelle CPU verbaut oder wieder die alte? Im Netzwerk 2 des OB1 hatte man mit etwas "Finetuning" den Zyklus gekonnt um 17ms verlängert. Der aufschlussreiche Kommentar dazu lautet
"Zyluszeit um 17 MS erhöht wegen Programm"
Wie du in #1 schreibst, lag die Zykluszeit der alten CPU bei ca. 100ms. Falls diese Zykluszeit u.U. auch für andere Unbekannte notwendig ist, dann könntest du unter Verwendung der schnellen CPU den ganzen OB1 mit dem OB35 synchronisieren. Im OB35 einfach einen Merker setzen und diesen am Ende des OB1 in einer While-Schleife abfragen und rücksetzen. Damit kannst du deine Zeitzähler auch im OB1 exakt um 100ms hochzählen.

Warum der Fehler erst jetzt auftritt, ist mit auch unklar. "Software rostet nicht", hat mal einer gesagt.
 
Zurück
Oben