Beiträge anzeigen

Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.


Nachrichten - mattsches

Seiten: 1 [2] 3 4 ... 18
16
Der Baustein werkelt im Wetterbaustein für Weatherbit.io. Siehe Link im ersten Post.

17
SPS-Programmierung / Re: BLIND_NIGHT doesn't work
« am: 22. April 2021, 17:33:55 »
Hi dawrut,

I found some issues with BLIND_NIGHT when I started using it and more or less rewrote its code. Don't remember if your issue was among my findings (more than seven years ago), but if you want, you can try if my version fixes your problem.

Declaration:
FUNCTION_BLOCK BLIND_NIGHT
VAR_INPUT
UP, DN : BOOL;
S_IN : BYTE;
PI, AI : BYTE;
E_NIGHT : BOOL := TRUE;
E_DAY : BOOL := TRUE;
END_VAR
VAR_INPUT CONSTANT
SUNRISE_OFFSET : TIME;
SUNSET_OFFSET : TIME;
NIGHT_POSITION : BYTE;
NIGHT_ANGLE : BYTE;
END_VAR
VAR_IN_OUT
CX : CALENDAR;
END_VAR
VAR_OUTPUT
QU, QD : BOOL;
STATUS : BYTE;
PO, AO : BYTE;
END_VAR
VAR
night : BOOL;
last_night, last_day : DATE;
END_VAR

(*
version 1.2 6 oct 2007
programmer hugo
tested by tobias


*)

Code:
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;

(* shade at night only in auto mode and enable = true *)
IF UP AND DN AND night THEN
status := 141;
po := night_position;
ao := night_angle;
ELSE
po := pi;
ao := ai;
status := s_in;
END_IF;

QU := UP;
QD := DN;


(* revision history
hm 29. sep 2007 rev 1.0
original version

hm 5. oct 2007 rev 1.1
added enable input

hm 6. oct 2007 rev 1.2
added pos and angle inputs and outputs
night position and angle can now be configured
any manual operation at night will cancel night operation

md 29 dec 2013 rev 1.3
added CX variable for sunrise, sunset and date and time information;
activated night program only if automatic mode is detected (i.e.
don't skip auto closing when in manual mode);
corrected missing QU/QD assignment when in night mode

md  12 jan 2015 rev 1.4
removed type conversion for TOD and DATE variables by directly
accessing cx.LTOD and cx.LDATE members

*)

Please note that the block now uses one CALENDAR parameter instead of the SUNRISE, SUNSET and DT parameters. The calendar variable is fed by a CALENDAR_CALC FB instance which does some additional calculations I found useful. If you prefer the original style of dedicated parameters, you can easily change my code back to that approach.

Have you checked the times for sunrise and sunset calculated by SUN_TIME?

Cheers,
mattsches

18
Hallo,

ich komme gerade nicht dazu, den Baustein auf 3.5 zu portieren. Aber du müsstest die Exportdatei eigentlich ganz gut importieren können. In der Regel passen dann die Referenzen auf die aufgerufenen Bausteine nicht, weil in 3.5 mit Namensraum gearbeitet wird (<Namensraum>.<FB_Name>), was in 2.3 nicht der Fall war.

Gruß,
mattsches

19
Änderungsvorschlag:

SUN_TIME, Zeile 5 der Klarheit halber ändern von
UTC : DATE; (* world time *)in
DAY : DATE; (* date of day to calculate times for *)
und Zeile 32 in CALENDAR_CALC von
sun(latitude := XCAL.LATITUDE, longitude := xcal.LONGITUDE, utc := DT_TO_DATE(xcal.UTC), H := H);in
sun(latitude := XCAL.LATITUDE, longitude := xcal.LONGITUDE, day := xcal.LDATE, H := H);
Dann wird der Baustein weiterhin um Mitternacht Lokalzeit getriggert, rechnet aber die Sonnenstandszeiten für den aktuellen Tag und nicht für den Vortag.

20
Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION
« am: 28. April 2020, 16:49:49 »
Exakt so ist es. Der Baustein verhält sich wie die anderen Wetterbausteine, die Fehlermeldung kommt vom IP_CONTROL, Puffer ist zu klein. Obwohl mich das überrascht (die JSON-Antwort der API sollte nicht besonders in der Länge variieren, lediglich die Vorhersagetexte ändern sich ja), könntest du die Abfrage und die Verarbeitung im Baustein weiter einschränken, so dass z. B. nur vier Tage abgerufen werden. Im Code sind die beiden Stellen recht leicht zu erkennen. Zum einen ist das der Initialwert für die Abfrage-URL. Zum anderen die Schleife über die JSON-Objekte für die einzelnen Tage.

21
BECKHOFF / Re: DLOG_STORE_FILE_CSV für Hochfrequente Daten
« am: 28. April 2020, 16:46:51 »
Hallo Richard,

das Problem ist - wie von peewit schon erwähnt - dass das Schreiben ins Dateisystem zu langsam ist. Selbst wenn du den Baustein ausbremsen könntest, bis der Schreibvorgang abgeschlossen wurde (was ich gerade nicht weiß), dann hilft dir das nichts. Denn dann erreichst du die erforderliche Zykluszeit erst recht nicht.

Spontan sehe ich nur die Möglichkeit, für die wie du ja sagst begrenzte Zeit die Daten in Variablen, also den RAM zu schreiben. Das ist synchron möglich, setzt aber natürlich entsprechend Arbeitsspeicher voraus. Diese Puffervariablen könntest du dann im Anschluss ins Dateisystem schreiben.

Gruß,
mattsches

22
Modulentwicklung / Re: Philips Hue
« am: 10. Januar 2020, 12:39:35 »
Nein. Die unterlagerten Systembibliotheken z. B. für den Zugriff auf die Ethernet-Schnittstelle unterscheiden sich.

Die OSCAT_NETWORK für CODESYS und Beckhoff TwinCAT stellt nach oben hin jedoch identische Schnittstellen zur Verfügung. Wenn du also nicht direkt auf die CODESYS-Systembibliotheken zugreifst, sondern über Bausteine aus der OSCAT_NETWORK.lib gehst, dann kann ein Beckhoff-Anwender deine Lib statt mit der OSCAT_NETWORK.lib für CODESYS mit der für TwinCAT betreiben, ohne deine Bibliothek ändern zu müssen.

23
Modulentwicklung / Re: Neuer Baustein zum Parsen von JSON-Streams
« am: 10. Januar 2020, 12:35:09 »
  • Am HMI anzeigen (ok, das ist profan).
  • Die Jalousien früher zum Verschatten schließen, wenn höhere Temperaturen angekündigt sind.
  • Die Vorlauftemperatur der Heizung drosseln bei angekündigtem Sonnenschein (mache ich nicht, macht meine Heizung schon von selbst).

24
Modulentwicklung / Re: Philips Hue
« am: 07. Januar 2020, 12:59:43 »
This will not work. You cannot use a standard CODESYS Ethernet.lib on a Beckhoff PLC since Beckhoff implemented own mechanisms for hardware and communication. That's why there is a special version of the OSCAT network library.

25
BECKHOFF / Re: TC3 Lib umgesetzt
« am: 15. Oktober 2019, 19:44:32 »
Hi,

für TwinCAT 2 kannst du die normalen OSCAT_BASIC und _BUILDING verwenden, und von der _NETWORK gibt es eine spezielle Beckhoff-Version. Habe ich ohne Probleme so im Einsatz. Für TwinCAT 3 sieht es meines Wissens eher mau aus.

Gruß,
mattsches

26
Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION
« am: 15. Oktober 2019, 19:41:41 »
Hallo Eric,

wenn du nicht gezielt Features der 1.35 benötigst sondern allgemein die OSCAT_NETWORK, dann ist für CODESYS V3.5 der Weg über den CODESYS Store der einfachste. Falls du unbedingt die 1.35 brauchst, wirst du nicht umhin kommen, sie selbst auf CODESYS V3.5 zu portieren. Oder du kontaktierst annD, der das schonmal gemacht hat. Leider ist in seinem Post vom 30.01.2018 der Anhang gelöscht worden (warum auch immer).

Eine 2.3er LIB kannst du in 3.5 durch einfaches Öffnen portieren. Du wirst aber einige Fehler erhalten, weil unter 3.5 z. B. Namensräume zwingend angewendet werden müssen und die Deklaration von Arrays sich geringfügig geändert hat. Kann sein, dass es noch weitere Punkte gibt. Das müsstest du halt beim Übersetzen Stück für Stück ausräumen.

Aber wie gesagt, CODESYS Store für die 1.21 oder annD für die 1.35 kontaktieren.

Gruß,
mattsches

27
Modulentwicklung / Re: Neuer Wetter-Baustein für Weatherbit.io
« am: 29. September 2019, 19:41:18 »
The YAHOO_WEATHER block is part of the OSCAT_NETWORK lib and is well documented the respective PDF.

There are different versions of the OSCAT_NETWORK lib, one for standard CODESYS and one Beckhoff. I assume that you either included the wrong OSCAT_NETWORK variant in library manager or that the namespace is set to something else than in my example. Both can be fixed in library manager.

28
Modulentwicklung / Re: Neuer Wetter-Baustein für Weatherbit.io
« am: 23. September 2019, 20:00:12 »
Hallo vicky,

schön, dass es funktioniert! Das mit der Sprache ist eine gute Idee. Bei mir war es nicht relevant, da ich mir nur die eigentlichen Wetterdaten aus der Vorhersage ziehe und rein symbolisch anzeige.

Vielleicht noch ein Hinweis an alle (es scheint ja noch nicht allzu viele Nutzer zu geben): Bei mir kommt es sporadisch zu dem Effekt, dass die Vorhersage "um zwei Tage verschoben" erscheint. Dass also im ersten Arrayelement die Daten für übermorgen hängen. Ich konnte den Fehler noch nicht forcieren, habe mir in letzter Zeit allerdings auch keine Zeit für eine genauere Analyse genommen. Kan auch sein, dass das ein Problem in meiner Applikation ist und nicht im Baustein. Aber es wäre schön, wenn hier jemand kurz Rückmeldung geben könnte, ob der Fehler auch anderswo auftritt.

Grüße,
mattsches

29
Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION
« am: 23. September 2019, 19:46:43 »
Peewit, an dem Eintrag hängt aber kein Anhang mehr dran. Stattdessen ein Vermerk

"[gelöscht durch Administrator]"

Gruß,
mattsches

30
Modulentwicklung / Re: Neuer Wetter-Baustein für Weatherbit.io
« am: 20. September 2019, 12:49:18 »
Hier eine Portierung für CODESYS V3.5. Namensräume sind OSCAT_BASIC für die Basic.lib und OSCAT_NETWORK für die Network.lib. Bitte entsprechend einstellen oder halt meine Bausteine anpassen.

Getestet habe ich nicht wirklich (=auf einer Steuerung). Das Programm lässt sich aber fehlerfrei übersetzen, die Bausteine (JSON_READER und WEATHERBIT) sollten so funktionieren.

Seiten: 1 [2] 3 4 ... 18