Bug in OSCAT DIMM_I?

[dast]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann es sein, dass sich im Funktionsblock DIMM_I der OSCAT Lib ein kleiner Fehler eingeschlichen hat.

Wenn ich nach dem Kommentar gehe sollten die folgenden beiden Zeilen

...
(* set direction to up when value < 127 otherwise set dir down dir is reversed because next action will reverse again *)
dir := out > 127;
...
(* set the appropriate direction of dimmer dir is reversed because next action will reverse again *)
dir := out > 127;

wohl so

...
(* set direction to up when value < 127 otherwise set dir down dir is reversed because next action will reverse again *)
dir := out >= 127;
...
(* set the appropriate direction of dimmer dir is reversed because next action will reverse again *)
dir := out >= 127;

oder so lauten

...
(* set direction to up when value < 127 otherwise set dir down dir is reversed because next action will reverse again *)
dir := NOT(out < 127);
...
(* set the appropriate direction of dimmer dir is reversed because next action will reverse again *)
dir := NOT(out < 127);

, oder?

Weil, was wenn out genau 127 ist?!
Dann ist sowohl out > 127 als auch out < 127 FALSE.

Und sollte die Grenze vielleicht nicht sogar bei 128 liegen, damit das ganze schön symmetrisch ist?

 

[PN/DP]

Das ist schon richtig so. Bedenklich ist eher, daß da anscheinend Baustein-Ausgänge geschrieben und danach zurückgelesen werden - das ist ziemlich pfui und außerdem nicht multitasking-safe.


Regeln für NOT bezüglich numerischer Vergleiche:
- NOT(">") <---> "<=" (nicht größer <---> kleiner oder gleich)
- NOT("<") <---> ">=" (nicht kleiner <---> größer oder gleich)
- NOT("=") <---> "<>" (nicht gleich <---> ungleich (kleiner oder größer))

==> NOT("out > 127")" <---> "out <= 127"

Man hätte theoretisch auch das höchstwertige Bit .7 abfragen können, da käme das gleiche 'raus, ein NOT(Bit) wäre aber einfacher zu verstehen, weil es nur 2 Fälle gibt. Beim Vergleich von zwei Zahlen gibt es aber 3 mögliche Ergebnisse: größer, kleiner oder gleich


Die Grenze liegt bei 128, es ist schön symetrisch:
0..127 = up | 128..255 = down

Harald

 

[dast]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sorry, wenn ich nochmal nachfrage ... aber was ist jetzt "... schon richtig so"?

Wenns symmetrisch sein soll, dann wohl:

DIR := NOT (OUT < 128);

oder halt

DIR := OUT >= 128;

Oder?

Das ganze ist aus der OSCAT Lib und das mit dem Zurücklesen der Baustein-Ausgänge auch so ... aber danke für den Hinweis, dass das Pfui ist und nicht Multitasking-Safe.
Das sollte vorerst aber für meine Anwendung kein Problem sein, läuft alles im selben Task.

Weiss nicht mal ob die OSCAT Lib prinzipiell "nicht" Multitasking-Safe ist ...

 

[PN/DP]

Mit "schon richtig so" meinte ich: Das ist kein Bug im DIMM_I, sondern Du verstehst es falsch.

Du hast wohl einen Knoten im Hirn, weil

DIR := NOT (OUT < 128);
ist das gleiche wie
DIR := NOT (OUT <= 127);

bzw.

DIR := OUT >= 128;
ist das gleiche wie
DIR := OUT > 127;

Harald

 

[dast]

Uups, da hatte ich wohl gestern echt nen Knoten im Hirn. Sorry!

Ja ist klar:

 NOT (OUT < 128)   =   OUT >= 128   =  OUT > 127

Ich hatte da auch noch ein andere Stelle im FB DIMM_I im Kopf:

ELSIF decode.TP_LONG THEN
    IF NOT Q THEN
        IF SOFT_DIMM THEN
            OUT := 1;
            dir := TRUE;
        ELSE
            OUT := LIMIT(MAX(MIN_ON,1), out, MAX_ON);
[B]            DIR := out < 127;[/B]
        END_IF;
        Q := TRUE;

Das out < 127 im Pfad für den langen Tastendruck (Dimmen) ist nicht "schön" symmetrisch. Sollte wohl eher out <= 127 lauten ...