Step 7 Flankenmerker Auswertung Fehlerhaft / Impulse fehlen

[Crack123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es ist die Neue DP/PN CPU Verbaut, nebenbei diese 17MS verlängerung ist dann tatsächlich mein Werk - der Kommentar ist sowieso nur für mich wichtig momentan,
ohne diesen hätte ich eine Zykluszeit von grademal 3-4MS gehabt was so wie ich mir denke/dachte noch mehr Probleme verursacht hätte,
dies war jetzt für meine *Programmierkenntnisse* die Einfachste und schnellste Variante, das können auch anderen Leute noch verstehen was da passiert.

In einem Baustein wird zb. mit der Zykluszeit eine Überwachung für einen Druckaufbau/sek überwacht und dort damit ein Wert berechnet, mit den nun 20MS viel das auswerten bzw. das Umrechnen für mich leichter.



Diese Zeitzähler sind im Prinzip nur wichtig wenn dieser Zeitmodbus benutzt wird, was Aktuell nicht der Fall ist, die Zykluszeit Künstlich auf 70-100MS verlangsamen kann auch nicht Sinn der Sache sein....alles Mist :neutral:
Zu einer Neu IBN mit einem Neuen Programm wird es nicht kommen da die Sicherheitsbedenken viel zu groß sind und das Extern vergeben einfach zu teuer wäre, leider!




Frage mich was würde eigentlich passieren wenn man den OB1 Aufruf des FBs einfach entfernt, dann wird dieser im OB35 alle 100MS aufgerufen und dieser hin und her hack wäre weg.

 

[PN/DP]

FB90 aufrufen im OB35 würde ich nicht machen - dafür sind mir viel zu viele Zugriffe auf Globalvariablen drin und es würde "ewig" dauern, alle Zugriffe zu prüfen, ob die Multitaskingtauglich sind. Laß mal besser den FB90 in der selben OB-Task wie das Restprogramm (also alle in der OB1-Task).

Ich kann mir jetzt vorstellen, wie es zu diesem zusätzlichen OB35-Aufruf gekommen sein könnte. Zunächst wird wohl nur so eine saubere Bit-setz-Interprozesskommunikations-Geschichte drin gewesen sein (wie ich in #18 vorgeschlagen habe) - man sieht ja, wie einfach man dahin zurückkommt. Solange der OB1-Zyklus kürzer als die OB35-Aufrufzeit ist, funktioniert die Zählerei so gut. Doch irgendwann wurde vermutlich das Programm so groß, daß die OB1-Zykluszeit manchmal länger als 100ms wurde und OB35-Zählereignisse verloren gingen, weil der OB35 zweimal den selben OB1-Zyklus unterbrach. Da wird ein Programmierer auf die Idee gekommen sein, die Zählereignisse "schnell nebenbei" direkt zu zählen statt nur der OB1-Task mitzuteilen und hat wohl nicht an die Folgen/Komplikationen gedacht, weil er nicht nur die Zählerei aufrief. Auf die Idee, statt dem einen Meldebit zwei Meldebits oder einen Int-Aufrufzähler zu benutzen ist wohl niemand gekommen.

Harald

 

[Crack123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kurzum Finger weg von dem Aufruf

Das mit dem OB35 und der Zykluszeit ist Realistisch weil es ja auch so ist, bei der Zykluszeitanzeige war ja 72-105MS zu sehen Min Max.

Mein Problem ist jetzt was sich nun geändert hat, Grundsätzlich Funktioniert die Anlage einwandfrei (zumindest soweit man es sehen/bemerken kann)
bis auf das Problem das der Dosierofen nach dem Abguß an 2 Verschiedenen Anlagen nicht in seine Grundposition zurückfährt,
bzw. nicht immer,
beim Live beobachten habe ich gesehen das 1 Freigabe nicht gekommen ist die aber auch wieder im Programm über 100 tausend Lokal Variablen irgendwann wieder auf diesem D91.DBX100.2 Bit endet.

Ich gehe davon aus selbst wenn dieses Bit kommt das halt dann dazwischen irgendwo mal der selbe Mist geschieht und 1 Bit mal kommt mal nicht.

Am liebsten würde ich diesen ganzen Mist löschen und Neu machen aber das wird nix.

 

[vollmi]

Ich persönlich würde den OB35 Aufruf löschen. Dort stattdessen einen Boolschen Merker setzen.

im FB90 würde ich #OB35_Aufruf als INOUT deklarieren. Und im OB 1 Aufruf dann den neuen Merker anhängen.

Dann wird zwar der Zähler leicht zykluszeitabhängig aber so wie ich das sehe spielt das hier keine grosse rolle da es sich wieder ausgleicht. OB1 muss allerdings unter 100ms bleiben.

mfG René

 

[JoopB]

Sie konte in FB90 NW 1 ein Ofner einfugen mit #OB35_Aufruf und an ende von NW2 fur die sprung ziel BEA dan wurde in OB35 nur NW 2 bearbeidet.


Gruss Joop

 

[Crack123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo!

Für mich wäre Aktuell wichtig das diese Flanken / Bit *vergesserei* aufhört und die Signal schön bzw. normal kommen.

 

[PN/DP]

Für mich wäre Aktuell wichtig das diese Flanken / Bit *vergesserei* aufhört und die Signal schön bzw. normal kommen.

Das einfachste "Wie" habe ich bereits in Beitrag #18 beschrieben.

Ich persönlich würde den OB35 Aufruf löschen. Dort stattdessen einen Boolschen Merker setzen.

Ich auch. Das ist die einfachste Variante.

im FB90 würde ich #OB35_Aufruf als INOUT deklarieren. Und im OB 1 Aufruf dann den neuen Merker anhängen.

Das ist nicht gut, dann gehen OB35-Ereignisse verloren, wenn der OB35 den FB90 unterbricht:
- beim Aufruf des FB90 ist der "OB35_Merker" = 0 und wird in die INOUT-Variable #OB35_Aufruf kopiert
- FB90 wird aufgerufen mit #OB35_Aufruf = 0
- OB35 unterbricht den FB90 und setzt den "OB35_Merker" auf 1
- FB90 wird fortgesetzt und beendet
- die INOUT-Variable #OB35_Aufruf = 0 wird in den angeschlossenen "OB35_Merker" zurückkopiert!
- der zwischenzeitliche 1-Zustand des "OB35_Merker" wird nicht bemerkt!

Lösung 1: (siehe mein Vorschlag #18) Der OB35 müsste direkt die INOUT-Variable #OB35_Aufruf setzen (DB90.OB35_Aufruf) und der INOUT #OB35_Aufruf darf nicht beschaltet werden. Der FB90 setzt seine INOUT-Variable #OB35_Aufruf zurück.

Lösung 2: #OB35_Aufruf ist ein IN-Parameter (INOUT geht auch). Der FB90 liest den Input nur, rücksetzen ist nicht nötig:

// OB35

SET
S "OB35_Merker"

// OB1

U "OB35_Merker"
R "OB35_Merker"
= #temp_OB35_Merker

CALL FB90, DB90
 OB35_Aufruf:=#temp_OB35_Merker

Dann wird zwar der Zähler leicht zykluszeitabhängig aber so wie ich das sehe spielt das hier keine grosse rolle da es sich wieder ausgleicht. OB1 muss allerdings unter 100ms bleiben.

Auf den Zählerstand wurde schon immer nur im OB1-Rhythmus reagiert. Im schlimmsten Fall schwankte die Reaktionszeit um ~ 100ms
Mit der neuen CPU wird die Reaktionszeit nur noch um ein paar ms schwanken.

Harald

 

[vollmi]

Das ist nicht gut, dann gehen OB35-Ereignisse verloren, wenn der OB35 den FB90 unterbricht:

Ich bin immerwieder erstaunt wie schnell du solche unzulänglichkeiten erkennst. Ich hätt sowas wieder erst beim Programmtest bemerkt.
Ich frage mich allerdings gerade. Ist denn mein Taktgeber (den ich mit den Taktmerkerbyte aus der HW als Flanke generiere) wirklich ungenauer als wenn man einen Takt im Weckalarm Zyklus baut?
Oder anders gefragt macht es Sinn genaue Zähler mit WeckalarmObs zu bauen?

mfG René

 

[Crack123]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo!

Da seitens der Bedienleute keine Beschwerden mehr kommen werde ich es erstmal mit meiner kleinen Timer Verzögerung als Änderung in diesem Programm belassen.

Eventuell kommt es mal dazu das die Anlage eine neue Steuerung sammt Programm bekommt und dieser ganze Mist weg kommt man wird sehen!

Wie schon geschrieben wurde sollte man aufpassen in so *bastelei* Programmen mit Änderungen, somit werde ich mich hüten da noch was anzufassen


Ich denke immer noch das dieser Zustand seid der letzten Änderung im Programm begonnen hat, wobei das nicht nachvollziehbar wäre warum der Fehler erst seid einiger Zeit war und nicht schon immer ?

lg

 

[Onkel Dagobert]

.. Wie schon geschrieben wurde sollte man aufpassen in so *bastelei* Programmen mit Änderungen ..

So war das nun aber auch nicht gemeint. Und vom Schwanzeinziehen war schon gar nicht die Rede !

 

[Crack123]

Naja stimmt ja im Grunde und Schwanzeinziehen neee aber ich hab ehrlich keine Lust das irgendwas schief läuft, das wird teuer und kann sehr gefährlich werden.