OSCAT > Ankündigungen / Announcements

Building 1.10

(1/6) > >>

hugo:
anbei eine erste beta der building 110 beta 1

die neuen module xblind werden nun über ein strukt vom typ blind verbunden und mittels ausführungsreihenfolge wird die priorität der module festgelegt.
wichtig ist dabei das als letztes modul xblind_ctrl2 ausgeführt wird und direkt davor xblind_input shade und night müssen in der reihenfolge von input ausgeführt werden.

neue funktionen in input sind ein beidseitiger langer tastendruck der den manual timeout vorzeitig beendet und ein doppelter druck länger als 5 sekunden springt in den kalibrier modus der es erlaubt mittels tasendrücken die laufzeiten zu ermitteln (manuelle kalibration).

ctrl2 hat nun 2 eingänge force_up und force_dn die eine aufschaltung von winbd und alarm direkt auf den baustein erlauben. werden mehrere force_up oder down benötogt kann dort einfach ein oder gatter vorgeschaltet werden.

ctrl arbeitet nun selbständig bei allen zykluszeiten und muss nicht mehr an die zykluszeit angepasst werden.

blind night hat nun weitere funktionalitäten und kann auch die jalousie morgens selbständig hochfahren.

sorry die dokumentation fehlt leider noch, die bausteine haben auch noch nicht den finalen stand

VorsichT !!!!! die building 1.10 benötigt die 3.31 beta hier aus dem forum !!!!!!

viel spass beim testen

[gelöscht durch Administrator]

pelmic:
Hallo,

wann wird es denn die neuen BLIND_ Funktionen für alle anderen Plattformen geben?
Wenn ich das richtig sehe, dann ist die Bibliothek nur für Codesys geeignet, oder?

Grüße,

pelmic

hugo:
die bibliothek ist für codesys und twincat und pcworx übersetzt.

ansonsten liegt sie auch im source unter *.txt vor und kann für beliebige iec61131 kompatible systeme verwendet werden.

welches system möchtest du benutzen?

pelmic:
Ich nutze PCWorx.
Wann kann man denn mit einer Release rechnen?

Danke,

pelmic

GA_Home:
Hallo Hugo

Ich habe mir den Baustein XBLIND_NIGHT angesehen.


--- Code: ---IF CX.LDATE <> last_set THEN (* event is only generated once per day *)
tmp := DINT_TO_TOD(TOD_TO_DINT(CX.SUN_SET) + SET_OFFSET * 60000);
IF (CX.LTOD > TSB AND cx.LTOD > tmp) OR CX.LTOD > TSE THEN
last_set := CX.LDATE;
timer(IN := TRUE, PT := TIMEOUT);
status := 101;
END_IF;
ELSIF CX.LDATE <> last_rise THEN (* event is only generated once per day *)
tmp := DINT_TO_TOD(TOD_TO_DINT(CX.SUN_RISE) + RISE_OFFSET * 60000);
IF (CX.LTOD > TRB AND CX.LTOD > tmp) OR CX.LTOD > TRE THEN
last_rise := CX.LDATE;
timer(IN := TRUE, PT := TIMEOUT);
STATUS := 102;
END_IF;
ELSE
timer.IN := FALSE;
END_IF;

--- Ende Code ---

Das würde bedeuten, ein neuer Tag beginnt und bei der If schleife würde dann CX.LDATE <> last_set so lange TRUE sein bis die Sonne untergegangen ist. Dann würde der elsif Zweig berücksichtigt dort ist aber die Sonnenaufgangsbedingung.

Fazit ich glaube die if und elsif sollten vertauscht werden.

Was bringt eigentlicht die Zuweisung timer.IN := FALSE; im else Zweig ???
Bei Aufruf des Timerbausteins wird sowieso dann immer IN:= TRUE mitgegeben.

Bin ich mit meiner Behauptung auf den Holzweg und ich habe gerade einen Knopf im Kopf?

ich bin noch immer beim Testen der Bausteine mir fehlt leider etwas Zeit.

Grüße,

GA_Home

Navigation

[0] Themen-Index

[#] Nächste Seite