31
Modulentwicklung / Re: Neuer Wetter-Baustein für Weatherbit.io
« am: 28. August 2019, 19:56:30 »
Sorry, bin gerade im Urlaub. Wird noch etwas dauern.
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.
32
oscat.lib fuer CoDeSys 3 / Re: DLOG_STORE_FILE_CSV
« am: 14. August 2019, 12:35:49 »
Importing CODESYS V2.3 project data in V3.5 is only supported by the 32 bit V3.5 version (see here: https://forum.codesys.com/viewtopic.php?t=8720). And you can only import full projects or libraries, not single V2.3 export files.
But why don't you just download the network.lib package from the CODESYS Store and install it? In addition to the installation in the library repository, this will copy the whole library in your user folder. In there, you can find the example programs.
But why don't you just download the network.lib package from the CODESYS Store and install it? In addition to the installation in the library repository, this will copy the whole library in your user folder. In there, you can find the example programs.
33
BECKHOFF / Re: MB_SERVER mit OpenHAB
« am: 03. August 2019, 20:30:26 »
Seb beteiligt sich ja schon gar nicht mehr an der Diskussion. Und dass der OpenHAB Modbus Client die Verbindung für jede Abfrage auf- und wieder abbaut, ist völlig unstrittig, Seb hatte das ja explizit bestätigt. Ich hatte dann lediglich klargestellt, dass das - entgegen Sebs These - kein regelkonformes Verhalten ist. Also gibt es aus meiner Sicht keine Unklarheiten.
Offen ist allerdings, ob der IP_CONTROL nach einem FIN evtl. den Port tatsächlich nicht sofort schließt, sondern das dann über einen Timeout geschieht.
Aber wie gesagt, Seb scheint hier raus zu sein, ich sehe ehrlich gesagt keine Notwendigkeit für weitere Nachforschungen. Wenn man nicht aus Liebhaberei nach obigem Punkt schauen möchte. Ich empfinde die gerade nicht. ;-)
Offen ist allerdings, ob der IP_CONTROL nach einem FIN evtl. den Port tatsächlich nicht sofort schließt, sondern das dann über einen Timeout geschieht.
Aber wie gesagt, Seb scheint hier raus zu sein, ich sehe ehrlich gesagt keine Notwendigkeit für weitere Nachforschungen. Wenn man nicht aus Liebhaberei nach obigem Punkt schauen möchte. Ich empfinde die gerade nicht. ;-)
34
BECKHOFF / Re: MB_SERVER mit OpenHAB
« am: 02. August 2019, 20:57:23 »
peewit,
die der vorherige Eintrag (von dem ich annehme, dass du dich auf ihn beziehst) kam von mir, nicht vom TO.
Gruß,
m.
die der vorherige Eintrag (von dem ich annehme, dass du dich auf ihn beziehst) kam von mir, nicht vom TO.
Gruß,
m.
35
BECKHOFF / Re: MB_SERVER mit OpenHAB
« am: 31. Juli 2019, 14:29:57 »
Ohne beurteilen zu können, ob der IP_CONTROL den Port nicht sauber schließt (was grundsätzlich ja nicht ausgeschlossen ist) möchte ich dir bzgl. des Verbindungsmanagements widersprechen. Es ist keinesfalls so, dass mit jedem Lese- oder Schreibzugriff eine Verbindung auf- und danach gleich wieder abgebaut werden soll. Die von dir verlinkte Seite sagt das so auch nicht. Und wenn man in den (tatsächlich offiziellen) Implementierungsguide schaut, dann liest man genau das Gegenteil:
Quelle: http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
Insofern ist die Implementierung in OpenHAB zumindest fragwürdig.
Das Verhalten des IP_CONTROL scheint mir allerdings ebenfalls untersuchenswert. Den Socket zu schließen, sollte keine 10 Sekunden dauern; das sieht auch mir nach einem Timeout aus.
Zitat
Implementation Rules:
1) Without explicit user requirement, it is recommended to implement the automatic TCP connection management
2) It is recommended to keep the TCP connection opened with a remote device and not to open and close it for each MODBUS/TCP transaction. Remark: However the MODBUS client must be capable of accepting a close request from the server and closing the connection. The connection can be reopened when required.
Quelle: http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
Insofern ist die Implementierung in OpenHAB zumindest fragwürdig.
Das Verhalten des IP_CONTROL scheint mir allerdings ebenfalls untersuchenswert. Den Socket zu schließen, sollte keine 10 Sekunden dauern; das sieht auch mir nach einem Timeout aus.
36
Modulentwicklung / Re: Neuer Baustein zum Parsen von JSON-Streams
« am: 22. Juli 2019, 20:16:35 »
Tja, das ist natürlich eine gute Frage. Mit Openweathermap hat es ja nicht allzu lange geklappt. Mal schauen, wie es bei Weatherbit aussieht.
Das Gute ist, dass mit dem JSON_PARSER nun eine größere Zahl von Wetter-APIs genutzt werden kann, da immer mehr Anbieter auf JSON umzusteigen scheinen. Einen solchen neuen Dienst anzuzapfen, ist ja dann keine große Sache mehr.
Das Gute ist, dass mit dem JSON_PARSER nun eine größere Zahl von Wetter-APIs genutzt werden kann, da immer mehr Anbieter auf JSON umzusteigen scheinen. Einen solchen neuen Dienst anzuzapfen, ist ja dann keine große Sache mehr.
37
Modulentwicklung / Re: OSCAT-NETWORK-LIB 1.35 TESTVERSION
« am: 21. Juli 2019, 21:41:45 »
Für alle die, die Bedarf für einen Wetter-Baustein haben, ich habe einen neuen Baustein für die Abfrage von Wetterdaten von Weatherbit.io erstellt. Damit ist eine zumindest aktuell funktionierende Alternative gefunden. Details siehe hier: http://www.oscat.de/community/index.php/topic,4952.0.html
38
Modulentwicklung / Re: Neuer Wetter-Baustein für openweathermap.org
« am: 21. Juli 2019, 21:37:00 »
Falls hier jemand auf der Suche nach einem Wetter-Baustein hereinschauen sollte: Es gibt zwischenzeitlich mit Weatherbit.io eine Alternative. Näheres siehe hier: http://www.oscat.de/community/index.php/topic,4952.0.html
39
Modulentwicklung / Neuer Baustein zum Parsen von JSON-Streams
« am: 21. Juli 2019, 21:35:59 »
Hallo,
wie beim neuen Wetterbaustein für Weatherbit.io bereits erwähnt (siehe http://www.oscat.de/community/index.php/topic,4952.0.html) habe ich einen neuen Bausteinen für das Parsen von JSON-Streams geschrieben. Gedankliche Vorlage war der XML_READER, der Aufbau und die Ansteuerung unterscheiden sich allerdings doch ziemlich gegenüber diesem.
Ich rechne nicht damit, dass die breite Masse Verwendung für einen solchen Baustein hat, daher spare ich mir eine genauere Beschreibung an dieser Stelle. Sollte hierfür Bedarf bestehen, bitte einfach melden, dann liefere ich sie gerne nach.
peewit, du könntest dir überlegen, ob der Bausteinen einen Platz in einer neuen Version der network.lib finden soll, dann sinnvollerweise gemeinsam mit dem Weatherbit-Baustein. Die Doku kann ich dann gerne übernehmen; die Portierung auf Steuerungssysteme abseits von CODESYS müssten dann andere Mitglieder der OSCAT-Community übernehmen, die dafür Verwendung haben.
Der JSON_READER ist als CODESYS V2.3/TwinCAT 2-Export angehängt. Eine CODESYS V3.5-Variante kann ich gerne bei Bedarf nachliefern.
Cheers,
mattsches
wie beim neuen Wetterbaustein für Weatherbit.io bereits erwähnt (siehe http://www.oscat.de/community/index.php/topic,4952.0.html) habe ich einen neuen Bausteinen für das Parsen von JSON-Streams geschrieben. Gedankliche Vorlage war der XML_READER, der Aufbau und die Ansteuerung unterscheiden sich allerdings doch ziemlich gegenüber diesem.
Ich rechne nicht damit, dass die breite Masse Verwendung für einen solchen Baustein hat, daher spare ich mir eine genauere Beschreibung an dieser Stelle. Sollte hierfür Bedarf bestehen, bitte einfach melden, dann liefere ich sie gerne nach.
peewit, du könntest dir überlegen, ob der Bausteinen einen Platz in einer neuen Version der network.lib finden soll, dann sinnvollerweise gemeinsam mit dem Weatherbit-Baustein. Die Doku kann ich dann gerne übernehmen; die Portierung auf Steuerungssysteme abseits von CODESYS müssten dann andere Mitglieder der OSCAT-Community übernehmen, die dafür Verwendung haben.
Der JSON_READER ist als CODESYS V2.3/TwinCAT 2-Export angehängt. Eine CODESYS V3.5-Variante kann ich gerne bei Bedarf nachliefern.
Cheers,
mattsches
40
Modulentwicklung / Neuer Wetter-Baustein für Weatherbit.io
« am: 21. Juli 2019, 21:28:09 »
Hallo zusammen,
nachdem openweathermap.org auch für die bestehenden API Keys die tagesgenaue Wettervorhersage abgeschaltet hat, stand ich wieder einmal vor dem Problem, keine Wetterdaten zu bekommen. Yahoo und World Weather sind ja bekanntlich schon länger tot.
Also habe ich mich mal wieder an das Thema gesetzt und einen neuen Baustein geschrieben. Dieses Mal für Weatherbit.io. Dort enthält der kostenlose API-Zugang die tagesgenauen Daten - hoffen wir, dass das so bleibt.
Eine kleine Hürde war die Bereitstellung der Daten durch den Dienst. Weatherbit.io liefert (wie zwischenzeitlich viele andere Dienste auch) die Daten nicht im XML-, sondern im JSON-Format aus. Also musste im selben Zuge noch ein JSON-Parser her.
Zum Wetterbaustein: Die Handhabung ist ähnlich wie bei YAHOO_WEATHER:
Es werden Daten für den aktuellen und die vier folgenden Tage abgerufen. Einheiten sind metrisch + °C; Imperial und Fahrenheit habe ich mir gespart, könnten aber leicht nachgerüstet werden.
Der neue JSON_READER wird vom Weatherbit-Baustein intern genutzt und ist in der angehängten Exportdatei bereits enthalten.
Das Ganze gibt es aktuell für CODESYS V2.3/TwinCAT 2. Eine Portierung auf CODESYS V3.5 ist sehr einfach möglich, eine angepasste Quelle kann ich bei Bedarf gerne nachliefern.
Bitte habt bei Fragen Verständnis, dass ich u. U. nicht sofort antworte. Ich schaue hier nicht unbedingt jeden Tag rein, schon gar nicht bei dem Wetter.
Viel Spaß!
nachdem openweathermap.org auch für die bestehenden API Keys die tagesgenaue Wettervorhersage abgeschaltet hat, stand ich wieder einmal vor dem Problem, keine Wetterdaten zu bekommen. Yahoo und World Weather sind ja bekanntlich schon länger tot.
Also habe ich mich mal wieder an das Thema gesetzt und einen neuen Baustein geschrieben. Dieses Mal für Weatherbit.io. Dort enthält der kostenlose API-Zugang die tagesgenauen Daten - hoffen wir, dass das so bleibt.
Eine kleine Hürde war die Bereitstellung der Daten durch den Dienst. Weatherbit.io liefert (wie zwischenzeitlich viele andere Dienste auch) die Daten nicht im XML-, sondern im JSON-Format aus. Also musste im selben Zuge noch ein JSON-Parser her.
Zum Wetterbaustein: Die Handhabung ist ähnlich wie bei YAHOO_WEATHER:
- Variable anlegen, in der die Wetterdaten bereitgestellt werden sollen (Typ WEATHERBIT_DATA)
- Gewünschten Ort mittels CITY_ID an den Baustein übergeben (Liste mit verfügbaren IDs siehe https://www.weatherbit.io/api/meta)
- API Key übergeben (dazu bei Weatherbit registrieren unter https://www.weatherbit.io/account/create)
- IP_C, S_BUF, R_BUF und IP_CONTROL-Aufruf wie bei YAHOO_WEATHER beschrieben
- Start der Abfrage mittels positiver Flanke an ACTIVATE
Es werden Daten für den aktuellen und die vier folgenden Tage abgerufen. Einheiten sind metrisch + °C; Imperial und Fahrenheit habe ich mir gespart, könnten aber leicht nachgerüstet werden.
Der neue JSON_READER wird vom Weatherbit-Baustein intern genutzt und ist in der angehängten Exportdatei bereits enthalten.
Das Ganze gibt es aktuell für CODESYS V2.3/TwinCAT 2. Eine Portierung auf CODESYS V3.5 ist sehr einfach möglich, eine angepasste Quelle kann ich bei Bedarf gerne nachliefern.
Bitte habt bei Fragen Verständnis, dass ich u. U. nicht sofort antworte. Ich schaue hier nicht unbedingt jeden Tag rein, schon gar nicht bei dem Wetter.
Viel Spaß!
41
oscat.lib fuer TwinCAT/CoDeSys / Re: Oscat.lib fehlt !!!
« am: 20. Mai 2019, 17:01:41 »
Genau. Du brauchst die Basic. In der Building ist offenbar noch die Referenz auf einen alten Dateinamen drin.
Du kannst aber einfach beide Bibliotheken in dein Steuerungsprojekt einfügen, und gut ist. Wegen Ressourcen brauchst du dir keine Sorgen zu machen, im Kompilat landen nur die Bausteine aus den Libs, die du im Code auch verwendest. Overhead entsteht da keiner. Und die Nutzung ist so entschieden einfacher, als wenn du dir einzelne Bausteine in dein Anwenderprogramm kopierst. Denn dann musst du den ganzen Abhängigkeiten (aufgerufene andere Bausteine, in deinem Fall jetzt aus einer anderen Bibliothek) nachgehen.
Du kannst aber einfach beide Bibliotheken in dein Steuerungsprojekt einfügen, und gut ist. Wegen Ressourcen brauchst du dir keine Sorgen zu machen, im Kompilat landen nur die Bausteine aus den Libs, die du im Code auch verwendest. Overhead entsteht da keiner. Und die Nutzung ist so entschieden einfacher, als wenn du dir einzelne Bausteine in dein Anwenderprogramm kopierst. Denn dann musst du den ganzen Abhängigkeiten (aufgerufene andere Bausteine, in deinem Fall jetzt aus einer anderen Bibliothek) nachgehen.
42
oscat.lib fuer TwinCAT/CoDeSys / Re: Oscat.lib fehlt !!!
« am: 20. Mai 2019, 13:02:43 »
Ähm - http://www.oscat.de/component/jdownloads/category/2-oscat-basic.html
Aber Deinen Posts nach zu urteilen hast du die Bibliotheken doch schon geraume Zeit im Einsatz?!
Aber Deinen Posts nach zu urteilen hast du die Bibliotheken doch schon geraume Zeit im Einsatz?!
43
Codesys 2 / Re: Error_C bei Yahoo Weather
« am: 12. Februar 2019, 13:17:05 »has anyone solved the problem ?
As you can read just one post before your initial one, Yahoo has discontinued the weather API service that was used by the function block. In favor of a new API with a higher security level.
So the current function block cannot be used anymore. Period. Until somebody takes the time to reprogram it to match the new interface. Provided that the neccessary security features can be handled at all.
44
Ankündigungen / Announcements / Re: OSCAT auf Github
« am: 07. Februar 2019, 20:43:56 »Hallo zusammen,
wie bereits angekündigt hat das EBC der RWTH Aachen University damit begonnen die OSCAT Bibliothek in ihr Git-Repository zu mirgieren.
Unter https://github.com/RWTH-EBC/AixOCAT findet ihr neben der OSCAT Bibliothek auch Erweiterungen, Beispielprogramme und ein Wiki.
Wir freuen uns auf eure Unterstützung.
Viele Grüße
Markus
Hallo Markus,
was ist denn aus euren Aktivitäten geworden? Wenn ich so ins Repo schaue, ist da ziemlich tote Hose. Außer dass die Quellcodes hineinkopiert wurden, hat sich nach allem, was ich sehen kann, nciht wirklich etwas getan. Auch auf Tobias' sehr berechtigte Frage nach der Toolchain für das (automatisierte) Bauen der Bibliotheken aus den Quellen gab es keine Reaktion.
Kann es sein, dass dads Ganze sehr schnell wieder zum Erliegen gekommen ist? Dann fände ich es sinnvoll, das Repo wieder zu löschen. Denn sonst gibt es eine weitere zukünftig veraltete Quelle für OSCAT-Bausteine. Dass das nicht gerade hilfreich ist, kann man an den mittlerweile veralteten Versionen im CODESYS Store sehen.
Wie stehst du, wie steht ihr (also die RWTH) dazu?
Gruß,
mattsches
45
oscat.lib fuer CoDeSys 3 / Re: ONTIME Fehler im Quellcode
« am: 07. Februar 2019, 20:39:27 »
Das hast Du völlig Recht. Ich hatte übersehen, dass ekki offenbar eine veraltete Version im Einsatz hatte. Die genannte Version 2.5 des Bausteins korrigiert den Fehler tatsächlich, datiert zurück auf 2011 (!) und ist seit mindestens Anfang 2012 auch im offiziellen OSCAT-Downloadbereich im Rahmen der OSCAT_BASIC 3.33 zu haben: http://www.oscat.de/component/jdownloads/category/2-oscat-basic.html?Itemid=0
Der Github-Fork wurde vor zehn Monaten angelegt. Allerdings herrscht dort nach allem, was ich sehen kann, ziemlich tote Hose. Ich habe jedenfalls keinen Baustein gefunden, der geändert wurde. Vielleicht liegt das an der fehlenden Toolchain. Denn wie kommt man von den vielen Quellen im Repo z. B. zu einer übersetzten CODESYS-Bibliothek? In der Firma würden wir das über einen Buildserver machen. Doch OSCAT wird soweit ich das verstehe in der Freizeit von einzelnen Motivierten betrieben. Bzw. nur noch einem verbliebenen - Peewit. Damit das Ganze auf GitHub funktioniert, müsste die RWTH Aachen in meinen Augen automatisiert das Bauen der Bibliotheken aus den Quellen übernehmen und das Ergebnis dann z. B. wieder auf GitHub pushen. Das wäre schon eine coole Sache. Ob die dortige Begeisterung so weit reicht, daran habe ich in Anbetracht der Zeitstempel meine Zweifel. Tobias hat sich in einem Beitrag ähnlich geäußert, im Juni letzten Jahres (http://www.oscat.de/community/index.php/topic,4425.msg16579.html#msg16579). Darauf gab es allerdings keine Reaktion. Aber das ist jetzt ziemlich off topic, sorry...
brro, danke für den Hinweis. Ekki, du solltest mal deine Bibliotheken aktualisieren...
Der Github-Fork wurde vor zehn Monaten angelegt. Allerdings herrscht dort nach allem, was ich sehen kann, ziemlich tote Hose. Ich habe jedenfalls keinen Baustein gefunden, der geändert wurde. Vielleicht liegt das an der fehlenden Toolchain. Denn wie kommt man von den vielen Quellen im Repo z. B. zu einer übersetzten CODESYS-Bibliothek? In der Firma würden wir das über einen Buildserver machen. Doch OSCAT wird soweit ich das verstehe in der Freizeit von einzelnen Motivierten betrieben. Bzw. nur noch einem verbliebenen - Peewit. Damit das Ganze auf GitHub funktioniert, müsste die RWTH Aachen in meinen Augen automatisiert das Bauen der Bibliotheken aus den Quellen übernehmen und das Ergebnis dann z. B. wieder auf GitHub pushen. Das wäre schon eine coole Sache. Ob die dortige Begeisterung so weit reicht, daran habe ich in Anbetracht der Zeitstempel meine Zweifel. Tobias hat sich in einem Beitrag ähnlich geäußert, im Juni letzten Jahres (http://www.oscat.de/community/index.php/topic,4425.msg16579.html#msg16579). Darauf gab es allerdings keine Reaktion. Aber das ist jetzt ziemlich off topic, sorry...
brro, danke für den Hinweis. Ekki, du solltest mal deine Bibliotheken aktualisieren...