HS-Logik-Problem

[Norbe]

Hallo Kollegen

ich habe folgendes Problem :
In einem Projekt habe ich Dachfenster mit aufliegenden elektr. Rolläden . Jetzt sind nachträglich Antriebe für die Dachfenster gekommen .
Nun muss ich per Logik die Rollos und die Dachfensterabtriebe gegeneinander verriegeln , weil sonst die Rollos flöten gehen ...
Logik habe ich wie in der Grafik realisiert . Im Eingang jeweils die Move-Objekte der Antriebe vom Taster und im Ausgang die move Objekte am Aktor , die durch eine Sperre verriegelt werden .
Angefahren werden beide ausschliesslich durch 1bit Objekte , also würde das sperren der move-Objekte ja reichen .
Und so wie ich es gemacht habe , sollten eigentlich beim fahren (move-Objekt = 1) der Rollos , die move - Objekte der Fenster sofort gesperrt werden - funzt aber nicht . 6 Sekunden nach dem fahren der Rollos liess der HS die move-Objekte der Fensterabtriebe noch durch .
Ich hab mir die Logik ein paarmal angeschaut , komm aber nicht drauf warum ...
Hat einer eine Idee ?????


P.S.: die move - Objekte nehm ich zum verriegeln nur deshalb , weil der Aktor die Position erst beim anhalten ausgibt , d.h. wenn beide in Pos.=0 sind , könnten sonst beide move-Objekte gesetzt werden ...

[Michel]

So auf die Schnelle (kann sein, daß ich was übersehen habe):

die Sperrgatter hast du standardmäßig offen.

Probier mal: erst Move-Objekt fahren, dann die Rollos. Ich tippe mal auf die fehlenden Telegramme der Move-Objekte.

Aber wie gesagt: habe mich nur 2 Minuten damit beschäftigt.
Schau dir mal die Doku zum Startverhalten der Logik an!

[viceversa]

Habe es auch nur überflogen. In diesem Zusammenhang beachte jedoch bitte:

Manche Aktoren senden die aktuelle Position erst 5s nach der letzten Fahrt. Vielleicht hängt es damit zusammen.

[Norbe]

eben weil die Aktoren die Position so spät senden , habe ich mit dem Move-Objekt des jeweils anderen Antriebs die Sperre schon zugemacht.
Meiner Ansicht nach müsste z.B. bei Move-Objekt Jal. DF = 1 sofort die Sperre für die Move-Objekte Dachfensterantriebe zugehen.
Tut sie aber nicht , und genau da liegt der Haken ...

[Gaston]

Das Problem rührt, denke ich, von einem Bug mit dem RS-Flip-Flop das ich vor zwei Wochen bei Dacom gemeldet habe. Durch diesen ist das Flip-Flop nicht Flanken sondern Wert gesteuert.

Die Behebung des Poblems hab ich auch gleich mitgeliefert, ist allerdings auf eingene Gefahr:

Im Verzeichnis des Experten die Datei dat\logik.dat editieren.

Das RS-Flip-Flop befindet sich ganz am Ende der Datei:

Hier müssen in den beiden folgenden Zeilen:

5012|9089|0|"((EI==0) or EC[1]) and (EN[1]<>0)"|"1"|""|1|0|0|2
5012|9089|0|"((EI==0) or EC[2]) and (EN[2]<>0)"|"0"|""|1|0|0|2

das (EI==0) durch (EI==1) ersetzt werden.

Eine Kopie der originaldatei sollte man sich vorher anlegen ;)

[Matthias Schmidt]

@Gaston

Ich dachte, die logik.dat wäre durch Checksumme geschützt?

[Norbe]

Das Problem rührt, denke ich, von einem Bug mit dem RS-Flip-Flop das ich vor zwei Wochen bei Dacom gemeldet habe. Durch diesen ist das Flip-Flop nicht Flanken sondern Wert gesteuert.


müsste es nicht trotzdem funktionieren , da ich ja beim ersten move=1 einen Wert in das RS-Flip-Flop schreibe ?

[Gaston]

@Gaston

Ich dachte, die logik.dat wäre durch Checksumme geschützt?

Sieht gottseidank niocht danack aus. Hatte zuerst auch die Befürchtung.

[Gaston]

müsste es nicht trotzdem funktionieren , da ich ja beim ersten move=1 einen Wert in das RS-Flip-Flop schreibe ?

Nein, DUrch den Bug ist die Reihenfolge der Abarbeitung in der Logik wichtig. Hierbei wird der Reset nach dem Signal ausgeführt und ist hat deshalb eine ungewollte Priorität gegenüber dem Signal.

Gehen wir mal davon aus deine Bedingung "%höhe..." < 2 ist wahr, damit wird eine "1" an den Reset geschick und auch ein Reset im RS-FlipFLop ausgeführt.

Wenn Du nun einen "Move" Befehl sendest wird zwar der Signaleingang "1" aber am Reset liegt auch noch die "1" sollange an bis dass der Positionwert vom Aktor eintrifft. Die verhindert dass das RS-FlipFlop in den "Set" Status gelangt.

Das Problem ist dass die EI==0 Bedingung immer Wahr ist (ausser bei der Initialisierung) und deshalb die EC[x] Bedingung (die eine Flanke erkennt) unwirksam macht.

Gruss,
Gaston

[Norbe]

also wenn ich das richtig verstanden habe , müsste ich am RS-Flip-Flop immer mit einem Signal an SET oder RESET , jeweils den andern negieren ???

[Matthias Schmidt]

Mal eine Frage:

Für was brauchst du das RS-Teil überhaupt?

Warum gibst Du das ODER und das KLEINER nicht direkt auf die SPERRE?

[Gaston]

also wenn ich das richtig verstanden habe , müsste ich am RS-Flip-Flop immer mit einem Signal an SET oder RESET , jeweils den andern negieren ???

Nein, weil dann könntest Du wie Matthias gefragt hat das RS-FlipFlop weglassen. Das wäre aber nicht richtig. In beiden fällen würde z.B. eine "0" auf das Move Objekt die Sperre sofort lösen anstatt zu Warten bis die Position<2 ist.

In der Logik gibt es einen anderen kleinen Logikfehler der aber Funktional wegen der kleinen Position (<2) nichts bewirkt. Und zwar ist das der Einsatzt des Oder-Gatters.

Wenn dort an einem der Eingänge eine "0" ankommt hängt das Resultat davon ab welcher Wert als letztes am anderen Eingeng gesendet wurde.

Eigentlich könntets Du beide Signale gleich mit dem "Signal" des RS-FLipFlops verbinden, ohne Oder-Gatter.

Gruss,
Gaston

[viceversa]

Danke Gaston für den Fehlerreport.

Ich hatte heute auch ein unerklärbares Problem mit dem RS Flip-Flop. Glücklicherweise habe ich mich an dieses Topic erinnert und die Änderungen eingearbeitet.

Nun funktioniert es. Danke!