Beiträge

Der Fehler bedeutet Buffer-Überlauf im Baustein IP_CONTROL - siehe in der oscat_netlib121_de.pdf bei 9.8 IP_CONTROL, Abschnitt ERROR, S.114.
Im Programm YAHOO_WEATHER_DEMO sind zwei Constanten höher gesetzt, probier das mal:

Code Auswählen Erweitern


VAR_GLOBAL_CONSTANT
    NETWORK_BUFFER_LONG_SIZE : UINT := 4095;
    NETWORK_BUFFER_SHORT_SIZE : UINT := 1407;
END_VAR

Die Zugriffe mit dem key aus der world-weather-demo scheinen ebenfalls begrenzt zu sein.
Wer damit jetzt testet, sollte sich nicht wundern, wenn der Baustein nicht funktioniert.
Mittlerweile wird die Abfrage bereits ab Mittag blockiert.

Die Zugriffe mit dem key aus der world-weather-demo scheinen ebenfalls begrenzt zu sein.
Wer damit jetzt testet, sollte sich nicht wundern, wenn der Baustein nicht funktioniert.
Mittlerweile wird die Abfrage bereits ab Mittag blockiert.

Das kann ich bestätigen - siehe erster Beitrag.
Ausserdem geht nur XML und JSON - CSV ist nicht mehr vorgesehen.

Hallo,
ich bin dabei, meine Wetteranzeige von den YAHOO_WEATHER-FBs auf die WORLD_WEATHER-FBs umzustellen.
Ich verwende die codesys_network_130.lib.

Wer sich jetzt bei WorldWeather anmeldet und einen Key erzeugt, wird feststellen, dass die WORLDWEATHER-FBs leider auch nicht mehr funktionieren.
Bei WorldWeather bekommt man nur noch einen Key für einen 60Tage-Premium-API-Zugang, auch wenn man den "Sign up for Free"-Button drückt.
Was nach den 60Tagen passiert, weiß ich noch nicht.
Weiß jemand, wie man die WorldWeather-Accounts wieder löscht?

Der erzeugte Key funktioniert jetzt aber nur mit den Link  http://api.worldweatheronline.com/premium/v1/weather.ashx?..... und liefert keine csv-Daten mehr, sondern JSON oder XML.
Der Oscat-WorldWeather-FB verwendet aber den Link http://api.worldweatheronline.com/free/v1/weather.ashx?..&format=csv... und liefert csv-Daten.
Somit funktioniert der jetzt erzeugte Key nicht mehr mit dem Oscat-WorldWeather-FB.

Es hilft nur einen alten Key zu verwenden, der für den Link mit "../free/v1/.." und "&format=csv" erstellt wurde.
Ich habe einen solchen Key aus einem der API Code Examples von der WorldWeather-Homepage genommen: xkq544hkar4m69qujdgujn7w.
Mit diesem Key funktioniert bei mir der WORLD_WEATHER-FB.

Der komplette Link für Berlin lautet dann:
http://api.worldweatheronline.com/free/v1/weather.ashx?key=xkq544hkar4m69qujdgujn7w&q=Berlin&format=csv&num_of_days=5

Hallo peewit,
Deine letzte Anpassung funktioniert bei mir seit Mittwoch oder Donnerstag nicht mehr.
Yahoo hat Dein "Baby" wieder ins Koma geschickt.
Schade.

V3.5 kenne ich nicht aber im PRG sollte es heißen

Code Auswählen Erweitern


VAR
xx : STRING[10];
...


Für die STC-RS485-EVC gibt es bei Thermokon die notwendigen Anleitungen. Die Standardeinstellungen reichen normalerweise.
Bei Wago gibt es einen eigenen Anwendungshinweis für die Enocean/RS485-Kommunikation, damit sollte man das hinbekommen.
Zuerst alles nicht ganz einfach, aber da muss man sich ein-und durcharbeiten.
Beim Micropelt wird nur der %-Wert , nicht der Temperatur-Wert als Ansteuerung verwendet. Der Micropelt unterstützt nicht alle Eigenschaften des EEP, steht aber auch in der Micropelt-Dokumentation.

kiar

Hallo,
wenn die Enocean-Klemme nur empfangen kann, lässt sich keine Ventilansteuerung realisieren.
Mit dem Sender/Empfänger Thermokon STC65-xx und der entsprechenden Rs485- oder Modbus-Schnittstellenkarte an der Wago funktioniert der Micropelt-Antrieb.

Gruß kiar

Bei mir passen die Werte jetzt wieder.
Dann war scheinbar doch was mit den Yahoo-Servern.

Bei mir werden z.Zt. Wetterdaten vom 11.11. oder 17.11. dargestellt.
Die Browser-Anzeige http://weather.yahooapis.com/forecastrss?w=... liefert das selbe Ergebnis.
Kann das mit dem beschädigten Rechenzentrum
http://www.heise.de/newsticker/meldung/Stromausfall-in-Rechenzentrum-legt-etliche-populaere-Websites-lahm-3010320.html
zu tun haben?

@NigthWatcher
Ich glaube noch nicht, dass Du das Problem sauber gelöst hast. Ich vermute, dass Du im Herbst wieder ein Problem hast.
Wie peewit schrieb, sollte die SPS mit UTC arbeiten. Der Baustein calendar_calc funktioniert nur sauber, wenn Du die UTC anlegst und auch die Zeitzone XCAL.XOFFSET auf Deutschland einstellst.
Die Local-Zeit wird im Baustein mit

Code Auswählen Erweitern

XCAL.LDT := UTC_TO_LTIME(XCAL.UTC, XCAL.DST_EN, XCAL.OFFSET);
berechnet. XCAL.OFFSET ist die Zeitzonenverschiebung. XCAL.DST_EN muß TRUE sein, damit der Baustein eine Sommer-/Winterzeitumschaltung berücksichtigt.

Die lokalen Aufgangs-/Untergangszeiten und die Zeit des höchsten Sonnenstandes werden ebenfalls mit XCAL.OFFSET in die gewünschte Zeitzone verschoben.

Code Auswählen Erweitern

XCAL.SUN_RISE := DINT_TO_TOD(TOD_TO_DINT(sun.sun_rise) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_SET := DINT_TO_TOD(TOD_TO_DINT(sun.sun_set) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_MIDDAY := DINT_TO_TOD(TOD_TO_DINT(sun.MIDDAY) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));


Ich kann mich erinnern, dass wir das Thema vor 6 Jahren schon hatten, als der calendar_calc entstand.
Ich hatte zwar auch immer mal wieder festgestellt, dass die Zeiten nicht passen. Da die aber nur bis 24Uhr falsch sind, hatte ich das nicht mehr weiter verfolgt.
Dank NightWatcher sind wir der Lösung wohl nah.

Ich habe mal schnell eine mögliche Änderung im Baustein calendar_cal eingebaut.
Bei einem Sommer/Winterzeitwechsel werden die 3 Funktionen mit dem zwischen 2 und 3 Uhr geänderten DST_ON erneut aufgerufen.
Ich habe die Änderungen mit  (**************) gekennzeichnet.
Kann das so gehen?

Code Auswählen Erweitern


FUNCTION_BLOCK CALENDAR_CALC
VAR_INPUT
SPE : BOOL;
H : REAL := -0.83333333333;
END_VAR
VAR_IN_OUT
XCAL : CALENDAR;
HOLIDAYS : ARRAY[0..29] OF HOLIDAY_DATA;
END_VAR
VAR
last : DT;
last_day : DINT;
holy : HOLIDAY;
sun : SUN_TIME;
last_hour: INT;
utod: TOD;
pos : SUN_POS;
plast: DT;
last_dst_on: BOOL;  (**************)
END_VAR
VAR_TEMP
dtemp : DINT;
tmp : INT;
END_VAR


(*
version 1.6 6. apr. 2011
programmer hugo
tested by oscat

calendar_calc liest die weltzeit .UTC aus einer CALENDAR Struktur und berechnet die restlichen Werte der Struktur.
calendar_calc stellt sicher das die Werte fortlaufend aktualisiert werden und dabei funktionen nur dann aufgerufen werden wenn dies nötig ist.
calendar_calc will calculate sun position data when SPE = TRUE;

*)


(* @END_DECLARATION := '0' *)
IF xcal.UTC <> last THEN
(* run once per second *)
(* update utc last calculated  *)
last := XCAL.UTC;
utod := DT_TO_TOD(xcal.UTC);

(* calculate ltc from utc *)
XCAL.LDT := UTC_TO_LTIME(XCAL.UTC, XCAL.DST_EN, XCAL.OFFSET);
XCAL.LDATE := DT_TO_DATE(XCAL.LDT);
XCAL.LTOD := DT_TO_TOD(XCAL.LDT);
dtemp := DAY_OF_DATE(XCAL.LDATE);
xcal.night := XCAL.LTOD < XCAL.SUN_RISE OR XCAL.LTOD > XCAL.SUN_SET;

(* run once per hour *)
tmp := HOUR(xcal.LTOD);
IF  tmp <> last_hour THEN
XCAL.DST_ON := DST(XCAL.UTC) AND xcal.DST_EN;
last_hour := tmp;
END_IF;

(* run once per day *)
IF dtemp <> last_day THEN
last_day := dtemp;
(* a new day has started, recalculate daily events *)
XCAL.YEAR := YEAR_OF_DATE(XCAL.LDATE);
XCAL.MONTH := MONTH_OF_DATE(XCAL.LDATE);
XCAL.DAY := DAY_OF_MONTH(XCAL.LDATE);
XCAL.WEEKDAY := DAY_OF_WEEK(XCAL.LDATE);
HOLY(date_in := XCAL.LDATE, LANGU := xcal.LANGUAGE, HOLIDAYS := HOLIDAYS);
XCAL.HOLIDAY := HOLY.Y;
XCAL.HOLY_NAME := HOLY.NAME;
sun(latitude := XCAL.LATITUDE, longitude := xcal.LONGITUDE, utc := DT_TO_DATE(xcal.UTC), H := H);
XCAL.SUN_RISE := DINT_TO_TOD(TOD_TO_DINT(sun.sun_rise) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_SET := DINT_TO_TOD(TOD_TO_DINT(sun.sun_set) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_MIDDAY := DINT_TO_TOD(TOD_TO_DINT(sun.MIDDAY) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_HEIGTH := sun.sun_declination;
XCAL.WORK_WEEK := WORK_WEEK(XCAL.LDATE);
END_IF;

(* calculate the suns position every 10 seconds when SPE = TRUE *)
IF SPE AND xcal.UTC -  plast >= t#25s THEN
plast := last;
pos(latitude := xcal.LATITUDE, longitude := xcal.LONGITUDE, utc := xcal.UTC);
xcal.SUN_HOR := pos.B;
xcal.SUN_VER := pos.HR;
END_IF;

(**************)
IF last_dst_on <> XCAL.DST_ON THEN
last_dst_on := XCAL.DST_ON;
XCAL.SUN_RISE := DINT_TO_TOD(TOD_TO_DINT(sun.sun_rise) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_SET := DINT_TO_TOD(TOD_TO_DINT(sun.sun_set) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
XCAL.SUN_MIDDAY := DINT_TO_TOD(TOD_TO_DINT(sun.MIDDAY) + XCAL.OFFSET * 60000 + SEL(XCAL.DST_ON,DINT#0,3600000));
END_IF;
(**************)

END_IF;



@NigthWatcher
Du musst für Deutschland (Zeitzone Berlin) bei

Code Auswählen Erweitern

.xoffset = 60
eintragen.

Der Sonnenauf- und -untergang sind am Tag der Umstellung falsch, heute ist es wieder richtig.
Das ist gerade am Sonntag lästig, wenn die Jalousien falsch fahren.