Nachrichten

76

SPS-Programmierung / Re: BLIND_CONTROL

« am: 25. Mai 2018, 22:56:05 »

Das würde ich so fixen:

Code: [Auswählen]


(* check inputs and start state machine *)
IF UP  AND NOT DN THEN
(*  manual UP *)
rmp.IN := 255;
STATUS := 121;
ELSIF DN AND NOT UP THEN
(* manual DN *)
rmp.IN := 0;
STATUS := 122;
ELSIF NOT (UP OR DN) THEN
(* manual standby mode *)
rmp.IN := PI;
STATUS := S_IN;
ELSE
STATUS := S_IN;
END_IF;

Neu ist der letzte ELSE-Zweig (kann ich innerhalb des Code-Tags leider nicht farblich hervorheben.

77

oscat.lib fuer CoDeSys 3 / Re: ONTIME Fehler im Quellcode

« am: 22. Mai 2018, 12:30:46 »

Hallo ekki,

da möchte ich spontan widersprechen. Die von dir vorgeschlagene Änderung bewirkt, dass nach Setzen von init überhaupt kein Reset mehr durchgeführt werden kann. Denn init wird auf TRUE gesetzt und somit ist der Ausdruck innerhalb der Klammer fortan immer wahr.

Im ursprünglichen Zustand wird bei positivem RST-Eingang auch bei init=TRUE last auf tx gesetzt und ms zurückgesetzt.

Störend ist dagegen diese Zeile:

Code: [Auswählen]

ELSIF RST THEN
Dieser Zweig wird nie abgearbeitet, da bei RST=TRUE bereits der erste Zweig zuschlägt. Daher gehört nach meinem Dafürhalten diese Zeile ersatzlos gestrichen, wodurch die Variablen seconds und cycles ebenfalls bei init=FALSE und RST=TRUE zurückgesetzt würden.

Gruß,
mattsches

78

SPS-Programmierung / Re: BLIND_CONTROL

« am: 16. Mai 2018, 12:52:07 »

Hallo ihr beiden,

das ist ein Fehler im BLIND_CONTROL. Ursache ist die letzte Zeile:

Code: [Auswählen]

status := act.status;

Zeile löschen, dann geht es.

79

oscat.lib fuer TwinCAT/CoDeSys / Re: AIN-Baustein und Probleme bei der Benutzung

« am: 03. Mai 2018, 16:42:05 »

Hallo,

Dein Fehler ist die Division durch 1000.0 (einer Gleitkommakonstante) und dass die Division außerhalb der Klammer für die Typkonvertierung stattfindet. Das macht aus dem zuvor erzeugten WORD wieder einen LREAL.

Ändere die Zeile mal auf

Code: [Auswählen]

Analogwert := INT_TO_WORD(OSCAT_BASIC.RDM2(...) / 1000);

Dann wird durch einen Integer geteilt und erst anschließend in WORD konvertiert.

80

Modulentwicklung / Module Development / Re: new module for "moving average"

« am: 13. April 2018, 12:35:40 »

Provided that you need to change N during runtime, yes, the buffer initialization makes sense. I'd prefer a leaner approach for detecting changes on N, without the A_TRIG_N instance call. But that's just my personal taste.

Code: [Auswählen]

(* limit N to size of buffer *)
N := MIN(N, SIZEOF(buffer)/4);

(* startup initialisation *)
IF NOT init OR rst OR N = 0 OR N <> N_old  THEN
   init := TRUE;
   FOR i := 0 TO UINT_TO_INT(N)-1 DO
      buffer := X;
   END_FOR;
   sum := X * N;
   Y := X;
ELSE
   i := INC1(i, UINT_TO_INT(N));
   sum := sum + X - buffer;
   Y := sum / N;
   buffer := X;
END_IF;

N_old := N;


With N_old being an FB internal variable, of course.

81

Modulentwicklung / Module Development / Re: new module for "moving average"

« am: 12. April 2018, 15:01:28 »

I don't know if you are aware of the FILTER_MAV_W function block in OSCAT_Basic which does a moving average, although for WORD variables. I needed that for REALs, too, so I modified it and fixed the buffer initialization at the same time. Might be interesting for you, since it seems considerably more compact than your code. If you really need a calculation with 1000 values (which seems a lot to me), you can easily change the size of the "buffer" array.

Code: [Auswählen]

FUNCTION_BLOCK FILTER_MAV_R
VAR_INPUT
X : REAL;
N : UINT;
RST : BOOL := FALSE;
END_VAR
VAR_OUTPUT
Y : REAL;
END_VAR
VAR
init: BOOL := FALSE;
buffer : ARRAY[0..31] OF REAL;
i: INT;
sum : REAL;
END_VAR
VAR_TEMP
tmp : INT;
END_VAR

(* limit N to size of buffer *)
N := MIN(N, SIZEOF(buffer)/4);

(* startup initialisation *)
IF NOT init OR rst OR N = 0 THEN
init := TRUE;
FOR i := 0 TO UINT_TO_INT(N)-1 DO
buffer[i] := X;
END_FOR;
sum := X * N;
Y := X;
ELSE
i := INC1(i, UINT_TO_INT(N));
sum := sum + X - buffer[i];
Y := sum / N;
buffer[i] := X;
END_IF;


82

Modulentwicklung / Re: Neuer Wetter-Baustein für openweathermap.org

« am: 28. Februar 2018, 19:53:40 »

Hallo,

grundsätzlich kannst du schon einen Baustein für die 15 Tage/3 Stunden-Vorhersage bauen oder meinen modifzieren. Du wirst halt die globale Variable NETWORK_BUFFER_LONG_SIZE aus der OSCAT Network Lib vergrößern müssen, da der zurückgelieferte XML-String länger als 4095 Zeichen ist und somit standardmäßig nicht in den Empfangspuffer passt. Das ist mit einer einfachen Anpassung in der Network.lib erledigt; allerdings kann der Baustein nicht einfach ohne diese Anpassung von jemand anders genutzt werden.

Gruß,
mattsches

83

Bestehende Module / Existing Modules / Re: CLICK und "summende Relais"

« am: 31. Januar 2018, 12:51:04 »

@ADS_0x1: Dass die Ausgänge SINGLE, DOUBLE und TRIPLE vom CLICK nur als Impulse ausgegeben werden, also nur für einen Zyklus anstehen, stimmt nicht:

Der entsprechende Ausgang bleibt mindestens einen Zyklus aktiv und maximal solange wie der Eingang IN aktiv bleibt.

Der Code bestätigt das für mich auch, ohne es jedoch noch einmal ausprobiert zu haben.

@charlie85:

Für das Umschalten deines Relais solltest du daher nicht direkt den Bausteinausgang nehmen, sondern ihn vorher über eine Flankenerkennung ziehen. R_TRIG heißt der entsprechende Baustein, ist in der Standard.lib enthalten. Die R_TRIG-Instanz rufst du im Code nach dem betreffenden CLICK auf, übergibst ihr als CLK InButton_10_03.SINGLE und baust deinen Dreizeiler so um:

Code: [Auswählen]

IF <Name der R_TRIG-Instanz>.Q THEN
OutLight_10_07 := NOT OutLight_10_07;
END_IF

Dann schaltet dein Relais bei jedem Drücken um (toggeln), ohne zu summen.

Wenn du auch mit DOUBLE und TRIPLE etwas toggeln willst, brauchst du dafür je eine weitere R_TRIG-Instanz.

84

Bestehende Module / Existing Modules / Re: Vorschläge für BLIND_SHADE, BLIND_CONTROL und BLIND_ACTUATOR

« am: 22. Januar 2018, 16:34:43 »

Wenn ich das über VPN und einen Button in der Visu teste, dann geht das Rollo runter, aber anschließend steht der Status erst auf 131, dann auf 130. Das verstehe ich nicht, ich würde 141 (Nachtbetrieb) erwarten.

Das liegt daran, dass der Automatikbetrieb nicht aktiv war, sondern Handbetrieb. Verantwortlich dafür sind die folgenden Codezeilen im BLIND_NIGHT:

Code: [Auswählen]

IF UP AND DN AND night THEN
status := 141;
po := night_position;
ao := night_angle;

"UP AND DN" steht für "Automatikbetrieb aktiv" (eine Konvention der BLIND-Bausteine).

Weiterhin befürchte ich, dieser Teil

Code: [Auswählen]

AND (last_day < DT_TO_DATE(dtin)) erzwingt, daß das Rollo vor Mitternacht runter muß, damit es morgens automatisch auf geht?

Nein, das trifft nicht zu. In der Booleschen Algebra hat UND Vorrang vor ODER (ähnlich wie "Punkt vor Strich"). Das Ergebnis der betreffenden Zeile ist also dann TRUE, wenn entweder die ganzen mit "AND" verknüpften Bedingungen vor dem eingefügten "OR ACTIVATE_NIGHT" bzw. "OR DEACTIVATE NIGHT" wahr sind oder die Bedinung dahinter. Also das neu eingefügte ACTIVATE bzw. DEACTIVATE.

Die von dir zitierte Bedingung bewirkt lediglich, dass die Jalousie nur dann vom BLIND_NIGHT hochgezogen wird, wenn das heute nicht schon einmal geschehen ist.

85

Bestehende Module / Existing Modules / Re: Vorschläge für BLIND_SHADE, BLIND_CONTROL und BLIND_ACTUATOR

« am: 19. Januar 2018, 00:47:09 »

Hallo Jens,
dazu würde ich den BLIND_NIGHT abändern. Baustein aus der Bibliothek in dein Projekt kopieren, umbenennen und dann z. B. mit zwei Eingängen ACTIVATE_NIGHT und DEACTIVATE_NIGHT ergänzen. Den Code

Code: [Auswählen]

IF NOT (up AND dn) AND night THEN
(* manual operation at night will cancel operation for one night *)
night := FALSE;
ELSIF (cx.LTOD > cx.SUN_SET + sunset_offset) AND (last_night < cx.LDATE) AND NOT night AND e_night AND UP AND DN THEN
(* enable night *)
night := TRUE;
last_night := DT_TO_DATE(cx.LDT);
ELSIF (cx.LTOD > cx.SUN_RISE + sunrise_offset) AND (last_day < cx.LDATE) AND night AND e_day AND (last_night < cx.LDATE) AND UP AND DN THEN
(* disable night *)
night := FALSE;
last_day := DT_TO_DATE(cx.LDT);
END_IF;

würde ich dann so umschreiben:

Code: [Auswählen]

IF NOT (up AND dn) AND night THEN
(* manual operation at night will cancel operation for one night *)
night := FALSE;
ELSIF (cx.LTOD > cx.SUN_SET + sunset_offset) AND (last_night < cx.LDATE) AND NOT night AND e_night AND UP AND DN [color=red]OR ACTIVATE_NIGHT[/color]THEN
(* enable night *)
night := TRUE;
last_night := DT_TO_DATE(cx.LDT);
ELSIF (cx.LTOD > cx.SUN_RISE + sunrise_offset) AND (last_day < cx.LDATE) AND night AND e_day AND (last_night < cx.LDATE) AND UP AND DN [color=red]OR DEACTIVATE_NIGHT[/color]THEN
(* disable night *)
night := FALSE;
last_day := DT_TO_DATE(cx.LDT);
END_IF;


ACTIVATE_NIGHT und DEACTIVATE_NIGHT könntest Du dann auf die entsprechenden Signale verschalten, wobei das Impulse sein müssen. D. h. sie müssten für mind. einen Zyklus TRUE sein und dann außerhalb des BLIND_NIGHT wieder zurück auf FALSE gesetzt werden. Also so, wie das z. B. bei Tastern der Fall ist.

Gruß,
mattsches

86

oscat.lib fuer CoDeSys 3 / Re: Holiday Array

« am: 12. Dezember 2017, 08:29:13 »

Da scheint was mit deiner Bibliothek nicht zu stimmen. Wo hast du die denn her? Ich habe die 3.3.1 von der OSCAT-Webseite installiert, damit kann ich deinen ursprünglichen Code (fast) ohne Fehler bauen. Denn der Namespace ist standardmäßig "BASIC", bei dir aber "OSCAT_BASIC" (hast du das bewusst geändert?). Ändere ich ihn im Bibliotheksverwalter, habe ich keine Fehler beim Übersetzen. Auch ohne Namensräume funktioniert alles ohne Probleme.

Vorschlag: Wirf die Bibliothek aus dem Repo, lade sie nochmal von der Webseite herunter und installiere sie bei dir. Die ganzen Deklarationen können dann auch ohne Namensraum erfolgen, solange dein Projekt nicht so groß ist, dass dadurch Konflikte entstehen (zweite Bibliothek im Projekt, die z. B. ebenfalls einen Datentyp "HOLIDAY_DATA" enthält).

87

oscat.lib fuer CoDeSys 3 / Re: Holiday Array

« am: 11. Dezember 2017, 23:00:14 »

Sorry, war ein Versehen meinerseits. Ich hatte gedacht, annD hätte den Baustein in der Bibliothek modifiziert. Nach allem, was ich lese, müsste es aber auch so gehen.

Ich habe hier gerade keine V3-Installation greifbar. Mal sehen, vielleicht schaffe ich es morgen tagsüber, das Ganze mal nachzustellen.

88

oscat.lib fuer CoDeSys 3 / Re: Holiday Array

« am: 11. Dezember 2017, 12:44:26 »

Hast Du es schonmal ohne Namensraum probiert? Also

Code: [Auswählen]

Feiertage: ARRAY [0..29] OF HOLIDAY_DATA (...)
?

Falls das auch nicht geht, wirst Du die Deklaration von XCAL im CALENDAR_CALC ändern müssen auf

Code: [Auswählen]

XCAL: OSCAT_BASIC.CALENDAR:=(OFFSET:=60,DST_EN:=TRUE,LANGUAGE:=2,LONGITUDE:=xxx,LATITUDE:=xxx);
Siehe Post von annD oben.

89

Modulentwicklung / Re: Neuer Wetter-Baustein für openweathermap.org

« am: 03. November 2017, 12:35:19 »

Achtung,

openweathermap.org hat die Lizenzpolitik dahingehend geändert, dass die vom Baustein genutzte 16 Tage-Vorhersage nun nicht mehr mit dem kostenfreien API-Key nutzbar ist. Leider kann auch nicht einfach auf die weiterhin kostenfreie 5 Tage/3 Stunden-Vorhersage umgebaut werden, da dort keine zusammenfassenden Werte pro Tag verfügbar sind, sondern ausschließlich die 3 Stunden-Abschnitte. Zudem sind bei der daraus resultierenden Größe der XML-Antwort Probleme mit der NETWORK_BUFFER-Variable zu erwarten, deren Standardlänge dann nicht ausreichen wird.

Ich habe derzeit keine schlüssige Idee, wie hier weiter verfahren werden könnte. Möglicherweise landet der Baustein nach dann recht kurzer Lebenszeit doch wieder in der Tonne.

90

Modulentwicklung / Re: Neuer Wetter-Baustein für openweathermap.org

« am: 03. November 2017, 11:36:09 »

Das ist interessant. Laut http://openweathermap.org/price gibt es bei der freien API keinen Zugriff mehr auf die 16 Tage-Vorhersage. Früher war das noch so.

Testweise habe ich gerade einen neuen API Key generiert, mit dem scheitert die Abfrage bei mir auch. Mit meinem alten API Key dagegen funktioniert sie.

Ich werde den Baustein also wohl auf die 5 Tage/3 Stunden-Vorhersage umbauen müssen. Kann dir aber leider nicht sagen, wann ich dazu kommen werde.