Nachrichten

46

BECKHOFF / Re: yahoo Weather seit 2019 kein Zugriff mehr auf query.yahooapis.com

« am: 31. Januar 2019, 21:08:32 »

openweathermap.org schien zeitweise eine Alternative zu sein, ich hatte einen entsprechenden Baustein schon erstellt (siehe hier: http://www.oscat.de/community/index.php/topic,2697.0.html). Aber dann hat der Betreiber auch dort das Lizenzmodell geändert, so dass der vom Baustein genutzte Abfragetyp nicht mehr kostenfrei zur Verfügung steht. Wer zufällig schon einen API Key hat, bei dem tut es, neue Keys werden abgewiesen.

Ich selbst habe keine Not, mein Key funktioniert. Wenn man aber einigermaßen programmieren kann, ist es einigermaßen überschaubar einen solchen Baustein abzuwandeln auf einen anderen Dienst. Kostenlose Wetter-APIs gibt es ja wohl noch einige.

In diesem Sinne darf sich jeder eingeladen fühlen, etwas zu tüfteln.

47

BECKHOFF / Re: yahoo Weather seit 2019 kein Zugriff mehr auf query.yahooapis.com

« am: 22. Januar 2019, 12:35:58 »

Siehe hier: http://www.oscat.de/community/index.php/topic,2388.msg16806.html#msg16806

48

Bestehende Module / Existing Modules / Re: Wann schaltet Timer2 das erste mal nach einspielen in CPU?

« am: 07. Dezember 2018, 12:17:29 »

Hallo Underfrange,

aus dem Code gelesen:

• Der Baustein ist sofort nach dem Laden aktiv und überprüft alle 100 ms die aktuelle Uhrzeit gegen die Parametrierung.
• Er schaltet also auch am Tag des Ladens, sobald die eingestellte Uhrzeit erreicht wird (und sofern mode so eingestellt ist, dass am aktuellen Tag überhaupt geschaltet wird).
• Es wird nur einmal pro Tag geschaltet. Der Ausgang bleibt dann für die mittels duration eingestellte Zeit aktiv.
• Schaltet der Baustein also z. B. um 15 Uhr durch und änderst du dann die Schaltzeit auf 20 Uhr, bleibt der Ausgang aktiv, bis duration abgelaufen ist. Er wird am Tag der Änderung um 20 Uhr auch nicht mehr schalten, sondern erst am nächsten.
• Schaltet der Baustein um 15 Uhr und änderst du die Zeit z. B. auf 10 Uhr, ändert auch das nichts am Ausgang. Er bleibt weiterhin aktiv, bis duration abgelaufen ist.
• Dasselbe gilt, wenn der Ausgang zwar nicht aktiv ist, der Baustein heute aber schon einmal geschaltet hat. Auch dann wird eine Änderung der Schaltzeit an diesem Tag ignoriert.
• Steht die Schaltzeit auf 15 Uhr, und du änderst diese z. B. um 10 Uhr auf 11 Uhr ab, dann schaltet der Baustein um 11 Uhr. Denn er hat an diesem Tag ja noch nicht geschaltet.
• Relevant für das (Wieder-)Aktivieren der Schaltzeitüberwachung ist nicht die Zeit seit dem letzten Schalten, sondern der Tag (Datumsänderung).

Das sollten eigentlich alle Fälle sein.

Gruß,
mattsches

49

Andere Projekte / other Projects / Re: Produktion je Minute und Je Stunde

« am: 08. November 2018, 16:42:29 »

Mit Verlaub, aber was erwartest du hier als Antwort? Es ist völlig unklar, was die Applikation macht bzw. machen soll: Welche Funktion die Lichtschranken haben. Was "aussagekräftig" in Bezug auf den gewünschten Wert bedeutet. Welcher Wert überhaupt gesucht ist (tatsächliche Produktion über die letzte Stunde/Minute? Vorhersage der Produktion der nächsten Stunde/Minute?). Wie ein "produziertes Stück" (vermutlich korrekt abgefüllte Flasche?) erkannt wird.

Ich kann nur für mich sprechen. Doch meine Motivation, Zeit zu investieren und mich in dein Problem hineinzudenken, ist eher gering, wenn ich nur einen dürren Satz hingeworfen bekomme.

50

oscat.lib fuer TwinCAT/CoDeSys / Re: Oscat network

« am: 30. Oktober 2018, 12:52:23 »

Und hier beschreibt ein Kollege, wie die Bibliotheken in TC3 einzubinden sind:

http://www.oscat.de/community/index.php/topic,2436.msg13147.html#msg13147

51

oscat.lib fuer TwinCAT/CoDeSys / Re: Oscat network

« am: 30. Oktober 2018, 12:48:13 »

Hallo,

ohne mich mit dem Problem im Detail auszukennen, die Frage kam schon mehrmals, offensichtlich hat es dann mit der Lib doch funktioniert:

http://www.oscat.de/community/index.php/topic,4416
http://www.oscat.de/community/index.php/topic,2226
http://www.oscat.de/community/index.php/topic,2567.msg13346.html#msg13346

52

oscat.lib fuer TwinCAT/CoDeSys / Re: 16Bit in Prozent

« am: 22. Oktober 2018, 22:22:27 »

Beim gleitenden Mittelwert hängt das Ergebnis stark davon ab, wie viele Messwerte gemittelt werden. Aber wenn ich darüber nachdenke - beim MAV_W und FT_AVG sind das maximal 32. Wenn in jedem Zyklus aktualisiert wird kann das je nach Zykluszeit immer noch sehr unruhig sein.

Ich würde daher die Messung langsamer abtasten (z. B. alle 100 ms). Also den AIN in diesem Takt aufrufen (BITS := 15, SIGN := 255, LOW := 0, HIGH := 100) und das Ergebnis über den FT_AVG ziehen. Dann sollte Ruhe einkehren.

53

oscat.lib fuer TwinCAT/CoDeSys / Re: 16Bit in Prozent

« am: 22. Oktober 2018, 12:48:10 »

Hallo Thorsten,

zum Beruhigen von unruhigen Signalen wird dir der DELAY nichts bringen. Der gibt dir dasselbe unruhige Signal lediglich zeitversetzt aus. Üblicherweise bildet man hier einen gleitenden Mittelwert. Für REALs gibt es bei OSCAT den FT_AVG (habe ich noch nicht eingesetzt), für 16 Bit Integer den FILTER_MAV_W. Obacht, der ist allerdings buggy, hier wurde ein Bugfix vorgeschlagen: http://www.oscat.de/community/index.php/topic,1236.0.html.

Ich hatte vor Jahren den FT_AVG übersehen, mir auf Basis von FILTER_MAV_W eine REAL-Variante gebaut und dabei die Fehler im MAV_W für mich korrigiert. Siehe Anhang.

Ob der AIN für die Wandlung in den Messbereich geeignet ist, hängt von deiner Systemkonfiguration ab. Leider schweigst du dich über die Details bzgl. Sensor und dessen Anschluss aus. 4..20 mA/0..10 V an AI-Karte? Feldbus direkt? IO-Link? Ich nehme an, Karte. Dann hängt es von dieser ab, welchen Wert du für 10 V/20 mA (also 100 % des Eingangsbereichs) erhältst. Und damit, ob der AIN passt. Im Zweifel bist du mit dem AIN1 besser beraten, da dieser bzgl. der Skalierung besser parametriert werden kann. Oder du schreibst die drei Zeilen halt selbst.

Gruß,
mattsches

[gelöscht durch Administrator]

54

oscat.lib fuer CoDeSys 3 / Re: Anfänger braucht Hilfe bei dem Holiday Baustein

« am: 18. Oktober 2018, 20:19:50 »

Hi Lugge,

sieh es mir nach, aber in der Tat scheinen hier ein bisschen die Grundlagen der Steuerungsprogrammierung zu fehlen. Die alle zu vermitteln, dürfte für dieses Forum vermutlich zu weit gehen. Insofern sei dir etwas Literatur ans Herz gelegt, irgendein Lehrbuch zu Programmierung nach IEC 61131-1.

Aber kurz zu deiner Frage:

Variablen, die in einer globalen Variablenliste deklariert werden, stehen global zur Verfügung, d. h. man kann von allen Bausteinen aus darauf zugreifen. Im Gegensatz zu Variablen, die im Baustein selbst deklariert werden.

Deklariert man - egal wo - eine Variable nach dem Schema

Code: [Auswählen]

Variablenname : Variablentyp := Initialwert,

dann wird diese beim Anlauf nach einem Reset mit diesem Wert beschrieben. Einmal. Wir im Anwenderprogramm nur lesend auf die Variable zugegriffen, ändert sie ihren Wert also nicht mehr. Aber nochmal: Egal ob in GVL oder Baustein deklariert, sie wird durch die obige Deklaration nicht zyklisch beschrieben.

Für Länge und Breite hatte ich das vorgeschlagen, da ich unterstelle, dass sich diese Werte in Deinem Programm nie ändern werden. Daher genügt es, wenn die Variablen einmalig initialisiert werden, das zyklische Beschreiben im Ablaufprogramm ist schlicht nicht erforderlich. Kostet jetzt nicht wirklich Rechenzeit, ist aber unnötig und macht den Code nur unübersichtlicher.

Wie die Syntax zum Initialisieren von Längen- und Breitengrad aussieht, habe ich ja schon geschrieben. Probier's einfach mal aus.

Gruß,
mattsches

55

oscat.lib fuer CoDeSys 3 / Re: Anfänger braucht Hilfe bei dem Holiday Baustein

« am: 18. Oktober 2018, 16:21:00 »

Hi Lugge,

in GVL folgende Deklaration:

Code: [Auswählen]

Zeitberechnung : CALENDAR := (
Longitude := 12.4238,
Latitude := 48.3936);

Müsste

Analog geht das für weitere Strukturelemente in der Variable "Zeitberechnung".

Gruß,
mattsches

56

oscat.lib fuer CoDeSys 3 / Re: Anfänger braucht Hilfe bei dem Holiday Baustein

« am: 17. Oktober 2018, 20:55:43 »

Hallo Lugge,

uiuiui, da ist aber einiges durcheinander geraten:

• Du hast einen eigenen Datentyp "HOLIDAY_DATA" deklariert, in dem du dann wiederum als ein Element ein Array des Typs HOLIDAY_DATA deklarierst. Daher der Rekursionsfehler (HOLIDAY_DATA verweist damit auf sich selbst).
• Das Element HOLIDAY innerhalb der Struktur ist das, was du eigentlich als globale Variablen anlegen musst. Allerdings nicht als zwei, sondern als eindimensionales Array. Warum deklarierst du mit [1..3, 0..29] und nicht - wie in der Doku beschrieben - mit [0..29]?
• Der von dir deklarierte Datentyp ist überhaupt nicht erforderlich, die Struktur ist bereits in der OSCAT_BASIC komplett deklariert. -> Löschen
• Dasselbe gilt für alle anderen von dir deklarierten Datentypen (CALENDAR, CONSTANTS_*, SDT) -> Ebenfalls löschen
• Eine Deklaration von GVL.HOLIDAYS kann ich auf deinen Screenshots nicht finden. Ich vermute, sie verweist auf deinen eigenen Datentyp HOLIDAY_DATA, und der erste Screenshot ist veraltet?!

Richtig wäre:

• Eine Deklaration GVL.HOLIDAY (oder wie auch immer du die Variable nennen willst) als ARRAY [0..29] of HOLIDAY_DATA. Siehe Beispiel unten für Bayern. Für andere Bundesländer einfach entsprechend anpassen.
• Die übergibst du dann an CALENDAR_CALC.HOLIDAYS.
• Die Typkonvertierungsfehler (TIME vs. DATE_AND_TIME) wirst du auch noch beheben müssen. Irgendwo in den vielen Kopieraktionen werden die beiden Typen vermischt, das bemängelt das eCOCKPIT dann zurecht.
• Parameterdaten wie Länge und Breite würde ich als Initialwerte bei der Deklaration übergeben. Sie ändern sich nie und müssen daher nicht zyklisch auf die Variable geschrieben werden. Wie das geht, siehe ebenfalls unten.

Deklaration von GVL.HOLIDAY:

Code: [Auswählen]

HOLIDAY : ARRAY[0..29] OF HOLIDAY_DATA := [(name := 'Neujahr', day := 1, month := 1, use := 1),
(name := 'Heilig Drei Könige', day := 6, month := 1, use := 1),
(name := 'Karfreitag', day := -2, month := 0, use := 1),
(name := 'Ostersonntag', day := 0, month := 0, use := 1),
(name := 'Ostermontag', day := 1, month := 0, use := 1),
(name := 'Tag der Arbeit', day := 1, month := 5, use := 1),
(name := 'Christi Himmelfahrt', day := 39, month := 0, use := 1),
(name := 'Pfingstsonntag', day := 49, month := 0, use := 1),
(name := 'Pfingstmontag', day := 50, month := 0, use := 1),
(name := 'Fronleichnam', day := 60, month := 0, use := 1),
(name := 'Augsburger Friedensfest', day := 8, month := 8, use := 0),
(name := 'Maria Himmelfahrt', day := 15, month := 8, use := 1),
(name := 'Tag der Deutschen Einheit', day := 3, month := 10, use := 1),
(name := 'Reformationstag', day := 31, month := 10, use := 0),
(name := 'Allerheiligen', day := 1, month := 11, use := 1),
(name := 'Buss und Bettag', day := 23, month := 11, use := 0),
(name := '1. Weihnachtstag', day := 25, month := 12, use := 1),
(name := '2. Weihnachtstag', day := 26, month := 12, use := 1)];

Iniitalwert bei Deklaration übergeben:

MyNewInt : INT := 123;  // Variable wird nach einem Kaltstart der Steuerung mit 123 initialisiert

Gruß,
mattsches

57

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

« am: 27. September 2018, 16:58:16 »

Das ist der Punkt. Ich habe ja oben schon darauf hingewiesen, dass alte Keys noch funktionieren, neue jedoch nicht mehr. Für diejenigen, die einen neuen Key anlegen müssen, ist der Baustein nicht nutzbar. Leider.

58

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

« am: 27. September 2018, 16:47:00 »

Auch wenn ich jetzt Wasser in den Wein gieße, die Arbeit war zumindest nicht optimal investiert. Denn:

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.

Diese Einschränkung gilt weiterhin, die tagesgenaue Vorhersage ist mit neu generierten API-Keys nicht kostenlos nutzbar.

Mit welchem API-Key hast Du denn getestet?

59

Modulentwicklung / Re: API Wetter.com CoDeSys

« am: 27. September 2018, 16:40:22 »

Jau, auch openweathermap.org haben die Lizenzbedingungen zu unseren Ungunsten geändert. Leider.

60

oscat.lib fuer CoDeSys 3 / Re: Anfänger braucht Hilfe bei dem Holiday Baustein

« am: 25. September 2018, 15:28:33 »

Probiere es mal mit zusätzlichen eckigen Klammern um die Arrayelemente:

Code: [Auswählen]

HOLIDAY_DE ... := [( ...
... )];